Ignorer les commandes du ruban
Passer au contenu principal
SharePoint

Networking

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

 

Commentaires

Aucun commentaire sur ce billet.