Lab 12 – Hot Standby Router Protocol
"Because two routers is better than one ."

This layout can be achieved using a single four router pod and its central switch. Two of the routers will act as the HSRP gateways, and the other two will act as the client and the server. This should make a good test of your design skills...take a piece of paper and make a brief sketch of how you would lay out this design. It won't be graded, but if you can visualize your goal you're already have way done with the task at hand!

Now, on to the actual work. As always, start off by erasing the previous configurations on your four routers and the central switch. Remember, the switches are connected to a larger switching fabric, so before you start make sure the external ports are shut down. Once your hardware has been reloaded, add the standard line configurations (timeout, secret, etc).

Now I'll give my answer to the design question that was asked earlier. The solution is to use VLANs on the central switch. The VLANs allow you to create a linear path through the switch, instead of using the entire switch as a shared medium. For the purpose of this exercise, Router 1 will be the client, Routers 2 and 3 will be the HSRP gateways, and router 4 will be the server. The trick is to add the two ethernet connections on R2 and R3 to separate VLANs...one for the client, and one for the server, and have R2 and R3 route between them. In this way, we're creating a linear path through the switch. Click Here to see a picture.

Connect to your switch, and create two VLANs, 20 and 30. The client will belong to VLAN 20. Add ports 0/1 (R1), 0/2 (R2), and 0/4 (R3) to this VLAN. Add ports 0/3 (R2), 0/5 (R3), and 0/6 (R4) to VLAN 30. Switch configuration is complete.

Configure R1 as your client. We're pretending it's a PC, so turn off routing with no ip routing. Add the default gateway address as 192.168.0.253 with ip default-gateway 192.168.0.253. Finally, bring up the ethernet interface with an IP address of 192.168.0.1/24.

Configure R2, R3, and R4 as follows:

HSRP is now enabled. Use the show standby command to verify HSRP is operating. One router should be active while the other is on standby. Each router should also list the other router as the neighbor. What is the default priority value?





To verify HSRP operation, connect to the client (R1) and ping the IP address of the server. If unsuccessful, check your EIGRP configuration, and check the interface status of all the individual connections. Once successful, do a traceroute to the server. Notice that the traceroute lists the actual IP address of the active router, not the virtual IP address.



Now, connect to the active router, and shut the client side interface. You should see terminal output stating that HSRP is changing states, and the standby router has become active. Use show standby to verify this has occurred.





Finally, do another traceroute from client to server. What gateway IP address is listed now? Bring the downed interface back up.



HSRP uses a default priority of 100 for all routers. As you may have guessed, HSRP priority is configurable to allow network engineers to select which router is active under normal conditions. In HSRP, the router with the highest priority number is the one that becomes active. Priority is configured with the standby [group number] priority [value] command. Change the default priorities on your routers so that the default active router becomes the passive router.

P3R3(config)#int Fa0/0
P3R3(config-if)#standby 1 priority 150

Verify the change with show standby.





This is all well and good if our routers lose their connection to the client network, but what happens if the egress interface goes down instead? If we were to shut Fa0/1 on our active router, it could clearly pose a problem for the network, since HSRP is only tracking Fa0/0. This is fixed by implementing the track command: standby [group number] track [interface] [priority]. This command tells HSRP to keep track of an additional interface. If the connection on the tracked interface is lost, HSRP lowers its own priority by the amount given. Apply this to your active router:

P3R3(config)#int Fa0/0
P3R3(config-if)#standby 1 track Fa0/1 51

Now HSRP on the active router is also tracking Fa0/1 for problems. If Fa0/1 goes down, R3 will automatically lower its own priority by 51 points. Since we configured R3 with priority 150, and R2 is using priority 100, dropping 51 points would give R2 the highest priority. Test your configuration by shutting down Fa0/1 on the active router. The track command should drop the priority, and the standby will become active. Shut down the tracked egress interface and verify that the standby router takes over.

Note: The if the track command is used without a priority value, it drops 10 points by default.

[Sample Configs]

This section builds upon the switch configurations used in the previous section, so it is not necessary to reset your equipment.

As we saw in Part 1, HSRP makes it very simple to provide redundant gateways for a network. Unfortunately, you may have noticed something very unfortunate from an efficiency standpoint about our previous design. Regardless of how many redundant routers you have running HSRP, you never use more than one gateway at a time. This is very inefficient in large networks, and is a waste of hardware during normal system operation. There is one very simple mechanism to avoid this: create multiple groups. This practice is logically similar to the way STP can be used to load balance switch uplinks. We create multiple groups, and make a different router active for each group using priorities. You then distribute the different virtual gateway IPs evenly among clients, so half of the clients use one group and the other half use the other group. Of course this is not the most ideal method of load balancing, since one group may produce heavy amounts of traffic and another group may not, but it's better than single group HSRP. If you understood the last section, you should be able to implement this part on your own since there's really no new commands... but don't skip over it because it's always good practice!

