[j-nsp] 802.3ad Question

[alexi]

Great , thanks Mark ...

what JUNOS are you using ? , I´ve heard that it has some issues with load
balancing in 8.0

Thanks again
Alexi

On Sat, Oct 31, 2009 at 4:22 AM, Mark Tinka <mtinka at globaltransit.net>wrote:

> On Friday 30 October 2009 01:19:27 am alexi wrote:
>
> > I´ve been reading that the load balancing in the bundle
> > (balancing between physical interfaces in the same
> > bundle) may be achieved using different criterias like
> > source or destination IP ... but it seems is a global
> > configurarion  and dont understand why
> >
> > do you have experience configuring load balancing schemes
> > ? any hint would help
>
> In our case, the 802.1AX links are between a Juniper M7i and
> a Cisco 6500 (the 6500 is running as a pure Layer 2 switch).
>
> On the Cisco side, the default 802.1AX load balancing
> schemes they support (and we're using) are:
>
> #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
> #
>
> On the M7i, this is what we have:
>
> test at lab# show forwarding-options
> hash-key {
>    family inet {
>        layer-3;
>        layer-4;
>    }
>    family mpls {
>        label-1;
>        label-2;
>        label-3;
>        payload {
>            ip;
>        }
>    }
> }
>
> [edit]
> test at lab#
>
> We're aggregating 3x Gig-E links between both devices, and
> it's working fairly well. Traffic distribution from the M7i
> to the 6500 is 1:1:1, while traffic distribution from the
> 6500 to the M7i is 1:1:0.7 (but this direction is governed
> by other Layer 3 devices upstream of the 6500).
>
> All in all, not too bad for us, now.
>
> You might want to look into 'family multiservice' on the
> Juniper side, which provides load balancing at the MAC
> layer. But it has different attributes depending on the
> platform in use. We haven't tried working with it (but could
> if we consider services such as VPLS in the future).
>
> Cheers,
>
> Mark.
>
>