Just a quick post on Interface ordering when using vmxnet3 on VMware. When you add more than 4 vmxnet3 data interfaces, on the addition of the 5th interface you may see that interface ordering is no longer sequential. This is not a vMX specific issue, it is due to the way the VMware balances PCI slot numbers to the guest PCI bus topology. More info here.

If you are using the vSphere Web Client, select the VM Options tab, click Advanced in the left frame, and click Edit Configuration at the bottom of the page.
If you are using the vSphere desktop client, select General under Advanced in the left frame, and click Configuration Parameters at the bottom of the page.)

Change the value of the following pciBridge settings from TRUE to FALSE:
pciBridge5.present
pciBridge6.present
pciBridge7.present
Do not make any changes to pciBridge0.present and pciBridge4.present

Click OK to update the VM settings, and then add any further vmxnet3 network adapters as may be required.

Now power up the VFP VM and check that the interface ordering is now correct.

Note, if you require more than 7 data interfaces, it may be necessary to make further changes. Repeat the steps above, however now change the pciBridge.preset from FALSE to TRUE and update the below parameters (add any that are missing):
pciBridge5.virtualDev = pcieRootPort
pciBridge5.functions = 8
pciBridge5.pciSlotNumber = 22

Share this:

My Day One book on the vMX is now available – the book gives an introduction to vMX and then goes on to walk through a complete build of it on Ubuntu Linux (Junipers preferred distribution). So you can get familiar with vMX and Junos, you will get straight in to the Lab and build and scale a topology, learning about EVPN and VPLS along the way.

The Day One is for network engineers or architects who are interested in learning more about vMX, and KVM in general. You might be thinking about how to deploy vMX in a production environment, or how to build and scale a lab or simulation, without access to physical routers.

It was a fun project and I’d like to thank Juniper for the opportunity.

Share this:

As of Junos 15.1F4, Juniper are now officially supporting vMX on Vmware.

The installation process has quite a few steps to it, so following on my my vMX Getting Started Guide for KVM, here is a quick post showing you how to do it on your home lab running Vmware Hypervisor ESXi 6.0.

ESXi Installation

Let’s get started with the installation of ESXi. I’m doing this running ESXi as a nested VM on a Macbook, but the process would be the same if you were doing it on bare metal.

Register with Vmware and download the ESXi ISO from Vmware and then boot your machine from the ISO. The installation of ESXi is a simple process. Go through the installation steps one by one and reboot ESXi once the installation has completed.

Following the reboot ESXi will load up and if your management LAN is running DHCP the host will have been assigned an IP address for management. You need to download the VMware client to be able to manage ESXi free. Open a web browser and connect to the ESXi IP – download the tools as suggested, and then load up the client.

Once the client is loaded, firstly you should license the ESXi host. You can get a free license from Vmware at the ESXi download page.

In the web client the license is applied at Home – Inventory – click configuration and then Licensed Features. You can then click edit to apply the license.

vMX Installation

If you have a valid login, you can download vMX directly from the vMX download page.

Now load up the client for your ESXi server and login.

There is no OVA build currently, so several steps need to be done manually.

Copy Files to the Datastore

Before progressing any further you will need to extract the vMX package. All of the vmdk files are located in the subdirectory “/vmdk”.

Software image for vMX VCP: jinstall64-vmx-15.1F4.15-domestic.vmdk

Software image for VCP file storage: vmxhdd.vmdk

Software image for VFP: vFPC-20151203.vmdk

metadata_usb.vmdk: Virtual hard disk with bootstrapping information. This is used by the VCP.

Click the summary tab, select the datastore under Storage, right click and select Browse Datastore.

Create a folder called “vmx” and then click the upload file button and upload all of the vmdk files listed above to this new folder.

Set Up the vMX Network

If you are not familiar with vMX then at this point it would be a good idea to read over my vMX Getting Started Guide for KVM, so that you understand the architecture of vMX, and how the vMX virtual machines communicate with one another.

The VMware release is no different to the KVM release when it comes to the required default networks. There are a minimum of three networks that will need to be configured:

Management network (br-ext)

Internal network for VCP and VFP communication (br-int)

Data interfaces

To create these networks, go back to the ESXi client, select the ESXi server and click theConfigurationtab. Select Networking under Hardware. In the top right corner click Add networking.

Management Network

Select Virtual Machine as the connection type and click next

Select Use vSwitch0 and click next

At port group properties, set network label to br-ext and click next

Now click finish

You will see the new port group “br-ext” has been added to the standard switch vSwitch0.

Internal Network

Again, select Networking under Hardware. In the top right corner click Add networking.

Select Virtual Machine as the connection type and click next

This time select Create a vSphere standard switch and clear all physical NIC check boxes, then click next

For network label, use br-int

You should now have a port group called “br-int”, with no adapters assigned

Data Network

Now add a data network, the process is repeated according to the number of data NICs that you wish to add. Time to create a single adapter named p1p1.

Again, select Networking under Hardware. In the top right corner click Add networking.

Select Virtual Machine as the connection type and click next

Select Create a vSphere standard switch and add the physical NIC that you want to use, and click next

Name the connection p1p1, click next, and finish

Repeat this process if you have any more data adapters to add to vMX.

Complete the network configuration

You will now see the 3 networks in the networking summary screen – br-ext, br-int and p1p1.

You must enable promiscuous mode in all vSwitches so that packets with any MAC addresses can reach the vMX. e.g. for OSPF to work properly.

For each vSwitch, click properties, then select vSwitch and click edit. Select security and change promiscuous mode to accept.

Set Up the vMX Virtual Machines

Just like vMX on KVM, there are two VMs that must be created – the virtual control plane (VCP) running the Junos OS, and the virtual forwarding plane (VFP) running an x86 visualised release of Trio running on Wind River Linux.

The process for creating both of the virtual machines is very similar. It’s a simple case of following the VMware wizard and choosing the correct settings for the VM.

VCP

This process below outlines the steps required to create the VCP virtual machine.

Within the VMware client, select the ESXi host, right click, new virtual machine

Select to create a custom virtual machine, and press next

Give the machines a suitable name, e.g. vcp-vmx1

Select the datastore where you would like to store the VM and press next

Set the virtual machine version to 8

For the guest OS type, choose Other, Other (64-bit)

Select one virtual socket, and 1 cpu core per socket, to assign a total of 1 CPU core to the VCP

Provision 2GB of memory

In the network setup, select 2 network adapters.
Asign br-ext as the 1st adapter and br-int as the 2nd adapter.
Set both to be e1000.

Select LSI Logic Parallel as the SCSI controller

When prompted to select the disk type, choose use an existing virtual disk, and then on the next screen browse to the correct datastore and select the jinstall64-vmx-15.1F4.15-domestic.vmdk image that you uploaded earlier

At the advanced options page, simply click next

Select to edit the virtual machine settings before completion and click continue

Now you need to add two more hard drives – click Add, and then Hard Disk, this time selecting vmxhdd.vmdk as the second drive

Repeat the add Hard Disk process again this time adding the metadata_usb.vmdk image as the third drive.

NOTE: this 3rd hard drive is important – if you don’t configure it then the first time VCP boots, VCP will setup as an “olive” not vMX!

You can now boot the VCP!

If the boot process appears to wait at “Loading /boot/loader” do not worry, on the VMware release you don’t see the full Junos OS boot process on the console.

VFP

This process below outlines the steps required to create the VFP virtual machine.

Within the VMware client, select the ESXi hosts, right click, new virtual machine

Select custom and press next

Give the machines a suitable name, e.g. vfp-vmx1

Select the datastore where you would like to store the VM and press next

Set the virtual machine version to 8

For the guest OS, choose Other, Other (64-bit)

When prompted to select the number of CPUs, for this build the minimum you can choose is three virtual sockets, and 1 cpu core per socket, to give a total of 3 CPU cores assigned to the VCP

Provision 8GB of memory

In the network setup, select at least 3 network adapters, assigning br-ext as the 1st adapter and br-int as the 2nd adapter. Set them both to be e1000 adapters. The data adapters can now be selected, set them to vmxnet3 or e1000 depending on your preference. For better performance, I’d suggest you use vmxnet3 because this is a paravirtualization adapter.NOTE: if you wish to use SR-IOV – at the time of writing SR-IOV is not officially supported on VMware, only on KVM.

Select LSI Logic Parallel as the SCSI controller

When prompted to select the disk to use, choose use an existing virtual disk, and then on the next screen browse to the datastore and select the vFPC-20151203.vmdk image that you uploaded earlier (bear in mind the image naming has changed from vPFE* to vFPC* in this latest release of vMX)NOTE: on my build the Juniper supplied image needed to be converted to thick provisioned using vmkfstools, otherwise the VM refused to boot (I was getting a VMware error related to free space even though the drives were not full). You may not have to do this! Thanks to @tomverhaeg for working through this strange issue with me!

At the advanced options page, simply click next

At Ready to Complete, you can click finish and boot the VFP!

NOTE: VMware virtual console for the VFP does not show anything beyond “Please Wait: Booting” – if you wish to login to the VFP you will need to configure serial console. The process for setting up serial console is described here.

Verification

At this point if both machines have powered on successfully you should have a running vMX.

Now login to the VCP and run the Junos command “show chassis fpc”. After a few moments you should see the FPC as online and ge-* interfaces will appear.

Share this:

