Flow aware return path routing

[alanwright1]

Hi Folks,

I have this network:

Clients--RTR1----Net1----RTR2----Web

| |

|-----Net2-----|

In this case net1 and 2 are equal cost paths and thus packets can go via either. However, RTR1 sends the SYN of a TCP flow over NET1, then all other packets for the flow over NET2. Where will the return traffic come back via? NET1 or NET2. Is there a feature on IOS which can make RTR2 send packets back to the MAC where they actually arrived from and not via the routing table?

TIA

Alan

[Joseph W. Doherty]

"Where will the return traffic come back via? NET1 or NET2."

If RTR2 also sees equal cost paths toward RTR1, return traffic would "normally" pick one of the two paths without any relationship to the outgoing traffic path (from RTR1 to RTR2).

I'm unaware of any feature that makes L3 forwarding dynamically "sticky" with regard to the flow's opposite selected physical path.

Was there a reason or problem why you need such a feature?

[alanwright1]

There is a reason. Quite often with loadbalancers, it is possible to have the traffic being processed by different servers. In this case, there is a need to sticky the return path.

[Joseph W. Doherty]

Not 100% familar with loadbalancers, but I thought they, if necessary, keep state information and direct traffic to individual server. I.e. they weren't dependent on the network itself maintaining "sticky" paths.

Your example has equal paths between two routers. Where would the loadbalancers be deployed?

[alanwright1]

Prior to rtr1 there is a box which modifies the DSCP of certain flows. In RTR1, PBR is used to send traffic with modified DSCP via NET2. The question is about RTR2 being able to have flow aware stickyness.

[Joseph W. Doherty]

Perhaps what might work is NAT.

Instead of just using DSCP, which works fine outbound but I assume isn't echoed back, use NAT for the special traffic.

Outbound, the traffic with "special" addresses take the "special" path. Inbound, again the traffic with "special" addresses take the "special" path.

NAT will maintain state both directions.

[alanwright1]

One minor issue in this scenario. With TCP flows, the SYN goes via NET1 and the remainder goes via NET2. I am not sure that NAT will help here. RTR2 will need to follow the SRC mac for each traffic flow. The crazy thing is, I can do this on a linux router for free, but sadly, the IT policy is to prevent linux routers to be used in such a case.

[Joseph W. Doherty]

Seems rather strange that the initial SYN goes one path and follow on packets for the same flow go another. I can see excluding the first packet from DSCP marking, but again, seems strange to do so.

NAT could still possibly help because if it's a question of the first SYN packet not being marked with DSCP, this too could be done on the NAT'ed packets.