vSZ-D Network Configuration

[ross_halliday]

Hello,

I'm attempting to turn up a vSZ-D instance in my lab. I've got a pair of vSZ controllers running in a cluster, each with three interfaces (Management, Cluster, Control). The vSZ-D documentation is pretty bad, as it calls the one interface "Management/Control" and doesn't really say what it does, or really how it's supposed to connect to the vSZ controllers. I've tried it on both the "Management" and "Cluster" networks but I can't get it to connect. I have not tried it on the "Control" (which is Public) for the controllers as this is the same subnet as the "Data" interface should be on.

Also, I have no idea how the "Data" interface is supposed to work VLAN-wise. Is the IP I assigned just untagged?

Could someone share how theirs is configured and working? I would really appreciate it!

Thanks

[eddie_sanmarco]

MY SE says he has not learned this deployment yet as it is so new. We are having a heck of a time getting this to work on Cisco UCS using direct I/O.

[ross_halliday]

I should follow up on this post, then! We have managed to get the vSZ-D working. The software has a problem in that, unlike the controller, it doesn't let you select which interface should be used for default routing. It turns out that the vSZ-D talks to the controller on the Control interface - not Management. This meant, for us, that it was trying to send all packets out of the Management interface, instead of the "Data" interface.

On the vSZ-D we had to change the Management and Control/Data to be in the SAME subnet/VLAN, and point it to the public IP of the controller. It then worked flawlessly. Of course management protocols now need to be firewalled off.

Our SE is working on getting this behaviour corrected so it acts more like the vSZ software.

[eddie_sanmarco]

So what I'm hearing is that when asked for the IP address of the vSZ-H controller I should be giving the vSZ-D the IP address of the control interface and not the management interface of the controller? The instruction specifically say that on the vSZ-D the management and data interface need to be on separate networks, so one of your statements confused me. I need the vSZ-D to communication on the 1Gig interface to the vSZ controller and all of the client data to use the data Direct I/O 10Gig interface on the vSZ-D.

[ross_halliday]

Yeah, it's very confusing. The important parts are:

 - vSZ-D "Management/Control" must connect to vSZ-H "Control"
 - vSZ-D "Data" is in totally separate routing table and not used as a candidate for routing any traffic other than tunnels

I eventually tried setting the vSZ-D to connect to the vSZ-H's Control IP (which is public). I expected the vSZ-D to start sending packets out of its own Data interface, which has an IP in the same subnet. This was not the case - it just sent them out the Management interface towards the default gateway. My setup has a totally isolated management VLAN so that default gateway was fake - if I had a firewall or router in there of some sort, the vSZ-D probably would have been able to communicate outwards to the vSZ-H with NAT or something, but it would have been ugly.

You can absolutely run the vSZ-D's Management/Control and Data interfaces on different network. In my setup it was easier to just put them on the same VLAN as I only allocate one /24 of public IPs per site. The APs still connect to the vSZ-D's Data interface. 

Hope that makes sense now!

[eddie_sanmarco]

Mind if I ask you, What VM platform are you using and are you using Direct I/O as recommended by Ruckus since they say vSwitch can cause random reboots to the vSZ-D.

I basically got this answer from them so far: "I spoke with our developer and below is the recommended NICs. If your Cisco UCS server is using other than the recommended then we don't support it." with a picture of their infamous documentation. Not very happy being told too bad so sad.