HSRP

 HSRP

Apply hot standby router protocol (HSRP)

How Does HSRP Work?

The general idea behind HSRP is rather simple: Configure multiple devices that all exist on the same subnet and are able to act as gateways to the hosts on the subnet. Basic redundancy can be configured by configuring some of the hosts to use one gateway and the other hosts to use another. However, in this situation, if either one of the gateways was to fail, then there are still a large number of hosts that would lose outside network access.

HSRP provides a solution to this problem by allowing two of the connected gateways to be configured to provide redundancy. HSRP does this by providing a virtual MAC and IP address that is shared between these two devices; the active device between the two of them will be responsible for the handling of traffic to the virtual IP address, while the standby device will monitor the active device for signs of failure. Should the active router fail, the standby router will take over the duties of handling traffic that is sent to the virtual IP address by both accepting traffic to the IP address and by taking over the virtual MAC address (using the Address Resolution Protocol (ARP)). Hosts that are configured on the subnet use the virtual IP address as their gateway IP address, and if there is a failure between the HSRP devices, the switchover requires no extra configuration on the host device.

The determination as to which HSRP device on a subnet is elected the active router (versus the standby router) is completed initially by referencing the configured HSRP priority (0 – 255). If configured, the device with the highest priority will become the active HSRP router, and the router with the second highest priority will become the standby router. If there are more than two devices, all other devices will monitor active and standby devices and wait until they are required when a failure occurs. If none of the HSRP devices are configured with a non-default priority (100), then HSRP will use the device with the highest configured IP address on the shared subnet.

HSRP also provides the ability to configure multiple HSRP groups on a single interface. There are a number of different reasons why multiple HSRP groups would work in this way, including the ability to offer further redundancy configurations and load balancing configuration options. The utilization of a single HSRP group between devices has one major disadvantage: One of the gateways always sits idle until the active device fails. This wastes the forwarding potential of this second device; to solve this problem, utilize multiple HSRP groups.

HSRP Versions

There are two versions of HSRP: version 1 and version 2. The difference between them in terms of general functionality is small, but there are several improvements that Cisco made when updating to version 2. Some of these improvements include:

• HSRP version 2 now advertises and learns millisecond timer values, improving the stability of HSRP.
• The total number of HSRP group numbers increases from 256 to 4096 (not necessarily to utilize this many groups on a single interface, but to match local VLAN numbers—on sub-interfaces—for easy troubleshooting and documentation).
• HSRP version 2 includes the addition of an identifier field (which contains the physical MAC address of the source) within the HSRP packet that allows the ability to easily track which device sent an HSRP packet (this is because the active HSRP router will send traffic using the virtual MAC address).
• HSRP version 2 changes the multicast address that is used for HSRP communication to avoid conflict with Cisco Group Management Protocol (CGMP).

Some other differences are not really improvements, per se. HSRP version 1 utilizes the MAC address range from 0000.0C07.AC00 through 0000.0C07.ACFF (00 = Group 0, FF = Group 255), while HSRP version 2 utilizes the MAC address range from 0000.0C9F.F000 through 0000.0C9F.FFFF (000 = Group 0, FFF = Group 4095). HSRP version 1 uses the multicast address 224.0.0.2, while HSRP version 2 uses the multicast address 224.0.0.102. HSRP version 1 and version 2 are not compatible and use different packet formats.

HSRP Preemption, Priority, and Object Tracking

By default, HSRP devices have preemption disabled. What this means is that if a device with a higher priority were to come up on an existing HSRP network, it would not automatically become the active HSRP device. It would only gain this role should both the active AND standby devices fail. If HSRP preemption is enabled, then the device with higher priority will assert itself when it comes online to become the active HSRP device. As covered briefly above, the default HSRP priority that is configured on interfaces is 100 with a valid range from 0 through 255 (higher being better).

Some other capabilities exist with HSRP that enable it to alter its behavior (which device is active and standby), should a separate tracked object alter its status. For example, if two HSRP devices were configured on a subnet and both had separate connections that connected them to the next level of connectivity (closer to the center of the network). If one of these connections went down, it would not be an optional condition for that device to become (or stay) the active HSRP router.

HSRP Configuration Process and Commands

A few basic commands are used to configure HSRP on a device (see Table 1). This section goes over the commands that are required, along with a sequence that can be used to configure them. The next section will go into some examples of how HSRP can be configured.

Table 1 - HSRP Configuration Commands

