Progress Update: DHCP and HSRP

Saturday, July 26, 2014

Today I managed some lab time where I was able to sit down with Tavita to try and sort out DHCP with the topology. We had connected all switches and DHCP server, and configured them as per the config files we had stored and worked on getting DHCP addressing to host PCs on each layer 2 segment. At first we were unsure why the hosts were not receiving addresses, but it became clear once we started to use 'debug ip udp' and 'debug ip dhcp server packet' commands as to why it was not allocating addresses. 

Dynamic Host Configuration Protocol (DHCP)

Basically, our topology did not give a method of returning the addresses to the network the DHCP request originated from. An easy fix for this issue was to apply the 'redistribute connected subnets' command to the 'router ospf 1' instances on BAS1 and BBS1. Currently, we have not set up HSRP, but I have already created a command list to enter on each router in order to create an instance of Hot Standby Router Protocol for each VLAN.

In order to get our DHCP working with host computers, the connected networks had to be redistributed into OSPF. The alternative would be to select the specific networks we are using 'network XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY area Z' statements, but it was easier to add the 'redistribute connected subnets' to each border multilayer switch. The configuration for the OSPF protocol is now as follows

##BAS1
router ospf 1
  log-adjacency-changes
  redistribute connected subnets
  passive-interface port-channel 4
  passive-interface port-channel 5
  network 10.0.2.0 0.0.0.63 area 1

##BAS2
router ospf 1
  log-adjacency-changes
  redistribute connected subnets
  passive-interface port-channel 4
  passive-interface port-channel 5

  network 10.0.2.0 0.0.0.63 area 1


The above configuration is exactly the same as BBS1/BBS2, however the port-channel group numbers are different. At this time, I am unsure of whether the redistribution of connected subnets will be affected once HSRP is active, however further testing will show whether problems will arise.

An issue we did run into when configuring the DHCP, is the ability for DHCP clients to send ICMP packets (or pings) to the DHCP server once they had received addresses. This issue is due to the way routing was performed, and the fact that we were splitting a single DHCP pool between two local area networks. The routing tables suggested that the first place to send packets from the 10.2.0.0 network was BBS1, as it was the first configured destination for the 10.2.0.0 network. What ended up happening was a test DHCP client on the Building B network was able to freely ping the DHCP server, however when you tried to ping the DHCP server from a Building A client, it would respond with "destination unreachable". In order to remedy this issue, we are creating two pools to suit each group of host computers. Each pool will allocate addresses to a single site only, as the routing protocol shouldn't have issues when sending ICMP packets. An updated DHCP pool configuration is as follows:


ip dhcp pool STUDENTS-A

  network 10.2.0.0 255.255.0.0
  default-router 10.2.255.254
  domain-name STUDENTS
!
ip dhcp pool STUDENTS-B
  network 10.3.0.0 255.255.0.0
  default-router 10.3.255.254
  domain-name STUDENTS
!
ip dhcp pool STAFF-A
  network 10.1.0.0 255.255.128.0
  default-router 10.1.127.254
  domain-name STAFF
!
ip dhcp pool STAFF-B
  network 10.1.128.0 255.255.128.0
  default-router 10.1.255.254
  domain-name STAFF
!
ip dhcp pool REGISTRY
  network 10.0.0.0 255.255.255.128
  default-router 10.0.0.126
  domain-name REGISTRY
!
ip dhcp pool PAYROLL
  network 10.0.0.128 255.255.255.128
  default-router 10.0.0.253 10.0.0.254
  domain-name PAYROLL
!
ip dhcp pool GUEST-A
  network 10.100.0.0 255.255.128.0
  default-router 10.100.127.254
  domain-name GUEST
!
ip dhcp pool GUEST-B
  network 10.100.128.0 255.255.128.0
  default-router 10.100.255.254
  domain-name GUEST

Hot Standby Router Protocol (HSRP)

HSRP allows us to have redundant default-gateways for our host computers to use to exit their local area network. If say the switch BAS1 were to come down due to an error, host computers will still have the ability to exit the network as the gateway will still be active, instead choosing the secondary backup gateway, BAS2. The same effect will be seen on BBS1/BBS2.

