02 August 2018

Day 3.4: DHCP and subnetting

Introduction

In the last entry, I set up a few things:
  • Routing between all the virtual routers on the network.
    • To do this, I enabled RIP on all the core (Core, Edge, and Access) routers for all the networks in the LAN.
  • Configured the Core0 router as the default gateway, and configured RIP to propagate default route information across the network.
  • Configured the Win2016 VM with a direct connection to the Internet, since while GNS3 routes traffic internally quickly enough, it's too slow for Internet connectivity. Win2016 still has access to the virtual LAN as well.

Onwards!

Next step is going to be setting up user access and VLANs (which, by necessity, involves configuring DHCP.)

But VLANs first.

Jumping over to my Access1 router, I set up my two user VLANs, which I designated 101 and 102:

Access1(vlan)#vlan 101
VLAN 101 added:
    Name: VLAN0101
Access1(vlan)#vlan 102
VLAN 102 added:
    Name: VLAN0102

Immediate problem: VLANs are apparently stored in Flash memory as opposed to NVRAM... and Access1 is not configured with any Flash memory.

Shut down switch. Go into configuration in GNS3. Add an 8MiB PCMCIA disk. Restart switch.

format flash:

Okay... now I can create my VLANs and update the database.

Next up: configure an IP address for each VLAN interface to use.

Access1(config)#interface Vlan101
Access1(config-if)#ip address 10.100.1.1 255.255.255.0
Access1(config-if)#no shut
Access1(config-if)#exit
Access1(config)#interface Vlan102
Access1(config-if)#ip address 10.100.2.1 255.255.255.0
Access1(config-if)#no shut
Access1(config-if)#exit
Access1(config)#

Since my VLANs aren't crossing multiple switches, I don't need to work about trunking to other switches. All I need to do is configure the appropriate Ethernet ports for the appropriate VLANs. GNS3 tells me in the Topology Summary which VMs are connected to which ports:


Access1#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Access1(config)#int fa3/0
Access1(config-if)#switchport access vlan 101
Access1(config-if)#ex
Access1(config)#
*Mar  1 00:20:00.015: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan101, changed state to up
Access1(config)#int fa3/1
Access1(config-if)#switchport access vlan 102
Access1(config-if)#^Z
Access1#

And...

Access1#show vlan-switch

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
101  VLAN0101                         active    Fa3/0
102  VLAN0102                         active    Fa3/1

All right, VLANs are set. One more thing first, configure each VLAN interface to use the Windows 2016 DHCP server.

Access1(config)#int Vlan101
Access1(config-if)#ip helper-address 10.1.0.100
Access1(config-if)#ex
Access1(config)#int Vlan102
Access1(config-if)#ip helper-address 10.1.0.100
Access1(config-if)#^Z
Access1#

Now to jump over to Windows and set up the DHCP server.

There's a few different options that needed to be set up:


I created a Superscope specifically to cover user VLANs, and then added a Scope for each VLAN to assign IP addresses within that subnet.

I also set a couple different server-wide options to control what gets assigned to all DHCP clients:


The two Router addresses are for the two interfaces of Core0, the DNS server is the IP address of the Windows 2016 VM.

Time to boot up my Windows 8 VM and see if it gets an IP address successfully.


Probably should've taken care of this first. Oh well.

After the VM came up, I discovered I was getting an address assigned by VMware. As it turns out, you have to start the VMs within GNS3 in order for GNS3 to control them.

But when I tried to do that, I got this message:


After a little digging, I discovered that GNS3 "takes control" of pre-configured VMware virtual networks while it's running. I had only configured it to use a single VMnet, and that was already in use by Win2016. After giving it control of several more VMnets and assigning Windows8 to one of those VMnets, I tried again:


I'll take "error messages I don't understand" for $400, Alex.

Oddly, the VM itself started up with no problem, although it had no network connectivity. I tried one more option: the "Allow GNS3 to override non custom VMware adapter," which I finally discovered had a tooltip informing me that this would allow GNS3 to control the network adapters belonging to the VM.

Still nothing.

After doing some research, I found a forum post suggesting that Windows-based clouds (which I did indeed have) were not as reliable as clouds running inside the GNS3 VM. Following the post's suggestion, I added a network adapter to the GNS3 VM, bridged to my home LAN, and rebooted the GNS3 VM.

GNS3 itself apparently did not like that I was changing its VM while it was running, and complained when I tried to add a new cloud. I opted to just restart GNS3 and try again.

Success... except I was now getting that error message when trying to start up Windows 2016.

At this point I noticed that when I was trying to configure VMnets in GNS3, it was trying to start two services related to Netgroup Packet Filter, that appeared to start and then stop. I figured that all my network interface shifting might have broken something on my local machine, so I decided to reboot.

I started up Win2016, so far so good - then the rest of my virtual routers - then Windows 8. All well and good, except... no IP address.

Oops. Apparently I forgot to save my Access1 configuration before restarting.

After rebuilding the configuration... no DHCP.

Time to enable UDP debugging on Access1 and try a DHCP renew:

Access1#debug ip udp
UDP packet debugging is on
Access1#
*Mar  1 00:07:10.863: UDP: rcvd src=0.0.0.0(68), dst=255.255.255.255(67), length=308
*Mar  1 00:07:10.867: UDP: sent src=10.100.2.1(67), dst=10.1.0.100(67), length=308

UDP packets are making it out, but not coming back. Checking on the next hop, InternalEdge2... no UDP packets are coming through, and yet, I can tracert to the DHCP server just fine.

Turning on IP error debugging on InternalEdge2 reveals:

InternalEdge2#debug ip error
IP packet errors debugging is on
InternalEdge2#
*Mar  1 00:31:01.927: IP: s=10.1.0.100 (FastEthernet2/0), d=10.100.2.1, len 337, dispose ip.noroute

There's the problem. I never added my user subnets to the RIP network listing on Access1, and so the rest of the network has no idea how to reach those subnets. Easy fix, at least:

Access1#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Access1(config)#router rip
Access1(config-router)#network 10.100.0.0
Access1(config-router)#^Z
Access1#

Checking the route listing on InternalEdge2 now shows a route to the 10.100.0.0 networks. DHCP renewed, and...


Got it!

Next step

Not sure, really. I'll figure something out.

1 comment:

  1. It’s great to come across a blog every once in a while that isn’t the same out of date rehashed material. Fantastic read. Best subnetting cheat sheet service provider

    ReplyDelete

I fought FreeRADIUS and FreeRADIUS won

Back to work So...  last I had written, several months ago,  I had managed to add my CentOS server to my domain and was going to work on ...