Hello,
Try the command: server identify-server-by-ip This command identifies reverse SLB traffic based on Source IP not just Source MAC. Greetings, Diederik On 1 Jun 2012, at 12:59 , Diederik Schouten wrote: > 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 <[email protected]> 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 >> [email protected] >> http://puck.nether.net/mailman/listinfo/foundry-nsp > _______________________________________________ > foundry-nsp mailing list > [email protected] > http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