Routers 1 and 4 use the same configuration as Part 1. We can use the same configs as we used for Router 2 and 3 at the end of Part 1 as well, but be sure to bring all your interfaces back up. Start by adding a second group to Fa0/0 on both routers. Give group 2 the virtual IP address 192.168.0.124/24. Do this on routers two and three:

P3R2(config)#int Fa0/0
P3R2(config-if)#standby 2 ip 192.168.0.124
P3R2(config-if)#standby 2 preempt

P3R3(config)#int Fa0/0
P3R3(config-if)#standby 2 ip 192.168.0.124
P3R3(config-if)#standby 2 preempt

For simplicity in planning, set both your group 1 priorities back to the default value of 100. Now all interfaces in both groups should be of equal priority:

P2R3(config)#int Fa0/0
P2R3(config-if)#standby 1 priority 100

P3R3(config)#int Fa0/0
P3R3(config-if)#standby 1 priority 100

Now for the balancing stage. Remember, the goal is to have different routers active for each group. Drop one router in each group down to priority 95.

P2R3(config)#int Fa0/0
P2R3(config-if)#standby 1 priority 95

P3R3(config)#int Fa0/0
P3R3(config-if)#standby 2 priority 95

Now one router should be active for each group. Use show standby to verify this is the case.





Finally, set up both routers to track their egress interfaces:

P2R3(config)#int Fa0/0
P2R3(config-if)#standby 1 track Fa0/1
P2R3(config-if)#standby 2 track Fa0/1

P3R3(config)#int Fa0/0
P3R3(config-if)#standby 1 track Fa0/1
P3R3(config-if)#standby 2 track Fa0/1

Notice that since we used low priorities of 95, the default track priority drop of 10 will suffice in the event of failure on the egress port.

That's all there is to configuration. Now test it using your client. Currently the client should be configured with the virtual gateway of group 1. Traceroute to the server to see which router it uses. Now change the default-gateway on the client to the virtual ip of group 2 and traceroute again. Which router does it use this time?



[Sample Configs]


Part 3: HSRP w/ Multihomed BGP
[http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080093f2c.shtml]

This section requires a different configuration than the previous sections, so start by resetting your equipment. You will need two pods that can communicate over the switching fabric, as well as access to Backbone 1 to complete this section. Be sure to log out of the backbone when you're not using it so others can have access!

Now that you're familiar with the concept of HSRP and its basic functions, we'll apply it to a new scenario that you might encounter in a real world environment. Consider a LAN environment which is connected to the internet via two different ISPs. ISP A is the primary route, as long as it remains up, ISP B should not be used. Should ISP A go down, you will configure HSRP to automatically switch outgoing traffic to ISP B. This takes care of all traffic leaving the LAN, but what about inbound traffic? For that, we'll use BGP configured on the ISP routers. BGP will allow us to route traffic in through ISP A as long as the connection remains up, but will switch to ISP B should the connection to ISP A be lost.

The simulation as a whole will require six routers:

The IP addresses used in the table match those in the original diagram (except for the LAN). You should be able to visualize how the diagram fits over our pod configuration. If you cannot, try drawing it. Don't continue the lab until you understand how the setup fits the picture!

The LAN client should be configured as a client, not a router. Turn off ip routing and give it the default gateway of your HSRP gateway address. Obviously, the interfaces used on the backbone will vary depending on which pods you use. Just make sure to match up the subnet numbers. Finally, make sure your LAN machines can see each other over the switching fabric. If they can't, you may need to reset your switches.

The first step in achieving our objectives is to enable HSRP for the LAN. This is your third time working with HSRP so I won't walk through it all again. If you get stuck, scroll up to the previous sections as it's all covered in detail there. Create a single HSRP group with gateway address 192.168.0.254 on both R3 routers . Give the HSRP router connected to ISP A higher priority, and set it to track its ISP interface (S1/0).

That's all there is to the HSRP configuration for outgoing traffic. Now we have to add BGP to the routers. This serves as the routing protocol, and will allow incoming traffic to select the ISP we choose based on availability.

Add your LAN routers to BGP AS 100. Use the network commands to identify the subnets to which the routers belong. The neighbor command identifies connected routers and their AS. Specify next-hop-self for the internal neighbors. Finally, add no synchronization to allow BGP to work as an iBGP without a full mesh.

P6R3(config)#router bgp 100
P6R3(config-router)#network 192.168.0.0 mask 255.255.255.0
P6R3(config-router)#neighbor 192.168.0.251 remote-as 100
P6R3(config-router)#neighbor 192.168.0.251 next-hop-self
P6R3(config-router)#neighbor 192.168.31.3 remote-as 300
P6R3(config-router)#no synchronization

