TACACS+, AAA, SSH and SNMP

AAA, TACACS+ & SSH

One thing that I overlooked due to configuring the devices was user accounts and AAA (Authentication, Authorization and Accounting). AAA is the process which involves authenticating users who wish to access network resources and devices. Authenticated users are then given privileges of which network resources and devices they are allowed to access, through authorization. Finally, when users access these resources a log must be kept in order to identify unauthorized logins, and recording which device by which user during which time of which day these unauthorized logins occurred. In order to begin configuring AAA, the devices also needed to be secured further than your standard plain-text password across telnet (heavily insecure).

In order to initiate AAA on the devices, the command aaa new-model must be entered in global configuration. Afterwards, the aaa authentication command will have to be configured in order to prepare administrative connection methods to be used, such as SSH or console. However, I have opted for a no authentication method on the console command in case of being locked out. In order to configure this, I have created a method list called console_login with the login method none following. 

I have also configured SSH access to the device, primarily due to the fact that sessions between client and server operate in clear text when sending passwords and other commands across TELNET. SSH provides encryption of data traversing the network, so no more sniffed packets with Wireshark. Furthermore, SSH has two versions, where either is better than TELNET in terms of security, but SSH version two offers better protection through encryption ciphers AES or 3DES to protect from packet sniffing, Message Authentication Code (MAC) algorithms for integrity checking, and supports public key certificates.

To configure SSH version two, a domain-name and public key must be configured first using ip domain-name and crypto key generate. I have opted for a key with a modulus of 1024 for better protection. Once the domain-name and keys have been generated, you can enter ip ssh version 2 into global configuration mode and version two will be used on the device. Following this, transport input ssh is entered under the virtual lines configuration (line vty 0 15). Any TELNET connection is blocked, and SSH is allowed. 

Setting the method lists to allow access across a particular line involved entering the command login authentication followed by the named method list. For console, console_login is used whilst the default method list configured for use with SSH. The default method list checks the TACACS+ server for a valid user account before reverting to using the locally configured accounts. 

#BAS1
!
! creates a new AAA model

aaa new-model
!
! configures a domain name on the device
ip domain-name faculty.school
!
! generates a key with the modulus 1024 for SSH
crypto key generate rsa general-keys label SSH-KEY modulus 1024
!
! creates a local user account
username nathan privilege 15 password 0 lewis
username tavita privilege 15 password 0 stewart
!
! configures the SSH version to use (SSH V1.99)

ip ssh version 2
!
! specifies the allowed methods of logging into the device
aaa authentication login default group tacacs+ local

aaa authentication login console_login none
!
! console port configuration
line console 0
 login authentication console_login
 logging synchronous
! virtual line configuration
line vty 0 15
 transport input ssh

 login authentication default

Instead of locally configured accounts, it is must easier to administrate a network when user accounts are configured on a central server, and each device retrieves their login details from a TACACS+ server. An alternative to TACACS+ is RADIUS, however TACACS+ is a superior protocol due to it's accounting and authentication ability. It also provides encryption of traffic between devices. The disadvantage of TACACS+ is the amount of traffic generated from logins and commands entered, however as this only applies when administrators are configuring devices (at this stage), the performance degradation is minimal to it's benefits. I am using Cisco ACS (Access Control Server) to act as a TACACS+ server, and in order for devices to retrieve login information, a TACACS+ client must be configured. The TACACS+ server IP and a secret shared key must be configured before the client can retrieve user logins. In order to do this you must enter tacacs-server host followed by the server IP as well as tacacs-server key followed by the shared key. Now the device will retrieve user logins from the TACACS+ server. I have opted in to supply a source-interface for my TACACS+ requests, using the command ip tacacs source-interface. I have used Loopback1 as the source interface, as the device is a multi-layer switch and a unique interface and IP address is preferred for troubleshooting purposes.

#BAS1
! specifies the tacacs+ server IP and secret key
tacacs-server host 10.0.2.102
tacacs-server key FACULTY
!
ip tacacs source-interface Loopback1

Configuring the TACACS+ server on Cisco Access Control Server (ACS) to send and receive information relating to TACACS+ will be included in a later post.

Simple Network Management Protocol (SNMP)

