Learning by doing: Adding routes to Neutron

This post outlines how to add routes to a Neutron router. The outcome of this post will allow the jumphost to access VMs and networks advertised behind the SRX. Working on my lab environment I have some server infrastructure and jump hosts in the network 192.168.100.0/24. Due to Neutron routing being very plain I could not dynamically peer the SRX with the Neutron gateway.

First time to list my routers in my project

[email protected]:~$ neutron router-list
+--------------------------------------+-----------------+-----------------------------------------------------------------------------+
| id                                   | name            | external_gateway_info                                                       |
+--------------------------------------+-----------------+-----------------------------------------------------------------------------+
| 27d89917-bb77-46c3-95d5-250a259ba304 | public_router   | {"network_id": "083ad060-d6dd-4e49-84e1-c8a2259982ff", "enable_snat": true} |
| 60aefbeb-d2f2-4daf-91b2-6f59391bfee5 | external_router | {"network_id": "083ad060-d6dd-4e49-84e1-c8a2259982ff", "enable_snat": true} |
| a41a761d-9ee1-449d-80be-3ea0f599c4f9 | isolated_router | {"network_id": "083ad060-d6dd-4e49-84e1-c8a2259982ff", "enable_snat": true} |
+--------------------------------------+-----------------+-----------------------------------------------------------------------------+

The router I want to use is the isolated_router. The ID is a41a761d-9ee1-449d-80be-3ea0f599c4f9.

The attached image below shows the rough network environment.

srx-ecmp-nsx

 

The three networks attached to the Distributed Logical Router are unknown beyond the edge of the SRX. WIN-MGT on the 192.168.100.0/24 network has no idea of it. It can only see the interface of the SRX in the 192.168.110.0/24 network. We need to teach the Neutron Router that routes between these two networks about 172.16.200.0/26.

This can be done with updating the neutron router.

[email protected]:~$ neutron router-update a41a761d-9ee1-449d-80be-3ea0f599c4f9 --routes type=dict list=true destination=172.16.83.0/24,nexthop=192.168.110.200 destination=172.16.200.0/28,nexthop=192.168.110.200 destination=172.16.200.16/28,nexthop=192.168.110.200
destination=172.16.200.32/28,nexthop=192.168.110.200 destination=172.16.201.0/24,nexthop=192.168.110.200
Updated router: a41a761d-9ee1-449d-80be-3ea0f599c4f9

The result when we look at the Neutron router again is much better.

[email protected]:~$ neutron router-show a41a761d-9ee1-449d-80be-3ea0f599c4f9
+-----------------------+-----------------------------------------------------------------------------+
| Field                 | Value                                                                       |
+-----------------------+-----------------------------------------------------------------------------+
| admin_state_up        | True                                                                        |
| distributed           | False                                                                       |
| external_gateway_info | {"network_id": "083ad060-d6dd-4e49-84e1-c8a2259982ff", "enable_snat": true} |
| id                    | a41a761d-9ee1-449d-80be-3ea0f599c4f9                                        |
| name                  | isolated_router                                                             |
| routes                | {"destination": "172.16.200.0/28", "nexthop": "192.168.110.200"}            |
|                       | {"destination": "172.16.200.16/28", "nexthop": "192.168.110.200"}            |
|                       | {"destination": "172.16.200.32/28", "nexthop": "192.168.110.200"}            |
|                       | {"destination": "172.16.201.0/24", "nexthop": "192.168.110.200"}            |
|                       | {"destination": "172.16.83.0/24", "nexthop": "192.168.110.200"}             |
| status                | ACTIVE                                                                      |
| tenant_id             | c3485cfe92be4f47852db87ca06b4383                                            |
+-----------------------+-----------------------------------------------------------------------------+

As you can see there is a new field that includes the routes that I have programmed into my Neutron router. I now have connectivity from the 192.168.100.0/24 network into my networks advertised off the DLR. Between the SRX and the DLR is an ECMP fabric.

mgt-lnxjump (0.0.0.0)                   Tue Jul 28 00:32:10 2015
Keys:  Help   Display mode   Restart statistics   Order of fields
   quit                 Packets               Pings
 Host                 Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.100.1      0.0%   173    0.5   0.3   0.2   4.7   0.3
 2. 192.168.110.200    0.0%   173    6.6   8.0   1.2  11.6   2.3
 3. 172.16.83.3        0.0%   173    3.9   4.0   1.1  23.4   2.3
 4. ???
 5. 172.16.200.17      0.0%   172    7.9   8.7   5.9  22.9   2.1

