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:[email protected]]
Sent: Sunday, June 03, 2012 12:38 PM
To: Drew Weaver
Cc: [email protected]; [email protected]
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 
<[email protected]<mailto:[email protected]>> 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: 
[email protected]<mailto:[email protected]> 
[mailto:[email protected]<mailto:[email protected]>]
 On Behalf Of Drew Weaver
Sent: Saturday, June 02, 2012 10:16 AM
To: '[email protected]<mailto:[email protected]>'; 
[email protected]<mailto:[email protected]>
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: 
[email protected]<mailto:[email protected]> 
[mailto:[email protected]<mailto:[email protected]>]
 On Behalf Of [email protected]<mailto:[email protected]>
Sent: Friday, June 01, 2012 3:08 PM
To: [email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
[email protected]<mailto:[email protected]>
http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
[email protected]<mailto:[email protected]>
http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp

Reply via email to