The following command list is what I'll be using to configure HSRP on the VLANs that require a redundant default-gateway for VLAN 10 (STUDENT), 20 (STAFF) and 100 (GUEST)


interface vlan 10 ##STUDENT

  ip address 10.2.255.252 255.255.0.0
  standby version 2
  standby 10 ip 10.2.255.254
  ip helper 10.0.2.22
!
interface vlan 20 ##STAFF
  ip address 10.1.127.252 255.255.128.0
  standby version 2
  standby 20 ip 10.1.127.254
  ip helper 10.0.2.22
!
interface vlan 100 ##GUEST
  ip address 10.100.127.252 255.255.128.0
  standby version 2
  standby 100 ip 10.100.127.254
  ip helper 10.0.2.22

The 'standby version X' command determines the version of HSRP to be used on that instance. I am using version two of HSRP because:

  • It learns and advertises millisecond timer values, which helps stability of the hsrp group. 
  • It's group number range is larger than in version one, allowing up to 4095 groups instead of 255. 
  • HSRP packets have changed to include a 6-byte identifier field which has management benefits such as allowing an administrator to identify the sender of the packet. 
  • The IP multicast address has changed from 224.0.0.2 in version one to 224.0.0.102 in version two. Version one's multicast address conflicted with CGMP (Cisco Group Management Protocol), which the change now allows CGMP and HSRP to operate without issue. 
'standby XX ip YYY.YYY.YYY.YYY' is the command to set the HSRP group-number and virtual IP address for the default-gateway. In this topology, the HSRP group-number will match the VLAN used by that instance of HSRP, where the virtual IP address (or default gateway address) will be the final address in the DHCP pool. The last 10 addresses of each DHCP pool will be allocated to gateways address, and will allow for a moderate amount of expansion.

Progress Update: VTP, Native VLANs, OSPF and DHCP

Friday, July 25, 2014

Over the last week, major changes have gone on with the project topology. I was able to finalize the VLAN and VTP configuration of the layer 2 LANs. This consisted of finalizing the VTP server selection, writing commands in preparation of configuring the devices as well as researching further into VTP across two separated LANs. I discussed VTP across two separated sites with my supervisor who informed me that it isn't industry practice to do this and the preferred approach would be to run separate VTP instances for each layer 2 segment.  This was a much easier problem to solve as it included configuring two VTP servers to suit each site as opposed to introducing VPN and L2TP tunnels.

VLAN Trunking Protocol (VTP)

Our project covers designing a new topology to cover a new faculty being implemented in a campus environment. So the VTP servers were configured to run within the domain "FACULTY". The commands listed below show how I configured the VLANs and VTP server for each site, and following that are the commands configured on the 'client' switches.

#CONFIGURING THE VTP SERVER

hostname BAS1
!
vlan 10
 name STUDENTS
!
vlan 20
 name STAFF
!
vlan 30
 name REGISTRY
!
vlan 35
 name PAYROLL
!
vlan 40
 name MANAGEMENT
!
vlan 50
 name GUESTWRLS
!
vlan 100
 name STAFFWRLS
!
vtp mode server

vtp domain FACULTY
vtp version 2
vtp password FACULTY
end

#CONFIGURING A VTP CLIENT

hostname BA1S 
!
vtp mode client
vtp domain FACULTY
vtp password FACULTY

Upon reloading the VTP clients, they will come back up with the VLANs from the VTP server filling it's own VLAN database. Any changes made to the server will be propagated to the clients, with the clients sharing the same database revision as the server.

To further the configuration of the layer 2 segment, the native VLANs used by the layer 2 etherchannel interfaces were changed from the default VLAN 1 to VLAN 40 which was named "MANAGEMENT". Separating the VLAN traffic from the default VLAN allows security for traffic traversing the LAN, where attackers would consider sniffing VLAN 1 without knowing which VLAN currently distributes trunking data. To configure an alternative native VLAN, it is best practice to shut down the ports/interfaces before configuring.

#CONFIGURING A NATIVE VLAN

hostname BA1S
!
interface port-channel1
 switchport trunk native vlan 40 #configuring native vlan as MANAGEMENT VLAN

OPEN SHORTEST PATH FIRST (OSPF)

