[f-nsp] Asymmetrical routing on ADX

[Drew Weaver]

Yes, on traffic leaving the load balancer, all of that traffic will go out via the current master in the VRRP group, but the responses from both the client and the remote server could come back via either physical port.

Thanks,
-Drew


From: Mike Allen [mailto:mkallen at gmail.com]
Sent: Sunday, June 03, 2012 12:38 PM
To: Drew Weaver
Cc: jeffm at iglou.com; foundry-nsp at puck.nether.net
Subject: Re: [f-nsp] Asymmetrical routing on ADX

Drew, this is actually expected behavior, for pretty much every L3 Switch/Router I have seen.  Arp resolves ip address to mac address, and mac address (normally) is associated with a single port (per vlan) at any one point in time.  If you have Mac addresses moving back and forth, that is generally a bad thing in a switched environment.  Traffic has the possibility of being black holed, as it will be forwarded only to the port where the destination mac address is at the instant the switch is ready to forward.

If you are looking to duplicate the traffic across multiple ports, you need to do a static arp entry, and possibly a static mac entry as well.  This will duplicate all packets to that ip/mac combo, and send it to multiple ports.  I have generally only seen this in clustering scenarios (like Microsoft Load Balancing), not in VRRP.  In normal VRRP, there is still a singular owner of that VRRP VIP at any one point in time, one router that will answer Arp's, thus it should only be learned on one port, not both.  If you are seeing it on both, it sounds like there may be a problem there.

WIthout seeing the configs, or more info, those are my thoughts, hope it helps.

Mike
On Sun, Jun 3, 2012 at 5:27 AM, Drew Weaver <drew.weaver at thenap.com<mailto:drew.weaver at thenap.com>> wrote:
I hate to reply to myself but I noticed that even though the switch is running router code and it's IP addresses are all handled via the VE when I do show ARP it is still seeing the arp on the physical ports rather than the VLAN.

This is pretty unfortunate.

Thanks,
-Drew


-----Original Message-----
From: foundry-nsp-bounces at puck.nether.net<mailto:foundry-nsp-bounces at puck.nether.net> [mailto:foundry-nsp-bounces at puck.nether.net<mailto:foundry-nsp-bounces at puck.nether.net>] On Behalf Of Drew Weaver
Sent: Saturday, June 02, 2012 10:16 AM
To: 'jeffm at iglou.com<mailto:jeffm at iglou.com>'; foundry-nsp at puck.nether.net<mailto:foundry-nsp at puck.nether.net>
Subject: Re: [f-nsp] Asymmetrical routing on ADX

That's exactly my stance on this issue.

It's especially annoying considering that the two physical ports in question are attached to a VLAN/Virtual Ethernet, I don't understand why it matters which physical interface in the VLAN handles the traffic destined for the VE..

To me that is really broken.

Thanks,
-Drew


-----Original Message-----
From: foundry-nsp-bounces at puck.nether.net<mailto:foundry-nsp-bounces at puck.nether.net> [mailto:foundry-nsp-bounces at puck.nether.net<mailto:foundry-nsp-bounces at puck.nether.net>] On Behalf Of jeffm at iglou.com<mailto:jeffm at iglou.com>
Sent: Friday, June 01, 2012 3:08 PM
To: foundry-nsp at puck.nether.net<mailto:foundry-nsp at puck.nether.net>
Subject: Re: [f-nsp] Asymmetrical routing on ADX

On Fri, June 1, 2012 12:25, Drew Weaver wrote:
> Why is asymmetrical routing bad if you have a complete mesh?

It isn't (even without a complete mesh).

Asymmetric routing is commonplace and normal, if you need a chokepoint to apply some sort of network policy (load balancing, firewalling, etc.) you need to make sure that you make it a chokepoint both coming and going, and if gear can't handle the next-hop (or even the interface that it uses) may be different for transmitted and received traffic, then bug reports need to be filed.


--
Jeff

_______________________________________________
foundry-nsp mailing list
foundry-nsp at puck.nether.net<mailto:foundry-nsp at puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
foundry-nsp at puck.nether.net<mailto:foundry-nsp at puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
foundry-nsp at puck.nether.net<mailto:foundry-nsp at puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20120604/62a3c86d/attachment.html>