Cisco CCNP SWITCH Topics

Table of Contents

Last year, I was not yet ready to take the CCIE R&S written exam, but my CCNP was about to expire. I decided to renew by taking the SWITCH exam, which had been revised since my original CCNP certification. I continued to study for the CCIE, but I focused my attention on topics that were on the SWITCH exam. As I was doing this, I was still in the middle of transitioning my learning process to using Anki, and therefore I was still taking traditional notes.

I had made this information available previously in individual Google Docs files, but have now consolidated it into this single post. If you’re looking at this information for CCNP preparation, some of it goes above and beyond what you need to learn for the exam. However, after reading the textbooks, you may receive an alternate take on some of the technologies covered here.

Please expand the Table of Contents for an overview of the covered topics.

Errdisable recovery

When an enabled cause is detected, the interface is placed into the err- disabled state and is effectively shut down. For BPDU Guard and port security, you can shut down just the offending VLAN on the port instead of shutting down the entire port. Without errdisable recovery, the port stays shut down until manually cleared with shutdown / no shutdown on the interface. With errdisable recovery, the interface can be brought out of errdisable state after all causes have timed out.

Supported causes are platform and version dependent.

Some supported causes are:

  • all
  • bpduguard
  • arp-inspection
  • channel-misconfig
  • dhcp-rate-limit
  • dtp-flap
  • gbic-invalid
  • inline-power
  • l2ptguard Layer 2 Protocol Tunnel
  • link-flap
  • loopback
  • pagp-flap
  • psecure-violation Port Security
  • psp Protocol Storm Protection
  • security-violation 802.1X violation
  • sfp-config-mismatch
  • udld
  • vmps

The timeout interval is configured separately, and applies to all causes. The default is 300 seconds, but can be configured from 30 to 86400 seconds. The recovery timer is initialized at a random differential from the configured value - the difference can be up to 15 percent of the configured value.

By default, errdisable detection is enabled for all causes. You can disable errdisable detection for any or all of the causes.

Defaults

  • Recovery is disabled for all causes
  • Detection is enabled for all causes.
  • Default recovery interval is 300 seconds

Configure

  • Configured globally
  • Cause:
    • errdisable recovery cause { all | arp-inspection | bpduguard | channel-misconfig | dhcp-rate-limit | dtp-flap | gbic-invalid | inline-power | l2ptguard | link-flap | loopback | pagp-flap | psecure-violation | psp | security-violation | sfp-mismatch | udld | vmps }
  • Interval:
    • errdisable recovery interval SECONDS
  • Optionally disable an errdisable cause:
    • no errdisable detect cause {all | bpduguard | dtp-flap | l2ptguard | link-flap | packet-buffer-error | pagp-flap | rootguard | udld}

Verify

  • Display error-disabled recovery timer information:
    • show errdisable recovery
  • Display interface status or a list of interfaces in err-disabled state:
    • show interfaces status err-disabled
  • Clear the error-disabled state from a port or VLAN that was error disabled by the per-VLAN error disable feature:
    • clear errdisable interface
  • Display the error-disable detection status:
    • show errdisable detect

Links

Describe SDM Templates

SDM (Switch Database Management) templates are used to optimize system resources on certain switch platforms depending on how the switches will be used in the network. The default template attempts to balance all resources, while individual templates allocate more of a specific resource at the expense of having fewer other resources available in the TCAM. When a particular resource is full, all processing overflow is sent to the CPU for processing which seriously impacts switch performance.

Available templates are:

  • Access (IPv4): Maximizes resources for ACLs
  • Default (IPv4): Provides balance to all functions
  • Routing (IPv4): Maximizes routing on the switch
  • VLAN (IPv4): Maximizes VLAN configuration on the switch with NO routing supported in hardware
  • Default (Dual): Balances IPv4 and IPv6 Layer 2 and Layer 3 functionality
  • VLAN (Dual): Provides maximum usage for IPv4 and IPv6 VLANs
  • Routing (Dual): Provides maximum usage for IPv4 and IPv6 routing, including IPv4 PBR
  • Indirect IPv4 and IPv6 routing: Maximizes IPv4 and IPv6 entries for indirect routes

Changing the template changes the available resources for a particular function. For example, the “Access” template allows you to configure 2000 secure ACEs, compared to the other templates which only support 1000. Likewise, the “Routing” template supports 11,000 unicast routes, compared to the default of 8,000 routes. The tradeoff with the “Routing” template is that it supports fewer unicast MAC address entries than the “default” template.

Switches running the “LAN Base” feature set will show values higher than what are actually supported by the license. For example, the templates show 1024 VLANs, but the LAN Base license only supports 255 VLANs.

Switches in a stack use the template setting on the master switch. If the master is using a template that is not supported by one of the stack members, the member goes into “SDM mismatch” mode and the switch cannot be a functioning member of the stack.

Defaults

  • The “default” template is assigned by default, which attempts to evenly balance all available system resources.

Configure

  • When changing the SDM template on a switch, the switch must be reloaded before the template takes effect.
  • Change the template globally:
    • sdm prefer TEMPLATE
  • Save and reload the switch for the settings to take effect:
    • copy run start
    • reload
  • To reset the switch back to the default SDM template, issue no sdm prefer and reload.

Verify

  • Display the current active template:
    • show sdm prefer
  • Display the resource numbers supported by the specified template
    • show sdm prefer TEMPLATE

Links

CDP

CDP is a Layer 2 device discovery protocol that runs on all Cisco-manufactured devices to allow network management applications to discover Cisco devices that are neighbors of already known devices. You can discover the type of device, and the IP address used for SNMP. CDP runs on all media that supports SNAP (Sub Network Access Protocol). Since CDP is Layer 2, two physically connected devices running different network layer protocols can still learn about each other.

Each device configured for CDP advertises at least one address at which the device can receive messages, and sends periodic advertisement messages to the well-known multicast address 0100.0CCC.CCCC. Devices discover each other by listening to that addresses, and they also listen to messages to learn when interfaces on other devices are up or go down.  

Advertisements contain TTL information to indicate the length of time a receiving device should hold the CDP information before discarding it. Advertisements are sent every 60 seconds by default. The received information is stored in a table and refreshed every time an advertisement is received. The information is removed from the table after three successive advertisements from the device are missed.

The information contained in the CDP advertisements varies based on the type of device and installed version of its operating system. Some of the information that can be learned includes the version of the OS running on the device, the hardware platform, IP addresses of interfaces, locally-connected devices advertising CDP, active interfaces including encapsulation type, hostname, duplex setting, VTP domain, native VLAN, and others.

CDP advertisements contain embedded TLV information. The TLV definitions for CDPv2 include:

  • Address: contains network addresses of both receiving and sending devices
  • Application: provides a mechanism to send an application-specific TLV through CDP
  • Appliance VLAN: the Voice VLAN setting
  • Capabilities: identifies the device type which indicates the functional capability of the device
  • Class of Service: describes L2 CoS value in a CDP packet
  • Device-ID: identifies the device in the form of a character string
  • Duplex: indicates the duplex configuration of the CDP broadcast interface which can be used to diagnose connectivity problems
  • EnergyWise: for negotiation of power-related parameters such as for IP phones and wireless access points
  • Extended Trust: trusts the CoS markings in incoming frames
  • IP Network Prefix: list of network prefixes to which a sending device can forward IP packets - includes the interface and port number
  • Location: delivers location-based information to endpoint devices such as Civic location (physical street address) and ELIN location which provides the location information of a caller for emergency services
  • Location-Server: mechanism for location servers to transfer the required information to neighboring devices
  • Native VLAN: indicates per interface
  • Platform: identifies hardware platform of the device
  • Port-ID: identifies the port on which.a CDP packet is sent
  • Power Available:  includes Request-ID field, Available Power, Power Management-ID, Management Power Level fields
  • Protocol Hello: Different protocols may piggyback their Hellos within a CDP message
  • Version: device software release information
  • VTP Management Domain: identifies VTP domain configured on the system

Secure CDP allows you to disable the advertisement of all of the individual TLVs except for Address and Device ID.

Defaults

  • CDP is enabled by default.
  • CDPv2 advertising is enabled by default.
  • The default advertisement interval is 60 seconds.
  • The default hold time is 180 seconds.

Configure

  • CDP is enabled by default. You can disable it globally with no cdp run however even after running this command, CDP will be reenabled automatically on interfaces if the encapsulation type changes (such as from HDLC to PPP)
  • You can disable CDP on individual interfaces with no cdp enable though it will be reenabled automatically if the encapsulation type changes
  • Adjust the advertisement interval and holdtime:
    • cdp timer SECONDS
    • cdp holdtime SECONDS
  • Disable CDPv2 advertisements globally:
    • no cdp advertise-v2
  • Disable logging of duplex mismatches for Ethernet interfaces globally or at the interface:
    • no cdp log mismatch duplex
  • Specify a source interface for CDP advertisements to ensure CDP reports the desired IP address to neighbors:
    • cdp source-interface INTERFACE
  • Secure CDP Configuration:
    • Globally create TLV list:
      • cdp tlv-list NAME
        • Add the TLVs you wish to filter out to the list, such as ip- prefix or hello-protocol
    • Apply the filter list either globally or at the interface level:
      • cdp filter-tlv-list NAME
        • Filter lists applied at the interface take precedence over lists applied globally

Verify

  • Display global CDP information including timers and v2 status:
    • show cdp
  • Display information about a specific CDP neighbor (or all neighbors by using *):
    • show cdp entry {* | DEVICE-ID}
  • Display L2 encapsulation type and timers of individual interfaces:
    • show cdp interface [INTERFACE]
  • Display information about detected neighbors:
    • show cdp neighbors [detail]
      • The detail keyword is similar to show cdp entry and displays more information about the CDP neighbors
  • Display the current CDP counters:
    • show cdp traffic
  • Display the contents of the CDP TLV-list:
    • show cdp tlv-list
  • Reset the statistics gathered by CDP:
    • clear cdp counters
  • Remove all neighbors from the CDP neighbor table. Neighbors will be re- discovered during their next advertisement interval.
    • clear cdp table

Links

LLDP

LLDP is designed to be the open equivalent to CDP and offers much of the same functionality. IEEE ratified LLDP as 802.1AB, and is designed for multi-vendor environments. A common use case for using LLDP is to set voice VLANs on Cisco switches when using non-Cisco IP phones. LLDP-MED (Media Endpoint Discovery) is an enhancement by the TIA for VoIP applications. Like CDP, LLDP is a Layer 2 protocol and devices can learn about each other regardless of the Layer 3 protocol being used on the device.

LLDP is unidirectional and only operates in advertising mode - there is no solicitation of information or monitoring of state changes between LLDP nodes. Advertisements are sent every 30 seconds by default to 0180.c200.000e with EtherType 0x88cc, or they may be encapsulated within a SNAP LLC frame. Devices can turn off send or receive functions independently. CDP and LLDP can operate simultaneously on the same interface.

LLDP attributes are described in TLVs, with the following being mandatory: Port description, System name, System description, System capabilities, Management address. LLDP-MED also includes Port VLAN ID and MAC/PHY configuration/status. By default, network connectivity devices such as routers and switches only send out LLDP packets until they receive LLDP-MED packets from an endpoint device, upon which time they start sending out LLDP-MED packets until they stop receiving LLDP-MED packets from the endpoint.

LLDP-MED defines three classes of endpoints:

  • Class 1 Generic - example IP communications controllers
  • Class 2 Media - endpoints that support media streams such as media gateways and conference bridges
  • Class 3 Communication Device - endpoints that support IP communications such as IP phones

Defaults

  • LLDP is disabled by default.
  • The default holdtime is 120 seconds.
  • LLDP waits 2 seconds before initialization by default.
  • LLDP updates are sent every 30 seconds by default.
  • All TLVs are sent and received by default.

Configure

  • Enable LLDP globally:
    • lldp run
  • Optionally disable LLDP on specific interfaces:
    • no lldp {med-tlv-select TLV | receive | transmit}
      • Where you can select individual TLVs that you wish to not advertise
  • Optionally adjust the LLDP hold time globally:
    • lldp holdtime SECONDS
  • Optionally adjust the LLDP advertisement frequency globally:
    • lldp timer SECONDS
  • Optionally enable specific TLVs to be advertised on an interface:
    • lldp tlv-select TLV-NAME

Verify

  • Display LLDP status and timer settings:
    • show lldp
  • Display information about LLDP neighbors:
    • show lldp neighbors [interface | detail]
  • Display information about a specific LLDP neighbor:
    • show lldp entry NEIGHBOR-ID
  • Display interface-related information about LLDP:
    • show lldp interface INTERFACE
  • Display LLDP statistics:
    • show lldp traffic
  • Display LLDP errors:
    • show lldp errors
  • Reset the LLDP statistics:
    • clear ldp counters
  • Reset the LLDP neighbor information (information will be re-learned in the next advertisement period):
    • clear lldp table

Links

UDLD

Unidirectional Link Detection operates over Layer 2 and enables interfaces connected with fiber optic or twisted-pair Ethernet cables to monitor the physical configuration and detect when a unidirectional link exists. UDLD must be supported on all connected devices to successfully identify and disable unidirectional links. Unidirectional links can be responsible for many networking issues, including Spanning Tree topology loops.

UDLD supports normal (default) and aggressive modes. Normal mode detects unidirectional links due to misconnected fiber optic ports. Aggressive mode can also detect unidirectional links due to one-way traffic on both fiber optic and twisted-pair links. UDLD works with Layer 1 mechanisms to learn the physical status of a link. Layer 1 autonegotiation takes care of physical signaling and fault detection, while UDLD performs tasks that autonegotiation cannot do, such as detecting the identities of neighbors and shutting down misconnected ports. With the combination of autonegotiation and UDLD, Layer 1 and Layer 2 detections work together to prevent both physical and logical unidirectional connections which leads to the malfunctioning of other protocols.

With normal mode, if the fiber strands are misconnected but Layer 1 does not detect the issue, UDLD will detect this and shut down the interface. However, if the fiber strands are connected properly, but traffic is still unidirectional, UDLD in normal mode will not detect the issue and the port will remain enabled. UDLD in aggressive mode can additionally detect on both fiber optic and twisted pair when one of the ports cannot send or receive traffic, or one of the ports is up while the other is down.

For point-to-point links, UDLD uses hello packets as a heartbeat, which are sent to the well-known MAC address 0100.0CCC.CCCC. UDLD learns about other UDLD- capable neighbors by sending a probe every 15 seconds by default, which contains its own Device ID along with the originator Port ID and timeout value. When the switch receives a hello message, it caches the information until the hold time expires. If the switch receives a new hello before the old entry expires, it replaces the old entry with the new one. UDLD relies on echoing for its detection mechanism. When a UDLD device learns about a neighbor or receives a resync request from an out-of-sync neighbor, it restarts the detection window on its side of the connection and sends echo messages in response. The sender of an echo expects to receive an echo in reply. If the detection window ends and no valid reply is received, the link might shut down depending on the UDLD mode. The link is always shut down in aggressive mode, but in normal mode the link status might be considered undetermined in which case it remains up. In aggressive mode, when the switch loses its neighbor, it tries to re-establish the relationship by sending 8 UDLD frames during 1 second, and err-disables the port if no response is received.

UDLD is designed to work with STP Loop Guard.

Defaults

  • UDLD is globally disabled by default.
  • UDLD normal (non-aggressive) mode is the default.
  • The default probe interval is 15 seconds.

Configure

  • Enable UDLD globally:
    • udld {enable | aggressive}
      • Running this command enables UDLD on all fiber-optic interfaces, but must still be enabled at the interface level for other port types.
  • Enable UDLD on an interface:
    • udld port [aggressive]
      • Required for non-fiber optic ports. Interface configurations override global. Use the no form to disable UDLD on the interface.
  • Optionally change the UDLD probe message interval globally:
    • udld message time SECONDS
      • This timer affects probe messages for ports that are in the advertisement phase and are determined to be bidirectional.
  • Reset an interface disabled by UDLD:
    • udld reset

