[c-nsp] Link aggregation funniness

[Mike]

Hi,

	So I have link aggregation happening and I'm noticing an interesting 
artifact in that I can no longer communicate with middle devices between 
the switches directly connected to the second port in the etherchannel, 
even tho it's very clearly passing traffic and apparently load balancing 
as expected.

	I am doing destination mac address balancing on sw1, and source mac 
address balancing on sw2. Behind SW1 is 'router' which is the source of 
management packets headed to the microwave radios. The radios which are 
on 'link#1', work fine. The radios on 'link#2', are unreachable. But I 
noticed also, if I originate management traffic from behind sw2, then I 
can talk to these but not the radios on link#1. Logically, all four 
radios are within a common subnet and on a common vlan.
	

router(vlan300)
	|
	|
	po1(vlan300)
	|
	link#1	sw1(gi0/6) -- DW1(near) --- DW1(far) -- sw2
	link#2	sw1(gi0/7) -- DW2(near) --- DW2(far) -- sw2



	What I think is happening, is that from the sw1 side, when the router 
sends a packet, the switch s simply picking the physical port to forward 
thru and this will be the same port everytime, thus radios on the other 
port won't ever hear their name called. I have experimented and if I put 
in a host route from the other side for the radios on the other link, I 
can make it work, I think it's only because of luck of the draw that the 
hash worked out to send out the other link. It seems then that really, 
with etherchannel, I cannot expect to have consistient access to middle 
devices and this really was intended for switch-to-switch operation. Can 
anyone suggest how I might make this fly?

Mike-