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
• Solution
• Configuration

Background

Lets first have a look in NetScalers documentation and to what it says MAC-Based Forwarding (MBF) is actually doing

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?

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

To solve this challenge in a neater way we can utilize Policy Based Routes (PBRs) instead.

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)

add ns pbr Mgmt ALLOW -srcIP = 192.168.100.1-192.168.100.254 -destIP "!=" 192.168.100.1-192.168.100.254 -nextHop 192.168.100.1 -priority 10
add ns pbr Srvr ALLOW -srcIP = 192.168.200.1-192.168.200.254 -destIP "!=" 192.168.200.1-192.168.200.254 -nextHop 192.168.200.1 -priority 20
add ns pbr DMZ ALLOW -srcIP = 192.168.1.1-192.168.1.254 -destIP "!=" 192.168.1.1-192.168.1.254 -nextHop 192.168.1.1 -priority 30
apply pbrs
add route 0.0.0.0 0.0.0.0 192.168.1.1
add route 192.168.0.0 255.255.0.0 192.168.200.1