Cisco CCNP

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

2009-08-12T22:57:00.000-07:00

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

2009-08-12T22:50:00.000-07:00

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

2009-08-12T22:40:00.001-07:00

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

2009-08-12T15:11:00.001-07:00

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

2009-08-12T15:05:00.000-07:00

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

Module 5: Implementing High Availability in a Campus Environment Parte3

2009-08-11T15:14:00.000-07:00

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

2009-08-11T15:04:00.001-07:00

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

Module 5: Implementing High Availability in a Campus Environment

2009-08-10T23:07:00.000-07:00

Module 5: Implementing High Availability in a Campus Environment

Module Overview

A network with high availability provides alternative means by which all infrastructure paths and key servers can be accessed at all times. The Hot Standby Routing Protocol (HSRP) is one of those software features that can be configured to provide Layer 3 redundancy to network hosts. HSRP optimization provides immediate or link-specific failover and a recovery mechanism. Virtual Router Redundancy Protocol (VRRP) and Gateway Load Balancing Protocol (GLBP) evolved from HSRP, providing additional Layer 3 redundancy options. VRRP is a vendor-neutral Layer 3 redundancy protocol and GLBP is a Cisco-proprietary improvement to HSRP that provides intrinsic load balancing.

5.1 Configuring Layer 3 Redundancy with HSRP

5.1.1 Describing Routing Issues

When a default gateway is configured on a device, there is usually no means by which to configure a secondary gateway, even if a second route exists to carry packets off the local segment.

For example, primary and secondary paths between the Building Access and Building Distribution submodules provide continuous access if of a link fails at the Building Access layer. Primary and secondary paths between the Building Distribution and Building Core layers provide continuous operations if a link fails at the Building Distribution layer.

In Figure , router A is responsible for routing packets for subnet A, and router B is responsible for handling packets for subnet B. If router A becomes unavailable, routing protocols can quickly and dynamically converge and determine that router B will now transfer packets that would otherwise have gone through router A. However, most workstations, servers, and printers do not receive this dynamic routing information.

End devices are typically configured with a single default gateway IP address that does not change when network topology changes occur. If the router whose IP address is configured as the default gateway fails, the local device is unable to send packets off the local network segment, effectively disconnecting it from the rest of the network. Even if a redundant router that could serve as a default gateway for that segment exists, there is no dynamic method by which these devices can determine the address of a new gateway.

Cisco IOS software runs proxy Address Resolution Protocol (ARP) to enable hosts that have no knowledge of routing options to obtain the MAC address of a gateway that is able to forward packets off the local subnet. For example, if the proxy ARP router receives an ARP request for an IP address that it knows is not on the same interface as the request sender, it generates an ARP reply packet with its local MAC address as the destination MAC address of the IP address being resolved. The host that sent the ARP request sends all packets destined for the resolved IP address to the MAC address of the router. The router then forwards the packets toward the intended host, perhaps repeating this process along the way. Proxy ARP is enabled by default.

With proxy ARP, the end-user station behaves as if the destination device were connected to its own network segment. If the responsible router fails, the source end station continues to send packets for that IP destination to the MAC address of the failed router, and the packets are therefore discarded.

Eventually, the proxy ARP MAC address ages out of the workstation’s ARP cache. The workstation may eventually acquire the address of another proxy ARP failover router, but it cannot send packets off the local segment during this failover time.

For further information on proxy ARP, refer to RFC 1027.

5.1.2 Identifying the Router Redundancy Process

With this type of router redundancy and , a set of routers works in concert to present the illusion of a single virtual router to the hosts on the LAN. By sharing an IP address and a MAC (Layer 2) address, two or more routers can act as a single “virtual” router. The virtual router’s IP address is configured as the default gateway for the workstations on a specific IP segment. When frames are to be sent from the workstation to the default gateway, the workstation uses ARP to resolve the MAC address associated with the IP address of the default gateway. ARP returns the MAC address of the virtual router. Frames sent to the virtual router’s MAC address can then be physically processed by any active or standby router that is part of that virtual router group.

Two or more routers use a protocol to determine which physical router is responsible for processing frames sent to the MAC or IP address of a single virtual router. Host devices send traffic to the address of the virtual router. The physical router that forwards this traffic is transparent to the end stations. This redundancy protocol provides the mechanism for determining which router should take the active role in forwarding traffic and determining when that role must be assumed by a standby router. The transition from one forwarding router to another is transparent to the end devices.

Figure describes the steps that take place when the forwarding router fails.

5.1.3 Describing HSRP

Hot Standby Router Protocol (HSRP) defines a standby group, with each router assigned to a specific role within the group. HSRP provides gateway redundancy by sharing IP and MAC addresses between redundant gateways. The protocol transmits virtual MAC and IP address information between two routers belonging to the same HSRP group.

Figure describes some of the terms used with HSRP.

An HSRP group consists of the following:

Active router
Standby router
Virtual router
Other routers

HSRP active and standby routers send hello messages to the multicast address 224.0.0.2 using UDP port 1985.

5.1.4 Identifying HSRP Operations

All the routers in an HSRP group have specific roles and interact in prescribed ways.

The virtual router is simply an IP and MAC address pair that end devices have configured as their default gateway. The active router processes all packets and frames sent to the virtual router address. The virtual router does not process physical frames and exists in software only.

Within an HSRP group, one router is elected to be the active router. The active router physically forwards packets sent to the MAC address of the virtual router.

The active router responds to traffic for the virtual router. If an end station sends a packet to the virtual router MAC address, the active router receives and processes that packet. If an end station sends an ARP request with the virtual router IP address, the active router replies with the virtual router MAC address.

In this example, router A assumes the active role and forwards all frames addressed to the well-known MAC address of 0000.0c07.acxx, where xx is the HSRP group identifier.

The IP address and corresponding MAC address of the virtual router are maintained in the ARP table of each router in the HSRP group. As shown in the Figure , the show ip arp command displays the ARP cache on a multilayer switch.

Figure describes the output for the show ip arp command.

In the example illustrated in Figure , the output displays an ARP entry for a router that is a member of HSRP group 1 in VLAN10. The virtual router for VLAN10 is identified as 172.16.10.110. The well-known MAC address that corresponds to this IP address is 0000.0c07.ac01, where 01 is the HSRP group identifier for group 1. The HSRP group number is the standby group number (1) converted to hexadecimal (01).

The HSRP standby router monitors the operational status of the HSRP group and quickly assumes packet-forwarding responsibility if the active router becomes inoperable. Both the active and standby routers transmit hello messages to inform all other routers in the group of their role and status. The routers use destination multicast address 224.0.0.2 with UDP port 1985 for these messages. The source address is the interface IP address of the sending router.

An HSRP group may contain other routers that are group members but are not in an active or standby state. These routers monitor the hello messages sent by the active and standby routers to ensure that active and standby routers exist for the HSRP group of which they are a member. These routers do forward packets addressed to their own specific IP addresses, but they do not forward packets addressed to the virtual router. These routers issue speak messages at every hello interval time.

Figure describes some of the terms used with HSRP.

When the active router fails, the other HSRP routers stop seeing hello messages from the active router. The standby router then assumes the role of the active router. If other routers are participating in the group, they contend to be the new standby router.

If both the active and standby routers fail, all routers in the group contend for the active and standby router roles.

Because the new active router assumes both the IP and MAC addresses of the virtual router, the end stations see no disruption in service. The end-user stations continue to send packets to the virtual router MAC address, and the new active router delivers the packets to the destination.

5.1.5 Describing HSRP States

A router in an HSRP group can be in one of the following states: initial, learn, listen, speak, standby, or active.

Figure describes the different HSRP states.

When a router exists in one of these states, it performs the actions required for that state. Not all HSRP routers in the group transition through all states. For example, if there are three routers in the group, the router that is not the standby or active router remains in the listen state.

All routers begin in the initial state, indicating that HSRP is not running. This state is entered via a configuration change, such as when HSRP is disabled on an interface, or when an HSRP-enabled interface is first brought up, such as when the no shutdown command is issued.

After the initial state, the interface moves to the learn state. The interface is expecting to see HSRP packets and from these packets determine the virtual IP and active HSRP router for the group.

Once the interface has seen HSRP packets and determined the virtual IP, it moves to the listen state. The purpose of the listen state is to determine if there are already active or standby routers for the group. If the active and standby routers are functional, the interface remains in this state. However, if hellos are not seen from either router, the interface moves to the speak state.

In the speak state, the routers are actively participating in the election of the active router, standby router, or both. The routers look at each other’s hello packets to determine which router should assume which role.

Three timers are used in HSRP: active, standby, and hello. If a hello is not received from an active HSRP router within the active timer, the router transitions to a new HSRP state.

Figure describes the HSRP timers.

In the standby state , because the router is a candidate to become the next active router, it sends periodic hello messages. It also listens for hello messages from the active router. There can only be one standby router in the HSRP group.

In the active state , the router is currently forwarding packets that are sent to the virtual MAC address of the group. It also replies to ARP requests directed to the virtual router’s IP address. The active router sends periodic hello messages. There must be one active router in each HSRP group.

5.1.6 Describing HSRP Configuration Commands

Figure illustrates common HSRP configuration commands.

Figure describes the essential commands used to configure and verify HSRP.

5.1.7 Enabling HSRP

The following command enables HSRP on an interface:

Switch(config-if)#standby group-number ip ip-address

Figure describes the command parameters for configuring an HSRP group on an interface.

When HSRP is running, the end-user stations must not discover the actual MAC addresses of the routers in the standby group. Any protocol that informs a host of a router’s actual address must be disabled. Enabling HSRP on a Cisco router interface automatically disables Internet Control Message Protocol (ICMP) redirects on that interface, which ensures that the addresses of the participating HSRP routers are not discovered.

After the standby ip command is issued, the interface changes to the appropriate state, and the router issues an HSRP message.

To remove an interface from an HSRP group, enter the no standby group ip command.

The following example states that interface VLAN11 is a member of HSRP group 11, the virtual router IP address for the group is 172.16.11.115, and ICMP redirects are disabled. To verify the HSRP configuration, use the show running-config command:

Switch#show running-config
Building configuration...

Current configuration:!

interface Vlan11
ip address 172.16.11.113 255.255.255.0
no ip redirects
standby 11 ip 172.16.11.115
!

Another way to verify the HSRP configuration is with the show standby brief command, which displays abbreviated information about the current state of all HSRP operations on the device.

To display the status of the HSRP router, use one of these commands:

Switch#show standby [interface [group]] [active | init | listen | standby] [brief]

Switch#show standby delay [type-number]

If the optional interface parameters are not included, the show standby command displays HSRP information for all interfaces.

The following example shows the output of the show standby command:

Switch#show standby Vlan11 11
Vlan11 - Group 11
Local state is Active, priority 110
Hellotime 3 holdtime 10
Next hello sent in 00:00:02.944
Hot standby IP address is 172.16.11.115 configured
Active router is local
Standby router is 172.16.11.114 expires in 00:00:08
Standby virtual mac address is 0000.0c07.ac01

This is the output when you use the brief parameter:

Switch#show standby brief
Interface Grp Prio P State Active addr Standby addr Group addr
Vl11 11 110 Active local 172.16.11.114 172.16.11.115

Notice that the group address 172.16.11.115 is on the same subnet as the standby and active router IP addresses.

Modulo 4-Implementing Inter-VLAN Routing.Parte3

2009-08-10T22:46:00.000-07:00

4.3.4 Describing CEF Configuration Commands

Use the commands in Figure to configure CEF and verify its operation. Figure describes the CEF configuration and verification commands.

4.3.5 Enabling CEF-Based MLS

Hardware Layer 3 switching is permanently enabled on Cisco Catalyst 6500 Series Supervisor Engine 720s with Policy Feature Card 2 (PFC2) or PFC3, Multilayer Switch Feature Card 3s (MSFC3s), and Distributed Forwarding Cards (DFCs). No configuration is required, and CEF cannot be disabled.

You can use the no ip cef command to disable CEF on the Cisco Catalyst 4000 or the no ip route-cache cef command on a Cisco Catalyst 3550 interface.

If CEF is enabled globally, it is automatically enabled on all interfaces as long as IP routing is enabled on the device. You can then enable or disable CEF on an interface basis. Cisco recommends that CEF be enabled on all Layer 3 interfaces. If CEF is disabled on an interface, you can enable CEF as follows:

On the Cisco Catalyst 3550 switch, use the ip route-cache cef interface configuration command.
On the Cisco Catalyst 4000 switch, use the ip cef interface configuration command.

Per-destination load balancing allows the router to use multiple paths to achieve load sharing. Packets for a given source-destination host pair are guaranteed to take the same path, even if multiple paths are available. This ensures that packets for a given host pair arrive in order. Per-destination load balancing is enabled by default when you enable CEF, and it is the load balancing method of choice for most situations.

Because per-destination load balancing depends on the statistical distribution of traffic, load sharing becomes more effective as the number of source-destination pairs increases.

The show ip cef command displays entries in the FIB.

4.3.6 Describing Common CEF Problems and Solutions

CEF is the fastest means of switching Layer 3 packets in hardware. The CEF tables stored in hardware are populated from information gathered by the route processor. There are two primary steps in troubleshooting CEF operations:

Ensure that the normal Layer 3 operations on the route processor are functioning properly so that the switch tables are populated with accurate and complete information.
Verify that information from the route processor has properly populated the FIB and adjacency table, and is being used by CEF to switch Layer 3 packets in hardware.

Troubleshooting CEF is, in essence, verifying that packets are indeed receiving the full benefit of CEF switching and not being punted to a slower packet switching or processing method. The Cisco term "punt" describes the action of sending a packet down to the next-fastest switching level. The following list defines the order of preferred Cisco IOS switching methods, from fastest to slowest:

Distributed CEF
CEF
Fast switching
Process switching

A punt occurs when the preferred switching method did not produce a valid path or, in CEF, a valid adjacency. If the CEF lookup process fails to find a valid entry in the FIB, CEF installs a punt adjacency to the less-preferred system. CEF punts all packets with that adjacency to the next-best switching mode to forward all the packets by some means, even if that means is less efficient.

Figure describes some basic CEF problems and associated solutions.

4.3.7 Describing CEF Troubleshooting Commands

The commands available to troubleshoot CEF are platform dependent. The commands in Figure can be used to troubleshoot CEF on the Cisco Catalyst 4500 series switch.

You can use the show interface command with the | begin L3 argument to verify that Layer 3 traffic is being switched, thereby utilizing CEF.

Use the show interfaces command with the | include switched command to show switching statistics at each layer for the interface and to verify that Layer 3 packets are being switched.

Figure illustrates the command used to display detailed information about the adjacency table.

Each time an adjacency entry is created, a Layer 2 data link–layer header for that adjacent node is pre-computed and stored in the adjacency table. This information is subsequently used for encapsulation during CEF switching of packets.

The show adjacency detail command displays the information to be used during this Layer 2 encapsulation. The header information displayed should be the same as would be expected during normal (non-CEF) Layer 2 forwarding operations. Adjacency statistics are updated approximately every 60 seconds.

The show cef drops command displays whether packets are being dropped because of incomplete or nonexistent adjacencies. The two known reasons for incomplete or nonexistent adjacencies are as follows:

The router cannot use ARP successfully for the next-hop interface.
After a clear ip arp or a clear adjacency command, the router marks the adjacency as incomplete, and then it fails to clear the entry.

The debug facility can be used to display detailed information on CEF operations. Use the debug ip cef command to view CEF drops because of an incomplete adjacency. You can include arguments to limit the output, which reduces overhead and allows you to focus on a specific CEF operation.

The following arguments limit the debug output:

drops: Records dropped packets.
access-list: Limits the collection of debugging information from specified lists.
receive: Records packets that are not switched using information from the FIB but that are received and sent to the next switching layer.
events: Records general CEF events.
prefix-ipc: Records updates related to IP prefix information, including the following:

Debugging of IP routing updates in a line card
Reloading of a line card with a new table
Notification that adding a route update from the route processor to the line card exceeds the maximum number of routes
Control messages related to FIB prefixes

table: Produces a table showing events related to the FIB. Possible types of events include the following:
Routing updates that populate the FIB
Flushing of the FIB
Adding or removing entries to the FIB
Table reloading process

4.3.8 Troubleshooting Layer 3 CEF-Based MLS

The CEF tables stored in hardware are populated from information gathered by the route processor. To properly troubleshoot CEF operations, first ensure that the normal Layer 3 operations on the route processor are functioning properly so that the CEF tables are populated with accurate and complete information. Next, verify that information from the route processor has properly populated the FIB and adjacency table used by CEF to perform Layer 3 switching of packets.

The steps below verify whether packet transfer between the following hosts is occurring using CEF:

Host 1 in VLAN10 with an IP address of 192.168.10.10
Host 2 in VLAN150 with an IP address of 192.168.150.3

Step 1 Verify CEF.

Verify that CEF is operational at global or interface level using these commands:

show ip cef summary
show ip cef vlan 10

Note:

CEF cannot be turned off on most Cisco Catalyst platforms. If CEF is not operational, it is likely that the Cisco Catalyst has disabled the feature. This may be because of a software, feature, or hardware incompatibility or inadequate memory to support a large FIB and adjacency table.

Step 2 Verify the configuration.

If CEF is not operational, display the running configuration to determine whether any switching functions have been configured that might disable CEF operations.

If CEF is operational, display the running configuration to verify the IP configuration of the Layer 3 interfaces used for the hosts to communicate. The IP addresses should be appropriate for the subnet, and the interfaces should not be shut down. The following is a sample of the configuration output expected for the VLANs associated with the host communication. On this router, VLAN 199 is the transit path that is traversed to arrive at subnet 192.168.150.0:

