Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Cisco: NSP

Link aggregation funniness

 

 

Cisco nsp RSS feed   Index | Next | Previous | View Threaded


mike-cisconsplist at tiedyenetworks

Aug 2, 2012, 6:49 PM

Post #1 of 3 (284 views)
Permalink
Link aggregation funniness

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


gert at greenie

Aug 2, 2012, 11:32 PM

Post #2 of 3 (258 views)
Permalink
Re: Link aggregation funniness [In reply to]

Hi,

On Thu, Aug 02, 2012 at 06:49:52PM -0700, Mike wrote:
> 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.

Exactly so. (Hashed by src/dst MAC address, or src/dst IP address,
depending on switch model and balancing setup - but that won't change
the issue for you).

> 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?

Do away with the port-channel, use two l3 vlans and l3 load balancing?

(Hard to say whether that's a viable alternative without knowing more
about your needs)

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert [at] greenie
fax: +49-89-35655025 gert [at] net


mike-cisconsplist at tiedyenetworks

Aug 3, 2012, 8:40 AM

Post #3 of 3 (249 views)
Permalink
Re: Link aggregation funniness [In reply to]

On 08/02/2012 11:32 PM, Gert Doering wrote:
>
> Do away with the port-channel, use two l3 vlans and l3 load balancing?
>
> (Hard to say whether that's a viable alternative without knowing more
> about your needs)
>
>


I figured it out - with link aggregation, it's not possible to reliably
talk to the middle devices precisely because of the load balancing. In
my case then, my middle devices do in fact have a seperate dedicated
ethernet for management for exactly this reason, so instead of me trying
to just do inline management, I'll plug the out of band management
cables in and should be good to go. Still this was an interesting
lession, thanks.

MIke

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Cisco nsp RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.