1	Enter privileged EXEC mode.	router>enable
2	Enter global configuration mode.	router#configure terminal
3	Enter interface configuration mode.	router(config)#interface interface
4	Configure an IP address on the interface.	router(config-if)#ip address address netmask
5	Configure an HSRP virtual IP address. Note: If the group-numberis not entered, then it will default to a group number of 0. The ip-address parameter is not required but does need to be entered on at least one HSRP device. The other devices are able to learn the virtual IP address from this device.	router(config-if)#standby [group-number] ip [ip-address]
6	Configure the HSRP priority (optional). Note: If the group-numberis not entered, then it will default to a group number of 0. The valid values for the priorityare from 0 through 255.	router(config-if)#standby [group-number] priority priority
7	Configure HSRP preemption (optional).	router(config-if)#standby [group-number] preempt
8	Associate a tracked object to the HSRP group (optional). Note: If the group-numberis not entered, then it will default to a group number of 0. By default, the decrement-value is 10; what this means is that the HSRP priority will go down by 10 if the object is not ‘up’. The shutdown parameter will disable the HSRP group if the tracked object goes down.	router(config-if)#standby [group-number] track object-number [decrement decrement-value][shutdown]
9	Create a tracked object (optional). Note: The object-numbercan be any number between 1 and 1000. The line-protocolparameter will track the protocol state of the configured interface. The ip routingparameter will track the IP routing capability of an interface (is it configured with an IP address and operational).	router(config)#track object-number interface interface {line-protocol | ip routing}

Implement router security

Secure router interfaces
let’s start by securing the router access interfaces. The interface we are most concerned about is the VTY line used for Telnet access across the network. I don’t recommend allowing Telnet access to the router from outside your local network unless it occurs via an encrypted session. You may find this a little limiting, especially if you’re getting support from an outside vendor. If so, you may want to grant limited access via the outside interface to only specific addresses. If you choose to do this, there are several tasks to be completed. The first thing you’ll want to do is restrict Telnet access. Then, you’ll want to assign a password to the VTY lines:
Inet-rtr (config)# access-list 1 permit 213.150.10.12
Inet-rtr (config)# line vty 0 4
Inet-rtr (config-line)# password 7 xxxxxx
Inet-rtr (config-line)# login
Inet-rtr (config-line)# access-class 1 in

Other ports to consider are the console and auxiliary ports. The console access is used for physically connecting to the router, and the auxiliary (AUX) port is generally used for modem access. You can secure these ports with passwords, or you can physically secure access to the router. Actually, doing both wouldn’t be a bad idea. You’ll also want to configure an enable secret password.

Securing the external interface
Since the external interface is considered the most vulnerable point of entry, we definitely want to restrict the traffic that can enter. We do this with access lists. In this case, we’ll be using extended access lists. There are several kinds of traffic we want to allow; everything else will be denied. This access list would be applied on the inbound of the outside interface:
access-list 101 deny  ip 172.16.222.0 0.0.0.255 any
access-list 101 deny  ip host 210.28.16.48 any

These two statements above are for antispoofing. They keep out packets that are masquerading with addresses from our internal network, as well as the outside interface address on our router.
access-list 101 permit tcp any any established
access-list 101 deny  ip 192.168.0.0 0.0.255.255 any
access-list 101 deny  ip 172.16.0.0 0.15.255.255 any
access-list 101 deny  ip 10.0.0.0 0.255.255.255 any

The statements above permit only packets that were initiated by internal sessions; they restrict packets from the reserved, private address space designated by RFC. You’ll also want to limit packets that appear to be coming from the localhost loopback address, broadcast addresses, and multicast addresses, as follows:
access-list 101 deny  ip 127.0.0.0 0.255.255.255 any
access-list 101 deny  ip 255.0.0.0 0.255.255.255 any
access-list 101 deny  ip 224.0.0.0 7.255.255.255 any

Then, there’s always the issue of ICMP traffic. It’s nice when users can ping sites outside your network and receive responses. There are other types of ICMP traffic that you may also want to allow.You’ll want to allow SMTP e-mail traffic, but only to internal e-mail servers.

Another kind of traffic you’ll want to allow through is DNS:
access-list 101 permit tcp any any eq domain
access-list 101 permit udp any any eq domain

I also recommend that you log all traffic that matches the restrictions in your access lists. You can do this by adding the log parameter to the end of your access list statements. This also requires a logging server to store the log files.

Turn off unnecessary services and features
It’s always a good idea to lower your exposure on an Internet boundary device, whether it’s a firewall, router, or other edge system. In an effort to do so, it’s recommended that you disable all unnecessary features. The following is a list of features to consider:
no cdp run
no service finger
no ip source-route
no ip directed-broadcast
service timestamps debug datetime
service timestamps log datetime
no service udp-small-servers
no service tcp-small-servers
no ip http server

First, we disable Cisco Discovery Protocol (CDP) on the external interface. It’s a great feature to use internally, but you don’t want to allow outside sources to access CDP information about your router or network. The reason for disabling finger is much the same. Source routing and directed broadcasts should always be disabled unless there is a specific need for these features. Configuring debug logging will allow you to track down router messages. The next statements pertain to minor services but are generally recommended for the disable list. The last statement will shut down the HTTP server facility on the router, which is always a good idea.

So here are some of the basic steps that I think you should consider when configuring a Cisco device facing an untrusted network, assuming you may need these protocols on the interior:

• Disable or block Telnet or SSH
• Use Cisco Login Block
• Disable or block SNMP

From the interior side of the device:

• Centralize log collection and monitoring
• Make sure your secret and username passwords are encrypted in your configuration
• Disable unused services
• Limit access with ACLs
• Use encrypted protocols like HTTPS and SSH

By NIYONGABO Olivier

Tel: +250722833804

E-mail: niyolivier90@gmail.com