End to end connectivity. We can see at hop three 172.16.83.3 is the E3 currently passing traffic. If this drops or turns off this hop will be updated with 172.16.83.1,2 or 4. ECMP is great!

Gotcha: A gotcha of this is that neutron doesn’t add additional static routes each time you execute the command. It will refresh the list. Ensure you don’t forget any else you may have some connectivity issues!

The alternative is to assign host routes under a DHCP scope. This is pretty easy. A host route is a DHCP option passed to an instance on boot that would allow an allocation of pre-defined static routes. This would do that but in my case my instance had spawned and the other instance accessing this environment was actually not a nova instance and therefore not in scope for an IP from my Neutron DHCP Client.

There you are. Connectivity to my remote network. Openstack is pretty powerful!

Integrating vSRX into VIRL

Cisco VIRL is a learning platform which allows you to run real devices. It is built on an OpenStack architecture that allows rapid deployment of instances of NX-OS, IOSv, IOS-XE ASA and vSRX. I am going to show you the tips on getting it installed into OpenStack.
Thanks to those who want to remain anonymous for the tips, testing and variables.
Here are the steps so that you can inject a configuration file into the vSRX:
 1. Convert ‘thin provision’ image to ‘fat provision image’. This can be done usingthevmware-vdiskmanager as per below:

 /Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -r "junos-vsrx-12.1X46-D10.2-domestic-disk.vmdk" -t 0 “junos-vsrx-12.1X46-D10.2-domestic-disk1.vmdk"
2. The image needs to be modified to accept configuration file injection. This must be done BEFORE loading the image into VIRL via the User World Management (Skinned OpenStack) interface.
You can run the command above on your VIRL VM, so copy the image into the VIRL VM and execute there.
sudo kvm -M pc-1.0 -enable-kvm -daemonize -m 2048 -smp 2,sockets=2,cores=1,threads=1 -hda ./junos-vsrx-12.1X46-D10.2-domestic-disk1.vmdk \
-serial telnet::9101,server,nowait -net nic,model=e1000,vlan=1001,macaddr=00:01:00:ff:88:01 -nographic;telnet localhost 9101
login as ‘root’Edit the file /etc/fstab (nano /etc/fstab). The /etc/fstab should look like this (thevtbd1 disk is theconfig disk)

Device Mountpoint FStype Options Dump Pass#
/dev/md0 / cd9660 ro 0 0
proc /proc procfs rw 0 0
#/dev/bo0s1e /config ufs rw 2 2 
/dev/bo0s1b none swap sw 0 0
/dev/vtbd1s1 /config msdosfs rw 0 0

 

* /dev/bo0s1e /config ufs rw 2 2 is the old configuration disk.

* /dev/vtbd1s1 /config msdosfs rw 0 0 This is the FAT configuration disk.

Save the file.
Now we need to remove the SSH key. Remove the file with:
/etc/ssh/*key - 'rm /etc/ssh/*key
Shut the VM down.
3. The VM image is now ready to be loaded into UWM as a vSRX image.

Using the vSRX image in VIRL

You can add the vSRX image to your VIRL server under the ‘admin/images/’ menu by selecting ‘add’ and choosing ‘VSRX’ from the pick list, as per the picture:

 NOTE – If you want to make the vSRX image your default vSRX image, leave the Name/Version field blank. You can put release version information in the ‘release’ field.
If you create a topology with a vSRX node in it, at simulation start time, the system will look for a default vSRX image. If there is no default image, the simulation will not start and you will need to specifically set the VM_image and VM_flavor field values to the vSRX image that you’ve registered.
Configuration text placed in the ‘configuration’ field for the vSRX, will be automatically loaded into the VM at boot time. A correctly formatted JUNOS configuration will be applied assuming that there are no syntax errors! If you want to provision the VM with a basic set of user accounts, the configuration snippet below can be applied:
system {
  root-authentication {
    encrypted-password "$1$zdCNVrJU$xNlhBZZk8WOn8z3vl6LEs/"; ## SECRET-DATA
                      }
       login {
            user juniper {
                full-name juniper;
                uid 2001;
                class super-user;
                         authentication {
                         encrypted-password "$1$uRcJqW9g$ldwpqqgCZW17bw/tBUeFk/"; ## SECRET-DATA
           }
       }
    }
}
NOTE – if you do NOT pass in any configuration, vSRX will not like you and will crash on you!!! Make sure you pass in a minimal config, like the one below.

Your mileage may vary with this. VIRL is fun because there are lots of things happening behind the scenes.