HSRP_U Lab Setup
In
part I we covered the preparation needed to get this HSRP lab running. Here we cover in more detail the configuration of the components.
Servers usually, like any other computer, are not concerned with redundant paths to the network. There are though some systems that are designed with redundancy in mind, they are generally called High Availability (HA) systems. The server operating system can determine when one interface or group of them has failed and selects an alternate interface or group of them to communicate with the outside world.
The loss of connection could be caused by the edge switch becoming unavailable. To remedy this loss of a switch we provide a separate switch for the alternate path used by the server. As a minimum we would provide two
access switches going up to the distribution layer. As stated at the beginning access switches provide alternate paths to the distribution layer. This connection from an access switch to a couple of distribution routers forms a “V” shape when drawn. By adding a second switch at the base the drawing forms a “U” this is the reason for the U in the Lab name.
Central to this lab is the First Hop Redundancy concept, that is, provide a redundant default gateway for the
servers. the added value of the lab is the experimentation with failures of the various components, both the switches, their switchportsand the links between devices. We also study the issues we have when we lose the primary management path to the edge switches.
The Server is simulated by QEMU. This is a virtual machine emulator, similar to VMWare. Being an Open Source project, the GNS3 developers have tailored a version of QEMU for the specific requirements of GNS3. While QEMU can be a platform for the emulation of ASAs, Juniper Routers or IDS devices, we use it here to emulate a computer running Linux. We run a strip down version called MicroCore. This version of MicroCore has been tailored to for the requirements of GNS3 labs.
Of particular interest to us is the possibility of bonding two (or more) network interfaces under one IP address. There are two basic modalities for this operation, Load Balancing (similar to Cisco layer 3 port channeling) and Active/Standby bonding. The latter is what we use in this lab. In our case the Server has an IP address of
10.24.13.1 and two interfaces, eth0 and eth1. Initially eth0 is the active interface and it connects to the network. If ARPed eth0 MAC address is sent.
The project folder has two subfolders where configuration information is stored. The “configs” subfolder has the Cisco devices configuration files and the “working” subfolder cntains the QEMU/MicroCore files.
Cisco Configuration Files
The five Cisco devices have very simple configuration lines. All devices share some lines shown below:
host <name>
no ip domain-lookup
line 0
logg s
no exec-t
privi l 15
In addition the devices have the participating interfaces defined, the routers have the OSPF routing process defined and the switches have their VLANs and SVIs defined. The Core router defines the default route and injects it to the other routers via OSPF. The Distribution routers have HSRP implemented. The switches track connectivity to the Distribution routers to determine their proper default route.
Core Router
int l0
ip addr 10.24.50.1 255.255.255.255
!
int f0/0
ip addr 10.24.0.254 255.255.255.252
no shut
!
int f0/1
ip addr 10.24.0.250 255.255.255.252
ip ospf cost 3
no shut
int f1/0
ip addr 192.168.137.254 255.255.255.0
no shut
!
router ospf 1
net 10.24.0.0 0.0.255.255 area 0
net 192.168.137.0 0.0.0.255 area 0
passive f1/0
default-information originate
!
ip route 0.0.0.0 0.0.0.0 192.168.137.1
Notice that interface f0/1 that connects to Distr_SEC sets OSPF cost to 3. Regularly a fast Ethernet cost would be 1. This would create a load balancing path to the server. Our design calls for using the primary path for all traffic. The secondary path normally has other functions not considered in this simulation.
Also notice the default route definition and the default-information originate command in the router section. This is how this router creates and injects the default gateway to the outside world. Making the interface connected to the outside passive, no OSPF adjacencies are attempted in that direction.
OSPF is used but any routing protocol would do even statically defined routes. The only requirement is that the path through the primary Distribution router be preferred and that path through the secondary router be taken when the primary is unavailable.
Primary Distribution Router
int l0
ip addr 10.24.50.2 255.255.255.255
!
int f0/0
no shut
exit
!
int f0/0.4
ip addr 10.24.1.254 255.255.255.0
encap dot1q 4
int f0/0.17
ip addr 10.24.13.252 255.255.255.0
encap dot1q 17
standby 1 ip 10.24.13.254
standby 1 timers 2 6
standby 1 priority 120
standby 1 preempt
!
int f0/1
ip addr 10.24.0.253 255.255.255.252
no shut
!
router ospf 1
net 10.24.0.0 0.0.255.255 area 0
In a real-life scenario we would use Cisco Catalyst multilayer switches and use VLAN interfaces. For this small simulation I am using routers with sub-interface encapsulation, very much as one would do in a multi-vlan, router-on-a-stick situation.
We have two interfaces defined, f0/1, the uplink to the Core, and f/0/0 in the LAN where we have the server. This being a small simulation we have this only interface downward. In a real life network the router would be part of many other networks. As said above, a Catalyst is the device of choice.
The primary Distribution router is defined as the primary path from layer 2/3 transitioning. The important VLAN is the production VLAN which services the server. In sub-interface f0/0.17 the router act as the default gateway for the server. Notice the standby set of commands. We define an HSRP standby group, 1 in this case, and by defining a higher than default priority we make it the primary path, where the secondary router stays with the default priority.
The standby group reacts to a virtual IP, 10.24.13.254, when ARPed. The MAC address given is 0000.0c07.ac**, where ** is the HSRP standby group, 0x01 in our case. This IP address is separate from either of the IP addresses assigned to the Distribution routers in this network segment.
Secondary Distribution Router
int l0
ip addr 10.24.50.3 255.255.255.255
!
int f0/0
no shut
!
int f0/0.5
ip addr 10.24.2.254 255.255.255.0
encap dot1q 5
int f0/0.17
ip addr 10.24.13.253 255.255.255.0
encap dot1q 17
standby 1 ip 10.24.13.254
standby 1 timers 2 6
standby 1 priority 100
standby 1 preempt
!
int f0/1
ip addr 10.24.0.249 255.255.255.252
ip ospf cost 3
no shut
!
router ospf 1
net 10.24.0.0 0.0.255.255 area 0
The secondary router has a similar configuration with just a lower priority in the standby group, the default value of 100. It also increases the OSPF cost to avoid a secondary path to network 10.24.0.252/30.
All three routers have a Loopback interface. While this is not strictly needed for the simulation, later in the lab we will use them for other purposes.
Edge Switch 1
vtp mode transparent
!
vlan 4
vlan 5
vlan 17
!
int f1/0
sw mode access
sw access vlan 17
!
int f1/12
sw mode trunk
!
int f1/14
sw mode trunk
!
int vlan4
ip addr 10.24.1.25 255.255.255.0
!
int vlan5
ip addr 10.24.2.25 255.255.255.0
Interface f1/0 services the server with VLAN 17. VLANs 4 and 5 are the management VLANs through the primary and the secondary paths. Interface f1/12 is the uplink and interface f1/14 is the connection to switch 2.
Edge Switch 2
vtp mode transparent
!
vlan 4
vlan 5
vlan 17
!
int f1/0
sw mode access
sw access vlan 17
!
int f1/12
sw mode trunk
!
int f1/14
sw mode trunk
!
int vlan4
ip addr 10.24.1.26 255.255.255.0
!
int vlan5
ip addr 10.24.2.26 255.255.255.0
Except for the IP addresses assigned to VLAN interfaces the configuration is equivalent to that of switch 1.
Other Configuration Files
We turn our attention to the configuration of other components, particularly, those related to the server being simulated.
QEMU Configuration
[qemu 127.0.0.1:10525]
workingdir = working
udp = 20000
[[QemuDevice]]
image = T:\DynamipsLabs\images\Qemu\linux-microcore-3.4.img
ram = 64
netcard = e1000
options = -no-acpi -vga none -vnc none
[[QEMU Server]]
e0 = Edge_Switch1 f1/0
e1 = Edge_Switch2 f1/0
symbol = server
Above we show the parameters as defined inside the GNS3 topology configuration file. In the QemuDevice section I define parameters that may be different from those defined in GNS3 preferences. For example in the options parameter I remove the QEMU console with –vga none and –vnc none. I rather use the serial connection that the MicroCore image offers through PuTTY.
Server [MicroCore]
/bin/hostname Server
/usr/local/bin/slocate –u
#
/sbin/modprobe bonding
/bin/echo active-backup > /sys/class/net/bond0/bonding/mode
/sbin/ifconfig bond0 10.24.13.1 netmask 255.255.255.0 up
/bin/echo +10.24.13.254 > /sys/class/net/bond0/bonding/arp_ip_target
/bin/echo 2000 > /sys/class/net/bond0/bonding/arp_interval
/sbin/ifconfig eth0 down
/bin/echo +eth0 > /sys/class/net/bond0/bonding/slaves
/sbin/ifconfig eth1 down
/bin/echo +eth1 > /sys/class/net/bond0/bonding/slaves
#
/sbin/route add -net 0.0.0.0 gw 10.24.13.254
/bin/echo nameserver 192.168.137.1 >> /etc/resolv.conf
The code lines above are the ones I added to the /opt/bootlocal file. The first line changes the host name from tc to Server. The second line creates the database for slocate (Secure Locate) an application I added to help me locate any file inside Linux. This application does not add to the simulation, it is there for convenience.
The last line adds a line to /etc/resolv.conf. I setup my laptop as the DNS server. The next to last line defines my default gateway as the virtual IP address of the HSRP standby group in the Distribution routers.
The rest of the lines set the bonding of the two physical interfaces up, eth0 and eth1, to a virtual interface, bond0, which handles layer 3. You may find the gory details of how to do this
here. I just want to clarify that there are several methods to implement this bonding and I chose the sysfs method. I selected the ARP method of monitoring instead of the Media Independent Interface (MII) monitoring. The default gateway is ARPed every 2000 milliseconds.
Go
here for the configuration files. Part III covers the actual running of the simulation.
