Day 3.3: Setting up routing

Introduction

Yesterday I built a network of virtual routers in GNS3 and connected my VMs to them. Today I'm going to work on configuring them to actually route traffic around the virtual network.

Getting started

As a reminder, here's what the network looks like right now:

To start out, I figured I should configure Core0 to connect to the Internet. Essentially, I started with the instructions here to set my "external" interface on Core0 (Fa0/0) for DHCP:

Core0#

*Mar  1 00:13:24.639: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 172.20.179.154, mask 255.255.0.0, hostname Core0

Core0#

So far so good - Fa0/0 now has an IP address on my home LAN. Equally importantly, it now has a default gateway assigned for routing traffic out to the Internet.

Core0#ping 75.75.75.75

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 75.75.75.75, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Okay, my bad. The default route forwards out to Fa0/0, but there's no default gateway set.

Core0(config)#ip route 0.0.0.0 0.0.0.0 172.20.0.1 permanent

Core0(config)#^Z

Core0#

*Mar  1 00:24:31.687: %SYS-5-CONFIG_I: Configured from console by console

Core0#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is 172.20.0.1 to network 0.0.0.0

C    172.20.0.0/16 is directly connected, FastEthernet0/0

     172.25.0.0/24 is subnetted, 2 subnets

C       172.25.1.0 is directly connected, FastEthernet1/0

C       172.25.2.0 is directly connected, FastEthernet2/0

S*   0.0.0.0/0 [1/0] via 172.20.0.1

               is directly connected, FastEthernet0/0

Core0#ping 75.75.75.75

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 75.75.75.75, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 60/78/96 ms

Core0#

Much better.

Next step is configuring the rest of the routers to learn routes. At this point, for simplicity, I'm going to use RIP.

Fortunately, GNS3 lets me edit each router's startup-config in a text editor so I don't have to manually enter all the config commands on each router to add:

router rip
version 2
network 172.25.0.0
network 172.26.0.0
network 172.27.0.0
network 172.28.0.0
network 172.29.0.0
no auto-summary

Next up, configure Core0 to propagate its static route via RIP:

Core0(config-router)#default-information originate

A quick check of Core2 confirms that the default route has propagated:

Core2#sh ip rip database

0.0.0.0/0    auto-summary

0.0.0.0/0

    [1] via 172.25.2.1, 00:00:01, FastEthernet0/0

Unfortunately, I can't ping 75.75.75.75 from Core2.

Tracerouting shows that packets are making it to Core1 and no further.

Core2#traceroute 75.75.75.75

Type escape sequence to abort.

Tracing the route to 75.75.75.75

  1 172.25.2.1 64 msec 64 msec 60 msec

  2  *

Oops. Apparently GNS3 Clouds don't work the way I had thought - I need to enable NAT so that Core0 can translate packets between my virtual LAN and my home LAN.

After some quick changes (irrelevant lines omitted):

interface FastEthernet0/0

 ip nat outside

interface FastEthernet1/0

 ip nat inside

interface FastEthernet2/0

 ip nat inside

ip nat inside source list 1 interface FastEthernet0/0 overload

!

access-list 1 permit 172.25.0.0 0.0.255.255

access-list 1 permit 172.26.0.0 0.0.255.255

access-list 1 permit 172.27.0.0 0.0.255.255

access-list 1 permit 172.28.0.0 0.0.255.255

access-list 1 permit 172.29.0.0 0.0.255.255

I can now ping the outside world from Core2.

Next up: configure default route propagation between all core routers with default-information originate.

Even after doing this, route information is not making it to Access1.

After some digging, I discovered that neither Core1 or Core2 was sending RIP updates to Access1 because I'd somehow forgotten to activate that interface on both Core1 and Core2.

After fixing this, I tried to ping 75.75.75.75 from Access1 - it worked, but only with a 40-60% success rate. Same with most other Internet sites I tried.

Problematically, this doesn't appear to happen if I try it from my physical machine, and I don't have this problem with pings anywhere in my home LAN. It looks like the latency within GNS3 - while not a problem as long as I'm inside my own network - is too slow for traffic to the Internet.

This isn't really a problem, except that my Windows 2016 server needs to be able to access the Windows Update service, and it can't do that if packets are constantly timing out.

Fortunately, this should be a fairly easy fix - I can add a second network adapter to that VM in VMware, connect it directly to my home LAN (bypassing GNS3) and set that as the default route for all traffic not headed for my virtual LAN.

So at this point, my W2016 VM has two network connections: SIMULCRON (connected to my virtual LAN) and EXTERNAL (connected directly to my home LAN.)

(It was also at this point that I switched ExtEdge2 back to a two-port router, and added a generic switch connecting the Windows 2016 VM to it, for simplicity configuring the router.)

Here's what my routing table ended up looking like:

Oddly, at this point, I can access the Internet and ping ExtEdge2, but I can't reach the rest of the virtual LAN.

(Sidenote: I discovered during this process that GNS3 doesn't handle editing of startup-config via the text editor very well if you do it while the VND is running.)

Not too soon after, I realized I'd never configured ExtEdge2 to advertise its path to Win2016 (which is on the 10.1.0.0/16 network, rather than the rest of the virtual network, which is a 172.* network.) After adding 10.1.0.0 to the RIP database on ExtEdge2, everything worked perfectly - and I confirmed I can ping from Core0 to Win2016, and back!

Next up...

Next step will be setting up user VLANs, like I planned in the original network diagram.

As an aside, while network performance is fine, Win2016 is struggling to paint the screen when I'm doing command-line stuff. I may also start using VPCS simulators to test network connectivity.