SNMP is a protocol which provides the administrator with the ability to monitor information of devices throughout the network. This can include interface information or CPU information, or much more. Using SNMP to monitor these aspects of the network can aid in finding issues that inhibit the networks ability to transfer data efficiently. Configuring SNMP on the devices involves choosing a version (1, 2c or 3) and then deciding which information you would like the device to forward to the SNMP manager.

The following will outline how I've configure SNMP to operate on the devices. For the multilayer switches which are operating in layer 3 as part of the backbone, I have configured Loopback interfaces which share an IP address with the Router-ID used for OSPF (see here).

!local interface for SNMP agent.
interface Loopback1
 description SNMP-AGENT
 ip address 1.1.1.1 255.255.255.255

The access-list entry used below provides a method of limiting which IP access can access the SNMP agent for information. In this example, the IP address of my Raspberry Pi which I have configured to act as an SNMP manager is permitted and logged.

access-list 5 permit 10.0.2.34 log

Next is the creation of a user to interact with SNMP on the device. I have opted to use SNMP version 3.

snmp-server user snmpmanager snmp-managers v3 auth md5 management priv des management access 5

And a group has been configured to use privileges such as read-only access.

snmp-server group snmp-managers v3 auth read readonly access 5

Specifying a local interface helps with a direction of where the information comes from. As opposed to letting the device choose where to send the information from, I have opted to send it from Loopback1. If there is a connection issue between devices, making sure the manager can ping Loopback1 on the agent will rule out connectivity issues.

snmp-server trap-source Loopback1

To finalize the configuration that I used, the host which will be the SNMP manager must be specified on the device. The IP address of the Raspberry Pi is entered along with informs and the specified version. With version 3, the auth sub-command becomes available which can be followed by the user in which to authenticate transmissions between the manager and the agent.

snmp-server host 10.0.2.34 informs version 3 auth snmpmanager

snmp-server host 10.0.2.34 version 3 auth snmpmanager

What is missing from this post is the trap information. I have not yet chosen any information to trap, but SNMP is configured so any trap information required by the network management policy can be added and monitored.

Access Control Lists & Zone Based Firewalls

Access Control Lists

In my last blog post, I covered Access Control Lists or ACLs which were being used on two multi-layer switches separating building b to the backbone of the network. I was having issues with limiting return traffic for ICMP requests sourced from the management network, as well as limiting what reponse was given if a computer which was not allowed to ping a remote network. The following ACL was configured on the student VLAN of building b:

#BBS1

ip access-list extended BLK_STUDENTS

 #allow DHCP/BOOTP packets in and out of VLAN interface

 permit udp any eq bootpc any eq bootps

 #allow HSRP packets from BBS2

 permit udp host 10.3.255.253 eq 1985 host 224.0.0.102 eq 1985

 #allow connections from the management network

 permit ip 10.0.3.128 0.0.0.127 any

 #allow echo-reply messages to reach management devices.

 permit icmp 10.3.0.0 0.0.255.255 10.0.3.128 0.0.0.127 echo-reply

 #prevent anything not specifically allowed, blackhole entry

 deny   ip any any

#BBS2

ip access-list extended BLK_STUDENTS

 !allow DHCP/BOOTP packets in and out of VLAN interface

 permit udp any eq bootpc any eq bootps

 !

 !allow HSRP packets from BBS1

 permit udp host 10.3.255.252 eq 1985 host 224.0.0.102 eq 1985

 !

 !allow connections from the management network

 permit ip 10.0.3.128 0.0.0.127 any

 !

 !allow echo-reply messages to reach management devices.

 permit icmp 10.3.0.0 0.0.255.255 any echo-reply

 !

 !prevent anything not specifically allowed, blackhole entry

 deny   ip any any

However, when a host on the students network tried to ping a device outside of its network, it would return the "destination unreachable" message. From a host perspective, this message implies that the destination 'exists' but is not reachable which could lead to malicious users learning about networks that exist further than their LANs. In order to prevent network snooping from users, the command "no ip unreachables" was configured on the VLAN interfaces. Here is a sample configuration of the Students VLAN interface (10):

#BBS1

