nsx lab – add/remove static routes

In the last post we added an ESG, but still need to configure routing that allows our vm web-1 172.16.10.10/24 to reach the vyos/physical router 192.168.100.1/24

NSX-Lab-dLR - esg + dLR

 

First up open an ssh session to the vyos and ping the ip of the ESG

vyos@vyos-gateway:~$ ping 192.168.100.4
PING 192.168.100.4 (192.168.100.4) 56(84) bytes of data.
64 bytes from 192.168.100.4: icmp_req=1 ttl=64 time=1.57 ms
64 bytes from 192.168.100.4: icmp_req=2 ttl=64 time=0.665 ms
64 bytes from 192.168.100.4: icmp_req=3 ttl=64 time=0.615 ms

So we know that 192.168.100.0/ section is fine

From web-1 ping the Web-LIF on the dLR, the dLR Transit interface ip, and finally the gateway which is the transit network interface on the ESG

[root@web-1 ~]# ping 172.16.10.254 -c 2
PING 172.16.10.254 (172.16.10.254) 56(84) bytes of data.
64 bytes from 172.16.10.254: icmp_seq=1 ttl=64 time=0.267 ms
64 bytes from 172.16.10.254: icmp_seq=2 ttl=64 time=0.340 ms

[root@web-1 ~]# ping 192.168.10.2 -c 2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=0.304 ms
64 bytes from 192.168.10.2: icmp_seq=2 ttl=64 time=0.343 ms

[root@web-1 ~]# ping -c 2 192.168.10.10
PING 192.168.10.10 (192.168.10.10) 56(84) bytes of data.

--- 192.168.10.10 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

 

So we can see issue is the link from the dLR to the ESG.
As the dLR has the the gateway configured as 192.168.10.10 it shouldn’t need to be told about routing

Open a session on the ESG ( VMware console will do ) and run show ip route

eg-routes-1

 

Now this can be confusing, configuring the route is easy enough but what is the route…?
The next hop is not an ip on this device (ESG) but on an adjacent device

In this case we place a route on ESG that traffic from 172.16.10.0 has as its next hop the dLR transit interface 192.168.10.2.
I suppose this is because traffic going north from the dLR knows to use 192.168.10.10 as a next hop, but on returning, the edge has no idea where to sent 172.16.x.x traffic

NSX-Lab-dLR - New Page 16

Create the route on the ESG*

I have done this for the network 172.16.10.0/24, using a bit of subnet trickery we could add 172.16.0.0/19 and get all the networks in one route

eg-routes-3

Check on the ESG if the route is there

eg-routes-2

And try a ping from web-1 to the ESW , and we should get a response

[root@web-1 ~]# ping 192.168.10.10 -c 2
 PING 192.168.10.10 (192.168.10.10) 56(84) bytes of data.
 64 bytes from 192.168.10.10: icmp_seq=1 ttl=63 time=1.07 ms
 64 bytes from 192.168.10.10: icmp_seq=2 ttl=63 time=1.14 ms

Now ping from web-1 to the north bound ip on the uplink, and we should also get a response

[root@web-1 ~]# ping 192.168.100.4 -c 2
 PING 192.168.100.4 (192.168.100.4) 56(84) bytes of data.
 64 bytes from 192.168.100.4: icmp_seq=1 ttl=63 time=1.17 ms
 64 bytes from 192.168.100.4: icmp_seq=2 ttl=63 time=0.830 ms

And try a ping from web-1  to the vyos router 192.168.100.1, and still no response, but we are a step closer.
The problem is that the vyos router doesn’t know what to do with 172.16.0.0 traffic, so open up a session on vyos and create a static route that sends 172.16.0.0 traffic to the north facing ip on the ESW

vyos@vyos-gateway:~$
vyos@vyos-gateway:~$ configure
[edit]
vyos@vyos-gateway# set protocols static route 172.16.0.0/19 next-hop 192.168.100.4 distance 1
[edit]
vyos@vyos-gateway# commit
[edit]
vyos@vyos-gateway# save
Saving configuration to '/config/config.boot'...
Done
[edit]vyos@vyos-gateway# exit
exit
vyos@vyos-gateway:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

C>* 127.0.0.0/8 is directly connected, lo
S>* 172.16.0.0/19 [1/0] via 192.168.100.4, eth2
C>* 192.168.100.0/24 is directly connected, eth2
C>* 192.168.110.0/24 is directly connected, eth0
C>* 192.168.130.0/24 is directly connected, eth1
vyos@vyos-gateway:~$

now ping from web-1  to the vyos router 192.168.100.1, and bingo, it responds

[root@web-1 ~]# ping 192.168.100.1 -c 2
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=62 time=1.78 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=62 time=1.58 ms

Now we have  got this working, lets remove the route ready for the next post

nsxlab-73

 

Once you have published the changes ping 192.168.100.1, 192.168.100.4 and these will fail as the route is removed
Also 192.168.10.10 is no longer reachable

 

nsx lab – configure dynamic routing protocols – ospf

nsx lab – series

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.