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

[Alexandre Snarskii]

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.