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
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
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
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