Disable MAC-Based Forwarding – Enable Policy Based Routing!

Enabling MAC-Based Forwarding (MBF) has become the go-to solution solution for multi-arm NetScaler deployments and routing issue bodging in a majority of the NetScaler deployments I’ve seen. But is it the right solution for the problems? Usually not.

Contrary to MBF being known as a problem solver, I came across several troubleshooting sessions with very weird connectivity and routing issues that I as actually able to fix by disabling MBF. Read about one example in my article about NetScaler services flapping with Hyper-V.

Background

With MAC-based forwarding (MBF) enabled, when a request reaches the NetScaler appliance, the appliance remembers the source MAC address of the frame and uses it as the destination MAC address for the resulting replies. MAC-based forwarding can be used to avoid multiple-route/ARP lookups and to avoid asymmetrical packet flows.

To further understand the problem in multi-arm deployments and the reason why MBF helps we need to ensure that we “think networking device” here.

Unlike a multi-arm Windows Server for example, NetScaler can be utilized as a router and will always behave like one. Means it will always take the shortest route, regardless of the interface on which the the user actually just requested a VIP for example.

If we take a sort of typical network architecture similar to the following and look at the traffic flows we can see one challenge: Where do we put our routes to the Client network?

Traffic Flows in a typical NetScaler Deployment

If we point the route towards the management network we’ll mess up the traffic to the server network and the same applies to the other direction.

MAC-Based Forwarding solves this by simply answering back to wherever the request came from. While that works in 95% of the cases it can create problems in more complex networks that I’ve outlined in the mentioned article about NetScaler services flapping with Hyper-V.

Solution

While regular routes allow routing decisions only based on the target, Policy Based Routes allow to consider other factors like:

Source IP

Desination IP

Protocol

etc.

So what we can do is define Policy Based Routes instead that will overwrite the regular routing table and force the respective traffic flows to be routed to their appropriate gateways.

This can be done by creating one PBR for each of the attached networks with the following simple parameters:

Source-IP equals network

Destination-IP does not equal network

Route to the network’s Gateway

Let’s look at the prior example once more and let’s look at the actual IP layer and validate that.

If you think about it, this solves all the challenges: Paket that need to be routed will be routed to the appropriate gateways, non-routed packets will be handled by the existing “direct-connected” routes.

It’s important to note, these only work for client initiated sessions! For NetScaler initiated sessions, same like with MBF, NetScaler will still need regular routes!

Configuration

The configuration is pretty simple, in the above scenario I’d configure the routing as follows (filled with some sample subnets)

This makes sense for internal clients consuming NS resources from the server VLAN. What if you have internal VPN users or L2L users coming in from the firewall (1) Have access to hit the NS AG from the DMZ (2) Can access NS LBS through inside interface and to server VLAN. NS Default route is the DMZ FW.

How would PBR resolve this? its seems to me the only way would be MBF. I can provide a diagram if necessary.

Hi Ethern, sorry for the late reply!
Not sure if I understand your problem correct. A diagram might help indeed :)

If you have a PBR for example for the server LAN that states:
“source=server LAN, destination!=server LAN, gateway server LAN gw”
Then if a VPN client coming in accessing a VIP on the server LAN the response would be routed correctly because the response (server LAN vip > any/VPN user) would match the above.

But maybe I’m getting it wrong – happy to take a closer look if your willing to draw a diagram!