[c-nsp] 6500: eompls in pfc mode vs. etherchannel load-balancing ?

[Phil Bedard]

I thought the restriction was speaking of the PE to P connection and  
the fact
it won't load-balance the EoMPLS LSP across multiple interfaces.

What is the hashing algorithm being used for the Etherchannel?  Guess  
it depends on
how the box pops the last label and selects on outbound interface...

Phil


On Mar 26, 2007, at 11:55 AM, Alexandre Snarskii wrote:

>
> Hi!
>
> Platform is 6509/12.2(33)SRA1, ingress card is 6704, egress is 6516,
> if that matters.
>
> Looks like that packets arriving from eompls circuit and destined
> to etherchannel all goes to just one of interface of channel...
> Is that intended behaviour (due to some hardware limitations, for
> example), or did i missed some feature ? :)
>
> Configuration is straightforward,
> int te 7/1
>  description UPLINK
>  mtu ...
>  ip address ...
>  mpls ip
> int po12
>  description Etherchannel to DOWNLINK
>  switchport
>  switchport trunk encaps dot
>  switchport trunk allowed vlan none
> int po12.NN
>  encaps dot NN
>  xconnect A.B.C.D NN e m
> int gi 4/7
>  channel-group 12 mode on
> int gi 4/8
>  channel-group 12 mode on
>
> And the results is as follows:
> GigabitEthernet4/7 is up, line protocol is up (connected)
>   30 second input rate 141600000 bits/sec, 45946 packets/sec
>   30 second output rate 0 bits/sec, 0 packets/sec
>      1376 packets output, 893315 bytes, 0 underruns
>      0 output errors, 0 collisions, 0 interface resets
>      0 babbles, 0 late collision, 0 deferred
>      0 lost carrier, 0 no carrier, 0 PAUSE output
>      0 output buffer failures, 0 output buffers swapped out
> GigabitEthernet4/8 is up, line protocol is up (connected)
>   30 second input rate 141962000 bits/sec, 46996 packets/sec
>   30 second output rate 821745000 bits/sec, 138817 packets/sec
>
> - traffic from client to eompls circuit is balanced well (by client's
> switch, not by our), and traffic from eompls circtit to client is not
> balanced at all.
>
> PS: why do I think that that behaviour may be due to hardware  
> limitation:
> there is a limitation in ethernet->eompls way, clearly standed in
> documentation:
>
> PFC3BXL or PFC3B mode EoMPLS does not support load balancing at the  
> tunnel
> ingress; only one Interior Gateway Protocol (IGP) path is selected  
> even if
> multiple IGP paths are available, but load balancing is available  
> at the
> MPLS core.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/