P5R3(config)#router bgp 100
P5R3(config-router)#network 192.168.0.0 mask 255.255.255.0
P5R3(config-router)#neighbor 192.168.0.250 remote-as 100
P5R3(config-router)#neighbor 192.168.0.250 next-hop-self
P5R3(config-router)#neighbor 192.168.42.4 remote-as 400
P5R3(config-router)#no synchronization

Add your ISP A router to BGP AS 300, and your ISP B router to AS 400:

P6R1(config)#router bgp 300
P6R1(config-router)#neighbor 192.168.31.1 remote-as 100
P6R1(config-router)#neighbor 192.168.63.4 remote-as 600

P5R1(config)#router bgp 400
P5R1(config-router)#neighbor 192.168.42.2 remote-as 100
P5R1(config-router)#neighbor 192.168.64.6 remote-as 600

Add your remote host router, the backbone, to AS 600:

BB1(config)#router bgp 600
BB1(config-router)#network 192.168.63.0 mask 255.255.255.0
BB1(config-router)#network 192.168.64.0 mask 255.255.255.0
BB1(config-router)#neighbor 192.168.63.3 remote-as 300
BB1(config-router)#neighbor 192.168.64.4 remote-as 400

This should complete the basic BGP configuration, but there's one more step required to achieve our goal of choosing one ISP over the other. One of the major benefits of BGP is it allows network designers to specify specific routes for traffic. We're going to change the as-path attribute of our backup connection on ISP B to make the path "longer" than the connection through ISP A. This configuration takes place on our backup HSRP router connected to ISP B. First, we add an access list which defines the destination network:

P5R3(config)#access-list 1 permit 192.168.0.0

Now, we create a route-map for this route with the route-map command. We use the match ip address 1 command to specify that the route map should match the addresses stored in access-list 1 (above). Finally, we tell the map that we want to prepend AS number 100 to the as-path attribute for this map. Notice this is the same AS number as the router belongs to. Essentially we're just increasing the path size here, but this same method can be used to redirect traffic.

P5R3(config)#route-map foo permit 10
P5R3(config-route-map)#match ip address 1
P5R3(config-route-map)#set as-path prepend 100

That's the end of the configuration! Now, give BGP a few seconds to synchronize and test your results. Try pinging between client and backbone or backbone to client. If you're having a problem with the connection, use normal troubleshooting steps. First, verify up and up on all the interfaces. Use show ip route and show ip bgp to verify where bgp is working (or NOT working). Try debug ip bgp commands as well. If all else fails, ask a TA for assistance...they're probably bored anyway. ;)

Once you've got connectivity it's time to verify our path selections. Do a traceroute from the client to the server to make sure it's using ISP A.



Now traceroute in the other direction from backbone to client. Does it take ISP A again? It should, this is where the modified as-path is at work. On the backbone, issue a show ip bgp 192.168.0.0 to get specifics about BGP's route to the client LAN. Notice that it knows both paths, but the route through ISP B will have a longer path.



Finally, test the backup link on ISP B. Manually shut down HSRP1's external interface to ISP A. Give the protocols a few seconds to catch up. Two things should happen at once:
1) HSRP tracking sees the interface go down and changes the priority, letting HSRP2 takeover as LAN gateway.
2) BGP sees the connection to AS 100 disappear from that route and removes it from the routing table. Now the only route is through ISP B and the size of the path no longer matters.

Test by doing two traceroutes again, one in each direction. Which path does traffic take now? If either direction fails, and you've given the protocols time to synchronize, check your configuration.





Bring the HSRP1 interface back online. ISP A should automatically take over the routing. That's it! Pretty cool, huh?

[Sample Configs]


Part 4: Gateway Load Balancing Protocol
[http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper0900aecd801790a3.shtml]

This section is currently optional. Not all the routers in our lab support GLBP yet. If you can find two pods that do, try this section. Otherwise, just read through the material so you're familiar with the concepts and commands involved.

This section requires the use of two adjacent pods whose switches are connected.

As was previously discussed, HSRP is effective for providing network redundancy, but it is not a very efficient technology. With a single group, redundant links sit idle. With multiple groups, very basic load balancing is possible, but it requires additional planning and administration, and does not guarantee any sort of even balancing of traffic. Gateway Load Balancing Protocol (GLBP) is an alternative to HSRP, which can provide additional load balancing features on top of redundancy.

