Jump to content
Welcome to our new Citrix community!

Binding subnets to interface


Recommended Posts

I have a NetScaler VPX running 13.0.47.24nc on ESXi with 3 vNIC's assigned, each on their own VM Network.   These VM Networks are not tagged so there are no VLAN ID's in use..   I am actually running in a shared hosting vCloud Director environment, which is the reason there are no VLAN tags on my VM Networks.  

 

 The 3 interfaces on the NetScaler are setup as follows. All 3 networks are /24

 

NIC 1 - Interface 0/1 - 10.5.1.5 - NSIP - Management network

NIC 2 - Interface 1/1 - 10.5.10.5 - SNIP - Server network

NIC 3 - Interface 1/2 - 172.16.5.5 - SNIP - DMZ - This is network out to internet (through Firewall DMZ Zone)

 

I've set the default route as 0.0.0.0/0.0.0.0 172.16.5.1 as this is the route to the internet.

 

The internal router on all 3 networks handling inter-network routing is a firewall and it's IP on all 3 of the above networks ends in .1 (10.5.1.1, 10.5.10.1, 172.16.5.1).  All servers on 10.5.10.0/24 have a default gateway of 10.5.10.1 and I intend to keep this (as opposed to pointing them to the NetScaler).

 

I believe I am having issues with packets going in one interface and out the other when I am crossing networks (ex: I ping from another device on Management network with IP of 10.5.1.100 to SNIP IP 10.5.10.5 and every other packet is dropped). 

 

After doing some reading, I can enable MBF, but Citrix KB's suggest this isn't the correct way to handle this, and that I should bind the subnets to their respective interfaces using VLAN's.  I see mention that this can be done even if there is no actual VLAN tagging going on (which is the case with my network configuration).  If that is so, do I arbitrarily pick a VLAN ID when I created it on the NetScaler?  Doing so won't cause the NetScaler to tag packets with this VLAN ID and potentially cause undesirable behavior in general?

 

 

 

Link to comment
Share on other sites

After some further reading, I see creating a VLAN without the "tagged" option means all traffic is sent without any tags on it, and it's just a port based VLAN, so that answers my question about the VLAN ID simply being arbitrary and won't have any impact on traffic flow.

 

I was still running into an issue with NSIP access outside the networks listed above (ie. across a VPN tunnel) where I was dropping every other ping, but I didn't have that issue from direclty connected network (ie. access from 10.5.10.100 to 10.5.1.5 is fine).   I found one of Carl S's articles that says to enable MBF or use a PBR to address asymetric routing where traffic is going into the NSIP but out a SNIP.  I opted to use a PBR  and that solved the issue.

 

This does bring me to the subsequent question, any reason to not just add a SNIP on the NSIP subnet to address the asymmetric routing of NSIP access? Since this is a VPX, interface 0/1 is not limited and it's already set to VMXNET3 in VMware.  I assume adding a SNIP on the Management network with the NSIP would let me remove the PBR and solve my access issue I had from across VPN.  All of my primary traffic is going to go through the DMZ and Servers network on other interfaces and SNIP's, so I wouldn't really be forcing more traffic through the Management network if I did this, correct?

 

Link to comment
Share on other sites

If you are accessing the NSIP from a source IP x.x.x.x then return traffic to the source  (without MBF) is based on route lookup of x.x.x.x. 

The route lookup of x.x.x.x will return a next hop then ADC will send traffic to that next hop via the appropriate interface but the source of the return traffic would be NSIP (has to be or else communication will fail).

 

Now, if you have a scenario where traffic from x.x.x.x to NSIP lands on interface 0/1 but the route lookup for x.x.x.x returns a next hop which is connected via int 0/2, then return will be via 0/2 (i think this is the problem you are having). in such scenarios modifying the route for x.x.x.x may not be feasible so better to stick with PBR that overrides the above logic

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...