ESXi 6.5 nfs dedicated vswitch

[Nicklebon]

Hopefully someone can point where I am screwing this up as I have no doubt that is the case. I am trying to set up a dedicated switch for NFS traffic on an AOI server using Napp-it. I have the vswitch and port groups setup. I have a single nic from the napp-it vm and vmk1 in dedicated PGs connected to the switch. I also have a dedicated stack. I can ping each interface from the other, provided I specify the custom stack on esxi. What I cannot do is connect via nfs. Also when I attempt to traceroute from the esxi console it is attempting to exit the wrong interface. Thoughts?

 

[Eickst]

What subnets are you using for everything? If your mgmt ip and napp-it box are on same subnet and you are trying to get to napp-it box it might need a static route to go to that IP over the nfs vmkernel port you created.

 

[Nicklebon]

The management interface,vmk0, of the ESXi box is in the 192.168.2.0/24 network as is one interface on the napp-it. The ESXi box also has vmk1 which is on 192.168.57.0/24 as .1. Napp-it also has an interface on 192.168.57/0/24 as .2 and this is the address being used for the nfs mount. I can ping both interfaces from napp-it and esxi. I see no packets from esxi on the napp-it when snooping the appropriate interface and attempting the mount. The vswitch looks like this:

 

[Eickst]

This may be a dumb question, are you trying to mount by name or by ip?

Also, have you checked the napp it server nfs permissions and make sure it isn't set to not allow the IP?

 

[Nicklebon]

I am mapping by IP. The issue has something to do with the custom stack. I deleted vmk1 and added it back using the default stack and everything works. This is not ideal and not a long term solution but atm it does work.

 

[Spartacus09]

View attachment 76728

So you have your management vmk0 port setup and functional connected to physical nic 0
And your goal is to have a second virtual switch dedicated to NFS traffic? do you have a a second nic port or just one?

From the looks of the picture you need to assign a physical adapter to the virtual vmk1 switches for it to function if you have dual nics.
Or are you trying to bridge two VMs together via a virtual switch?

 

[Eickst]

It's an all in one box so he isn't using physical adapters, just a virtual napp-it box to server up all the storage (i'm assuming with OP's first post)

 

[Grimlaking]

The management interface,vmk0, of the ESXi box is in the 192.168.2.0/24 network as is one interface on the napp-it. The ESXi box also has vmk1 which is on 192.168.57.0/24 as .1. Napp-it also has an interface on 192.168.57/0/24 as .2 and this is the address being used for the nfs mount. I can ping both interfaces from napp-it and esxi. I see no packets from esxi on the napp-it when snooping the appropriate interface and attempting the mount. The vswitch looks like this:

View attachment 76728

Maybe I'm going too deep here.

But you have two different subnets that need to talk to each other. This means they will need a gateway to know the route to reach the other via TCP/IP. As these have no actual adapter access to traverse an actual network have you constructed your own virtual network with a gateway for these to reference?

Or maybe I just don't see where the other VM is in the network construct. A /16 might work for you to allow anything in the last two octects to co exist as long as they are not on different vlans.

Again maybe I went the wrong way based on this post.

 

[Nicklebon]

Not a routing issue. All devices in question have interfaces directly attached to the appropriate networks.

 

[lopoetve]

I am mapping by IP. The issue has something to do with the custom stack. I deleted vmk1 and added it back using the default stack and everything works. This is not ideal and not a long term solution but atm it does work.

Why not? Default routing stack says "if there's an interface on the right subnet, use it - if not, use default gateway" - that's exactly what you want

Other vmkernel stacks are for when you need things to do something ~other~ than the above, like a static route through an ipsec gateway or the like that doesn't obey the normal rules.