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
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
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
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
Check on the ESG if the route is there
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  vyos@vyos-gateway# set protocols static route 172.16.0.0/19 next-hop 192.168.100.4 distance 1  vyos@vyos-gateway# commit  vyos@vyos-gateway# save Saving configuration to '/config/config.boot'... Done 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
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