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
