Ignorer les commandes du ruban
Passer au contenu principal
SharePoint

Networking

août 17
Route Reflector configuration in a basic MPLS network supporting L3VPN service (IOS-XE)

In a previous article you learned how to build a basic L3VPN for a customer owning two distant sites. In this article we extend the topology by adding a VPNv4 route reflector. We modified a bit the addressing plan according to RFC3021 which allow the use of /31 subnets mask for point-to-point links and RFC6752 which recommand to use officially allocated public addresses for infrastructure links and loopbacks. We assume that we received from our RIR the block 23.0.0.0/8.

Cabling

 

 

Same calbing plan as in the previous article plus a new link between router P and the route reflector (RR).

Point-to-point links are emulated via dedicated VLANs on a vSwitch. For example, link between P (R3) and RR (R6) is emulated via VLAN 50 :

 

Addressing

 

23.0.0.0/24 is dedicated to PE routers and RR loopbacks.

23.0.1.0/24 is dedicated for infrastructure links.

 

RR configuration

 

 

In our previous article, PE1 and PE2 were peering VPNv4 routes directly. To support adding multiple VPN PE routers without maintaining a full meshed iBGP network, we add a VPNv4 route reflector in our topology.

On R6 (RR), we configure a peer group including each VPN PE in order to reduce configuration overhead when adding more VPN PE in the future (it's also simplify BGP update message generation on the router). We disable ipv4 peering because we dedicate this router to vpnv4 route reflection. Notice the « route-reflector-client »  command under vpnv4 address family :

 

Interface Loopback0
ip address 23.0.0.3 255.255.255.255
!
! MPLS is not needed on this link as it is not intended that VPN
! traffic will be forwarded by the route reflector
interface GigabitEthernet2
ip address 23.0.1.4 255.255.255.254
negotiation auto
!
router ospf 1
network 23.0.0.0 0.0.0.255 area 0
network 23.0.1.0 0.0.0.255 area 0
!
router bgp 1
bgp log-neighbor-changes
neighbor VPN-PE peer-group
neighbor VPN-PE remote-as 1
neighbor VPN-PE update-source Loopback0
neighbor 23.0.0.1 peer-group VPN-PE
neighbor 23.0.0.2 peer-group VPN-PE
!
address-family ipv4
no neighbor 23.0.0.1 activate
no neighbor 23.0.0.2 activate
exit-address-family
!
address-family vpnv4
neighbor VPN-PE send-community extended
neighbor VPN-PE route-reflector-client
neighbor 23.0.0.1 activate
neighbor 23.0.0.2 activate
exit-address-family

     

On PE1, we also configure a peer-group including the route reflector for the same reasons as mentioned above in the case we decide to add a second route reflector for redundancy :

 

router bgp 1
bgp log-neighbor-changes
neighbor VPN-RR peer-group
neighbor VPN-RR remote-as 1
neighbor VPN-RR update-source Loopback0
neighbor 23.0.0.3 peer-group VPN-RR
!
address-family ipv4
no neighbor 23.0.0.3 activate
exit-address-family
!
address-family vpnv4
neighbor VPN-RR send-community extended
neighbor 23.0.0.3 activate
exit-address-family

     

Configuration is similar on PE2.

Verifications :

 

PE1#show ip route vrf CUSTOMER1
snip
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 2 subnets
B 172.16.100.0 [20/0] via 192.168.0.0, 23:12:20
B 172.16.200.0 [200/0] via 23.0.0.2, 01:38:46
192.168.0.0/24 is variably subnetted, 3 subnets, 2 masks
C 192.168.0.0/31 is directly connected, GigabitEthernet2
L 192.168.0.1/32 is directly connected, GigabitEthernet2
B 192.168.0.2/31 [200/0] via 23.0.0.2, 01:38:46
CE1#ping 172.16.200.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.200.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/8/15 ms
août 01
Basic MPLS L3VPN configuration on IOS XE

In this article, we show you how to build a basic VPRN : an ISP network composed of 1 core router interconnecting two customer sites on 2 different edge routers. OSPF is used as an IGP and customer's routers are peering with ISP router using eBPG. After completing steps below, hosts on each sites should ping each other.

Software used in this scenario :

  • Hypervisor : VMware ESXi 6.0.0 build-2494585
  • Routers : CSR1000V, IOS XE Version 03.15.00.S, IOS Version 15.5(2)S

Step 1 : cabling routers

Routers and hosts are connected using VLANs on a same vSwtich to emulate direct connections.



Step 2 : addressing and IGP configuration and MPLS activation


We begin configuring CE1, this router is not part of the backbone, neither MPLS nor IGP is needed :

interface GigabitEthernet2
 ip address 192.168.10.1 255.255.255.252
 negotiation auto
!
interface GigabitEthernet3
 ip address 172.16.100.254 255.255.255.0
 negotiation auto


On PE1, we activate MPLS toward the core router that only switch label packets. We also activate OSPF on the core facing interface for the edge router to be known (routed) within the backbone. Notice that customer facing interface is added to a VRF :

ip vrf CUSTOMER1
 rd 64512:1
 route-target export 64512:1
 route-target import 64512:1
!
interface GigabitEthernet2
 ip vrf forwarding CUSTOMER1
 ip address 192.168.10.2 255.255.255.252
 negotiation auto
!
interface GigabitEthernet3
 ip address 192.168.20.1 255.255.255.252
 negotiation auto
 mpls ip
!
router ospf 1
 network 192.168.20.0 0.0.0.3 area 0


On P router, we activate OSPF and MPLS on both links :

interface GigabitEthernet2
 ip address 192.168.20.2 255.255.255.252
 negotiation auto
 mpls ip
!
interface GigabitEthernet3
 ip address 192.168.30.2 255.255.255.252
 negotiation auto
 mpls ip
!
router ospf 1
 network 192.168.20.0 0.0.0.3 area 0
 network 192.168.30.0 0.0.0.3 area 0


Configuration on PE2 and CE2 is not detailed because it is similar to PE1 and CE1 configuration.

Verifications :

! to check on which interface MPLS is activated
PE1#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
GigabitEthernet3       Yes (ldp)     No       No  No     Yes
 
! to check LDP ID, and LDP Hello messages received if any
PE1#show mpls ldp discovery
 Local LDP Identifier:
    192.168.20.1:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet3 (ldp): xmit/recv
            LDP Id: 192.168.30.2:0
 
! to check LDP session
PE1#show mpls ldp neighbor
    Peer LDP Ident: 192.168.30.2:0; Local LDP Ident 192.168.20.1:0
        TCP connection: 192.168.30.2.51582 - 192.168.20.1.646
        State: Oper; Msgs sent/rcvd: 6/6; Downstream
        Up time: 00:00:53
        LDP discovery sources:
          GigabitEthernet3, Src IP addr: 192.168.20.2
        Addresses bound to peer LDP Ident:
          192.168.30.2    192.168.20.2
 
! to check ospf adjacency
PE1#show ip ospf neighbor
 
Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.30.2      1   FULL/BDR        00:00:30    192.168.20.2    GigabitEthernet3

Step 3 : configuring eBGP peering

 

On CE1,

router bgp 64512
 bgp log-neighbor-changes
 redistribute connected
 neighbor 192.168.10.2 remote-as 4200000000

 

On PE1,

router bgp 4200000000
 bgp log-neighbor-changes
 !
 address-family ipv4 vrf CUSTOMER1
  neighbor 192.168.10.1 remote-as 64512
  neighbor 192.168.10.1 activate
 exit-address-family

 

Verifications :

! to check eBGP session
PE1#show bgp all summary
snip
 
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.10.1    4        64512      15      15        3    0    0 00:09:56        2
 
! to check prefixes learned
PE1#show bgp vpnv4 unicast vrf CUSTOMER1
snip
 
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 64512:1 (default for vrf CUSTOMER1)
 *>  172.16.100.0/24  192.168.10.1             0             0 64512 ?
 r>  192.168.10.0/30  192.168.10.1             0             0 64512 ?
 
! to check RIB insertion
PE1#show ip route vrf CUSTOMER1
Routing Table: CUSTOMER1
snip
 
Gateway of last resort is not set
 
      172.16.0.0/24 is subnetted, 1 subnets
B        172.16.100.0 [20/0] via 192.168.10.1, 00:05:17
      192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.10.0/30 is directly connected, GigabitEthernet2
L        192.168.10.2/32 is directly connected, GigabitEthernet2

Step 4 : configuring MP-BGP


On PE1, we configure iBGP peering with P2 to exchange VPNv4 routes via MP-BGP :

 bgp log-neighbor-changes
 neighbor 192.168.30.1 remote-as 4200000000
 !
 address-family vpnv4
  neighbor 192.168.30.1 activate
  neighbor 192.168.30.1 send-community extended
 exit-address-family

 

Similar configuration is done on PE2.

Verifications :

  
! to check iBGP session
PE1#show bgp vpnv4 unicast all summary
snip
 
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.10.1    4        64512      21      22        9    0    0 00:15:40        2
192.168.30.1    4   4200000000      15      15        9    0    0 00:08:10        2
 
! to check prefixes learned
PE1#show bgp vpnv4 unicast all
snip
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 64512:1 (default for vrf CUSTOMER1)
 *>  172.16.100.0/24  192.168.10.1             0             0 64512 ?
 *>i 172.16.200.0/24  192.168.30.1             0    100      0 64512 ?
 r>  192.168.10.0/30  192.168.10.1             0             0 64512 ?
 *>i 192.168.40.0/30  192.168.30.1             0    100      0 64512 ?
 
! to check RIB import
PE1#show ip route vrf CUSTOMER1
 
Routing Table: CUSTOMER1
snip
 
Gateway of last resort is not set
 
      172.16.0.0/24 is subnetted, 2 subnets
B        172.16.100.0 [20/0] via 192.168.10.1, 00:18:38
B        172.16.200.0 [200/0] via 192.168.30.1, 00:11:57
      192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.10.0/30 is directly connected, GigabitEthernet2
L        192.168.10.2/32 is directly connected, GigabitEthernet2
      192.168.40.0/30 is subnetted, 1 subnets
B        192.168.40.0 [200/0] via 192.168.30.1, 00:11:57
 
! problem, on CE1, routes from CE2 are not learned from PE1 :
CE1#show ip route
snip
 
Gateway of last resort is not set
 
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.100.0/24 is directly connected, GigabitEthernet3
L        172.16.100.254/32 is directly connected, GigabitEthernet3
      192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.10.0/30 is directly connected, GigabitEthernet2
L        192.168.10.1/32 is directly connected, GigabitEthernet2
CE1#show ip bgp
snip
 
     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.100.0/24  0.0.0.0                  0         32768 ?
 *>  192.168.10.0/30  0.0.0.0                  0         32768 ?

First issue

If we activate BGP updates debugging on CE1, we can see that CE2's routes are announced by PE1 but denied by CE1 :

CE1#terminal monitor
CE1#debug bgp ipv4 unicast updates
BGP updates debugging is on for address family: IPv4 Unicast
CE1#clear bgp ipv4 un 192.168.10.2
CE1#
*Jul 19 2016 12:12:15.842 CEST: %BGP-3-NOTIFICATION: sent to neighbor 192.168.10.2 6/4 (Administrative Reset) 0 bytes
*Jul 19 2016 12:12:15.843 CEST: %BGP-5-ADJCHANGE: neighbor 192.168.10.2 Down User reset
*Jul 19 2016 12:12:15.843 CEST: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.10.2 IPv4 Unicast topology base removed from session  User reset
*Jul 19 2016 12:12:15.895 CEST: %BGP-5-ADJCHANGE: neighbor 192.168.10.2 Up
CE1#
*Jul 19 2016 12:12:15.896 CEST: BGP(0): (base) 192.168.10.2 send UPDATE (format) 172.16.100.0/24, next 192.168.10.1, metric 0, path Local
*Jul 19 2016 12:12:15.899 CEST: BGP(0): 192.168.10.2 rcv UPDATE w/ attr: nexthop 192.168.10.2, origin ?, originator 0.0.0.0, merged path 4200000000 64512, AS_PATH , community , extended community , SSA attribute
*Jul 19 2016 12:12:15.899 CEST: BGPSSA ssacount is 0
*Jul 19 2016 12:12:15.899 CEST: BGP(0): 192.168.10.2 rcv UPDATE about 172.16.200.0/24 -- DENIED due to: AS-PATH contains our own AS;
*Jul 19 2016 12:12:15.899 CEST: BGP(0): 192.168.10.2 rcv UPDATE about 192.168.40.0/30 -- DENIED due to: AS-PATH contains our own AS;

This is a normal behavior : routes are rejected by CE1 because AS-PATH attribute contains CE1's AS number. This is the well known BGP loop prevention mechanism. One solution is to delete CE's AS number from the AS-PATH :

PE1(config)#router bgp 4200000000
PE1(config-router)#address-family ipv4 vrf CUSTOMER1
PE1(config-router-af)#neighbor 192.168.10.1 as-override

 

With the « as-override » command, BGP router rewrite AS-PATH attribute before sending BGP update replacing customer's AS number 64512 with it's own AS number 4200000000. This time, BGP updates are accepted by CE1 and routes are installed in CE1's RIB, notice the modified AS-PATH :

CE1#show ip bgp
snip
     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.100.0/24  0.0.0.0                  0         32768 ?
 *>  172.16.200.0/24  192.168.10.2                           0 4200000000 4200000000 ?
 *>  192.168.10.0/30  0.0.0.0                  0         32768 ?
 *>  192.168.40.0/30  192.168.10.2                           0 4200000000 4200000000 ?
 
CE1#show ip route
snip
 
      172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C        172.16.100.0/24 is directly connected, GigabitEthernet3
L        172.16.100.254/32 is directly connected, GigabitEthernet3
B        172.16.200.0/24 [20/0] via 192.168.10.2, 00:18:44
      192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.10.0/30 is directly connected, GigabitEthernet2
L        192.168.10.1/32 is directly connected, GigabitEthernet2
      192.168.40.0/30 is subnetted, 1 subnets
B        192.168.40.0 [20/0] via 192.168.10.2, 00:18:44

 

Now let's try to test connectivity between customer sites by pinging CE2's internal interface:

CE1#ping 172.16.200.254 source 172.16.100.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.200.254, timeout is 2 seconds:
Packet sent with a source address of 172.16.100.254
.....
Success rate is 0 percent (0/5)
 
CE1#traceroute 172.16.200.254 source 172.16.100.254
Type escape sequence to abort.
Tracing the route to 172.16.200.254
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.10.2 2 msec 4 msec 1 msec
  2  *  *  *
  3  *  *  *
  4  *  *  *
snip

 

Ping KO, traceroute stops at PE1…

Second issue

As you noticed, we tried to set up MPLS L3VPN without configuring loopbacks on the ISP's routers. Because we don't care of redundancy in our scenario (there's only one path between edge routers), we can think that loopbacks are not required but in fact loopbacks are needed for packets can get to their destination.

The problem is that when pinging 172.16.200.254 CE2's interface from 172.16.100.254 CE1's interface, packets are leaving CE1 with only one label, the VPN label, but no IGP label on top of the label stack. When receiving these labeled packets, router P drops them, because VPN labels are irrelevant for core routers.

The reason for PE1 forwarding packets to P with no IGP label is that P distributes to its neighbors the implicit-null label for prefix 192.168.30.0/30 as it is directly connected :

P#show mpls ldp bindings detail
snip
  lib entry: 192.168.30.0/30, rev 4, chkpt: none
        local binding:  label: imp-null (owner LDP)
          Advertised to:
          192.168.20.1:0         192.168.30.1:0
        remote binding: lsr: 192.168.20.1:0, label: 16 checkpointed
        remote binding: lsr: 192.168.30.1:0, label: imp-null checkpointed

 

Notice the outpout chain for destination 172.16.200.0/24 on PE1 :

PE1#show ip cef vrf CUSTOMER1 172.16.200.0/24 internal
172.16.200.0/24, epoch 0, flags [rlbls], RIB[B], refcnt 6, per-destination sharing
  sources: RIB
  feature space:
    IPRM: 0x00018000
    Broker: linked, distributed at 3rd priority
    LFD: 172.16.200.0/24 0 local labels
        contains path extension list
  ifnums: (none)
  path list 7F9D765E3A08, 5 locks, per-destination, flags 0x249 [shble, rif, hwcn, bgp]
    path 7F9DC3D77E00, share 1/1, type recursive, for IPv4, flags [must-be-lbld]
      MPLS short path extensions: MOI flags = 0x0 label 17
      recursive via 192.168.30.1[IPv4:Default] label 17, fib 7F9DD0427358, 1 terminal fib, v4:Default:192.168.30.0/30
      path list 7F9D765E3968, 2 locks, per-destination, flags 0x69 [shble, rif, rcrsv, hwcn]
          path 7F9D76666788, share 1/1, type recursive, for IPv4, flags [dsnt-src-via, cef-intnl]
            recursive via 192.168.30.0/30<nh:192.168.30.1>[IPv4:Default], fib 7F9DD0427558, 1 terminal fib, v4:Default:192.168.30.0/30
            path list 7F9D765E3AA8, 3 locks, per-destination, flags 0x49 [shble, rif, hwcn]
                path 7F9DC3D77EA8, share 1/1, type attached nexthop, for IPv4
                  MPLS short path extensions: MOI flags = 0x0 label implicit-null
                  nexthop 192.168.20.2 GigabitEthernet3, IP adj out of GigabitEthernet3, addr 192.168.20.2 7F9DD052DF90
  output chain:
    label 17
    label implicit-null
    TAG adj out of GigabitEthernet3, addr 192.168.20.2 7F9DD052DDA8

 

The solution is to configure loopbacks, and use them for iBGP sessions establishment between edge routers :

PE1(config)#interface lo0
PE1(config-if)#ip add 1.1.1.1 255.255.255.255
 
PE1(config)#router ospf 1
PE1(config-router)#network 1.1.1.1 0.0.0.0 area 0
 
PE1(config)#router bgp 4200000000
PE1(config-router)#no neighbor  192.168.30.1
PE1(config-router)#neighbor 2.2.2.2 remote-as 4200000000
PE1(config-router)#neighbor 2.2.2.2 update-source lo0
PE1(config-router)#address-family  vpnv4
PE1(config-router-af)#neighbor 2.2.2.2 activate
 
PE2(config)#int lo0
PE2(config-if)#ip add 2.2.2.2 255.255.255.255
 
PE2(config)#router ospf 1
PE2(config-router)#network 2.2.2.2 0.0.0.0 area 0
 
PE2(config-router)#router bgp 4200000000
PE2(config-router)#no neighbor 192.168.20.1
PE2(config-router)#neighbor 1.1.1.1 remote-as 4200000000
PE2(config-router)#neighbor 1.1.1.1update-source lo0
PE2(config-router)#address-family vpnv4
PE2(config-router-af)#nei 1.1.1.1 activate

 

Now, on PE2, next-hop for 172.16.200.0/24 is 2.2.2.2. As router P is not directly connected to 2.2.2.2/32 no implicit-null label is distributed for this prefix but label 17. Notice the output chain on PE1 :

PE1#show ip route vrf CUSTOMER1
 
Routing Table: CUSTOMER1
snip
 
      172.16.0.0/24 is subnetted, 2 subnets
B        172.16.100.0 [20/0] via 192.168.10.1, 1d23h
B        172.16.200.0 [200/0] via 2.2.2.2, 00:11:04
      192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.10.0/30 is directly connected, GigabitEthernet2
L        192.168.10.2/32 is directly connected, GigabitEthernet2
      192.168.40.0/30 is subnetted, 1 subnets
B        192.168.40.0 [200/0] via 2.2.2.2, 00:11:04
 
P#show mpls ldp bindings
snip
  lib entry: 2.2.2.2/32, rev 8
        local binding:  label: 17
        remote binding: lsr: 192.168.30.1:0, label: imp-null
        remote binding: lsr: 192.168.20.1:0, label: 19
snip
 
PE1#show ip cef vrf CUSTOMER1 172.16.200.0/24 internal
172.16.200.0/24, epoch 0, flags [rlbls], RIB[B], refcnt 6, per-destination sharing
  sources: RIB
  feature space:
    IPRM: 0x00018000
    Broker: linked, distributed at 3rd priority
    LFD: 172.16.200.0/24 0 local labels
        contains path extension list
  ifnums: (none)
  path list 7F9D765E3A08, 5 locks, per-destination, flags 0x249 [shble, rif, hwcn, bgp]
    path 7F9D76666788, share 1/1, type recursive, for IPv4, flags [must-be-lbld]
      MPLS short path extensions: MOI flags = 0x0 label 17
      recursive via 2.2.2.2[IPv4:Default] label 17, fib 7F9DD0427258, 1 terminal fib, v4:Default:2.2.2.2/32
      path list 7F9D765E3AA8, 5 locks, per-destination, flags 0x49 [shble, rif, hwcn]
          path 7F9DC3D77EA8, share 1/1, type attached nexthop, for IPv4
            MPLS short path extensions: MOI flags = 0x0 label 17
            nexthop 192.168.20.2 GigabitEthernet3 label 17, IP adj out of GigabitEthernet3, addr 192.168.20.2 7F9DD052DF90
  output chain:
    label 17
    label 17
    TAG adj out of GigabitEthernet3, addr 192.168.20.2 7F9DD052DDA8

 

And… it works !

CE1#ping 172.16.200.254 source 172.16.100.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.200.254, timeout is 2 seconds:
Packet sent with a source address of 172.16.100.254
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/16/24 ms
 
CE1#traceroute 172.16.200.254 source 172.16.100.254
Type escape sequence to abort.
Tracing the route to 172.16.200.254
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.10.2 5 msec 2 msec 3 msec
  2 192.168.20.2 [MPLS: Labels 17/17 Exp 0] 7 msec 7 msec 13 msec
  3 192.168.40.2 [AS 4200000000] [MPLS: Label 17 Exp 0] 7 msec 19 msec 20 msec
  4 192.168.40.1 [AS 4200000000] 23 msec *  7 msec

Configuration file and Visio diagram

 MPLS_basic_L3VPN.zip

juin 16
LDP session establishment

In Luc de Ghein's « MPLS fundamentals », at page 72, we learn that « In Cisco IOS, the MPLS LDP router ID needs to be present in the routing table of the LDP neighboring routers. If it is not, the LDP session is not formed. °»

We want to verify this assertion.

 

Software used in this scenario :

  • Hypervisor : VMware ESXi 6.0.0 build-2494585
  • Virtual router : IOS XE version 03.14.01.S, IOS version 15.5(1)S1
  • Cisco 3825 : Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9-M), Version 12.3(11)T7, RELEASE SOFTWARE (fc3)
  • Sniffer : Wireshark 2.0.1


 

Figure 1 : Network Topology Diagram

 

Find below the starting configuration of R1 and R2 :

​​===================================
R1
===================================
!
! to enable LDP because the default on IOS 12.3(11)T7 is TDP
!
mpls label protocol ldp
!
interface GigabitEthernet0/0
 ip address 192.168.10.1 255.255.255.0
 no shutdown
 mpls ip
!
!
===================================
R2
===================================
!
interface GigabitEthernet2
 ip address 192.168.10.2 255.255.255.0
 no shutdown
 mpls ip
!

        

First we need to understand how the LDP session is formed, to do that let's fire up wireshrak on Gi2 of R2

 

We see that R2 is trying to discover another LDP peer by sending « Hello Message ». Let' take a closer look at one of these frames, for example the frame numbered one

 

As you can see on the capture above, R2 (192.168.10.2) is trying to establish a LDP connection with a neighbor, by sending a « Hello Message » to the multicast group 224.0.0.2 (all routers on the same network segment) using the source and destination port UDP 646. You can also see that with no loopback or static LDP router ID configured, the LDP session uses the IP address of interface Gi2.

Digression : Before the IETF standardized LDP for exchanging labels between LSR, Cisco routers used a protocol developped by Cisco called TDP for « Taggued Distribution Protocol ». TDP uses the UDP port 711 to the broadcast address 255.255.255.255.

With the command below, we can see that the LDP identifier (4 bytes) on R2 is indeed Gi2, notice the platform-wide label space (2 bytes) after the LDP ID and also the Transport IP address (which we will discuss later):

​ R2#show mpls ldp discovery detail
 Local LDP Identifier:
    192.168.10.2:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet2 (ldp): xmit
            Enabled: Interface config
            Hello interval: 5000 ms; Transport IP addr: 192.168.10.2
            Clients: IPv4, mLDP

        

The different MPLS LDP default parameters for the session and the discovery can be seen with this command :

​R1#show mpls ldp parameters
Protocol version: 1
No label generic region for downstream label distribution
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Downstream on Demand max hop count: 255
LDP for targeted sessions
LDP initial/maximum backoff: 15/120 sec
LDP loop detection: off

 

​R2#show mpls ldp parameters
LDP Feature Set Manager: State Initialized
  LDP features:
    Auto-Configuration
    Basic
    ICPM
    IP-over-MPLS
    IGP-Sync
    LLAF
    TCP-MD5-Rollover
    TDP
    NSR
Protocol version: 1
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Downstream on Demand max hop count: 255
LDP for targeted sessions
LDP initial/maximum backoff: 15/120 sec
LDP loop detection: off
LDP NSR: Disabled

 

Let's take a closer look at the wireshark capture

 

As you can see on the screenshot above, the LSR R2 sends a TCP SYN to the LSR R1 using its interface GigaEthernet 2 (192.168.10.2) plus the destination port 646. The LSR R1 responds with a SYN/ACK using its interface GigaEthernet 0/0, as we configured. The LDP TCP connection is initiated by the highest LDP ID (LID), here R2 with the LID 192.168.10.2.

 

We now add a loopback on each LSR R1 and R2 :

===================================
R1
===================================
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 
===================================
R2
===================================
interface Loopback0
 ip address 2.2.2.2 255.255.255.255

        

Let's see if the LID or the Transport Address on R1 and R2 has not changed by using the command below,

​R1#show mpls ldp discovery detail
 Local LDP Identifier:
    192.168.10.1:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet0/0 (ldp): xmit/recv
            Hello interval: 5000 ms; Transport IP addr: 192.168.10.1
            LDP Id: 192.168.10.2:0
              Src IP addr: 192.168.10.2; Transport IP addr: 192.168.10.2
              Hold time: 15 sec; Proposed local/peer: 15/15 sec
 

 

R2#show mpls ldp discovery detail
 Local LDP Identifier:
    192.168.10.2:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet2 (ldp): xmit/recv
            Enabled: Interface config
            Hello interval: 5000 ms; Transport IP addr: 192.168.10.2
            LDP Id: 192.168.10.1:0
              Src IP addr: 192.168.10.1; Transport IP addr: 192.168.10.1
              Hold time: 15 sec; Proposed local/peer: 15/15 sec
              Reachable via 192.168.10.0/24
              Password: not required, none, in use
            Clients: IPv4, mLDP

        

Next, let's disable and re-enable the interface Gi0/0 on R1 and Gi2 on R2 and use the same command as before

​R1#show mpls ldp discovery detail
 Local LDP Identifier:
    1.1.1.1:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet0/0 (ldp): xmit/recv
            Hello interval: 5000 ms; Transport IP addr: 1.1.1.1
            LDP Id: 2.2.2.2:0; no route to transport addr
              Src IP addr: 192.168.10.2; Transport IP addr: 2.2.2.2
              Hold time: 15 sec; Proposed local/peer: 15/15 sec

 

​R2#show mpls ldp discovery detail
 Local LDP Identifier:
    2.2.2.2:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet2 (ldp): xmit/recv
            Enabled: Interface config
            Hello interval: 5000 ms; Transport IP addr: 2.2.2.2
            LDP Id: 1.1.1.1:0; no route to transport addr
              Src IP addr: 192.168.10.1; Transport IP addr: 1.1.1.1
              Hold time: 15 sec; Proposed local/peer: 15/15 sec
              Password: not required, none, in use
            Clients: IPv4, mLDP

        

Look at the result above, the LID and the transport address are now equal to the value of the loopback.

As you migth know, the LDP ID is determined by the three rules below, in order of precedence :

  1. Configuration
  2. Highest IP address of an up and running loopback when LDP comes up
  3. Highest IP address of an up and running nonloopback when LDP comes up

 

We see in Wireshark that  the LSR ID and the Transport Address on R1 and R2 are now equal to their respective Loopback0.

 

 

 

What if we want to influence this behavior by specifying a physical interface, according to the previous rules, we can. Let's say we desire to use the interface Gi0/0 as a LID on R1, we just have to use this command :

​mpls ldp router-id GigabitEthernet 0/0 force

        

 

Note : the command above will break any LDP connection already established on the link.

Let's do the same on R2 and check the results with the previous command on R1 and R2

 

​R1#show mpls ldp discovery detail
 Local LDP Identifier:
    192.168.10.1:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet0/0 (ldp): xmit/recv
            Hello interval: 5000 ms; Transport IP addr: 192.168.10.1
            LDP Id: 192.168.10.2:0
              Src IP addr: 192.168.10.2; Transport IP addr: 192.168.10.2
              Hold time: 15 sec; Proposed local/peer: 15/15 sec

         

 

​R2#show mpls ldp discovery detail
 Local LDP Identifier:
    192.168.10.2:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet2 (ldp): xmit/recv
            Enabled: Interface config
            Hello interval: 5000 ms; Transport IP addr: 192.168.10.2
            LDP Id: 192.168.10.1:0
              Src IP addr: 192.168.10.1; Transport IP addr: 192.168.10.1
              Hold time: 15 sec; Proposed local/peer: 15/15 sec
              Reachable via 192.168.10.0/24
              Password: not required, none, in use
            Clients: IPv4, mLDP

        

 

According to the RFC 5036, the Transport Address is an optional field defined as such :

      IPv4 Transport Address

         Specifies the IPv4 address to be used for the sending LSR when

         opening the LDP session TCP connection.  If this optional TLV

         is not present, the IPv4 source address for the UDP packet

         carrying the Hello SHOULD be used.

 

In summary, if the Transport Address is configured, it is used to establish the LDP TCP connection.

In Cisco IOS Version 12.3(11)T7 of R1 (platform 3825), we have the command below to configure the Transport Address using the Loopback0°:

​mpls ldp discovery transport-address 1.1.1.1

 

Note : Virtual router : IOS XE version 03.14.01.S, IOS version 15.5(1)S1 does not support the command above.

Let's switch to the Wireshark capture

 

 

LSR R1 is now using its Loopback0 interface as its Transport Address though the LSR ID of R1 is still its interface GigabitEthernet 0/0.

R1#show mpls ldp discovery detail
 Local LDP Identifier:
    192.168.10.1:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet0/0 (ldp): xmit/recv
            Hello interval: 5000 ms; Transport IP addr: 1.1.1.1
            LDP Id: 192.168.10.2:0
              Src IP addr: 192.168.10.2; Transport IP addr: 192.168.10.2
              Hold time: 15 sec; Proposed local/peer: 15/15 sec

 

Notice that in the Wireshark capture, the LDP session is down

 

 

Now, if we add a static route to the Loopback0 of R1 on R2, the LDP session should be up again.

ip route 1.1.1.1 255.255.255.255 192.168.10.1

        

Indeed, we observe the LDP session is established in the Wireshark capture below. R1 is now using its transport address to establish the LDP session.

 

Conclusion,

​Luc de Ghein's assertion « In Cisco IOS, the MPLS LDP router ID needs to be present in the routing table of the LDP neighboring routers. If it is not, the LDP session is not formed. °» is verified but it is a particular case. It is  Mr de Ghein's assumes that the value of the LDP ID is equal to the transport address, this is true in most  MPLS cases but as we learned in this lab, you can customize your LDP session to use the transport address instead of the LDP router ID to establish the LDP session. If you do you will have to configure a static route or advertise the address using an IGP because the neighboring LSR needs to know how to reach the transport address you configured.

mai 01
Network Diagram and Visio Layers (2/2)

In a previous article, we showed you how to take advantage of Visio Layers to display different type of information (L1, L2/L3, routing) on a network diagram without overloading it. In this article we propose you a shortcut to quickly hide or display a particular layer.

Software used in this scenario : Microsoft Visio 2013 (15.0.4420.107) MSO (15.0.4420.107) 64 bits
The idea is to add a switch button for each layer to hide or display this one :

We didn’t find a simple way to add a button on the Visio sheet (as it’s possible with Excel) so we decided to take advantage of the « Double-click » action to run a macro when user double-click on a rectange shape.

Step 1 : create macros

Enable the « Developper » tab which is not displayed in the ribbon by default (click right on the ribbon) :

 

 

In the « Developper » tab, create a new macro by clicking on « Record Macro » :



Give a name to your macro and press OK :

 

You notice changes in the code section in the « Developper » tab. « Pause Recording » is now available and « Record Macro » button change to « Stop Recording ». These changes indicate that you are in recording mode.

 

Return in the « Home » tab and, open the « Layer Properties » box and uncheck the « Visible » box for the layer « routing » :

 

Stop macro recording and open the « Macros » dialog box :



Select the newly created macro and click « Edit » :



It open the Visual Basic Editor :

 

In the code editor window, select lines below :

 

And replace them with this code :

Dim vsoLayer1 As Visio.Layer
    Set vsoLayer1 = Application.ActiveWindow.Page.Layers.Item("none")
    If vsoLayer1.CellsC(visLayerVisible) = 0 Then
        vsoLayer1.CellsC(visLayerVisible).FormulaU = 1
    ElseIf vsoLayer1.CellsC(visLayerVisible) = 1 Then
        vsoLayer1.CellsC(visLayerVisible).FormulaU = 0
    End If
    If vsoLayer1.CellsC(visLayerPrint) = 0 Then
        vsoLayer1.CellsC(visLayerPrint).FormulaU = 1
    ElseIf vsoLayer1.CellsC(visLayerPrint) = 1 Then
        vsoLayer1.CellsC(visLayerPrint).FormulaU = 0
    End If

Because the goal of this article is not to teach you about VBA coding, we don’t explain you in detail the purpose of each line.



In short, red blocks below are best practice code automatically added when recording macro (see https://social.technet.microsoft.com/Forums/office/en-US/3b7e95a7-bc8f-4fef-b604-7a6dc7898bf5/diagram-services?forum=visiogeneral) :

 

The rest of the code is the switching function to set or unset the layer visible and printable and is inspired by the code that has been automatically generated with the recording tool.

Duplicate the sub « none » for each layer of your network diagram and change sub name and « Application.ActiveWindow.Page.Layers.Item » selection appropriately :

Sub L1()
'
' Macro to quickly hide or display the "L1" layer
'
 
    'Enable diagram services
    Dim DiagramServices As Integer
    DiagramServices = ActiveDocument.DiagramServicesEnabled
    ActiveDocument.DiagramServicesEnabled = visServiceVersion140 + visServiceVersion150
 
    Dim vsoLayer1 As Visio.Layer
    Set vsoLayer1 = Application.ActiveWindow.Page.Layers.Item("L1")
    If vsoLayer1.CellsC(visLayerVisible) = 0 Then
        vsoLayer1.CellsC(visLayerVisible).FormulaU = 1
    ElseIf vsoLayer1.CellsC(visLayerVisible) = 1 Then
        vsoLayer1.CellsC(visLayerVisible).FormulaU = 0
    End If
    If vsoLayer1.CellsC(visLayerPrint) = 0 Then
        vsoLayer1.CellsC(visLayerPrint).FormulaU = 1
    ElseIf vsoLayer1.CellsC(visLayerPrint) = 1 Then
        vsoLayer1.CellsC(visLayerPrint).FormulaU = 0
    End If
 
    'Restore diagram services
    ActiveDocument.DiagramServicesEnabled = DiagramServices
End Sub
Sub L2L3()
'
' Macro to quickly hide or display the "L2L3" layer
'
 
    'Enable diagram services
    Dim DiagramServices As Integer
    DiagramServices = ActiveDocument.DiagramServicesEnabled
    ActiveDocument.DiagramServicesEnabled = visServiceVersion140 + visServiceVersion150
 
    Dim vsoLayer1 As Visio.Layer
    Set vsoLayer1 = Application.ActiveWindow.Page.Layers.Item("L2L3")
    If vsoLayer1.CellsC(visLayerVisible) = 0 Then
        vsoLayer1.CellsC(visLayerVisible).FormulaU = 1
    ElseIf vsoLayer1.CellsC(visLayerVisible) = 1 Then
        vsoLayer1.CellsC(visLayerVisible).FormulaU = 0
    End If
    If vsoLayer1.CellsC(visLayerPrint) = 0 Then
        vsoLayer1.CellsC(visLayerPrint).FormulaU = 1
    ElseIf vsoLayer1.CellsC(visLayerPrint) = 1 Then
        vsoLayer1.CellsC(visLayerPrint).FormulaU = 0
    End If
 
    'Restore diagram services
    ActiveDocument.DiagramServicesEnabled = DiagramServices
End Sub
Sub routing()
'
' Macro to quickly hide or display the "routing" layer
'
 
    'Enable diagram services
    Dim DiagramServices As Integer
    DiagramServices = ActiveDocument.DiagramServicesEnabled
    ActiveDocument.DiagramServicesEnabled = visServiceVersion140 + visServiceVersion150
 
    Dim vsoLayer1 As Visio.Layer
    Set vsoLayer1 = Application.ActiveWindow.Page.Layers.Item("routing")
    If vsoLayer1.CellsC(visLayerVisible) = 0 Then
        vsoLayer1.CellsC(visLayerVisible).FormulaU = 1
    ElseIf vsoLayer1.CellsC(visLayerVisible) = 1 Then
        vsoLayer1.CellsC(visLayerVisible).FormulaU = 0
    End If
    If vsoLayer1.CellsC(visLayerPrint) = 0 Then
        vsoLayer1.CellsC(visLayerPrint).FormulaU = 1
    ElseIf vsoLayer1.CellsC(visLayerPrint) = 1 Then
        vsoLayer1.CellsC(visLayerPrint).FormulaU = 0
    End If
 
    'Restore diagram services
    ActiveDocument.DiagramServicesEnabled = DiagramServices
End Sub

Save your code :

Visio may ask you to change the file format to support macros :


Select No. In the « Save as » dialog box choose « Visio macro-enabled drawing » file format :


This lead to the creation of a .vsdm file (format which support macros).

At the end of this step, you should see your 4 macros :


 

Step 2 : create craft buttons

Instert 4 rectangle shapes, one for each layer :

 

Select the first rectangle « L1 » and open the « Behavior » box in the « Developper » tab. Uncheck all options under the « Selection Highlighting » section in the « Behavior » tab :


In the « Double-Click » tab activate the « Run macro » option and select the « L1 » macro :


Now you can display or hide any layer by double-clicking on the corresponding craft button (it also set up correct configuration to print what is displayed) :

 

 

Do the same for others rectangles.

References

https://support.office.com/en-US/article/Change-a-shape-s-double-click-behavior-29757697-eec0-4e82-b5e4-bf045a4629ae

https://support.office.com/en-us/article/Record-macros-in-Visio-05c29ac5-922d-4fd4-8d60-8e2ccd3ecc5a

https://social.technet.microsoft.com/Forums/office/en-US/3b7e95a7-bc8f-4fef-b604-7a6dc7898bf5/diagram-services?forum=visiogeneral

mars 27
Network Diagram and Visio Layers (1/2)

In this first article, we show you how to take advantage of Visio layers to display different network informations (L1, L2/L3, routing configuration) on the same sheet without overload the network diagram.

Software used in this scenario : Microsoft Visio 2013 (15.0.4420.107) MSO (15.0.4420.107) 64 bits

At the end of this article, you would be able to draw a network diagram like this one :

 

Network nodes without any information…

 

…with physical interfaces…

 

…with VLANs and IP addresses…

 

…with routing protocols

Creating the primary layer : network nodes

First, we start to draw our network diagram with routers and MPLS cloud but without any link :

 

Then we select all shapes and add them to a new layer « none » which will be displayed with secondary layers (L1, L2/L3, routing).

 

 

Now we can add secondary layers to display on the same network diagram different informations following the OSI model.

Creating secondary layers : physical interfaces (OSI layer 1)

 

We want to add new shapes (links and labels) to a new layer « L1 ». The tip to select only these new shapes quickly is to hide the previous layer « none » and then select all shapes displayed.

 

Open the « Layer Properties » box and uncheck the « Visible » box for the layer « none » :

 

As you can see, a default layer « Lien » (link in english) is created when you add links on a Visio drawing. Just ignore it for the use case we describe in this article.

 

Now you can easily select all shapes and create a new layer « L1 » :

 

Uncheck the layer « Lien » in the « Layer » box and create a new one :

 

 

 

To display back the primary layer « none », open the « Layer Properties » box and check the « Visible » box for the layer « none » :

 

 

 

Creating secondary layers : VLANs and IP addresses (OSI layer 2&3)

To add a third layer with VLANs and IP addresses, we begin to hide layer « L1 » :

 

 

 

 We start to add OSI layer 2&3 informations :

 

You may notice line jumps on the drawing. We found two ways to remove them. The easiest way is to deactivate the option « Afficher les déviations de trait » (« Show Line Jumps » in the english version) in the « Design » tab :

 

And the tedious way…

First enable the « Developper » tab which is not displayed in the ribbon by default (click right on the ribbon) :

 

 

Then select links on which you observe a jump and open the « Behavior » box in the « Developper » tab :

 

In « Connector » tab, after « Line jumps » section select « Never » : 

 

Tadda ! Same result as with the first method :

 

Now, we create a third layer « L2/L3 » the same way we created the layer « L1 » (don't forget to uncheck the layer « Lien » in the « Layer » box if necessary) :

 

You should notice a little bug when displaying back the primary layer. Routers are not on top of links :

 

To correct this, select routers and bring them to front :

 

 

Creating secondary layers : routing protocols (OSI layer 3)

Finally we create our last layer with routing information like AS number, dynamic routing protocols used, loopbacks :

 

 

Adding a shape to an existing Visio layer

We found three ways to add a new shape to an existing layer in a Visio drawing.

Copying an exisiting shape

It's the easiest way but it's not always possible if the shape is not already present on the sheet.

 

As you can see, the copied shape belong to Layer « none ».

Insert a new shape

If the shape you want to add is not already present on the sheet, insert it and add it to the correct layer :

 

Activate the layer

You can also automatically assigned shapes when you add them to the sheet. To add « PROVIDER » text box and so on we open the « Layer Properties » box and check the « Active » box for the layer « none » :

 

And new shapes are automatically added to the layer « none » :

 

Printing

To print specific combination of layers, open the « Layer Properties » box and check the « Print » boxes for the layers you want to print :

 

 

Conclusion

With Visio layers you can aggregate many information without overloading the network diagram. In the next article, we proposed you a quick way to switch from a layer to another without having to open the « Layer Properties » box.

References

https://support.office.com/en-us/article/Add-a-layer-adcb61d3-5e8b-431e-bb9d-4a35eae28e48?ui=en-US&rs=en-US&ad=US#bm3

https://support.office.com/en-us/article/Layer-dialog-box-b5edb607-a93d-4906-9203-68c9b99cfe5a

https://support.office.com/en-us/article/Set-line-jumps-for-connectors-1a5516db-0212-4352-90dd-fc9cfd4018ed

https://support.office.com/en-US/article/Show-the-Developer-tab-E1192344-5E56-4D45-931B-E5FD9BEA2D45

mars 02
Does load-balancing occur between labeled and unlabeled paths on Cisco IOS ? (2/2)

In a previous article we showed that contrary to Luc de Ghein's assertion (« If a prefix is reachable via a mix of labeled and unlabeled (IP) paths, Cisco IOS does not consider the unlabeled paths for load-balancing labeled packets. », MPLS Fundamentals, page 50), there was no load-sharing at the edge of the MPLS cloud that is when an edge LSR receives an IP packet (CEF lookup).

The purpose of this article is to verify if load-sharing occur between labeled and unlabeled paths inside the MPLS cloud at the core level that is when a core LSR receives a labeled packet (LFIB lookup).

Software used in this scenario :

  • Hypervisor : VMware ESXi 6.0.0 build-2494585
  • Routers : IOS XE version 03.14.01.S, IOS version 15.5(1)S1
  • Servers : Windows 10 Education
  • Sniffer : Wireshark 2.0.2
  • Traffic simulator : Ostinato 0.7.1

 

 Routers configuration (without admin interfaces) :

​​===================================

R1
===================================
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
!snip ADMIN INTERFACE snip
!
!R1 <=> R2
interface GigabitEthernet2
 ip address 192.168.10.1 255.255.255.0
 negotiation auto
 mpls ip
!
!R1 <=> SRV1
interface GigabitEthernet3
 ip address 192.168.100.254 255.255.255.0
 negotiation auto
!
router ospf 1
 passive-interface GigabitEthernet3
 network 1.1.1.1 0.0.0.0 area 0
 network 192.168.100.0 0.0.0.255 area 0
 network 192.168.10.0 0.0.0.255 area 0
 
===================================
R2
===================================
ip cef load-sharing algorithm include-ports source
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
!snip ADMIN INTERFACE snip
!
!R2 <=> R1 VLAN 10
interface GigabitEthernet2
 ip address 192.168.10.2 255.255.255.0
 negotiation auto
 mpls ip
!
!R2 <=> R3 VLAN 20
interface GigabitEthernet3
 ip address 192.168.20.2 255.255.255.0
 negotiation auto
 mpls ip
!
!R2 <=> R3 VLAN 30
interface GigabitEthernet4
 ip address 192.168.30.2 255.255.255.0
 negotiation auto
!
router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
 network 192.168.10.0 0.0.0.255 area 0
 network 192.168.20.0 0.0.0.255 area 0
 network 192.168.30.0 0.0.0.255 area 0
 
===================================
R3
===================================
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
!snip ADMIN INTERFACE snip
!
!R3 <=> R4 VLAN 40
interface GigabitEthernet2
 ip address 192.168.40.3 255.255.255.0
 negotiation auto
 mpls ip
!
!R3 <=> R2 VLAN 20
interface GigabitEthernet3
 ip address 192.168.20.3 255.255.255.0
 negotiation auto
 mpls ip
!
!R3 <=> R2 VLAN 30
interface GigabitEthernet4
 ip address 192.168.30.3 255.255.255.0
 negotiation auto
!
router ospf 1
 network 3.3.3.3 0.0.0.0 area 0
 network 192.168.20.0 0.0.0.255 area 0
 network 192.168.30.0 0.0.0.255 area 0
 network 192.168.40.0 0.0.0.255 area 0
 
===================================
R4
===================================
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!
!snip ADMIN INTERFACE snip
!
!R4 <=> SRV2
interface GigabitEthernet3
 ip address 192.168.200.254 255.255.255.0
 negotiation auto
!
!R4 <=> R3
interface GigabitEthernet2
 ip address 192.168.40.4 255.255.255.0
 negotiation auto
 mpls ip
!
router ospf 1
 passive-interface GigabitEthernet3
 network 4.4.4.4 0.0.0.0 area 0
 network 192.168.40.0 0.0.0.255 area 0
 network 192.168.200.0 0.0.0.255 area 0

 MPLS is enabled on VLAN 20 and disabled on VLAN 30.

R2#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
GigabitEthernet2       Yes (ldp)     No       No  No     Yes
GigabitEthernet3       Yes (ldp)     No       No  No     Yes
 
R3#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
GigabitEthernet2       Yes (ldp)     No       No  No     Yes
GigabitEthernet3       Yes (ldp)     No       No  No     Yes
 
! Two paths learned from OSPF
R2#show ip route 192.168.200.1
Routing entry for 192.168.200.0/24
  Known via "ospf 1", distance 110, metric 3, type intra area
  Last update from 192.168.30.3 on GigabitEthernet4, 01:44:32 ago
  Routing Descriptor Blocks:
    192.168.30.3, from 4.4.4.4, 01:44:32 ago, via GigabitEthernet4
      Route metric is 3, traffic share count is 1
  * 192.168.20.3, from 4.4.4.4, 01:44:32 ago, via GigabitEthernet3
      Route metric is 3, traffic share count is 1
 
! One labeled path and one unlabeled path in LFIB
R2#show mpls forwarding-table 192.168.200.1 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
21         21         192.168.200.0/24 3072          Gi3        192.168.20.3
        MAC/Encaps=14/18, MRU=1500, Label Stack{21}
        000C29DB0426000C29610C848847 00015000
        No output feature configured
           No Label   192.168.200.0/24 9120          Gi4        192.168.30.3
        MAC/Encaps=14/14, MRU=1504, Label Stack{}
        000C29DB0430000C29610C8E0800
        No output feature configured
    Per-destination load-sharing, slots: 1 3 5 7 9 11 13 15

Load-sharing algorithm is modified to include source port (see R2’s configuration above). We send 100 TCP SYN packets from SRV1 to SRV2 on port 3389 with source port variating between 1026 and 1125 :

 

 

 

 

 

 

As in our previous article, we observe packets are load-balanced between labeled and unlabeled paths. 24 packets are forwarded on VLAN 20 and 76 packets are forwarded on VLAN 30 :

 

VLAN 20 capture on the left, VLAN 30 on the right

This is confirmed on R2 :

​R2#show mpls forwarding-table 192.168.200.1Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
21         21         192.168.200.0/24 1536          Gi3        192.168.20.3
           No Label   192.168.200.0/24 4560          Gi4        192.168.30.3

« Bytes Label Switched » represents the number of bytes switched with this incoming label. This includes the outgoing label and Layer 2 header.

Each TCP SYN packet sent by SRV1 to SRV2 is 60 bytes long :

14 (Ethernet header)+20 (IP header)+20 (TCP header)+6 (payload) = 60 bytes

24 packets are forwarded on Gi3 (VLAN 20) with MPLS encapsulation (1 label = 4 bytes) :

64*24 = 1536 bytes

76 packets are forwarded unlabeled on Gi4 (VLAN 30) :

60*76 = 4560 bytes

Finally, all packets leave the MPLS cloud unlabeled (100*60 bytes) at downstream LSR (R4) :

R4#show adjacency 192.168.200.1 detail

Protocol Interface                 Address
IP       GigabitEthernet3          192.168.200.1(8)  
                                   100 packets, 6000 bytes  
                                   epoch 1  
                                   sourced in sev-epoch 0  
                                   Encap length 14  
                                   000C2962A9AF000C2972547C0800  
                                   L2 destination address byte offset 0  
                                   L2 destination address byte length 6  
                                   Link-type after encap: ip  
                                   ARP  

Conclusion

We coud not verify Luc de Ghein's assertion « If a prefix is reachable via a mix of labeled and unlabeled (IP) paths, Cisco IOS does not consider the unlabeled paths for load-balancing labeled packets. » neither on edge LSR or core LSR. It seems that this behavior is platform dependent.

Notes

« show mpls forwarding-table » counters (« Bytes Label Switched »field) can be cleared with « clear mpls counters » command

« show adjacency [interface] [ip-address] detail » counters (packets and bytes transmitted) can be cleared with « clear counters interface » command

References

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mpls/command/mp-cr-book/mp-s2.html#wp4232274342

 

févr. 12
Does load-balancing occur between labeled and unlabeled paths on Cisco IOS ? (1/2)

In Luc de Ghein's « MPLS fundamentals », at page 49, we learn that « If multiple equal-cost paths exist for an IPv4 prefix, the Cisco IOS can load-balance labeled packets »

And at page 50, we learn that « If a prefix is reachable via a mix of labeled and unlabeled (IP) paths, Cisco IOS does not consider the unlabeled paths for load-balancing labeled packets. ».

We wanted to verify these assertions.

 

Software used in this scenario :

  • Hypervisor : VMware ESXi 6.0.0 build-2494585
  • Routers : IOS XE version 03.14.01.S, IOS version 15.5(1)S1
  • Servers : Windows 10 Education
  • Sniffer : Wireshark 2.0.1
  • Traffic simulator : Ostinato 0.7.1

MPLS010.jpg 

Routers configuration (without admin interfaces) :

===================================

R1
===================================
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
!snip ADMIN INTERFACE snip
!
!R1 <=> R2 VLAN 10
interface GigabitEthernet2
 ip address 192.168.10.1 255.255.255.0
 negotiation auto
 mpls ip
!
!R1 <=> R2 VLAN 20
interface GigabitEthernet3
 ip address 192.168.20.1 255.255.255.0
 negotiation auto
!
!SRV1 <=> R1 VLAN 100
interface GigabitEthernet4
 ip address 192.168.100.254 255.255.255.0
 negotiation auto
!
router ospf 1
 passive-interface GigabitEthernet4
 network 1.1.1.1 0.0.0.0 area 0
 network 192.168.10.0 0.0.0.255 area 0
 network 192.168.20.0 0.0.0.255 area 0
 network 192.168.100.0 0.0.0.255 area 0
 
===================================
R2
===================================
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
!snip ADMIN INTERFACE snip
!
!R1 <=> R2 VLAN 10
interface GigabitEthernet2
 ip address 192.168.10.2 255.255.255.0
 negotiation auto
 mpls ip
!
!R1 <=> R2 VLAN 20
interface GigabitEthernet3
 ip address 192.168.20.2 255.255.255.0
 negotiation auto
!
!R2 <=> R3 VLAN 30
interface GigabitEthernet4
 ip address 192.168.30.2 255.255.255.0
 negotiation auto
 mpls ip
!
router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
 network 192.168.10.0 0.0.0.255 area 0
 network 192.168.20.0 0.0.0.255 area 0
 network 192.168.30.0 0.0.0.255 area 0
 
===================================
R3
===================================
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
!snip ADMIN INTERFACE snip
!
!R2 <=> R3
interface GigabitEthernet2
 ip address 192.168.30.3 255.255.255.0
 negotiation auto
 mpls ip
!
!R3 <=> SRV2
interface GigabitEthernet3
 ip address 192.168.200.254 255.255.255.0
 negotiation auto
!
router ospf 1
 passive-interface GigabitEthernet3
 network 3.3.3.3 0.0.0.0 area 0
 network 192.168.30.0 0.0.0.255 area 0
 network 192.168.200.0 0.0.0.255 area 0

 

Load-balancing between labeled paths

First we try to highlight load-balancing over VLAN 10 and VLAN 20 with MPLS activated on both links between R1 and R2. We send 100 TCP SYN packets from SRV1 to SRV2 on port 3389.

R1(config)#interface gigabitEthernet 3

R1(config-if)#mpls ip
R1(config-if)#end
 
R2(config)#interface gigabitEthernet 3
R2(config-if)#mpls ip
R2(config-if)#end
 
R1#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
GigabitEthernet2       Yes (ldp)     No       No  No     Yes
GigabitEthernet3       Yes (ldp)     No       No  No     Yes
 
R2#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
GigabitEthernet2       Yes (ldp)     No       No  No     Yes
GigabitEthernet3       Yes (ldp)     No       No  No     Yes
GigabitEthernet4       Yes (ldp)     No       No  No     Yes
 
! Two paths learned from OSPF
R1#show ip route 192.168.200.1
Routing entry for 192.168.200.0/24
  Known via "ospf 1", distance 110, metric 3, type intra area
  Last update from 192.168.20.2 on GigabitEthernet3, 00:00:36 ago
  Routing Descriptor Blocks:
    192.168.20.2, from 3.3.3.3, 00:00:36 ago, via GigabitEthernet3
      Route metric is 3, traffic share count is 1
  * 192.168.10.2, from 3.3.3.3, 00:00:36 ago, via GigabitEthernet2
      Route metric is 3, traffic share count is 1
 
! Two labeled paths in LFIB
R1#show mpls forwarding-table 192.168.200.1 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
19         19         192.168.200.0/24 0             Gi2        192.168.10.2
        MAC/Encaps=14/18, MRU=1500, Label Stack{19}
        000C29610C7A000C2952B1488847 00013000
        No output feature configured
    Per-destination load-sharing, slots: 0 2 4 6 8 10 12 14
           19         192.168.200.0/24 0             Gi3        192.168.20.2
        MAC/Encaps=14/18, MRU=1500, Label Stack{19}
        000C29610C84000C2952B1528847 00013000
        No output feature configured
    Per-destination load-sharing, slots: 1 3 5 7 9 11 13 15

Ostinato configuration (do not forget to fill source MAC and source IP otherwise packets are not forwarded by R1) :

MPLS001.jpg 

MPLS002.jpg 

MPLS003.jpg 

MPLS004.jpg 

MPLS005.jpg 

First observation, packets are not loadbalanced between Gi2 and Gi3 on R1 !

MPLS006.jpg 

VLAN 10 capture on the left, VLAN 20 on the right

After a few searches, we understand that MPLS forwarding is related to CEF and we learn that there are two CEF load-sharing modes (per-packet and per-destination). On R1 « per-destination » is configured for prefix 192.168.200.0/24 :

​​R1#show ip cef 192.168.200.1 detail

192.168.200.0/24, epoch 2, per-destination sharing
  local label info: global/19
  nexthop 192.168.10.2 GigabitEthernet2 label 19
  nexthop 192.168.20.2 GigabitEthernet3

With « per-destination » algorithm, source IP and destination IP of each IP packet are hashed. Packets with same computed hash are forwared through the same interface.

But we learn also that CEF load-sharing algorithm can be tuned :

R1(config)#ip cef load-sharing algorithm ?
  include-ports  Algorithm that includes layer 4 ports
  original       Original algorithm
  tunnel         Algorithm for use in tunnel only environments
  universal      Algorithm for use in most environments
 
R1(config)#ip cef load-sharing algorithm include-ports ?
  destination  Use destination port in hash function
  source       Use source port in hash function
 
R1(config)#ip cef load-sharing algorithm include-ports source
R1(config)#end

According to this modification, we also change Ostinato configuration to send 100 TCP packets with source port from 1026 to 1125 :

MPLS007.jpg 

This time, load balacing occur between Gi2 and Gi3 !

MPLS008.jpg 

An interesting command permits to know in advance the outgoing interface selected by CEF algorithm for each packet by specifying source IP address, source port, destination IP address (and destination port but here we include only source ports in CEF load-sharing algorithm) :

! Verified in captures above

R1#show ip cef exact-route 192.168.100.1 src-port 1026 192.168.200.1
192.168.100.1 -> 192.168.200.1 => label 19TAG adj out of GigabitEthernet2, addr 192.168.10.2
R1#show ip cef exact-route 192.168.100.1 src-port 1029 192.168.200.1
192.168.100.1 -> 192.168.200.1 => label 19TAG adj out of GigabitEthernet3, addr 192.168.20.2

 

Load-balancing between labeled and unlabeled paths

Finally to prove Luc de Ghein's assertion we disable MPLS on Gi3 and send the same stream :

R1(config)#interface gigabitEthernet 3

R1(config-if)#no mpls ip
R1(config-if)#end
 
R2(config)#interface gigabitEthernet 3
R2(config-if)#no mpls ip
R2(config-if)#end
 
R1#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
GigabitEthernet2       Yes (ldp)     No       No  No     Yes
 
R2#show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
GigabitEthernet2       Yes (ldp)     No       No  No     Yes
GigabitEthernet4       Yes (ldp)     No       No  No     Yes
 
R1#show mpls forwarding-table 192.168.200.1 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
19         19         192.168.200.0/24 0             Gi2        192.168.10.2
        MAC/Encaps=14/18, MRU=1500, Label Stack{19}
        000C29610C7A000C2952B1488847 00013000
        No output feature configured
           No Label   192.168.200.0/24 0             Gi3        192.168.20.2
        MAC/Encaps=14/14, MRU=1504, Label Stack{}
        000C29610C84000C2952B1520800
        No output feature configured
    Per-destination load-sharing, slots: 1 3 5 7 9 11 13 15

In contrary to Luc de Ghein's assertion, MPLS load-balancing occur between labeled and unlabeled paths !

MPLS009.jpg 

Conclusion

At the edge of the MPLS cloud, load-balancing is effective between labeled paths and between labeled and unlabeled paths. We coud not verify Luc de Ghein's assertion « If a prefix is reachable via a mix of labeled and unlabeled (IP) paths, Cisco IOS does not consider the unlabeled paths for load-balancing labeled packets. ».

Notes

  • When the MPLS is enabled on an interface, the LSR periodically sends (hello interval) hello messages.
    The hello messages (UDP source port = port destination = 646) are sent to the 224.0.0.2 address (All Routers on this Subnet)
    The LSR ID and space ID label are indicated in each message hello.
    A transport IP address is also indicated.
  • An LSR can not establish an LDP session with a neighbor router if the transport address announced by this one isn't present in its routing table!
  • A single LDP session is established between two LSR if the generated labels have global meaning for the router (per-platform label space)
  • The LDP session is established on TCP port 646
  • On IOS XE 03.14.01.S, IOS Release 15.5 (1) S1, you can not choose the transport address.
    The "mpls ldp discovery transport-address" is not available
À propos de ce blog
Non, ce n'est pas vraiment ma photo. Je n'ai simplement pas eu le temps de mettre à jour cette section. Il est quand même bon de savoir que quelqu'un me lit entièrement. Merci !