interface Vlan10

 description STUDENTS-B

 ip address 10.3.255.252 255.255.0.0

 !ip access-group BLK_STUDENTS in

 ip helper-address 10.0.2.22

 no ip unreachables

 standby version 2

 standby 10 ip 10.3.255.254

 standby 10 preempt

#BBS2

interface Vlan10

 description STUDENTS-B

 ip address 10.3.255.253 255.255.0.0

 ip access-group BLK_STUDENTS in

 ip helper-address 10.0.2.22

 no ip unreachables

 standby version 2

 standby 10 ip 10.3.255.254

 standby 10 preempt

A similar configuration was configured on each VLAN interface across Building A and B devices, specifically the multi-layer switches which separated each access network to the network backbone.

Zone Based Policy Firewalls

Instead of configuring ACLs on the routers exiting the network, Zone Based Policy Firewalls or ZBFs were configured on CENR1 and CENR2. The great thing with ZBFs is that you can mark an interface in a certain security zone using the "zone security {zone}" command. I have used two zones, 'Local' and 'ISP' as the routers are using two interfaces each, a FastEthernet 10/100 interface and a Serial interface. The FastEthernet interface is connected to the backbone network via Fa0/24 on CENS1 and CENS2 respectively, whereas the Serial interface is connected to the 'ISP' via S0/0/0 and S0/0/1 on 'ISP' respectively.

#CENR1 #CENR2
zone security Local
zone security ISP

After the zones are configured, zone pairs are configured using the "zone-pair security {name} source {src-zone} destination {dest-zone}" which defines a pairing of zones.

#CENR1 #CENR2
zone-pair security Local->ISP source Local destination ISP

Next comes the creation of class maps. Class maps allows traffic to be marked for use with ZBF. In my case, I have configured an inspection class map using the "class-map type inspect match-any" configuration to inspect any HTTP, HTTPS and DNS traffic.

#CENR1 #CENR2
class-map type inspect match-any basic-web
 ! match traffic using the protocol HTTP (TCP 80)
 match protocol http
 ! match traffic using the protocol HTTPS (TCP 8080)
 match protocol https
 ! match traffic using the protocol DNS (TCP/UDP 53) 
 match protocol dns

Following this, a policy map is created in order to pair actions with inspected traffic. In the case of this network, traffic exiting to the ISP is inspected using the class-map "basic-web" configured earlier. Any other classes that haven't been explicitly configured are dropped.

#CENR1 #CENR2
policy-map type inspect Local_to_ISP
 class type inspect basic-web
  inspect
 class class-default
  drop

Now a service policy must be configured on the zone pairs by using the command "service-policy type inspect" under the zone pair sub configuration.

#CENR1 #CENR2
zone-pair security Local->ISP
 service-policy type inspect Local_to_ISP

And then to finalize, the interfaces are configured as zone members using the interface subcommand "zone-member security".

#CENR1
interface fastethernet0/1
 zone-member security Local
!
interface serial0/0/1
 zone-member security ISP

#CENR2
interface fastethernet0/1
 zone-member security Local
!
interface serial0/0/0
 zone-member security ISP

The final configuration for the zone-based policy firewall is as follows:

#CENR1
hostname CENR1
!
! zone based policy firewall configuration
! configuring security zones
zone security Local
zone security ISP
!
! configuring zone pairs
zone-pair security Local->ISP source Local destination ISP
!
!creating an inspection class map
class-map type inspect match-any basic-web
 ! match traffic using the protocol HTTP (TCP 80)
 match protocol http
 ! match traffic using the protocol HTTPS (TCP 8080)
 match protocol https
 ! match traffic using the protocol DNS (TCP/UDP 53) 
 match protocol dns
!
! creating inspection policy map 
policy-map type inspect Local_to_ISP
 class type inspect basic-web
  inspect
 class class-default
  drop
!
zone-pair security Local->ISP
 service-policy type inspect Local_to_ISP
!
interface fastethernet0/1
 zone-member security Local
!
interface serial0/0/1

 zone-member security ISP