I’ve been working on a few projects recently that have in one way or another required the leaking of routes between different routing tables / routing instances. When I first started working with Junos I did find RIB groups a bit confusing, so here goes with a post about the feature.

In this post I’m going to show you three ways to leak routes between tables – using RIB groups, Instance Import and Logical Tunnels.

Lab topology

In this post I will re-use the topology I created in my last vMX post.

The topology consists of 2 x vMX, PE1 and PE2 will be the main routers on each vMX, and INTGW and CE2 will be Logical Systems.

The link between PE2 and CE2 will be via a VRF routing-instance “red”. All other routes are in table inet.0.

The object of the lab is to leak routes between inet.0 and red.inet.0 on PE2. We will leak a default route between inet.0 and red.inet.0 and leak CE2’s loopback in to inet.0

First let’s setup the topology…

INTGW

This device is simulating an Internet gateway. I will originate a default route in IS-IS to the rest of the topology.

RIB Groups

First of all I will go though how to accomplish the objective with RIB Groups alone.

Essentially a RIB group will allow you to take a route that would be normally be destined for one table, e.g. inet.0, and place that route in another table also, e.g. red.inet.0. This can be done for static, connected, or dynamic routing.

Dynamic routes, these are applied per protocol, e.g. set protocols ospf rib-group <name>

For this lab we’ll be leaking the IS-IS routes, so I apply the rib-group to IS-IS. Remember as I am leaking routes from inet.0 to red.inet.0 I must apply the rib-group in the master config, not under the routing instance.

The rib-group is applied in to the table where the routes would normally be placed.

Awesome! The IS-IS routes are there – we can see the default route and also the loopback on PE1. But what if we wanted to leak the default only? Junos has that covered with an import policy.

I’ll create a policy to accept the default only and apply that to the rib-group.

Just a quick note on the import policy – as IS-IS has a default import policy of accept, I need to add a final term to reject otherwise I will match everything! See this Juniper doc for a reminder of the default import/export policies for the various routing protocols.

No default route there! Well I purposely made my life difficult by running a different protocol between PE2 and CE2. Remember PE1 and PE2 are talking IS-IS, but PE2 and CE2 are talking OSPF. So whilst the IS-IS route is now in the red.inet.0 table, we need to create an export policy to redistribute the IS-IS route over to CE2 via OSPF. The export policy is applied to the routing-instance.

Note this time my policy does not need an explicit reject to be configured as the default export policy for OSPF is reject.

Great, so CE2 knows how to route to INTGW via the default, but INTGW will not know how to route back at this point. I could do NAT on PE2 to hide the address of CE2, or repeat the rib-group process but this time to leak routes from red.inet.0 to inet.0 on PE2. We’ll do it with a rib-group.

Notice this time that the order of the import-rib has changed. We are copying routes from red.inet.0, as this is where the routes would normally be placed so red.inet.0 is the first entry in the import-rib statement. This also reminds us where to apply the rib-group.

The rib-group is applied to the routing-instance OSPF process, and again we must export the OSPF routes to IS-IS. Note this export is applied to the master IS-IS process, not the routing instance.

This policy is simply saying for a default route in the master inet.0 table then accept for import and deny everything else. We then apply this policy to the red routing-instance.

set routing-instances red routing-options instance-import FROM_GLOBAL

Now the policy has been configured, table red.inet.0 has a default route imported from the master instance. Since I left the IS-IS to OSPF export in place from the previous rib-group exercise, CE2 will also have the default route.

Using the instance-import feature is perhaps a little more intuitive than rib-groups, although both can achieve the same end result.

Logical Tunnel

A final way of doing the leaking is to use Logical Tunnel interfaces. The configuration is very simple – an LT is created with one end of the tunnel in the master inet.0 table, and the other end added to red routing instance. We then simply run a routing protocol or static routing via the tunnel interface.

First of all we create the tunnel interfaces and assign one side to the correct routing instance. This is a vMX so I also need to enable the tunnel services.

From here, it’s a simple matter of running a routing protocol via the tunnel. As my red routing-instance is using OSPF routing with CE2, I configure the LT interfaces in OSPF within the master config and the routing-instance.

Note, because I’m running IS-IS between PE1 and PE2, on PE2 I’m also redistributing IS-IS routes to OSPF and OSPF routes to IS-IS to provide reachability.

Conclusion

I’ve shown three way to leak routes between routing tables on Junos. There are of course many other ways of doing this – static route with next-table, or if I was running MPLS VPNs in this lab I’d also have route-targets to play with, or the auto-export feature for prefix leaking between local VRFs.

If you would like to see a post about these other methods, please say so in the comments. Thanks for reading this post 🙂

Share this:

Following my Juniper vMX getting started guide post, I thought it would be useful to show how vMX could be used to create a lab environment.