We will use the same switch layout as we did in parts one and two, with two vlans, one for clients and one for servers. Routers 2, 3, and 4 will still be in VLAN 30 with R2 and R3 as the GLBP routers and R4 is the server. R1 will again be a client. The difference here is that we will need more clients to test our GLBP implementation. We can use routers connected to an adjacent switch to accomplish this, as long as they can reach the GLBP routers via the switching fabric. Add the inter-switch ports (usually Fa0/23 and Fa0/24) to the client VLAN (20). Connect to your adjacent pod, and add the routers there to VLAN 20 as well. For the purpose of this lab, I'll be using Pods 3 and 4. It's important that you can visualize the logical layout we're using here. Router 1 and all the routers in the second pod are acting as clients on a single ethernet LAN. Routers 2 and 3 are acting as the gateways to this LAN, and R4 is a destination outside the LAN. It can be confusing, so if you don't understand the layout, try drawing it on paper or ask a TA.

Enough talk, let's configure. Start off with the same IP addressing scheme as Parts 1 and 2. Set up all the interface IP addresses, and configure EIGRP. Use 192.168.0.254 as the client's default-gateway again. Do not configure any of the HSRP from the previous sections.

Now for the new part. GLBP is configured at the interface level using the glbp commands. First, set up the virtual gateway IP address as you did before, using glbp [group number] ip [virtual ip address]. Do this on both gateway routers:

P3R2(config)#int Fa0/0
P3R2(config-if)#glbp 1 ip 192.168.0.254

P3R3(config)#int Fa0/0
P3R3(config-if)#glbp 1 ip 192.168.0.254

In GLBP, one router is determined as the "Active Virtual Gateway." While all gateways process traffic, the AVG is responsible for assigning virtual MAC addresses, and responds to all ARP requests on behalf of the other gateways. The AVG is determined the same way as the active router is determined with HSRP, using priorities. Again, the default priority is 100, and the higher priority wins. Make R2 the AVG by lowering the priority on R3:

P3R3(config)#int Fa0/0
P3R3(config-if)#glbp 1 priority 95

Since GLBP load balances the routers, we can specify the weight of different routers based on how much of the load we want them to handle. This is accomplished with the glbp [group number] weighting [maximum] (lower [minimum]) command. If the weight of a router falls below its minimum (due to a tracked interface going down), the device will become inactive. Give each router an equal maximum weight of 100 with a minimum weight of 95.

P3R2(config)#int Fa0/0
P3R2(config-if)#glbp 1 weighting 100 lower 95

P3R3(config)#int Fa0/0
P3R3(config-if)#glbp 1 weighting 100 lower 95

GLBP uses a more advanced tracking mechanism than we used with HSRP. You use the track configuration command to create a tracking object. Here, 30 identifies the tracking object (they're numbered like access lists), interface Fa0/1 specifies what we're tracking, and line-protocol specifies what aspect of that interface we're tracking. The delay up [time] command specifies the wait time before a notification of the object coming online is sent.

P3R2(config)#track 30 interface Fa0/1 line-protocol
P3R2(config)#delay up 30

P3R3(config)#track 30 interface Fa0/1 line-protocol
P3R3(config)#delay up 30

Now we apply the track object to our glbp group.

P3R2(config)#int Fa0/0
P3R2(config-if)#glbp 1 weighting track 30

P3R3(config)#int Fa0/0
P3R3(config-if)#glbp 1 weighting track 30

Notice that this doesn't mean tracking drops the priority by 30 points like it did in HSRP, it means we're using tracking object 30. The priority deduction here will be the default 10 points when an interface goes down. Since we specified a minimum weight of 95, this is still enough to take our routers into standby mode. Finally, we have the equivalent of the HSRP preempt command: the glbp [group number] forwarder preempt (delay minimum [delay]) command. This tells the router to take over role of active forwarder after delay seconds if it has a higher priority than the current active forwarder.

P3R2(config)#int Fa0/0
P3R2(config-if)#glbp 1 forwarder preempt delay minimum 0

P3R3(config)#int Fa0/0
P3R3(config-if)#glbp 1 forwarder preempt delay minimum 0

That's the end of the configuration. By default, GLBP uses round-robin load balancing. To change this, use the glbp [group number] load-balancing [type] command. Finally, test your configuration. Ping from any one of the clients to the server, and do a traceroute.



Now do a traceroute from a different client to the server. You should notice that it used the opposite router the first client did. Round-robin load-balancing is alternating between gateways. If you test with a third client, it should alternate back to the first gateway, and so on.







Use show glbp on each gateway. It should show how many ARP responses the router has sent. Note that since the load balancing is based on ARP responses, doing multiple traceroutes from the same client will all go through the same gateway. This is why we need multiple client machines to test the configuration.





Finally, shut one of the gateway interfaces. The remaining gateway should take over the full traffic load now. Confirm this with a few traceroutes. Write erase, reload, relax...it's over!

[Sample Configs]