Verify

  • Display administrative, operational, and bidirectional state of UDLD:
    • show udld [interface INTERFACE]
  • Display information about detected UDLD neighbors:
    • show udld neighbors

Links

EtherChannel Misconfiguration Guard

Helps protect against improperly configured EtherChannels by assuming all BPDUs received in an EtherChannel must have the same source MAC, and err-disabling the interfaces when a misconfiguration is detected. A misconfiguration can occur if the switch interfaces are configured in an EtherChannel, but the interfaces on the other device are not, or if the channel parameters (such as protocol) are not the same on both ends of the link.

If the interfaces become err-disabled, you can re-enable them with errdisable recovery, or manually shut/no shut the interfaces.

Defaults

  • EtherChannel misconfig guard is enabled on the switch by default.

Configure

  • Enabled by default, but can be disabled globally with:
    • no spanning-tree etherchannel guard misconfig
  • Optionally automatically recover ports errdisabled from a misconfiguration:
    • errdisable recovery cause channel-misconfig

Verify

  • Display global state of EtherChannel misconfig guard:
    • show spanning-tree summary
  • Display which switch ports are in the misconfigured EtherChannel:
    • show interfaces status err-disabled
  • Display EtherChannel information:
    • show etherchannel summary

Links

PortFast (and RSTP Edge ports)

PortFast is used to immediately bring an interface from blocking to the forwarding state, bypassing the forward delay (listening/learning). This technology is designed for ports, both access and trunk, that connect to end devices that do not participate in the Spanning-Tree topology. Interfaces configured for PortFast are not expected to receive BPDUs from the connected devices. An interface with PortFast enabled does go through the normal cycle of Spanning-Tree status changes when the switch is restarted.

With RSTP, Edge ports do not generate TCNs.

Defaults

  • PortFast is disabled by default, however it will be enabled automatically on ports negotiated as dynamic access.

Configure

  • You can globally enable PortFast on all non-trunking ports with:
    • spanning-tree portfast default
  • Alternatively, you can enable PortFast on individual interfaces. This is a requirement for trunk ports:
    • spanning-tree portfast [trunk]
  • If PortFast is enabled globally, you can disable it on individual interfaces:
    • spanning-tree portfast disable
  • NOTE: When you enable the Voice VLAN feature, PortFast is enabled automatically. However, when you disable the Voice VLAN, PortFast is not automatically disabled.

Verify

  • Display the global state of PortFast:
    • show spanning-tree summary
  • Display which VLANs have PortFast enabled on a particular interface:
    • show spanning-tree interface INTERFACE portfast

Links

UplinkFast

UplinkFast enables classic 802.1D STP to immediately use an Alternate port for forwarding when the existing Root port experiences a direct failure, instead of having to wait for the Forwarding Delay. A topology change notification is also sent. UplinkFast is designed for use on access-layer switches.

UplinkFast cannot be enabled on VLANs that have been configured with a switch priority. Any VLANs that have had their STP priority modified will not be enabled for UplinkFast. When UplinkFast is enabled, the switch priority of all VLANs is changed to 49152 + the System ID Extension, except for those VLANs whose priority has been manually configured, which have no effect. The path cost is also increased by 3000 if the existing cost was less than 3000. If the path cost was already 3000 or above, it is not altered. The changes to the priority and cost are to reduce the chance of the switch becoming Root. When disabling UplinkFast, the priorities and costs are reset to their defaults, if they were not manually modified from their defaults.

When the switch loses its Root port and switches to the Alternate as a result of having UplinkFast configured, the switch sends dummy multicast frames to 0100.0ccd.cdcd for each entry in its CAM table, with each entry being the source address. The goal is to update the upstream switches with the new path to reach those connected stations. The default rate is 150 pps.

When the switch is in Rapid-PVST+ or MST mode, you can configure UplinkFast, but the feature remains disabled until the switch is changed to PVST+ mode.

Do not enable Root Guard on interfaces that will be used with UplinkFast. If Root Guard is enabled, the backup interface will be placed into Root Inconsistent state and blocked if the existing Root port fails.

Defaults

  • UplinkFast is disabled by default.
  • UplinkFast has a default station-learning message rate of 150 pps.

Configure

  • Enable globally:
    • spanning-tree uplinkfast [max-update-rate PPS]
      • If the rate is set to 0, station-learning frames are not generated which causes the Spanning-Tree topology to converge more slowly after loss of connectivity.

Verify

  • Display the global state of UplinkFast:
    • show spanning-tree summary

Links

BackboneFast

BackboneFast is complementary to UplinkFast and enables classic 802.1D STP to detect indirect failures in the core. BackboneFast optimizes the MaxAge timer so that when a switch receives an inferior BPDU from the Designated port of another switch, which indicates that the other switch may have lost its path to the Root, BackboneFast tries to find an alternate path to the Root. BackboneFast must be enabled on all switches in the network.

BackboneFast starts when a Root or Alternate port receives inferior BPDUs from the upstream Designated switch. Inferior BPDUs indicate the upstream switch is declaring itself as both Root bridge and Designated switch, which means the upstream switch lost its connection to the Root bridge. This is how BackboneFast can detect indirect failures. Normally, the switch will ignore the received inferior BPDUs until the MaxAge timer expires.

If the inferior BPDU arrives on a blocked interface, the Root port and other blocked interfaces become alternate paths to the Root switch. If the inferior BPDU arrives on the Root port, all blocked interfaces become alternate paths to the Root switch. If the inferior BPDU arrives on the Root port and there are no blocked interfaces, the switch assumes connectivity to the Root has been lost, and causes the MaxAge timer to expire, and the switch becomes Root according to normal Spanning-Tree operation.

If the switch has alternate paths to the Root, a RLQ Root Link Query request is sent across the paths, and waits for a RLQ reply from the other switches. When a switch receives a RLQ reply from another switch on a blocked interface and the reply is destined for a different switch, it forwards the reply packet regardless of the Spanning-Tree interface state.

If the switch discovers it still has an alternate path to the Root, the MaxAge timer is expired for the interface that received the inferior BPDU. If all alternate paths to the Root indicate the switch has lost connectivity to the Root, the MaxAge is expired on the port that received the RLQ reply. If one or more alternate paths can still connect to the Root, the switch makes all interfaces on which it received an inferior BPDU its Designated ports and moves them from Blocking to Listening/Learning and finally Forwarding.

When the switch is in Rapid-PVST+ or MST mode, you can configure BackboneFast, but the feature remains disabled until the switch is changed to PVST+ mode.

Defaults

  • BackboneFast is disabled by default.

Configure

  • Enable globally:
    • spanning-tree backbonefast

Verify

  • Display global state of BackboneFast:
    • show spanning-tree summary

Links

BPDUguard

This feature can be enabled globally or per-port. Global configuration enables BPDU Guard only on ports also configured with PortFast enabled.

When enabled globally with spanning-tree portfast bpduguard default Spanning- Tree will errdisable ports operating with PortFast enabled if a BPDU is received on the port. The entire interface is errdisabled by default, but you can configure it to just shut down the offending VLAN on the port with errdisable detect cause bpduguard shutdown vlan.

When enabled on the individual interface with spanning-tree bpduguard enable PortFast is not required and the interface is placed into errdisable mode upon receipt of a BPDU.

BPDU Guard is commonly used for service providers to prevent customer access ports from participating in the Spanning-Tree topology.

Defaults

  • BPDU Guard is disabled by default.

Configure

  • Enable BPDU Guard globally for all ports that are also running PortFast:
    • spanning-tree portfast bpduguard default
  • BPDU Guard can be enabled on individual interfaces with or without PortFast:
    • spanning-tree bpduguard enable
  • BPDU Guard can be disabled on individual interfaces:
    • spanning-tree bpduguard disable
  • Configure BPDU Guard to only shut down the offending VLAN instead of the entire interface:
    • errdisable detect cause bpduguard shutdown vlan

Verify

  • Display global state of BPDU Guard:
    • show spanning-tree summary

Links

BPDUfilter

BPDU Filtering can be enabled globally or per-port. When enabled globally, only PortFast-enabled ports will be filtered by default.

When enabled globally with spanning-tree portfast bpdufilter default interfaces that are enabled for PortFast will not send or receive BPDUs, with the exception of sending 11 BPDUs when the link first comes up, before filtering outbound BPDUs. You should enable BPDU Filter globally so that hosts connected to PortFast ports do not receive BPDUs. If a BPDU is received on a PortFast- enabled interface, the port loses its PortFast operational status, and BPDU Filtering is disabled. One of the use cases for enabling BPDU Filtering globally is that host-facing ports should not receive BPDUs.

When enabled on the individual interface with spanning-tree bpdufilter enable PortFast is not required. This command prevents the port from sending or receiving BPDUs, which effectively disables Spanning-Tree on the interface.

Defaults

  • BPDU Filter is disabled by default.

Configure

  • Enable globally on all ports configured for PortFast:
    • spanning-tree portfast bpdufilter default
  • Enable on an individual interface, regardless of PortFast:
    • spanning-tree bpdufilter enable
  • Disable on an interface, when enabled globally:
    • spanning-tree bpdufilter disable

Verify

  • Display global state of BPDU Filter:
    • show spanning-tree summary

Links

Loopguard

Loop Guard monitors non-Designated ports and prevents them from becoming Designated ports because of a unidirectional link failure, and is considered the opposite of Root Guard. The goal is similar to UDLD, but STP BPDUs are used to detect unidirectional links. This feature should be enabled across the entire switched network. When enabled, Spanning-Tree does not send BPDUs on Root or Alternate ports, when in PVST+ or Rapid-PVST+ mode. When in MST mode, BPDUs are not sent on nonboundary ports only if the interface is blocked by Loop Guard in all MST instances. On a boundary port, Loop Guard blocks the interface in all MST instances. Loop Guard only operates on interfaces that are considered P2P by Spanning-Tree.

Normally, an Alternate blocking port will receive BPDUs generated by the connected Designated port on the other end of the link (unless Bridge Assurance in configured, in which case all ports send BPDUs regardless of role or state). If the Alternate blocking port stops receiving BPDUs due to a unidirectional link, it will normally enter the forwarding state, which will cause a loop. Loop Guard prevents this by transitioning the blocking port into a Loop Inconsistent state when BPDUs are no longer received.

Loop Guard operates on a per-VLAN basis. For example, if there is an inconsistency with a single VLAN on a trunk port, the other VLANs will still process traffic normally while only the single VLAN is placed into Loop Inconsistent on the interface.

Loop Guard and Root Guard are mutually-exclusive and cannot be enabled at the same time on an individual interface. Loop Guard is intended to complement UDLD.

Defaults

  • Loop Guard is disabled on all interfaces by default.

Configure

  • Loop Guard can be enabled globally, or enabled/disabled at the individual port level.
    • Global:
      • spanning-tree loopguard default
    • Interface:
      • spanning-tree guard loop

Verify

  • Displays global state of Loop Guard:
    • show spanning-tree summary
  • Verify if Loop Guard is enabled on a particular interface:
    • show spanning-tree interface INTERFACE detail

Links

Rootguard

Root Guard restricts which interface is allowed to be the Spanning-Tree Root port, or the path to the Root for the switch. Root Guard prevents a Designated port from becoming a non-Designated port. When an interface is configured for Root Guard, it is placed into a blocking Root Inconsistent state if it receives a superior BPDU, which would cause a change of the current Root port. The primary use case is to protect the Spanning-Tree topology to prevent Access- layer (or customer-side) switches from becoming Root or altering the path to the Root. When the interface is placed into Root Inconsistent state, it will recover and begin forwarding again when it stops receiving superior BPDUs.

Root Guard is enabled per-interface, but operates per-VLAN. Root Guard should be enabled on all interfaces on the Root bridge, and on all Designated interfaces on all downstream switches for which you wish to protect the Spanning-Tree topology.

Root Guard should not be enabled on interfaces that also use the UplinkFast feature because those interfaces will be placed into Root Inconsistent state if the current Root port fails.

Root Guard and Loop Guard are mutually-exclusive and cannot be enabled at the same time on an individual interface.

Defaults

  • RootGuard is disabled on all interfaces by default.

Configure

  • Root Guard is enabled on directly on the interface:
    • spanning-tree guard root

Verify

  • Display if root guard is enabled on an interface:
    • show spanning-tree interface INTERFACE detail

Links

SPAN

SPAN copies traffic received or sent (or both) on source ports or source VLANs to a destination port for analysis. SPAN does not affect the switching of network traffic on the source ports or VLANs, and the destination port must be dedicated for SPAN use. Destination ports do not receive or forward traffic except for traffic that is required for the SPAN (or RSPAN) session. Oversubscribed SPAN ports (such as a 1Gb link monitoring a 10Gb link) does not affect switching behavior or performance, but traffic may be dropped or lost on the SPAN destination port.

Only traffic that enters or leaves source ports or VLANs can be monitored with SPAN. Traffic routed to a source VLAN cannot be monitored, such as when traffic from another VLAN gets routed to the source VLAN, though traffic received on the source VLAN and routed to another VLAN can be monitored.

With local SPAN, all source ports or VLANs and destination ports are in the same switch or switch stack. Local SPAN does not have separate source and destination sessions. Sources can be ports or VLANs, but not both in the same session. Switches support up to two SPAN or RSPAN source sessions, and you can run both a local SPAN and RSPAN source session in the same switch or switch stack. You can configure two separate SPAN or RSPAN source sessions with separate or overlapping sets of SPAN source ports and VLANs. Both switched and routed ports can be configured as SPAN sources and destinations. There can be multiple destination ports in a SPAN session, up to 64 destination ports per switch stack. EtherChannels can be monitored either as a whole or the individual interfaces.

SPAN sessions can monitor received traffic, transmitted traffic, or both. Receive SPAN traffic is monitored as much as possible all the packets received by the source interface or VLAN before any modification or processing is performed by the switch. For example, packets modified by QoS or features that would cause the packet to be dropped, such as input ACLs. The traffic would still be received on the receive SPAN session even though the switch may ultimately modify or drop the traffic. Transmit SPAN traffic is monitored after all the modification and processing has been performed by the switch. Monitoring of both traffic types is the default.

Traffic is sent untagged, and BPDUs, CDP, VTP, DTP, STP, and PAgP traffic is not sent unless the destination port is configured with the encapsulation replicate option. When enabled, packets are sent on the destination port with the same encapsulation as the source: untagged, ISL, or 802.1Q, and packets of all types including BPDU and Layer 2 protocol packets are monitored.

When monitoring a trunk port, you can limit monitoring to specific VLANs with VLAN filtering. VLAN filtering is designed for trunk ports as the source and is mutually exclusive from VLAN monitoring. If VLAN filtering is enabled, the SPAN source cannot be a VLAN.

When a port is configured as a destination port, the configuration overrides the original port configuration. The when destination port configuration is removed, the port’s original configuration is reverted. If a change is made to its configuration while it is enabled as a SPAN destination port, the configuration does not take effect until the port is no longer a destination, with the exception of QoS, which takes effect immediately. The destination port cannot be a Secure port or a private VLAN port, and it cannot be an EtherChannel group or a VLAN. The destination port can belong to only a single SPAN session at a time. Incoming traffic is disabled on SPAN destination ports.

You can filter traffic to the SPAN or RSPAN destination with IPv4, IPv6, and MAC ACLs. This is referred to as Flow-Based SPAN. The FSPAN ACLs are independent of any other security ACLs applied to the source ports or VLANs. For example, if a security input ACL denies a packet, it will still be forwarded to the SPAN destination if the FSPAN ACL permits it. You can attach ACLs to only one SPAN or RSPAN session at a time.

Defaults

  • SPAN sessions can monitor only received traffic or only transmitted traffic, with the monitoring of both being the default.
    • Traffic is sent to destination ports untagged, and other types of Layer 2 protocol traffic such as BPDUs, CDP, VTP, DTP, STP, PAgP are not sent by default.
  • When monitoring trunk ports, all VLANs present on the trunk are monitored by default.

