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-
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
