|
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 |
|
|
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 routersRouters 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
|
|
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 :
-
Configuration
-
Highest IP address of an up and running loopback when LDP comes up
-
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.
|
|
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 macrosEnable 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 buttonsInstert 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. Referenceshttps://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 |
| 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 nodesFirst, 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 layerWe found three ways to add a new shape to an existing layer in a Visio drawing. Copying an exisiting shapeIt'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 shapeIf the shape you want to add is not already present on the sheet, insert it and add it to the correct layer :
Activate the layerYou 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 » :
PrintingTo print specific combination of layers, open the « Layer Properties » box and check the « Print » boxes for the layers you want to print : 
ConclusionWith 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. Referenceshttps://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 |
|
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 |
ConclusionWe 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 |
| 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
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 pathsFirst 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) :
First observation, packets are not loadbalanced between Gi2 and Gi3 on R1 !
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 :
This time, load balacing occur between Gi2 and Gi3 !
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 pathsFinally 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 !
ConclusionAt 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
|
Détails de la conformité javascript:commonShowModalDialog('{SiteUrl}'+
'/_layouts/15/itemexpiration.aspx'
+'?ID={ItemId}&List={ListId}', 'center:1;dialogHeight:500px;dialogWidth:500px;resizable:yes;status:no;location:no;menubar:no;help:no', function GotoPageAfterClose(pageid){if(pageid == 'hold') {STSNavigate(unescape(decodeURI('{SiteUrl}'))+
'/_layouts/15/hold.aspx'
+'?ID={ItemId}&List={ListId}'); return false;} if(pageid == 'audit') {STSNavigate(unescape(decodeURI('{SiteUrl}'))+
'/_layouts/15/Reporting.aspx'
+'?Category=Auditing&backtype=item&ID={ItemId}&List={ListId}'); return false;} if(pageid == 'config') {STSNavigate(unescape(decodeURI('{SiteUrl}'))+
'/_layouts/15/expirationconfig.aspx'
+'?ID={ItemId}&List={ListId}'); return false;}}, null); 0x0 0x1 ContentType 0x01 898 Historique des versions de l’ensemble de documents /_layouts/15/images/versions.gif?rev=23 javascript:SP.UI.ModalDialog.ShowPopupDialog('{SiteUrl}'+
'/_layouts/15/DocSetVersions.aspx'
+ '?List={ListId}&ID={ItemId}') 0x0 0x0 ContentType 0x0120D520 330 Envoyer à un autre emplacement /_layouts/15/images/sendOtherLoc.gif?rev=23 javascript:GoToPage('{SiteUrl}' +
'/_layouts/15/docsetsend.aspx'
+ '?List={ListId}&ID={ItemId}') 0x0 0x0 ContentType 0x0120D520 350
|
|
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 ! |
|