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