Configure

  • Entering SPAN configuration commands does not remove previously-configured SPAN parameters for a session. You must enter the no monitor session command to delete configured SPAN parameters.
  • Specify the source session and port:
    • monitor session SESSION-NUMBER source {interface INTERFACE | vlan VLAN} [both | rx | tx]
      • You can specify multiple VLANs with a comma or hyphen. You can issue the command multiple times for multiple source ports.
  • Specify the destination port:
    • monitor session SESSION-NUMBER destination interface INTERFACE [encapsulation replicate] [ingress {dot1q vlan VLAN | isl | untagged vlan VLAN}
      • The session number must be the same as the source session. You can issue the command multiple times for multiple destination ports. If you use the ingress option, all traffic received on the destination port will be forwarded using the specified encapsulation type.
  • Optionally select desired VLANs to monitor when monitoring a source trunk port:
    • monitor session SESSION-NUMBER filter vlan VLANS
      • The specified VLANs are those that are monitored
  • Optionally apply a pre-defined ACL to select the desired traffic to be monitored (FSPAN):
    • monitor session SESSION-NUMBER filter {ip | ipv6 | mac} access-group ACL

Verify

  • Display information about all or individual SPAN sessions on a device:
    • show monitor [session]

Links

RSPAN

RSPAN supports source ports, source VLANs, and destination ports on different switches or switch stacks, which enables remote monitoring of multiple switches across the network. Traffic for each RSPAN session is carried over a user- specified RSPAN VLAN dedicated for the single RSPAN session in all participating switches. The RSPAN traffic from the source ports or VLANs is copied into the RSPAN VLAN and forwarded over trunk ports carrying the RSPAN VLAN to a destination session that monitors the RSPAN VLAN. Each RSPAN source switch must have either ports or VLANs as RSPAN sources, and the destination is always a physical port.

RSPAN consists of at least one RSPAN source session, an RSPAN VLAN, and at least one RSPAN destination session. Source and destination sessions are configured independently on different network devices. In an RSPAN source session, the SPAN packets are relabeled with the RSPAN VLAN ID and directed over normal trunk ports to the destination switch. The RSPAN destination session takes all packets received on the RSPAN VLAN, strips off the VLAN tagging, and presents them on the destination port. There can be more than one source session and more than one destination session active in the same RSPAN VLAN.

Switches do not support a combination of local SPAN and RSPAN in a single session. An RSPAN source session cannot have a local destination port. An RSPAN destination session cannot have a local source port. An RSPAN destination session and an RSPAN source session that are using the same RSPAN VLAN cannot run on the same switch or switch stack.

Traffic in the RSPAN VLAN is always flooded, and no MAC address learning occurs on the RSPAN VLAN. RSPAN VLAN traffic only flows on trunk ports. STP can run on RSPAN VLAN trunks, but not on RSPAN destination ports. An RSPAN VLAN cannot be a private VLAN primary or secondary VLAN. RSPAN VLAN characteristics can be propagated across switches with VTP. It is normal to have multiple RSPAN VLANs in a network at the same time with each RSPAN VLAN defining a network-wide RSPAN session. It is also possible to have multiple RSPAN destination sessions throughout the network that monitor the same RSPAN VLAN. The RSPAN VLAN ID separates the sessions.

Defaults

  • The same defaults of SPAN apply to RSPAN

Configure

  • Create the RSPAN VLAN on all switches (VTP can propagate the configuration):
    • vlan VLAN
      • remote-span
  • Source Switch(es):
    • Specify the source session and port:
      • monitor session SESSION-NUMBER source {interface INTERFACE | vlan VLAN} [both | rx | tx]
        • You can specify multiple VLANs with a comma or hyphen. You can issue the command multiple times for multiple source ports.
    • Specify the RSPAN session and destination RSPAN VLAN:
      • monitor session SESSION-NUMBER destination remote vlan VLAN
    • Optionally select desired VLANs to monitor when monitoring a source trunk port:
      • monitor session SESSION-NUMBER filter vlan VLANS
        • The specified VLANs are those that are monitored
    • Optionally apply a pre-defined ACL to select the desired traffic to be monitored (FRSPAN):
      • monitor session SESSION-NUMBERfilter {ip | ipv6 | mac} access-group ACL
        • The session number must be the same as the source session.
  • Destination Switch(es):
    • Specify the source RSPAN session and source RSPAN VLAN:
      • monitor session SESSION-NUMBER source remote vlan VLAN
    • Specify the destination port:
      • monitor session SESSION-NUMBER destination interface INTERFACE [ingress {dot1q vlan VLAN | isl | untagged vlan VLAN}
        • The session-number must be the same as the source session. If you use the ingress option, all traffic received on the destination port will be forwarded using the specified encapsulation type.

Verify

  • Display information about all or individual sessions on a device:
    • show monitor [session]

Links

VSS concepts

Available on various Catalyst 6800, 6500 and 4500 platforms. VSS creates a single logical switch out of two physical chassis switches, which eliminates the need for FHRPs and creates no STP blocking ports. The VSS pair represents a single control and management plane, and reduces the number of L3 routing protocol peers.

The active supervisor in the VSS controls both chassis and runs the Layer 2 and Layer 3 control protocols and manages the switching modules on both chassis. However, both the active and standby chassis perform data traffic forwarding. The active VSS supervisor controls the console port. The console port of the standby supervisor(s) is effectively disabled and blocks attempts to enter configuration mode.

Pair of switches in Virtual Switch Domain connected by the Virtual Switch Link, which is an EtherChannel consisting of one or more 10 Gbps Ethernet links (two is the recommended minimum, eight is the maximum). All traffic traversing the VSL is prepended with a 32-byte header (VS Header) containing ingress/egress switchport indexes, CoS, VLAN number, and other information from the L2 and L3 headers. VSS pairs are identified by the configured Virtual Switch Domain ID, which must be unique among switch pairs in the network. A single router MAC address is used to represent the single logical device to the rest of the network, and can it be derived from the BIA of the active supervisor, or configured manually. Manual configuration is recommended to eliminate the possibility of duplicate MAC addresses on the network if the supervisor card is ever used elsewhere in the network.

Upon switch boot, the startup-config is pre-parsed in order to bring up the VSL interfaces. The Link Management Protocol (LMP) is used to track and reject unidirectional links, and exchange the Chassis ID and other information between the two switches. The Role Resolution Protocol (RRP) is used to determine compatible hardware and software versions to form the VSL and to determine which switch becomes Active and which becomes Hot Standby from the control plane perspective. After RRP determines the roles, a configuration consistency check is performed to ensure proper VSL operation, which includes the switch virtual domain ID, switch virtual switch ID, switch priority, switch preempt, VSL port channel link ID, VSL port interfaces and state, power redundancy mode, and power enable on VSL cards. If the configurations do not match, the hot standby supervisor reverts to Route Processor Redundancy (RPR) mode and disables all non-VSL interfaces. If everything properly matches, the supervisor in the hot standby chassis will be in NSF/SSO mode.

VSS introduces support for Multichassis EtherChannels (MEC), where links from a single EtherChannel connect from a single device, such as a server or a switch, to both chassis. With VSS, EtherChannels and L3 ECMP forwarding favors locally- attached interfaces which produces deterministic traffic patterns and removes the need to send traffic over the VSL. EtherChannel hashing algorithms are modified in VSS to always favor locally-attached interfaces. Each flow on an EtherChannel will enter and exit the same switch and not traverse the VSL. The EtherChannel hash distribution method is “Adaptive”. The VSL is like a regular EtherChannel in that it supports up to 8 links. When configuring the VSL, consider the possible failure scenarios and the bandwidth needed for things like service modules and SPAN sessions.

The VSL is used primarily for control traffic (Layer 2 and Layer 3 protocols), and data traffic is avoided where possible. The VSL is used for data traffic when Layer 2 traffic is flooded over a VLAN, where packets are processed by the active supervisor but the ingress interface is on the standby chassis, and when the packet destination is on the peer chassis (such as BUM traffic).

The VSS hot standby chassis monitors the active VSS chassis using the VSL. If the standby detects a failure, it initiates a switchover and takes on the active role. When the failed chassis recovers, it becomes the new standby and does not preempt the now current active.

There are two options for dual-active detection: an Enhanced PAgP connection to a supported neighbor, and a dedicated link between the VSS pairs for VSLP fast hellos. Both methods may be used simultaneously, and is a recommended design best practice.

There is an option for Quad-Supervisor VSS SSO which has the advantage of maintaining full bandwidth for the VSS pair during a supervisor switchover, as well as maintaining network availability for single-attached devices. Service modules are considered single-attached devices.

When converting a switch from standalone mode to VSS configuration mode, the conversion process removes any previous configuration that exists on the standalone chassis. As part of the conversion process, configure a unique domain ID that matches on both switches, a switch ID that is unique to each switch (such as 1 and 2), and port-channel interfaces for the VSL that are unique on each switch (such as Po1 and Po2). VSS supports up to 512 total EtherChannels (510 usable - the VSL always requires two). IOS releases before 12.2(33)SXI supported 128 total EtherChannels.

Defaults

  • VSS mode is not enabled by default. Standalone mode is the default.
  • The default VSS switch priority is 100, with a range of 1 - 255.
  • Dual-Active detection via enhanced PAgP and Fast Hellos is enabled by default.

Configure

  • NOTE: It is recommended to backup the existing startup-config on each chassis before proceeding so that you may revert to standalone mode if necessary.
  • Enable SSO and NSF on both chassis:
    • redundancy
      • mode sso
    • router PROTOCOL PID
      • nsf
  • Assign the Virtual Switch Domain ID and switch numbers. The VSD ID is 1 - 255 and must match on both switches. The switch number must be unique on each switch, and must be either 1 or 2:
    • switch virtual domain NUM
      • switch NUM
  • Configure the VSL port channel and ports. The port channel number and switch virtual link numbers must be different on each switch:
    • Switch 1:
      • interface port-channel 10
        • switch virtual link 1
    • Switch 2:
      • interface port-channel 20
        • switch virtual link 2
  • Add two or more 10GigE interfaces to the port channel on each switch:
    • Switch 1:
      • interface range 10G-INTERFACES
        • channel-group 10 mode on
    • Switch 2:
      • interface range 10G-INTERFACES
        • channel-group 20 mode on
  • Convert both switches to VSS mode by running the following command on both switches:
    • switch convert mode virtual
  • Optionally change the VSS switch priority from the default of 100 with a range of 1 - 255, higher preferred. You must reload the switch for the setting to take effect:
    • switch virtual domain ID
      • switch {1 | 2} priority PRIORITY
  • Optionally configure the VSS router MAC address assignment. You must reload the switch for the setting to take effect:
    • switch virtual domain ID
      • mac-address MAC-ADDRESS
  • Enable Dual-Active detection via enhanced PAgP:
    • switch virtual domain ID
      • dual-active detection pagp
  • Enable Dual-Active detection via Fast Hellos. Interfaces must connect directly to each other between chassis, must be physical interfaces, and cannot be part of the VSL:
    • switch virtual domain ID
      • dual-active detection fast-hello
    • interface INTERFACE
      • dual-active fast-hello

Verify

  • Display general information about the VSS pair including domain ID and local role:
    • show switch virtual
  • Display the role, switch number, and priority for each of the VSS chassis:
    • show switch virtual role
  • Display the status of the VSL:
    • show switch virtual link
  • Display the operating redundancy mode:
    • show redundancy states
  • Display information about dual-active detection:
    • show switch virtual dual-active

Links

Stackwise

Up to nine stacking-capable switches can be connected together via StackWise or StackWise Plus ports. Catalyst 3750 switches run StackWise, while 3750E/X switches run StackWise Plus. 3750 switches can participate in a 3750E/X stack, but the entire stack will run in StackWise mode, not StackWise Plus. A stack is formed automatically when two or more switches are connected together.

StackWise uses dedicated cables to create a single switching unit with a 32 Gbps switching stack interconnect in a bidirectional closed-loop path, which acts as a switch fabric for all the connected switches. All members have full access to the stack interconnect bandwidth. The stack interconnect contains two logical counter-rotating paths, each supporting 16 Gbps in both directions, yielding a total bidirectional bandwidth of 32 Gbps. If there is a break in one of the two paths, the traffic is immediately wrapped back across the single remaining 16 Gbps path.

Switch stacks elect a Master, which controls several functions and presents the entire stack as a single device to the rest of the network. The election process is based on highest configured priority (default 1, max 15, 0 = don’t participate in the election). If there is a tie in priority, the switch with the most extensive feature set (such as IP Services) is selected. If the feature set ties, switches that have been configured previously take precedence over switches with default configurations. If no switches have been previously configured, the switch with the longest uptime is selected to be Master. The final tiebreaker is the switch with the lowest MAC address will become Master, if all other criteria are equal.

Initial Master elections take place within 120 seconds of the first member being powered on. After the 120 seconds, newly powered-on members remain members and do not participate in the initial Master election, though all members participate in re-elections. If a new stack Master is elected and the previous stack Master becomes available again, it does not preempt the current stack Master.

The stack Master can change if the current Master fails, reboots, is removed from the switch stack, or when there is a stack merge, which happens when a new switch is powered up before being connected to the stack cables or when two stack cables are disconnected from the stack. On Master switchover, the new Master re-applies the running-config for the stack.

The stack Master controls all centralized functions and is the primary point of contact for IP functions such as Telnet/SSH sessions, pings, CLI, and routing information exchange. The Master builds and propagates the L3 FIB, and implements unicast and multicast routing tasks. QoS and ACL configuration information is distributed from the Master to the members. The master also manages and propagates the configuration files to the stack. Copies of the startup and running config are kept on all switches so that any switch can immediately become the Master if necessary. The Master controls the console, the CDP neighbor table, and the VLAN database. The Master facilitates upgrading of the switch stack.

Each switch member handles distributed functions such as storing its own local MAC addresses as well as tables for the other MAC addresses in the stack. Each member receives a mapping of MAC addresses for the entire stack from the Master, so that every switch in the stack is aware of every port. Each member keeps its own Spanning-Tree for each supported VLAN, and the Master keeps a copy of all Spanning-Tree tables for each VLAN in the stack.

Each switch in a stack has a member number which determines the interface-level configuration. For example, the g0/1 interface on switch member number 4 becomes g4/0/1. When a switch joins a stack, by default it takes the next lowest available member number (up to 9). Once a switch is assigned a member number, it retains that number even if the switch is removed and joined to another stack, unless the member number is configured manually or it conflicts with an existing member number, in which case the next lowest available number is chosen.

Switch stacks are identified to the rest of the network by the stack master bridge ID, and if operating as a Layer 3 device, by its router MAC address. The management IP address of the stack is a system-level setting and does not change even if the stack Master changes. You can connect to the console port of any of the stack members for management. If the stack Master changes, the stack Bridge ID and router MAC address changes as well, unless the persistent MAC address feature is enabled, in which case there is a four-minute delay before the BID and MAC are changed. If the previous stack Master rejoins the stack during the four minute period, the previous master becomes a stack member, but the new Master uses the BID and MAC of the previous Master.

StackWise features distributed Layer 2 forwarding, where individual switches will continue to forward information based on the tables they last received from the Master if it has failed. Layer 3 NSF is also supported with RPR+. Frames that flow across the stacking cables are prepended with a 24-byte header to provide for QoS and multicast. In the cast of multicast, only a single frame is sent across the bus, but with multiple destination addresses.

When replacing a switch, if the model is identical, the new switch will receive the port-level configuration of the original switch, otherwise the original configuration is lost and the new switch receives all stack global information. Switches being added or removed to a switch stack should be powered off when connecting or removing. Adding a powered-on switch causes election of a new stack Master. Even if the existing stack Master is re-elected, all member switches will reload and change their stack member numbers to the lowest available. Removing a powered on switch from the stack causes the stack to divide into two or more switch stacks with the same configuration, which can cause duplicate IPs on the network.

Switch members can be pre-provisioned before being added to the stack. You can configure the stack member number, the switch type, and the interfaces associated with a switch that is not currently a part of the stack. The configuration is referred to as the provisioned configuration, and when the switch is added to the stack it receives the configuration and is referred to as the provisioned switch.

A switch can experience a stack mismatch and is not added to the stack as a member when there is an IOS version mismatch (both IOS version level and feature set), or when there is an SDM template mismatch. All stack members must run same template as the Master. IOS version mismatch is noticed before the SDM mismatch and is attempted to be rectified first. You can also have a missing hardware feature mismatch with mixed stacks (3750 with 3750E/X) such as PoE and jumbo frames.

When a member is added to the stack and its IOS version differs from the Master, the situation needs to be rectified.

Auto-upgrade is attempted first, where auto-copy copies a running image of any stack member into the switch, but if the process fails then auto-extract is attempted where all flash devices are searched for a suitable image.  Auto- upgrade performs the upgrade only when the two feature sets are the same type, so it will not automatically upgrade a switch from IP Base to IP Services, or vice-versa. If that fails, auto-advise provides a recommendation on how to upgrade manually by telling you the configuration command and image tar filename needed to manually upgrade the switch stack or the switch in VM (version mismatch) mode. Auto-advise cannot be disabled, and there are no commands to check its status. Auto-advise also does not provide suggestions when the IOS feature sets are different, such as the stack running IP Base and attempting to add a member switch running IP Services.

You can perform a rolling upgrade for IOS, where member switches are upgraded automatically one at a time.

3750s running LAN Base can only stack among themselves - you cannot stack LAN Base switches with those running IP Base or IP Services

You can debug individual stack members with the session stack-member-number command. The member number is appended to the hostname at the system prompt, and you can only issue show and debug commands.

If the stack is in the full-ring state, you can disable one individual stack port in the entire ring. The stack enters the partial-ring state. Disabling an individual stack port is used for troubleshooting.

StackWise uses source stripping for frames that traverse the ring. When a unicast frame is sent on the ring, the destination copies it, but the frame is not removed from the ring until it is looped back around to the source. StackWise Plus introduces destination stripping, or spatial re-use, where the unicast frame is removed from the ring as soon as it reaches the destination member on the ring. This allows for a minimum throughput performance of 64 Gbps bidirectionally on the ring.

With StackWise, the ring represents the switch fabric itself, and all frames must traverse the entire ring, even if the destination is another port on the same physical switch. StackWise Plus removes this limitation and switches packets locally when possible, bypassing the ring. In a mixed stack with 3750 and 3750E/X switches, the ring will operate in StackWise mode, but the 3750E/X members can still switch frames locally.

Defaults

  • The LAN Base feature set supports switch stacks only when all switches in the stack are running LAN Base.
  • All stack members are eligible to participate in an election to become the stack Master by default.
  • The default stack member number is 1. When an unconfigured switch joins an existing stack, it uses the next lowest available member number (up to 9).
  • The default member priority value is 1.
  • Auto-upgrade is enabled by default.
  • Stack Master persistent MAC is disabled by default, and when enabled it has a default delay of four minutes.

Configure

  • Optionally manually assign a switch member number:
    • switch CURRENT-MEMBER-NUMBER renumber NEW-MEMBER-NUMBER
    • reload slot CURRENT-MEMBER-NUMBER
  • Optionally assign a switch member’s priority value:
    • switch MEMBER-NUMBER priority PRIORITY
      • Priority default is 1, range is 1 - 15 with higher being more preferred. The new value is effective immediately, but does not affect the current stack Master.
  • Optionally enable the persistent MAC feature:
    • stack-mac persistent timer [0 | VALUE-1-60]
      • Default is 4, range 0 - 60, 0 = MAC of previous Master is used until no stack-mac persistent timer is issued
  • Optionally provision a new member for a switch stack:
    • switch MEMBER-NUMBER provision TYPE
      • Type refers to the model number of the supported switch and is available in the context help

Verify

  • Display the stack MAC address, persistent MAC timer and member information (number, role, MAC, priority, version, state):
    • show switch [detail]
  • Display all switch stack information, such as the stack protocol version:
    • show platform stack manager all
  • Display the stack port events and history:
    • show platform stack ports {buffer | history}
  • Display port information for the stack. Use the summary keyword to display the stack cable length and status:
    • show switch stack-ports [summary]
  • Display the number of frames per member that are sent to the stack ring. The detail keyword includes the receive queues and the ASIC:
    • show switch stack-ring activity [detail]
  • Display speed, state, and protocol of the StackWise ring:
    • show switch stack-ring speed

Links

AAA with TACACS+ and RADIUS

TACACS+ and RADIUS are centralized solutions that are more scalable than using local databases. The IOS device acts as a client to the TACACS+ or RADIUS server.

TACACS+ uses TCP port 49, encrypts the entire payload, separates each AAA function, and is geared toward device administration.

RADIUS uses UDP ports 1812 and 1813 (accounting), encrypts only the password field, combines authentication and authorization, and is geared toward network access.

With TACACS+ you can authorize individual commands, whereas RADIUS authorization is all or nothing.

TACACS+ supports message passing, where additional challenges besides login/password can be presented, or notifications can be displayed such as custom banners for different types of events.

Both TACACS+ and RADIUS can be used with accounting, where commands are logged and associated with the user.

Links

Local privilege authorization fallback

IOS can be configured to attempt authorization via TACACS+ and RADIUS first, but use the local database (or bypass authorization completely) if the servers are unreachable.

There are three authorization fallback methods: local, if-authenticated, and none.  Local uses locally-configured usernames and passwords. If-authenticated provides authorization if the user has been previously authenticated (by any means). None automatically enables authorization.

Links

Protected Ports

Protected ports do not forward Layer 2 data traffic between other protected ports on the same switch (or switch stack). This is a subset of PVLAN functionality (and its configuration is mutually exclusive from PVLAN configuration). Forwarding between protected and nonprotected ports works as usual. Port monitoring does not work if both the monitor and monitored ports are protected. Also referred to unofficially as “Private VLAN Edge” ports.

Defaults

  • No ports are protected by default.

Configure

  • Port protection is configured per-interface:
    • switchport protected

Verify

  • Display the protected port configuration status:
    • show interfaces switchport | include Protected

Links

PACL

ACLs that are applied to Layer 2 interfaces on a switch. PACLs are supported only on physical interfaces, not EtherChannels, and can be applied only on interfaces in the inbound direction. You can use standard IP access lists using source addresses, extended IP access lists using src/dst addresses and optional protocol type information, and MAC extended access lists using src/dst MAC addresses and optional protocol type information. The switch examines ACLs associated with all inbound features configured on a given interface and permits or denies packet forwarding based on how the packet matches entries in the ACL.

PACLs are commonly used in 802.1x deployments to restrict inbound traffic before and after 802.1x authentication.

Defaults

  • When you apply a PACL to a trunk port, the ACL filters traffic on all VLANs present on the trunk port. Likewise, when you apply a PACL to a port with a Voice VLAN, the ACL filters traffic on both voice and data VLANs.
  • You can apply up to one IP access list and one MAC access list simultaneously on a Layer 2 interface.
  • PACLs take precedence over VACLs
  • PACLs do not generate ICMP unreachable messages when packets are denied by an access-group, contrary to the normal default.
  • When you apply an undefined ACL to an interface, the switch acts as if the ACL has not been applied to the interface and permits all packets.

Configure

  • Create IP or MAC ACL:
    • ip access-list or access-list NUM
    • mac access-list extended
  • Apply to Layer 2 interface:
    • IPv4 ACL interface command:
      • ip access-group {ACL-NUMBER | ACL-NAME} in
    • MAC ACL interface command:
      • mac access-group NAME in

Verify

  • Display “Inbound access list”:
    • show ip interface INTERFACE
  • Display “Inbound access-list”:
    • show mac access-group [INTERFACE]
  • Display ACL definitions (both IP and MAC):
    • show access-lists

Links

VACL (IP and non-IP)

VACLs (also referred to as VLAN maps) access-control all packets, both bridged and routed, and are used to filter traffic between devices in the same VLAN. VACLs are not defined by direction (in or out). VACLs are applied only on traffic going through the locally-configured switch (not other switches in the same VLAN, etc) as it enters the VLAN through an interface.

All non-IP protocols are access-controlled through MAC VACLs. IP traffic is not controlled by MAC VACLs. While MAC VACLs can contain MAC addresses, they are usually used with EtherTypes or LSAP (Link Service Access Point) values, which consist of SSAP and DSAP (Source/Destination). For example, permit any any 0x806 0x0 specifies EtherType 806 (ARP). The 0x0 at the end is the EtherType/LSAP mask.

PACLs take precedence over VACLs. When configured with both, traffic passing the PACL is then filtered by the VACL.

You can apply only one VACL to a VLAN.

When a VACL has at least one match clause for the type of packet (IP or MAC) and the packet does not match any of the match clauses, the default action is to drop the packet. If there are no match clauses for the type of packet, the default action is forward. Within each vlan access-map NAME clause, the default action is to forward unless otherwise specified.

VACLs do not use permit or deny keywords. To deny a packet with a VACL, the referencing ACL should match the packet, and the VACL action is set to drop. The permit keyword in the ACL matches the packet, whereas the deny keyword indicates the packet does not match within the ACL.

If a VACL cannot be applied in hardware, all packets in that VLAN must be bridged and routed by software. When the VACL is applied in hardware, the vlan filter needs to be reapplied after changing its configuration so it can be recompiled for the TCAM.

If 802.1Q tunneling is configured on an interface, any 802.1Q encapsulated IP packets received on the tunnel port can be filtered by MAC ACLs, but not IP ACLs, because the switch does not recognize the protocol inside the 802.1Q header.

Like a regular ACL, entries are processed top-down with the packet being acted upon with the first matching entry. If there are multiple types of ACLs mixed in the same VLAN map, non-matching traffic of the ACL type is dropped, but the other type could still be processed by further entries. For example, if the VACL is configured to match certain IP traffic, other IP traffic that does not match is dropped, and non-IP traffic is still passed (unless there is a Non-IP entry in the VACL, in which case the traffic is processed by that entry).

VACLs are not supported on switches running the LAN base feature set.

You can enable VACL logging where syslog messages are created for denied IP packets when the first matching packet is received, for any matching packets received within the last five minutes, and if the threshold is reached before the five minute interval. Log messages are generated per-flow.

Defaults

  • VACLs are not enabled by default.
  • The default action within a clause is to forward.
  • VACL logging is not enabled by default.

Configure

  • Create standard/extended IP ACL, or MAC extended ACL first.
  • Create VACL map entry globally:
    • vlan access-map NAME [SEQ_NUM]
      • If not specified, sequence numbers are added automatically in increments of 10
  • Match the packet against one or more ACLs:
    • match {ip | mac} address {NAME| NUMBER} [NAME| NUMBER]
  • Optionally define action:
    • action forward
    • action drop [log]
  • Apply the VACL globally:
    • vlan filter MAPNAME vlan-list VLANS
  • Optionally configure VACL logging parameters:
    • vlan access-log {maxflow LOG-TABLE-SIZE | threshold PACKETS}

Verify

  • Display entries of VLAN access maps:
    • show vlan access-map [MAPNAME]
  • Display which VACLs are applied to which VLANs:  
    • show vlan filter [access-map NAME | vlan VLAN]

Links

Storm Control

Storm control prevents traffic on a LAN from being disrupted by a broadcast, multicast, or unicast storm on one of the physical interfaces. Storm control monitors packets passing from an interface to the switching bus and determines if the packet is broadcast, multicast, or unicast and counting the number of packets of the specified type received within the 1-second time interval and compares the measurement with the predefined suppression-level threshold.

Storm control uses one of these methods to measure traffic activity:

  • Bandwidth as a percentage of total available bandwidth of the port
  • Traffic rate in PPS at which the packets are received
  • Traffic rate in BPS at which the packets are received
  • Traffic rate in PPS and for small frames. This feature is enabled globally, and the threshold for small frames is configured for each interface

When the rising threshold is reached, the port blocks traffic, and remains blocked until the traffic rate drops below the falling threshold (if one is specified) then resumes normal forwarding.

Defaults

  • The default suppression level is 100%, which means storm control is effectively disabled
  • When the falling threshold is not specified, it is equal to the rising threshold
  • The default action for storm control is to filter out the offending traffic and not send traps
  • When the threshold for multicast traffic is reached, all multicast traffic is blocked except for control traffic (such as BPDUs and CDP). However the switch does not differentiate between routing updates (such as OSPF) and regular multicast traffic, so both types are blocked.
  • Threshold percentages are approximations due to hardware variations
  • When you configure storm control on an EtherChannel, the settings are propagated to the physical interfaces
  • Incoming VLAN-tagged packets smaller than 67 bytes are considered small frames, which are forwarded by the switch but do no cause the storm-control counters to increment

Configure

  • Configure at the interface level:
    • storm-control {broadcast | multicast | unicast} level {LEVEL [LEVEL-LOW] | bps BPS [BPS-LOW] | pps PPS [PPS-LOW]}
      • Where Level is the rising threshold from 0.00 to 100.00 and Level-Low is the falling threshold
  • Optionally configure an action when a storm is detected:
    • storm-control action {shutdown | trap}
      • Where shutdown will err-disable the port during a storm, and trap generates an SNMP trap when a storm is detected
  • Enable the small-frame rate-arrival feature on the switch if you wish to detect these frames:
    • errdisable detect cause small-frame
  • Enable detection on the interface level:
    • small violation-rate PPS
      • Where PPS is from from 1 to 10,000

Verify

  • Display interfaces, filter states, and thresholds:
    • show storm-control [INTERFACE] [broadcast | multicast | unicast]

Links

DHCP Snooping (+ Information Option)

The primary goal of DHCP snooping is to enforce DHCP security. DHCP snooping provides network security by filtering untrusted DHCP messages and by building and maintaining a DHCP snooping binding database. DHCP snooping acts like a firewall between untrusted host interfaces and trusted DHCP server interfaces (or interfaces connecting to another switch). The switch itself does not participate in DHCP packet exchange, but enforces DHCP packet flow integrity.

The DHCP snooping binding database has the MAC, IP, lease time, binding type (dhcp snooping), VLAN, and interface information that corresponds to the local untrusted interfaces of a switch. It does not maintain these details for hosts connected to trusted interfaces. When a switch receives a packet on an untrusted interface, it compares the source MAC and the DHCP client hardware address - if they match, the packet is forwarded, otherwise it is dropped. This is to prevent DHCP spoofing. The database can be saved to flash memory or an external server so that the information persists across switch reloads.

When DHCP snooping is enabled, all DHCP messages are accepted on trusted ports, but only DHCPREQUEST, DHCPDISCOVER, and DHCPRELEASE messages are accepted on untrusted ports.

The switch drops DHCP packets during these situations:

  • A packet received from a DHCP server outside the network or firewall
  • A packet received on an untrusted interface and the source MAC and DHCP client hardware address do not match
  • Switch receives DHCPRELEASE or DHCPDECLINE broadcast message that has a MAC in the DHCP snooping database, but the interface information in the database does not match the interface on which the message was received
  • DHCP relay agent forwards a DHCP packet that includes a relay-agent IP (giaddr) that is not 0.0.0.0, or the relay agent forwards a packet that includes Option-82 information to an untrusted port.

You can control the rate limit of DHCP messages received on a port in packets per second. The port can then be placed into err-disabled state if the rate is exceeded.

DHCP snooping is managed by the stack master in a switch stack. When a stack member is removed, the address bindings associated with the switch age out. All snooping statistics are generated by the master, and if a new stack master is elected the statistics counters are reset.

DHCP snooping can be used with private VLANs. It must be configured on the primary VLAN. Configuration on secondary VLANs has no effect (and is outright rejected when there is no configuration on the primary VLAN).

DHCP snooping is enabled globally, but not active until it is also enabled on a VLAN.

It is recommended to use NTP so that the lease time in the database is accurate.

Do not enable DHCP snooping on RSPAN VLANs because DHCP packets might not reach the RSPAN destination port.

If DHCP snooping is enabled and an interface changes to the down state, the switch does not delete the statically configured bindings.

Information Option:

The DHCP Information Option (Option 82) is used to identify the device and port that the client connects to. This information allows the DHCP server to allocate IP addresses based on the remote-id and/or circuit-id. The addition of the DHCP Information Option is enabled by default with DHCP snooping, and the switch adds the information to all received HDCP packets. The Remote ID typically represents the device itself, and the Circuit ID typically represents the device’s point of attachment into the network.

A potential issue is that the switch inserts the information but leaves the “giaddr” field at zero. DHCP Relay is supposed to set the “giaddr” field to its own IP address, and if it is not, the IOS DHCP server will reject these messages by default. One option is to configure the switch to not insert Option 82 information with no ip dhcp snooping information option. Alternatives are to configure the DHCP server to accept these messages, and/or to trust the port where the DHCP messages are received.

When an aggregation switch with DHCP snooping enabled is connected to an edge switch that is inserting Option 82, the packets are dropped by default. If you set the interfaces to trusted, the bindings will not be populated in the DHCP snooping binding database. To allow the packets through and still have binding entries, use ip dhcp snooping information option allow-untrusted globally. The uplink on the edge switch must be configured as trusted.

Defaults

  • DHCP snooping is disabled by default
  • The DHCP snooping information option is enabled by default when DHCP snooping is enabled
  • DHCP snooping rate limiting is not configured by default. Cisco recommends an untrusted rate limit of 100 PPS or less
  • The default DHCP snooping interface trust state is untrusted
  • DHCP snooping MAC address verification is enabled by default when DHCP snooping is enabled
  • The default value for the DHCP snooping database timeout is 300 seconds. The default write delay is also 300 seconds.
  • Option 82 information is inserted into DHCP messages automatically by default when DHCP snooping is enabled.
  • The default Remote ID suboption is the switch MAC address, though some newer versions of code use the hostname by default.
  • The default Circuit ID suboption is the port identifier from which the packet is received in vlan-mod-port (VLAN-Module-Port) format. Port numbers start at 3, so an interface g0/1 is port 3, g0/2 is port 4, etc. Module refers to the switch number in a stack.
  • The remote-id and circuit-id packet formats change, depending on whether the defaults are used, or manually-configured values.

Configure

  • Before globally enabling DHCP snooping on the switch, make sure that the devices acting as the DHCP server and the DHCP relay agent are configured and enabled.
  • Enable globally:
    • ip dhcp snooping
  • Enable DHCP snooping on one or more VLANs:
    • ip dhcp snooping vlan VLANS [smartlog]
      • The smartlog option configures the switch to send the contents of dropped packets to a NetFlow collector
  • Enable trusted interfaces (typically for DHCP servers and switch uplinks):
    • ip dhcp snooping trust
  • Optionally enable DHCP packet rate limiting on the interface:
    • ip dhcp snooping limit rate PPS
  • Optionally disable MAC address verification globally (enabled by default):
    • no ip dhcp snooping verify mac-address
  • Optionally configure DHCP snooping binding database options:
    • ip dhcp snooping database LOCATION
    • ip dhcp snooping database timeout SECONDS
    • ip dhcp snooping database write-delay SECONDS
  • It is recommended to store the database binding file on a TFTP server. You must first create an empty file on the TFTP server.
  • Before configuring the DHCP snooping information option on the switch, be sure to configure the device that is acting as the DHCP server. When configuring a large number of circuit IDs on the switch, keep in mind the impact of lengthy character strings on the NVRAM or flash memory.
  • Globally enable the information option:
    • ip dhcp snooping information option
  • Optionally configure the remote-ID suboption:
    • ip dhcp snooping information option format remote-id [string STRING | HOSTNAME]
  • Optionally enable the switch to accept incoming DHCP snooping packets with Option 82 from the edge switch (recommended for aggregation switches):
    • ip dhcp snooping information option allow-untrusted
  • Optionally enable the circuit-ID suboption on an interface:
    • ip dhcp snooping vlan VLAN information option format-type circuit-id [override] string STRING
      • Use the override keyword when you do not want the circuit-ID suboption inserted in TLV format to define subscriber information

Verify

  • Display the DHCP snooping configuration for the switch:
    • show ip dhcp snooping
  • Display only the dynamically configured bindings:
    • show ip dhcp snooping binding
  • Display both static and dynamic bindings:
    • show ip source binding
  • Display the DHCP snooping binding database status and statistics:
    • show ip dhcp snooping database
  • Display the DHCP snooping statistics in summary or detail form:
    • show ip dhcp snooing statistics
  • For testing or debugging, you can manually add binding entries to the DHCP snooping binding database:
    • ip dhcp snooping binding MAC-ADDRESS vlan VLAN-ID IP-ADDRESS interface INTERFACE expiry SECONDS
  • Display if Option 82 insertion is enabled or not, the remote-id, and the circuit-id format:
    • show ip dhcp snooping
  • Display DHCP snooping events in real-time:
    • debug ip dhcp snooping event
      • Look for “DHCP_SNOOPING drop message with non-zero giaddr or option82 value on untrusted port”

Links

IP Source Guard

IP Source Guard restricts IP traffic on nonrouted, Layer 2 interfaces by filtering traffic based on the DHCP snooping binding database and on manually configured IP source bindings. IP Source Guard can be used to prevent traffic attacks if a host tries to use the IP address of its neighbor. After DHCP snooping is enabled on an untrusted interface, you can enable IP source guard, which blocks all IP traffic received on the interface except for DHCP packets allowed by DHCP snooping. A PACL is applied to the interface which allows only IP traffic with a source IP in the IP source binding table, and denies all other traffic. Like manually-defined PACLs, the PACL that IPSG uses takes precedence over other ACLs on the port, such as router ACL or VACLs.

The IP source binding table has bindings that are learned by DHCP snooping or manually configured. Each entry in the binding table has an IP address, associated MAC address, and associated VLAN number. The switch uses the IP source binding table only when IPSG is enabled.

IPSG is supported only on Layer 2 ports, including access and trunk. IPSG can be used with source IP address filtering or with source IP and MAC address filtering. Source IP address filtering forwards IP traffic when the source IP matches the DHCP snooping binding database or a binding in the IP source binding table. When the binding is changed, the switch modifies the PACL and reapplies it to the interface. Enabling IPSG on a port for which IP source bindings are not configured (either manually or learned from DHCP snooping), the PACL denies all IP traffic on the interface. With source IP and MAC filtering, the switch forwards traffic only when the source IP and MAC match an entry in the IP source binding table. The switch uses port-security to filter source MACs, and the interface can be shutdown when a port-security violation occurs.

If you enable IPSG on a trunk interface with multiple VLANs and DHCP snooping is enabled on all the VLANs, the source IP address filter is applied on all the VLANs. If IPSG is enabled and you enable or disable DHCP snooping on a VLAN on the trunk interface, the switch might not properly filter traffic.

If you enable IPSG with source IP and MAC address filtering, you must also enter the ip dhcp snooping information option global command and ensure that the DHCP server supports option 82. When IP source guard is enabled with MAC address filtering, the DHCP host MAC address is not learned until the host is granted a lease. When forwarding packets from the server to the host, DHCP snooping uses option-82 data to identify the host port.

Port security is not supported with IPSG on PVLAN interfaces.

IPSG can be enabled along with 802.1x port-based authentication

With IPSG smart logging, packets with a source address other than the specified address or an address learned by DHCP are denied and the packet contents are sent to a NetFlow collector.

IP Source Guard for static hosts:

IP Source Guard can be used for static hosts for static and non-DHCP environments. IPSG for static hosts relies on IP device tracking table entries to install PACLs, and does not require DHCP Snooping to be enabled. The switch creates static entries based on ARP requests or other IP packets to maintain the list of valid hosts for a given port. You can also specify the number of hosts allowed to send traffic to a given port, which is equivalent to port security at Layer 3.

IPSG for static hosts also support dynamic hosts when the host receives a DHCP-assigned IP that is available in the DHCP snooping database. The same entry is learned by the IP device tracking table. In stacked environments, when master failover occurs, IPSG entries for static hosts attached to member ports are retained.

Do not use IP Source Guard for static hosts on uplink ports or trunk ports.

Defaults

  • IP Source Guard is disabled by default
  • No IP source bindings are configured by default.
  • No IP source bindings are configured by default.
  • IP device tracking is disabled by default.
  • To enable IPSG with source IP and MAC address filtering, you must enable port security on the interface.

Configure

  • NOTE: DHCP Snooping must be enabled first (even if manual bindings are to be used)
  • Enable on the interface:
    • IPSG with source IP filtering:
      • ip verify source [smartlog]
    • IPSG with source IP and MAC address filtering:
      • ip verify source port-security
        • IP/MAC filtering requires DHCP server support of Option 82 or else the client is not assigned an IP. The MAC in the DHCP packet is not learned as a secure address - the MAC of the DHCP client is learned as secure only when the switch receives non-DHCP data traffic
  • Optionally add static IP source bindings globally:
    • ip source binding MAC vlan VLAN IP interface INTERFACE
      • NOTE: set switchport mode access or trunk first or else the switchport mode command will be rejected after bindings are configured
  • Static Hosts:
    • Globally enable IP host table and IP device tracking:
      • ip device tracking
    • Enable IPSG for static hosts with MAC filtering on an Access port:
      • ip verify source tracking port-security
        • IP/MAC filtering requires DHCP server support of Option 82 or else the client is not assigned an IP. The MAC in the DHCP packet is not learned as a secure address - the MAC of the DHCP client is learned as secure only when the switch receives non-DHCP data traffic
  • Establish limit for the number of static IPs that the IP device tracking table allows on the port:
    • ip device tracking maximum NUMBER
  • Optionally active port security for the port:
    • switchport port-security
  • Optionally establish a maximum of MAC addresses for the port:
    • switchport port-security maximum VALUE

Verify

  • Display IP Source Guard configuration including IPSG permit ACLs for static hosts:
    • show ip verify source [interface INTERFACE]
  • Display IP source bindings on the switch:
    • show ip source binding
  • Display IP-to-MAC bindings for a given host on the switch interface and device tracking configuration:
    • show ip device track all

Links

Dynamic ARP Inspection

DAI helps prevent malicious attacks on the switch by not relaying invalid ARP requests and responses to other ports in the same VLAN. Without DAI, ARP spoofing and ARP cache poisoning can occur because ARP allows a gratuitous reply from a host even if an ARP request was not received. DAI intercepts, logs, and discards ARP packets with invalid IP-to-MAC bindings. DAI ensures that hosts connected to untrusted interfaces do not poison the ARP caches of other hosts in the network, however, DAI does not prevent hosts in other portions of the network from poisoning the caches of the hosts that are connected to a switch running DAI. DAI is an ingress security feature; it does not perform any egress checking.

DAI uses the DHCP snooping database for verification. ARP packets received on trusted interfaces are not inspected, and ARP packets received on untrusted interfaces are forwarded only if they are valid as checked against the DHCP snooping database. DAI is enabled per-VLAN. While DAI uses the DHCP snooping database, it maintains a separate set of trusted/untrusted interfaces from DHCP snooping. Host-facing ports should be untrusted, and switch-facing ports should be trusted. If a connected switch is not running DAI, the port connecting to it should be untrusted.

For non-DHCP environments (and for hosts that have static IP addresses), DAI can validate against user-configured ARP ACLs. ARP ACLs can also be used when connecting to a switch that is not running DAI (and the port connect it is untrusted). ARP ACLs can be used even if the switch uses DHCP snooping, in which case the ARP ACLs take precedence over the DHCP snooping database - if the ARP ACL denies the packet, the switch also denies the packet even if the information in the DHCP snooping database would permit it.

You can configure DAI to drop ARP packets when the IP addresses in the packets are invalid, or when the MAC addresses in the body of the ARP packets do not match the addresses specified in the Ethernet header.

You can configure rate limiting of ARP packets on an untrusted interface (with the default being 15 PPS). When the rate limit is exceeded, the port is placed into err-disabled state, and can be recovered either manually or with errdisable recovery. When using EtherChannels in a switch stack, the rate limit is applied to ports per stack member. If a rate limit of 20 PPS is set on the EtherChannel, each switch with ports in the EtherChannel can carry up to 20 PPS. If any switch member exceeds the limit, the entire EtherChannel is placed into err-disabled state. When enabling DAI on a switch, policers that were configured to police ARP traffic are no longer effective and all ARP traffic is sent to the CPU.

Physical ports can join an existing EtherChannel only when the trust state matches. The EtherChannel inherits its trust state from the first physical port that joins the channel. Changing the trust state on the EtherChannel changes the trust state on its member interfaces.

Dropped ARP packets are logged into the switch log buffer and rate-controlled system messages are generated. After the message is generated, the entry is cleared from the log buffer. Each log entry contains flow information such as the receiving VLAN, interface, src/dst IP and MACs. Log buffer entries can represent more than a single packet, such as when an interface receives many packets on the same VLAN with the same ARP parameters. Smart logging sends the records to a NetFlow collector.

DAI is supported on access, trunk, EtherChannel, and private VLAN ports. Do not enable DAI on RSPAN VLANs because packets might not reach the RSPAN destination port.

Defaults

  • DAI is not enabled by default, and no validation checks are performed
  • When DAI is enabled, all interfaces are untrusted until explicitly configured as trusted
  • The default ARP packet rate limit on untrusted interfaces is 15 PPS. Trusted interfaces are not rate limited by default. If the rate limit is configured and the trust state is changed, the configured rate limit applies to the new trust state.
  • No ARP ACLs are defined by default
  • All denied/dropped ARP packets are logged per-VLAN by default
  • The default number of entires in the log buffer is 32 by default, with the number of system messages limited to 5 per second, and the logging rate interval of 1 second.
  • Errdisable recovery for DAI is disabled by default.
  • Optional specific checks are not performed by default (src/dst MAC/IP)

Configure

  • Enable DHCP snooping or configure manual ARP ACLs before enabling DAI.
  • Enable DAI globally on a per-VLAN basis:
    • ip arp inspection vlan VLAN-RANGE
  • Optionally enable smart logging globally:
    • ip arp inspection smartlog
  • Optionally enable ARP packet rate limiting on the interface:
    • ip arp inspection limit {rate PPS [burst interval SECONDS] | none}
  • Optionally globally enable errdisable recovery for DAI:
    • errdisable detect cause arp-inspection
    • errdisable recovery cause arp-inspection
    • errdisable recovery interval SECONDS
  • Enable trust at the interface level where appropriate:
    • ip arp inspection trust
  • Optionally enable specific checks on incoming ARP packets globally (off by default):
    • ip arp inspection validate {[src-mac] [dst-mac] [ip [allow zeros]]}
      • Where src-mac checks the source MAC in the Ethernet header against the sender MAC in the ARP body for both ARP requests and responses, dst-mac checks the destination MAC in the Ethernet header against the target MAC in the ARP body for ARP responses, and ip checks the ARP body for invalid/unexpected IP addresses including 0.0.0.0, 255.255.255.255, and all IP multicast addresses. Sender IPs are checked in all ARP requests and responses, and target IPs are checked only in ARP responses. The allow zeros keyword permits a sender address of 0.0.0.0 (ARP probe).
  • Optionally configure the log buffer globally:
    • ip arp inspection log-buffer {entries NUMBER | logs NUMBER | interval SECONDS}
      • A logs value of 0 means the entry is placed in the log buffer but a system message is not generated. An interval of 0 seconds immediately generates a system message and the log buffer is always empty. An interval setting of 0 overrides a lot setting of 0. When the logs value is greater than the interval value, logs value divided by interval value is the number of system messages generated every second. If the interval value is greater than logs, one system message is sent every interval value divided by logs value seconds. 0 is not allowed for both.
  • Optionally control globally the type of packets that are logged per VLAN (default all dropped/denied packets are logged):
    • ip arp inspection vlan VLAN-RANGE logging {acl-match {matchlog | none} | dhcp-bindings {all | none | permit} | arp-probe}
      • Where acl-match toggles packets logged when the ACE is configured as such, and dhcp-bindings toggles logs based on the results of the DHCP snooping database. The arp-probe option specifies logging of packets permitted specifically because they are ARP probes.
  • Configure ARP ACLs for non-DHCP environments, or when you need to override the DHCP snooping database, and apply it to the specified VLANs:
    • arp access-list NAME
      • permit ip host SENDER-IP mac host SENDER-MAC [log]
      • exit
    • ip arp inspection filter ARP-ACL vlan VLAN-RANGE [static]
      • Where the static keyword treats implicit denies as explicit - this causes the inspection to stop with the ARP ACL and not be processed further by the DHCP snooping binding database if the packet was implicitly denied by the ACL.

Verify

  • Display DAI configuration:
    • show ip arp inspection {interfaces | vlan VLANS}
  • Display DAI statistics:
    • show ip arp inspection statistics vlan VLANS
  • Verify ACEs:
    • show arp access-list
  • Verify errdisable recovery status for DAI:
    • show errdisable recovery
  • Displays the DAI log buffer:
    • show ip arp inspection log
  • Reset DAI counters:
    • clear ip arp inspection statistics
  • Reset DAI logs:
    • clear ip arp inspection log
  • View log entries:
    • show logging | begin ARP
  • View log entries:
    • show logging | begin Invalid

Links

Port-Security (+HSRP interaction)

Port security is used to restrict input to an interface by limiting and identifying MAC addresses of devices allowed to access the port. When you assign secure MAC addresses to a secure port, the port does not forward packets with source addresses outside the group of defined addresses. When a port is configured as secure, and the maximum number of secure MAC addresses is reached, a security violation occurs when the MAC address of a device attempting to access the port is different from any of the identified secure MAC addresses. If a device with a secure MAC address configured on one secure port attempts to access another secure port, a violation is flagged.

Without port security, normally MAC addresses are added to the CAM table as “Dynamic”, however with port security enabled, they are added as “Static” by default, and do not time out by default.

There are three types of secure MAC addresses supported by the switch:

  • Static - manually configured and added to the running-config
  • Dynamic - dynamically configured and removed when the switch is restarted
  • Sticky - dynamic or manual, and added to the running-config

Violation modes:

  • Protect - when the number of secure MACs reaches the max limit on the port, packets with unknown source addresses are dropped until you either remove a sufficient number of secure MACs to drop below the max value, or increase the max value. You are not notified that a security violation has occurred. This mode is not recommended on trunk ports because the protect mode disables learning when any VLAN reaches its max limit, even if the port itself has not reached its max limit
  • Restrict - similar to Protect, except you are notified that a security violation has occurred via SNMP trap, syslog, and the violation counter increments
  • Shutdown - port security violation causes the interface to become err-disabled and is shut down immediately (and the port LED turns off). The port can be re-enabled with errdisable recovery or by manually entering shut / no shut on the interface.
  • Shutdown VLAN - only the offending VLAN on an interface is shutdown. Use case is a port with a Voice VLAN - a violation could shut down the data VLAN on the interface, while the Voice VLAN remains operational.

Port security is not compatible with these features: DTP, dynamic access port, routed port, protected port, SPAN destination port, EtherChannel ports

Port security aging can be used to add/remove devices on a secure port without manually deleting the existing secure MACs and still limit the number of secure addresses on a port. This can be enabled/disabled per-port. There are two types of aging:

  • Absolute - where the secure addresses on the port are deleted after the specified aging time
  • Inactivity - where the secure addresses on the port are deleted only if they are inactive for the specified aging time

HSRP Interaction:

FHRPs use virtual MAC addresses in addition to physical MAC addresses, and you must account for this when enabling port security on an interface, because the default maximum is one secure address.

HSRP has an option to use the interface’s burned-in (physical) address as its virtual MAC address, instead of the preassigned HSRP MAC address for the group.

Defaults

  • Port Security is disabled by default
  • Sticky address learning is disabled by default
  • Default maximum number of secure MAC addresses per port is 1. Be sure to set the value to at least 2 when using a Voice VLAN.
  • Default violation mode is shutdown
  • errdisable recovery, if enabled, has a default timer of 300 seconds
  • Port security aging is disabled by default (aging time is 0). Aging is not supported with sticky MACs
  • The maximum number of secure MAC addresses you can configure on a switch/stack is set by the maximum number of available MAC addresses allowed in the system
  • Port security can only be configured on static access or trunk ports, not dynamic access ports. Voice VLAN is only supported on access ports, not trunk ports (even though the configuration is allowed). You cannot configure static secure or sticky secure MAC addresses in the Voice VLAN.
  • HSRP uses its preassigned MAC address of 0000.0c07.acXX by default, where XX refers to the HSRP group number in hexadecimal

Configure

  • Set the port to be static access or trunk:
    • switchport mode {access | trunk}
  • Optionally set the Voice VLAN:
    • switchport voice vlan VLAN
  • Enable port security on the interface:
    • switchport port-security
  • Optionally set the maximum number of secure addresses allowed on the interface (default 1):
    • switchport port-security maximum VALUE [vlan VLAN | vlan access | vlan voice]
      • If you try to set the maximum value to a number less than the number of secure addresses already configured on an interface, the command is rejected. When protecting a trunk port, the maximum value refers to the aggregate across all VLANs. The same MAC address on two VLANs counts as two different MAC addresses. You can also specify the max number per VLAN.
  • Optionally set the violation mode (default shutdown):
    • switchport port-security violation {protect | restrict | shutdown | shutdown vlan}
  • Optionally Configure static secure MAC addresses on an interface:
    • switchport port-security mac-address MAC-ADDRESS [vlan {VLAN-ID | access | voice}
      • When you configure fewer addresses than the max, the remaining addresses are dynamically learned
  • Optionally Convert dynamic MAC addresses to sticky on an interface:
    • switchport port-security mac-address sticky
  • Optionally configure port security aging on an interface:
    • switchport port-security aging {static | time MINUTES | type {absolute | inactivity} }
      • Where static enables aging for manually-configured addresses, time in minutes from 0 to 1440
      • Note: the switch does not support port security aging of sticky secure addresses
  • Optionally configure errdisable recovery globally:
    • errdisable recovery cause psecure-violation
  • Return port to default condition:
    • no switchport port-security
  • Return port to default number of secure MAC addresses (1):
    • no switchport port-security maximum
  • Return port to default violation mode (shutdown):
    • no switchport port-security violation {protect | restrict}
  • Disable sticky learning:
    • no switchport port-security mac-address sticky
      • Sticky addresses are converted to dynamic
  • Remove secure MACs from the table:
    • clear port-security {all | configured | dynamic | sticky}
  • Remove a specific MAC:
    • no switchport port-security mac-address MAC-ADDRESS
  • Modify port security on an interface for interaction with HSRP:
    • standby use-bia

Verify

  • Display port-security status and settings on an interface:
    • show port-security [interface INTERFACE [vlan] ] [address]
  • Display the maximum number of secure addresses allowed in the switch/stack:
    • show port-security
  • Display which causes are enabled/disabled for recovery, the recovery timeout value, and which interfaces will be recovered during the next timeout:
    • show errdisable recovery
  • Display the BIA MAC address used for HSRP:
    • show standby

Links

Private VLAN (+interaction with VTPv3)

Private VLANs address scalability and IP address management issues by partitioning a regular VLAN into subdomains. The subdomains are represented by a pair of VLANs: a primary and secondary. A primary VLAN can have multiple VLAN pairs, one pair for each subdomain. The secondary VLAN ID differentiates one subdomain from another. All members of a Private VLAN can share the same IP address space.

Each Private VLAN has only one Primary VLAN, with every port being a member. The Primary VLAN carries unidirectional traffic downstream from Promiscuous ports to other Promiscuous ports and to Isolated and Community ports.

Secondary VLANs can be one of two types:

  • Isolated, where ports in the same Isolated VLAN cannot communicate with each other at Layer 2. A Private VLAN has only one Isolated VLAN, which carries unidirectional traffic upstream to the Promiscuous ports.
  • Community, where ports within a Community VLAN can communicate with each other but not with ports in other communities at the Layer 2 level. There can be multiple Secondary Community VLANs in a Private VLAN. Community VLANs carry upstream traffic from the Community ports to both Promiscuous ports and other ports within the same Community.

Private VLAN ports are access ports that are one of three types:

  • Promiscuous, which belongs to the Primary VLAN and can communicate with all interfaces, including Community and Isolated
  • Isolated, which belongs to an Isolated Secondary VLAN and has complete Layer 2 separation from other parts within the same Private VLAN except for the Promiscuous ports. Traffic received from an Isolated port is forwarded only to Promiscuous ports
  • Community, which belongs to a Community Secondary VLAN, and can communicate with other Community ports in the same Community Secondary VLAN and Promiscuous ports

Trunk ports carry traffic from regular VLANs, as well as traffic from Primary, Isolated and Community VLANs. Through Trunking, Private VLANs can be distributed across multiple switches. Intermediary switches should also have Private VLANs configured, even if there are no ports that are members of the Private VLAN.

Other Information:

  • VTP version 1 & 2 do not support Private VLANs, so they must be manually configured on each switch when not using VTPv3. PVLANs are considered Extended VLANs, which VTPv3 can advertise.
  • SVIs can only be configured on the Primary VLAN. SVIs configured for Secondary VLANs are automatically inactive.
  • With switch stacks, Private VLAN connectivity is lost when the stack member containing Promiscuous ports is removed from the stack.
  • Only one STP instance runs for the entire Private VLAN. When a Secondary VLAN is associated with the Primary VLAN, the STP parameters of the Primary are propagated to the Secondary.
  • DHCP Snooping can be enabled on Private VLANs. When enabled on the Primary VLAN, it is propagated to the Secondary. If configured on the Secondary VLAN, the configuration does not take effect if the Primary is already configured.
  • IP Source Guard can be enabled on Private VLAN ports, but requires DHCP Snooping configured on the Primary VLAN.
  • Different QoS configurations can be applied to Primary, Isolated, and Community VLANs.
  • Private VLAN host or promiscuous ports cannot be a SPAN destination port. The port becomes inactive if configured as such
  • When configuring a static MAC address, it must be created on both Primary and Secondary VLANs (dynamic MAC addresses are replicated automatically)
  • You can configure 802.1x port-based authentication on a Private VLAN port, but do not configure 802.1x with port security, voice VLAN, or per-user ACL on Private VLAN ports

Defaults

  • No Private VLANs are configured by default.
  • If the switch is configured for VTPv1 or VTPv2, the switch must be set to Transparent mode to use Private VLANs.
  • If VLANs are not already created, the Private VLAN configuration process creates them.
  • You cannot configure VLAN 1 or 1002-1005 as Primary or Secondary VLANs. All other VLANs (including Extended range) can belong to Private VLANs.
  • Private VLAN configuration commands must be used to assign ports to Primary, Isolated, or Community VLANs. Layer 2 access ports assigned to VLANs configured as Primary, Isolated, or Community VLANs are inactive while the VLAN is part of the Private VLAN configuration.
  • When IGMP Snooping is enabled on the switch (which is the default), the switch/stack supports up to 20 Private VLAN domains.
  • Do not configure Private VLAN ports on interfaces that are also configured for:
    • Dynamic-access port VLAN membership
    • DTP
    • MVR Multicast VLAN Registration
    • Voice VLAN
    • WCCP
  • Newer IOS can support Private VLANs with EtherChannels (platform and version dependent)

Configure

  • Set VTP mode to Transparent, if using VTPv1 or VTPv1:
    • vtp mode transparent
  • Create Secondary VLAN and designate type:
    • vlan VLAN-ID
      • private-vlan {isolated | community}
      • exit
  • Create Primary VLAN and Associate Secondary VLANs:
    • vlan PRIMARY-VLAN-ID
      • private-vlan primary
      • private-vlan association [add | remove] SECONDARY-VLAN-LIST
      • exit
  • Assign VLAN membership to Isolated or Community host port:
    • interface INTERFACE-ID
      • switchport private-vlan host-association PRIMARY-VLAN SECONDARY-VLAN
      • switchport mode private-vlan host
  • Configure Promiscuous port(s) and Map to the Primary/Secondary VLAN pair:
    • interface INTERFACE-ID
      • switchport private-vlan mapping PRIMARY-VLAN {add | remove} SECONDARY-VLAN-LIST
      • switchport mode private-vlan promiscuous
  • Optionally create Primary SVI and map secondary VLANs to the Primary:
    • interface vlan PRIMARY-VLAN-ID
      • private-vlan mapping [add | remove] SECONDARY-VLAN-LIST
  • IMPORTANT: VLAN database configuration commands do not take effect until you exit VLAN configuration mode.

Verify

  • Display VLAN membership for ports:
    • show interfaces status
  • Display Private VLAN information for the switch/stack:
    • show vlan private-vlan [TYPE]
  • Display interface Private VLAN configuration:
    • show interface switchport
  • Display information about the Private VLAN mapping for VLAN SVIs:
    • show interface private-vlan mapping
  • IMPORTANT: After verification, save the running-config because VLANs are stored in the running configuration, not the vlan.dat file, when VTP is running in Transparent mode.

Links

802.1x, EAP, RADIUS

The 802.1x standard defines a client-server-based access control and authentication protocol that prevents unauthorized clients from connecting to the network through publicly accessible ports unless they are properly authenticated. Until the client is authenticated, 802.1x access control allows only EAPoL, CDP and STP traffic through the port to which the client is connected.

The 802.1x client (supplicant) replies to requests from the switch (authenticator). The client can send its identity to the switch on its own, or the switch can initiate communications by sending an EAP-request/identity frame to the client to request its identity. The switch communicates with the RADIUS authentication server on the client’s behalf and performs the actual authentication of the client. If authentication succeeds, the switch port becomes authorized. If authentication fails, the authentication can be retried, or the switch port can be assigned to a guest VLAN with limited functionality, or network access may be denied.

The switch encapsulates and decapsulates EAP frames. The switch receives EAPoL frames and relays them to the authentication server by stripping the Ethernet header and encapsulating the remaining EAP frame in the RADIUS format. The reverse happens when forwarding between the server and the client.

Upon successful authentication, the access VLAN can be set automatically on the switch port via username-to-VLAN mappings on the RADIUS server. Per-user ACLs are also supported.

RADIUS with EAP extensions is the only supported 802.1x port-based authentication server type. Individual ports can also be forced to authorized or unauthorized state.

Links

MAC Authentication Bypass

MAC Authentication Bypass allows the switch to authorize the port based on the client MAC address as the 802.1x client identity sent to the RADIUS server. If 802.1x authentication times out while waiting for an EAPoL response from the client, the switch tries to authenticate the client by using MAC authentication bypass.

If an EAPoL packet is detected on the interface during the lifetime of the link, the switch determines the client to be an 802.1x-capable supplicant and uses 802.1x authentication to authorize the interface. If the switch previously used MAC authentication bypass to authorize a port and later detects an 802.1x supplicant, the client is re-authenticated, but the port does not become unauthorized during the process. The MAC authentication bypass session can be terminated and forced through re-authentication after a timeout, depending on the RADIUS server settings.

Links

HSRP v1 and v2

HSRPv1 is the default setting, but v2 addresses many issues present in v1. HSRPv2 does not interoperate with v1 (though you can run different versions on different physical interfaces on the same device).

With HSRPv1, millisecond timers are not advertised or learned, whereas HSRPv2 does, which ensures stability of the HSRP groups in all cases. HSRPv1 groups are limited from 0 to 255, HSRPv2 expands the range to 4095. HSRPv1 uses the source MAC as the HSRP vMAC, which prevents you from using active hello messages to identify which physical device sent the message. HSRPv2 includes a 6-byte identifier field to uniquely identify the sender of the message (which is typically populated with the interface MAC address). HSRPv1 uses 224.0.0.2 UDP port 1985 to send HSRP hellos, which can conflict with the CGMP leave processing (which results in unicast flooding), HSRPv2 also introduces IPv6 support. HSRPv1 uses a default vMAC of 0000.0C07ACxx where xx is the group number in hexadecimal.

HSRPv2 uses 224.0.0.102 to send hellos, which allows CGMP leave processing to be enabled at the same time as HSRP. Since v2 has an expanded group number range, it uses a new MAC address range of 0000.0C9F.F000 - 0000.0C9F.FFFF. When the HSRP version number is changed, each group is reinitialized because it now uses the new vMAC. HSRPv2 uses a TLV packet format, and when v2 packets are received by a v1 device, the type field is mapped to the version field by v1 and subsequently ignored. HSRPv2 for IPv6 uses the address FF02::66 on UDP port 2029 with a vMAC of 0005.73a0.0xxx where xxx is the group number in hexadecimal.

HSRP uses jitter timers to improve the reliability of HSRP by reducing the chance of bunching of HSRP group operations, which helps reduce CPU and network traffic spikes. A given timer instance may take up to 20% more than the configured value. The hello timer has a negative jitter, and the holddown timer has a positive jitter.

When enabling HSRP on an interface, the bare minimum configuration is standby ip. However, all devices in the group will remain in the Learn state until the VIP is configured on at least one device. Configuration of the VIP on the Active router always overrides the VIP currently in use. When preemption is not enabled, the first router in the group to be configured with the VIP becomes Active, regardless of higher priorities or IP addresses of other devices. After the other routers in the group learn the VIP through hellos.

When HSRP is in the Active state on an interface, proxy ARP requests are answered using the vMAC of the HSRP group. If the interface is in any other HSRP state, proxy ARP responses are suppressed.

You can configure the initialization delay for a HSRP member. This is to prevent a former Active device from immediately taking over when it comes back online. This can work in conjunction with preemption to allow a router to preempt the current active, but after a configured delay period.The recommended settings are 30 seconds for the regular delay, and 60 seconds for the reload timer.

HSRP groups can become “redundancy clients” of other groups, where the client group takes its state from the master group it is following. Client groups must be on the same physical interface as the master group. Client groups do not use their configured timer, priority, or preemption settings. Client groups follow the master HSRP group with a slight random delay so that all client groups do not change at the same time.

You can specify the vMAC used by HSRP, which is useful for protocols that rely on knowing a specific MAC address, such as APPN Advanced Peer-to-Peer Networking, where an end node is typically configured with the MAC of the adjacent network node (instead of using an IP address).

HSRP supports preemption, where devices configured for a higher priority (or higher IP address when there is a tie) can assume the Active state without a failure having occurred. When HSRP preemption is combined with priority settings and object tracking, HSRP group members can dynamically become Active in reaction to other changes in the network besides direct interface failures. When a higher priority router preempts a lower priority router, it sends a “coup” message. When the lower priority router receives a “coup” message, or a hello from a higher priority active router, it changes to the speak state and sends a “resign” message.

Object tracking allows the HSRP member to adjust its priority based on the tracked objects, such as interface status or the availability of a particular IP route. Tracked objects that go down cause the HSRP member to decrement its priority by 10 by default. The priority decrement is cumulative when multiple tracked objects go down. Alternatively, the HSRP member can be configured to return to the Init state and become disabled rather than having its priority decremented. If the tracked object is an interface that is physically removed as in the case of OIR online insertion and removal, the tracked object remains down even when replaced, so you must use the no standby track command before physically removing the interface. When an object is already being tracked by an HSRP group, you cannot change to the shutdown feature - you must remove the standby track command and then re-enable it with the shutdown option.

The default Hello and Hold timers are 3 and 10 seconds, respectively, and can be adjusted. Hello can be adjusted between 1 and 254 seconds, or 15 and 999 milliseconds. The hold time range depends on the configured Hello time. When configured for seconds, the hold time has a range of the Hello time plus 50ms, then rounded up to the next second, up to 255. When the hold time is configured for milliseconds, the range is 3x the Hello (but not less than 50ms) up to 3000ms. The timers on the Active router are distributed via hellos (unless they are set to less than one second) and always override any locally configured values. All routers in a group should use the same values.

There can be an arbitrary number of members in the HSRP group, but at most one router will be in the Active state, one will be in the Standby state, and all others will be in the Listen state. After convergence, only the Active and Standby send periodic HSRP messages.

HSRP states: 0 Init, 1 Learn, 2 Listen, 4 Speak, 8 Standby, 16 Active

  • 0 Initial indicates that HSRP does not run. This state is entered through a configuration change or when an interface first becomes available
  • 1 Learn the router has not determined the VIP and has not yet seen an authenticated hello message from the active router. The router is waiting to hear from the active router
  • 2 Listen the router knows the VIP but the router is neither Active nor Standby. The router listens for hello messages from the active and standby
  • 4 Speak the router sends periodic hellos and actively participates in the election of the active and/or standby. A router cannot enter the Speak state unless it knows the VIP
  • 8 Standby the router is a candidate to become the next Active router and sends periodic hellos
  • 16 Active the router currently forwards packets that are sent to the group vMAC. The router sends periodic hellos

Defaults

  • HSRP is not enabled by default.
  • HSRPv1 is the default when enabling HSRP. HSRPv2 must be used for IPv6.
  • The default Hello time is 3 seconds. The default Hold time is 10 seconds.
  • The default HSRP group is 0 if not specified.
  • The default HSRP priority is 100.
  • HSRP sends one gratuitous ARP packet when a group becomes active, and then another two and four seconds later.
  • HSRP group initialization is not delayed by default.
  • HSRPv1 default vMAC address is 0000.0C07.ACxx where xx is the group number in hexadecimal.
  • HSRPv2 default vMAC address is 0000.0C9F.Fxxx where xxx is the group number in hexadecimal.
  • HSRPv2 default vMAC address for IPv6 is 0005.73a0.0xxx where xxx is the group number in hexadecimal.
  • Preemption is disabled by default. When enabled, the default group is 0 with no default delay.
  • HSRP is enabled for SSO by default.
  • Object tracking is disabled by default. When enabled, the default decrement value is 10.

Configure

  • Enable HSRP at the interface level:
    • standby GROUP ip VIRTUAL-IP [secondary]
      • Note: standby ip is the absolute minimal configuration required. The default group is 0 if not specified. The secondary keyword enables HSRP for secondary IP addresses, if configured on the interface. HSRP will not progress past the Learn state unless at least one group member is configured with the VIP.
  • Optional Settings:
    • Configure the number of gratuitous ARP packets sent (and how often) by a HSRP group when it transitions into the Active state:
      • standby arp gratuitous [count NUMBER] [interval SECONDS]
    • Configure HSRP to send a single gratuitous ARP packet for each active group to ensure the ARP cache is accurate:
      • standby send arp [INTERFACE [GROUP]]
        • HSRP checks that the VIP is entered correctly in the ARP cache prior to sending a gratuitous ARP packet. If the entry is incorrect, HSRP attempts to re-add it. This enables you to ensure that a host ARP cache is updated prior to starting heavy CPU-usage processes or configurations.
    • Configure the delay before HSRP group initialization:
      • standby delay minimum SECONDS [reload RELOAD-SECONDS]
        • 1 is the default value, with 30 seconds being a common configuration. The reload timer affects initialization delay after the device has been reloaded. 5 is the default, with 60 being a common configuration.
    • Enable the HSRP group to become a client group and follow the state and use the settings of the master group:
      • standby GROUP follow GROUP-NAME
        • Note: a client group cannot become the client of another client group.
    • Specify the vMAC to by used for the HSRP group:
      • standby [GROUP] mac-address MAC-ADDRESS
        • This value needs to be set to the same on all participating members, otherwise HSRP will re-initialize every time the Active router changes.
    • Configure a group name for the interface, which is used for HSRP client groups, and other features:
      • standby name GROUP-NAME
    • Enable preemption:
      • standby [GROUP] preempt [delay { [minimum SECONDS] [reload SECONDS] [sync SECONDS] }
        • When configured without options, the group is 0 with no delay. The minimum keyword prevents preemption until the configured number of seconds have passed. The reload keyword is similar, but applies only after the device is reloaded, and the timer starts at the interface-up event. The sync keyword applies to the maximum sync period for IP redundancy clients, who can prevent preemption from occurring until the timer expires.
    • Specify the priority for the HSRP group member, with 100 being the default, and higher priority being better:
      • standby [GROUP] priority PRIORITY
    • Enable SSO integration with HSRP (enabled by default on supported platforms):
      • standby sso
        • Use the no form of this command to disable integration when you wish to manually switch over to another RP.
    • Adjust the hello and hold timers, whose defaults are 3 seconds, and 10 seconds respectively:
      • standby [GROUP] timers [msec] HELLO-TIME [msec] HOLD-TIME
        • The configurable ranges force the holdtime to always be at least three times the hello time.
    • Automatically adjust the HSRP priority based on a tracked object:
      • standby track OBJECT [decrement VALUE] [shutdown]
        • The object must be created first globally with the track command. The decrement and shutdown keywords are mutually exclusive, and you cannot change between them - you must remove the configuration and then re-enable it.
    • Use the interface’s MAC for the vMAC instead of the standard vMAC based on group membership:
      • standby use-bia [scope interface]
        • The scope interface keyword is used with subinterfaces. Using this option breaks the proxy-arp functionality.
    • Change the HSRP version being used:
      • standby version {1 | 2}
        • Version 1 is the default, version 2 addresses limitations of v1 and is required for IPv6.

Verify

  • Display the HSRP interfaces, groups, priorities, state, active and standby devices, and VIP:
    • show standby brief
  • Display detailed information about all HSRP groups:
    • show standby
  • Display the number and configured interval of GARP packets sent by HSRP:
    • show standby arp gratuitous
  • Display the current delay timers:
    • show standby delay
      • Minimum is the time in seconds to delay HSRP group initialization after an interface comes up. Reload is the time in seconds to delay after the router has reloaded.
  • Display information about tracked objects:
    • show track
  • Display realtime information about the HSRP process:
    • debug standby [events | errors | packets | terse]
  • Filters the HSRP debug output to the interface and group:
    • debug condition standby INTERFACE GROUP

Links

HSRP Group Shutdown

HSRP Group Shutdown allows you to configure an HSRP group to become disabled (its state changed to Init) instead of having its priority decremented when a tracked object goes down. If the object is already tracked by the HSRP group, you cannot change the configuration to use the HSRP group shutdown feature; you must first remove the tracking configuration with no standby track and then reconfigure it.

Defaults

  • Object tracking and HSRP group shutdown are not enabled by default.

Configure

  • Globally create the tracked object:
    • track OBJECT-NUMBER interface INTERFACE {line-protocol | ip routing}
  • Configure HSRP group shutdown on the interface:
    • standby GROUP track OBJECT-NUMBER shutdown

Verify

  • Display information and the status of tracked objects:
    • show track

Links

HSRP MD5 Authentication

HSRP MD5 authentication provides added security and protects against HSRP spoofing. When enabled, each HSRP group member uses a key to generate an MD5 hash that is part of the outgoing packet. A hash of the incoming packet is generated and if the generated hash does not match the packet, the packet is ignored. The key can be supplied directly via key string, or indirectly through a key chain.

Defaults

  • The default HSRP authentication type is plaintext

Configure

  • Key chain method:
    • Configure key chain globally:
      • key chain NAME
        • key KEY-ID
          • key-string STRING
    • Configure HSRP interface MD5 key chain authentication:
      • standby GROUP authentication md5 key-chain KEY-CHAIN-NAME
  • Interface key string method:
    • standby GROUP authentication md5 key-string STRING

Verify

  • Display HSRP group status:
    • show standby
  • Display HSRP process to determine if there are authentication errors:
    • debug standby errors

Links

HSRP Support for ICMP Redirects

HSRP automatically filters outgoing ICMP redirect messages and changes the next hop IP to the group VIP. The next-hop IP is compared to the list of active HSRP devices on the network, and if a match is found, the real next-hop IP is replaced with the VIP and the redirect message is allowed to continue. If there is no match, the ICMP redirect is sent only if the device corresponding to the new next-hop IP is not running HSRP. Redirects to passive HSRP devices (devices running HSRP but have not active groups on the interface) are not allowed.

Defaults

  • HSRP filtering of ICMP redirect messages is enabled by default on devices running HSRP

Configure

  • Enable on the interface if it has been disabled previously:
    • standby redirect [timers ADVERTISEMENT HOLDDOWN] [unknown]
  • The command no standby redirect unknown prevents ICMP redirects from being sent to non-HSRP devices (enabled by default)

Verify

  • Display redirect status, timers, VIPs and vMACs for each group:
    • show standby redirect

Links

HSRP Multiple Group Optimization

When multiple HSRP groups are maintained on subinterfaces, each one requires additional state and processing load. You can enable a master HSRP group, and have the subsequent groups on the subinterfaces linked to the master group instead of requiring their own processing. Client groups do not participate in any device election mechanisms and rely solely on the state of the master group. Client groups send periodic messages to refresh the vMAC. Client groups must be on the same physical interface as the master group.

Additionally, configuring multiple HSRP groups can facilitate load sharing by having different active devices for different groups. For example, two routers can be configured with different groups and a different VIP, but be in the same subnet. End hosts could be configured (either manually or via DHCP) to use one VIP or another by default, but both VIPs are always available due to HSRP. This is also referred to as MHSRP.

Defaults

  • Group optimization is not enabled by default and must be configured manually based on the network design.

Configure

  • Enable the name feature on the master HSRP group:
    • standby name GROUP-NAME
  • Configure the client group to follow the master group:
    • standby GROUP follow GROUP-NAME

Verify

  • Display the HSRP status:
    • show standby

Links

VRRPv2

VRRP is an election protocol that allows several routers on a multiaccess link to utilize the same virtual IP address. With VRRP, one router is elected the virtual router master, while the others act as a backup on case the virtual router master fails. A VRRP group is a group of routers representing a single virtual router for clients to use as their default gateway. VRRP is available for Ethernet-based interfaces including VRFs and VLANs.VRRP does not work on serial interfaces. VRRP must be in the Master state for proxy ARP to use the VRRP vMAC address (primary IP address).

The configured VIP can also be used on a router’s physical interface, in which case that router becomes the Master. If the Master fails, the router configured with the highest priority (or highest IP address if there is a tie in priority) becomes the Master to provide uninterrupted service. When the original Master recovers, it becomes Master again (whether or not preemption is disabled). The priority range is 1 - 254, with 100 being the default. Preemption is enabled by default.

VRRP can manage multiple IP addresses, including secondaries. VRRP can also facilitate load sharing in the same manner as MHSRP with multiple Master routers with different VIPs. VRRP supports automatic priority adjustments with object tracking. The VIP configured on the Master router always overrides any other configured VIP. All routers in the VRRP group must be configured with the same primary address for the virtual router. If different primary addresses are configured, the routers in the group will not communicate with each other and any misconfigured routers will change their state to Master. If you remove the VRRP configuration from the Master router that is using the interface IP address as the primary, there will be duplicate IP addresses on the network. If VRRP is configured this way and you need to remove its configuration, change the interface IP address first.

VRRP uses 224.0.0.18 for advertisements with IP Protocol 112 for transport. The VRRP vMAC is 0000.5e00.01xx where XX is the VRRP group in hexadecimal. VRRP does not accept a virtual group number 0 and never has an empty group. The valid range for VRRP group numbers is 1 - 255. VRRP does not support address learning; all addresses must be manually configured.

The Master sends VRRP advertisements to other VRRP routers in the same group which communicate the priority and state of the Master. The default advertisement interval is one second. The VRRPv2 RFC (3768) does not support millisecond timers, but Cisco’s implementation does support it through manual configuration of the master and backup, though show vrrp will still only show 1 second. Use of millisecond timers is limited to Cisco equipment only, and is not recommended. The range is 50ms - 999ms, or 1 - 255 seconds. The timers set on the Master always override other timers. All routers in a VRRP group must be configured with the same timer values or they will not communicate, and any misconfigured router will become a Master. The hold time is not configurable, and is 3x the advertisement interval plus a skew time which is calculated as ((256 - VRRP priority) / 256), where routers with a higher priority will have a shorter skew time. The default advertisement interval of 1 with a priority of 100 yields the default hold time as 3.609 seconds using the formula (3 * 1) + (256 - 100)/256)

VRRP ignores unauthenticated messages, and supports plaintext, MD5 string, and MD5 key chains. You can set a timeout delay for authentication where the old key string is accepted along with the new key string to help prevent route flapping. You should change the key on the Master last.

VRRP supports ISSU via SSO on supported platforms with redundant RPs. This feature is enabled by default on supported platforms.

VRRP initialization can be delayed for all groups on an interface, though not configured by default. The recommended setting is 30 seconds delay, 60 seconds for reload.

VRRP groups can be linked by name to a VRRS Virtual Router Redundancy Service client. VRRP provides stateless redundancy for IP routing and by itself is limited to maintaining its own state. However, linking a VRRS client to a VRRP group allows client applications to implement stateful failover. IP redundancy clients are other Cisco IOS processes or applications that use VRRP to provide or withhold a service or resource dependent upon the state of the group.

Defaults

  • A VRRP router is the virtual router Master when it owns the IP address of the virtual router and the IP address of the physical interface.
  • The default priority is 100.
  • Preemption is enabled by default. There is no preemption delay by default.
  • The default master advertisement (hello) interval is 1 second.
  • SSO integration with VRRP is enabled by default on supported platforms.
  • VRRP authentication is disabled by default.
  • There is no initialization delay by default.
  • VRRP groups are not configured with description strings by default.
  • Object tracking is not enabled by default, but has a default priority decrement value of 10 when it is.

Configure

  • VRRP groups become operational as soon as they are enabled. If you intend to optionally customize VRRP operations, you should configure the options before enabling the VRRP group otherwise it is possible for an unintended router to become and remain the VRRP Master.
  • You can deactivate a VRRP group on an interface while retaining its configuration:
    • vrrp GROUP shutdown
  • Enable VRRP on an interface:
    • vrrp GROUP ip VIRTUAL-IP [secondary]
      • All routers in the VRRP group must be configured with the same primary address and a matching list of secondary addresses. If different addresses are configured, the routers in the VRRP group will not communicate with each other.
  • Optionally add a description for the group:
    • vrrp GROUP description STRING
  • Optionally adjust the priority level:
    • vrrp GROUP priority LEVEL
  • Optionally adjust the preemption timer:
    • vrrp GROUP preempt delay minimum SECONDS
      • The router that is the IP address owner will preempt, regardless of this setting.
  • Optionally configure a delay before VRRP is initialized:
    • vrrp delay {minimum SECONDS [reload SECONDS] | reload SECONDS}
      • This command applies to all groups on an interface and cannot be configured per-group. The reload timer specifies how long to wait after a router reload.
  • Optionally adjust the master advertisement (hello) interval:
    • vrrp GROUP timers advertise [msec] INTERVAL
      • Without the msec keyword, the interval is in seconds.
  • Optionally configure the router to learn the advertisement interval used by the Master when it is acting as a backup:
    • vrrp GROUP timers learn
  • Optionally disable SSO integration:
    • no vrrp sso
      • This command can be used when you wish to manually restart VRRP on a different RP.
  • Optionally enable object tracking on an interface:
    • vrrp GROUP track OBJECT-NUMBER [decrement PRIORITY]
      • Tracked object must be created globally first with the track command
  • Optionally enable MD5 authentication with a key string:
    • vrrp GROUP authentication md5 key-string STRING [timeout SECONDS]
      • The timeout value is how long the router will continue to accept the old key when the key is changed.
  • Optionally enable MD5 authentication with a key chain:
    • vrrp GROUP authentication md5 key-chain KEY-CHAIN
      • Key chain must be created globally first
  • Optionally enable text authentication:
    • vrrp GROUP authentication text STRING
  • Optionally link a VRRS client to a VRRP group by name:
    • vrrp GROUP name NAME
    • vrrs follow NAME
      • NOTE: VRRS is configured only on subinterfaces.

Verify

  • Display information about VRRP including groups and timers:
    • show vrrp [group] [brief]
  • Display information about VRRP on particular interfaces:
    • show vrrp interface INTERFACE [brief]
  • Display information about tracked objects:
    • show track
  • Display realtime information about VRRP authentication attempts:
    • debug vrrp authentication
  • Display realtime information about all VRRP processes:
    • debug vrrp all

Links

VRRPv3

VRRPv3 introduces support for IPv6. When VRRPv3 is in use, VRRPv2 is unavailable on the device (with the exception of the compatibility mode option on the interface).

VRRPv3 uses multicast for advertisements. It continues to use 224.0.0.18 for IPv4, and FF02::12 for IPv6. Both use IP Protocol 112 for transport.

VRRPv3 supports millisecond timers across vendors, whereas VRRPv2 only had millisecond timer support for Cisco devices.

VRRPv3 does not support SSO integration.

VRRPv3 does not change operations over v2, and the commands are mostly identical and configured in VRRP address family mode on the interface.

Defaults

  • VRRPv2 interoperability is disabled by default.

Configure

  • Enable the device for VRRPv3 mode globally:
    • fhrp version vrrp v3
  • VRRPv3 is configured on interfaces in address family mode where the address family must be specified before further configuration:
    • vrrp GROUP address-family {ipv4 | ipv6}
  • Configure the address to be used for the VIP:
    • address IP-ADDRESS [primary | secondary]
      • VRRPv3 requires a primary virtual link-local address for the group. After this address is specified, a global address(es) may be used for the secondary
  • Optionally enable VRRPv2 interoperability:
    • vrrpv2
  • Most of the remaining commands are identical to their VRRPv2 counterparts without being prefaced by “vrrp”. For example, “description” instead of “vrrp description”

Verify

  • Display information about VRRP groups:
    • show vrrp detail

Links

GLBP

GLBP protects data traffic from a failed device or circuit while allowing packet load sharing between a group of redundant devices. Each host is configured with the same VIP, and all devices in the virtual group participate in forwarding packets.

GLBP members communicate with each other through hello messages send every 3 seconds to 224.0.0.102 using UDP 3222 for source and destination

GLBP uses three different packet types: Hello, Request, Reply. Hellos are used to advertise protocol information via multicast, and are sent when any virtual gateway or virtual forwarder is in Speak, Standby, or Active state. Request and Reply packets are used for virtual MAC assignments, and are both unicast messages to and from the AVG Active Virtual Gateway.

Members of a GLBP group elect one device to be the AVG for the group, and the remaining group members provide backup for the AVG if it becomes unavailable. The AVG assigns a virtual MAC address to each member of the GLBP group, and each device is responsible for forwarding packets sent to its vMAC. The non-AVG devices are AVFs Active Virtual Forwarders. The AVG is responsible for answering ARP requests for the VIP, and load sharing is achieved by the AVG replying to the ARP requests with different vMACs.  GLBP groups can contain up to four vMACs. Other group members request a vMAC after they discover the AVG through hello messages. A virtual forwarder that has been assigned a vMAC by the AVG is a primary VF. Other members of the GLBP group learn the vMAC from hellos messages. A VF that has learned the vMAC is a secondary VF.

GLBP uses the vMACs 0007.b40X.XXYY where XXX is the GLBP group, and YY is the router number (01, 02, 03, 04).

Virtual gateway redundancy is similar to HSRP in that one gateway is elected the AVG, another is the standby, and the remaining gateways are placed into Listen state. If the AVG fails, the standby is promoted, and a new standby is elected from the gateways in Listen state. Likewise, if a primary AVF fails, a secondary VF assumes the vMAC and becomes an AVF. The new AVF has a different forwarder number from the old failed AVF and GLBP migrates hosts away from the old forwarder number using two timers that start as soon as the gateway changes to the AVF state.

The timers are sent in hello messages. The Redirect time is the interval during which the AVG continues to redirect hosts to the old VF vMAC. When the Redirect time expires, the AVG stops using the old VF vMAC in ARP replies, though the VF will continue to forward packets sent to the old VF vMAC. The Secondary Holdtime is the interval during which the VF is valid. When the Secondary Holdtime expires, the VF is removed from all gateways in the GLBP group, and the expired VF number becomes eligible for reassignment by the AVG. During the timer period, the new AVF responds to packets for two MACs - its own, and the vMAC it assumed from the failed VF.

GLBP gateway priority is based on configured priority from 1 to 255, or the highest IP address if the priorities match. Preemption is disabled by default, and a backup AVG can only be promoted if the current AVG fails, regardless of configured priorities. GLBP uses weighting to determine the proportion of traffic forwarded through each AVF. Thresholds can be set to disable forwarding when the weighting for a GLBP group falls below a certain value, and automatically re-enabled when the threshold rises to the upper value (which is the max value by default). GLBP group weighting can be adjusted automatically with object tracking. When object tracking is enabled, the default is to decrement the weighting by 10 when the tracked interface goes down, and increment by 10 when the interface comes back up. When multiple tracked interfaces are down, the configured weighting decrements are cumulative. GLBP AVF preemption is enabled by default with a delay of 30 seconds, where a secondary VF can preempt a primary VF (AVF) if its weighting falls below a threshold for 30 seconds.

The GLBP client cache, which is disabled by default, caches host clients using the GLBP VIP for their default gateway. When an ARP or ND request for the VIP is made, the AVG creates a new entry in the client cache containing the MAC of the host, the number of the AVF the host has been assigned to, and the total number of network hosts currently assigned to each forwarder in the GLBP group. The client cache also stores the protocol address used by each host and the time elapsed since the host-to-forwarder assignment was last updated. The client cache can store information on up to 2000 hosts per GLBP group, with an expected normal max of 1000.  When the max is reached, the oldest entry is discarded when a new client is added. The GLBP client cache can be enabled and disabled per GLBP group.

GLBP can use MD5 authentication both directly and via key chains. Plaintext authentication can also be used.

GLBP supports ISSU through SSO. SSO is enabled by default on supported platforms. If SSO is disabled, when the RP is switched, GLBP relinquishes its activity as a GLBP group member and rejoins as if it had been reloaded.

GLBP supports up to 1024 virtual devices (GLBP groups) oh each physical interface of a device and up to four VFs per group.

GLBP was introduced in IOS 12.2(14)S, 12.2(15)T, 15.0(1)S

Defaults

  • GLBP is disabled by default.
  • The default GLBP Hello interval is 3 seconds, and the default Hold time is 10 seconds.
  • GLBP authentication is disabled by default.
  • GLBP AVG Preemption is disabled by default. When enabled, the default timer is 30 seconds.
  • GLBP AVF Preemption is enabled by default with a delay of 30 seconds.
  • The default load balancing method is round-robin.
  • GLBP client cache is disabled by default.
  • SSO support is enabled by default on supported platforms.
  • The AVG redirect timer has a default of 10 minutes (600 seconds), with a default timeout of 14,400 seconds (4 hours)
  • The default AVG priority is 100, with higher numbers more preferred. When priorities are the same, the gateway with the highest IP address in the group is the AVG.
  • The default gateway weighting value is 100 and the default lower value is 1. The default upper value is the specified maximum value.
  • The default object tracking decrement value is 10. Objects are not tracked for GLBP weighting changes by default.

Configure

  • The GLBP forwarder requires devices that can support multiple MAC addresses on the physical interface. Enhanced Object Tracking is not SSO aware and cannot be used with GLBP in SSO mode.
  • Each gateway in a GLBP group must be configured with the same group number, and at least one gateway in the group must be configured with the VIP to be used by the group – all other required parameters can be learned.
  • If VLANs are in use on an interface, the GLBP group number must be different for each VLAN.
  • Basic GLBP configuration on an interface:
    • glbp GROUP ip [IP [secondary]]
      • At least one GLBP member must be configured with the VIP, the others can learn it through hellos. If the IP is not specified on at least one group member, the group remains disabled. The specified IP must be in the same subnet as the interface IP address. Specifying the VIP on the AVG always overrides the current designated address in use.
  • GLBP customization options on the interface (recommended to configure before enabling GLBP for the group):
    • glbp GROUP timers [msec] HELLO [msec] HOLD
      • Default Hello is 3s, default Hold is 10s. Timers configured on the AVG always override any other timer settings. All routers in a group should use the same timer values.
    • glbp GROUP timers redirect REDIRECT-TIME TIMEOUT
      • 0 causes the timer to never expire and is not a recommended setting. The timer must be long enough to allow all hosts to refresh their ARP cache entry that contained the vMAC.
    • glbp GROUP load-balancing [host-dependent | round-robin | weighted]
      • Specifies the method of load balancing by the AVG. Host-dependent makes certain that a particular end host uses the same VF each time. Round-robin is the default, each VF in turn is included in ARP replies for the VIP. Weighted is dependent upon the weighting value advertised by the gateway, which enables unequal load distribution and is useful when the routers have different forwarding capabilities. When the no form of the command is issued, if the AVG does not have an AVF, it preferentially replies to ARP requests with the MAC of the first listening VF.
    • glbp GROUP priority LEVEL
    • glbp GROUP preempt [delay minimum SECONDS]
      • A device can become the AVG if it has a higher priority than the current, with an optional delay before preemption occurs. The default is 30 seconds when preemption is enabled.
    • glbp GROUP client-cache maximum NUMBER [timeout MINUTES]
      • Enables the GLBP client cache and specifies the maximum number of clients in the cache from 8 to 2000. For IPv4, Cisco recommends a cache timeout value slightly longer than the max expected end-host ARP cache timeout value. This command enables the cache for the specified group only. You must run this command for each group for which you wish to enable the cache on. When the cache already exists, if the maximum value is set lower than the current number of cached clients, all the existing cache entries are discarded. When disabling the cache after it was previously enabled, all cache entries are discarded before the cache is disabled.
    • glbp GROUP name REDUNDANCY-NAME
      • Enables redundancy by assigning a name to the GLBP group. The redundancy client must be configured with the same GLBP group name. This is used in conjunction with the Stateful NAT redundancy command (which is the “redundancy client”)
    • Global: no glbp sso
      • Disables SSO support in GLBP
    • GLBP MD5 Authentication with a Key String on an interface:
      • glbp GROUP authentication md5 key-string KEY
  • GLBP MD5 Authentication with a Key Chain on an interface:
    • glbp GROUP authentication md5 key-chain KEYCHAIN
      • NOTE: Key chain must be configured globally
  • GLBP MD5 Authentication with Plaintext on an interface:
    • glbp GROUP authentication text STRING
  • GLBP weighting values and object tracking:
    • Global: track OBJECT-NUMBER interface INTERFACE {line-protocol | ip routing}
      • Where the line-protocol keyword checks the interface status, and ip routing additionally checks that IP routing is enabled on the interface and that an IP address is configured
    • Interface: glbp GROUP weighting track OBJECT-NUMBER [decrement VALUE]
    • Interface: glbp GROUP weighting MAXIMUM [lower LOWER] [upper UPPER]
      • Where MAXIMUM is the initial weighting value, and the other two values are the upper and lower thresholds. The default lower is 1, and the default upper is the same as the configured (or default) maximum.
    • Interface: glbp GROUP forwarder preempt [delay minimum SECONDS]
      • Enabled by default with a delay of 30 seconds if the current AVF falls below its low threshold, with an optional delay before preemption occurs

Verify

  • Display information about GLBP groups and their status:
    • show glbp [brief]
  • Run this on the AVG to get the most information including client cache statistics:
    • show glbp detail  
  • Display configured authentication keys:
    • show key chain
  • Display information about tracked objects:
    • show track
  • Filter debug information to a particular interface and group:
    • debug condition glbp INTERFACE GROUP
  • Display realtime information about GLBP processes:
    • debug glbp [errors | events | packets | terse]

Links

Here are the links to the Google Docs versions. These exist because before I discovered the powers of Anki, I was still taking traditional notes, and it was my intention to create a single large document for every item on the CCIE blueprint. I made a decent dent in the process (this posting alone is 25,000 words and is not inclusive of all the other notes I’d taken that don’t pertain to the SWITCH exam), but I realized I wasn’t retaining the information from the individual topics. I discovered it to be a waste of time (for me personally) to both take direct notes and create Anki flashcards. I learned that I learn best by taking notes directly as Anki flashcards in Question & Answer format. I highly recommend reading my posting on creating meaningful flashcards for more details about this process.

The SWITCH-related topics in Google Docs format: