miércoles 12 de agosto de 2009

Module 8: Minimizing Service Loss and Data Theft in a Campus Network Parte3

8.3 Protecting Against Spoof Attacks


8.3.1 Describing a DHCP Spoof Attack

One of the ways an attacker can gain access to network traffic is to spoof responses that would be sent by a valid DHCP server. The DHCP spoofing device replies to client DHCP requests. The legitimate server may reply as well, but if the spoofing device is on the same segment as the client, its reply to the client may arrive first. The intruder’s DHCP reply offers an IP address and supporting information that designates the intruder as the default gateway or Domain Name System (DNS) server. In the case of a gateway, the clients forward packets to the attacking device, which in turn sends them to the desired destination. This is referred to as a “man-in-the-middle” attack, and it may go entirely undetected as the intruder intercepts the data flow through the network.

Figure describes the DHCP spoofing attack sequence.



8.3.2 Describing DHCP Snooping


DHCP snooping is a Cisco Catalyst feature that determines which switch ports can respond to DHCP requests. Ports are identified as trusted and untrusted. Trusted ports can source all DHCP messages, while untrusted ports can source requests only. Trusted ports host a DHCP server or can be an uplink toward the DHCP server. If a rogue device on an untrusted port attempts to send a DHCP response packet into the network, the port is shut down.

Untrusted ports are those not explicitly configured as trusted. A DHCP binding table is built for untrusted ports. Each entry contains the client MAC address, IP address, lease time, binding type, VLAN number, and port ID recorded as clients make DHCP requests. The table is then used to filter subsequent DHCP traffic. From a DHCP snooping perspective, untrusted access ports should not send any DHCP server responses, such as DHCPOFFER, DHCPACK, or DHCPNAK.

With the DHCP option-82 feature enabled on the switch, port-to-port DHCP broadcast isolation is achieved when the client ports are within a single VLAN. During client-to-server exchanges, broadcast requests from clients connected to VLAN access ports are intercepted by a relay agent running on the switch and are not flooded to other clients on the same VLAN. The relay agent inserts additional information inside the DHCP request packet, such as which port the request originated from, and then forwards it to the DHCP server. During server-to-client exchanges, the DHCP (option-82 aware) server sends a broadcast reply that contains the option-82 field. The relay agent uses this information to identify which port connects to the requesting client and avoids forwarding the reply to the entire VLAN.


8.3.3 Configuring DHCP Snooping


To enable DHCP snooping, use the commands in Figure . Figure describes the steps to configuring DHCP snooping.

Figure shows how to display the DHCP snooping configuration for a switch.

Only ports that are trusted or that have a rate limit applied are shown in the output. All other ports are untrusted and are not displayed.

IP source guard is a security feature that prevents IP source address spoofing. This feature is enabled on a DHCP snooping untrusted Layer 2 port. All IP traffic on the port is blocked, except for DHCP packets that are allowed by the DHCP snooping process. When a client receives a valid IP address from the DHCP server, a per-port VLAN Access Control List (PVACL) is installed on the port. This process restricts the client IP traffic to those source IP addresses configured in the binding. Any IP traffic with a source IP address other than that in the IP source binding is filtered out. This filtering limits a host’s ability to attack the network by claiming a neighbor host’s IP address.

Note:
If IP source guard is enabled on a trunk port with a large number of VLANs that have DHCP snooping enabled, you might run out of ACL hardware resources and some packets might be switched in software.

IP source guard supports only the Layer 2 ports, including both access and trunk. For each untrusted Layer 2 port, there are two levels of IP traffic security filtering, as follows:

Source IP address filter: IP traffic is filtered based on its source IP address. Only IP traffic with a source IP address that matches the IP source binding entry is permitted.

An IP source address filter is changed when a new IP source entry binding is created or deleted on the port. The port PVACL is recalculated and reapplied in the hardware to reflect the IP source binding change. By default, if the IP filter is enabled without any IP source binding on the port, a default PVACL that denies all IP traffic is installed on the port. Similarly, when the IP filter is disabled, any IP source filter PVACL is removed from the interface.

A static IP source binding may be configured on a port via the following global command:

Switch(config)#ip source binding ip-addr ip vlan number interface interface

Source IP and MAC address filter: IP traffic is filtered based on its source IP address as well as its MAC address. Only IP traffic with source IP and MAC addresses matching the IP source binding entry are permitted.

Figure describes IP source guard commands. Figure describes the procedure for enabling IP source guard.

Note:
The static IP source binding can only be configured on Layer 2 switch ports. If you issue the ip source binding vlan interface command on a Layer 3 port, you receive this error message: “Static IP source binding can only be configured on switch port.”


8.3.4 Describing ARP Spoofing


In normal ARP operation, a host sends a broadcast to determine the MAC address of a host with a particular IP address. The device at that IP address replies with its MAC address. The originating host caches the ARP response, using it to populate the destination Layer 2 header of packets sent to that IP address. By spoofing an ARP reply from a legitimate device with a gratuitous ARP, an attacking device appears to be the destination host sought by the senders. The ARP reply from the attacker causes the sender to store the MAC address of the attacking system in its ARP cache. All packets destined for those IP addresses are forwarded through the attacker system.

Figures and illustrate the sequence of events in an ARP spoofing attack.


8.3.5 Dynamic ARP Inspection


Dynamic ARP Inspection (DAI) determines the validity of an ARP packet based on the MAC address-to-IP address bindings stored in a DHCP snooping database. Additionally, DAI can validate ARP packets based on user-configurable ACLs for hosts that use statically configured IP addresses.

To prevent ARP spoofing or “poisoning,” a switch must ensure that only valid ARP requests and responses are relayed. To ensure that only valid ARP requests and responses are relayed, DAI takes the following actions:

  • Forwards ARP packets received on a trusted interface without any checks

  • Intercepts all ARP packets on untrusted ports

  • Verifies that each intercepted packet has a valid IP-to-MAC address binding before forwarding packets that can update the local ARP cache

  • Drops, logs, or drops and logs ARP packets with invalid IP-to-MAC address bindings

Generally, all access switch ports should be cofigured as untrusted and all switch ports connected to other switches as trusted. All ARP packets traversing the network from an upstream distribution or core switch could bypass the security check requiring no further validation.

You can also use DAI to set the rate limit of ARP packets and then err-disable the interface if the rate is exceeded.


8.3.6 Configuring Dynamic ARP Inspection


Figure lists the commands used to configure Dynamic ARP Inspection, and Figure describes the commands.

The following example shows how to configure DAI for hosts on VLAN 1, where client devices are located for switch 2. All client ports are untrusted by default. Only port 3/3 is trusted, because this is the only port where DHCP replies would be expected.

Switch S2(config)#ip arp inspection vlan 1
Switch S2(config)#interface fastethernet 3/3
Switch S2(config-if)#ip arp inspection trust

8.3.7 Protecting Against ARP Spoofing Attacks

To mitigate the chances of ARP spoofing, the following procedures are recommended:

Step 1 Implement protection against DHCP spoofing.

Step 2 Enable dynamic ARP inspection.



Module 8: Minimizing Service Loss and Data Theft in a Campus Network Parte2

8.2 Protecting Against VLAN Attacks
8.2.1 Explaining VLAN Hopping

VLAN hopping is a network attack whereby an end system sends packets to, or collects packets from, a VLAN that should not be accessible to that end system. This is accomplished by tagging the invasive traffic with a specific VLAN ID or by negotiating a trunk link to send or receive traffic on penetrated VLANs. VLAN hopping can be accomplished by switch spoofing or double tagging.


In a switch spoofing attack, the network attacker configures a system to spoof itself as a switch by performing Inter-Switch Link (ISL) or 802.1Q trunking, along with Dynamic Trunking Protocol (DTP) negotiations, to establish a trunk connection to the switch. Any switch port configured as DTP auto may become a trunk port when a DTP packet generated by the attacking device is received, and thereby accept traffic destined for any VLAN supported on that trunk. The malicious device can then send packets to, or collect packets from, any VLAN carried on the negotiated trunk.

Figure describes the switch spoofing sequence of events.

Another method of VLAN hopping is for a workstation to generate frames with two 802.1Q headers to get the switch to forward the frames onto a VLAN that would be inaccessible to the attacker through legitimate means.

If the double-tagged frame has a multicast, broadcast, or unknown destination, the switch that receives the frame floods this frame out all ports attached to the same VLAN (VLAN 10) as the attacker’s port native VLAN. The switch would strip the first VLAN tag before forwarding, provided this tag matched the native VLAN of the port it was received on. Any access port on this first switch assigned to VLAN 10 would receive the frame with the second VLAN tag. If a trunk port has the same native VLAN (VLAN 10), the switch would not re-tag the frame and it would arrive at the next switch with only the second VLAN tag. The second switch would then believe the frame originated from a different VLAN (VLAN 20) and thus flood it out to all ports active in this second VLAN. Also the second switch would forward the frame on any additional trunks that were active with the second VLAN.

If the trunk port on the first switch was assigned a different VLAN than the attacker’s port, the frame would simply be flooded to all active ports in VLAN 10 on both switches (no VLAN hopping). The reason is that the first switch would tag the 801.1Q frame with the attacker’s port VLAN prior to sending it across the trunk.

Figure describes the double-tagging method of VLAN hopping.


8.2.2 Mitigating VLAN Hopping

The measures to defend the network from VLAN hopping consist of a series of best practices for all switch ports and a set of parameters to follow when establishing a trunk port:

  • Configure all unused ports as access ports so that trunking cannot be negotiated across those links.

  • Place all unused ports in the shutdown state and associate with a VLAN designated only for unused ports, carrying no user data traffic.

  • When establishing a trunk link, configure the following:

    • Make the native VLAN different from any data VLANs

    • Set trunking as “on,” rather than negotiated

    • Specify the VLAN range to be carried on the trunk

Note:
The configuration commands in Figure do not work on access ports that support VoIP because they will be configured as trunk ports. However, on all other access ports, it is best practice to apply these commands to mitigate VLAN hopping.


8.2.3 VLAN Access Control Lists


Cisco multilayer switches support three types of ACLs:

  • Router access control list (RACL): Applied to Layer 3 interfaces such as SVI or L3 routed ports. It controls the access of routed traffic between VLANs. RACLs are applied on interfaces for specific directions (inbound or outbound). You can apply one access list in each direction. To improve performance in Cisco Catalyst multilayer switches, RACLs are supported in ternary content addressable memory (TCAM).

  • Port access control list (PACL): Applied on a Layer 2 switch port, trunk port, or EtherChannel port. PACLs perform access control on traffic entering a Layer 2 interface. With PACLs, you can filter IP traffic by using IP access lists and non-IP traffic by using MAC addresses. When you apply a PACL to a trunk port, it filters traffic on all VLANs present on the trunk port.

  • VLAN access control list (VACL): Supported in software on Cisco multilayer switches. Filtering based on Layer 2 or Layer 3 parameters within a VLAN. Unlike RACLs, VACLs are not defined by direction (input or output).

Catalyst switches support four ACL lookups per packet: input and output security ACL, and input and output Quality of Service (QoS) ACL.

Catalyst switches use two methods of performing a merge: order independent and order dependent. With order-independent merge, ACLs are transformed from a series of order-dependent actions to a set of order-independent masks and patterns. The resulting access control entry (ACE) can be very large. The merge is processor and memory intensive.

An order-dependent merge is a recent improvement on some Catalyst switches in which ACLs retain their order-dependent aspect. The computation is much faster and is less processor intensive.

RACLs are supported in hardware through IP standard ACLs and IP extended ACLs, with permit and deny actions. ACL processing is an intrinsic part of the packet forwarding process. ACL entries are programmed in hardware. Lookups occur in the pipeline whether ACLs are configured or not. With RACLs, access list statistics and logging are not supported.

8.2.4 Configuring VACLs


VACLs (also called VLAN access maps in Cisco IOS software) apply to all traffic on the VLAN. You can configure VACLs for IP and MAC-layer traffic.

VACLs follow route-map conventions in which map sequences are checked in order.

When a matching permit ACE is encountered, the switch takes the action. When a matching deny ACE is encountered, the switch checks the next ACL in the sequence or checks the next sequence.

Three VACL actions are permitted:

  • Permit (with capture, Catalyst 6500 only)

  • Redirect (Catalyst 6500 only)

  • Deny (with logging, Catalyst 6500 only)

Two features are supported only on the Cisco Catalyst 6500:

  • VACL capture: Forwarded packets are captured on capture ports. The capture option is only on permit ACEs. The capture port can be an IDS monitor port or any Ethernet port. The capture port must be in an output VLAN for Layer 3 switched traffic.

  • VACL redirect: Matching packets are redirected to specified ports. You can configure up to five redirect ports. Redirect ports must be in a VLAN where the VACL is applied.

The VACL capture option copies traffic to specified capture ports. VACL ACEs installed in hardware are merged with RACLs and other features.

Figure lists the commands used to configure VACLs. Figure describes the steps used to configure VACLs.

Figure shows a sample configuration.

The above configuration does not allow any host using a source IP address from 10.1.0.0 through 10.1.255.255 to send frames across this switch. If the switch receives a frame sourced from this range of IP addresses, they are dropped. It does not matter which VLAN the frame originates from or if the frame is destined for the same originating VLAN. Frames with any other source are allowed to forward.

Note:
You may also specify MAC address filtering within a VLAN using VACL configurations.



8.2.5 Private VLANs and Protected Ports


Internet service providers (ISPs) often have devices from multiple clients, as well as their own servers, on a single Demilitarized Zone (DMZ) segment or VLAN. As security issues proliferate, it becomes necessary to provide traffic isolation between devices, even though they may exist on the same Layer 3 segment and VLAN. Catalyst 6500/4500/3750/3560 switches implement private VLANs to keep some switch ports shared and some isolated, although all ports exist on the same VLAN. The 2960 supports “protected ports,” which is functionally similar to PVLANs on a per-switch basis.

The traditional solution to address these ISP requirements is to provide one VLAN per customer, with each VLAN having its own IP subnet. A Layer 3 device then provides interconnectivity between VLANs and Internet destinations.

These are the challenges with this traditional solution:

  • Supporting a separate VLAN per customer may require a high number of interfaces on service provider network devices.

  • Spanning tree becomes more complicated with many VLAN iterations.

  • Network address space must be divided into many subnets, which wastes space and increases management complexity.

  • Multiple ACL applications are required to maintain security on multiple VLANs, resulting in increased management complexity.

PVLANs and protected ports provide Layer 2 isolation between ports within the same VLAN. This isolation eliminates the need for a separate VLAN and IP subnet per customer.

A protected port does not forward any traffic (unicast, multicast, or broadcast) to any other port that is also a protected port. Traffic cannot be forwarded between protected ports at Layer 2; all traffic passing between protected ports must be forwarded through a Layer 3 device. The forwarding behavior between a protected port and a non-protected port is not affected and proceeds normally.

The example in Figure shows how to configure Fast Ethernet 0/1 interface as a protected port and verify the configuration.

PVLANs are supported on Catalyst 3560, 3750, 4500 and 6500 switches.

A port in a PVLAN can be one of three types:

  • Isolated: Has complete Layer 2 separation from other ports within the same PVLAN, except for the promiscuous port. PVLANs block all traffic to isolated ports, except the traffic from promiscuous ports. Traffic received from an isolated port is forwarded only to promiscuous ports.

  • Promiscuous: Communicates with all ports within the PVLAN, including the community and isolated ports. The default gateway for the segment would likely be hosted on a promiscuous port, given that all devices in the PVLAN need to communicate with that port.

  • Community: Communicate among themselves and with their promiscuous ports. These interfaces are isolated at Layer 2 from all other interfaces in other communities, or in isolated ports within their PVLAN.

Note:
Because trunks can support the VLANs carrying traffic between isolated, community, and promiscuous ports, isolated and community port traffic might enter or leave the switch through a trunk interface.

PVLAN ports are associated with a set of supporting VLANs that are used to create the PVLAN structure. A PVLAN uses VLANs in three ways:

  • As a primary VLAN: Carries traffic from promiscuous ports to isolated, community, and other promiscuous ports in the same primary VLAN.

  • As an isolated VLAN: Carries traffic from isolated ports to a promiscuous port.

  • As a community VLAN: Carries traffic between community ports and to promiscuous ports. You can configure multiple community VLANs in a PVLAN.

Isolated and community VLANs are called secondary VLANs. You can extend PVLANs across multiple devices by trunking the primary, isolated, and community VLANs to other devices that support PVLANs.

Note:
A promiscuous port can service only one primary VLAN. A promiscuous port can service one isolated or many community VLANs.

With a promiscuous port, you can connect a wide range of devices as access points to a PVLAN. For example, you can connect a promiscuous port to the server port to connect an isolated VLAN or a number of community VLANs to the server. A load balancer may be used to load-balance the servers present in the isolated or community VLANs, or you can use a promiscuous port to monitor or back up all the PVLAN servers from an administration workstation.


8.2.6 Configuring PVLANs


To configure a PVLAN on an IOS-based Catalyst 3560, 3750, 4500, or 6500, follow these steps:

Step 1 Set VTP mode to transparent.

Step 2 Create the secondary VLANs.

Note:
Isolated and community VLANs are secondary VLANs.

Step 3 Create the primary VLAN.

Step 4 Associate the secondary VLAN with the primary VLAN. Only one isolated VLAN can be mapped to a primary VLAN, but more than one community VLAN can be mapped to a primary VLAN.

Step 5 Configure an interface as an isolated or community port.

Step 6 Associate the isolated port or community port with the primary-secondary VLAN pair.

Step 7 Configure an interface as a promiscuous port.

Step 8 Map the promiscuous port to the primary-secondary VLAN pair.

Use these commands to configure a VLAN as a PVLAN:

Switch(config)#vlan vlan_ID
Switch(config-vlan)#[no] private-vlan {isolated | primary}

The following example shows how to configure VLAN202 as a primary VLAN and verify the configuration:

Switch#configure terminal
Switch(config)#vlan 202
Switch(config-vlan)#private-vlan primary
Switch(config-vlan)#end
Switch#show vlan private-vlan type

Primary Secondary Type Interfaces
------- --------- ----------------- ------------
202 primary

This example shows how to configure VLAN 200 as an isolated VLAN and verify the configuration:

Switch#configure terminal
Switch(config)#vlan 200
Switch(config-vlan)#private-vlan isolated
Switch(config-vlan)#end
Switch#show vlan private-vlan type

Primary Secondary Type Interfaces
------- --------- ----------------- ------------
202 primary
200 isolated

To associate secondary VLANs with a primary VLAN, perform this procedure:

Switch(config)#vlan primary_vlan_ID
Switch(config-vlan)#[no] private-vlan association {secondary_vlan_list | add secondary_vlan_list | remove secondary_vlan_list}

When you associate secondary VLANs with a primary VLAN, note the following:

  • The secondary_vlan_list parameter contains only one isolated VLAN ID.

  • Use the remove keyword with the secondary_vlan_list parameter to clear the association between the secondary and primary VLANs. The list can contain only one VLAN.

  • Use the no keyword to clear all associations with the primary VLAN.

  • The command does not take effect until you exit VLAN configuration mode.

To configure a Layer 2 interface as a PVLAN promiscuous port, perform this procedure:

Switch(config)#interface {fastethernet | gigabitethernet} slot/port
Switch(config-if)#switchport mode private-vlan {host | promiscuous}
Switch(config-if)#[no] switchport private-vlan mapping primary_vlan_ID {secondary_vlan_list | add secondary_vlan_list | remove secondary_vlan_list}

When you configure a Layer 2 interface as a PVLAN promiscuous port, note the following:

  • The secondary_vlan_list parameter cannot contain spaces. It can contain multiple comma-separated items. Each item can be a single PVLAN ID or a hyphenated range of PVLAN IDs.

  • Enter a secondary_vlan_list or use the add keyword with a secondary_vlan_list to map the secondary VLANs to the PVLAN promiscuous port.

  • Use the remove keyword with a secondary_vlan_list to clear the mapping between secondary VLANs and the PVLAN promiscuous port.

  • Use the no keyword to clear all mappings with the PVLAN promiscuous port.

This example shows how to configure interface FastEthernet 5/2 as a PVLAN promiscuous port, map it to a PVLAN, and verify the configuration:

Switch#configure terminal
Switch(config)#interface fastethernet 5/2
Switch(config-if)#switchport mode private-vlan promiscuous
Switch(config-if)#switchport private-vlan mapping 202 440
Switch(config-if)#end
Switch#show interfaces fastethernet 5/2 switchport
Name: Fa5/2
Switchport: Enabled
Administrative Mode: private-vlan promiscuous
Operational Mode: down
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative private-vlan host-association: none ((Inactive))

Administrative private-vlan mapping: 202 (VLAN0202) 440 (VLAN0440)

Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled

To configure a Layer 2 interface as a PVLAN host port, perform this procedure:

Switch(config)#interface {fastethernet | gigabitethernet} slot/port
Switch(config-if)#switchport mode private-vlan {host | promiscuous}
Switch(config-if)#[no] switchport private-vlan host-association primary_vlan_ID secondary_vlan_ID

This example shows how to configure interface FastEthernet 5/1 as a PVLAN host port and verify the configuration:

Switch#configure terminal
Switch(config)#interface fastethernet 5/1
Switch(config-if)#switchport mode private-vlan host
Switch(config-if)#switchport private-vlan host-association 202 440
Switch(config-if)#end
Switch#show interfaces fastethernet 5/1 switchport
Name: Fa5/1
Switchport: Enabled

Administrative Mode: private-vlan host
Operational Mode: down
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)

Administrative private-vlan host-association: 202 (VLAN0202)
Administrative private-vlan mapping: none

Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled

To permit routing of secondary VLAN ingress traffic, perform this procedure:

Switch(config)#interface vlan primary_vlan_ID
Switch(config-if)#[no] private-vlan mapping primary_vlan_ID {secondary_vlan_list | add secondary_vlan_list | remove secondary_vlan_list}

When you permit routing on the secondary VLAN ingress traffic, note the following:

  • Enter a value for the secondary_vlan_list parameter or use the add keyword with the secondary_vlan_list parameter to map the secondary VLANs to the primary VLAN.

  • Use the remove keyword with the secondary_vlan_list parameter to clear the mapping between secondary VLANs and the primary VLAN.

  • Use the no keyword to clear all mappings with the PVLAN promiscuous port.

This example shows how to permit routing of secondary VLAN ingress traffic from PVLAN440 and verify the configuration:

Switch#configure terminal
Switch(config)#interface vlan 202
Switch(config-if)#private-vlan mapping add 440
Switch(config-if)#end
Switch#show interfaces private-vlan mapping
Interface Secondary VLAN Type
--------- --------- -----------------
vlan202 440 isolated




Module 8: Minimizing Service Loss and Data Theft in a Campus NetworkParte1

Module 8: Minimizing Service Loss and Data Theft in a Campus Network


Overview


This module defines the potential vulnerabilities related to VLANs within a network and possible solutions. Topics include port security for mitigation of MAC spoofing and flooding, using PVLANs and VACLs to control VLAN traffic, VLAN hopping, DHCP spoofing, ARP spoofing, and STP attacks. You learn about many potential problems and solutions; in particular, you learn how to secure switch access using vty ACLs and implementing SSH.


8.1.1 Overview of Switch Security Concerns

A lot of industry attention dwells on security attacks from outside the walls of an organization and at the upper Open Systems Interconnection (OSI) layers. Network security often focuses on edge-routing devices and on filtering packets based on Layer 3 and 4 headers, ports, and stateful packet inspection. This includes all issues surrounding Layer 3 and above as traffic makes its way into the campus network from the Internet. Generally, most security discussions do not consider campus access devices and Layer 2 communication.

The default state of networking equipment highlights this focus on external protection and internal open communication. Firewalls are placed at the organizational borders and default to a secure operational mode, allowing no communication until configured to do so. The default operational mode for routers and switches placed internal to an organization is to accommodate communication and forward all traffic, which often results in minimal security configuration and renders them targets for malicious attacks. If an attack is launched at Layer 2 on an internal campus device, the rest of the network can be quickly compromised, often without detection.

Many security features are available for switches and routers, but they must be enabled to be effective. As with Layer 3, where security had to be tightened on devices within the campus as malicious activity increased, security measures must now be taken to guard against malicious activity at Layer 2. A new security focus centers on attacks launched by maliciously leveraging normal Layer 2 switch operations. Security features exist to protect switches and Layer 2 operations but, as with access control lists (ACLs) for upper-layer security, a policy must be established and appropriate features configured to protect against potential malicious acts while maintaining daily network operations.


8.1.2 Describing Unauthorized Access by Rogue Devices

Rogue access comes in several forms. For example, because unauthorized rogue access points are inexpensive and readily available, employees sometimes plug them into existing LANs and build ad hoc wireless networks without IT department knowledge or consent. These rogue access points can be a serious breach of network security because they can be plugged into a network port behind the corporate firewall. Employees generally do not enable any security settings on the rogue access point, so it is easy for unauthorized users to use the access point to intercept network traffic and hijack client sessions.

Malicious rogue access points, while much less common than employee-installed ones, present an even greater risk and challenge because they are intentionally hidden from physical and network view. These rogue access points create an unsecured wireless LAN connection that puts the entire wired network at risk.

Another security threat is rogue Layer 2 switches. An attacker with physical access to data cabling attaches a rogue switch that can be used to manipulate Spanning Tree Protocol (STP), hop VLANs, sniff traffic, and so on. This rogue switch can be a workstation with the ability to trunk and participate in other Layer 2 operations.

To mitigate STP manipulation, use the root guard and BPDU guard enhancement commands to enforce the placement of the root bridge in the network and the STP domain borders. The STP BPDU guard allows network designers to keep the active network topology predictable. While BPDU guard may seem unnecessary given that the administrator can set the bridge priority to zero, there is still no guarantee that the bridge will be elected as the root bridge because there might be another bridge with priority zero and a lower bridge ID. BPDU guard is best deployed toward user-facing ports to prevent rogue switch network extensions by an attacker.


8.1.3 Switch Attack Categories

Layer 2 malicious attacks are typically launched by a device connected to the campus network. This can be a physical rogue device placed on the network or an external intrusion that takes control of and launches attacks from a trusted device. In either case, the network sees all traffic as originating from a legitimate connected device.

The following lists the types of attacks launched against switches and Layer 2:

  • MAC layer attacks

  • VLAN attacks

  • Spoof attacks

  • Switch device attacks

Figure describes attack methods and mitigation steps.



8.1.4 Describing a MAC Flooding Attack



A common Layer 2 or switch attack is MAC flooding, which causes a switch’s CAM table to overflow, resulting in flooding regular data frames out all switch ports. This attack can be launched to collect a broad sample of traffic or as a denial of service (DoS) attack.

A switch’s CAM tables are limited and, therefore, can contain only a limited number of entries at any one time. A network intruder can maliciously flood a switch with a large number of frames from a range of invalid source MAC addresses. If enough new entries are made before old ones expire, new valid entries are not accepted. Then, when traffic arrives at the switch for a legitimate device that is located on one of the switch ports that was not able to create a CAM table entry, the switch must flood frames to that address out all ports. This has two adverse effects:

  • Switch traffic forwarding is inefficient and voluminous.

  • An intruding device can be connected to any switch port and capture traffic not normally seen on that port.

If the attack is launched before the beginning of the day, the CAM table in the switches would be full. As the majority of legitimate end devices are powered up, their source MAC addresses would not be entered into the CAM tables. If this represents a large number of network devices, the number of MAC addresses for which traffic will be flooded is high, and switch ports will carry flooded frames from a large number of devices.

If the initial flood of invalid CAM table entries is a one-time event, the switch eventually ages out older, invalid CAM table entries, allowing new, legitimate devices to create an entry. Traffic flooding will cease and may never be detected, while the intruder captured a significant amount of data from the network.

Figure shows the progression of a MAC flooding attack.

To mitigate against MAC flooding, port security is configured to define the number of MAC addresses that are allowed on a given port. Port security can also specify which MAC address is allowed on a given port.



8.1.5 Describing Port Security

Cisco Catalyst switches include port security as a feature. Port security restricts a switch port to a specific set or number of MAC addresses. Those addresses can be learned dynamically or configured statically. The port then provides access only to frames from those addresses. If, however, the number of addresses is limited to four but no specific MAC addresses are configured, the port allows any four MAC addresses to be learned dynamically, and port access is then limited to those four dynamically learned addresses.

A port security feature called “sticky learning,” which is available on some switch platforms, combines the features of dynamically learned and statically configured addresses. When this feature is configured on an interface, the interface converts dynamically learned addresses to “sticky secure” addresses. The addresses are added to the running configuration as if they were configured using the switchport port-security mac-address command.

Scenario

Imagine five individuals whose laptops are allowed to connect to a specific switch port when they visit an area of the building. We want to restrict switch port access to the MAC addresses of those five laptops and allow no addresses to be learned dynamically on that port.

Figure describes the process for achieving this.

Note:
Port security cannot be applied to trunk ports where addresses might change frequently. Implementations of port security vary by Cisco Catalyst platform. Check your documentation to see if and how your particular hardware supports this feature.

8.1.6 Configuring Port Security on a Switch

Figure describes what is involved in configuring port security to limit switch port access to a finite, specific set of end-device MAC addresses.

Figure lists the configuration steps. You should be aware of the following things:

Step 1 Port security is enabled on a port-by-port basis.

Step 2 By default, only one MAC address is allowed access through a given switch port when port security is enabled. This parameter increases that number. It places no restriction on specific MAC addresses, just on the total number of addresses that can be learned by the port. Learned addresses are not aged out by default, but can be configured to do so after a specified time using the switchport port-security aging command. The value parameter can be any number from 1 to 1024, with some restrictions regarding the number of ports on a given switch with port security enabled.

Note:
Be sure to set the value parameter to a value of 2 when you are configuring a port to support VoIP and requires a phone and computer accessible on the port. If the default value is used, a port security violation occurs.

Step 3 Access to the switch port can be restricted to one or more specific MAC addresses. If the number of MAC addresses assigned is lower than the value parameter set in Step 2, the remaining allowed addresses can be learned dynamically. If you specify a set of MAC addresses that is equal to the maximum number allowed, access is limited to that set of MAC addresses.

Step 4 By default, if the maximum number of connections is achieved and a new MAC address attempts to access the port, the switch must take one of the following actions:

  • Protect: Frames from the non-allowed address are dropped, but there is no log of the violation.

Note:
The protect argument is platform or version dependent.
  • Restrict: Frames from the non-allowed address are dropped, a log message is created, and a Simple Network Management Protocol (SNMP) trap is sent.

  • Shut down: If any frames are seen from a non-allowed address, the interface is errdisabled, a log entry is made, an SNMP trap is sent, and manual intervention or errdisable recovery must be used to make the interface usable.

Use show commands to verify the port security configuration.

The show port-security command lists the ports on which port security has been enabled. It also displays count information and security actions to be taken per interface.

The full command syntax is as follows:

Switch#show port-security [interface interface_id] address

You can view port security status by interface or by the addresses associated with port security on all interfaces.

Figure displays output from the show port-security command when you do not enter an interface. Use the interface keyword to provide output for a specific interface.

Figure displays output from the show port-security command for a specified interface.

Use the address keyword to display MAC address table security information. Figure displays output from the show port-security address privileged EXEC command. The Remaining Age column is populated only if specifically configured for a given interface.


8.1.7 Port Security with Sticky MAC Addresses

Port security can be used to mitigate spoof attacks by limiting access through each switch port to a single MAC address. This prevents intruders from using multiple MAC addresses over a short period of time but does not limit port access to a specific MAC address. The most restrictive port security implementation would specify the exact MAC address of the single device that is to gain access through each port. Implementing this level of security, however, requires considerable administrative overhead.

Port security has a feature called “sticky MAC addresses” that can limit switch port access to a single, specific MAC address without the network administrator having to determine the MAC address of every legitimate device and manually associate it with a particular switch port.

When sticky MAC addresses are used, the switch port converts dynamically learned MAC addresses to sticky MAC addresses, and adds them to the running configuration as if they were static entries for a single MAC address allowed by port security. Sticky secure MAC addresses are added to the running configuration but do not become part of the startup configuration file, unless the running configuration is copied to the startup configuration after addresses have been learned. If they are saved in the startup configuration, they do not have to be relearned when the switch is rebooted, which provides a higher level of network security.

The following command converts all dynamic port security–learned MAC addresses to sticky secure MAC addresses:

switchport port-security mac-address sticky

This command cannot be used on ports where voice VLANs are configured.



8.1.8 Authentication, Authorization, and Accounting


Authentication, authorization, and accounting (AAA) network security services provide the primary framework through which access control is set up on a switch. AAA is an architectural framework for configuring a set of three independent security functions in a consistent manner. AAA provides a modular way of performing these services. For purposes of this course, only authentication is discussed.

Authentication is the way a user is identified before being allowed access to the network and network services. AAA authentication is configured by defining a list of named authentication methods and then applying that list to various interfaces. The method list defines the types of authentication to be performed and in which sequence they are performed. The method list must be applied to a specific interface before any of the defined authentication methods are performed. If there is no defined method list, the default method list (named “default”) is applied. A defined method list overrides the default method list.

In many circumstances, AAA uses protocols such as RADIUS, TACACS+, or 802.1x to administer security functions. If the switch is acting as a network access server, AAA is the means through which a switch establishes communication between the network access server and the RADIUS, TACACS+, or 802.1x security server.


8.1.9 Authentication Methods

The AAA security services facilitate a variety of login authentication methods.

The list-name argument is the name of the list being created. The method argument refers to the actual method the authentication algorithm tries. Additional authentication methods are used only if the previous method returns an error, not if it fails.

For example, to specify RADIUS as the default method for user authentication during login, enter the following command:

aaa authentication dot1x default group radius

Figure describes the basic process for configuring AAA.


8.1.10 802.1x Port-Based Authentication

The IEEE 802.1x standard defines a port-based access control and authentication protocol that restricts unauthorized workstations from connecting to a LAN through publicly accessible switch ports. The authentication server authenticates each workstation connected to a switch port before making available any services offered by the switch or the LAN.

Until the workstation is authenticated, 802.1x access control allows only Extensible Authentication Protocol over LAN (EAPOL) traffic through the port to which the workstation is connected. After authentication succeeds, normal traffic can pass through the port.

With 802.1x port-based authentication, the devices in the network have the following specific roles:

  • Client: The device (workstation) that requests access to the LAN and switch services, and responds to requests from the switch. The workstation must be running 802.1x-compliant client software, such as what is offered in the Microsoft Windows XP and Vista operating systems. (The port that the client is attached to is the supplicant [client] in the IEEE 802.1x specification.)

  • Authentication server: Performs the actual authentication of the client. The authentication server validates the identity of the client and notifies the switch whether or not the client is authorized to access the LAN and switch services. Because the switch acts as the proxy, the authentication service is transparent to the client. The RADIUS security system with EAP extensions is the only supported authentication server.

  • Switch (also called the authenticator): Controls physical access to the network based on the authentication status of the client. The switch acts as an intermediary (proxy) between the client (supplicant) and the authentication server, requesting identifying information from the client, verifying that information with the authentication server, and relaying a response to the client. The switch uses a RADIUS software agent, which is responsible for encapsulating and decapsulating the EAP frames and interacting with the authentication server.

The switch port state determines whether the client is granted access to the network. The port starts in the unauthorized state. While in this state, the port disallows all ingress and egress traffic, except for 802.1x protocol packets. When a client is successfully authenticated, the port transitions to the authorized state, allowing all traffic for the client to flow normally.

If the switch requests the client identity (authenticator initiation) and the client does not support 802.1x, the port remains in the unauthorized state, and the client is not granted access to the network.

In contrast, when an 802.1x-enabled client connects to a port and the client initiates the authentication process (supplicant initiation) by sending the EAPOL-start frame to a switch not running the 802.1x protocol, no response is received, and the client begins sending frames as if the port is in the authorized state.

You control the port authorization state by using the dot1x port-control interface configuration command and these keywords:

  • force-authorized: Disables 802.1x port-based authentication and causes the port to transition to the authorized state without any authentication exchange required. The port transmits and receives normal traffic without 802.1x-based authentication of the client. This is the default setting.

  • force-unauthorized: Causes the port to remain in the unauthorized state, ignoring all attempts by the client to authenticate. The switch cannot provide authentication services to the client through the interface.

  • auto: Enables 802.1x port-based authentication and causes the port to begin in the unauthorized state, allowing only EAPOL frames to be sent and received through the port. The authentication process begins when the link state of the port transitions from down to up (authenticator initiation) or when an EAPOL-start frame is received (supplicant initiation). The switch requests the identity of the client and begins relaying authentication messages between the client and the authentication server. The switch uniquely identifies each client attempting to access the network with the client MAC address.

If the client is successfully authenticated (receives an “accept” frame from the authentication server), the port state changes to authorized, and all frames from the authenticated client are allowed through the port. If the authentication fails, the port remains in the unauthorized state, but authentication can be retried. If the authentication server cannot be reached, the switch can retransmit the request. If no response is received from the server after the specified number of attempts, authentication fails and network access is not granted.

When a client logs off, it sends an EAPOL-logoff message, causing the switch port to transition to the unauthorized state.

The commands for configuring 802.1x are illustrated in Figure .

To implement 802.1x port-based authentication, follow the steps in Figure .

In Figure , the example shows how to enable AAA and 802.1x on Fast Ethernet port 5/1.



CCNP3 Module 7: Configuring Campus Switches to Support Voice Parte2

7.2 Accommodating Voice Traffic on Campus Switches


7.2.1 QoS and Voice Traffic in the Campus Module

Regardless of the speed of individual switches or links, speed mismatches, many-to-one switching fabrics, and aggregation can cause congestion and latency. If congestion management features are not in place, some packets will be dropped, causing retransmissions that inevitably increase network load even more. QoS can mitigate latency caused by congestion on campus devices.

QoS classifies and marks traffic at one device. Other devices can then prioritize or queue the traffic according to the marks applied to individual frames or packets.

Figure describes how QoS is applied in the campus network.



7.2.2 LAN-Based Classification and Marking



Classification and marking identifies traffic for proper prioritization as the traffic traverses the network. Traffic is classified by examining information at different layers of the Open Systems Interconnection (OSI) model. The classified traffic receives a mark or QoS value. IP traffic can be classified according to any values configurable in an access control list (ACL) or any of the following criteria :

  • Layer 2 parameters: MAC address, Multiprotocol Label Switching (MPLS), ATM cell loss priority (CLP) bit, Frame Relay discard eligible (DE) bit, or ingress interface

  • Layer 3 parameters: IP precedence, differentiated services code point (DSCP), QoS group, IP address, or ingress interface

  • Layer 4 parameters: TCP or UDP ports, or ingress interface

  • Layer 7 parameters: Application signatures or ingress interface

All traffic classified or grouped according to these criteria will be marked according to that classification. QoS marks establish priority levels or priority classes of service for network traffic as it is processed by each switch. Once traffic is marked with a QoS value, QoS policies on switches and interfaces handle traffic according to the values contained in the individual frames and packets. As a result of classification and marking, traffic is prioritized accordingly at each switch to ensure that delay-sensitive traffic receives priority processing as the switch manages congestion, delay, and bandwidth allocation.

QoS Layer 2 classification examines information in the Ethernet or 802.1Q header, such as the destination MAC address or VLAN ID. QoS Layer 2 marking occurs in the Priority field of the 802.1Q header. LAN Layer 2 headers have no means of carrying a QoS value, so 802.1Q encapsulation is required if Layer 2 QoS marking is to occur. The Priority field is 3 bits long and is also known as the 802.1p User Priority or Class of Service (CoS) value.

This 3-bit field supports CoS values from 1 to 7, with 1 being associated with delay tolerant traffic such as TCP/IP. Voice traffic, which by nature is not delay tolerant, receives higher default CoS values. A CoS value of 5 is given to Voice Bearer traffic, which is the phone conversation itself, so voice quality is impaired if packets are dropped or delayed. Call signaling to create, maintain, and tear down a voice call receives a CoS of 3.

As a result of Layer 2 classification and marking, the following QoS operations can occur:

  • Input queue scheduling: When a frame enters a port, it can be assigned to a port-based queue prior to being scheduled for switching to an egress port. Typically, multiple queues are used where traffic requires different service levels.

  • Policing: Frames are inspected to see if a predefined rate of traffic within a certain timeframe has been exceeded. The timeframe is typically a fixed number internal to the switch. If a frame has exceeded the rate limit, it can either be dropped or the CoS value can be marked down.

  • Output queue scheduling: The switch places the frame into an appropriate outbound (egress) queue for switching. The switch ensures that the buffer does not overflow on the queue.

QoS Layer 3 classification examines header values, such as the destination IP address or protocol. QoS Layer 3 marking occurs in the Type of Service (ToS) byte in the IP header. The first three bits of the ToS byte are occupied by IP Precedence, which correlates to the three CoS bits carried in the Layer 2 header.

The ToS byte can also be used for DSCP marking. DSCP allows prioritization hop by hop as packets are processed on each switch and interface. Figure shows how DSCP uses ToS bits. The first three DSCP bits, correlating to Precedence and CoS, identify the DSCP CoS for the packet.

The next three DSCP bits establish a drop precedence for the packet. Packets with a high DSCP drop precedence value are dropped before those with a low value if a device or queue becomes overloaded. Voice traffic is marked with a low value to minimize voice packet drop.

Each 6-bit DSCP value is also given a DSCP name. DSCP classes 1-4 are Assured Forwarding (AF) classes. If the DSCP class value is 3 and the drop precedence is 1, the DSCP would be AF31.



7.2.3 Describing QoS Trust Boundaries



Trust boundaries establish a border for traffic entering the campus network. As traffic traverses the switches of the campus network, it is handled and prioritized according to the marks received or trusted when the traffic originally entered the network at the trust boundary.

At the trust boundary device, QoS values are trusted if they accurately represent the type of traffic and precedence processing the traffic should receive as it enters the campus network. If untrusted, the traffic is marked with a new QoS value appropriate for the policy in place at the point where the traffic entered the campus network. Ideally, the trust boundary exists at the first switch receiving traffic from a device or IP phone. It is also acceptable to establish the trust boundary where all the traffic from an access switch enters a Building Distribution layer port.

Note:
Best practices suggest classifying and marking traffic as close to the traffic source as possible.


7.2.4 Configuring a Switch for the Attachment of a Cisco Phone



Figure illustrates a typical switch-phone-PC topology. Several commands are used to configure and verify basic features for managing voice traffic on Cisco Catalyst switch ports. Figure provides descriptions for the commands used to manage voice traffic.



7.2.5 Basic Switch Commands to Support Attachment of a Cisco IP Phone



Several commands are used to configure and verify the basic required functions on a switch port connected to an IP phone with a PC connected to that phone. An example configuration is illustrated in Figure .



7.2.6 What is AutoQoS VoIP?



AutoQoS gives customers the ability to deploy QoS features for converged IP telephony and data networks much faster and more efficiently. AutoQoS simplifies and automates the Modular QoS CLI (MQC) definition of traffic classes and the creation and configuration of traffic policies. AutoQoS generates traffic classes and policy map CLI templates. When AutoQoS is configured at the interface, the traffic receives the required QoS treatment automatically. In-depth knowledge of the underlying technologies, service policies, link efficiency mechanisms, and Cisco QoS best practice recommendations for voice requirements is not required to configure AutoQoS.

AutoQoS can be extremely beneficial for the following scenarios:

  • Small- to medium-sized businesses that must deploy IP telephony quickly but lack the experience and staffing to plan and deploy IP QoS services

  • Large customer enterprises that need to deploy Cisco telephony solutions on a large scale, while reducing the costs, complexity, and timeframe for deployment, and ensuring that the appropriate QoS for voice applications is being set in a consistent fashion

  • International enterprises or service providers requiring QoS for VoIP where little expertise exists in different regions of the world and where provisioning QoS remotely and across different time zones is difficult

  • Service providers requiring a template-driven approach to delivering managed services and QoS for voice traffic to large numbers of customer premise devices

Cisco AutoQoS simplifies and shortens the QoS deployment cycle. AutoQoS helps in all five major aspects of successful QoS deployments :

  • Application classification: AutoQoS leverages intelligent classification on routers using Cisco network-based application recognition (NBAR) to provide stateful packet inspection. AutoQoS relies on CDP to ensure that the device attached to the LAN is really a Cisco IP phone. Once an IP phone is identified, the voice traffic is automatically classified and QoS policies are applied.

  • Policy generation: AutoQoS evaluates the network environment and generates an initial policy. It automatically generates interface configurations, policy maps, class maps, and ACLs. AutoQoS VoIP automatically employs Cisco NBAR to classify voice traffic, and mark the traffic with the appropriate DSCP value. It can be instructed to rely on, or trust, the DSCP markings previously applied to the packets.

  • Configuration: With one command, AutoQoS configures the port to prioritize voice traffic without affecting other network traffic, while still offering the flexibility to adjust QoS settings for unique network requirements. It also disables QoS settings when a Cisco IP Phone is relocated or moved to prevent malicious activity.

  • Monitoring and reporting: AutoQoS provides visibility into the classes of service deployed via system logging and Simple Network Management Protocol (SNMP) traps, with notification of abnormal events (that is, VoIP packet drops).

  • Consistency: Deployed QoS configurations are consistent among router and switch platforms, ensuring seamless QoS operation and interoperability within the network.



7.2.7 Configuring AutoQoS VoIP on a Cisco Catalyst Switch



When the AutoQoS feature is enabled on the first interface, QoS is globally enabled (mls qos global configuration command).

When the auto qos voip trust interface configuration command is entered, the ingress classification on the interface is set to trust the CoS QoS label received in the packet, and the egress queues on the interface are reconfigured. QoS labels in ingress packets are trusted.

When the auto qos voip cisco-phone interface configuration command is entered, the trusted boundary feature is enabled. The trusted boundary feature uses CDP to detect the presence or absence of a Cisco IP Phone. When a Cisco IP Phone is detected, the ingress classification on the interface is set to trust the QoS label received in the packet. When a Cisco IP Phone is absent, the ingress classification is set to not trust the QoS label in the packet. The egress queues on the interface are also reconfigured. This command extends the trust boundary if an IP Phone is detected.

To display the initial AutoQoS configuration, use the show auto qos [interface [interface-id]] privileged EXEC command. To display any user changes to that configuration, use the show running-config privileged EXEC command. You can compare the output of the show auto qos and show running-config commands to identify the user-defined QoS settings.

AutoQoS performs the following functions in a LAN :

  • Enforces the trust boundary on Cisco Catalyst switch access ports, and uplinks and downlinks

  • Enables Cisco Catalyst strict priority queuing (also known as expedited queuing) with weighted round robin (WRR) scheduling for voice and data traffic, where appropriate

  • Configures queue admission criteria (maps CoS values in incoming packets to the appropriate queues)

  • Modifies queue sizes and weights where required


7.3 Voice Support Lab Exercises



7.3.1 Lab 7-1 Configuring Switches for IP Telephony Support Lab Activity



Lab Exercise: Lab 7-1 Configuring Switches for IP Telephony Support

  • Configure auto QoS to support IP phones

  • Configure CoS override for data frames

  • Configure the distribution layer to trust access layer QoS measures

  • Manually configure CoS for devices that cannot specify CoS (camera)

  • Configure HSRP for voice and data VLANS to ensure redundancy

  • Configure 802.1Q trunks and EtherChannels for Layer 2 redundancy and load balancing


Summary

When you are implementing a VoIP network, you must address quality of service (QoS), power, and capacity planning considerations. One of the easiest ways to deal with QoS is to implement the AutoQoS features. In addition, using auxiliary VLANs and inline power eases the implementation of the VoIP network. This module highlighted the issues related to implementing a VoIP network, and the initial steps to take to ensure that the VoIP network works correctly.



CCNP3 Module 7: Configuring Campus Switches to Support Voice

Module Overview


When migrating to a Voice over IP (VoIP) network, all network requirements, including power and capacity planning, must be examined. In addition, congestion avoidance techniques should be implemented. This module highlights the basic issues and defines the initial steps to take to ensure a functional VoIP implementation.


7.1 Planning for Implementation of Voice in a Campus


7.1.1 Converged Network Benefits

The benefits of packet telephony versus circuit-switched telephony are as follows:

  • More efficient use of bandwidth and equipment: Traditional telephony networks use a 64-kbps channel for every voice call. Packet telephony shares bandwidth among multiple logical connections and offloads traffic volume from existing voice switches.

  • Lower costs for telephony network transmission: A substantial amount of equipment is needed to combine 64-kbps channels into high-speed links for transport across the network. Packet telephony statistically multiplexes voice traffic alongside data traffic. This consolidation represents substantial savings on capital equipment and operations costs.

  • Consolidated voice and data network expenses: Data networks that function as separate networks to voice networks become major traffic carriers. The underlying voice networks are converted to utilize the packet-switched architecture to create a single integrated communications network with a common switching and transmission system. The benefit is significant cost savings on network equipment and operations.

  • Increased revenues from new services: Packet telephony enables new integrated services, such as broadcast-quality audio, unified messaging, and real-time voice and data collaboration. These services increase employee productivity and profit margins well above those of basic voice services. In addition, these services enable companies and service providers to differentiate themselves and improve their market position.

  • Greater innovation in services: Unified communications use the IP infrastructure to consolidate communication methods that were previously independent; for example, fax, voice mail, e-mail, wireline telephones, cellular telephones, and the Web. The IP infrastructure provides users with a common method to access messages and initiate real-time communications—independent of time, location, or device.

  • Access to new communications devices: Packet technology can reach devices that are largely inaccessible to the time-division multiplexing (TDM) infrastructures of today. Examples of such devices are computers, wireless devices, household appliances, personal digital assistants, and cable set-top boxes. Intelligent access to such devices enables companies and service providers to increase the volume of communications they deliver, the breadth of services they offer, and the number of subscribers they serve. Packet technology, therefore, enables companies to market new devices, including videophones, multimedia terminals, and advanced IP phones.

  • Flexible new pricing structures: Companies and service providers with packet-switched networks can transform their service and pricing models. Because network bandwidth can be dynamically allocated, network usage no longer needs to be measured in minutes or distance. Dynamic allocation gives service providers the flexibility to meet the needs of their customers in ways that bring them the greatest benefits.

7.1.2 VoIP Network Components

The basic components of a VoIP network are:

  • IP phones: Provide IP voice to the desktop.

  • Gatekeeper: Provides connection admission control (CAC), bandwidth control and management, and address translation.

  • Gateway: Provides translation between VoIP and non-VoIP networks, such as the public switched telephone network (PSTN). It also provides physical access for local analog and digital voice devices, such as telephones, fax machines, key sets, and PBXs.

  • Multipoint control unit (MCU): Provides real-time connectivity for participants in multiple locations to attend the same videoconference or meeting.

  • Call agent: Provides call control for IP phones, CAC, bandwidth control and management, and address translation.

  • Application servers: Provide services such as voice mail, unified messaging, and Cisco CallManager Attendant Console.

  • Videoconference station: Provides access for end-user participation in videoconferencing. The videoconference station contains a video capture device for video input and a microphone for audio input. The user can view video streams and hear the audio that originates at a remote user station.

Other components, such as software voice applications, interactive voice response (IVR) systems, and soft phones, provide additional services to meet the needs of enterprise sites.



7.1.3 Traffic Characteristics of Voice and Data



Voice traffic has extremely stringent quality of service (QoS) requirements. Voice traffic usually generates a smooth demand on bandwidth and has minimal impact on other traffic as long as voice traffic is managed.

Although voice packets are typically small (60 to 120 bytes), they cannot tolerate delay or drops. The result of delays and drops is often unacceptable voice quality. Because drops cannot be tolerated, User Datagram Protocol (UDP) is used to package voice packets. TCP retransmit capabilities have no value.

For voice quality, the delay should be no more than 150 ms (one-way requirement) and less than 1 percent packet loss.

A typical voice call requires 17 to 106 kbps of guaranteed priority bandwidth, plus an additional 150 bps per call for voice-control traffic. Multiplying these bandwidth requirements by the maximum number of calls expected during the busiest time period indicates the overall bandwidth required for voice traffic.

The QoS requirements for data traffic vary greatly.

Different applications (for example, a human resources application versus an automated teller machine [ATM] application) may make greatly different demands on the network. Even different versions of the same application may have varying network traffic characteristics.

Data traffic can demonstrate either smooth or bursty characteristics, and it differs from voice and video in terms of delay and drop sensitivity. Almost all data applications can tolerate some delay and generally can tolerate high drop rates.

Because data traffic can tolerate drops, the retransmit capabilities of TCP become important and, as a result, many data applications use TCP.

It is important to be able to identify different types of traffic that move over networks. With TCP/IP, most applications can be identified by their use of TCP or UDP port numbers, and with TCP, a stream of traffic usually occurs.

However, some applications use dynamic port numbers that make classifications more difficult. Cisco IOS software supports network-based application recognition (NBAR), which can be used to recognize dynamic port applications.



7.1.4 VoIP Call Flow

VoIP calls can contend with normal client data for bandwidth. If both the client PC and the VoIP phone are on the same VLAN, each will try to use the available bandwidth without consideration of the other device. To avoid this issue, use two VLANs to allow separation of VoIP and client data. After data is separated, QoS can be applied to prioritize the VoIP traffic as it traverses the network.

A major component of designing a successful IP telephony network is properly provisioning the network bandwidth. You can calculate the required bandwidth by adding the bandwidth requirements for each major application, including voice, video, and data. This sum represents the minimum bandwidth requirement for any given link, and it should not exceed approximately 75 percent of the total available bandwidth for the link.

From a traffic standpoint, an IP telephony call consists of two traffic types, as illustrated in Figure using a Cisco CallManager:

  • Voice carrier stream: Real-Time Transport Protocol (RTP) packets that contain the actual voice samples.

  • Call control signaling: Packets belonging to one of several protocols—those used to set up, maintain, tear down, or redirect a call, depending upon call endpoints. Examples are H.323 or Media Gateway Control Protocol (MGCP).

A VoIP packet consists of the voice payload, RTP header, UDP header, IP header, and Layer 2 encapsulation. The IP header is 20 bytes, the UDP header is 8 bytes, and the RTP header is 12 bytes. The link layer overhead varies in size according to the Layer 2 media used; Ethernet requires 18 bytes of overhead. The voice payload size and the packetization period are device dependent.

Coder-Decoders (codecs) convert the analog voice to a digital signal format. This technology has been used for years to convert a telephone signal into a 64,000 bps digital signal (DS0) for use on TDM-based systems. Today, an IP phone uses a G.711 codec for normal voice digitization. G.711 is the only type supported for the Cisco Conference Connection and Personal Assistant applications. G.729 is another supported codec that provides compression of the voice traffic down to 8 kbps. Cisco VoIP equipment supports G.711 and G.729, along with several other common industry standards.



7.1.5 Auxiliary VLANs

Some Cisco Catalyst switches offer a unique feature called an “auxiliary VLAN” or a “voice VLAN.” Auxiliary VLANs allow you to overlay a voice topology onto a data network. You can segment phones into separate logical networks, even though the data and voice infrastructure are physically the same.

Auxiliary VLANs place the phones into their own VLANs without any end-user intervention. Furthermore, these VLAN assignments can be seamlessly maintained, even if the phone is moved to a new location. The user simply plugs the phone into the switch, and the switch provides the phone with the necessary VLAN information. By placing phones into their own VLANs, network administrators gain the advantages of network segmentation and control. Furthermore, network administrators can preserve their existing IP topology for the data end stations. IP phones can be easily assigned to different IP subnets using standards-based DHCP operation.

With the phones in their own IP subnets and VLANs, network administrators can more easily identify and troubleshoot network problems. Additionally, network administrators can create and enforce QoS or security policies. Auxiliary VLANs enable Cisco network administrators to gain all the advantages of physical infrastructure convergence while maintaining separate logical topologies for voice and data terminals. This creates the most effective way to manage a multiservice network.



7.1.6 QoS



Almost any network can take advantage of QoS for optimum efficiency, whether it is a small corporate network, an Internet service provider (ISP), or an enterprise network. QoS utilizes features and functionality to meet the networking requirements of applications sensitive to loss, delay, and delay variation (jitter). QoS allows preference to be given to critical application flows for the available bandwidth.

The Cisco IOS implementation of QoS software provides these benefits:

  • Priority access to resources: Administrators can control which traffic is allowed to access specific network resources, such as bandwidth, equipment, and WAN links. Critical traffic can take possession of a resource because the QoS implementation drops low-priority frames.

  • Efficient management of network resources: If network management and accounting tools indicate that specific traffic is experiencing latency, jitter, or packet loss, you can use QoS tools to adjust how that traffic is handled.

  • Tailored services: ISPs can offer carefully tailored grades of service to their customers. For example, an ISP can offer one service level agreement (SLA) to a customer website that receives 3,000 to 4,000 hits per day and another to a site that receives only 200 to 300 hits per day.

  • Coexistence of mission-critical applications: Mission-critical business applications receive priority access to network resources while providing adequate processing for applications that are not delay sensitive. Multimedia and voice applications tolerate little latency and require priority access to resources. Other delay-tolerant traffic traversing the same link, such as Simple Mail Transfer Protocol (SMTP) over TCP, can still be adequately serviced.



7.1.7 Importance of High Availability for VoIP



The traditional telephony network strives to provide 99.999 percent uptime to the user. This corresponds to 5.25 minutes per year of downtime. Many data networks cannot make the same claim. To provide telephony users the same, or close to the same, level of service as they experience with traditional telephony, the reliability and availability of the data network takes on new importance.


Reliability is a measure of how resilient a network can be. Efforts to ensure reliability include choosing hardware and software with a low mean time between failure, or installing redundant hardware and links. Availability is a measure of how accessible the network is to the users. When a user wants to make a call, for example, the network should be accessible to that user. Efforts to ensure availability include installing proactive network management to predict failures before they happen, and taking steps to correct problems in the design of the network as it grows.

When the data network goes down, it may not come back up for minutes or even hours. This delay is unacceptable for telephony users. Local users with network equipment, such as voice-enabled routers, gateways, or switches for IP phones, now find that their connectivity is terminated. Administrators must provide an uninterruptible power supply (UPS) to these devices in addition to providing network availability. Previously, users received their power directly from the telephone company central office or through a UPS that was connected to a keyswitch or PBX in the event of a power outage. Today, the network devices must continue to function, provide service to the end devices, and possibly (as with Power over Ethernet [PoE]) supply power to end devices.

Note:
Cisco has the option of using DC power with many of its routers, which allows power to be distributed from a “battery bank” that is continuously being charged. When a power outage occurs, the batteries supply DC to the equipment. Battery banks are very common in the telephone industry.

Network reliability comes from incorporating redundancy into the network design. In traditional telephony, switches have multiple redundant connections to other switches. If either a link or a switch becomes unavailable, the telephone company can easily re-route calls. This is why telephone companies can claim a high availability rate.

High availability encompasses many areas of the network. In a fully redundant network, the following components need to be duplicated:

  • Servers and call managers

  • Access layer devices, such as LAN switches

  • Distribution layer devices, such as routers or multilayer switches

  • Core layer devices, such as multilayer switches

  • Interconnections, such as WAN links and PSTN gateways, even through different providers

  • Power supplies and UPSs

In some data networks, a high level of availability and reliability is not critical enough to warrant financing the hardware and links required to provide complete redundancy. But if voice is layered onto the network, these requirements need to be revisited.

With Cisco Architecture for Voice, Video and Integrated Data (AVVID) technology, Cisco CallManager clusters provide a way to design redundant hardware. When using gatekeepers, you can configure backup devices as secondary gatekeepers in case the primary gatekeeper fails. Redundant devices and Cisco IOS services, like Hot Standby Router Protocol (HSRP), also provide high availability. For proactive network monitoring and trouble reporting, a network management platform such as CiscoWorks2000 provides a high degree of responsiveness to network issues.

7.1.8 Power Requirements in Support of VoIP



Accurate calculations of power requirements are critical for an effective IP telephony solution. IP phones are best implemented with PoE. Power can be supplied to the IP phones directly from Cisco Catalyst switches with inline power capabilities or by inserting a Cisco Catalyst Inline Power Patch Panel. In addition to IP phones, failover power and total load must be considered for all devices in the IP telephony availability definition, including Building Distribution and Campus Backbone submodules, gateways, Cisco CallManager, and other servers and devices. Power calculations must be network-based rather than device-based. Also, as with wireless access points, VoIP phones are best implemented with Power over Ethernet (PoE).

To provide highly available power protection, you need either a UPS with a minimum battery life of 1 hour for power system failures, or a generator. This solution must include UPS or generator backup for all devices associated with the IP telephony network. In addition, consider UPS systems that have auto-restart capability and a service contract for 4-hour support response.

Recommendations for IP telephony high-availability power and environment include the following:

  • UPS and generator backup

  • UPS systems with auto-restart capability

  • UPS system monitoring

  • 4-hour service response contract for UPS system problems

  • Recommended equipment operating temperatures maintained at all times

martes 11 de agosto de 2009

Module 5: Implementing High Availability in a Campus Environment Parte3

5.3 Configuring Layer 3 Redundancy with VRRP and GLBP


5.3.1 Describing Virtual Router Redundancy

Like HSRP, Virtual Router Redundancy Protocol (VRRP) allows a group of routers to form a single virtual router. In an HSRP or VRRP group, one router is elected to handle all requests sent to the virtual IP address. With HSRP, this is the active router. An HSRP group has one active router, at least one standby router, and perhaps many listening routers. A VRRP group has one master router and one or more backup routers. The LAN workstations are then configured with the address of the virtual router as their default gateway.

VRRP differs from HSRP in the following ways:

  • VRRP is an IEEE standard (RFC 2338) for router redundancy; HSRP is a Cisco-proprietary protocol.

  • The virtual router represents a group of routers, known as a VRRP group or virtual router group.

  • The active router is referred to as the master virtual router.

  • The master virtual router may have the same IP address as the virtual router group.

  • Multiple routers can function as backup routers.

  • VRRP is supported on Ethernet, Fast Ethernet, and Gigabit Ethernet interfaces, and with Multiprotocol Label Switching (MPLS), virtual private networks (VPNs), and VLANs.

In Figure , routers A, B, and C are members of a VRRP group. The IP address of the virtual router is the same as that of the LAN interface of router A (10.0.0.1). Router A is responsible for forwarding packets sent to this IP address.

The clients have a gateway address of 10.0.0.1. Routers B and C are backup routers. If the master router fails, the backup router with the highest priority becomes the master router. When router A recovers, it resumes the role of master router.

VRRP provides redundancy for the real IP address of a router or for a virtual IP address shared among the VRRP group members. If a real IP address is used, the router with that address becomes the master. If a virtual IP address is used, the master is the router with the highest priority. The master router uses VRRP messages to inform group members that it is the master.



5.3.2 Identifying the VRRP Operations Process


Figure shows a LAN topology in which VRRP is configured so that routers A and B share the load of being the default gateway for clients 1 through 4. Routers A and B act as backup virtual routers to one another should either one fail.

In this example, two virtual router groups are configured. For virtual router 1, router A is the owner of IP address 10.0.0.1, and therefore the master virtual router for clients configured with that default gateway address. Router B is the backup virtual router to router A.

For virtual router 2, router B is the owner of IP address 10.0.0.2 and is the master virtual router for clients configured with the default gateway IP address of 10.0.0.2. Router A is the backup virtual router to router B.

Given that the IP address of the VRRP group is that of a physical interface on one of the group members, the router owning that address is the master in the group. Its priority is set to 255. Backup router priority values can range from 1 to 254; the default is 100. A priority value of 0 indicates that the current master has stopped participating in VRRP. This setting is used to trigger backup routers to transition quickly to the master without having to wait for the current master to time out.

With VRRP, only the master sends advertisements (the equivalent of HSRP hellos). Advertisements are sent on multicast 224.0.0.18 protocol number 112 at a default interval of 1 second.

When the master becomes unavailable, the dynamic failover uses three timers: the advertisement interval, the master down interval, and the skew time.

  • The advertisement interval is the time between advertisements in seconds. The default is 1 second.

  • The master down interval is the number of seconds for the backup to declare the master down. The default is 3 x advertisement interval + skew time.

  • The skew time, (256 - priority) / 256 ms, ensures that the backup router with the highest priority becomes the new master.

Figure lists the steps involved in the VRRP transition.

Note:
If the VRRP master has an orderly shutdown, it sends an advertisement with a priority of 0. This priority setting then triggers the backup router to take over quicker by waiting only the skew time instead of the master down interval.


5.3.3 Configuring VRRP

VRRP is supported on select Cisco Catalyst platforms and can be configured using the commands in Figure .

Figure describes the VRRP command parameters.

Figure describes how to configure VRRP.

Example: Implementing VRRP

SwitchA(config)#interface vlan10
SwitchA(config-if)#ip address 10.1.10.5 255.255.255.0
SwitchA(config-if)#vrrp 10 ip 10.1.10.1
SwitchA(config-if)#vrrp 10 priority 150
SwitchA(config-if)#vrrp 10 timer advertise 4
SwitchB(config)#interface vlan10
SwitchB(config-if)#ip address 10.1.10.6 255.255.255.0
SwitchB(config-if)#vrrp 10 ip 10.1.10.1
SwitchB(config-if)#vrrp 10 priority 100
SwitchB(config-if)#vrrp 10 timer advertise 4

5.3.4 Describing GLBP


While HSRP and VRRP provide gateway resiliency, the upstream bandwidth is not used for the standby members of the redundancy group while the device is in standby mode. Only the active router for HSRP and VRRP groups forwards traffic for the virtual MAC. Resources associated with the standby router are not fully utilized. Some load balancing can occur by creating multiple groups and assigning multiple default gateways, but this configuration creates an administrative burden.

Cisco designed the Gateway Load Balancing Protocol (GLBP) to allow automatic selection, simultaneous use of multiple gateways, and automatic failover between those gateways. Multiple routers share the load of frames that, from a client perspective, are sent to a single default gateway address.

With GLBP, resources can be fully utilized without the administrative burden of configuring multiple groups and managing multiple default gateway configurations as is required with HSRP and VRRP.

GLBP has the following functions:

  • Active virtual gateway (AVG): Members of a GLBP group elect one gateway to be the AVG for that group. Other group members provide backup for the AVG if the AVG becomes unavailable. The AVG assigns a virtual MAC address to each member of the group.

  • Active virtual forwarder (AVF): Each gateway assumes responsibility for forwarding packets sent to the virtual MAC address assigned to it by the AVG. These gateways are known as AVFs for their virtual MAC address.

  • Communication: GLBP members communicate with each other using hello messages sent every 3 seconds to the multicast address 224.0.0.102, User Datagram Protocol (UDP) port 3222.

GLBP has the following features:

  • Load sharing: Traffic from LAN clients can be shared by multiple routers.

  • Multiple virtual routers: Up to 1,024 virtual routers (GLBP groups) can be on each physical interface of a router, and there can be up to four virtual forwarders per group.

  • Preemption: You can preempt an AVG with a higher priority backup virtual gateway. Forwarder preemption works in a similar way, except that it uses weighting instead of priority and is enabled by default.

  • Efficient resource utilization: Any router in a group can serve as a backup, which eliminates the need for a dedicated backup router because all available routers can support network traffic.

GLBP provides upstream load sharing by utilizing the redundant uplinks simultaneously. It uses link capacity efficiently, thus providing peak-load traffic coverage. By making use of multiple available paths upstream from the routers or Layer 3 switches running GLBP, output queues may also be reduced.

HSRP and VRRP use only a single path; other paths are idle, unless multiple groups and gateways are configured. The single path may encounter higher output queue rates during peak times, which leads to lower performance from higher jitter rates. The impact of jitter is lessened and overall performance is improved with GLBP, because more upstream bandwidth is available and additional upstream paths are used.



5.3.5 Identifying the GLBP Operations Process


GLBP allows automatic selection and simultaneous use of all available gateways in the group. The members of a GLBP group elect one gateway to be the AVG for that group. Other members of the group provide backup for the AVG if it becomes unavailable. The AVG assigns a virtual MAC address to each member of the GLBP group. All routers become AVFs for frames addressed to that virtual MAC address. As clients send Address Resolution Protocol (ARP) requests for the address of the default gateway, the AVG sends these virtual MAC addresses in the ARP replies. A GLBP group can have up to four group members.

GLBP supports the following operational modes for load balancing traffic across multiple default routers servicing the same default gateway IP address:

  • Weighted load-balancing algorithm: The amount of load directed to a router is dependent upon the weighting value advertised by that router.

  • Host-dependent load-balancing algorithm: A host is guaranteed to use the same virtual MAC address as long as that virtual MAC address is participating in the GLBP group.

  • Round-robin load-balancing algorithm: As clients send ARP requests to resolve the MAC address of the default gateway, the reply to each client contains the MAC address of the next possible router in round-robin fashion. All routers’ MAC addresses take turns being included in address resolution replies for the default gateway IP address.

GLBP automatically manages the virtual MAC address assignment, determines who handles the forwarding, and ensures that each station has a forwarding path for failures to gateways or tracked interfaces. If failures occur, the load-balancing ratio is adjusted among the remaining AVFs so that resources are used in the most efficient way.

As shown in Figure , GLBP attempts to balance traffic on a per-host basis using the round-robin algorithm.

Figure describes how GLBP balances traffic using the round-robin algorithm.

In Figure , clients A and B have each resolved a different MAC address for the default gateway, so they send their routed traffic to separate routers, although they both have the same default gateway address configured. Each GLBP router is an AVF for the virtual MAC address to which it has been assigned.

Like HSRP, GLBP can be configured to track interfaces. In Figure , the WAN link from router R1 is lost, and GLBP detects the failure.

Because interface tracking was configured on R1, the job of forwarding packets for virtual MAC address 0000.0000.0001 is taken over by the secondary virtual forwarder for the MAC, which is router R2. Therefore, the client sees no disruption of service nor does it need to resolve a new MAC address for the default gateway.

GLBP is supported on select Cisco Catalyst platforms. Figure illustrates the GLBP interface commands. Figure describes the command parameters. Figure describes the steps needed to configure GLBP.

The following example configures GLBP on two multilayer switches:

SwitchA(config)#interface vlan7
SwitchA(config-if)#ip address 10.1.7.5 255.255.255.0
SwitchA(config-if)#glbp 7 ip 10.1.7.1
SwitchA(config-if)#glbp 7 priority 150
SwitchA(config-if)#glbp 7 timers msec 250 msec 750
SwitchB(config)#interface vlan7
SwitchB(config-if)#ip address 10.1.7.6 255.255.255.0
SwitchB(config-if)#glbp 7 ip 10.1.7.1
SwitchB(config-if)#glbp 7 priority 100
SwitchB(config-if)#glbp 7 timers msec 250 msec 750
SwitchA#show glbp 7
Vlan7 - Group 7
State is Active
2 state changes, last state change 23:50:33
Virtual IP address is 10.1.7.1
Hello time 250 msec, hold time 750 msec
Next hello sent in 40 msecs
Redirect time 600 sec, forwarder time-out 7200 sec
Authentication text "stringabc"
Preemption enabled, min delay 60 sec
Active is local
Standby is unknown
Priority 254 (configured)
Weighting 105 (configured 110), thresholds: lower 95, upper 105
Track object 2 state Down decrement 5
Load balancing: host-dependent
There is 1 forwarder (1 active)
Forwarder 1
State is Active
1 state change, last state change 23:50:15
MAC address is 0007.b400.0101 (default)
Owner ID is 0005.0050.6c08
Redirection enabled
Preemption enabled, min delay 60 sec

5.4 High Availability Lab Exercise

5.4.1 Lab 5-1 Hot Standby Router Protocol


Lab Activity

Lab Exercise: Lab 5-1 Hot Standby Router Protocol

Configure inter-VLAN routing with HSRP to provide redundant, fault tolerant routing to the internal network.

Summary


Device, link, or hardware component redundancy at strategic points in the network leads to high availability. Hot Standby Router Protocol (HSRP) provides router redundancy to network hosts and can be optimized in several ways. Virtual Router Redundancy Protocol (VRRP) and Gateway Load Balancing Protocol (GLBP) were derived from HSRP and provide additional redundancy features.

Module 5: Implementing High Availability in a Camp...Parte2

5.2 Optimizing HSRP


5.2.1 Describing HSRP Optimization Options

The options illustrated in Figures and make it possible to optimize HSRP operation in the campus network.


Each standby group has its own active and standby routers. The network administrator can assign a priority value to each router in a standby group, allowing the administrator to influence the active and standby router selection.

To set the priority value of a router (default is 100), enter this command in interface configuration mode:

Switch(config-if)#standby group-number priority priority-value

Figure describes the variables for the standby command.

During the election process, the router with the highest priority in an HSRP group becomes the active router. In the case of a tie, the router with the highest configured IP address is chosen.

To reinstate the default standby priority value, use the no standby priority command.

The following example states that interface VLAN10 has a priority value of 150 in HSRP group 1. If this priority value is the highest number in that HSRP group, the routing device on which this interface resides is the active router for that group.

Switch#show running-config
Building configuration...

Current configuration:
!

interface Vlan10
ip address 172.16.10.32 255.255.255.0
no ip redirects
standby 1 priority 150
standby 1 ip 172.16.10.110

The standby router automatically assumes the active router role when the active router fails or is removed from service. This new active router remains the forwarding router, even if a former active router with a higher priority regains service in the network.

A former active router can be configured to resume the forwarding router role from a router with a lower priority by using the following command in interface configuration mode:

Switch(config-if)#standby [group-number] preempt [{delay} [minimum delay] [sync delay]]

When the standby preempt command is issued, the interface changes to the appropriate state.

Note:
If the routers do not have preempt configured, a router that boots up significantly faster than the others in the standby group becomes the active router, regardless of the configured priority.

To remove the interface from preemptive status, use the no standby group preempt command.

The following example states that interface VLAN10 is configured to resume its role as the active router in HSRP group 1, assuming that interface VLAN10 on this router has the highest priority in that standby group.

Switch#show running-config
Building configuration...

Current configuration:
!

interface Vlan10
ip address 172.16.10.82 255.255.255.0
no ip redirects
standby 1 priority 150
standby 1 preempt
standby 1 ip 172.16.10.110

HSRP hello messages are transmitted constantly by the active and standby HSRP routers and during elections by all HSRP-enabled routers. The hello message contains the priority of the router, along with the hello time and hold time values. The hello time is the interval between the hello messages that the router sends. The hold time is the amount of time that the current hello message is considered valid. The default hello and hold times are 3 and 10 seconds, respectively, which means failover time could be as much as 10 seconds for clients to start communicating with the new default gateway. In some cases, this interval may be excessive for application support.

You can change the default values of the timers to milliseconds to accommodate subsecond failovers. Lowering the hello timer results in increased traffic for hello messages and should be used cautiously. The hold time should be at least three times the value of the hello time.

To change the timers, enter this command in interface configuration mode:

Switch(config-if)#standby group-number timers [msec] hellotime holdtime
Note:
Hello and dead timers intervals must be identical for all devices within an HSRP group.

Figure describes the command options.

To reinstate the default values, use the no standby group timers command.

In some situations, the status of an interface directly affects which router needs to become the active router. This is particularly true when each of the routers in an HSRP group has a different path to resources within the campus network.

In Figure , routers A and B reside in one building, and they each support a Gigabit Ethernet link to the other building. Router A has the higher priority and is the active forwarding router for standby group 1. Router B is the standby router for that group. Routers A and B are exchanging hello messages through their E0 interfaces.


The Gigabit Ethernet link between the active forwarding router for the standby group and the other building experiences a failure.
If HSRP is not enabled, router A would detect the failed link and send an ICMP redirect to router B. However, when HSRP is enabled, ICMP redirects are disabled. Therefore, neither router A nor the virtual router sends an ICMP redirect. In addition, although the G1 interface on router A is no longer functional, router A still communicates hello messages out interface E0, indicating that router A is still the active router. Packets sent to the virtual router for forwarding to headquarters may not be routed.

It is possible that a dynamic routing protocol (if in use) would detect the link failure and then update the routing tables of the routers. However, traffic would then be sent by hosts to the active HSRP router and forwarded back across the Ethernet segment to the standby HSRP router where the functional Gigabit link would be used.


Interface tracking enables the priority of a standby group router to be automatically adjusted based on the availability of that router’s interfaces. When a tracked interface becomes unavailable, the HSRP priority of the router is decreased. When properly configured, the HSRP tracking feature ensures that a router with an unavailable key interface relinquishes the active router role.

In this example, the E0 interface on router A tracks the G1 interface. If the link between the G1 interface and the other building fails, the router automatically decrements the priority on the E0 interface and stops transmitting hello messages out that interface. Router B assumes the active router role when no hello messages are detected for the hold time period. The hello packet has a field that indicates the current priority of the HSRP-enabled interface. Router A changes this field to indicate its priority for subsequent hellos.

To configure HSRP tracking, enter the command in Figure in interface configuration mode.

To disable interface tracking, use the no standby group track command.

The command to configure HSRP tracking on a multilayer switch is the same as on the external router, except that the interface type can be identified as a switch virtual interface or as a physical interface.

Multiple tracking statements may be applied to an interface, which is useful if the intent is for the currently active HSRP interface to relinquish its status only when two (or more) tracked interfaces fail।


5.2.2 Tuning HSRP Operations

You can adjust HSRP timers to tune the performance of HSRP on distribution devices, thereby increasing their resilience and reliability in routing packets off the local VLAN.

You can set the HSRP hello and hold times to millisecond values so that HSRP failover occurs in less than 1 second. For example:

Switch(config-if)#standby 1 timers msec 200 msec 750

Remember that the lower the hello timer is, the greater the hello traffic.

Preemption is an important feature of HSRP, because it allows the primary router to resume the active role when the router comes back online after a failure or maintenance event. Preemption forces a predictable routing path for the VLAN during normal operations and ensures that the Layer 3 forwarding path for a VLAN parallels the Layer 2 Spanning Tree Protocol (STP) forwarding path whenever possible.

You should always use preemption when tracking interfaces. In the previous example, when the Gigabit link came back up, router A’s priority would increase, but without preemption, it would not become the HSRP active router until router B had a state change.

When a preempting distribution switch is rebooted, HSRP preempt communication should not begin until the distribution switch has established full connectivity to the rest of the network. This allows routing protocol convergence to occur more quickly once the preferred router is in an active state. To accomplish this, measure the system boot time and set the HSRP preempt delay to a value 50 percent greater than the boot time. This ensures that the primary distribution switch establishes full connectivity to the network before HSRP communication occurs.

For example, if the boot time for the distribution device is 120 seconds, the preempt configuration would be as follows:

standby 1 preempt
standby 1 preempt delay minimum 180


5.2.3 Describing Load Sharing

With a single HSRP group on a subnet, the active router is forwarding all the packets off that subnet while the standby router is not forwarding any packets. To facilitate load sharing, a single router may be a member of multiple HSRP groups on the same segment. Multiple standby groups further enable redundancy and load sharing. While a router is actively forwarding traffic for one HSRP group, the router can be in standby or listen state for another group. Each standby group emulates a single virtual router. There can be up to 255 standby groups on any LAN, but the maximum number of standby groups need be no more than the number of routers on a segment. In most cases, two standby groups are sufficient.

CAUTION:

Increasing the number of groups in which a router participates increases the load on the router, which can impact the router’s performance.

In Figure , both router A and B are members of groups 1 and 2. Router A is the active forwarding router for group 1 and the standby router for group 2. Router B is the active forwarding router for group 2 and the standby router for group 1.

The following example shows how multiple HSRP groups can be configured on the same segment to facilitate load sharing. To be useful, half the hosts on the segment need to use 172.16.10.110 as a default gateway, while the other half need to use 172.16.10.120.

RouterA#show running-config
Building configuration...

Current configuration:
!

interface Vlan10
ip address 172.16.10.32 255.255.255.0
no ip redirects
standby 1 priority 150
standby 1 ip 172.16.10.110
standby 2 priority 50
standby 2 ip 172.16.10.120
RouterB#show running-config
Building configuration...

Current configuration:
!

interface Vlan10
ip address 172.16.10.33 255.255.255.0
no ip redirects
standby 1 priority 50
standby 1 ip 172.16.10.110
standby 2 priority 150
standby 2 ip 172.16.10.120
RouterA#show standby brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Vl10 1 150 Active local 172.16.10.33 172.16.10.110
Vl10 2 50 Standby 172.16.10.33 local 172.16.10.120

Routers can simultaneously provide redundant backup and perform load sharing across different IP subnets.

In Figure , two HSRP-enabled routers participate in two separate VLANs, using ISL or 802.1Q. Running HSRP over trunks allows users to configure redundancy among multiple routers that are configured as front ends for VLAN IP subnets. By configuring HSRP over trunks, users can eliminate situations in which a single point of failure causes traffic interruptions. This feature provides some improvement in overall networking resilience by providing load balancing and redundancy capabilities between subnets and VLANs.

For a VLAN, configure the same device to be both the spanning tree root and the HSRP active router. This approach ensures that the Layer 2 forwarding path leads directly to the Layer 3 active router, thereby achieving maximum load balancing efficiency on the routers and trunks.

A standby group, an IP address, and a single well-known MAC address with a unique group identifier should be allocated to the group for each VLAN. Although up to 255 standby groups can be configured, the number of group identifiers used should be kept to a minimum. If you are configuring two distribution layer switches, you typically need only two standby group identifiers.

The following example shows how multiple HSRP groups can be configured on two HSRP-enabled routers participating in two separate VLANs

RouterB#show running-config
Building configuration...

Current configuration:
!

interface Vlan10
ip address 172.16.10.32 255.255.255.0
no ip redirects
standby 1 priority 150
standby 1 ip 172.16.10.110
interface Vlan20
ip address 172.16.20.32 255.55.255.0
no ip redirects
standby 2 priority 50
standby 2 ip 172.16.20.120

RouterB#show running-config
Building configuration...

Current configuration:
!

interface Vlan10
ip address 172.16.10.33 255.255.255.0
no ip redirects
standby 1 priority 50
standby 1 ip 172.16.10.110
interface Vlan20
ip address 172.16.20.33 255.255.255.0
no ip redirects
standby 2 priority 150
standby 2 ip 172.16.20.120


5.2.4 HSRP Debug Commands

The commands in Figure are used to debug HSRP operations.

Figure describes the debug commands.


5.2.5 Debugging HSRP Operations

The Cisco IOS implementation of HSRP supports the debug command, which displays HSRP state changes and information regarding the transmission and receipt of HSRP packets. To enable HSRP debugging, enter the following command in privileged EXEC mode:

Switch#debug standby

Figure provides a description of debug standby fields.

CAUTION:

Because debugging output is assigned high priority in the CPU process, this command can render the system unusable.

Example: Debugging with Two Active Routers

The example in Figure displays output on distribution router 1DSW1. Router 1DSW1 is also receiving an HSRP hello from 172.16.1.112 for the same VLAN and same virtual IP address but with a different standby group number. Hence, both routers are active for the same virtual IP address.

The debug standby command is being used to troubleshoot the problem. The standby group number is not consistent, so the two routers have not formed a standby group.

Example: Debugging Active Router Negotiation

This example displays the debug standby command output as the 1DSW1 router with IP address 172.16.1.111 initializes and negotiates for the role of active router.

*Mar 8 20:34:10.221: SB11: Vl11 Init: a/HSRP enabled
*Mar 8 20:34:10.221: SB11: Vl11 Init -> Listen
*Mar 8 20:34:20.221: SB11: Vl11 Listen: c/Active timer expired (unknown)
*Mar 8 20:34:20.221: SB11: Vl11 Listen -> Speak
*Mar 8 20:34:20.221: SB11: Vl11 Hello out 172.16.11.111 Speak pri 100 ip 172.16.11.115
*Mar 8 20:34:23.101: SB11: Vl11 Hello out 172.16.11.111 Speak pri 100 ip 172.16.11.115
*Mar 8 20:34:25.961: SB11: Vl11 Hello out 172.16.11.111 Speak pri 100 ip 172.16.11.115
*Mar 8 20:34:28.905: SB11: Vl11 Hello out 172.16.11.111 Speak pri 100 ip 172.16.11.115
*Mar 8 20:34:30.221: SB11: Vl11 Speak: d/Standby timer expired (unknown)
*Mar 8 20:34:30.221: SB11: Vl11 Standby router is local
*Mar 8 20:34:30.221: SB11: Vl11 Speak -> Standby
*Mar 8 20:34:30.221: SB11: Vl11 Hello out 172.16.11.111 Standby pri 100 ip 172.16.11.115
*Mar 8 20:34:30.221: SB11: Vl11 Standby: c/Active timer expired (unknown)
*Mar 8 20:34:30.221: SB11: Vl11 Active router is local
*Mar 8 20:34:30.221: SB11: Vl11 Standby router is unknown, was local
*Mar 8 20:34:30.221: SB11: Vl11 Standby -> Active
*Mar 8 20:34:30.221: %STANDBY-6-STATECHANGE: Vlan11 Group 11 state Standby -> Active
*Mar 8 20:34:30.221: SB11: Vl11 Hello out 172.16.11.111 Active pri 100 ip 172.16.11.115

To disable the debugging feature, use either the no debug standby or the no debug all command.

Example: Debugging First and Only Router on Subnet

Because 1DSW1 (172.16.11.111) is the only router on the subnet, and it is not configured for preempt, it goes through five HSRP states before becoming the active router. Notice that at Mar 8 20:34:10.221 the interface comes up, and 1DSW1 enters the listen state. The router stays in listen state for a hold time of 10 seconds. 1DSW1 then goes into speak state at Mar 8 20:34:20.221 for 10 seconds. When the router is speaking, it sends its state out every 3 seconds, according to its hello interval. After 10 seconds in speak state, the router has determined that there is no standby router and enters the standby state at Mar 8 20:34:30.221. The router has also determined that there is not an active router; therefore, it immediately enters active state at Mar 8 20:34:30.221. From that point on, the active router sends its active state hello message every 3 seconds. Because there are no other routers on this broadcast domain, no hellos are being received.

1DSW1(config)#interface vlan 11
1DSW1(config-if)#no shut

*Mar 8 20:34:08.925: %SYS-5-CONFIG_I: Configured from console by console
*Mar 8 20:34:10.213: %LINK-3-UPDOWN: Interface Vlan11, changed state to up
*Mar 8 20:34:10.221: SB: Vl11 Interface up
*Mar 8 20:34:10.221: SB11: Vl11 Init: a/HSRP enabled
*Mar 8 20:34:10.221: SB11: Vl11 Init -> Listen
*Mar 8 20:34:11.213: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan11, changed state to up
*Mar 8 20:34:20.221: SB11: Vl11 Listen: c/Active timer expired (unknown)
*Mar 8 20:34:20.221: SB11: Vl11 Listen -> Speak
*Mar 8 20:34:20.221: SB11: Vl11 Hello out 172.16.11.111 Speak pri 100 ip 172.16.11.115
*Mar 8 20:34:23.101: SB11: Vl11 Hello out 172.16.11.111 Speak pri 100 ip 172.16.11.115
*Mar 8 20:34:25.961: SB11: Vl11 Hello out 172.16.11.111 Speak pri 100 ip 172.16.11.115
*Mar 8 20:34:28.905: SB11: Vl11 Hello out 172.16.11.111 Speak pri 100 ip 172.16.11.115
*Mar 8 20:34:30.221: SB11: Vl11 Speak: d/Standby timer expired (unknown)
*Mar 8 20:34:30.221: SB11: Vl11 Standby router is local
*Mar 8 20:34:30.221: SB11: Vl11 Speak -> Standby
*Mar 8 20:34:30.221: SB11: Vl11 Hello out 172.16.11.111 Standby pri 100 ip 172.16.11.115
*Mar 8 20:34:30.221: SB11: Vl11 Standby: c/Active timer expired (unknown)
*Mar 8 20:34:30.221: SB11: Vl11 Active router is local
*Mar 8 20:34:30.221: SB11: Vl11 Standby router is unknown, was local
*Mar 8 20:34:30.221: SB11: Vl11 Standby -> Active
*Mar 8 20:34:30.221: %STANDBY-6-STATECHANGE: Vlan11 Group 11 state Standby -> Active
*Mar 8 20:34:30.221: SB11: Vl11 Hello out 172.16.11.111 Active pri 100 ip 172.16.11.115
*Mar 8 20:34:33.085: SB11: Vl11 Hello out 172.16.11.111 Active pri 100 ip 172.16.11.115
*Mar 8 20:34:36.025: SB11: Vl11 Hello out 172.16.11.111 Active pri 100 ip 172.16.11.115
*Mar 8 20:34:38.925: SB11: Vl11 Hello out 172.16.11.111 Active pri 100 ip 172.16.11.115

Example: Router Without Preempt Coming Up

Router 1DSW1 (172.16.11.111) is configured with a priority of 100, which is higher than the priority of 50 of the current active router, 1DSW2 (172.16.11.112). Router 1DSW1 is not configured with preempt, so even though it has a higher priority, it does not immediately become the active router. After router 1DSW1 goes through the HSRP initialization states, it will come up as the standby router.

1DSW1(config)#interface vlan 11
1DSW1(config-if)#no shut

*Mar 1 00:12:16.871: SB11: Vl11 Hello in 172.16.11.112 Active pri 50 ip 172.16.11.115
*Mar 1 00:12:16.871: SB11: Vl11 Active router is 172.16.11.112
*Mar 1 00:12:16.891: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 00:12:18.619: %LINK-3-UPDOWN: Interface Vlan11, changed state to up
*Mar 1 00:12:18.623: SB: Vl11 Interface up
*Mar 1 00:12:18.623: SB11: Vl11 Init: a/HSRP enabled
*Mar 1 00:12:18.623: SB11: Vl11 Init -> Listen
*Mar 1 00:12:19.619: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan11, changed state to up
*Mar 1 00:12:19.819: SB11: Vl11 Hello in 172.16.11.112 Active pri 50 ip 172.16.11.115
*Mar 1 00:12:19.819: SB11: Vl11 Listen: h/Hello rcvd from lower pri Active router (50/172.16.11.112)
*Mar 1 00:12:22.815: SB11: Vl11 Hello in 172.16.11.112 Active pri 50 ip 172.16.11.115
*Mar 1 00:12:22.815: SB11: Vl11 Listen: h/Hello rcvd from lower pri Active router (50/172.16.11.112)
*Mar 1 00:12:25.683: SB11: Vl11 Hello in 172.16.11.112 Active pri 50 ip 172.16.11.115
*Mar 1 00:12:25.683: SB11: Vl11 Listen: h/Hello rcvd from lower pri Active router (50/172.16.11.112)
*Mar 1 00:12:28.623: SB11: Vl11 Listen: d/Standby timer expired (unknown)
*Mar 1 00:12:28.623: SB11: Vl11 Listen -> Speak
*Mar 1 00:12:28.623: SB11: Vl11 Hello out 172.16.11.111 Speak pri 100 ip 172.16.11.115
*Mar 1 00:12:28.659: SB11: Vl11 Hello in 172.16.11.112 Active pri 50 ip 172.16.11.115
*Mar 1 00:12:28.659: SB11: Vl11 Speak: h/Hello rcvd from lower pri Active router (50/172.16.11.112)
*Mar 1 00:12:31.539: SB11: Vl11 Hello in 172.16.11.112 Active pri 50 ip 172.16.11.115
*Mar 1 00:12:31.539: SB11: Vl11 Speak: h/Hello rcvd from lower pri Active router (50/172.16.11.112)
*Mar 1 00:12:31.575: SB11: Vl11 Hello out 172.16.11.111 Speak pri 100 ip 172.16.11.115
*Mar 1 00:12:34.491: SB11: Vl11 Hello in 172.16.11.112 Active pri 50 ip 172.16.11.115
*Mar 1 00:12:34.491: SB11: Vl11 Speak: h/Hello rcvd from lower pri Active router (50/172.16.11.112)
*Mar 1 00:12:34.547: SB11: Vl11 Hello out 172.16.11.111 Speak pri 100 ip 172.16.11.115
*Mar 1 00:12:37.363: SB11: Vl11 Hello in 172.16.11.112 Active pri 50 ip 172.16.11.115
*Mar 1 00:12:37.363: SB11: Vl11 Speak: h/Hello rcvd from lower pri Active router (50/172.16.11.112)
*Mar 1 00:12:37.495: SB11: Vl11 Hello out 172.16.11.111 Speak pri 100 ip 172.16.11.115
*Mar 1 00:12:38.623: SB11: Vl11 Speak: d/Standby timer expired (unknown)
*Mar 1 00:12:38.623: SB11: Vl11 Standby router is local
*Mar 1 00:12:38.623: SB11: Vl11 Speak -> Standby
*Mar 1 00:12:38.623: SB11: Vl11 Hello out 172.16.11.111 Standby pri 100 ip 172.16.11.115
*Mar 1 00:12:40.279: SB11: Vl11 Hello in 172.16.11.112 Active pri 50 ip 172.16.11.115
*Mar 1 00:12:40.279: SB11: Vl11 Standby: h/Hello rcvd from lower pri Active router (50/172.16.11.112)
*Mar 1 00:12:41.551: SB11: Vl11 Hello out 172.16.11.111 Standby pri 100 ip 172.16.11.115
*Mar 1 00:12:43.191: SB11: Vl11 Hello in 172.16.11.112 Active pri 50 ip 172.16.11.115
*Mar 1 00:12:43.191: SB11: Vl11 Standby: h/Hello rcvd from lower pri Active router (50/172.16.11.112)
*Mar 1 00:12:44.539: SB11: Vl11 Hello out 172.16.11.111 Standby pri 100 ip 172.16.11.115
*Mar 1 00:12:46.167: SB11: Vl11 Hello in 172.16.11.112 Active pri 50 ip 172.16.11.115
*Mar 1 00:12:46.167: SB11: Vl11 Standby: h/Hello rcvd from lower pri Active router (50/172.16.11.112)
*Mar 1 00:12:47.415: SB11: Vl11 Hello out 172.16.11.111 Standby pri 100 ip 172.16.11.115
*Mar 1 00:12:49.119: SB11: Vl11 Hello in 172.16.11.112 Active pri 50 ip 172.16.11.115
*Mar 1 00:12:49.119: SB11: Vl11 Standby: h/Hello rcvd from lower pri Active router (50/172.16.11.112)
*Mar 1 00:12:50.267: SB11: Vl11 Hello out 172.16.11.111 Standby pri 100 ip 172.16.11.115

Example: Router with Preempt Coming Up

Router 1DSW1 (172.16.11.11) is configured with a priority of 100, which is higher than the priority of the active router, 1DSW2 (172.16.11.112). 1DSW1 is also configured with preempt. At Mar 1 00:16:43.099, VLAN11 on 1DSW1 comes up and transitions into the listen state. At Mar 1 00:16:43.295, 1DSW1 receives a hello message from the active router (1DSW2). 1DSW1 determines that the active router has a lower priority. At Mar 1 00:16:43.295, 1DSW1 immediately sends out a coup message indicating that 1DSW1 is transitioning to the active router. 1DSW2 enters the speak state and eventually becomes the standby router.

1DSW1(config)#interface vlan 11
1DSW1(config-if)#no shut

*Mar 1 00:16:41.295: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 00:16:43.095: %LINK-3-UPDOWN: Interface Vlan11, changed state to up
*Mar 1 00:16:43.099: SB: Vl11 Interface up
*Mar 1 00:16:43.099: SB11: Vl11 Init: a/HSRP enabled
*Mar 1 00:16:43.099: SB11: Vl11 Init -> Listen
*Mar 1 00:16:43.295: SB11: Vl11 Hello in 172.16.11.112 Active pri 50 ip 172.16.11.115
*Mar 1 00:16:43.295: SB11: Vl11 Active router is 172.16.11.112
*Mar 1 00:16:43.295: SB11: Vl11 Listen: h/Hello rcvd from lower pri Active router (50/172.16.11.112)
*Mar 1 00:16:43.295: SB11: Vl11 Active router is local, was 172.16.11.112
*Mar 1 00:16:43.295: SB11: Vl11 Coup out 172.16.11.111 Listen pri 100 ip 172.16.11.115
Mar 1 00:16:43.295
*Mar 1 00:16:43.299: %STANDBY-6-STATECHANGE: Vlan11 Group 11 state Listen -> Active
*Mar 1 00:16:43.299: SB11: Vl11 Hello out 172.16.11.111 Active pri 100 ip 172.16.11.115
*Mar 1 00:16:43.303: SB11: Vl11 Hello in 172.16.11.112 Speak pri 50 ip 172.16.11.115
*Mar 1 00:16:44.095: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan11, changed state to up
*Mar 1 00:16:46.187: SB11: Vl11 Hello in 172.16.11.112 Speak pri 50 ip 172.16.11.115
*Mar 1 00:16:46.207: SB11: Vl11 Hello out 172.16.11.111 Active pri 100 ip 172.16.11.115
*Mar 1 00:16:49.095: SB11: Vl11 Hello in 172.16.11.112 Speak pri 50 ip 172.16.11.115
*Mar 1 00:16:49.195: SB11: Vl11 Hello out 172.16.11.111 Active pri 100 ip 172.16.11.115
*Mar 1 00:16:52.079: SB11: Vl11 Hello in 172.16.11.112 Speak pri 50 ip 172.16.11.115
*Mar 1 00:16:52.147: SB11: Vl11 Hello out 172.16.11.111 Active pri 100 ip 172.16.11.115
*Mar 1 00:16:53.303: SB11: Vl11 Hello in 172.16.11.112 Standby pri 50 ip 172.16.11.115
*Mar 1 00:16:53.303: SB11: Vl11 Standby router is 172.16.11.112
*Mar 1 00:16:55.083: SB11: Vl11 Hello out 172.16.11.111 Active pri 100 ip 172.16.11.115
*Mar 1 00:16:56.231: SB11: Vl11 Hello in 172.16.11.112 Standby pri 50 ip 172.16.11.115
*Mar 1 00:16:58.023: SB11: Vl11 Hello out 172.16.11.111 Active pri 100 ip 172.16.11.115
*Mar 1 00:16:59.223: SB11: Vl11 Hello in 172.16.11.112 Standby pri 50 ip 172.16.11.115
*Mar 1 00:17:00.983: SB11: Vl11 Hello out 172.16.11.111 Active pri 100 ip 172.16.11.115
*Mar 1 00:17:02.211: SB11: Vl11 Hello in 172.16.11.112 Standby pri 50 ip 172.16.11.115
*Mar 1 00:17:03.847: SB11: Vl11 Hello out 172.16.11.111 Active pri 100 ip 172.16.11.115