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

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?

Disabling MBF - Enabling PBR - Traffic Flows
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

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.

Disabling MBF - Enabling PBR - Detailed Schema

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

5 Replies to “Disable MAC-Based Forwarding – Enable Policy Based Routing!”

      1. 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.

        Like

      2. 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!

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.