Switch#show running-config
interface VLAN 10
description Source VLAN
ip address 192.168.10.1 255.255.255.0
!
interface VLAN 199
description Transit VLAN
ip address 192.168.199.1 255.255.255.0

Step 3 Verify the population of the routing table on the route processor.

The routing protocols and route processor must populate the routing table accurately before those routing table entries can be of use, because they are transferred to the FIB to facilitate Layer 3 switching. Verify the routing table by referring to a network diagram, knowing which routes should appear in the routing table, and then execute the show ip route command. In the case of troubleshooting connectivity to the specific network of the destination host (192.168.150.3/24), use the following command:

Switch#show ip route | include 192.168.150.0
O 192.168.150.0/24 [110/2] via 192.168.199.3, 00:13:00, VLAN 199

Step 4 The network is accessible via the next-hop address 192.168.199.3. Therefore, the ARP entry by which to access 192.168.150.3 should be the MAC address resolved for 192.168.199.3.

Verify an ARP entry on the route processor.

Verify that there is an ARP entry for the next-hop IP address before checking whether that entry is represented in the adjacency table.

Switch#show ip arp 192.168.199.3
Protocol Address Age Hardware Addr Type Interface
Internet 192.168.199.3 176 0030.7150.6800 ARPA VLAN 199

Step 5 Verify the CEF FIB table entry for the route.

Step 3 verified that a route to network 192.168.150.0 existed in the routing table. Now verify that a CEF FIB entry exists to that same destination to ensure that packets are CEF-switched using the FIB rather than process-switched using the routing table.

Switch#show ip cef 192.168.150.0
192.168.150.0/24, version 298, cached adjacency 192.168.199.3
0 packets, 0 bytes
via 192.168.199.3, VLAN 199, 0 dependencies
next−hop 192.168.199.3, VLAN 199
valid cached adjacency

This output verifies that there is a valid CEF entry for the destination network. Packets can be CEF-switched to the destination host.

Step 6 Verify an adjacency table entry for the destination.

Verify that the FIB entry shown in step 5 has an associated adjacency table entry by using this command:

Switch#show adjacency detail | begin 192.168.199.3
IP VLAN 199 192.168.199.3(7)
0 packets, 0 bytes
003071506800
.....
...
.

The above output indicates that there is an adjacency for the next-hop IP address. The destination MAC address (003071506800) is the MAC address in the ARP table, as displayed in step 4.

The counters (0 packets, 0 bytes) are almost always 0, since packets are switched in hardware and, as such, they never reach the route processor, which is required to increment counters.

Step 7 Verify CEF from the supervisor engine.

The CEF FIB and adjacency table entries shown in the example can also be verified from the supervisor engine on modular switch platforms, such as the 6500 series switches. This step is not necessary on fixed configuration switches, such as the 3560.

To display an FIB entry for the specific network from the supervisor engine:

Console> (enable) show mls entry cef ip 192.168.150.0/24
Mod FI-Type Destination-IP Destination-Mask NextHop-IP Weight
--------------------------------------------------------------
15 resolved 192.168.150.0 255.255.255.255 192.168.199.3 1
To display an FIB entry for the specific network from the supervisor engine:
Console> (enable) show mls entry cef ip 192.168.150.0/24 adjacency
Mod:15
Destination-IP : 192.168.199.3 Destination-Mask : 255.255.255.255
FIB-Type : resolved

AdjType NextHop-IP NextHop-Mac VLAN Encp TX-Packets
--------------------------------------------------------------
connect 192.168.199.3 00-30-71-50-68-00 199 ARPA 0

४.4Inter-VLAN Routing Lab Exercises

4.4.1 Lab 4-1 Inter-VLAN Routing with an External Router

Lab Activity

Lab Exercise: Lab 4-1 Inter-VLAN Routing with an External Router

This lab configures inter-VLAN routing using an external router, also known as a router-on-a-stick.

4.4.2 Lab 4-2 Inter-VLAN Routing with an Internal Route Processor and Monitoring CEF Functions

Lab Activity

Lab Exercise: Lab 4-2 Inter-VLAN Routing with an Internal Route Processor and Monitoring CEF Functions

This lab routes between VLANs using a 3560 switch with an internal route processor using Cisco Express Forwarding (CEF)

Module Sumary

The configuration of multiple VLANs usually requires that Layer 3 routing occurs between those VLANs. This inter-VLAN routing can be provided external to a Layer 2 switch or within a multilayer switch through the configuration of Switch Virtual Interfaces (SVIs) and IP routing. When routing occurs within a Cisco Catalyst multilayer switch, Cisco Express Forwarding (CEF) is deployed to facilitate Layer 3 switching through hardware-based tables, providing an optimal packet-forwarding process.

Modulo 4-Implementing Inter-VLAN Routing.Parte2

2009-08-10T22:35:00.000-07:00

4.2 Enabling Routing Between VLANs

4.2.1 Describing Layer 3 SVI

An SVI is a virtual Layer 3 interface that can be configured for any VLAN that exists on a Layer 3 switch. It is virtual in that there is no physical interface for the VLAN, and yet it can accept configuration parameters applied to Layer 3 router interfaces. The SVI for the VLAN provides Layer 3 processing for packets from all switch ports associated with that VLAN. Only one SVI can be associated with a VLAN. You configure an SVI for a VLAN for the following reasons:

To provide a default gateway for a VLAN so that traffic can be routed between VLANs
To provide fallback bridging if it is required for non-routable protocols
To provide Layer 3 IP connectivity to the switch
To support routing protocol and bridging configurations

By default, an SVI is created for the default VLAN (VLAN1) to permit remote switch administration. Additional SVIs must be explicitly created.

SVIs are created the first time a VLAN interface configuration mode is entered for a particular VLAN SVI. The VLAN corresponds to the VLAN tag associated with data frames on an Ethernet trunk or to the VLAN ID (VID) configured for an access port. An IP address is assigned in interface configuration mode to each VLAN SVI that is to route traffic off of and on to the local VLAN.

4.2.2 Describing Configuration Commands for Inter-VLAN Communication on a Multilayer Switch

The commands in Figure are used to configure inter-VLAN routing on a multilayer switch using SVIs. These commands are described in Figure .

4.2.3 Configuring Inter-VLAN Routing on a Multilayer Switch

To configure inter-VLAN routing on a Cisco Catalyst SVI, perform the steps in Figure . Figure describes each of these steps.

4.2.4 Describing Routed Ports on a Multilayer Switch

A routed switch port is a physical switch port on a multilayer switch that is capable of Layer 3 packet processing. A routed port is not associated with a particular VLAN, as contrasted with an access port or SVI.

The switch port functionality is removed from the interface. A routed port behaves like a regular router interface, except that it does not support VLAN subinterfaces. Routed switch ports can be configured using most commands applied to a physical router interface, including the assignment of an IP address and the configuration of Layer 3 routing protocols.

A routed switch port is a standalone port that is not associated with a VLAN, whereas an SVI is a virtual interface that is associated with a VLAN. SVIs generally provide Layer 3 services for devices connected to the ports of the switch where the SVI is configured. Routed switch ports can provide a Layer 3 path into the switch for a number of devices on a specific subnet, all of which are accessible from a single physical switch port.

The number of routed ports and SVIs that can be configured on a switch is not limited by software. However, the interrelationship between these interfaces and other features configured on the switch may overload the CPU because of hardware limitations.

4.2.5 Configuration of Routed Ports on a Multilayer Switch

Routed switch ports are typically configured by removing the Layer 2 switch port capability of the switch port. On most switches, the ports are Layer 2 ports by default. On some switches, the ports are Layer 3 ports by default. The layer at which the port functions determines the commands that can be configured on the port.

A routed port has the following characteristics and functions:

Physical switch port with Layer 3 capability
Not associated with any VLAN
Serves as the default gateway for devices out that switch port
Layer 2 port functionality must be removed before it can be configured

4.2.6 Configuring Routed Ports on a Multilayer Switch

To configure a routed port, perform the steps in Figure . Figure describes each of these steps.

4.3 Deploying CEF-Based Multilayer Switching

4.3.1 Explaining Layer 3 Switch Processing

Layer 3 switching refers to a class of high performance routers optimized for the campus LAN or intranet, providing both wire-speed Ethernet routing and switching services.

A Layer 3 switch router performs the following three major functions:

Packet switching
Route processing
Intelligent network services

Compared to other routers, Layer 3 switch routers process more packets faster by using ASIC hardware instead of microprocessor-based engines. Layer 3 switch routers also improve network performance with two software functions: route processing and intelligent network services.

Layer 3 switching software employs a distributed architecture in which the control path and data path are relatively independent. The control path code, such as routing protocols, runs on the route processor, whereas most of the data packets are forwarded by the Ethernet interface module and the switching fabric.

Each interface module includes a microcoded processor that handles all packet forwarding. The control layer functions between the routing protocol and the firmware datapath microcode with the following primary duties:

Manages the internal data and control circuits for the packet-forwarding and control functions
Extracts the other routing and packet forwarding-related control information from the Layer 2 and Layer 3 bridging and routing protocols and the configuration data, and then conveys the information to the interface module to control the datapath
Collects the datapath information, such as traffic statistics, from the interface module to the route processor
Handles certain data packets sent from the Ethernet interface modules to the route processor

Layer 3 switching can occur at two different locations on the switch:

Centralized: Switching decisions are made on the route processor by a central forwarding table, typically controlled by an ASIC.
Distributed: Switching decisions are made on a port or line-card level. Cached tables are distributed and synchronized to various hardware components so that processing can be distributed throughout the switch chassis.

Layer 3 switching uses one of these two methods, depending on the platform:

Route caching: Also known as flow-based or demand-based switching, a Layer 3 route cache is built in hardware, since the switch sees traffic flow into the switch.
Topology-based: Information from the routing table is used to populate the route cache regardless of traffic flow. The populated route cache is called the forwarding information base (FIB). CEF builds the FIB.

4.3.2 Explaining CEF-based Multilayer Switches

Cisco Layer 3 devices can use a variety of methods to switch packets from one port to another. The most basic method of switching packets between interfaces is called process switching. Process switching moves packets between interfaces on a scheduled basis, based on information in the routing table and the Address Resolution Protocol (ARP) cache. As packets arrive, they are put in a queue to wait for further processing. When the scheduler runs, the outbound interface is determined, and the packet is switched. Waiting for the scheduler introduces latency.

To speed the switching process, strategies exist to switch packets on demand as they arrive and to cache the information necessary to make packet-forwarding decisions.

CEF uses these strategies to expediently switch data packets to their destination. It caches information generated by the Layer 3 routing engine. CEF caches routing information in one table (the FIB), and caches Layer 2 next-hop addresses for all FIB entries in an adjacency table. Because CEF maintains multiple tables for forwarding information, parallel paths can exist and enable CEF to load balance per packet.

CEF operates in one of two modes.

Central CEF: The FIB and adjacency tables reside on the route processor, and the route processor performs the express forwarding. Use this mode when line cards are not available for CEF switching, or when features are not compatible with distributed CEF.
Distributed CEF (dCEF): Supported only on Cisco Catalyst 6500 switches. Line cards maintain identical copies of the FIB and adjacency tables. The line cards can perform the express forwarding by themselves, relieving the main processor of being involved in the switching operation. Distributed CEF uses an interprocess communications (IPC) mechanism to ensure that the FIBs and adjacency tables are synchronized on the route processor and line cards.

There is a wide range of CEF-based Cisco multilayer switches:

Catalyst 2970
Catalyst 3550
Catalyst 3560
Catalyst 3750
Catalyst 4500
Catalyst 4948
Catalyst 6500

The Cisco Catalyst 6500 is a modular switch in which the Multilayer Switch Feature Card (MSFC) is responsible for control-plane operations, and the supervisor Policy Feature Card (PFC) is responsible for the data-plane operations.

4.3.3 Identifying the Multilayer Switch Packet Forwarding Process

CEF separates the control plane hardware from the data plane hardware and switching. ASICs separate the control plane and data plane, thereby achieving higher data throughput. The control plane is responsible for building the FIB and adjacency tables in software. The data plane is responsible for forwarding IP unicast traffic using hardware.

When traffic cannot be processed in hardware, the traffic must receive processing in software by the Layer 3 engine, thereby not receiving the benefit of expedited hardware-based forwarding. A number of different packet types may force the Layer 3 engine to process them. Some examples of IP exception packets are the following :

IP packets that use IP header options. (Packets that use TCP header options are switched in hardware because they do not affect the forwarding decision.)
Packets that have an expiring IP Time to Live (TTL) counter.
Packets that are forwarded to a tunnel interface.
Packets that arrive with non-supported encapsulation types.
Packets that are routed to an interface with non-supported encapsulation types.
Packets that exceed the maximum transmission unit (MTU) of an output interface and must be fragmented.

CEF-based tables are initially populated and used as follows :

The FIB is derived from the IP routing table and is arranged for maximum lookup throughput.
The adjacency table is derived from the ARP table, and it contains Layer 2 rewrite (MAC) information for the next hop.
CEF IP destination prefixes are stored in the TCAM table, from the most specific to the least specific entry.
When the CEF TCAM table is full, a wildcard entry redirects frames to the Layer 3 engine.
When the adjacency table is full, a CEF TCAM table entry points to the Layer 3 engine to redirect the adjacency.
The FIB lookup is based on the Layer 3 destination address prefix (longest match).

The FIB table is updated when the following occurs:

An ARP entry for the destination next hop changes, ages out, or is removed.
The routing table entry for a prefix changes.
The routing table entry for the next hop changes.

These are the basic steps for initially populating the adjacency table:

Step 1	The Layer 3 engine queries the switch for a physical MAC address.
Step 2	The switch selects a MAC address from the chassis MAC range and assigns it to the Layer 3 engine. This MAC address is assigned by the Layer 3 engine as a burned-in address for all VLANs and is used by the switch to initiate Layer 3 packet lookups.
Step 3	The switch installs wildcard CEF entries, which point to drop adjacencies (for handling CEF table lookup misses).
Step 4	The Layer 3 engine informs the switch of its interfaces participating in MLS (MAC address and associated VLAN). The switch creates the (MAC, VLAN) Layer 2 CAM entry for the Layer 3 engine.
Step 5	The Layer 3 engine informs the switch about features for interfaces participating in MLS.
Step 6	The Layer 3 engine informs the switch about all CEF entries related to its interfaces and connected networks. The switch populates the CEF entries and points them to Layer 3 engine redirect adjacencies.

Only the first few packets for a connected destination reach the Layer 3 engine so that the Layer 3 engine can use ARP to locate the host. A throttling adjacency is installed so that subsequent packets to that host are dropped in hardware until an ARP response is received. The throttling adjacency is removed when an ARP reply is received (and a complete rewrite adjacency is installed for the host). The switch removes the throttling adjacency if no ARP reply is seen within 2 seconds to allow more packets through to reinitiate ARP. This relieves the Layer 3 engine from excessive ARP processing or from ARP-based denial of service attacks.

Figure provides an example of ARP throttling, which consists of these steps:

Step 1	Host A sends a packet to host B.
Step 2	The switch forwards the packet to the Layer 3 engine based on the “glean” entry in the FIB. A glean adjacency entry indicates that a particular next hop should be directly connected, but there is no MAC header rewrite information available.
Step 3	The Layer 3 engine sends an ARP request for host B and installs the drop adjacency for host B. At this point, subsequent frames destined for host B from host A are dropped (ARP throttling).
Step 4	Host B responds to the ARP request. The Layer 3 engine installs an adjacency for host B and removes the drop adjacency.

The adjacency table is populated as adjacencies are discovered. Each time an adjacency entry is created (such as through the ARP protocol) a link-layer header for that adjacent node is pre-computed and stored in the adjacency table. After a route is determined, it points to a next hop and corresponding adjacency entry. The route is subsequently used for encapsulation during CEF switching of packets.

A route might have several paths to a destination prefix, as when a router is configured for simultaneous load balancing and redundancy. For each resolved path, a pointer is added for the adjacency corresponding to the next-hop interface for that path. This mechanism is used for load balancing across several paths.

In addition to adjacencies associated with next-hop interfaces (host-route adjacencies), other types of adjacencies are used to expedite switching when certain exception conditions exist. When the prefix is defined, prefixes requiring exception processing are cached with one of the following special adjacencies:

Null adjacency: Packets destined for a null0 interface are dropped. This can be used as an effective form of access filtering.
Glean adjacency: When a router is connected directly to several hosts, the FIB table on the router maintains a prefix for the subnet rather than for the individual host prefixes. The subnet prefix points to a glean adjacency. When packets need to be forwarded to a specific host, the adjacency database is gleaned for the specific prefix.
Punt adjacency: Features that require special handling, or features that are not yet supported in conjunction with CEF switching paths, are forwarded to the next switching layer for handling. For example, the packet may require CPU processing. Features that are not supported are forwarded to the next-higher switching level.
Discard adjacency: Packets are discarded.
Drop adjacency: Packets are dropped, but the prefix is checked.

When a link-layer header is appended to packets, FIB requires the appended header to point to an adjacency corresponding to the next hop. If an adjacency was created by FIB and not discovered through a mechanism such as ARP, the Layer 2 addressing information is not known, and the adjacency is considered incomplete. The packet is forwarded to the route processor where an ARP request would be used to find the Layer 2 information and complete the adjacency.

These are the steps that would occur when you use CEF to forward frames between host A and host B on different VLANs:

Step 1	Host A sends a packet to host B. The switch recognizes the frame as a Layer 3 packet because the destination MAC (MAC-M) matches the Layer 3 engine MAC.
Step 2	The switch performs a CEF lookup based on the destination IP address (IP-B). The packet hits the CEF entry for the connected (VLAN20) network and is redirected to the Layer 3 engine using a glean adjacency.
Step 3	The Layer 3 engine installs an ARP throttling adjacency in the switch for the host B IP address.
Step 4	The Layer 3 engine sends ARP requests for host B on VLAN20.
Step 5	Host B sends an ARP response to the Layer 3 engine.
Step 6	The Layer 3 engine installs the resolved adjacency in the switch (removing the ARP throttling adjacency).
Step 7	The switch forwards the packet to host B.
Step 8	The switch receives a subsequent packet for host B (IP-B).
Step 9	The switch performs a Layer 3 lookup and finds a CEF entry for host B. The entry points to the adjacency with rewrite information for host B.
Step 10	The switch rewrites packets per the adjacency information and forwards the packet to host B on VLAN20.

Modulo 4-Implementing Inter-VLAN Routing

2009-08-10T22:23:00.000-07:00

Module 4: Implementing Inter-VLAN Routing

Module Overview

A switch with multiple VLANs requires a means of passing Layer 3 traffic between those VLANs. This module describes the process and methods of routing traffic from VLAN to VLAN. A router that is external to the Layer 2 switch hosting the VLANs can provide the inter-VLAN routing. When routing occurs within a Catalyst multilayer switch, Cisco Express Forwarding (CEF) is deployed to facilitate Layer 3 switching through hardware-based tables, providing an optimal packet forwarding process. On a multilayer switch, routing is enabled between VLANs through the configuration of switch virtual interfaces (SVIs) associated with the various VLANs on the multilayer switch.

4.1 Describing Routing Between VLANs

4.1.1 Inter-VLAN Routing Using an External Router

If a switch supports multiple VLANs but has no Layer 3 capability to route packets between those VLANs, the switch must be connected to a router external to the switch. This setup is accomplished most efficiently by providing a single trunk link between the switch and the router that can carry the traffic of multiple VLANs and which, in turn, can be routed by the router. This single physical link must be Fast Ethernet or greater to support Inter-Switch Link (ISL) encapsulation, but 802.1Q is supported on 10-Mbps Ethernet router interfaces.

In Figure , the clients on VLAN10 need to establish sessions with a server that is in VLAN20, which requires that traffic be routed between the VLANs. Figure describes the actions necessary for traffic to be routed between VLANs using an external router.

With inter-VLAN routing, the router receives frames from the switch with the source VLAN tagged (for example VLAN10). It associates the frames with the proper subinterface and then decodes the frame payload (the IP packet). The router then performs Layer 3 processing based on the destination network address contained in the IP packet to determine which subinterface should forward the IP packet. The IP packet is now encapsulated in a dot-1Q (or ISL) frame that is tagged with the VLAN identification (for example VLAN20) of the forwarding subinterface and transmitted across the trunk toward the switch.

In Figure , the router can receive packets on one VLAN and forward them to another. To perform inter VLAN routing functions, the router must know how to reach all VLANs that are being interconnected. The router must have a separate logical connection (subinterface) for each VLAN and ISL or 802.1Q trunking must be enabled on the single physical interface between the router and the switch. The routing table lists all the subnets associated with the VLANs that are configured on the router subinterfaces as directly connected. The router must learn routes to networks that are not configured on directly connected interfaces through dynamic routing protocols or static routes.

There are advantages and disadvantages of inter-VLAN routing on an external router.

The advantages are as follows:

The advantages are as follows:

Implementation is simple.
Layer 3 services are not required on the switch.
The router provides communications between VLANs.

The disadvantages are as follows:

The router is a single point of failure.
The single traffic path between the switch and the router may become congested.
- Latency is higher than on a Layer 3 switch.

4.1.2 Describing Inter-VLAN Routing Using External Router Configuration Commands

You can configure inter-VLAN routing using an external router over either ISL or 802.1Q trunks. The commands for configuring the trunk interface on the router are shown in Figure . Figure provides a description of the commands.

4.1.3 Configuring Inter-VLAN Routing Using an External Router

A router interface providing inter-VLAN routing on a trunk link must be configured with a subinterface for each VLAN that will be serviced across the link. Each subinterface on the physical link must then be configured with the same trunk encapsulation protocol. That protocol, either 802.1Q or ISL, is typically determined by what was configured on the switch side of the link.

Use the encapsulation dot1q subinterface configuration command to enable 802.1Q encapsulation on a router subinterface. The subinterface number does not have to match the dot-1Q VLAN number, but it is good practice to do so.

Since traffic on the native VLAN is not tagged, all native VLAN frames are received as normal Ethernet frames, so it is not necessary to define a specific encapsulation tag for those networks. Some versions of Cisco IOS allow for the creation of a subinterface for the native VLAN. If the native VLAN is configured as a subinterface, you should use the encapsulation dot1q native command. All other non-native VLANs have an 802.1Q tag inserted into their frames. These non-native VLANs should always be configured as subinterfaces on the router, and the VLANs must be defined as 802.1Q tagged frames and have the VLAN associated to them identified. The subinterface command encapsulation dot1q accomplishes this task.

The VLAN subnets are directly connected to the router. Routing between these subnets does not require a dynamic routing protocol, because the subnets are directly connected. Routes to the subnets associated with each VLAN appear in the routing table as directly connected interfaces.

Use the encapsulation isl vlan_id subinterface configuration command to enable ISL trunking on a router subinterface.

The native keyword is not used with the encapsulation ISL subinterface command, because ISL does not have the concept of a native VLAN.

Figure describes the actions needed to perform ISL encapsulation on external routers.

After the router is properly configured and connected to the network, the router or the switch can communicate with other nodes on the network.

To test connectivity to remote hosts, use the ping command from privileged mode :

Switch#ping destination-ip-address

Step 1 From the router, ping a host address on each VLAN to verify router connectivity.

Step 2 From a host on a particular VLAN, ping a host on another VLAN to verify routing across the external router.

The ping command returns one of these responses:

Success rate is 100 percent or ip-address is alive: This response occurs in 1 to 10 ms, depending on network traffic and the number of Internet Control Message Protocol (ICMP) packets sent.
Destination does not respond: No answer message is returned if the host does not respond.
Unknown host: This response occurs if the targeted host cannot be resolved.
Destination unreachable: This response occurs if the default gateway cannot reach the specified network or is being blocked.
Network or host unreachable: This response occurs if the Time to Live (TTL) times out. The default is 2 seconds.

Use show commands to display the current (running) configuration, IP routing information, and IP protocol information to verify whether the routing table represents the subnets of all VLANs.

Router#show vlans
Virtual LAN ID: 10 (Inter Switch Link Encapsulation)
vLAN Trunk Interface: FastEthernet0/0.10
Protocols Configured: Address: Received: Transmitted:
IP 10.10.1.1 0 20

Virtual LAN ID: 20 (Inter Switch Link Encapsulation)
vLAN Trunk Interface: FastEthernet0/0.20
Protocols Configured: Address: Received: Transmitted:
IP 10.20.1.1 0 20

Router#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 2 subnets
C 10.10.1.0 is directly connected, FastEthernet0/0.10
C 10.20.1.0 is directly connected, FastEthernet0/0.20

4.1.4 Explaining Multilayer Switching

Traditionally, a switch makes forwarding decisions by looking at the Layer 2 header, whereas a router makes forwarding decisions by looking at the Layer 3 header.

A multilayer switch combines the functionality of a switch and a router into one device, therefore enabling the device to switch traffic when the source and destination are in the same VLAN and to route traffic when the source and destination are in different VLANs (that is, different subnets).

In Figure , traffic between PC A and PC B are switched at Layer 2, whereas traffic between PC B and PC C are switched at Layer 3.

Multilayer switches forward frames and packets at wire speed by using application-specific integrated circuit (ASIC) hardware. Specific Layer 2 and Layer 3 components, such as routing tables or access control lists (ACLs), are cached into hardware. These tables are stored in content-addressable memory (CAM) and ternary content-addressable memory (TCAM).

Layer 2 forwarding in hardware is based on the destination MAC address. The Layer 2 switch learns and records the source MAC addresses from all frames that it receives. The MAC address table lists MAC addresses paired with the associated VLANs and interfaces. When a frame is received on an interface, the switch determines which VLAN the frame originated from, searches all interfaces that belong to that VLAN for the destination MAC, and forwards the frame out the appropriate interface.

Figure describes how a Layer 2 switch forwards packets.

Layer 3 forwarding is based on the destination IP address. Layer 3 forwarding occurs when a packet is routed from a source in one subnet to a destination in another subnet. When a multilayer switch (MLS) sees its own MAC address in the Layer 2 header, it recognizes that the packet is either destined for itself or is to be routed. If the packet is not destined for the MLS, the destination IP address is compared against the Layer 3 forwarding table for the longest match. In addition, router ACL checks are performed. In this case, the frame header needs to be rewritten with new source and destination MAC addresses.

Figures and describe how a Layer 3 switch forwards packets.

4.1.5 Frame Rewrite

Figure shows how the frame and packet header would be altered if CEF is used to forward frames. When frames are received on an interface, the trailer checksum is first calculated to verify accurate delivery of the frame. The frame is discarded if the calculation is not accurate. Next the payload is extracted. The IP header checksum is tested to verify that it is an accurate IP header. Once the packet is processed, IP unicast packets are rewritten on the output interface as follows:

The source MAC address changes from the sender MAC address to the router MAC address.
The destination MAC address changes from the router MAC to the next-hop MAC address.
The TTL is decremented by one and, as a result, the IP header checksum is recalculated.
The frame checksum is recalculated.

Routing, switching, ACL, and QoS tables are stored in a high-speed table memory so that forwarding decisions and restrictions can be made in high-speed hardware. Cisco Catalyst switches create and use two primary table architectures:

CAM table: Primary table used to make Layer 2 forwarding decisions. The table is built by recording the source address and inbound port of all frames. When a frame arrives at the switch with a destination MAC address of an entry in the CAM table, the frame is forwarded out only through the port associated with that specific MAC address.
TCAM table: Stores ACL, QoS, and other information generally associated with upper-layer processing.

Table lookups are done with efficient search algorithms. A “key” is created to compare the frame to the table content. For example, the destination MAC address and VLAN ID (VID) of a frame constitute the key for a Layer 2 table lookup. This key is fed into a hashing algorithm, which produces a pointer into the table. The system uses the pointer to access a smaller specific area of the table without requiring searching the entire table.

In a Layer 2 table, all bits of all information are significant for frame forwarding (for example, VLANs, destination MAC addresses, and destination protocol types). However, in more complicated tables associated with upper-layer forwarding criteria, some bits of information may be too inconsequential to analyze. For example, an ACL may require a match on the first 24 bits of an IP address, but the last 8 bits may be insignificant information.

In specific high-end switch platforms, the TCAM is a portion of memory designed for rapid, hardware-based table lookups of Layer 3 and Layer 4 information. In the TCAM, a single lookup provides all Layer 2 and Layer 3 forwarding information for frames, including CAM and ACL information.

Figure displays the ACL information stored in the TCAM table that would result in a packet being permitted or denied.

TCAM matching is based on three values: 0, 1, or X (where X is either number), hence the term “ternary.” The memory structure is broken into a series of patterns and masks. Masks are shared among a specific number of patterns and are used as wildcards in some content fields.

The following two ACL entries are referenced in Figure , which shows how their values are stored in the TCAM:

access-list 101 permit ip host 10.1.1.1 any
access-list 101 deny ip 10.1.1.0 0.0.0.255 any

The TCAM table entries in Figure consist of the following types of regions:

Longest match region: Each longest match region consists of groups of Layer 3 address entries (“buckets”) organized in decreasing order by mask length. All entries within a bucket share the same mask value and key size. The buckets can change their size dynamically by borrowing address entries from neighboring buckets. Although the size of the whole protocol region is fixed, you can reconfigure it. The reconfigured size of the protocol region takes effect only after the next system reboot.
First-match region: The first-match region consists of ACL entries. Lookup stops after the first match of the entry.

sinfonica de venezuela

2009-07-05T19:59:00.001-07:00

Sinfónica de Venezuela