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.
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.
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
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!
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
8 Replies to “Disable MAC-Based Forwarding – Enable Policy Based Routing!”
MBF is just not worth it especially if you plan to deploy virtual appliances on Hyper-V! Thanks for the tips.
Haha, guess what the mentioned second article about a troubleshooting session involving MBF will involve
(spoiler) Hyper-V :-)
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!
You say that PBRs overrule normal routes but what about direct routes where a snip is involved, which one is used in that case, the PBR or snip/direct route?
Hi Eric, PBRs even superseed direct connected routes. Thats why I added the “destination != local subnet” in the PBRs. That way the PBR won’t match that traffic and the regular direct connected routes apply.
Dear Manuel ,
we are facing the same probelm exactly and i open case with citrix , and follow up your article
i configured PBR cause i didnt have one gateway for all subnet , and i cannt recognize the client
subnet , and i have multiple subnet also for servers so different gateways , so please correct me
i configured pbr by add put the server gatway at next hop , and low source ip with virtual ip address only , and its work and the performance become very good
? this is considred as true or not , or did i need any thing else ??
firstname.lastname@example.org , im waiting your response :)