#CENR2
hostname CENR2
!
! zone based policy firewall configuration
! configuring security zones
zone security Local
zone security ISP
!
! configuring zone pairs
zone-pair security Local->ISP source Local destination ISP
!
!creating an inspection class map
class-map type inspect match-any basic-web
 ! match traffic using the protocol HTTP (TCP 80)
 match protocol http
 ! match traffic using the protocol HTTPS (TCP 8080)
 match protocol https
 ! match traffic using the protocol DNS (TCP/UDP 53) 
 match protocol dns
!
! creating inspection policy map 
policy-map type inspect Local_to_ISP
 class type inspect basic-web
  inspect
 class class-default
  drop
!
zone-pair security Local->ISP
 service-policy type inspect Local_to_ISP
!
interface fastethernet0/1
 zone-member security Local
!
interface serial0/0/0
 zone-member security ISP

Project Update: HSRP and Access Control Lists

HSRP
As I thought I had already configured HSRP, I ran into issues when configuring ACLs where the HSRP configuration wasn't finished and needed some attention. I booted up Packet Tracer and configured a topology containing one of the two building networks. From there, I discovered my issues with the HSRP configuration.

First of all, as I had just configured HSRP running on only the Student and Staff networks of a single building, copying the configs and modifying to suit wasn't too bad, however DHCP and the VLANs needed to be altered as Building A only houses access to the Student LAN, Staff LAN, Staff Wireless and Guest Wireless. All that needed doing was adding a base config on top of the already configured VLAN interfaces. As an example of the final configuration for HSRP on Building B Switch 1, for the Students VLAN:

#BBS1
interface vlan 10
 description STUDENTS-B #describing the VLAN network
 ip address 10.3.255.252 255.255.0.0 #allocating a static IP address
 standby version 2 #configuring the HSRP version.
 standby 10 ip 10.3.255.254 #configuring HSRP virtual IP address.
 standby 10 preempt #enabling preemption, see below for more details.
 standby 10 priority 110 #increasing the priority over the alternative link.

 ip helper 10.0.2.22 #DHCP helper address.

I have changed the older configuration to include 'standby 10 preempt' and 'standby 10 priority 110'. The keyword 'preempt' enables preemption which will allow a device to automatically go to ACTIVE state alongside it's peer, which will go to the STANDBY state. Basically, if the priority command was not issued, the first device to boot would become the ACTIVE virtual forwarder. Based on the output above, BBS1 will become the ACTIVE virtual forwarder for HSRP group 10, due to the higher priority. BBS2 will become the STANDBY virtual forwarder for the group.

Access Control Lists (ACLs)

I found a fair bit of issue when thinking about how to go about configuring ACLs. As I don't know what to block and what to allow, it was difficult coming up with a baseline to follow in the future. However, with the help of packet tracer I have managed to configure the ACLs on Building A, and partially on Building B. In order to finalize the configuration, a list of protocols allowed to use the network must be obtained and configured correctly before adding to the ACL.

ip access-list extended BLK_STUDENTS
10 permit udp any eq bootpc any eq bootps #allow DHCP messages
20 permit udp host 10.2.255.253 eq 1985 host 224.0.0.102 eq 1985 #allow HSRP messages.
30 permit ip 10.0.3.0 0.0.0.127 any #allow traffic from management network
        40 permit tcp 10.2.0.0 0.0.255.255 any ack #allow acks from student network.
        50 deny tcp 10.2.0.0 0.0.255.255. any syn #disallow syn from student network.
1000 deny ip any any log #disallow anything not explicitly allowed above.

The above allows the devices to receive DHCP allocated address, and also allow the two multi-layer switches to do HSRP. The management network is allowed into the student network, but student devices are only able to respond to TCP ack messages, not initiate syn messages.

A bit of experimental ICMP protection that I've covered is to prevent devices from snooping the network is to block echo responses that are in response to unreachable peers. The ICMP ACL is as follows:

ip access-list extended BLK_ICMP
remark ICMP-SECURITY #remark to show what the following commands suggest.
970 deny icmp any any net-unreachable #block net-unreachable messages.
980 deny icmp any any port-unreachable #block port-unreachable messages.

990 deny icmp any any host-unreachable #block host-unreachable messages.

It's a work in progress but I hope it will prevent snooping of devices based on the response from pinging other devices in other networks.

Project Update: Gateway to ISP

I have been super busy over the last few weeks finishing off basic connectivity throughout the network, and have been able to send ICMP echos to loopback1 on the ISP router. My original method was a bit too advanced for this particular situation, as it was a point-to-point multi-homed connection configured under the Border Gateway Protocol (BGP) routing protocol. I wasn't able to correctly configure OSPF to offer a summary exit route to the ISP using BGP and in turn, bit the bullet and went with a single default route per ISP-facing interface (two default routes across CENR1 and CENR2). 

The current configuration is as follows:

#CENR1
interface fastethernet0/1
 ip address 10.0.2.26 255.255.255.248
 standby 99 ip 10.0.2.29
 standby 99 version 2
 standby 99 priority 110
 standby 99 preempt

interface Serial0/0/1
 ip address 202.78.120.2 255.255.255.252
 clock rate 128000

ip route 0.0.0.0 0.0.0.0 serial0/0/1

router ospf 1
  redistribute static

#CENR2
interface fastethernet0/1
 ip address 10.0.2.62 255.255.255.248
 standby 99 ip 10.0.2.29
 standby 99 version 2
 standby 99 priority 100
 standby 99 preempt

interface serial0/0/0

 ip address 202.78.120.6 255.255.255.252

ip route 0.0.0.0 0.0.0.0 serial0/0/0

router ospf 1
  redistribute static

#ISP
ip route 202.78.120.2 255.255.255.255 Serial0/0/0
ip route 202.78.120.6 255.255.255.255 Serial0/0/1

interface Loopback1
 ip address 202.78.123.7 255.255.255.255

interface Serial0/0/1
 ip address 202.78.120.5 255.255.255.252
 clock rate 128000

interface Serial0/0/0
 ip address 202.78.120.1 255.255.255.252

Currently the security of the network isn't fully configured, which allows end users on the Student, Staff LAN networks are able to connect to devices throughout the network. The next blog post will cover my work on HSRP and ACLs

Hot Standby Router Protocol (HSRP)

Today I had another chance to get lab time in order to further progress with Tavita and my joint project. Today's agenda was to configure HSRP, which wasn't too hard to configure. The commands I used to configure HSRP were stated in the last blog post, however in order to keep this post covering HSRP, I will relist them below:

##BAS1 (running-config)

interface Vlan10
  ip address 10.2.255.252 255.255.0.0
  ip helper-address 10.0.2.22
  standby version 2
  standby 10 ip 10.2.255.254
!
interface Vlan20
  ip address 10.1.127.252 255.255.128.0
  ip helper-address 10.0.2.22
  standby version 2
  standby 20 ip 10.1.127.254
!
interface Vlan100
  ip address 10.100.127.252 255.255.128.0
  ip helper-address 10.0.2.22
  standby version 2

  standby 100 ip 10.100.127.254

##BAS2 (running-config)

interface Vlan10
  ip address 10.2.255.253 255.255.0.0
  ip helper-address 10.0.2.22
  standby version 2
  standby 10 ip 10.2.255.254
!
interface Vlan20
  ip address 10.1.127.253 255.255.128.0
  ip helper-address 10.0.2.22
  standby version 2
  standby 20 ip 10.1.127.254
!
interface Vlan100
  ip address 10.100.127.253 255.255.128.0
  ip helper-address 10.0.2.22
  standby version 2

  standby 100 ip 10.100.127.254

Both multilayer switch configurations listed above are HSRP group members for three separate HSRP groups. The group numbers refer to the VLAN that the HSRP group is associated with. The last three IP addresses of their respective networks have been used for the HSRP virtual IP address as well as the VLAN interface address. The same configuration above is used on Building B multilayer switches, however alternative IP addressing is used as our DHCP pools have been segregated.

The next step in our project in order to get full connectivity is to configure two routers, connected to the two central multilayer switches in the following configuration:

My current issue with this configuration is finding a solution to allow load balancing with exiting to the "ISP". In our project, ISP would be the main campus network where we would get internet from, however BGP could be configured in order to represent what an ISP configure could be like.

*Note: This configuration may change in order to better represent what we want to do for the final design.

Progress Update: DHCP and HSRP

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

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.