This post follows on immediately where the last one finished. I will create a multi-router topology on a vMX instance using Logical Systems, and then go on to configure EVPN on this topology. As with the previous post, this is all running on my Macbook pro on a nested Ubuntu VM.

Lab topology

In this post I will create the following simple topology of 4 MX routers. You will be able to extend the principles shown here to expand your own topology to be as large and complex as you like.

The topology will consist of a 2 x vMX running on the same Ubuntu host.

I will configure EVPN however EVPN is unfortunately not supported within a Logical System, so R2 and R3 will be the main routers on each vMX and will be my EVPN PEs.

R1 and R4 will be created as Logical System routers.

I will connect ge-0/0/1 and ge-0/0/2 on each of vMX back to back using a linux bridge and these interfaces will then be used to provide the interconnection between the main router and Logical System using VLANs. I could use LT interfaces but where is the fun in that.

ge-0/0/3 on vMX1 and vMX2 will be interconnected using a Linux virtio bridge on the host.

vMX2 instance setup

First things first, let’s get the second instance of vMX running. If you remember from my 1st vMX post there is a configuration file for the vMX instance. Running a second vMX instance is no different and has it’s own settings file. I will copy vmx1’s config file and use that as the basis for the vMX2.

The external bridge can be used by both vMX1 and vMX2 so no need to change this setting. This is used to bridge the management interfaces on vMX to the host management interface defined above.

BRIDGES:
- type : external
name : br-ext # Max 10 characters

For the vRE and vPFE I will need to make some changes to console port, management ip address and MAC address. The MAC addresses taken from the locally administered MAC addresses ranges, so no problem to choose my own – taking care not to overlap with vMX1. Also, chose a console port number and management IP address that will not overlap with vMX1.

If I look at the linux bridges the script automatically created you’ll see that another internal bridge is present to enable the RE and PFE communication on vMX2. The external bridge (management bridge) is shared by all vMX management interfaces.

virtio bindings

As I did in my vMX getting started post, for the Ethernet connectivity to the vMX I will be using KVM virtio paravirtualisation.

virtio bindings are flexible and can be used to map multiple vMX instances to a physical host interface, or to connect vMX instances or vMX interfaces together which we will be doing here. Linux bridges are used to stitch everything together.

At this point both vMX1 and vMX2 are running, but I need to create the virtio bindings to enable the communication between each MX.

For both vMX1 and vMX2 this is done in the same configuration file – config/vmx-junosdev.conf

Finally I will create a link between ge-0/0/3 on vMX1 and vMX2. I could use the same technique as shown above, but what if I wanted to connect more than 2 vMX together on the same Ethernet segment? It would be done like this with an additional bridge being defined and shared by each vMX.

EVPN Lab

EVPN is defined in RFC7432. It provides a number of enhancements over VPLS, particularly as MAC address learning now occurs in the control plane and is advertised between PEs using an MP-BGP MAC route. Compared to VPLS which uses data plane flooding to learn MAC addresses, this BGP based approach enables EVPN to limit the flooding of unknown unicast. MAC addresses are now being routed which in multi homed scenarios enables all active links to be utilised. Neat stuff. Also look up the Juniper Day 1 on EVPN.

I’ve already configured a base configuration on R2 and R3. Note I changed the chassis network-services mode to enhanced-ip from the vMX default of enhanced-ethernet.

Now I have reachability between R2 and R3 I can go ahead and add the required base config for EVPN.

Note: EVPN is unfortunately not supported within a Logical System so I am configuring EVPN on the main routers.

From Junos 14.1R4 the chained composite next hop features for EVPN will automatically be configured. Chained composite next hops are required for EVPN and allow the ingress PE to take multiple actions before forwarding.

Logical Systems

My configuration gets a little more complicated here, because I need to create R1 and R4 as Logical Systems on my vMX. I will do this now.

Remember that ge-0/0/1 and ge0/0/2 have been connected back to back by the virtio bridge. I will use ge-0/0/1 as the interface on R2/R3 and ge-0/0/2 as the interfaces on the Logical System routers R1/R4.

Not required for this lab, but if you wanted to create multiple Logical System routers on the same vMX this can of course be done. In the example below I have created two routers R5 and R6, they are linked together via ge-0/0/1 (R5) and ge-0/0/2 (R6) with vlan 56 being used as the VLAN ID for this point to point link. You can of course configure OSPF/BGP/MPLS etc directly between these routers. The configuration is defined in the appropriate logical system stanza.

Summary

In this post I showed how multiple vMX can be configured and interconnected on the same Linux host. I also built a topology of 4 logical routers on the two vMX and used EVPN to demonstrate the capability of vMX.

I’ve also completed a VPLS lab with 5 x Logical System routers running on a single vMX. If you would like to see a post on this type of configuration please mention in the comments or tweet @mattdinham.