On Friday, October 21, 2011 12:00:47 AM Alexandre Snarskii wrote: > Well, there are scenarios when load-balancing will not > happen (for example, if LAG carries point-to-point link > between routers, and traffic is MPLS-encapsulated), but > this is expected behaviour (S/D mac's are always the > same in this case, and that's the only option for non-ip > traffic on EX series).
That was my initial deduction (you're right, our traffic is
MPLS-encapsulated on egress) during the maintenance window,
but then remembered that before our Cisco 6500's could
specifically add MPLS labels to the hash algorithm, I could
load balance MPLS traffic with no issue.
Below is the algorithm on the Cisco that replaced the
EX4200. Notice it doesn't support MPLS labels for hashing:
test@lab#sh etherchannel load-balance
EtherChannel Load-Balancing Configuration:
src-dst-ip
EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Disabled
IPv4: Source XOR Destination IP address
IPv6: Source XOR Destination IP address
test@lab#
Now look at the 6500 which does (and also supports load
balancing of MPLS traffic):
test@lab#sh etherchannel load-balance
EtherChannel Load-Balancing Configuration:
src-dst-ip
mpls label-ip
EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Source XOR Destination MAC address
IPv4: Source XOR Destination IP address
IPv6: Source XOR Destination IP address
MPLS: Label or IP
test@lab#
So I assumed that since the Cisco could look deeper into the
frame and extract IP information on which to hash, that the
EX4200 could do it.
Obviously, I was wrong, because even the Cisco switch we put
in to replace the EX4200 doesn't have label hashing, it
still can load balance the MPLS-encapsulated traffic,
perhaps just by IP address alone embedded within the MPLS
payload.
Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
