Juniper has a great “Getting Started” guide on setting up vMX on VMware vSphere. In the “Installing vMX with OVA files” section of the guide, it only uses the standard vswitch in the setup.
Installing vMX on VMWare Guide
So how do we setup vMX on a Virtual Distributed switch? Unfortunately, the “Getting Started” guide won’t help you. So I’ve created this guide to help you out. This guide assumes you’ve already setup a VDS already in your VMware environment. Below are two links that go over the basics of setting up the VMware vSphere Distributed Switch if you haven’t done that yet.
Part 1: Getting Starting with the VMware vSphere Distributed Switch
Part 2: Getting Starting with the VMware vSphere Distributed Switch
This guide was created using VMware vSphere 6.0 Update 2 via the web console. While the official documentation for vMX supports VMware 5.5, 6.0 works fine for lab environments.
So rather than repeat the entire “Getting Started” guide, I’m just going to go over the differences starting from the “Setting Up the Network” section of the guide.
Once you complete this section you can continue on the “Getting Starting” guide at the “Deploying the VCP VM” section.
- After logging into the web interface, click on the Networking section.
2. Click on the root of the virtual distributed switch, then the “Getting Started” tab, and then the “Create a new port group” section to start creating a port group.
VM port groups are a way that we can create logical rules around the virtual ports that are made available to VMs. It’s common to create a port group for each VLAN and network subnet that you want to present to your VMs. Port groups also can be used to create 802.1Q trunks.
As shown in the drawing below we are first creating the management port group. This is just a personal preference, but I normally name the port groups after the VLANS that they are part of. In the case of the management port group, you can just make one and associate all of your VMX’s first interface to the same VLAN. You don’t need to make a separate management port group for each router.
3. As stated earlier, give the management port group a descriptive name. In this example shown below, I’m using “VLAN350-Juniper-Mgmt”. Click next.
4. Change the VLAN type to “VLAN”, give it a VLAN ID, and check the “Customize default policies configuration”. In this example, I gave it the VLAN ID of 350. Click next.
5. This step is critical. In the security settings, “Promiscuous Mode”, “MAC Address Changes”, and “Forged transmits” need to be set to “Accept”. If you don’t do this you won’t be able to get into the management interface of the vMXs that you create later.
Next step we need to create the internal bridge between the VFP virtual machine and the VCP virtual machine, as shown in the illustration below.
This is just like the internal connection of a real hardware MX router that separates the control plane from the data forwarding plane. In this case, the Control Plane is the VCP virtual machine and the VFP virtual machine is the data forwarding plane. The VCP only has two connections. One is the management interface we created earlier and the other is the next interface we are going to create. This interface has to be unique for each pair of VCP/VFP virtual machines.
The VFP virtual machine can have up to ten interfaces. The last eight of them will be revenue ports for routing and bridging traffic but the first two interfaces are the management port and the internal port to connect to the VCP virtual machine.
FYI, the ten interface limit is a limitation of VMWare. Linux KVM can scale to 23 port per vMX.
6. We start the process the same way we created the other port group. In this case, I’ve given it the name of “VLAN351-R1-br-int”.
7. Change the VLAN type to “VLAN”, give it a VLAN ID, and check the “Customize default policies configuration”. In this example, I gave it the VLAN ID of 351. Click next.
8. Just as in the previous example, this step is critical. In the security settings, “Promiscuous Mode”, “MAC Address Changes”, and “Forged transmits” need to be set to “Accept”. If you don’t do this VCP and the VFP virtual machines won’t be able to communicate with each other and you’ll have no interfaces because the VFP won’t register to the VCP via the internal bridge we are building with this port group.
Final notes, before you continue on to the “Getting Starting” guide at the “Deploying the VCP VM” section.
- The Management port group can be the same for all of the vMXs. But the internal port group MUST be unique for each pair of VCP/VFP virtual machines. If two vMXs have the same port group as their internal bridge, neither will come up properly.
- When you create the other eight ports on the VFP virtual machine, you can use the same process as described above. “Promiscuous Mode”, “MAC Address Changes”, and “Forged transmits” need to be set to “Accept”.
- Also, if you want to play with 802.1Q trunking you can setup a port group as a trunk instead of a VLAN. Then you can play around with trunking vMXs together like you would traditional switches. There’s a lot of flexibility.
- This is just a personal preference, but I also create a port group and name it “disabled” and go into the “Miscellaneous” section of the port group and set “Block all ports” to “Yes” as shown below. Then any port that I’m not actively using on the VFP virtual machine I normally put in this port group.
I hope this helps you. Please feel free to leave me comments, questions, or corrections.
Netbine.net 