The hashing in the MPLS Core vary from vendors, let’s take the example of Cisco, for IP payloads the load-balancing is done on IP header (L3/L4 fields) and for non-IP payloads it is done on the last label, this is required to preserve the characteristics of the emulated service (VPWS).
The routers distinguish the IP from non-IP payloads by checking the version field of the paylods: 4 for IPv4 and 6 for IPv6. But unfortunately if you have some non-IP payloads that starts with 4 or 6, the load-balancing can be messy, and it already happens with MAC addresses starting with 4 ;). So Cisco highly recommend to use for non-IP payloads in the L2VPN the CW which starts with a 0.
Kısaca payload eğer ip değil ise, Ethernet over mpls vs gibi, ve L2 info mac adresi 4 veya 6 ile başlıyor ise hatlar üzerinde istenmeyen bir yük dağılımı olabilir. Burada istenmeyen dağılımdan kasıt ; L2 VPN / PW kullanımında out-of sync paketlerin istenmez. Bu durumda kaynak ve alıcı arasında L2 VPN paketlerinin hep aynı path takip etmesi istenir. Yol üzerinde LSP router/ P router kendi üzerinden geçen trafik için hangi servisin verildiğini bilmez peki neye göre seçim yapar. En hızlı yöntem son etiketten sonra ki bitlere bakmaktır. Eğer 4/6 ile başlıyorsa IP demektir. Burada mac adreslerinin hep 00-0 ile başlayacağı var sayılmıştır. Günümüzde ise 4 ve 6 ile başlayan mac adresleri bulunmaktadır. Bu ise L2VPN için istenmeyen davranışa yol açabilir. Bunu önlemek için control-word kullanımı çözüm olabilir.
http://tools.ietf.org/html/draft-ietf-mpls-ecmp-bcp-03
A less obvious case is when the packets of a given flow happen to
have constant values in the fields upon which IP ECMP would be per-
formed. For example if an ethernet frame immediately follows the
label and the LSR does not do ECMP on IPv6, then either the first
nibble will be 0x4 or it will be something else. If the nibble is
not 0x4 then no IP ECMP is performed, but Label ECMP may be per-
formed. If it is 0x4, then the constant values of the MAC addresses
overlay the fields that would have been occupied by the source and
destination addresses of an IP header. As a result the ECMP algo-
rithm would be feed a constant value and thus would always return the
same result
Control word kullanımı bir çözüm olabilir.
Bunun için IETF iki çözüm yolu önermiştir :
– Flow Label, FAT label : L2VPN uygulanır. Tüm mpls etiketlerine ek bir flow label eklenir. Giriş ve çıkış mpls cihazları (ingress and egress LER) LSP kurulması sırasında LDPvb ile flow label kullanımını sinyalleşirler veya statik olarak belirtilir. Sonuçda mpls networkunde load balancing ek bir etikette kullanımda olur.LSP’lerde paket mpls gibi görülür ve mpls load balance göre, en altaki etikete göre load balance yapılırlar.
– Entropy Label : L2VPN, L3VPN için uygulanabilir. İki adet ek etiket kullanılır. Bunlarda ilki entrophy label kullanıldığını belirten, reserverd label olan 7’dir. Daha sonra flow label benzet enhtophy label gelir. Bu iki etiket transport label’dan sonra gelir. Dolayısı ile birden fazla transpot label kullanımı durmunda? Bakınız draft-kini-mpls-entropy-label-src-stacked-tunnels-01.
Bitstream access (PPPoL2TPoEoMPLS, tunnelerin EoMPLS ile PE router’a oradan’da BNG taşınması) P routerlarda bundle kullanılıyor ve mpls trafiği buradan geçiyor ise yükün dağılımında sorunlar olabilir (ether+mpls+mpls+ether (ttvlan)+ip (l2tp ipleri)+l2tp+ppp (kullanıcı paketdi). Bu durumda kullanıcı trafiğini (ppp) hash’e almanın bir yolu yoktur. Bu durumda bundle interface’i default olarak ip load balance (l2tp tunnel ipleri) veya mac load balance yapabilir. MAC göre yapılması pek tercih edilmiyebilir. Genelde her bir SSG trafiği ayrı bir vlan üzerinden, ayrı bir subint üzerinden, alınır. Subint’ler de genelde aynı mac’ı kullanır. Burada ip kullanılması veya FAT label kullanılması daha uygun olabilir. Bundle interfacelere eşit olarak dağılması zaten sorun değildir, zira TT’den alırkende trafiğin farklı bundle interfacelere dağılımı gerekecekdir.
TT=Provider PE=P=PE=BNG : TT ve Provider PE arasında nasıl dağılıyor ise Provider PE ve P arasındada benzer şekilde dağılacakdır. Eğer TT Provider PE arasını bundle yerine manual (vlan dağıtarak) yapılır ise benzer bir dağılım PE ve P arasındada otomatikman olacakdır (Her bir vlan bir src/dst ip veya SSG bağlantısına denk gelir. TT ve PE arasında’da bundle kullanılacak ise servislerin vlanların dağılımına dikkat edilmelidir (mac bazlıda sorun olabilir).
Linkeler :
https://www.nanog.org/meetings/nanog57/presentations/Tuesday/tues.general.SnijdersWheeler.MACaddresses.14.pdf
https://supportforums.cisco.com/discussion/10788591/mplsvpn-network-load-balancing-core
https://supportforums.cisco.com/document/111291/asr9000xr-loadbalancing-architecture-and-characteristics