[f-nsp] Asymmetrical routing on ADX

[Diederik Schouten]

Since the session/ip/port information does not change, I very much doubt it had anything to do with the way source-nat replies are coming back.

I expect it had all to do with the much more logical impact of the various security features and packetprocessing/forwarding logic.

Are the replies coming back from at least the same MAC address?

Looking at your setup I'm quite sure they are not.
MAC info is also included in the sessioncache/state-tables.

For fast processing (as the ADX) in its core is a switch it would be most efficient to return packets belonging to a particular session to the MAC address the packets were received from...
Or for security reasons you normally would want packets from a particular session to keep coming in on the same interface from the same MAC address... as anti-spoofing solution.

There is a not-so well documented command to set this to IP based rather than MAC based if I remember correctly.

I can't find it for the moment, but will look into it tomorrow.


I have to add that asym-routing in general is bad and should be avoided.
Why is this happening in your network? And is there a way to avoid it?


Greetings,

   Diederik

Sent from my iPhone

On 31 mei 2012, at 23:24, Drew Weaver <drew.weaver at thenap.com> wrote:

> Hi,
> 
> I have recently experienced a problem where performance to a VIP is terrible when the ADX is uplinked to two separate routers running VRRP. TAC suggested that it is because source-nat replies were coming back on a different physical interface than the requests went out on.
> 
> In my config I have ports 1 and 3 assigned to the same VLAN with a virtual ethernet attached. If both of the physical ports are assigned to the same VLAN/VE then why would the ADX care which VLAN members the replies return on? That seems to defeat the purpose of having virtual ethernet or L3 VLAN style functionality.
> 
> There has to be a work around for this, does anyone know what it is?
> 
> 
> 
> 
> 
> 
> Sent from my Samsung Galaxy Tab
> _______________________________________________
> foundry-nsp mailing list
> 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/20120601/334b4acd/attachment.html>