A routing protocol is something that we haven't looked over for a few months as configuring the layer 2 LANs were paramount and routing across the backbone was as simple as adding three commands under the global configuration and it totally slipped my mind until today. The configuration has changed since this post and is currently configured as the following:

hostname CENS1
!
ip routing
!
router ospf 1
 network 10.0.2.0 0.0.0.63 area 1

Dynamic Host Configuration Protocol (DHCP)

In order to finalize the host computers connectivity with the rest of the network and allocate addressing without too much trouble, DHCP must be configured in order to dynamically allocate IP addresses from a pool amongst clients who request the addresses. At this time, we've only been able to configure a test server with a Cisco 2800 series router configured with a static route and plugged into CENS1's interface FastEthernet0/24. In order to continue with allocating the address amongst host computers on either sites, an IP helper address must be configured on the exit switches. Unfortunately Tavita and I haven't managed to get it working yet, but that is on the cards for tomorrow. So far our configuration for the DHCP server is as follows:

hostname DHCP-SERVER
!
ip dhcp pool STUDENTS
 network 10.2.0.0 255.254.0.0
 default-router 10.3.255.253 10.3.255.254
 domain-name STUDENTS
ip dhcp pool STAFF
 network 10.1.0.0 255.255.0.0
 default-router 10.1.255.253 10.1.255.254
 domain-name STAFF
ip dhcp pool REGISTRY
 network 10.0.0.0 255.255.255.128
 default-router 10.0.0.125 10.0.0.126
 domain-name REGISTRY
ip dhcp pool PAYROLL
 network 10.0.0.128 255.255.255.128
 default-router 10.0.0.253 10.0.0.254
 domain-name PAYROLL
ip dhcp pool GUEST
 network 10.100.0.0 255.255.0.0
 default-router 10.100.255.253 10.100.255.254
 domain-name GUEST
!
ip dhcp excluded-address 10.3.255.253 10.3.255.254
ip dhcp excluded-address 10.1.255.253 10.1.255.254
ip dhcp excluded-address 10.0.0.125 10.0.0.126
ip dhcp excluded-address 10.0.0.253 10.0.0.254
ip dhcp excluded-address 10.100.255.253 10.100.255.254
!
service dhcp

That's all for now. I will continue on regarding DHCP in a later post as currently, the above configuration isn't implemented or tested. However I will be testing it in the lab tomorrow and will confirm whether it's working.







Software, Monitoring and the Raspberry Pi

Tuesday, July 22, 2014

I've been quite slack when it comes to organising anything with the Raspberry Pi. It is difficult to configure the RPi when you're not entirely sure of what portions of the network you're meant to monitor, or which programs will do exactly what are required of the RPi. Fortunately, there are other RPi users who have use their devices for network monitoring, giving some insight as to what to monitor and what software to use.

Bridging Layer 2 sites across a Layer 3 backbone

Monday, July 21, 2014

The plan of the network shows a layer 3 backbone being used to bridge the two buildings, which comprise of layer 2 networks running 802.1q VLANs. My idea of the network was to bridge the VLANs in Building A with the VLANs in Building B so as to have seamless internetworking between users of the same group (Students, Academic Staff, Registry, etc.)

Unfortunately, due to the equipment I have available to use in the networking lab rooms, I am struggling to find possible solutions to this issue. I have considered several tunneling protocols including Layer 2 Tunnelling Protocol, GRE tunnels and VPN tunnels (configured as as a trunk.) However, as I am using Cisco Catalyst 3560 Multilayer Switches running IOS 12.2(50) to make up the Layer 3 backbone, does not support the command "xconnect" under any VLAN or FastEthernet interfaces and therefore will not allow L2TP tunneling. 

GRE tunneling is another tunneling protocol that is available for use on Cisco ISR (Integrated Services Router), and is not recommended to end on Cisco Catalyst switches due to poor performance and network stability issues. 

VPN tunnelling are an option due to being available on the Catalyst 3560 switches, however my issue with this is the added overhead to bridge the two buildings. As the backbone is entirely within the campus network, the overhead of a VPN connection between two almost distance-negligible devices may be too great. I have yet to test this on the real gear.

A few extra sources of information on tunnels available on Cisco equipment: