Table of Contents

Preface

New and Changed Information

Overview

Configuring IPv4

Configuring IPv6

Configuring GLBP

Configuring HSRP

Customer Object Tracking

IETF RFCs

Cisco Prime DCNM Unicast Management Guide, Release 7.0

Preface

This document describes the configuration details for Cisco NX-OS unicast routing in Cisco Data Center Network Manager (DCNM).

Audience

To use this guide, you must be familiar with IP and routing technology.

Organization

This document is organized into the following chapters:

Title

Description

Chapter 1, “Overview”

Presents an overview of unicast routing and brief descriptions of each feature.

Chapter 2, “Configuring IPv4”

Describes how to configure and manage IPv4, including ARP and ICMP.

Chapter 3, “Configuring IPv6”

Describes how to configure and manage IPv6.

Chapter 4, “Configuring GLBP”

Describes how to configure GLBP.

Chapter 5, “Configuring HSRP”

Describes how to configure the Hot Standby Routing Protocol.

Chapter 6, “Configuring Object Tracking”

Describes how to configure object tracking.

Appendix 7, “IETF RFCs supported by Cisco NX-OS Unicast Features, Release 7.0x”

Lists IETF RFCs supported by Cisco NX-OS.

Document Conventions

Command descriptions use these conventions:

Convention

Description

boldface font

Commands and keywords are in boldface.

italic font

Arguments for which you supply values are in italics.

[ ]

Elements in square brackets are optional.

[ x | y | z ]

Optional alternative keywords are grouped in brackets and separated by vertical bars.

string

A nonquoted set of characters. Do not use quotation marks around the string or the string will include the quotation marks.

Screen examples use these conventions:

screen font

Terminal sessions and information that the switch displays are in screen font.

boldface screen font

Information that you must enter is in boldface screen font.

italic screen font

Arguments for which you supply values are in italic screen font.

< >

Nonprinting characters, such as passwords, are in angle brackets.

[ ]

Default responses to system prompts are in square brackets.

!, #

An exclamation point (!) or a pound sign (#) at the beginning of a line of code indicates a comment line.

This document uses the following conventions:

Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the manual.

Caution Means reader be careful. In this situation, you might do something that could result in equipment damage or loss of data.

Related Documentation

This section contains information about the documentation available for Cisco DCNM and for the platforms that Cisco DCNM manages.

This section includes the following topics:

- Cisco DCNM Documentation

- Cisco Nexus 1000V Series Switch Documentation

- Cisco Nexus 2000 Series Fabric Extender Documentation

- Cisco Nexus 3000 Series Switch Documentation

- Cisco Nexus 4000 Series Switch Documentation

- Cisco Nexus 5000 Series Switch Documentation

- Cisco Nexus 7000 Series Switch Documentation

Cisco DCNM Documentation

The Cisco DCNM documentation is available at the following URL:

http://www.cisco.com/en/US/products/ps9369/tsd_products_support_series_home.html

The documentation set for Cisco DCNM includes the following documents:

Release Notes

Cisco DCNM Release Notes, Release 7.x

Installation and Licensing

Fundamentals Configuration Guide, Cisco DCNM for SAN

Cisco DCNM Installation and Licensing Guide, Release 6.x

Cisco DCNM for LAN Configuration Guides

FabricPath Configuration Guide, Cisco DCNM for LAN, Release 6.x

Interfaces Configuration Guide, Cisco DCNM for LAN, Release 6.x

Layer 2 Switching Configuration Guide, Cisco DCNM for LAN, Release 6.x

Security Configuration Guide, Cisco DCNM for LAN, Release 6.x

System Management Configuration Guide, Cisco DCNM for LAN, Release 6.x

Unicast Configuration Guide, Cisco DCNM for LAN, Release 6.x

Virtual Device Context Configuration Guide, Cisco DCNM for LAN, Release 6.x

Virtual Device Context Quick Start, Cisco DCNM for LAN

Web Services API Guide, Cisco DCNM for LAN, Release 6.x

Cisco DCNM for SAN Configuration Guides

Fabric Configuration Guide, Cisco DCNM for SAN

High Availability and Redundancy Configuration Guide, Cisco DCNM for SAN

Intelligent Storage Services Configuration Guide, Cisco DCNM for SAN

Inter-VSAN Routing Configuration Guide, Cisco DCNM for SAN

Interfaces Configuration Guide, Cisco DCNM for SAN

IP Services Configuration Guide, Cisco DCNM for SAN

Quality of Service Configuration Guide, Cisco DCNM for SAN

Security Configuration Guide, Cisco DCNM for SAN

SME Configuration Guide, Cisco DCNM for SAN

System Management Configuration Guide, Cisco DCNM for SAN

Cisco Nexus 1000V Series Switch Documentation

The Cisco Nexus 1000V Series Switch documentation is available at the following URL:

http://www.cisco.com/en/US/products/ps9902/tsd_products_support_series_home.html

Cisco Nexus 2000 Series Fabric Extender Documentation

The Cisco Nexus 2000 Series Fabric Extender documentation is available at the following URL:

http://www.cisco.com/en/US/products/ps10110/tsd_products_support_series_home.html

Cisco Nexus 3000 Series Switch Documentation

The Cisco Nexus 3000 Series switch documentation is available at the following URL:

http://www.cisco.com/en/US/products/ps11541/tsd_products_support_series_home.html

Cisco Nexus 4000 Series Switch Documentation

The Cisco Nexus 4000 Series Switch documentation is available at the following URL:

http://www.cisco.com/en/US/products/ps10596/tsd_products_support_series_home.html

Cisco Nexus 5000 Series Switch Documentation

The Cisco Nexus 5000 Series Switch documentation is available at the following URL:

http://www.cisco.com/en/US/products/ps9670/tsd_products_support_series_home.html

Cisco Nexus 7000 Series Switch Documentation

The Cisco Nexus 7000 Series Switch documentation is available at the following URL:

http://www.cisco.com/en/US/products/ps9902/tsd_products_support_series_home.html

Related Documentation

Cisco NX-OS includes the following documents:

Release Notes

Cisco Nexus 7000 Series NX-OS Release Notes, Release 5.x

NX-OS Configuration Guides

Cisco Nexus 7000 Series NX-OS Configuration Examples, Release 5.x

Configuring the Cisco Nexus 2000 Series Fabric Extender

Cisco Nexus 7000 Series NX-OS FabricPath Configuration Guide

Configuring Feature Set for FabricPath

Cisco NX-OS FCoE Configuration Guide for Cisco Nexus 7000 and Cisco MDS 9500

Cisco Nexus 7000 Series NX-OS Fundamentals Configuration Guide

Cisco Nexus 7000 Series NX-OS High Availability and Redundancy Guide

Cisco Nexus 7000 Series NX-OS Interfaces Configuration Guide

Cisco Nexus 7000 Series NX-OS Layer 2 Switching Configuration Guide

Cisco Nexus 7000 Series NX-OS LISP Configuration Guide

Cisco Nexus 7000 Series NX-OS MPLS Configuration Guide

Cisco Nexus 7000 Series NX-OS Multicast Routing Configuration Guide

Cisco Nexus 7000 Series NX-OS OTV Configuration Guide

Cisco Nexus 7000 Series OTV Quick Start Guide

Cisco Nexus 7000 Series NX-OS Quality of Service Configuration Guide

Cisco Nexus 7000 Series NX-OS SAN Switching Configuration Guide

Cisco Nexus 7000 Series NX-OS Security Configuration Guide

Cisco Nexus 7000 Series NX-OS System Management Configuration Guide

Cisco Nexus 7000 Series NX-OS Unicast Routing Configuration Guide

Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide

Cisco Nexus 7000 Series NX-OS Virtual Device Context Quick Start

NX-OS Command References

Cisco Nexus 7000 Series NX-OS Command Reference Master Index

Cisco Nexus 7000 Series NX-OS FabricPath Command Reference

Cisco NX-OS FCoE Command Reference for Cisco Nexus 7000 and Cisco MDS 9500

Cisco Nexus 7000 Series NX-OS Fundamentals Command Reference

Cisco Nexus 7000 Series NX-OS High Availability Command Reference

Cisco Nexus 7000 Series NX-OS Interfaces Command Reference

Cisco Nexus 7000 Series NX-OS Layer 2 Switching Command Reference

Cisco Nexus 7000 Series NX-OS LISP Command Reference

Cisco Nexus 7000 Series NX-OS MPLS Command Reference

Cisco Nexus 7000 Series NX-OS Multicast Routing Command Reference

Cisco Nexus 7000 Series NX-OS OTV Command Reference

Cisco Nexus 7000 Series NX-OS Quality of Service Command Reference

Cisco Nexus 7000 Series NX-OS SAN Switching Command Reference

Cisco Nexus 7000 Series NX-OS Security Command Reference

Cisco Nexus 7000 Series NX-OS System Management Command Reference

Cisco Nexus 7000 Series NX-OS Unicast Routing Command Reference

Cisco Nexus 7000 Series NX-OS Virtual Device Context Command Reference

Other Software Documents

Cisco NX-OS Licensing Guide

Cisco Nexus 7000 Series NX-OS MIB Quick Reference

Cisco Nexus 7000 Series NX-OS Software Upgrade and Downgrade Guide

Cisco NX-OS System Messages Reference

Cisco Nexus 7000 Series NX-OS Troubleshooting Guide

Cisco NX-OS XML Interface User Guide

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What’s New in Cisco Product Documentation , which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to the What’s New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.

New and Changed Information

This chapter provides release-specific information for each new and changed feature in the Cisco DCNM Installation Guide, Release 7.0.x Unicast Configuration Guide, Cisco DCNM for LAN, Release 7.0.x . The latest version of this document is available at the following Cisco website:

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/unicast/configuration/guide/l3_nxos-book.html

http://www.cisco.com/en/US/docs/switches/datacenter/sw/6_x/dcnm/unicast/configuration/guide/l3_dcnm-book.htmll

To check for additional information about Cisco NX-OS Release 5.x Cisco DCNM Release 6.x, see the Cisco NX-OS Release NotesCisco DCNM Release Notes available at the following Cisco website:

http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/release/notes/42_nx-os_release_note.html

http://www.cisco.com/en/US/docs/switches/datacenter/sw/6_x/dcnm/release/notes/dcnm_6_x_relnotes.html

Table 1 summarizes the new and changed features for the Cisco DCNM Installation Guide, Release 7.0.x Unicast Configuration Guide, Cisco DCNM for LAN, Release 7.0.x , and tells you where they are documented.

Table 1 New and Changed Features for Release 7.0.x

Feature

Description

Changed in Release

Where Documented

BFD

Added support for BFD.

5.0(2)

See the Cisco Nexus 7000 Series NX-OS Interfaces Configuration Guide, Release 7.0.x for more information.

There are no changes since Release 7.0(1)

—

—

—

Unicast Routing

No change from Release 5.1.

5.2(1)

—

Object Tracking

Added support for configuring object tracking on an IPv6 interface.

5.1(1)

Chapter 6, “Configuring Object Tracking”

HSRP

Added support for IPv6.

5.0(2)

Chapter 5, “Configuring HSRP”

IPv6

Added support IPv6 Path MTU discovery

5.0(2)

Chapter 3, “Configuring IPv6”

Object Tracking

Added support for IPv6.

5.0(2)

Chapter 6, “Configuring Object Tracking”

Overview

The Cisco Data Center Network Manager (DCNM) supports IP addressing, object tracking, and Gateway Load Balancing Protocol (GLBP).

This chapter includes the following sections:

- IPv4 and IPv6

- First-Hop Redundancy Protocols

- Object Tracking

This chapter introduces the underlying concepts for Layer 3 unicast routing protocols in Cisco NX-OS.

This chapter includes the following sections:

- Information About Layer 3 Unicast Routing

- Routing Algorithms

- Layer 3 Virtualization

- Cisco NX-OS Fowarding Architecture

- Summary of Layer 3 Unicast Routing Features

- Related Topics

Information About Layer 3 Unicast Routing

Layer 3 unicast routing involves two basic activities: determining optimal routing paths and packet switching. You can use routing algorithms to calculate the optimal path from the router to a destination. This calculation depends on the algorithm selected, route metrics, and other considerations such as load balancing and alternate path discovery.

This section includes the following topics:

- Routing Fundamentals

- Packet Switching

- Routing Metrics

- Router IDs

- Autonomous Systems

- Convergence

- Load Balancing and Equal Cost Multipath

- Route Redistribution

- Administrative Distance

- Stub Routing

Routing Fundamentals

Routing protocols use a router path that evaluate the best path to the destination. A metric is a standard of measurement, such as a path bandwidth, that routing algorithms use to determine the optimal path to a destination. To aid path determination, routing algorithms initialize and maintain routing tables, that contain route information such as the IP destination address and the address of the next router. Destination and next-hop associations tell a router that an IP destination can be reached optimally by sending the packet to a particular router that represents the next hop on the way to the final destination. When a router receives an incoming packet, it checks the destination address and attempts to associate this address with the next hop. See the “Unicast RIB” section for more information about the route table.

Routing tables can contain other information, such as the data about the desirability of a path. Routers compare metrics to determine optimal routes, and these metrics differ depending on the design of the routing algorithm used. See the “Routing Metrics” section.

Routers communicate with one another and maintain their routing tables by transmitting a variety of messages. The routing update message is one such message that consists of all or a portion of a routing table. By analyzing routing updates from all other routers, a router can build a detailed picture of the network topology. A link-state advertisement, another example of a message sent between routers, informs other routers of the link state of the sending router. You can also use link information to enable routers to determine optimal routes to network destinations. For more information, see the “Routing Algorithms” section.

Packet Switching

In packet switching, a host determines that it must send a packet to another host. Having acquired a router address by some means, the source host sends a packet addressed specifically to the router physical (Media Access Control [MAC]-layer) address but with the IP (network layer) address of the destination host.

The router examines the destination IP address and tries to find the IP address in the routing table. If the router does not know how to forward the packet, it typically drops the packet. If the router knows how to forward the packet, it changes the destination MAC address to the MAC address of the next hop router and transmits the packet.

The next hop might be the ultimate destination host or another router that executes the same switching decision process. As the packet moves through the internetwork, its physical address changes, but its protocol address remains constant (see Figure 1-1).

Figure 1-1 Packet Header Updates Through a Network

Routing Metrics

Routing algorithms use many different metrics to determine the best route. Sophisticated routing algorithms can base route selection on multiple metrics.

This section includes the following metrics:

- Path Length

- Reliability

- Routing Delay

- Bandwidth

- Load

- Communication Cost

Path Length

The path length is the most common routing metric. Some routing protocols allow you to assign arbitrary costs to each network link. In this case, the path length is the sum of the costs associated with each link traversed. Other routing protocols define hop count, a metric that specifies the number of passes through internetworking products, such as routers, that a packet must take from a source to a destination.

Reliability

This is the context of routing algorithms, is the dependability (in terms of the bit-error rate) of each network link. Some network links might go down more often than others. After a network fails, certain network links might be repaired more easily or more quickly than other links. The reliability factors that you can take into account when assigning the reliability rating are arbitrary numeric values that you usually assign to network links.

Routing Delay

The routing is the length of time required to move a packet from a source to a destination through the internetwork. The delay depends on many factors, including the bandwidth of intermediate network links, the port queues at each router along the way, the network congestion on all intermediate network links, and the physical distance that the packet needs to travel. Because the routing delay is a combination of several important variables, it is a common and useful metric.

Bandwidth

This is the available traffic capacity of a link. For example, a 10-Gigabit Ethernet link would be preferable to a 1-Gigabit Ethernet link. Although the bandwidth is the maximum attainable throughput on a link, routes through links with greater bandwidth do not necessarily provide better routes than routes through slower links. For example, if a faster link is busier, the actual time required to send a packet to the destination could be greater.

Load

This is the degree to which a network resource, such as a router, is busy. You can calculate the load in a variety of ways, including CPU utilization and packets processed per second. Monitoring these parameters on a continual basis can be resource intensive.

Communication Cost

This is a measure of the operating cost to route over a link. The communication cost is another important metric, especially if you do not care about performance as much as operating expenditures. For example, the line delay for a private line might be longer than a public line, but you can send packets over your private line rather than through the public lines that cost money for usage time.

Router IDs

Each routing process has an associated process. You can configure the router ID to any interface in the system. If you do not configure the router ID, Cisco NX-OS selects the router ID based on the following criteria:

- Cisco NX-OS prefers loopback0 over any other interface. If loopback0 does not exist, then Cisco NX-OS prefers the first loopback interface over any other interface type.

- If you have not configured no loopback interfaces, Cisco NX-OS uses the first interface in the configuration file as the router ID. If you configure any loopback interface after Cisco NX-OS selects the router ID, the loopback interface becomes the router ID. If the loopback interface is not loopback0 and you configure loopback0 later with an IP address, the router ID changes to the IP address of loopback0.

- If the interface that the router ID is based on changes, that new IP address becomes the router ID. If any other interface changes its IP address, there is no router ID change.

Autonomous Systems

A (AS) is a network controlled by a single technical administration entity. Autonomous systems divide global external networks into individual routing domains, where local routing policies are applied. This organization simplifies routing domain administration and simplifies consistent policy configuration.

Each autonomous system can support multiple interior routing protocols that dynamically exchange routing information through route. The Regional Internet Registries assign a unique number to each public autonomous system that directly connects to the Internet. This autonomous system number (AS number) identifies both the routing process and the autonomous system.

Cisco NX-OS supports 4-byte AS numbers. Table 1-1 lists the AS number ranges.

Table 1-1 AS Numbers

2-Byte Numbers

4-Byte Numbers in AS.dot Notation

4-Byte Numbers in plaintext Notation

Purpose

1 to 64511

0.1 to 0.64511

1 to 64511

Public AS (assigned by RIR)1

64512 to 65534

0.64512 to 0.65534

64512 to 65534

Private AS (assigned by local administrator)

65535

0.65535

65535

Reserved

N/A

1.0 to 65535.65535

65536 to 4294967295

Public AS (assigned by RIR)

1.RIR=Regional Internet Registries

Private autonomous system numbers are used for internal routing domains but must be translated by the router for traffic that is routed out to the Internet. You should not configure routing protocols to advertise private autonomous system numbers to external networks. By default, Cisco NX-OS does not remove private autonomous system numbers from routing updates.

Note The autonomous system number assignment for public and private networks is governed by the Internet Assigned Number Authority (IANA). For information about autonomous system numbers, including the reserved number assignment, or to apply to register an autonomous system number, see the following URL:

http://www.iana.org/

Convergence

A key aspect to measure for any routing algorithm is how much time a router takes to react to network topology changes. When a part of the network changes for any reason, such as a link failure, the routing information in different routers might not match. Some routers will have updated information about the changed topology, other routers will still have the old information. This is the amount of time before all routers in the network have updated, matching routing information. The convergence time varies depending on the routing algorithm. Fast convergence minimizes the chance of lost packets caused by inaccurate routing information.

Load Balancing and Equal Cost Multipath

Routing protocols can use equal cost multipath (ECMP) to share traffic across multiple paths.When a router learns multiple routes to a specific network, it installs the route with the lowest administrative distance in the routing table. If the router receives and installs multiple paths with the same administrative distance and cost to a destination, load balancing can occur. Load balancing distributes the traffic across all the paths, sharing the load. The number of paths used is limited by the number of entries that the routing protocol puts in the routing table. Cisco NX-OS supports up to 16 paths to a destination.

The Enhanced Interior Gateway Routing Protocol (EIGRP) also supports unequal cost load-balancing.

Route Redistribution

If you have multiple routing protocols configured in your network, you can configure these protocols to share routing information by configuring route redistribution in each protocol. For example, you can configure Open Shortest Path First (OSPF) to advertise routes learned from the Border Gateway Protocol (BGP). You can also redistribute static routes into any dynamic routing protocol. The router that is redistributing routes from another protocol sets a fixed route metric for those redistributed routes. This avoids the problem of incompatible route metrics between the different routing protocols. For example, routes redistributed from EIGRP into OSPF are assigned a fixed link cost metric that OSPF understands.

Route redistribution also uses an administrative distance (see the “Administrative Distance” section) to distinguish between routes learned from two different routing protocols. The preferred routing protocol is given a lower administrative distance so that its routes are picked over routes from another protocol with a higher administrative distance assigned.

Administrative Distance

The rating of the trustworthiness of a routing information source. The higher the value, the lower the trust rating. Typically, a route can be learned through more than one protocol. Administrative distance is used to discriminate between routes learned from more than one protocol. The route with the lowest administrative distance is installed in the IP routing table.

Stub Routing

You can use stub routing in a hub-and-spoke network topology, where one or more end (stub) networks are connected to a remote router (the spoke) that is connected to one or more distribution routers (the hub). The remote router is adjacent only to one or more distribution routers. The only route for IP traffic to follow into the remote router is through a distribution router. This type of configuration is commonly used in WAN topologies in which the distribution router is directly connected to a WAN. The distribution router can be connected to many more remote routers. Often, the distribution router is connected to 100 or more remote routers. In a hub-and-spoke topology, the remote router must forward all nonlocal traffic to a distribution router, so it becomes unnecessary for the remote router to hold a complete routing table. Generally, the distribution router sends only a default route to the remote router.

Only specified routes are propagated from the remote (stub) router. The stub router responds to all queries for summaries, connected routes, redistributed static routes, external routes, and internal routes with the message “inaccessible.” A router that is configured as a stub sends a special peer information packet to all neighboring routers to report its status as a stub router.

Any neighbor that receives a packet informing it of the stub status does not query the stub router for any routes, and a router that has a stub peer does not query that peer. The stub router depends on the distribution router to send the proper updates to all peers.

Stub routing does not prevent routes from being advertised to the remote router. shows that the remote router can access the corporate network and the Internet through the distribution router only. A full route table on the remote router, in this example, serves no functional purpose because the path to the corporate network and the Internet would always be through the distribution router. A larger route table would reduce only the amount of memory required by the remote router. The bandwidth and memory used can be lessened by summarizing and filtering routes in the distribution router. In this network topology, the remote router does not need to receive routes that have been learned from other networks because the remote router must send all nonlocal traffic, regardless of its destination, to the distribution router. To configure a true stub network, you should configure the distribution router to send only a default route to the remote router.

OSPF supports stub areas and EIGRP supports stub routers.

Routing Algorithms

Routing algorithms determine how a router gathers and reports reachability information, how it deals with topology changes, and how it determines the optimal route to a destination. Various types of routing algorithms exist, and each algorithm has a different impact on network and router resources. Routing algorithms use a variety of metrics that affect calculation of optimal routes. You can classify routing algorithms by type, such as static or dynamic, and interior or exterior.

This section includes the following topics:

- Static Routes and Dynamic Routing Protocols

- Interior and Exterior Gateway Protocols

- Distance Vector Protocols

- Link-State Protocols

Static Routes and Dynamic Routing Protocols

Static routes are route table entries that you manually configure. These static routes do not change unless you reconfigure them. Static routes are simple to design and work well in environments where network traffic is relatively predictable and where network design is relatively simple.

Because static routing systems cannot react to network changes, you should not uses them for today’s large, constantly changing networks. Most routing protocols today use dynamic routing algorithms, which adjust to changing network circumstances by analyzing incoming routing update messages. If the message indicates that a network change has occurred, the routing software recalculates routes and sends out new routing update messages. These messages permeate the network, triggering routers to rerun their algorithms and change their routing tables accordingly.

You can supplement dynamic routing algorithms with static routes where appropriate. For example, you should configure each subnetwork with a static route to the IP or router of last resort (a router to which all unrouteable packets are sent).

Interior and Exterior Gateway Protocols

You can separate networks into unique routing domains or autonomous system s . An autonomous system is a portion of an internetwork under common administrative authority that is regulated by a particular set of administrative guidelines. Routing protocols that route between autonomous systems are called exterior gateway protocols or interdomain protocols. BGP is an example of an exterior gateway protocol. Routing protocols used within an autonomous system are called interior gateway protocols or intradomain protocols. EIGRP and OSPF are examples of interior gateway protocols.

Distance Vector Protocols

Distance vector protocols use algorithms (also known as Bellman-Ford algorithms) that call for each router to send all or some portion of its routing table to its neighbors. Distance vector algorithms define routes by distance (for example, the number of hops to the destination) and direction (for example, the next-hop router). These routes are then broadcast to the directly connected neighbor routers. Each router uses these updates to verify and update the routing tables.

To prevent routing loops, most distance vector algorithms use which means that the routes learned from an interface are set as unreachable and advertised back along the interface that they were learned on during the next periodic update. This prevents the router from seeing its own route updates coming back.

Distance vector algorithms send updates at fixed intervals but can also send updates in response to changes in route metric values. These triggered updates can speed up the route convergence time. The Routing Information Protocol (RIP) is a distance vector protocol.

Link-State Protocols

The protocols, also known as shortest path first (SPF), share information with neighboring routers. Each router builds a link-state advertisement (LSA), which contains information about each link and directly connected neighbor router.

Each LSA has a sequence number. When a router receives and LSA and updates its link-state database, the LSA is flooded to all adjacent neighbors. If a router receives two LSAs with the same sequence number (from the same router), the router does not flood the last LSA received to its neighbors to prevent an LSA update loop. Because the router floods the LSAs immediately after they receive them, convergence time for link-state protocols is minimized.

Discovering neighbors and establishing adjacency is an important part of a link state protocol. Neighbors are discovered using special Hello packets that also serve as keepalive notifications to each neighbor router. Adjacency is the establishment of a common set of operating parameters for the link-state protocol between neighbor routers.

The LSAs received by a router are added to its link-state database. Each entry consists of the following parameters:

- Router ID (for the router that originated the LSA)

- Neighbor ID

- Link cost

- Sequence number of the LSA

- Age of the LSA entry

The router runs the SPF algorithm on the link-state database, building the shortest path tree for that router. This SPF tree is used to populate the routing table.

In link-state algorithms, each router builds a picture of the entire network in its routing tables. The link-state algorithms send small updates everywhere, while distance vector algorithms send larger updates only to neighboring routers.

Because they converge more quickly, link-state algorithms are somewhat less prone to routing loops than distance vector algorithms. However, link-state algorithms require more CPU power and memory than distance vector algorithms. Link-state algorithms can be more expensive to implement and support. Link-state protocols are generally more scalable than distance vector protocols.

OSPF is an example of a link-state protocol.

Layer 3 Virtualization

Cisco NX-OS introduces the virtual device context (VDC), which provides separate management domains per VDC and software fault isolation. Each VDC supports multiple Virtual Routing and Forwarding Instances (VRFs) and multiple routing information bases to support multiple address domains. Each VRF is associated with a routing information base (RIB) and this information is collected by the Forwarding Information Base (FIB). Figure 1-2 shows the relationship between VDC, VRF, and the Cisco NX-OS system.

Figure 1-2 Layer 3 Virtualization Example

A VRF represents a layer 3 addressing domain. Each layer 3 interface (logical or physical) belongs to one VRF. A VRF belongs to one VDC. Each VDC can support multiple VRFs.

See to the Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide, Release 5.x , for details on VDCs.

Cisco NX-OS Fowarding Architecture

The Cisco NX-OS forwarding architecture is responsible for processing all routing updates and populating the forwarding information to all modules in the chassis.

This section includes the following topics:

- Unicast RIB

- Adjacency Manager

- Unicast Forwarding Distribution Module

- FIB

- Hardware Forwarding

- Software Forwarding

Unicast RIB

The Cisco NX-OS forwarding architecture consists of multiple components, as shown in Figure 1-3.

Figure 1-3 Cisco NX-OS Forwarding Architecture

The unicast RIB exists on the active supervisor. It maintains the routing table with directly connected routes, static routes, and routes learned from dynamic unicast routing protocols. The unicast RIB also collects adjacency information from sources such as the Address Resolution Protocol (ARP). The unicast RIB determines the best next-hop for a given route and populates the unicast forwarding information bases (FIB) on the supervisors and modules by using the services of unicast FIB distribution module (FDM).

Each dynamic routing protocol must update the unicast RIB for any route that has timed out. The unicast RIB then deletes that route and recalculates the best next-hop for that route (if an alternate path is available).

Adjacency Manager

The adjacency manager exists on the active supervisor and maintains adjacency information for different protocols including ARP, Neighbor Discovery Protocol (NDP), and static configuration. The most basic adjacency information is the Layer 3 to Layer 2 address mapping discovered by these protocols. Outgoing layer 2 packets use the adjacency information to complete the Layer 2 header.

The adjacency manager can trigger ARP requests to find a particular Layer 3 to Layer 2 mapping. The new mapping becomes available when the corresponding ARP reply is received and processed. For IPv6, the adjacency manager finds the Layer 3 to Layer 2 mapping information from NDP. See Chapter3, “Configuring IPv6”

Unicast Forwarding Distribution Module

The unicast forwarding distribution module exists on the active supervisor and distributes the forwarding path information from the unicast RIB and other sources. The unicast RIB generates forwarding information which the unicast FIB programs into the hardware forwarding tables on the standby supervisor and the modules. The unicast forwarding distribution module also downloads the FIB information to newly inserted modules.

The unicast forwarding distribution module gathers adjacency information, rewrite information, and other platform-dependent information when updating routes in the unicast FIB. The adjacency and rewrite information consists of interface, next-hop, and Layer 3 to Layer 2 mapping information. The interface and next-hop information is received in route updates from the unicast RIB. The Layer 3 to Layer 2 mapping is received from the adjacency manager.

FIB

The unicast FIB exists on supervisors and switching modules and builds the information used for the hardware forwarding engine. The unicast FIB receives route updates from the unicast forwarding distribution module and sends the information along to be programmed in the hardware forwarding engine. The unicast FIB controls the addition, deletion, and modification of routes, paths, and adjacencies.

The unicast FIBs are maintained on a per-VRF and per-address-family basis, that is, one for IPv4 and one for IPv6 for each configured VRF. Based on route update messages, the unicast FIB maintains a per-VRF prefix and next-hop adjacency information database. The next-hop adjacency data structure contains the next-hop IP address and the Layer 2 rewrite information. Multiple prefixes could share a next-hop adjacency information structure.

Hardware Forwarding

Cisco NX-OS supports distributed packet forwarding. The ingress port takes relevant information from the packet header and passes the information to the local switching engine. The local switching engine does the Layer 3 lookup and uses this information to rewrite the packet header. The ingress module forwards the packet to the egress port. If the egress port is on a different module, the packet is forwarded using the switch fabric to the egress module. The egress module does not participate in the Layer 3 forwarding decision.

The forwarding tables are identical on the supervisor and all the modules.

You also use the show platform fib or show platform forwarding commands to display details on hardware forwarding.

Software Forwarding

The software forwarding path in Cisco NX-OS is used mainly to handle features that are not supported in hardware or to handle errors encountered during hardware processing. Typically, packets with IP options or packets that need fragmentation are passed to the CPU on the active supervisor. All packets that should be switched in software or terminated go to the supervisor. The supervisor uses the information provided by the unicast RIB and the adjacency manager to make the forwarding decisions. The module is not involved in the software forwarding path.

Software forwarding is controlled by control plane policies and rate limiters. (see the Cisco Nexus 7000 Series NX-OS Security Configuration Guide, Release 5.x ).

Summary of Layer 3 Unicast Routing Features

This section provides a brief introduction to the Layer 3 unicast features and protocols supported in Cisco NX-OS.

This section includes the following topics:

- IPv4 and IPv6

- IP Services

- OSPF

- EIGRP

- IS-IS

- BGP

- RIP

- Static Routing

- Layer 3 Virtualization

- Route Policy Manager

- Policy-Based Routing

- First-Hop Redundancy Protocols

- Object Tracking

IPv4 and IPv6

IPv4 and IPv6

Layer 3 uses either the IPv4 or IPv6 protocol. IPv6 is a new IP protocol designed to replace IPv4, the Internet protocol that is predominantly deployed and used throughout the world. IPv6 increases the number of network address bits from 32 bits (in IPv4) to 128 bits. For more information, see Chapter 2, “Configuring IPv4” or Chapter3, “Configuring IPv6”

IP Services

IP Services includes Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS Client) clients.

OSPF

The OSPF protocol is a link-state routing protocol used to exchange network reachability information within an autonomous system. Each OSPF router advertises information about its active links to its neighbor routers. Link information consists of the link type, the link metric, and the neighbor router connected to the link. The advertisements that contain this link information are called link-state advertisements.

EIGRP

The EIGRP protocol is a unicast routing protocol that has the characteristics of both distance vector and link-state routing protocols. It is an improved version of IGRP, which is a Cisco proprietary routing protocol. EIGRP relies on its neighbors to provide the routes, typical to a distance vector routing protocol. It constructs the network topology from the routes advertised by its neighbors, similar to a link-state protocol, and uses this information to select loop-free paths to destinations.

IS-IS

The Intermediate System-to-Intermediate System (IS-IS) protocol is an intradomain Open System Interconnection (OSI) dynamic routing protocol specified in International Organization for Standardization (ISO) 10589. The IS-IS routing protocol is a link-state protocol. Features of IS-IS are as follows:

- Hierarchical routing

- Classless behavior

- Rapid flooding of new information

- Fast Convergence

- Very scalable

BGP

The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol. A BGP router advertises network reachability information to other BGP routers using Transmission Control Protocol (TCP) as its reliable transport mechanism. The network reachability information includes the destination network prefix, a list of autonomous systems that needs to be traversed to reach the destination, and the next-hop router. Reachability information contains additional path attributes such as preference to a route, origin of the route, community and others.

RIP

The Routing Information Protocol (RIP) is a distance-vector protocol that uses a hop count as its metric. RIP is widely used for routing traffic in the global Internet and is an Interior Gateway Protocol (IGP), which means that it performs routing within a single autonomous system.

Static Routing

Static routing allows you to enter a fixed route to a destination. This feature is useful for small networks where the topology is simple. Static routing is also used with other routing protocols to control default routes and route distribution.

Layer 3 Virtualization

Virtualization allows you to share physical resources across separate management domains. Cisco NX-OS supports Virtual Device Contexts (VDCs) which allow you to create separate virtual systems within a Cisco NX-OS system. Each VDC is isolated from the others, which means that a problem in one VDC does not affect any other VDCs. VDCs are also secure from the other. You can assign separate network operators to each VDC and these network operators cannot control or view the configuration of a different VDC.

Cisco NX-OS also supports Layer 3 virtualization with VPN Routing and Forwarding (VRF). A VRF provides a separate address domain for configuring layer 3 routing protocols.

Route Policy Manager

The Route Policy Manager provides a route filtering capability in Cisco NX-OS. It uses route maps to filter routes distributed across various routing protocols and between different entities within a given routing protocol. Filtering is based on specific match criteria, which is similar to packet filtering by access control lists.

Policy-Based Routing

Policy-based routing uses the Route Policy Manager to create policy route filters. These policy route filters can forward a packet to a specified next hop based on the source of the packet or other fields in the packet header. Policy routes can be linked to extended IP access lists so that routing might be based on such things as protocol types and port numbers.

First-Hop Redundancy Protocols

First-Hop Redundancy Protocols

First-hop redundancy protocols allow you to provide redundant connections to your hosts. In the event that an active first-hop router fails, the FHRP automatically selects a standby router to take over. You do not need to update the hosts with new IP addresses since the address is virtual and shared between each router in the FHRP group. For more information on the Gateway Load Balancing Protocol (GLBP), see Chapter 4, “Configuring GLBP” For more information on the Hot Standby Router Protocol (HSRP), see Chapter 5, “Configuring HSRP”

Object Tracking

Object Tracking

Object tracking allows you to track specific objects on the network, such as the interface line protocol state, IP routing, and route reachability, and take action when the tracked object’s state changes. This feature allows you to increase the availability of the network and shorten recovery time if an object state goes down. For more information, see Chapter 6, “Configuring Object Tracking”

Related Topics

The following Cisco documents are related to the Layer 3 features:

- Cisco Nexus 7000 Series NX-OS Multicast Routing Configuration Guide, Release 5.x

- Cisco Nexus 7000 Series NX-OS High Availability and Redundancy Guide, Release 5.x

- Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide, Release 5.x

- Exploring Autonomous System Numbers: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-1/autonomous_system_numbers.html

Configuring IPv4

This chapter describes how to configure Internet Protocol version 4 (IPv4), which includes addressing, Address Resolution Protocol (ARP), and Internet Control Message Protocol (ICMP), on the Cisco Data Center Network Manager (DCNM) Cisco NX-OS device.

This chapter includes the following sections:

- Information About IPv4

- Licensing Requirements for IPv4

- Prerequisites for IPv4

- Guidelines and Limitations

- Default SettingsPlatform Support

- Configuring IPv4

- Configuring IP Directed Broadcasts

- Configuration Examples for IPv4

- Field Descriptions for IP

- Additional References

- Feature History for IP

Information About IPv4

You can configure IP on the device to assign IP addresses to network interfaces. When you assign IP addresses, you enable the interfaces and allow communication with the hosts on those interfaces.

You can configure an IP address as primary or secondary on a device. An interface can have one primary IP address and multiple secondary addresses. All networking devices on an interface should share the same primary IP address because the packets that are generated by the device always use the primary IPv4 address. Each IPv4 packet is based on the information from a source or destination IP address. See the “Multiple IPv4 Addresses” section.

You can use a subnet to mask the IP addresses. A mask is used to determine what subnet an IP address belongs to. An IP address contains the network address and the host address. A mask identifies the bits that denote the network number in an IP address. When you use the mask to subnet a network, the mask is then referred to as a subnet mask. Subnet masks are 32-bit values that allow the recipient of IP packets to distinguish the network ID portion of the IP address from the host ID portion of the IP address.

The IP feature in the Cisco NX-OS system is responsible for handling IPv4 packets that terminate in the supervisor module, as well as forwarding of IPv4 packets, which includes IPv4 unicast/multicast route lookup, reverse path forwarding (RPF) checks, and software access control list/policy based routing (ACL/PBR) forwarding. The IP feature also manages the network interface IP address configuration, duplicate address checks, static routes, and packet send/receive interface for IP clients.

This section includes the following topics:

- Multiple IPv4 Addresses

- Address Resolution Protocol

- ARP Caching

- Static and Dynamic Entries in the ARP Cache

- Devices That Do Not Use ARP

- Reverse ARP

- Reverse ARP

- Proxy ARP

- Local Proxy ARP

- Gratuitous ARP

- Glean Throttling

- Path MTU Discovery

- ICMP

- Virtualization Support

Multiple IPv4 Addresses

The Cisco NX-OS system supports multiple IP addresses per interface. You can specify an unlimited number of secondary addresses for a variety of situations. The most common are as follows:

- When there are not enough host IP addresses for a particular network interface. For example, if your subnetting allows up to 254 hosts per logical subnet, but on one physical subnet you must have 300 host addresses, then you can use secondary IP addresses on the routers or access servers to allow you to have two logical subnets using one physical subnet.

- Two subnets of a single network might otherwise be separated by another network. You can create a single network from subnets that are physically separated by another network by using a secondary address. In these instances, the first network is extended, or layered on top of the second network. A subnet cannot appear on more than one active interface of the router at a time.

Note If any device on a network segment uses a secondary IPv4 address, all other devices on that same network interface must also use a secondary address from the same network or subnet. The inconsistent use of secondary addresses on a network segment can quickly cause routing loops.

Address Resolution Protocol

Networking devices and Layer 3 switches use Address Resolution Protocol (ARP) to map IP (network layer) addresses to (Media Access Control [MAC]-layer) addresses to enable IP packets to be sent across networks. Before a device sends a packet to another device, it looks in its own ARP cache to see if there is a MAC address and corresponding IP address for the destination device. If there is no entry, the source device sends a broadcast message to every device on the network.

Each device compares the IP address to its own. Only the device with the matching IP address replies to the device that sends the data with a packet that contains the MAC address for the device. The source device adds the destination device MAC address to its ARP table for future reference, creates a data-link header and trailer that encapsulates the packet, and proceeds to transfer the data. Figure 2-1 shows the ARP broadcast and response process.

Figure 2-1 ARP Process

When the destination device lies on a remote network which is beyond another device, the process is the same except that the device that sends the data sends an ARP request for the MAC address of the default gateway. After the address is resolved and the default gateway receives the packet, the default gateway broadcasts the destination IP address over the networks connected to it. The device on the destination device network uses ARP to obtain the MAC address of the destination device and delivers the packet. ARP is enabled by default.

The default system-defined CoPP policy rate-limits ARP broadcast packets bound for the supervisor module. The default system-defined CoPP policy prevents an ARP broadcast storm from affecting the control plane traffic, but does not affect bridged packets.

ARP Caching

ARP caching minimizes broadcasts and limits wasteful use of network resources. The mapping of IP addresses to MAC addresses occurs at each hop (device) on the network for every packet sent over an internetwork, which may affect network performance.

ARP caching stores network addresses and the associated data-link addresses in memory for a period of time, which minimizes the use of valuable network resources to broadcast for the same address each time a packet is sent. You must maintain the cache entries since the cache entries are set to expire periodically because the information might become outdated. Every device on a network updates its tables as addresses are broadcast.

Static and Dynamic Entries in the ARP Cache

You must manually configure the IP addresses, subnet masks, gateways, and corresponding MAC addresses for each interface of each device when using static routes. Static routing enables more control but requires more work to maintain the route table. You must update the table each time you add or change routes.

Dynamic routing uses protocols that enable the devices in a network to exchange routing table information with each other. Dynamic routing is more efficient than static routing because the route table is automatically updated unless you add a time limit to the cache. The default time limit is 25 minutes but you can modify the time limit if the network has many routes that are added and deleted from the cache.

Devices That Do Not Use ARP

When a network is divided into two segments, a bridge joins the segments and filters traffic to each segment based on MAC addresses. The bridge builds its own address table, which uses MAC addresses only, as opposed to a device, which has an ARP cache that contains both IP addresses and the corresponding MAC addresses.

Passive hubs are central-connection devices that physically connect other devices in a network. They send messages out on all their ports to the devices and operate at Layer 1, but do not maintain an address table.

Layer 2 switches determine which port is connected to a device to which the message is addressed and send only to that port, unlike a hub, which sends the message out all its ports. However, Layer 3 switches are devices that build an ARP cache (table).

Reverse ARP

Reverse ARP (RARP) as defined by RFC 903 works the same way as ARP, except that the RARP request packet requests an IP address instead of a MAC address. RARP often is used by diskless workstations because this type of device has no way to store IP addresses to use when they boot. The only address that is known is the MAC address because it is burned into the hardware.

Use of RARP requires an RARP server on the same network segment as the router interface. Figure 2-2 illustrates how RARP works.

Figure 2-2 Reverse ARP

There are several limitations of RARP. Because of these limitations, most businesses use DHCP to assign IP addresses dynamically. DHCP is cost effective and requires less maintenance than RARP. The following are the most important limitations:

- Since RARP uses hardware addresses, if the internetwork is large with many physical networks, a RARP server must be on every segment with an additional server for redundancy. Maintaining two servers for every segment is costly.

- Each server must be configured with a table of static mappings between the hardware addresses and IP addresses. Maintenance of the IP addresses is difficult.

- RARP only provides IP addresses of the hosts and not subnet masks or default gateways.

Proxy ARP

Proxy ARP enables a device that is physically located on one network appear to be logically part of a different physical network connected to the same device or firewall. Proxy ARP allows you to hide a device with a public IP address on a private network behind a router, and still have the device appear to be on the public network in front of the router. By hiding its identity, the router accepts responsibility for routing packets to the real destination. Proxy ARP can help devices on a subnet reach remote subnets without configuring routing or a default gateway.

When devices are not in the same data link layer network but in the same IP network, they try to transmit data to each other as if they are on the local network. However, the router that separates the devices does not send a broadcast message because routers do not pass hardware-layer broadcasts and the addresses cannot be resolved.

When you enable Proxy ARP on the device and it receives an ARP request, it identifies the request as a request for a system that is not on the local LAN. The device responds as if it is the remote destination for which the broadcast is addressed, with an ARP response that associates the device’s MAC address with the remote destination's IP address. The local device believes that it is directly connected to the destination, while in reality its packets are being forwarded from the local subnetwork toward the destination subnetwork by their local device. By default, Proxy ARP is disabled.

Local Proxy ARP

You can use local Proxy ARP to enable a device to respond to ARP requests for IP addresses within a subnet where normally no routing is required. When you enable local Proxy ARP, ARP responds to all ARP requests for IP addresses within the subnet and forwards all traffic between hosts in the subnet. Use this feature only on subnets where hosts are intentionally prevented from communicating directly by the configuration on the device to which they are connected.

Gratuitous ARP

Gratuitous ARP sends a request with identical source IP address and destination IP address to detect duplicate IP addresses. Cisco NX-OS Release 4.0(3) and later releases support enabling or disabling gratuitous ARP requests or ARP cache updates.

Glean Throttling

When forwarding an incoming IP packet in a line card, if the Address Resolution Protocol (ARP) request for the next hop is not resolved, the line card forwards the packets to the supervisor (glean throttling). The supervisor resolves the MAC address for the next hop and programs the hardware.

The Cisco Nexus 7000 Series device hardware has glean rate limiters to protect the supervisor from the glean traffic. If the maximum number of entries is exceeded, the packets for which the ARP request is not resolved continues to be processed in the software instead of getting dropped in the hardware.

When an ARP request is sent, the software adds a /32 drop adjacency in the hardware to prevent the packets to the same next-hop IP address to be forwarded to the supervisor. When the ARP is resolved, the hardware entry is updated with the correct MAC address. If the ARP entry is not resolved before a timeout period, the entry is removed from the hardware

Path MTU Discovery

Path MTU discovery is a method for maximizing the use of available bandwidth in the network between the endpoints of a TCP connection. It is described in RFC 1191. Existing connections are not affected when this feature is turned on or off.

ICMP

You can use ICMP to provide message packets that report errors and other information that is relevant to IP processing. ICMP generates error messages, such as ICMP destination unreachable messages, ICMP Echo Requests (which send a packet on a round trip between two hosts) and Echo Reply messages. ICMP also provides many diagnostic functions and can send and redirect error packets to the host. By default, ICMP is enabled.

Some of the ICMP message types are as follows:

- Network error messages

- Network congestion messages

- Troubleshooting information

- Timeout announcements

Note ICMP redirects are disabled on interfaces where the local proxy ARP feature is enabled.

Virtualization Support

IPv4 supports Virtual Routing and Forwarding instances (VRFs). VRFs exist within virtual device contexts (VDCs). By default, Cisco NX-OS places you in the default VDC and default VRF unless you specifically configure another VDC and VRF.

Licensing Requirements for IPv4

The following table shows the licensing requirements for this feature:

Product

License Requirement

Cisco DCNM

IP requires no license. Any feature not included in a license package is bundled with the Cisco DCNM and is provided at no charge to you. For a complete explanation of the Cisco DCNM licensing scheme, see the Cisco DCNM Installation and Licensing Guide, Release 5.x .

Cisco NX-OS

IP requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. For an explanation of the Cisco NX-OS licensing scheme for your platform, see the licensing guide for your platform. For a complete explanation of the Cisco NX-OS licensing scheme, see the Cisco NX-OS Licensing Guide

Prerequisites for IPv4

IPv4 has the following prerequisites:

- IPv4 can only be configured on Layer 3 interfaces.

Guidelines and Limitations

IPv4 has the following configuration guidelines and limitations:

- You can configure a secondary IP address only after you configure the primary IP address.

Default Settings

Table 2-1 lists the default settings for IP parameters.

Table 2-1 Default IP Parameters

Parameters

Default

ARP timeout

1500 seconds

proxy ARP

Disabled

Platform Support

The following platforms support this feature but may implement it differently. For platform-specific information, including guidelines and limitations, system defaults, and configuration limits, see the corresponding documentation.

Platform

Documentation

Cisco Nexus 1000V Series Switches (mgmt0 port only)

Cisco Nexus 1000V Series Switches Documentation

Cisco Nexus 4000 Series Switches (mgmt0 port only)

Cisco Nexus 4000 Series Switches Documentation

Cisco Nexus 7000 Series Switches

Cisco Nexus 7000 Series Switches Documentation

Configuring IPv4

You can access IP addressing for Layer 3 interfaces from the Interfaces feature selection.

For more information about the Data Center Network Manager features, see the Fundamentals Configuration Guide, Cisco DCNM for LAN, Release 5.x .

This section includes the following topics:

- Configuring IPv4 Addressing

- Configuring Multiple IP Addresses

- Configuring a Static ARP Entry

- Configuring Proxy ARP

- Configuring Local Proxy ARP

- Configuring Path MTU Discovery

- Configuring Path MTU Discovery

- Configuring IP Directed Broadcasts

- Configuring IP Glean Throttling

- Configuring the Hardware IP Glean Throttle Maximum

- Configuring a Hardware IP Glean Throttle Timeout

- Configuring the Hardware IP Glean Throttle Syslog

Note If you are familiar with the Cisco IOS CLI, be aware that the Cisco NX-OS commands for this feature might differ from the Cisco IOS commands that you would use.

Configuring IPv4 Addressing

You can assign a primary IP address for a network interface.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. interface ethernet number

3. ip address ip-address/length

4. show ip interface

5. copy running-config startup-config

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Interfaces > Physical > Ethernet .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device to display a list of slots.

Step 3 Double-click the slot to display a list of interfaces.

Step 4 Click the interface that you want to configure as a routed interface.

The system highlights the interface in the Summary pane, and tabs appear in the Details pane.

Step 5 From the Details pane, click the Port Details tab.

The Port Details tab appears.

Step 6 From the Port Details tab, expand the Port Mode Settings section.

The port mode appears.

Step 7 From the Mode drop-down list, choose Routed .

The IP address information appears in the Details pane and Cisco NX-OS removes any Layer 2 configuration.

Step 8 (Optional) From the IPv4 Address Settings, set the Primary field to the IPv4 address for this routed interface.

Step 9 (Optional) Set the Net mask field to the network mask for this IPv4 address in dotted decimal notation.

Step 10 From the menu bar, choose File > Deploy to apply your changes to the device.

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

interface ethernet number

Example:

switch(config)# interface ethernet 2/3

switch(config-if)#

Enters interface configuration mode.

Step 3

ip address ip-address/length

[secondary]

Example:

switch(config-if)# ip address 192.2.1.1 255.0.0.0

Specifies a primary or secondary IPv4 address for an interface.

- The network mask can be a four-part dotted decimal address. For example, 255.0.0.0 indicates that each bit equal to 1 means the corresponding address bit belongs to the network address.

- The network mask can be indicated as a slash (/) and a number - a prefix length. The prefix length is a decimal value that indicates how many of the high-order contiguous bits of the address comprise the prefix (the network portion of the address). A slash must precede the decimal value and there is no space between the IP address and the slash.

Step 4

show ip interface

Example:

switch(config-if)# show ip interface

(Optional) Displays interfaces configured for IPv4.

Step 5

copy running-config startup-config

Example:

switch(config-if)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to assign an IPv4 address:

switch# config t

switch(config)# interface ethernet 2/3

switch(config-if)# ip address 192.2.1.1 255.0.0.0

switch(config-if)# copy running-config startup-config

Configuring Multiple IP Addresses

You can only add secondary IP addresses after you configure primary IP addresses.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. interface ethernet number

3. ip address ip-address/length

4. show ip interface

5. copy running-config startup-config

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Interfaces > Physical > Ethernet .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device to display a list of slots.

Step 3 Double-click the slot to display a list of interfaces.

Step 4 Click the interface that you want to configure as a routed interface.

The system highlights the interface in the Summary pane, and tabs appear in the Details pane.

Step 5 From the Details pane, click the Port Details tab.

The Port Details tab appears.

Step 6 From the Port Details tab, expand the Port Mode Settings section.

The port mode appears.

Step 7 (Optional) From the IPv4 Address settings section, in the Secondary area, right-click and choose Add Secondary IP to add a secondary IP address.

Step 8 From the secondary area, in the IP address field, enter an IPv4 address.

Step 9 From the net mask field, enter the network mask for this IPv4 address in dotted decimal notation.

Step 10 (Optional) From the IPv4 Address settings section, in the Helper area, right-click and choose Add Helper IP to add a helper IP address.

Step 11 From the Helper area, in the IP address field, enter an IPv4 address.

Step 12 From the menu bar, choose File > Deploy to apply your changes to the device.

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

interface ethernet number

Example:

switch(config)# interface ethernet 2/3

switch(config-if)#

Enters interface configuration mode.

Step 3

ip address ip-address/length

[secondary]

Example:

switch(config-if)# ip address 192.2.1.1 255.0.0.0 secondary

Specifies the configured address as a secondary IPv4 address.

Step 4

show ip interface

Example:

switch(config-if)# show ip interface

(Optional) Displays interfaces configured for IPv4.

Step 5

copy running-config startup-config

Example:

switch(config-if)# copy running-config startup-config

(Optional) Saves this configuration change.

Configuring a Static ARP Entry

You can configure a static ARP entry on the device to map IP addresses to MAC hardware addresses, including static multicast MAC addresses.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. interface ethernet number

3. ip arp ipaddr mac_addr

4. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

interface ethernet number

Example:

switch(config)# interface ethernet 2/3

switch(config-if)#

Enters interface configuration mode.

Step 3

ip arp ipaddr mac_addr

Example:

switch(config-if)# ip arp 192.2.1.1 0019.076c.1a78

Associates an IP address with a MAC address as a static entry.

Step 4

copy running-config startup-config

Example:

switch(config-if)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to configure a static ARP entry:

switch# config t

switch(config)# interface ethernet 2/3

switch(config-if)# ip arp 1 92.2.1.1 0019.076c.1a78

switch(config-if)# copy running-config startup-config

Configuring Proxy ARP

You can configure Proxy ARP on the device to determine the media addresses of hosts on other networks or subnets.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. interface ethernet number

3. ip proxy-arp

4. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

interface ethernet number

Example:

switch(config)# interface ethernet 2/3

switch(config-if)#

Enters interface configuration mode.

Step 3

ip proxy-arp

Example:

switch(config-if)# ip proxy-arp

Enables Proxy ARP on the interface.

Step 4

copy running-config startup-config

Example:

switch(config-if)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to configure Proxy ARP:

switch# config t

switch(config)# interface ethernet 2/3

switch(config-if)# ip proxy-arp

switch(config-if)# copy running-config startup-config

Configuring Local Proxy ARP

You can configure Local Proxy ARP on the device.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. interface ethernet number

3. ip local-proxy-arp

4. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

interface ethernet number

Example:

switch(config)# interface ethernet 2/3

switch(config-if)#

Enters interface configuration mode.

Step 3

ip local-proxy-arp

Example:

switch(config-if)# ip local-proxy-arp

Enables Local Proxy ARP on the interface.

Step 4

copy running-config startup-config

Example:

switch(config-if)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to configure Local Proxy ARP:

switch# config t

switch(config)# interface ethernet 2/3

switch(config-if)# ip local-proxy-arp

switch(config-if)# copy running-config startup-config

Configuring Gratuitous ARP

You can configure gratuitous ARP on an interface.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. interface ethernet number

3. ip arp gratuitous { request | update }

4. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

interface ethernet number

Example:

switch(config)# interface ethernet 2/3

switch(config-if)#

Enters interface configuration mode.

Step 3

ip arp gratuitous { request | update }

Example:

switch(config-if)# ip arp gratuitous request

Enables gratuitous ARP on the interface. Default is enabled.

Step 4

copy running-config startup-config

Example:

switch(config-if)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to disable gratuitous ARP requests:

switch# config t

switch(config)# interface ethernet 2/3

switch(config-if)# no ip arp gratuitous request

switch(config-if)# copy running-config startup-config

Configuring Path MTU Discovery

You can configure path MTU discovery on an interface.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. interface ethernet number

3. ip tcp path-mtu-discovery

4. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

interface ethernet number

Example:

switch(config)# interface ethernet 2/3

switch(config-if)#

Enters interface configuration mode.

Step 3

ip tcp path-mtu-discovery

Example:

switch(config-if)# ip tcp path-mtu-discovery

Enables path MTU discovery.

Step 4

copy running-config startup-config

Example:

switch(config-if)# copy running-config startup-config

(Optional) Saves this configuration change.

Configuring IP Packet Verification

Cisco NX-OS supports an Intrusion Detection System (IDS) that checks for IP packet verification. You can enable or disable these IDS checks.

To enable IDS checks, use the following commands in global configuration mode:

Command

Purpose

hardware ip verify address { destination zero | identical | reserved | source {broadcast | multicast }}

Performs the following IDS checks on the IP address:

- destination zero —Drops IP packets if the destination IP address is 0.0.0.0.

- identical —Drops IP packets if the source IP address is identical to the destination IP address.

- reserved —Drops IP packets if the IP address is in the 127.x.x.x range.

- source —Drops IP packets if the IP source address is either 255.255.255.255 (broadcast) or in the 224.x.x.x range (multicast).

hardware ip verify checksum

Drops IP packets if the packet checksum is invalid.

hardware ip verify fragment

Drops IP packets if the packet fragment has a nonzero offset and the DF bit is active.

hardware ip verify length { consistent | maximum { max-frag | max-tcp | udp } | minimum }

Performs the following IDS checks on the IP address:

- consistent —Drops IP packets where the Ethernet frame size is greater than or equal to the IP packet length plus the Ethernet header.

- maximum max-frag —Drops IP packets if the maximum fragment offset is greater than 65536.

- maximum max-tcp —Drops IP packets if the TCP length is greater than the IP payload length.

- maximum udp —Drops IP packets if the IP payload length is less than the UDP packet length.

- minimum —Drops IP packets if the Ethernet frame length is less than the IP packet length plus four octets (the CRC length).

hardware ip verify tcp tiny-frag

Drops TCP packets if the IP fragment offset is 1, or if the IP fragment offset is 0 and the IP payload length is less than 16.

hardware ip verify version

Drops IP packets if the ethertype is not set to 4 (IPv4).

Use the show hardware forwarding ip verify command to display the IP packet verification configuration.

Configuring IP Directed Broadcasts

An IP directed broadcast is an IP packet whose destination address is a valid broadcast address for some IP subnet, but which originates from a node that is not itself part of that destination subnet.

A device that is not directly connected to its destination subnet forwards an IP directed broadcast in the same way it would forward unicast IP packets destined to a host on that subnet. When a directed broadcast packet reaches a device that is directly connected to its destination subnet, that packet is "exploded" as a broadcast on the destination subnet. The destination address in the IP header of the packet is rewritten to the configured IP broadcast address for the subnet, and the packet is sent as a link-layer broadcast.

If directed broadcast is enabled for an interface, incoming IP packets whose addresses identify them as directed broadcasts intended for the subnet to which that interface is attached will be exploded as broadcasts on that subnet.

To enable IP directed broadcasts, use the following command in interface configuration mode:

Command

Purpose

ip directed-broadcas t

Enables the translation of a directed broadcast to physical broadcasts

Configuring IP Glean Throttling

Cisco NX-OS software supports glean throttling rate limiters to protect the supervisor from the glean traffic.

You can enable IP glean throttling.

Note We recommend that you configure the IP glean throttle feature by using the hardware ip glean throttle command to filter the unnecessary glean packets that are sent to the supervisor for ARP resolution for the next hops that are not reachable or do not exist. IP glean throttling boosts software performance and helps to manage traffic more efficiently.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. hardware ip glean throttle

3. no hardware ip glean throttle

4. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

hardware ip glean throttle

Example:

switch(config)# hardware ip glean throttle

Enables ARP throttling.

Step 3

no hardware ip glean throttle

Example:

switch(config)# no hardware ip glean throttle

Disables ARP throttling.

Step 4

copy running-config startup-config

Example:

switch(config)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to enable IP glean throttling:

switch# config t

switch(config)# hardware ip glean throttle

switch(config-if)# copy running-config startup-config

Configuring the Hardware IP Glean Throttle Maximum

You can limit the maximum number of drop adjacencies that will be installed in the FIB.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. hardware ip glean throttle maximum count

3. no hardware ip glean throttle maximum count

4. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

hardware ip glean throttle maximum count

Example:

switch(config)# hardware ip glean throttle maximum 2134

Configures the number of drop adjacencies that will be installed in the FIB.

Step 3

no hardware ip glean throttle maximum count

Example:

switch(config)# no hardware ip glean throttle maxumum 2134

Applies the default limits.

The default value is 1000. The range is from 0 to 32767 entries.

Step 4

copy running-config startup-config

Example:

switch(config)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to limit the maximum number of drop adjacencies that will be installed in the FIB:

switch# config t

switch(config)# hardware ip glean throttle maximum 2134

switch(config-if)# copy running-config startup-config

Configuring a Hardware IP Glean Throttle Timeout

You can configure a timeout for the installed drop adjacencies to remain in the FIB.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. hardware ip glean throttle timeout timeout-in-sec

3. no hardware ip glean throttle timeout timeout-in-sec

4. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

hardware ip glean throttle maximum timeout timeout-in-sec

Example:

switch(config)# hardware ip glean throttle maximum timeout 300

Configures the timeout for the installed drop adjacencies to remain in the FIB.

Step 3

no hardware ip glean throttle maximum timeout timeout-in-sec

Example:

switch(config)# no hardware ip glean throttle maxumum timeout 300

Applies the default limits.

The timeout value is in seconds. The range is from 300 seconds (5 minutes) to 1800 seconds (30 minutes).

Note After the timeout period is exceeded, the drop adjacencies are removed from the FIB.

Step 4

copy running-config startup-config

Example:

switch(config)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to configure a timeout for the drop adjacencies that will be installed in the

switch# config t

switch(config)# hardware ip glean throttle maximum timeout 300

switch(config-if)# copy running-config startup-config

Configuring the Hardware IP Glean Throttle Syslog

You can generate a syslog if the number of packets that get dropped for a specific flow exceeds the configured packet count.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. hardware ip glean throttle syslog pck-count

3. no hardware ip glean throttle syslog pck-count

4. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

hardware ip glean throttle syslog pck-count

Example:

switch(config)# hardware ip glean throttle syslog 1030

Generates a syslog if the number of packets that get dropped for a specific flow exceed the configured packet count.

Step 3

no hardware ip glean throttle syslog pck-count

Example:

switch(config)# no hardware ip glean throttle syslog 1030

Applies the default limits.

The default is 10000 packet hit. The range is from 0 to 65535 packets.

Note After the timeout period is exceeded, the drop adjacencies are removed from the FIB.

Step 4

copy running-config startup-config

Example:

switch(config)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to generate a syslog if the number of packets that get dropped for a specific flow exceeds the configured packet count:

switch# config t

switch(config)# hardware ip glean throttle syslog 1030

switch(config-if)# copy running-config startup-config

Verifying the IPv4 Configuration

To display the IPv4 configuration information, perform one of the following tasks:

Command

Purpose

show hardware forwarding ip verify

Displays the IP packet verification configuration.

show ip adjacency

Displays the adjacency table.

show ip adjacencysummary

Displays the summary of number of throttle adjacencies.

show ip arp

Displays the ARP table.

show ip arp summary

Displays the summary of number of throttle adjacencies.

show ip adjacency throttle statistics

Displays only the throttled adjacencies.

show ip interface

Displays IP related interface information.

show ip arp statistics [ vrf vrf-name ]

Displays the ARP statistics.

Configuration Examples for IPv4

This example shows how to configure an IPv4 address:

config t

interface e 1/2

no switchport

ip address 192.2.1.1/16

Field Descriptions for IP

See the Basic Parameters chapter in the Interfaces Configuration Guide, Cisco DCNM for LAN, Release 6.x , for information on IP address fields.

Additional References

For additional information related to implementing IP, see the following sections:

- Related Documents

- Standards

Related Documents

Related Topic

Document Title

IP CLI commands

Cisco Nexus 7000 Series NX-OS Unicast Routing Command Reference

Standards

Standards

Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.

—

Feature History for IP

Table 2-2 lists the release history for this feature.

Table 2-2 Feature History for IP

Feature Name

Releases

Feature Information

Glean Throttling

5.1(1)

Added support for IPv4 glean throttling.

ARP

4.1(4)

Added support to protect against an ARP broadcast storm.

IP

4.1(3)

Changed plaform ip verify command to hardware ip verify command.

ARP

4.0(3)

Added support for gratuitous ARP. The following command was added:

- ip arp gratuitous { request | update }

Feature Name

Releases

Feature Information

IP

4.0(1)

This feature was introduced.

Configuring IPv6

This chapter describes how to configure Internet Protocol version 6 (IPv6), which includes addressing, Neighbor Discovery Protocol (ND), and Internet Control Message Protocol version 6 (ICMPv6), on the Cisco Data Center Network Manager (DCNM). Cisco NX-OS device

This chapter includes the following sections:

- Information About IPv6

- Licensing Requirements for IPv6

- Prerequisites for IPv6

- Guidelines and Limitations for IPv6

- Guidelines and Limitations for IPv6

- Default SettingsConfiguring IPv6

- Verifying the IPv6 Configuration

- Configuration Examples for IPv6

- Additional References

- Feature History for IPv6

Information About IPv6

IPv6, which is designed to replace IPv4, increases the number of network address bits from 32 bits (in IPv4) to 128 bits. IPv6 is based on IPv4 but it includes a much larger address space and other improvements such as a simplified main header and extension headers.

The larger IPv6 address space allows networks to scale and provide global reachability. The simplified IPv6 packet header format handles packets more efficiently. The flexibility of the IPv6 address space reduces the need for private addresses and the use of Network Address Translation (NAT), which translates private (not globally unique) addresses into a limited number of public addresses. IPv6 enables new application protocols that do not require special processing by border routers at the edge of networks.

IPv6 functionality, such as prefix aggregation, simplified network renumbering, and IPv6 site multihoming capabilities, enable more efficient routing. IPv6 supports Routing Information Protocol (RIP), Integrated Intermediate System-to-Intermediate System (IS-IS), Open Shortest Path First (OSPF) for IPv6, and multiprotocol Border Gateway Protocol (BGP).

This section includes the following topics:

- IPv6 Address Formats

- IPv6 Unicast Addresses

- IPv6 Anycast Addresses

- IPv6 Multicast Addresses

- IPv4 Packet Header

- Simplified IPv6 Packet Header

- DNS for IPv6

- Path MTU Discovery for IPv6

- CDP IPv6 Address Support

- ICMP for IPv6

- IPv6 Neighbor Discovery

- IPv6 Neighbor Solicitation Message

- IPv6 Router Advertisement Message

- IPv6 Neighbor Redirect Message

- Virtualization Support

IPv6 Address Formats

An IPv6 address has 128 bits or 16 bytes. The address is divided into eight, 16-bit hexadecimal blocks separated by colons (:) in the format: x:x:x:x:x:x:x:x. Two examples of IPv6 addresses are as follows:

2001:0DB8:7654:3210:FEDC:BA98:7654:3210

2001:0DB8:0:0:8:800:200C:417A

IPv6 addresses contain consecutive zeros within the address. You can use two colons (::) at the beginning, middle, or end of an IPv6 address to replace the consecutive zeros. Table 3-1 shows a list of compressed IPv6 address formats.

Note You can use two colons (::) only once in an IPv6 address to replace the longest string of consecutive zeros within the address.

You can use a double colon as part of the IPv6 address when consecutive 16-bit values are denoted as zero. You can configure multiple IPv6 addresses per interface but only one link-local address.

The hexadecimal letters in IPv6 addresses are not case sensitive.

Table 3-1 Compressed IPv6 Address Formats

IPv6 Address Type

Preferred Format

Compressed Format

Unicast

2001:0:0:0:0DB8:800:200C:417A

2001::0DB8:800:200C:417A

Multicast

FF01:0:0:0:0:0:0:101

FF01::101

Loopback

0:0:0:0:0:0:0:0:1

::1

Unspecified

0:0:0:0:0:0:0:0:0

::

A node may use the loopback address listed in Table 3-1 to send an IPv6 packet to itself. The loopback address in IPv6 is the same as the loopback address in IPv4. For more information, see Chapter1, “Overview”

Note You cannot assign the IPv6 loopback address to a physical interface. A packet that contains the IPv6 loopback address as its source or destination address must remain within the node that created the packet. IPv6 routers do not forward packets that have the IPv6 loopback address as their source or destination address.

Note You cannot assign an IPv6 unspecified address to an interface. You should not use the unspecified IPv6 addresses as destination addresses in IPv6 packets or the IPv6 routing header.

The IPv6-prefix is in the form documented in RFC 2373 where the IPv6 address is specified in hexadecimal using 16-bit values between colons. The prefix length is a decimal value that indicates how many of the high-order contiguous bits of the address comprise the prefix (the network portion of the address). For example, 2001:0DB8:8086:6502::/32 is a valid IPv6 prefix.

IPv6 Unicast Addresses

An IPv6 unicast address is an identifier for a single interface, on a single node. A packet that is sent to a unicast address is delivered to the interface identified by that address. This section includes the following topics:

- Aggregatable Global Addresses

- Link-Local Addresses

- IPv4-Compatible IPv6 Addresses

- Unique Local Addresses

- Site-Local Address

Aggregatable Global Addresses

An aggregatable global address is an IPv6 address from the aggregatable global unicast prefix. The structure of aggregatable global unicast addresses enables strict aggregation of routing prefixes that limits the number of routing table entries in the global routing table. Aggregatable global addresses are used on links that are aggregated upward through organizations, and eventually to the Internet service providers (ISPs).

shows the structure of an aggregatable global address.Aggregatable global IPv6 addresses are defined by a global routing prefix, a subnet ID, and an interface ID. Except for addresses that start with binary 000, all global unicast addresses have a 64-bit interface ID. The IPv6 global unicast address allocation uses the range of addresses that start with binary value 001 (2000::/3).

Addresses with a prefix of 2000::/3 (001) through E000::/3 (111) are required to have 64-bit interface identifiers in the extended universal identifier (EUI)-64 format. The Internet Assigned Numbers Authority (IANA) allocates the IPv6 address space in the range of 2000::/16 to regional registries.

The aggregatable global address consists of a 48-bit global routing prefix and a 16-bit subnet ID or Site-Level Aggregator (SLA). In the IPv6 aggregatable global unicast address format document (RFC 2374), the global routing prefix included two other hierarchically structured fields called Top-Level Aggregator (TLA) and Next-Level Aggregator (NLA). The IETF decided to remove the TLS and NLA fields from the RFCs because these fields are policy based. Some existing IPv6 networks deployed before the change might still use networks that are on the older architecture.

A subnet ID, which is a 16-bit subnet field, can be used by individual organizations to create a local addressing hierarchy and to identify subnets. A subnet ID is similar to a subnet in IPv4, except that an organization with an IPv6 subnet ID can support up to 65,535 individual subnets.

An interface ID identifies interfaces on a link. The interface ID is unique to the link. In many cases, an interface ID is the same as or based on the link-layer address of an interface. Interface IDs used in aggregatable global unicast and other IPv6 address types are 64 bits long and are in the modified EUI-64 format.

Interface IDs are in the modified EUI-64 format in one of the following ways:

- For all IEEE 802 interface types (for example, Ethernet, and Fiber Distributed Data interfaces), the first three octets (24 bits) are the Organizationally Unique Identifier (OUI) of the 48-bit link-layer address (MAC address) of the interface, the fourth and fifth octets (16 bits) are a fixed hexadecimal value of FFFE, and the last three octets (24 bits) are the last three octets of the MAC address. The Universal/Local (U/L) bit, which is the seventh bit of the first octet, has a value of 0 or 1. Zero indicates a locally administered identifier; 1 indicates a globally unique IPv6 interface identifier.

- For all other interface types (for example, serial, loopback, ATM, Frame Relay, and tunnel interface types—except tunnel interfaces used with IPv6 overlay tunnels), the interface ID is similar to the interface ID for IEEE 802 interface types; however, the first MAC address from the pool of MAC addresses in the router is used as the identifier (because the interface does not have a MAC address).

- For tunnel interface types that are used with IPv6 overlay tunnels, the interface ID is the IPv4 address assigned to the tunnel interface with all zeros in the high-order 32 bits of the identifier.

Note For interfaces that use the Point-to-Point Protocol (PPP), where the interfaces at both ends of the connection might have the same MAC address, the interface identifiers at both ends of the connection are negotiated (picked randomly and, if necessary, reconstructed) until both identifiers are unique. The first MAC address in the router is used as the identifier for interfaces using PPP.

If no IEEE 802 interface types are in the router, link-local IPv6 addresses are generated on the interfaces in the router in the following sequence:

1. The router is queried for MAC addresses (from the pool of MAC addresses in the router).

2. If no MAC addresses are available in the router, the serial number of the router is used to form the link-local addresses.

3. If the serial number of the router cannot be used to form the link-local addresses, the router uses a Message Digest 5 (MD5) hash to determine the MAC address of the router from the hostname of the router.

Link-Local Addresses

A link-local address is an IPv6 unicast address that can be automatically configured on any interface using the link-local prefix FE80::/10 (1111 1110 10) and the interface identifier in the modified EUI-64 format. Link-local addresses are used in the neighbor discovery protocol and the stateless autoconfiguration process. Nodes on a local link can use link-local addresses to communicate; the nodes do not need globally unique addresses to communicate. Figure 3-1 shows the structure of a link-local address.

IPv6 routers cannot forward packets that have link-local source or destination addresses to other links.

Figure 3-1 Link-Local Address Format

IPv4-Compatible IPv6 Addresses

An IPv4-compatible IPv6 address is an IPv6 unicast address that has zeros in the high-order 96 bits of the address and an IPv4 address in the low-order 32 bits of the address. The format of an IPv4-compatible IPv6 address is 0:0:0:0:0:0:A.B.C.D or ::A.B.C.D. The entire 128-bit IPv4-compatible IPv6 address is used as the IPv6 address of a node and the IPv4 address embedded in the low-order 32 bits is used as the IPv4 address of the node. IPv4-compatible IPv6 addresses are assigned to nodes that support both the IPv4 and IPv6 protocol stacks and are used in automatic tunnels. Figure 3-2 shows the structure of an IPv4-compatible IPv6 address and a few acceptable formats for the address.

Figure 3-2 IPv4-Compatible IPv6 Address Format

Unique Local Addresses

A unique local address is an IPv6 unicast address that is globally unique and is intended for local communications. It is not expected to be routable on the global Internet and is routable inside of a limited area, such as a site and it may be routed between a limited set of sites. Applications may treat unique local addresses like global scoped addresses.

A unique local address has the following characteristics:

- It has a globally unique prefix (it has a high probability of uniqueness).

- It has a well-known prefix to allow for easy filtering at site boundaries.

- It allows sites to be combined or privately interconnected without creating any address conflicts or requiring renumbering of interfaces that use these prefixes.

- It is ISP-independent and can be used for communications inside of a site without having any permanent or intermittent Internet connectivity.

- If it is accidentally leaked outside of a site via routing or Domain Name Server (DNS), there is no conflict with any other addresses.

Figure 3-3 shows the structure of a unique local address.

Figure 3-3 Unique Local Address Structure

Site-Local Address

Because RFC 3879 deprecates the use of site-local addresses, you should follow the recommendations of unique local addressing (ULA) in RFC 4193 when you configure private IPv6 addresses.

IPv6 Anycast Addresses

An anycast address is an address that is assigned to a set of interfaces that belong to different nodes. A packet sent to an anycast address is delivered to the closest interface—as defined by the routing protocols in use—identified by the anycast address. Anycast addresses are syntactically indistinguishable from unicast addresses because anycast addresses are allocated from the unicast address space. Assigning a unicast address to more than one interface turns a unicast address into an anycast address. You must configure the nodes to which the anycast address to recognize that the address is an anycast address.

Note Anycast addresses can be used only by a router, not a host. Anycast addresses cannot be used as the source address of an IPv6 packet.

Figure 3-4 shows the format of the subnet router anycast address; the address has a prefix concatenated by a series of zeros (the interface ID). The subnet router anycast address can be used to reach a router on the link that is identified by the prefix in the subnet router anycast address.

Figure 3-4 Subnet Router Anycast Address Format

IPv6 Multicast Addresses

An IPv6 multicast address is an IPv6 address that has a prefix of FF00::/8 (1111 1111). An IPv6 multicast address is an identifier for a set of interfaces that belong to different nodes. A packet sent to a multicast address is delivered to all interfaces identified by the multicast address. The second octet following the prefix defines the lifetime and scope of the multicast address. A permanent multicast address has a lifetime parameter equal to 0; a temporary multicast address has a lifetime parameter equal to 1. A multicast address that has the scope of a node, link, site, or organization, or a global scope, has a scope parameter of 1, 2, 5, 8, or E, respectively. For example, a multicast address with the prefix FF02::/16 is a permanent multicast address with a link scope. Figure 3-5 shows the format of the IPv6 multicast address.

Figure 3-5 IPv6 Multicast Address Format

IPv6 nodes (hosts and routers) are required to join (where received packets are destined for) the following multicast groups:

- All-nodes multicast group FF02:0:0:0:0:0:0:1 (the scope is link-local)

- Solicited-node multicast group FF02:0:0:0:0:1:FF00:0000/104 for each of its assigned unicast and anycast addresses

IPv6 routers must also join the all-routers multicast group FF02:0:0:0:0:0:0:2 (the scope is link-local).

The solicited-node multicast address is a multicast group that corresponds to an IPv6 unicast or anycast address. IPv6 nodes must join the associated solicited-node multicast group for every unicast and anycast address to which it is assigned. The IPv6 solicited-node multicast address has the prefix FF02:0:0:0:0:1:FF00:0000/104 concatenated with the 24 low-order bits of a corresponding IPv6 unicast or anycast address (see Figure 3-6). For example, the solicited-node multicast address that corresponds to the IPv6 address 2037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. Solicited-node addresses are used in neighbor solicitation messages.

Figure 3-6 IPv6 Solicited-Node Multicast Address Format

Note IPv6 has no broadcast addresses. IPv6 multicast addresses are used instead of broadcast addresses.

IPv4 Packet Header

The basic IPv4 packet header has 12 fields with a total size of 20 octets (160 bits) (see Figure 3-7). The 12 fields may be followed by an Options field, which is followed by a data portion that is usually the transport-layer packet. The variable length of the Options field adds to the total size of the IPv4 packet header. The shaded fields of the IPv4 packet header are not included in the IPv6 packet header.

Figure 3-7 IPv4 Packet Header Format

Simplified IPv6 Packet Header

The basic IPv6 packet header has 8 fields with a total size of 40 octets (320 bits) (see Figure 3-8). Fragmentation is handled by the source of a packet and checksums at the data link layer and transport layer are used. The User Datagram Protocol (UDP) checksum checks the integrity of the inner packet and the basic IPv6 packet header and Options field are aligned to 64 bits, which can facilitate the processing of IPv6 packets.

Table 3-2 lists the fields in the basic IPv6 packet header.

Table 3-2 Basic IPv6 Packet Header Fields

Field

Description

Version

Similar to the Version field in the IPv4 packet header, except that the field lists number 6 for IPv6 instead of number 4 for IPv4.

Traffic Class

Similar to the Type of Service field in the IPv4 packet header. The Traffic Class field tags packets with a traffic class that is used in differentiated services.

Flow Label

New field in the IPv6 packet header. The Flow Label field tags packets with a specific flow that differentiates the packets at the network layer.

Payload Length

Similar to the Total Length field in the IPv4 packet header. The Payload Length field indicates the total length of the data portion of the packet.

Next Header

Similar to the Protocol field in the IPv4 packet header. The value of the Next Header field determines the type of information following the basic IPv6 header. The type of information following the basic IPv6 header can be a transport-layer packet, for example, a TCP or UDP packet, or an Extension Header, as shown in Figure 3-8.

Hop Limit

Similar to the Time to Live field in the IPv4 packet header. The value of the Hop Limit field specifies the maximum number of routers that an IPv6 packet can pass through before the packet is considered invalid. Each router decrements the value by one. Because no checksum is in the IPv6 header, the router can decrement the value without needing to recalculate the checksum, which saves processing resources.

Source Address

Similar to the Source Address field in the IPv4 packet header, except that the field contains a 128-bit source address for IPv6 instead of a 32-bit source address for IPv4.

Destination Address

Similar to the Destination Address field in the IPv4 packet header, except that the field contains a 128-bit destination address for IPv6 instead of a 32-bit destination address for IPv4.

Figure 3-8 IPv6 Packet Header Format

Optional extension headers and the data portion of the packet are after the eight fields of the basic IPv6 packet header. If present, each extension header is aligned to 64 bits. There is no fixed number of extension headers in an IPv6 packet. Each extension header is identified by the Next Header field of the previous header. Typically, the final extension header has a Next Header field of a transport-layer protocol, such as TCP or UDP. Figure 3-9 shows the IPv6 extension header format.

Figure 3-9 IPv6 Extension Header Format

Table 3-3 lists the extension header types and their Next Header field values.

Table 3-3 IPv6 Extension Header Types

Header Type

Next Header Value

Description

Hop-by-hop options header

0

Header that is processed by all hops in the path of a packet. When present, the hop-by-hop options header always follows immediately after the basic IPv6 packet header.

Destination options header

6

Header that can follow any hop-by-hop options header. The header is processed at the final destination and at each visited address specified by a routing header. Alternatively, the destination options header can follow any Encapsulating Security Payload (ESP) header. The destination options header is processed only at the final destination.

Routing header

43

Header that is used for source routing.

Fragment header

44

Header that is used when a source fragments a packet that is larger than the Maximum Transmission Unit (MTU) for the path between itself and a destination. The Fragment header is used in each fragmented packet.

Upper-layer headers

6 (TCP)

17 (UDP)

Headers that are used inside a packet to transport the data. The two main transport protocols are TCP and UDP.

DNS for IPv6

IPv6 supports DNS record types that are supported in the DNS name-to-address and address-to-name lookup processes. The DNS record types support IPv6 addresses (see Table 3-4 ).

Note IPv6 also supports the reverse mapping of IPv6 addresses to DNS names.

Table 3-4 IPv6 DNS Record Types

Record Type

Description

Format

AAAA

Maps a hostname to an IPv6 address. (Equivalent to an A record in IPv4.)

www.abc.test AAAA 3FFE:YYYY:C18:1::2

PTR

Maps an IPv6 address to a hostname. (Equivalent to a PTR record in Ipv4.)

2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.8.1.c.0.y.y.y.y.e.f.f.3.ip6.int PTR www.abc.test

Path MTU Discovery for IPv6

As in IPv4, you can use path MTU discovery in IPv6 to allow a host to dynamically discover and adjust to differences in the MTU size of every link along a data path. In IPv6, however, fragmentation is handled by the source of a packet when the path MTU of one link along a given data path is not large enough to accommodate the size of the packets. Having IPv6 hosts handle packet fragmentation saves IPv6 router processing resources and helps IPv6 networks run more efficiently. Once the path MTU is reduced by the arrival of an ICMP Too Big message, Cisco NX-OS retains the lower value. The connection will not increase the segment size periodically to gauge the throughput.

Note In IPv6, the minimum link MTU is 1280 octets. We recommend that you use an MTU value of 1500 octets for IPv6 links.

CDP IPv6 Address Support

You can use the Cisco Discovery Protocol (CDP) IPv6 address support for neighbor information feature to transfer IPv6 addressing information between two Cisco devices. Cisco Discovery Protocol support for IPv6 addresses provides IPv6 information to network management products and troubleshooting tools.

ICMP for IPv6

You can use ICMP in IPv6 to provide information about the health of the network. ICMPv6, the version that works with IPv6, reports errors if packets cannot be processed correctly and sends informational messages about the status of the network. For example, if a router cannot forward a packet because it is too large to be sent out on another network, the router sends out an ICMPv6 message to the originating host. Additionally, ICMP packets in IPv6 are used in IPv6 neighbor discovery and path MTU discovery. The path MTU discovery process ensures that a packet is sent using the largest possible size that is supported on a specific route.

A value of 58 in the Next Header field of the basic IPv6 packet header identifies an IPv6 ICMP packet. The ICMP packet follows all the extension headers and is the last piece of information in the IPv6 packet.Within the IPv6 ICMP packets, the ICMPv6 Type and ICMPv6 Code fields identify IPv6 ICMP packet specifics, such as the ICMP message type. The value in the Checksum field is computed by the sender and checked by the receiver from the fields in the IPv6 ICMP packet and the IPv6 pseudo header.

Note The IPv6 header does not have a checksum. But a checksum is important on the transport layer to determine misdelivery of packets. All checksum calculations that include the IP address in the calculation must be modified for IPv6 to accommodate the new 128-bit address. A checksum is generated using a pseudo header.

The ICMPv6 Data field contains error or diagnostic information that relates to IP packet processing. Figure 3-10 shows the IPv6 ICMP packet header format.

Figure 3-10 IPv6 ICMP Packet Header Format

IPv6 Neighbor Discovery

You can use the IPv6 Neighbor Discovery Protocol (NDP) to determine whether a neighboring router is reachable. IPv6 nodes use neighbor discovery to determine the addresses of nodes on the same network (local link), to find neighboring routers that can forward their packets, to verify whether neighboring routers are reachable or not, and to detect changes to link-layer addresses. NDP uses ICMP messages to detect whether packets are sent to neighboring routers that are unreachable.

IPv6 Neighbor Solicitation Message

A node sends a Neighbor solicitation message, which has a value of 135 in the Type field of the ICMP packet header, on the local link when it wants to determine the link-layer address of another node on the same local link (see Figure 3-11). The source address is the IPv6 address of the node that sends the neighbor solicitation message. The destination address is the solicited-node multicast address that corresponds to the IPv6 address of the destination node. The neighbor solicitation message also includes the link-layer address of the source node.

Figure 3-11 IPv6 Neighbor Discovery—Neighbor Solicitation Message

After receiving the neighbor solicitation message, the destination node replies by sending a neighbor advertisement message, which has a value of 136 in the Type field of the ICMP packet header, on the local link. The source address is the IPv6 address of the node (the IPv6 address of the node interface that sends the neighbor advertisement message). The destination address is the IPv6 address of the node that sent the neighbor solicitation message. The data portion includes the link-layer address of the node that sends the neighbor advertisement message.

After the source node receives the neighbor advertisement, the source node and destination node can communicate.

Neighbor solicitation messages can verify the reachability of a neighbor after a node identifies the link-layer address of a neighbor. When a node wants to verify the reachability of a neighbor, it uses the destination address in a neighbor solicitation message as the unicast address of the neighbor.

Neighbor advertisement messages are also sent when there is a change in the link-layer address of a node on a local link. When there is a change, the destination address for the neighbor advertisement is the all-nodes multicast address.

Neighbor unreachability detection identifies the failure of a neighbor or the failure of the forward path to the neighbor and is used for all paths between hosts and neighboring nodes (hosts or routers). Neighbor unreachability detection is performed for neighbors to which only unicast packets are being sent and is not performed for neighbors to which multicast packets are being sent.

A neighbor is considered reachable when a positive acknowledgment is returned from the neighbor (indicating that packets previously sent to the neighbor have been received and processed). A positive acknowledgment—from an upper-layer protocol (such as TCP)—indicates that a connection is making forward progress (reaching its destination). If packets are reaching the peer, they are also reaching the next-hop neighbor of the source. Forward progress is also a confirmation that the next-hop neighbor is reachable.

For destinations that are not on the local link, forward progress implies that the first-hop router is reachable. When acknowledgments from an upper-layer protocol are not available, a node probes the neighbor using unicast neighbor solicitation messages to verify that the forward path is still working. The return of a solicited neighbor advertisement message from the neighbor is a positive acknowledgment that the forward path is still working (neighbor advertisement messages that have the solicited flag set to a value of 1 are sent only in response to a neighbor solicitation message). Unsolicited messages confirm only the one-way path from the source to the destination node; solicited neighbor advertisement messages indicate that a path is working in both directions.

Note A neighbor advertisement message that has the solicited flag set to a value of 0 is not considered as a positive acknowledgment that the forward path is still working.

Neighbor solicitation messages are also used in the stateless autoconfiguration process to verify the uniqueness of unicast IPv6 addresses before the addresses are assigned to an interface. Duplicate address detection is performed first on a new, link-local IPv6 address before the address is assigned to an interface (the new address remains in a tentative state while duplicate address detection is performed). A node sends a neighbor solicitation message with an unspecified source address and a tentative link-local address in the body of the message. If another node is already using that address, the node returns a neighbor advertisement message that contains the tentative link-local address. If another node is simultaneously verifying the uniqueness of the same address, that node also returns a neighbor solicitation message. If no neighbor advertisement messages are received in response to the neighbor solicitation message and no neighbor solicitation messages are received from other nodes that are attempting to verify the same tentative address, the node that sent the original neighbor solicitation message considers the tentative link-local address to be unique and assigns the address to the interface.

IPv6 Router Advertisement Message

Router advertisement (RA) messages, which have a value of 134 in the Type field of the ICMP packet header, are periodically sent out to each configured interface of an IPv6 router. For stateless autoconfiguration to work properly, the advertised prefix length in RA messages must always be 64 bits.

The RA messages are sent to the all-nodes multicast address (see Figure 3-12).

Figure 3-12 IPv6 Neighbor Discovery—RA Message

RA messages typically include the following information:

- One or more onlink IPv6 prefixes that nodes on the local link can use to automatically configure their IPv6 addresses

- Life-time information for each prefix included in the advertisement

- Sets of flags that indicate the type of autoconfiguration (stateless or stateful) that can be completed

- Default router information (whether the router sending the advertisement should be used as a default router and, if so, the amount of time in seconds that the router should be used as a default router)

- Additional information for hosts, such as the hop limit and MTU that a host should use in packets that it originates

RAs are also sent in response to router solicitation messages. Router solicitation messages, which have a value of 133 in the Type field of the ICMP packet header, are sent by hosts at system startup so that the host can immediately autoconfigure without needing to wait for the next scheduled RA message. The source address is usually the unspecified IPv6 address (0:0:0:0:0:0:0:0). If the host has a configured unicast address, the unicast address of the interface that sends the router solicitation message is used as the source address in the message. The destination address is the all-routers multicast address with a scope of the link. When an RA is sent in response to a router solicitation, the destination address in the RA message is the unicast address of the source of the router solicitation message.

You can configure the following RA message parameters:

- The time interval between periodic RA messages

- The router life-time value, which indicates the usefulness of a router as the default router (for use by all nodes on a given link)

- The network prefixes in use on a given link

- The time interval between neighbor solicitation message retransmissions (on a given link)

- The amount of time that a node considers a neighbor reachable (for use by all nodes on a given link)

The configured parameters are specific to an interface. The sending of RA messages (with default values) is automatically enabled on Ethernet interfaces. For other interface types, you must enter the no ipv6 nd suppress-ra command to send RA messages. You can disable the RA message feature on individual interfaces by entering the ipv6 nd suppress-ra command.

IPv6 Neighbor Redirect Message

Routers send neighbor redirect messages to inform hosts of better first-hop nodes on the path to a destination (see Figure 3-13). A value of 137 in the Type field of the ICMP packet header identifies an IPv6 neighbor redirect message.

Figure 3-13 IPv6 Neighbor Discovery—Neighbor Redirect Message

Note A router must be able to determine the link-local address for each of its neighboring routers in order to ensure that the target address (the final destination) in a redirect message identifies the neighbor router by its link-local address. For static routing, you should specify the address of the next-hop router using the link-local address of the router. For dynamic routing, you must configure all IPv6 routing protocols to exchange the link-local addresses of neighboring routers.

After forwarding a packet, a router sends a redirect message to the source of the packet under the following circumstances:

- The destination address of the packet is not a multicast address.

- The packet was not addressed to the router.

- The packet is about to be sent out the interface on which it was received.

- The router determines that a better first-hop node for the packet resides on the same link as the source of the packet.

- The source address of the packet is a global IPv6 address of a neighbor on the same link or a link-local address.

Virtualization Support

IPv6 supports Virtual Routing and Forwarding instances (VRFs). VRFs exist within virtual device contexts (VDCs). By default, Cisco NX-OS places you in the default VDC and default VRF unless you specifically configure another VDC and VRF.

Licensing Requirements for IPv6

The following table shows the licensing requirements for this feature:

Product

License Requirement

Cisco DCNM

IPv6 requires no license. Any feature not included in a license package is bundled with the Cisco DCNM and is provided at no charge to you. For a complete explanation of the Cisco DCNM licensing scheme, see the Cisco DCNM Installation and Licensing Guide, Release 5.x .

Cisco NX-OS

IPv6 requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. For an explanation of the Cisco NX-OS licensing scheme for your platform, see the licensing guide for your platform.For a complete explanation of the Cisco NX-OS licensing scheme, see the Cisco NX-OS Licensing Guide

Prerequisites for IPv6

IPv6 has the following prerequisites:

- You must be familiar with IPv6 basics such as IPv6 addressing, IPv6 header information, ICMPv6, and IPv6 Neighbor Discovery (ND) Protocol.

- Ensure that you follow the memory/processing guidelines when you make a device a dual-stack device (IPv4/IPv6).

Guidelines and Limitations for IPv6

IPv6 has the following configuration guidelines and limitations:

- IPv6 packets are transparent to Layer 2 LAN switches because the switches do not examine Layer 3 packet information before forwarding IPv6 frames. IPv6 hosts can be directly attached to Layer 2 LAN switches.

- You can configure multiple IPv6 global addresses within the same prefix on an interface. However, multiple IPv6 link-local addresses on an interface are not supported.

- Because RFC 3879 deprecates the use of site-local addresses, you should configure private IPv6 addresses according to the recommendations of unique local addressing (ULA) in RFC 4193.

Default Settings

Table 3-5 lists the default settings for IPv6 parameters.

Table 3-5 Default IPv6 Parameters

Parameters

Default

ND reachable time

0 milliseconds

neighbor solicitation retransmit interval

1000 milliseconds

Platform Support

The following platforms support this feature but may implement it differently. For platform-specific information, including guidelines and limitations, system defaults, and configuration limits, see the corresponding documentation.

Platform

Documentation

Cisco Nexus 1000V Series Switches (mgmt0 port only)

Cisco Nexus 1000V Series Switches Documentation

Cisco Nexus 4000 Series Switches (mgmt0 port only)

Cisco Nexus 4000 Series Switches Documentation

Cisco Nexus 7000 Series Switches

Cisco Nexus 7000 Series Switches Documentation

Configuring IPv6

You can configure IPv6 addresses for Layer 3 interfaces from the Interfaces feature selection.

For more information about the Data Center Network Manager features, see the Fundamentals Configuration Guide, Cisco DCNM for LAN, Release 5.x .

This section includes the following topics:

- Configuring IPv6 Addressing

- Configuring an IPv6 Secondary Address

- Configuring IPv6 Neighbor Discovery

- Configuring IPv6 Packet Verification

Note If you are familiar with the Cisco IOS CLI, be aware that the Cisco NX-OS commands for this feature might differ from the Cisco IOS commands that you would use.

Configuring IPv6 Addressing

You must configure an IPv6 address on an interface for the interface to forward IPv6 traffic. When you configure a global IPv6 address on an interface, it automatically configures a link-local address and activates IPv6 for that interface.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. interface ethernet number

3. ipv6 address { addr [ eui64 ] [ route-preference preference ] [ secondary ] tag tag-id ] ]

or

ipv6 address ipv6-address use-link-local-only

4. show ipv6 interface

5. copy running-config startup-config

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Interfaces > Physical > Ethernet .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device to display a list of slots.

Step 3 Double-click the slot to display a list of interfaces.

Step 4 Click the interface that you want to configure as a routed interface.

The system highlights the interface in the Summary pane, and tabs appear in the Details pane.

Step 5 From the Details pane, click the Port Details tab.

The Port Details tab appears.

Step 6 From the Port Details tab, expand the Port Mode Settings section.

The port mode appears.

Step 7 From the Mode drop-down list, choose Routed .

The IP address information appears in the Details pane and Cisco NX-OS removes any Layer 2 configuration.

Step 8 From the IPv6 Address Settings area, set the Primary/prefix-length field to the IPv6 address and prefix length for this routed interface.

The length range is from 1 to 128.

Step 9 (Optional) To set EUI64, check EUI64 .

Step 10 (Optional) From the Link local field, enter the link local IPv6 address.

Step 11 (Optional) To set this routed interface for link-local routing only, check Use local only .

Step 12 From the menu bar, choose File > Deploy to apply your changes to the device.

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

interface ethernet number

Example:

switch(config)# interface ethernet 2/3

switch(config-if)#

Enters interface configuration mode.

Step 3

ipv6 address { addr [ eui64 ] [ route-preference preference ] [ secondary ] tag tag-id ]

or

ipv6 address ipv6-address use-link-local-only

Example:

switch(config-if)# ipv6 address 2001:0DB8::1/10

or

switch(config-if)# ipv6 address use-link-local-only

Specifies an IPv6 address assigned to the interface and enables IPv6 processing on the interface.

Specifying the ipv6 address command configures global IPv6 addresses with an interface identifier (ID) in the low-order 64 bits of the IPv6 address. Only the 64-bit network prefix for the address needs to be specified; the last 64 bits are automatically computed from the interface ID.

Specifying the ipv6 address use-link-local-only command configures a link-local address on the interface that is used instead of the link-local address that is automatically configured when IPv6 is enabled on the interface.

Enables IPv6 processing on an interface without configuring an IPv6 address.

Step 4

show ipv6 interface

Example:

switch(config-if)# show ipv6 interface

(Optional) Displays interfaces configured for IPv6.

Step 5

copy running-config startup-config

Example:

switch(config-if)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to configure an IPv6 address:

switch# config t

switch(config)# interface ethernet 3/1

switch(config-if)# ipv6 address ?

A:B::C:D/LEN IPv6 prefix format: xxxx:xxxx/ml, xxxx:xxxx::/ml,

xxxx::xx/128

use-link-local-only Enable IPv6 on interface using only a single link-local

address

switch(config-if)# ipv6 address dc3:dc3::/64 eui64

This example shows how to display an IPv6 interface:

switch(config-if)# show ipv6 interface ethernet 3/1

Ethernet3/1, Interface status: protocol-down/link-down/admin-down, iod: 36

IPv6 address: 0dc3:0dc3:0000:0000:0218:baff:fed8:239d

IPv6 subnet: 0dc3:0dc3:0000:0000:0000:0000:0000:0000/64

IPv6 link-local address: fe80::0218:baff:fed8:239d (default)

IPv6 multicast routing: disabled

IPv6 multicast groups locally joined:

ff02::0001:ffd8:239d ff02::0002 ff02::0001 ff02::0001:ffd8:239d

IPv6 multicast (S,G) entries joined: none

IPv6 MTU: 1500 (using link MTU)

IPv6 RP inbound packet-filtering policy: none

IPv6 RP outbound packet-filtering policy: none

IPv6 inbound packet-filtering policy: none

IPv6 outbound packet-filtering policy: none

IPv6 interface statistics last reset: never

IPv6 interface RP-traffic statistics: (forwarded/originated/consumed)

Unicast packets: 0/0/0

Unicast bytes: 0/0/0

Multicast packets: 0/0/0

Multicast bytes: 0/0/0

Configuring an IPv6 Secondary Address

You can configure secondary addresses or helper addresses for an interface.

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Interfaces > Physical > Ethernet .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, double-click the device to display a list of slots.

Step 3 Double-click the slot to display a list of interfaces.

Step 4 Click the interface that you want to configure as a routed interface.

The system highlights the interface in the Summary pane, and tabs appear in the Details pane.

Step 5 From the Details pane, click the Port Details tab.

The Port Details tab appears.

Step 6 From the Port Details tab, expand the Port Mode Settings section.

The port mode appears.

Step 7 From the IPv6 Address settings section, in the Secondary area, right-click and choose Add IPv6 Address to add a secondary IPv6 address.

Step 8 From the IP Address/Prefix-length field, enter the IPv6 address and prefix length for this secondary IPv6 address.

Step 9 (Optional) To set EUI64 format, check EUI64 .

Step 10 From the menu bar, choose File > Deploy to apply your changes to the device.

Configuring IPv6 Neighbor Discovery

You can configure IPv6 neighbor discovery on the router. The neighbor discovery protocol enables IPv6 nodes and routers to determine the link-layer address of a neighbor on the same link, find neighboring routers, and keep track of neighbors.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command). You must first enable IPv6 on the interface.

SUMMARY STEPS

1. config t

2. interface ethernet number

3. ipv6 nd

4. show ipv6 nd interface

5. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

interface ethernet number

Example:

switch(config)# interface ethernet 2/31

switch(config-if)#

Enters interface configuration mode.

Step 3

ipv6 nd

Example:

switch(config-if)# ipv6 nd

Enables IPv6 neighbor discovery on the interface.

Step 4

show ipv6 nd interface

Example:

switch(config-if)# show ipv6 nd interface

(Optional) Displays interfaces configured for IPv6 neighbor discovery.

Step 5

copy running-config startup-config

Example:

switch(config-if)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to configure IPv6 neighbor discovery reachable time:

switch# config t

switch(config)# interface ethernet 3/1

switch(config-if)# ipv6 nd reachable-time 10

This example shows how to display an IPv6 neighbor discovery interface:

switch(config-if)# show ipv6 nd interface ethernet 3/1

ICMPv6 ND Interfaces for VRF "default"

Ethernet3/1, Interface status: protocol-down/link-down/admin-down

IPv6 address: 0dc3:0dc3:0000:0000:0218:baff:fed8:239d

ICMPv6 active timers:

Last Neighbor-Solicitation sent: never

Last Neighbor-Advertisement sent: never

Last Router-Advertisement sent:never

Next Router-Advertisement sent in: 0.000000

Router-Advertisement parameters:

Periodic interval: 200 to 600 seconds

Send "Managed Address Configuration" flag: false

Send "Other Stateful Configuration" flag: false

Send "Current Hop Limit" field: 64

Send "MTU" option value: 1500

Send "Router Lifetime" field: 1800 secs

Send "Reachable Time" field: 10 ms

Send "Retrans Timer" field: 0 ms

Neighbor-Solicitation parameters:

NS retransmit interval: 1000 ms

ICMPv6 error message parameters:

Send redirects: false

Send unreachables: false

Optional IPv6 Neighbor Discovery

You can use the following optional IPv6 Neighbor Discovery commands:

Command

Purpose

ipv6 nd hop-limit

Configures the maximum number of hops used in router advertisements and all IPv6 packets that are originated by the router.

ipv6 nd managed-config-flag

Sets the managed address configuration flag in IPv6 router advertisements.

ipv6 nd mtu

Sets the maximum transmission unit (MTU) size of IPv6 packets sent on an interface.

ipv6 nd ns-interval

Configures the interval between IPv6 neighbor solicitation retransmissions on an interface.

ipv6 nd other-config-flag

Configures the other stateful configuration flag in IPv6 router advertisements.

ipv6 nd ra-interval

Configures the interval between IPv6 router advertisement (RA) transmissions on an interface.

ipv6 nd ra-lifetime

Configures the router lifetime value in IPv6 router advertisements on an interface.

ipv6 nd reachable-time

Configures the amount of time that a remote IPv6 node is considered reachable after some reachability confirmation event has occurred.

ipv6 nd redirects

Enables ICMPv6 redirect messages to be sent.

ipv6 nd retrans-timer

Configures the advertised time between neighbor solicitation messages in router advertisements.

ipv6 nd suppress-ra

Suppresses IPv6 router advertisement transmissions on a LAN interface.

Configuring IPv6 Packet Verification

Cisco NX-OS supports an Intrusion Detection System (IDS) that checks for IPv6 packet verification. You can enable or disable these IDS checks.

To enable IDS checks, use the following commands in global configuration mode:

Command

Purpose

hardware ip verify address { destination zero | identical | reserved | source multicast }

Performs the following IDS checks on the IPv6 address:

- destination zero —Drops IPv6 packets if the destination IP address is ::.

- identical —Drops IPv6 packets if the source IPv6 address is identical to the destination IPv6 address.

- reserved —Drops IPv6 packets if the IPv6 address is in the ::1 range.

- source multicast —Drops IPv6 packets if the IPv6 source address is in the FF00::/8 range (multicast).

hardware ip verify checksum

Drops IPv6 packets if the packet checksum is invalid.

hardware ip verify fragment

Drops IPv6 packets if the packet fragment has a nonzero offset and the DF bit is active.

hardware ipv6 verify length { consistent | maximum { max-frag | max-tcp | udp }}

Performs the following IDS checks on the IPv6 address:

- consistent —Drops IPv6 packets where the Ethernet frame size is greater than or equal to the IPv6 packet length plus the Ethernet header.

- maximum max-frag —Drops IPv6 packets if the formula (IPv6 Payload Length – IPv6 Extension Header Bytes) + (Fragment Offset * 8) is greater than 65536.

- maximum max-tcp —Drops IPv6 packets if the TCP length is greater than the IP payload length.

- maximum udp —Drops IPv6 packets if the IPv6 payload length is less than the UDP packet length.

hardware ipv6 verify tcp tiny-frag

Drops TCP packets if the IPv6 fragment offset is 1, or if the IPv6 fragment offset is 0 and the IP payload length is less than 16.

hardware ipv6 verify version

Drops IPv6 packets if the ethertype is not set to 6 (IPv6).

Use the show hardware forwarding ip verify command to display the IPv6 packet verification configuration.

Verifying the IPv6 Configuration

To display configuration information, perform one of the following tasks:

Command

Purpose

show hardware forwarding ip verify

Displays the IPv4 and IPv6 packet verification configuration.

show ipv6 interface

Displays IPv6 related interface information.

show ipv6 adjacency

Displays the adjacency table.

show ipv6 icmp

Displays ICMPv6 information.

show ipv6 nd

Displays IPv6 neighbor discovery interface information.

show ipv6 neighbor

Displays IPv6 neighbor entry.

Configuration Examples for IPv6

This example shows how to configure IPv6:

config t

interface ethernet 3/1

ipv6 address dc3:dc3::/64 eui64

ipv6 nd reachable-time 10

Field Descriptions for IPv6

See the Basic Parameters chapter in the Interfaces Configuration Guide, Cisco DCNM for LAN, Release 6.x , for information on IPv6 address fields.

Additional References

For additional information related to implementing IPv6, see the following sections:

- Related Documents

- Standards

Related Documents

Related Topic

Document Title

IPv6 CLI commands

Cisco Nexus 7000 Series NX-OS Unicast Routing Command Reference

Standards

Standards

Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.

—

Feature History for IPv6

Table 3-6 lists the release history for this feature.

Table 3-6 Feature History for IPv6

Feature Name

Releases

Feature Information

IPv6 path MTU discovery

5.0(2)

Added support for IPv6 path MTU discovery.

IPv6

4.1(3)

Changed the plaform { ip | ipv6 } verify command to the hardware { ip | ipv6 } verify command.

IPv6 address

4.0(3)

Added the tag keyword to the ipv6 address command.

Feature Name

Releases

Feature Information

IPv6

4.0(1)

This feature was introduced.

Configuring GLBP

This chapter describes how to configure the Gateway Load Balancing Protocol (GLBP) on the Cisco Data Center Network Manager (DCNM)NX-OS device.

This chapter includes the following sections:

- Information About GLBP

- Licensing Requirements for GLBP

- Prerequisites for GLBP

- Guidelines and Limitations

- Default Settings

- Platform Support

- Configuring GLBP

- Verifying the GLBP Configuration

- Configuration Examples for GLBP

- Field Descriptions for GLBP

- Additional References

- Feature History for GLBP

Information About GLBP

GLBP provides path redundancy for IP by sharing protocol and Media Access Control (MAC) addresses between redundant gateways. Additionally, GLBP allows a group of Layer 3 routers to share the load of the default gateway on a LAN. A GLBP router can automatically assume the forwarding function of another router in the group if the other router fails.

This section includes the following topics:

- GLBP Overview

- GLBP Active Virtual Gateway

- GLBP Virtual MAC Address Assignment

- GLBP Virtual Gateway Redundancy

- GLBP Virtual Forwarder Redundancy

- GLBP Authentication

- GLBP Load Balancing and Tracking

- High Availability and Extended Non-Stop Forwarding

- Virtualization Support

GLBP Overview

GLBP provides automatic gateway backup for IP hosts configured with a single default gateway on an IEEE 802.3 LAN. Multiple routers on the LAN combine to offer a single virtual first-hop IP gateway while sharing the IP packet forwarding load. Other routers on the LAN may act as redundant GLBP gateways that become active if any of the existing forwarding gateways fail.

GLBP performs a similar function to the Hot Standby Redundancy Protocol (HSRP) and the Virtual Router Redundancy Protocol (VRRP). HSRP and VRRP allow multiple routers to participate in a virtual group configured with a virtual IP address. These protocols elect one member as the active router to forward packets to the virtual IP address for the group. The other routers in the group are redundant until the active router fails.

GLBP performs an additional load balancing function that the other protocols do not provide. GLBP load balances over multiple routers (gateways) using a single virtual IP address and multiple virtual MAC addresses. GLBP shares the forwarding load among all routers in a GLBP group instead of allowing a single router to handle the whole load while the other routers remain idle. You configure each host with the same virtual IP address, and all routers in the virtual group participate in forwarding packets. GLBP members communicate between each other using periodic hello messages.

GLBP Active Virtual Gateway

GLBP prioritizes gateways to elect an active virtual gateway ( AVG) . If multiple gateways have the same priority, the gateway with the highest real IP address becomes the AVG. The AVG assigns a virtual MAC address to each member of the GLBP group. Each member is the active virtual forwarder ( AVF ) for its assigned virtual MAC address, forwarding packets sent to its assigned virtual MAC address.

The AVG also answers Address Resolution Protocol (ARP) requests for the virtual IP address. Load sharing is achieved when the AVG replies to the ARP requests with different virtual MAC addresses.

Note Packets received on a routed port destined for the GLBP virtual IP address will terminate on the local router, regardless of whether that router is the active GLBP router or a redundant GLBP router. This includes ping and Telnet traffic. Packets received on a Layer 2 (VLAN) interface destined for the GLBP virtual IP address will terminate on the active router.

GLBP Virtual MAC Address Assignment

The AVG assigns the virtual MAC addresses to each member of the group. The group members request a virtual MAC address after they discover the AVG through hello messages. The AVG assigns the next MAC address based on the load-balancing algorithm selected (see the “GLBP Load Balancing and Tracking” section). A gateway that is assigned with a virtual MAC address by the AVG is the primary virtual forwarder. The other members of the GLBP group that learn the virtual MAC addresses from hello messages are secondary virtual forwarders.

GLBP Virtual Gateway Redundancy

GLBP provides virtual gateway redundancy. A member in a group can be in the active, standby, or listen state. GLBP uses a priority algorithm to elect one gateway as the AVG and elect another gateway as the standby virtual gateway. The remaining gateways go into the listen state. You can configure the GLBP priority on each gateway. If the GLBP priority is identical on multiple gateways, GLBP uses the gateway with the highest IP address as the AVG.

If an AVG fails, the standby virtual gateway assumes responsibility for the virtual IP address. GLBP elects a new standby virtual gateway from the gateways in the listen state.

GLBP Virtual Forwarder Redundancy

GLBP provides virtual forwarder redundancy. Virtual forwarder redundancy is similar to virtual gateway redundancy with an active virtual forwarder (AVF). If the AVF fails, a secondary virtual forwarder in the listen state assumes responsibility for the virtual MAC address. This secondary virtual forwarder is also a primary virtual forwarder for a different virtual MAC address. GLBP migrates hosts away from the old virtual MAC address of the failed AVF, using the following two timers:

- Redirect timer—Specifies the interval during which the AVG continues to redirect hosts to the old virtual MAC address. When the redirect time expires, the AVG stops using the old virtual MAC address in ARP replies, although the secondary virtual forwarder continues to forward packets that were sent to the old virtual MAC address.

- Secondary hold timer—Specifies the interval during which the virtual MAC address is valid. When the secondary hold time expires, GLBP removes the virtual MAC address from all gateways in the GLBP group and load balances the traffic over the remaining AVFs. The expired virtual MAC address becomes eligible for reassignment by the AVG.

GLBP uses hello messages to communicate the current state of the timers.

In Figure 4-1, router A is the AVG for a GLBP group and is responsible for the virtual IP address 192.0.2.1. Router A is also an AVF for the virtual MAC address 0007.b400.0101. Router B is a member of the same GLBP group and is designated as the AVF for the virtual MAC address 0007.b400.0102. Client 1 has a default gateway IP address of 192.0.2.1, the virtual IP address, and a gateway MAC address of 0007.b400.0101 that points to router A. Client 2 shares the same default gateway IP address but receives the gateway MAC address 0007.b400.0102 because router B is sharing the traffic load with router A.

Figure 4-1 GLBP Topology

If router A becomes unavailable, client 1 does not lose access to the WAN because router B assumes responsibility for forwarding packets sent to the virtual MAC address of router A and for responding to packets sent to its own virtual MAC address. Router B also assumes the role of the AVG for the entire GLBP group. Communication for the GLBP members continues despite the failure of a router in the GLBP group.

GLBP Authentication

GLBP has three authentication types:

- MD5 authentication

- Plain text authentication

- No authentication

MD5 authentication provides greater security than plain text authentication. MD5 authentication allows each GLBP group member to use a secret key to generate a keyed MD5 hash that is part of the outgoing packet. At the receiving end, a keyed hash of an incoming packet is generated. If the hash within the incoming packet does not match the generated hash, the packet is ignored. The key for the MD5 hash can either be given directly in the configuration using a key string or supplied indirectly through a key chain.

You can also choose to use a simple password in plain text to authenticate GLBP packets or choose no authentication for GLBP.

GLBP rejects packets in any of the following cases:

- The authentication schemes differ on the router and in the incoming packet.

- MD5 digests differ on the router and in the incoming packet.

- Text authentication strings differ on the router and in the incoming packet.

GLBP Load Balancing and Tracking

You can configure the following load-balancing methods for GLBP:

- Round-robin—GLBP cycles through the virtual MAC addresses sent in ARP replies, load balancing the traffic across all the AVFs.

- Weighted—AVG uses the advertised weight for an AVF to decide the load directed to the AVF. A higher weight means that the AVG directs more traffic to the AVF.

- Host dependent—GLBP uses the MAC address of the host to determine which virtual MAC address to direct the host to use. This algorithm guarantees that a host gets the same virtual MAC address if the number of virtual forwarders does not change.

The default for IPv4 networks is round-robin. You can disable all load balancing for GLBP on an interface. If you do not configure load balancing, the AVG handles all traffic for the hosts while the other GLBP group members are in standby or listen mode.

You can configure GLBP to track an interface or routes and enable the secondary virtual forwarder to take over if a tracked link goes down. GLBP tracking uses weighted load-balancing to determine whether a GLBP group member acts as an AVF. You must configure the initial weighting values and optional thresholds to enable or disable this group member as an AVF. You can also configure the interface to track and the value that will reduce the interface’s weighting if the interface goes down. When the GLBP group weighting drops below the lower threshold, the member is no longer an AVF and a secondary virtual forwarder takes over. When the weighting rises above the upper threshold, the member can resume its role as an AVF.

Figure 4-2 shows an example of GLBP tracking and weighting.

Figure 4-2 GLBP Object Tracking and Weighting

In Figure 4-2, the Ethernet 1/2 interface on router 1 is the gateway for host 1 (the AVF for virtual MAC address, vMAC1), while Ethernet 2/2 on router 2 acts as a secondary virtual forwarder for Host 1. Ethernet 1/2 tracks Ethernet 3/1, which is the network connection for router 1. If Ethernet 3/1 goes down, the weighting for Ethernet 1/2 drops to 90. Ethernet 2/2 on router 2 preempts Ethernet 1/2 and takes over as AVF because it has the default weighting of 100 and is configured to preempt the AVF.

See the “Configuring GLBP Weighting and Tracking” section for details about configuring weighting and tracking.

High Availability and Extended Non-Stop Forwarding

GLBP supports stateful restarts and stateful switchover. A stateful restart occurs when the GLBP process fails and is restarted. A stateful switchover occurs when the active supervisor switches to the standby supervisor. Cisco NX-OS applies the run-time configuration after the switchover.

If GLBP hold timers are configured for short time periods, these timers may expire during a controlled switchover or in-service software upgrade (ISSU). GLBP supports extended non-stop forwarding (NSF) to temporarily extend these GLBP hold timers during a controlled switchover or in-service software upgrade (ISSU).

With extended NSF configured, GLBP sends hello messages with the extended timers. GLBP peers update their hold timers with these new values. The extended timers prevent unnecessary GLBP state changes during the switchover or ISSU. After the switchover or ISSU event, GLBP restores the hold timers to their original configured values. If the switchover fails, GLBP restores the hold timers after the extended hold timer values expire.

See the “Configuring Extended Hold Timers for GLBP” section for more information.

Virtualization Support

GLBP supports Virtual Routing and Forwarding instances (VRFs). VRFs exist within virtual device contexts (VDCs). By default, Cisco NX-OS places you in the default VDC and default VRF unless you specifically configure another VDC and VRF.

If you change the VRF membership of an interface, Cisco NX-OS removes all Layer 3 configuration, including GLBP.

Licensing Requirements for GLBP

The following table shows the licensing requirements for this feature:

Product

License Requirement

Cisco DCNM

GLBP requires a LAN Enterprise license. For a complete explanation of the Cisco DCNM licensing scheme and how to obtain and apply licenses, see the Cisco DCNM Installation and Licensing Guide, Release 5.x.

Cisco NX-OS

GLBP requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. For an explanation of the Cisco NX-OS licensing scheme for your platform, see the licensing guide for your platformFor a complete explanation of the Cisco NX-OS licensing scheme, see the Cisco NX-OS Licensing Guide .

Prerequisites for GLBP

The following prerequisites are required for using this feature on Cisco DCNM. For a full list of feature-specific prerequisites, see the platform-specific documentation.

GLBP has the following prerequisites:

- Globally enable the GLBP feature (see the “Enabling the GLBP Feature” section).

- System-message logging levels for the GLBP feature must meet or exceed Cisco DCNM requirements. During device discovery, Cisco DCNM detects inadequate logging levels and raises them to the minimum requirements. Cisco Nexus 7000 Series switches that run Cisco NX-OS Release 4.0 are an exception. For Cisco NX-OS Release 4.0, prior to device discovery, use the command-line interface to configure logging levels to meet or exceed Cisco DCNM requirements. For more information, see the Fundamentals Configuration Guide, Cisco DCNM for LAN, Release 5.x .

- You can only configure GLBP on Layer 3 interfaces (see the Cisco Nexus 7000 Series NX-OS Interfaces Configuration Guide, Release 5.x, and the Interfaces Configuration Guide, Cisco DCNM for LAN, Release 6.x ).

- If you configure VDCs, install the Advanced Services license and enter the desired VDC (see the Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide, Release 5.x).

Guidelines and Limitations

GLBP has the following configuration guidelines and limitations:

- You should configure all customization options for GLBP on all GLBP member gateways before enabling a GLBP group by configuring a virtual IP address.

- You must configure an IP address for the interface that you configure GLBP on and enable that interface before GLBP becomes active.

- The GLBP virtual IP address must be in the same subnet as the interface IP address.

- We recommend that you do not configure more than one first-hop redundancy protocol on the same interface.

- Cisco NX-OS removes all layer 3 configuration on an interface when you change the VDC, interface VRF membership, port channel membership, or when you change the port mode to layer 2.

- Cisco NX-OS does not support GLBP group configuration on interface secondary subnets.

Default Settings

Table 4-1 lists the default settings for GLBP parameters.

Table 4-1 Default GLBP Parameters

Parameters

Default

Authentication

No authentication

Forwarder preemption delay

30 seconds

Forwarder timeout

14400 seconds

Hello timer

3 seconds

Hold timer

10 seconds

GLBP feature

Disabled

Load balancing

Round robin

Preemption

Disabled

Priority

100

Redirect timer

600 seconds

Weighting

100

Platform Support

The following platform supports this feature. For platform-specific information, including guidelines and limitations, system defaults, and configuration limits, see the corresponding documentation.

Platform

Documentation

Cisco Nexus 7000 Series switches

Cisco Nexus 7000 Series Switches Documentation

Configuring GLBP

You can access GLBP from the Routing feature selection.

For more information about the Data Center Network Manager features, see the Fundamentals Configuration Guide, Cisco DCNM for LAN, Release 5.x .

This section includes the following topics:

- Enabling the GLBP Feature

- Creating a GLBP Group

- Configuring GLBP Authentication

- Configuring GLBP Load Balancing

- Configuring GLBP Weighting and Tracking

- Configuring Extended Hold Timers for GLBP

- Configuring Gateway Preemption

- Customizing GLBP

- Enabling a GLBP Group

Note If you are familiar with the Cisco IOS CLI, be aware that the Cisco NX-OS commands for this feature might differ from the Cisco IOS commands that you would use.

Enabling the GLBP Feature

You must enable the GLBP feature before you can configure and enable any GLBP groups.

BEFORE YOU BEGIN

System-message logging levels for the GLBP feature must meet or exceed Cisco DCNM requirements. During device discovery, Cisco DCNM detects inadequate logging levels and raises them to the minimum requirements. Cisco Nexus 7000 Series switches that run Cisco NX-OS Release 4.0 are an exception. For Cisco NX-OS Release 4.0, prior to device discovery, use the command-line interface to configure logging levels to meet or exceed Cisco DCNM requirements. For more information, see the Fundamentals Configuration Guide, Cisco DCNM for LAN, Release 5.x .

Ensure that you are in the correct VDC (or use the switchto vdc command).

DETAILED STEPS

To enable the GLBP feature, use the following command in global configuration mode:

Command

Purpose

feature glbp

Example :

switch(config)# feature glbp

Enables GLBP.

To disable the GLBP feature in a VDC and remove all associated configuration, use the following command in global configuration mode:

Command

Purpose

no feature glbp

Example :

switch(config)# no feature glbp

Disables the GLBP feature in a VDC.

Creating a GLBP Group

You can create a GLBP group on an interface.

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > GLBP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure GLBP on.

Step 3 From the menu bar, choose Actions > New GroupSetting .

The system highlights the new GLBP row in the Summary pane, and tabs update in the Details pane.

Step 4 From the highlighted Interface field, select the interface that you want to configure a GLBP group on from the drop-down list.

Step 5 From the Group ID field, enter the group number for this group.

The range is from 0 to 1023.

The system creates the new group on the device and highlights the new GLBP group in the Summary pane, and tabs update in the Details pane.

Step 6 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 7 From the Group Details tab, expand the Group Details section.

The basic group information appears in the Details pane.

Step 8 (Optional) From the Priority field, enter the priority for this GLBP group member.

Step 9 (Optional) From the Group Name field, enter a name for this GLBP group member.

Step 10 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Enabling a GLBP Group

Configuring GLBP Authentication

You can configure GLBP to authenticate the protocol using cleartext or an MD5 digest. MD5 authentication uses a key chain (see the Cisco Nexus 7000 Series NX-OS Security Configuration Guide, Release 5.x Security Configuration Guide, Cisco DCNM for LAN, Release 6.x ).

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

Enable the GLBP feature (see the “Enabling the GLBP Feature” section).

Note You must configure the same authentication and keys on all members of the GLBP group.

SUMMARY STEPS

1. config t

2. interface interface- type slot/port

3. ip ip-address/length

4. glbp group- number

5. authentication text string

or

authentication md5 { key-chain key-chain | key-string { text | encrypted text }

6. ip [ ip-address [ secondary ]]

7. show glbp [ group group-number ]

8. copy running-config startup-config

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > GLBP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure GLBP on.

Step 3 Click the group that you want to configure authentication on.

Step 4 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 5 From the Group Details tab, expand the Authentication, Gateway Preemption section.

The authentication information appears in the Details pane.

Step 6 From the Authentication area, from the Method drop-down list, choose the authentication method.

Step 7 (Optional) For text authentication, in the password field, enter the password string.

Step 8 (Optional) For MD5 authentication, check either Key or Key Chain .

Step 9 (Optional) For the Key option, in the key field, enter the key string and check encrypted for an encrypted key string.

Step 10 (Optional) For the Key Chain option, from the key chain drop-down list, choose the key chain that you want to use.

Step 11 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Creating a GLBP Group

- Enabling a GLBP Group

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

interface interface-type slot/port

Example:

switch(config)# interface ethernet 1/2

switch(config-if)#

Enters interface configuration mode.

Step 3

ip ip-address /length

Example :

switch(config-if)# ip 192.0.2.1/8

Configures the IPv4 address for the interface.

Step 4

glbp group-number

Example :

switch(config-if)# glbp 1

switch(config-if-glbp)#

Creates a GLBP group and enters GLBP configuration mode. The range is from 0 to 1024.

Step 5

authentication text string

Example :

switch(config-if-glbp)# authentication text mypassword

Configures cleartext authentication for GLBP on this interface.

authentication md5 { key-chain key-chain | key-string { text | encrypted text }

Example :

switch(config-if-glbp)# authentication md5 key-chain glbp-keys

Configures MD5 authentication for GLBP on this interface.

Step 6

ip [ ip-address [ secondary ]]

Example :

switch(config-if-glbp)# ip 192.0.2.10

Enables GLBP on an interface and identifies the primary IP address of the virtual gateway.

After you identify a primary IP address, you can use the glbp group ip command again with the secondary keyword to indicate additional IP addresses supported by this group. If you only use the ip keyword, GLBP learns the virtual IP address from the neighbors.

Step 7

show glbp [ group group-number ]

Example :

switch(config-if-glbp)# show glbp 1

(Optional) Displays GLBP information.

Step 8

copy running-config startup-config

Example:

switch(config-if-glbp)# copy running-config startup-config

(Optional) Saves this configuration change.

The following example shows how to configure MD5 authentication for GLBP on Ethernet 1/2 after creating the key chain:

switch# config t

switch(config)# key chain glbp-keys

switch(config-keychain)# key 0

switch(config-keychain-key)# key-string 7 zqdest

switch(config-keychain-key) accept-lifetime 00:00:00 Jun 01 2008 23:59:59 Sep 12 2008

switch(config-keychain-key) send-lifetime 00:00:00 Jun 01 2008 23:59:59 Aug 12 2008

switch(config-keychain-key) key 1

switch(config-keychain-key) key-string 7 uaeqdyito

switch(config-keychain-key) accept-lifetime 00:00:00 Aug 12 2008 23:59:59 Dec 12 2008

switch(config-keychain-key) send-lifetime 00:00:00 Sep 12 2008 23:59:59 Nov 12 2008

switch(config)# interface ethernet 1/2

switch(config-if)# glbp 1

switch(config-if-glbp)# authenticate md5 key-chain glbp-keys

switch(config-if-glbp)# copy running-config startup-config

Configuring GLBP Load Balancing

You can configure GLBP to use load balancing based on round-robin, weighted, or host-dependent methods (see the “GLBP Load Balancing and Tracking” section).

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > GLBP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure GLBP on.

Step 3 Click the group that you want to configure load balancing on.

Step 4 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 5 From the Group Details tab, expand the Group Details section.

The basic group information appears in the Details pane.

Step 6 From the Method drop-down list, choose the load-balancing method.

Step 7 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Creating a GLBP Group

- Enabling a GLBP Group

To configure GLBP load balancing, use the following command in GLBP configuration mode:

Command

Purpose

load-balancing [host-dependent | round-robin | weighted ]

Example :

switch(config-if-glbp)# load-balancing weighted

Sets the GLBP load-balancing method. The default is round-robin.

Configuring GLBP Weighting and Tracking

You can configure GLBP weighting values and object tracking to work with the GLBP weighted load-balancing method.

You can optionally configure the interface to preempt an active virtual forwarder (AVF) if the interface was originally assigned with the virtual MAC address or if this interface has a higher weight than the AVF.

BEFORE YOU BEGIN

Ensure that you have configured the object tracking entry that you want to use to modify GLBP weighting (see the “Configuring Object Tracking” section).

Ensure that you are in the correct VDC (or use the switchto vdc command).

Enable the GLBP feature (see the “Enabling the GLBP Feature” section).

SUMMARY STEPS

1. config t

2. track object- id interface interface-type number { ip routing | line-protocol }

3. track object- id ip route ip-prefix/length reachability

4. interface interface- type slot/port

5. ip ip-address/length

6. glbp group-number

7. weighting maximum [ lower lower ] [ upper upper ]

8. weighting track object-number [ decrement value ]

9. forwarder preempt [ delay minimum seconds ]

10. ip [ ip-address [ secondary ]]

11. show glbp interface-type number

12. copy running-config startup-config

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > GLBP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure GLBP on.

Step 3 Click the group that you want to configure weighting and tracking on.

Step 4 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 5 From the Group Details tab, expand the Weighting and Object Tracking section.

The weighting and object tracking information appears in the Details pane.

Step 6 From the Weight area, enter the maximum, lower threshold, and upper threshold weighting values.

Step 7 From the GLBP Tracking area, right-click and choose Add TrackObject from the pop-up menu.

Step 8 From the object ID drop-down list, choose the object ID that you want to use to modify the GLBP weighting value with.

Step 9 In the Weight Decrement field, enter the value that you want to decrement the GLBP weighting with if the tracked object state goes down.

Step 10 (Optional) From the Group Details tab, expand the Virtual Forwarder Setting section.

The virtual forwarders information appears in the Details pane.

Step 11 (Optional) Check Virtual Forwarder Preemption .

Step 12 (Optional) In the Preemption Delay field, enter the delay value in seconds.

Step 13 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Creating a GLBP Group

- Configuring Gateway Preemption

- Enabling a GLBP Group

Command or Action

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

track object-id interface interface-type number { ip routing | line-protocol }

Example:

switch(config)# track 1 interface ethernet 2/2 line-protocol

switch(config-track#

Configures the interface that this GLBP interface tracks. Changes in the state of the interface affect the priority of this GLBP interface as follows:

- You configure the interface and corresponding object number that you use with the track command in GLBP configuration mode.

- The line-protocol keyword tracks whether the interface is up. The ip keyword also checks that IP routing is enabled on the interface and an IP address is configured.

track object-id ip route ip-prefix/length reachability

Example:

switch(config)# track 2 ip route 192.0.2.0/8 reachability

switch(config-track#

Creates a tracked object for a route nd enters tracking configuration mode. The object-id range is from 1 to 500.

Step 3

interface interface-type slot/port

Example:

switch(config)# interface ethernet 1/2

switch(config-if)#

Enters interface configuration mode.

Step 4

ip ip-address /length

Example :

switch(config-if)# ip 192.0.2.1/8

Configures the IPv4 address for the interface.

Step 5

glbp group-number

Example :

switch(config-if)# glbp 1

switch(config-if-glbp)#

Creates a GLBP group and enters GLBP configuration mode.

Step 6

weighting maximum [ lower lower ] [ upper upper ]

Example:

switch(config-if-glbp)# weighting 110 lower 95 upper 105

Specifies the initial weighting value and the upper and lower thresholds for a GLBP gateway. The maximum range is from 1 to 254. The default weighting value is 100. The lower range is from 1 to 253. The upper range is from 1 to 254.

Step 7

weighting track object-number [ decrement value ]

Example:

switch(config-if-glbp)# weighting track 2 decrement 20

Specifies an object to be tracked that affects the weighting of a GLBP gateway. The value argument specifies a reduction in the weighting of a GLBP gateway when a tracked object fails. The range is from 1 to 255.

Step 8

forwarder preempt [ delay minimum seconds ]

Example:

switch(config-if-glbp)# forwarder preempt delay minimum 60

(Optional) Configures the router to take over as AVF for a GLBP group if the current AVF for a GLBP group falls below its low weighting threshold. The range is from 0 to 3600 seconds.

This command is enabled by default with a delay of 30 seconds.

Step 9

ip [ ip-address [ secondary ]]

Example :

switch(config-if-glbp)# ip 192.0.2.10

Enables GLBP on an interface and identifies the primary IP address of the virtual gateway.

After you identify a primary IP address, you can use the glbp group ip command again with the secondary keyword to indicate additional IP addresses supported by this group. If you only use the ip keyword, GLBP learns the virtual IP address from the neighbors.

Step 10

show glbp interface-type number

Example:

switch(config-if-glbp)# show glbp ethernet 1/2

(Optional) Displays GLBP information for an interface.

Step 11

copy running-config startup-config

Example:

switch(config-if-glbp)# copy running-config startup-config

(Optional) Saves this configuration change.

The following example shows how to configure GLBP weighting and tracking on Ethernet 1/2:

switch# config t

switch(config)# track 2 interface ethernet 2/2 ip routing

switch(config)# interface ethernet 1/2

switch(config-if)# glbp 1

switch(config-if-glbp)# weighting 110 lower 95 upper 105

switch(config-if-glbp)# weighting track 2 decrement 20

switch(config-if-glbp)# copy running-config startup-config

Configuring Gateway Preemption

You can configure gateway preemption.

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > GLBP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure GLBP on.

Step 3 Click the group that you want to configure authentication on.

Step 4 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 5 From the Group Details tab, expand the Authentication, Gateway Preemption section.

The preemption information appears in the Details pane.

Step 6 From the Authentication, Gateway Preemption section, check Gateway Preemption .

Step 7 From the Minimum Delay field, enter the minimum delay to wait before preemption occurs.

The default is 3600 seconds.

Step 8 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Creating a GLBP Group

- Configuring GLBP Weighting and Tracking

- Enabling a GLBP Group

Customizing GLBP

Customizing the behavior of GLBP is optional. Be aware that as soon as you enable a GLBP group by configuring a virtual IP address, that group is operational. If you enable a GLBP group before you customize GLBP, the router could take over control of the group and become the AVG before you finish customizing the feature. If you plan to customize GLBP, you should do so before enabling GLBP.

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > GLBP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure GLBP on.

Step 3 Click the group that you want to configure timers on.

Step 4 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 5 From the Group Details tab, expand the Timers section.

The timers information appears in the Details pane.

Step 6 From the Configured Timers area, in the Hello Time (msec) field, enter the hello time.

Step 7 From the Configured Timers area, in the Hold Time (msec) field, enter the hold time.

Step 8 From the Configured Timers area, in the Redirect Time (sec) field, enter the redirect time.

Step 9 From the Configured Timers area, in the Forwarder Time-out (sec) field, enter the hold time.

Step 10 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Creating a GLBP Group

- Enabling a GLBP Group

To customize GLBP, use the following commands in GLBP configuration mode:

Command or Action

Purpose

timers [ msec ] hellotime [ msec ] holdtime

Example:

switch(config-if-glbp)# timers 5 18

Configures the following hello and hold times for this GLBP member:

- hellotime —The interval between successive hello packets sent by the AVG in a GLBP group. The range is from 1 to 60 seconds or from 250 to 60000 milliseconds. The default value is 3 seconds.

- holdtime —The interval before the virtual gateway and virtual forwarder information in the hello packet is considered invalid. The range is from 2 to 180 seconds or from 1020 to 180000 milliseconds. The default is 10 seconds.

The optional msec keyword specifies that the argument is expressed in milliseconds, instead of the default seconds.

timers redirect redirect timeout

Example:

switch(config-if-glbp)# timers redirect 600 7200

Configures the following timers:

- redirect —The time interval in seconds during which the AVG continues to redirect clients to an AVF. The range is from 0 to 3600 seconds. The default is 600 seconds.

- timeout— The interval in seconds before a secondary virtual forwarder becomes invalid. The range is from 610 to 64800 seconds. The default is 14,440 seconds.

priority level

Example:

switch(config-if-glbp)# priority 254

Sets the priority level used to select the AVG in a GLBP group. The range is from 1 to 255. The default is 100.

preempt [ delay minimum seconds ]

Example:

switch(config-if-glbp)# preempt delay minimum 60

Configures the router to take over as AVG for a GLBP group if it has a higher priority than the current AVG. This command is disabled by default.

Use the optional delay minimum keywords and the seconds argument to specify a minimum delay interval in seconds before preemption of the AVG takes place.

The seconds range is from 0 to 3600 seconds. The minimum delay default is 3600 seconds.

Configuring Extended Hold Timers for GLBP

You can configure GLBP to use extended hold timers to support extended NSF during a controlled switchover or ISSU. You should configure extended hold timers on all GLBP gateways. (see the “High Availability and Extended Non-Stop Forwarding” section).

Note You must configure extended hold timers on all GLBP gateways if you configure extended hold timers. You can configure different extended holdtimer values on each GLBP gateway, based on the expected system switchover delays.

Note If you configure a non-default hold timer, you should configure the same value on all GLBP gateways when you configure GLBP extended hold timers.

To configure GLBP extended hold timers , use the following command in global configuration mode:

Command

Purpose

glbp timers extended-hold [ timer ]

Example :

switch(config)# glbp timers extended-hold

Sets the GLBP extended hold timer, in seconds. The timer range is from 10 to 255. The default is 10.

Use the show glbp command or the show running-config glbp command to display the extended hold time.

Enabling a GLBP Group

You can configure the virtual IP address on an interface to enable the GLBP group. You must configure each gateway in the GLBP group with the same group number. The GLBP member can learn all other required parameters from another GLBP member.

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > GLBP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure GLBP on.

Step 3 Click the group that you want to configure timers on.

Step 4 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 5 From the Group Details tab, expand the Group Details section.

The general information appears in the Details pane.

Step 6 (Optional) To manually set the virtual IP address, enter an IP address in the Virtual IP address field.

Step 7 (Optional) To learn the virtual IP address, check Learn Virtual IP from Members Of Group .

Step 8 (Optional) From the Virtual Secondary IP Address field, enter a secondary IP address.

Step 9 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Creating a GLBP Group

Command or Action

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

interface interface-type slot/port

Example:

switch(config)# interface ethernet 1/2

switch(config-if)#

Enters interface configuration mode.

Step 3

ip ip-address /length

Example :

switch(config-if)# ip 192.0.2.1/8

Configures the IPv4 address for the interface.

Step 4

glbp group-number

Example :

switch(config-if)# glbp 1

switch(config-if-glbp)#

Creates a GLBP group and enters GLBP configuration mode.

Step 5

ip [ ip-address [ secondary ]]

Example :

switch(config-if-glbp)# ip 192.0.2.10

Enables GLBP on an interface and identifies the virtual IP address. The virtual IP should be in the same subnet as the interface IP address.

After you identify a virtual IP address, you can use the glbp group ip command again with the secondary keyword to indicate additional IP addresses supported by this group. If you only use the ip keyword, GLBP learns the virtual IP address from the neighbors.

Step 6

show glbp [group group-number ] [ brief ]

Example:

switch(config-if-glbp)# show glbp brief

(Optional) Displays a brief summary of GLBP information.

Step 7

copy running-config startup-config

Example:

switch(config-if-glbp)# copy running-config startup-config

(Optional) Saves this configuration change.

The following example shows how to enable GLBP on Ethernet 1/2:

switch# config t

switch(config)# interface ethernet 1/2

switch(config-if)# glbp 1

switch(config-if-glbp)# ip 192.0.2.10

Verifying the GLBP Configuration

To display GLBP configuration information, perform one of the following tasks:

Command

Purpose

show glbp [group group-number]

Displays the GLBP status for all or one group.

show glbp [group group-number] capability

Displays the GLBP capability for all or one group.

show glbp [interface interface-type slot/port]

Displays the GLBP status for an interface.

show glbp [group group-number] [interface interface-type slot/port] [active] [disabled] [init] [listen] [standby]

Displays the GLBP status for a group or interface for virtual forwarders in the selected state.

show glbp [group group-number] [interface interface-type slot/port] [active] [disabled] [init] [listen] [standby] brief

Displays a brief summary of the GLBP status for a group or interface for virtual forwarders in the selected state.

Configuration Examples for GLBP

The following example enables GLBP on an interface, with MD5 authentication, interface tracking, and weighted load balancing:

key chain glbp-keys

key 0

key-string 7 zqdest

accept-lifetime 00:00:00 Jun 01 2008 23:59:59 Sep 12 2008

send-lifetime 00:00:00 Jun 01 2008 23:59:59 Aug 12 2008

key 1

key-string 7 uaeqdyito

accept-lifetime 00:00:00 Aug 12 2008 23:59:59 Dec 12 2008

send-lifetime 00:00:00 Sep 12 2008 23:59:59 Nov 12 2008

feature glbp

track 2 interface ethernet 2/2 ip

interface ethernet 1/2

ip address 192.0.2.2/8

glbp 1

authentication md5 key-chain glbp-keys

weighting 110 lower 95 upper 105

weighting track 2 decrement 20

ip 192.0.2.10

no shutdown

Field Descriptions for GLBP

This section includes the following field descriptions for GLBP:

- GLBP: Group Details Tab: Group Details Section

- GLBP: Group Details Tab: Authentication, Gateway Preemption Section

- GLBP: Group Details Tab: Weighting and Object Tracking Section

- GLBP: Group Details Tab: Virtual Forwarder Setting Section

- GLBP: Group Details Tab: Timers Section

- GLBP: Virtual Gateways and Forwarders Tab: Forwarder Details Section

- GLBP: Virtual Gateways and Forwarders Tab: GLBP Group Member Details Section

GLBP: Group Details Tab: Group Details Section

Table 4-2 GLBP: Group Details: Group Details

Field

Description

Gateway

Group ID

Display only. Group number for the GLBP group.

Priority

Priority for the group member, used for AVG selection.

Group Name

Name for the GLBP group.

Method

Load balancing method for this GLBP group.

Gateway State

Display only. Administrative state for the group member.

State Change Count

Display only. Number of times the GLBP gateway state changed.

Last State Change

Display only. Time of the last GLBP gateway state change.

Active Gateway

IP Address

Address of active gateway.

Priority

Priority of active gateway.

Standby Gateway

IP Address

Address of standby gateway.

Priority

Priority of standby gateway.

IP Address Settings

Learn Virtual IP from Members of Group

Learned IP address for the group.

Virtual IP Address

Virtual IP address for the group.

Secondary IP Address

Secondary IP address for the group.

GLBP: Group Details Tab: Authentication, Gateway Preemption Section

Table 4-3 GLBP: Group Details: Authentication, Gateway Preemption

Field

Description

Authentication

Method

Authentication method.

Password

Password for text authentication.

Key

Key string for MD5 authentication.

Encrypted

Key string is encrypted for MD5 authentication.

Key Chain

Key chain name for MD5 authentication.

Gateway Preemption

Gateway Preemption

Gateway preemption.

Minimum Delay

Minimum delay to wait before preemption occurs.

GLBP: Group Details Tab: Weighting and Object Tracking Section

Table 4-4 GLBP: Group Details: Weighting and Object Tracking

Field

Description

Weight

Maximum

Maximum weighted value.

Lower Threshold

Lower threshold of weighted value.

Upper Threshold

Upper threshold of weighted value.

GLBP Tracking

Object ID

ID of object to track.

Tracked Object

Detail of tracked object.

Weight Decrement

Value to decrement the GLBP weight if the tracked object goes down.

GLBP: Group Details Tab: Virtual Forwarder Setting Section

Table 4-5 GLBP: Group Details:Virtual Forwarder Setting

Field

Description

Forwarder ID

ID of virtual forwarder.

Virtual MAC Address

Virtual MAC address for the GLBP group.

Virtual Forwarder Preemption

Device that takes over as the AVF for a GLBP group if the current AVF for a GLBP group falls below its low weighting threshold.

Preemption Delay

Delay before virtual forwarder preemption occurs.

GLBP: Group Details Tab: Timers Section

Table 4-6 GLBP: Group Details:Timers

Field

Description

Active Timer Values

Hello Time

Display only. GLBP group hello time.

Hold Time

Display only. GLBP group hold time.

Virtual Forwarder Redirect Time

Display only. The time interval in seconds during which the active virtual gateway continues to redirect clients to an active virtual forwarder.

Secondary Forwarder Hold Time

Display only. The interval in seconds before a secondary virtual forwarder becomes invalid.

Configured Timers

Hello Time

GLBP group hello time.

Hold Time

GLBP group hold time.

Virtual Forwarder Redirect Time

Time interval in seconds during which the active virtual gateway continues to redirect clients to an active virtual forwarder.

Secondary Forwarder Hold Time

Interval in seconds before a secondary virtual forwarder becomes invalid.

GLBP: Virtual Gateways and Forwarders Tab: Forwarder Details Section

Table 4-7 GLBP:Virtual Gateways and Forwarders:Forwarder Details

Field

Description

Forwarder ID

Display only. ID of virtual forwarder.

MAC Address

Display only. MAC address for the GLBP group.

Virtual MAC Address

Display only. Virtual MAC address for the GLBP group.

Redirection

Display only. Redirection state.

Weighting

Display only. Weighting value for this forwarder.

Gateway State

Display only. Administrative state for the group member.

State Change Count

Display only. Number of times the GLBP gateway state changed.

Last State Change

Display only. Time of the last GLBP gateway state change.

GLBP: Virtual Gateways and Forwarders Tab: GLBP Group Member Details Section

Table 4-8 GLBP:Virtual Gateways and Forwarders:GLBP Group Member Details

Field

Description

IP Address

IP address of the group member.

MAC Address

MAC address of the group member.

Additional References

For additional information related to implementing GLBP, see the following sections:

- Related Documents

- Standards

Related Documents

Related Topic

Document Title

Configuring the Hot Standby Redundancy protocol

Chapter 5, “Configuring HSRP”

GLBP CLI commands

Cisco Nexus 7000 Series NX-OS Unicast Routing Command Reference

Configuring high availability

Cisco Nexus 7000 Series NX-OS High Availability and Redundancy Guide, Release 5.x

Standards

Standards

Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.

—

Feature History for GLBP

Table 4-9 lists the release history for this feature.

Table 4-9 Feature History for GLBP

Feature Name

Releases

Feature Information

Extended hold timers

4.2(1)

Added support for extended hold timers for extended NSF support.

GLBP

4.0(1)

This feature was introduced.

Configuring HSRP

This chapter describes how to configure the Hot Standby Router Protocol ( HSRP ) on the Cisco Data Center Network Manager (DCNM)NX-OS device.

This chapter includes the following sections:

- Information About HSRP

- Licensing Requirements for HSRP

- Prerequisites for HSRP

- Guidelines and Limitations

- Default Settings

- Platform Support

- Configuring HSRP

- Verifying the HSRP Configuration

- Configuration Examples for HSRP

- Field Descriptions for HSRP

- Additional References

- Feature History for HSRP

Information About HSRP

HSRP is a first-hop redundancy protocol ( FHRP ) that allows a transparent failover of the first-hop IP router. HSRP provides first-hop routing redundancy for IP hosts on Ethernet networks configured with a default router IP address. You use HSRP in a group of routers for selecting an active router and a standby router. In a group of routers, the active router is the router that routes packets; the standby router is the router that takes over when the active router fails or when preset conditions are met.

Many host implementations do not support any dynamic router discovery mechanisms but can be configured with a default router. Running a dynamic router discovery mechanism on every host is not feasible for a number of reasons, including administrative overhead, processing overhead, and security issues. HSRP provides failover services to these hosts.

This section includes the following topics:

- HSRP Overview

- HSRP for IPv4

- HSRP for IPv6

- HSRP Versions

- HSRP Authentication

- HSRP and Proxy Address Resolution Protocols

- HSRP Messages

- HSRP Load Sharing

- Object Tracking and HSRP

- vPC and HSRP

- BFD

- High Availability and Extended Nonstop Forwarding

- Virtualization Support

HSRP Overview

When you use HSRP, you configure the HSRP virtual IP address as the host’s default router (instead of the IP address of the actual router). The virtual IP address is an IPv4 or IPv6 address that is shared among a group of routers that run HSRP.

When you configure HSRP on a network segment, you provide a virtual MAC address and a virtual IP address for the HSRP group. You configure the same virtual address on each HSRP-enabled interface in the group. You also configure a unique IP address and MAC address on each interface that acts as the real address. HSRP selects one of these interfaces to be the active router . The active router receives and routes packets destined for the virtual MAC address of the group.

HSRP detects when the designated active router fails. At that point, a selected standby router assumes control of the virtual MAC and IP addresses of the HSRP group. HSRP also selects a new standby router at that time.

HSRP uses a priority mechanism to determine which HSRP-configured interface becomes the default active router. To configure an interface as the active router, you assign it with a priority that is higher than the priority of all the other HSRP-configured interfaces in the group. The default priority is 100, so if you configure just one interface with a higher priority, that interface becomes the default active router.

Interfaces that run HSRP send and receive multicast User Datagram Protocol (UDP)-based hello messages to detect a failure and to designate active and standby routers. When the active router fails to send a hello message within a configurable period of time, the standby router with the highest priority becomes the active router. The transition of packet forwarding functions between the active and standby router is completely transparent to all hosts on the network.

You can configure multiple HSRP groups on an interface.

Figure 5-1 shows a network configured for HSRP. By sharing a virtual MAC address and a virtual IP address, two or more interfaces can act as a single virtual router .

Figure 5-1 HSRP Topology With Two Enabled Routers

The virtual router does not physically exist but represents the common default router for interfaces that are configured to provide backup to each other. You do not need to configure the hosts on the LAN with the IP address of the active router. Instead, you configure them with the IP address (virtual IP address) of the virtual router as their default router. If the active router fails to send a hello message within the configurable period of time, the standby router takes over, responds to the virtual addresses, and becomes the active router, assuming the active router duties. From the host perspective, the virtual router remains the same.

Note Packets received on a routed port destined for the HSRP virtual IP address will terminate on the local router, regardless of whether that router is the active HSRP router or the standby HSRP router. This includes ping and Telnet traffic. Packets received on a Layer 2 (VLAN) interface destined for the HSRP virtual IP address will terminate on the active router.

HSRP for IPv4

HSRP routers communicate with each other by exchanging HSRP hello packets. These packets are sent to the destination IP multicast address 224.0.0.2 (reserved multicast address used to communicate to all routers) on UDP port 1985. The active router sources hello packets from its configured IP address and the HSRP virtual MAC address while the standby router sources hellos from its configured IP address and the interface MAC address, which may or may not be the burned-in address (BIA). The BIA is the last six bytes of the MAC address that is assigned by the manufacturer of the network interface card (NIC).

Because hosts are configured with their default router as the HSRP virtual IP address, hosts must communicate with the MAC address associated with the HSRP virtual IP address. This MAC address is a virtual MAC address, 0000.0C07.ACxy, where xy is the HSRP group number in hexadecimal based on the respective interface. For example, HSRP group 1 uses the HSRP virtual MAC address of 0000.0C07.AC01. Hosts on the adjoining LAN segment use the normal Address Resolution Protocol (ARP) process to resolve the associated MAC addresses.

HSRP version 2 uses the new IP multicast address 224.0.0.102 to send hello packets instead of the multicast address of 224.0.0.2, which is used by version 1. HSRP version 2 permits an expanded group number range of 0 to 4095 and uses a new MAC address range of 0000.0C9F.F000 to 0000.0C9F.FFFF.

HSRP for IPv6

IPv6 hosts learn of available IPv6 routers through IPv6 neighbor discovery (ND) router advertisement (RA) messages. These messages are multicast periodically, or may be solicited by hosts, but the time delay for detecting when a default route is down may be 30 seconds or more. HSRP for IPv6 provides a much faster switchover to an alternate default router than the IPv6 ND protocol provides, less than a second if the milliseconds timers are used. HSRP for IPv6 provides a virtual first hop for IPv6 hosts.

When you configure an IPv6 interface for HSRP, the periodic RAs for the interface link-local address stop after IPv6 ND sends a final RA with a router lifetime of zero. No restrictions occur for the interface IPv6 link-local address. Other protocols continue to receive and send packets to this address.

IPv6 ND sends periodic RAs for the HSRP virtual IPv6 link-local address when the HSRP group is active. These RAs stop after a final RA is sent with a router lifetime of 0 when the HSRP group leaves the active state. HSRP uses the virtual MAC address for active HSRP group messages only (hello, coup, and redesign).

HSRP for IPv6 uses the following parameters:

- HSRP version 2

- UDP port 2029

- Virtual MAC address range from 0005.73A0.0000 through 0005.73A0.0FFF

- Multicast link-local IP destination address of FF02::66

- Hop limit set to 255

HSRP IPv6 Addresses

An HSRP IPv6 group has a virtual MAC address that is derived from the HSRP group number and a virtual IPv6 link-local address that is derived, by default, from the HSRP virtual MAC address. The default virtual MAC address for an HSRP IPv6 group will always be used to form the virtual IPv6 link-local address, regardless of the actual virtual MAC address used by the group.

Table 5-1 shows the MAC and IP addresses used for IPv6 neighbor discovery packets and HSRP packets.

Table 5-1 HSRP and IPv6 ND Addresses

Packet

MAC Source Address

IPv6 Source Address

IPv6 Destination Address

Link-layer Address Option

Neighbor solicitation (NS)

Interface MAC address

Interface IPv6 address

—

Interface MAC address

Router solicitation (RS)

Interface MAC address

Interface IPv6 address

—

Interface MAC address

Neighbor advertisement (NA)

Interface MAC address

Interface IPv6 address

Virtual IPv6 address

HSRP virtual MAC address

Route advertisement (RA)

Interface MAC address

Virtual IPv6 address

—

HSRP virtual MAC address

HSRP (inactive)

Interface MAC address

Interface IPv6 address

—

—

HSRP (active)

Virtual MAC address

Interface IPv6 address

—

—

HSRP does not add IPv6 link-local addresses to the Unicast Routing Information Base (URIB). There are also no secondary virtual IP addresses for link-local addresses.

For global unicast addresses, HSRP will add the virtual IPv6 address to the URIB and IPv6 but will not register the virtual IPv6 addresses to ICMPv6. ICMPv6 redirects are not supported for HSRP IPv6 groups.

HSRP Versions

Cisco NX-OS supports HSRP version 1 by default. You can configure an interface to use HSRP version 2.

HSRP version 2 has the following enhancements to HSRP version 1:

- Expands the group number range. HSRP version 1 supports group numbers from 0 to 255. HSRP version 2 supports group numbers from 0 to 4095.

- For IPv4, uses the IPv4 multicast address 224.0.0.102 or the IPv6 multicast address FF02::66 to send hello packets instead of the multicast address of 224.0.0.2, which is used by HSRP version 1.

- Uses the MAC address range from 0000.0C9F.F000 to 0000.0C9F.FFFF for IPv4 and 0005.73A0.0000 through 0005.73A0.0FFF for IPv6 addresses. HSRP version 1 uses the MAC address range 0000.0C07.AC00 to 0000.0C07.ACFF.

- Adds support for MD5 authentication.

When you change the HSRP version, Cisco NX-OS reinitializes the group because it now has a new virtual MAC address.

HSRP version 2 has a different packet format than HSRP version 1. The packet format uses a type-length-value (TLV) format. HSRP version 2 packets received by an HSRP version 1 router are ignored.

HSRP Authentication

HSRP message digest 5 (MD5) algorithm authentication protects against HSRP-spoofing software and uses the industry-standard MD5 algorithm for improved reliability and security. HSRP includes the IPv4 or IPv6 address in the authentication TLVs.

HSRP and Proxy Address Resolution Protocols

You can use HSRP when the hosts are configured for proxy Address Resolution Protocol (ARP). When you enable HSRP on an interface on which an ARP request is received, the response includes the virtual MAC address. If the HSRP interface is not the active router, then it does not respond (because the active router responds). If you enable multiple HSRP groups on the interface, and the router acts as the active HSRP router for more than one group, then one of the HSRP group's MAC addresses provides the proxy ARP response.

HSRP Messages

Routers that are configured with HSRP exchange the following three types of multicast messages:

- Hello—The hello message conveys the HSRP priority and state information of the router to other HSRP routers.

- Coup—When a standby router wants to assume the function of the active router, it sends a coup message.

- Resign—A router that is the active router sends this message when it is about to shut down or when a router that has a higher priority sends a hello or coup message.

HSRP Load Sharing

HSRP allows you to configure multiple groups on an interface. You can configure two overlapping IPv4 HSRP groups to load share traffic from the connected hosts while providing the default router redundancy expected from HSRP. Figure 5-2 shows an example of a load-sharing HSRP IPv4 configuration.

Figure 5-2 HSRP Load Sharing

Figure 5-2 shows two routers A and B and two HSRP groups. Router A is the active router for group A but is the standby router for group B. Similarly, router B is the active router for group B and the standby router for group A. If both routers remain active, HSRP load balances the traffic from the hosts across both routers. If either router fails, the remaining router continues to process traffic for both hosts.

Note HSRP for IPv6 load balances by default. If there are two HSRP IPv6 groups on the subnet, then hosts will learn of both from their router advertisements and choose to use one so that the load is shared between the advertised routers.

Object Tracking and HSRP

You can use object tracking to modify the priority of an HSRP interface based on the operational state of another interface. Object tracking allows you to route to a standby router if the interface to the main network fails.

Two objects that you can track are the line protocol state of an interface or the reachability of an IP route. If the specified object goes down, Cisco DC-OS reduces the HSRP priority by the configured amount. For more information, see the “Configuring HSRP Object Tracking” section.

vPC and HSRP

HSRP interoperates with virtual port channels (vPCs). vPCs allow links that are physically connected to two different Cisco Nexus 7000 Series devices to appear as a single port channel by a third device. See the Cisco Nexus 7000 Series NX-OS Layer 2 Switching Configuration Guide, Release 5.x , for more information on vPCs.

vPC forwards traffic through both the active HSRP router and the standby HSRP router. You can configure a threshold on the priority of the standby HSRP router to determine when traffic should fail over to the vPC trunk. See the “Configuring the HSRP Priority” section.

Note You should configure HSRP on the primary vPC peer device as active and HSRP on the vPC secondary device as standby.

BFD

This feature supports bidirectional forwarding detection (BFD). BFD is a detection protocol designed to provide fast forwarding-path failure detection times. BFD provides subsecond failure detection between two adjacent devices and can be less CPU-intensive than protocol hello messages because some of the BFD load can be distributed onto the data plane on supported modules. See the Cisco Nexus 7000 Series NX-OS Interfaces Configuration Guide, Release 5.x , for more information.

High Availability and Extended Nonstop Forwarding

HSRP supports stateful restarts and stateful switchovers. A stateful restart occurs when the HSRP process fails and is restarted. A stateful switchover occurs when the active supervisor switches to the standby supervisor. Cisco NX-OS applies the run-time configuration after the switchover.

If HSRP hold timers are configured for short time periods, these timers may expire during a controlled switchover or in-service software upgrade (ISSU). HSRP supports extended non-stop forwarding (NSF) to temporarily extend these HSRP hold timers during a controlled switchover or in-service software upgrade (ISSU).

With extended NSF configured, HSRP sends hello messages with the extended timers. HSRP peers update their hold timers with these new values. The extended timers prevent unnecessary HSRP state changes during the switchover or ISSU. After the switchover or ISSU event, HSRP restores the hold timers to their original configured values. If the switchover fails, HSRP restores the hold timers after the extended hold timer values expire.

See the “Configuring Extended Hold Timers for HSRP” section for more information.

Virtualization Support

HSRP supports Virtual Routing and Forwarding instances (VRFs). VRFs exist within virtual device contexts (VDCs). By default, Cisco NX-OS places you in the default VDC and default VRF unless you specifically configure another VDC and VRF.

If you change the VRF membership of an interface, Cisco NX-OS removes all Layer 3 configuration, including HSRP.

Licensing Requirements for HSRP

The following table shows the licensing requirements for this feature:

Product

License Requirement

Cisco DCNM

HSRP requires the Enterprise LAN license. Any feature not included in a license package is bundled with the Cisco DCNM and is provided at no charge to you. For a complete explanation of the Cisco DCNM licensing scheme, see the Cisco DCNM Installation and Licensing Guide, Release 5.x .

Cisco NX-OS

HSRP requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. For an explanation of the Cisco NX-OS licensing scheme for your platform, see the licensing guide for your platformFor a complete explanation of the Cisco NX-OS licensing scheme, see the Cisco NX-OS Licensing Guide .

Prerequisites for HSRP

The following prerequisites are required for using this feature on Cisco DCNM. For a full list of feature-specific prerequisites, see the platform-specific documentation.

HSRP has the following prerequisites:

- You must enable the HSRP feature in a device before you can configure and enable any HSRP groups.

- System-message logging levels for the HSRP feature must meet or exceed Cisco DCNM requirements. During device discovery, Cisco DCNM detects inadequate logging levels and raises them to the minimum requirements. Cisco Nexus 7000 Series switches that run Cisco NX-OS Release 4.0 are an exception. For Cisco NX-OS Release 4.0, prior to device discovery, use the command-line interface to configure logging levels to meet or exceed Cisco DCNM requirements. For more information, see the Fundamentals Configuration Guide, Cisco DCNM for LAN, Release 5.x .

- If you configure VDCs, install the Advanced Services license and enter the desired VDC (see the Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide, Release 5.x).

Guidelines and Limitations

HSRP has the following configuration guidelines and limitations:

- You must configure an IP address for the interface that you configure HSRP on and enable that interface before HSRP becomes active.

- You must configure HSRP version 2 when you configure an IPv6 interface for HSRP.

- For IPv4, the virtual IP address must be in the same subnet as the interface IP address.

- We recommend that you do not configure more than one first-hop redundancy protocol on the same interface.

- Proxy ARP must be disabled when you configure HSRP on same interface.

- HSRP version 2 does not interoperate with HSRP version 1. An interface cannot operate both version 1 and version 2 because both versions are mutually exclusive. However, the different versions can be run on different physical interfaces of the same router.

- You cannot change from version 2 to version 1 if you have configured groups above the group number range allowed for version 1 (0 to 255).

- Cisco NX-OS removes all Layer 3 configuration on an interface when you change the interface VRF membership, port channel membership, or when you change the port mode to Layer 2.

- If you configure virtual MAC addresses with vPC, you must configure the same virtual MAC address on both vPC peers.

- You cannot use the HSRP MAC address burned-in option on a VLAN interface that is a vPC member.

Default Settings

Table 5-2 lists the default settings for HSRP parameters.

Table 5-2 Default HSRP Parameters

Parameters

Default

HSRP

Disabled

Authentication

Enabled as text for version 1, with cisco as the password

HSRP version

Version 1

Preemption

Disabled

Priority

100

virtual MAC address

Derived from HSRP group number

Platform Support

The following platform supports this feature. For platform-specific information, including guidelines and limitations, system defaults, and configuration limits, see the corresponding documentation.

Platform

Documentation

Cisco Nexus 7000 Series switches

Cisco Nexus 7000 Series Switches Documentation

Configuring HSRP

You can access HSRP from the Routing feature selection.

For more information about the Cisco Data Center Network Manager features, see the Fundamentals Configuration Guide, Cisco DCNM for LAN, Release 5.x .

This section includes the following topics:

- Enabling the HSRP Feature

- Using the HSRP Template

- Configuring the HSRP Version

- Configuring an HSRP Group for IPv4

- Configuring an HSRP Group for IPv6

- Configuring the HSRP Virtual MAC Address

- Authenticating HSRP

- Configuring Preemption

- Configuring HSRP Object Tracking

- Configuring the HSRP Priority

- Customizing HSRP

- Configuring Extended Hold Timers for HSRP

Note If you are familiar with the Cisco IOS CLI, be aware that the Cisco NX-OS commands for this feature might differ from the Cisco IOS commands that you would use.

Enabling the HSRP Feature

You must globally enable the HSRP feature before you can configure and enable any HSRP groups.

BEFORE YOU BEGIN

System-message logging levels for the HSRP feature must meet or exceed Cisco DCNM requirements. During device discovery, Cisco DCNM detects inadequate logging levels and raises them to the minimum requirements. Cisco Nexus 7000 Series switches that run Cisco NX-OS Release 4.0 are an exception. For Cisco NX-OS Release 4.0, prior to device discovery, use the command-line interface to configure logging levels to meet or exceed Cisco DCNM requirements. For more information, see the Fundamentals Configuration Guide, Cisco DCNM for LAN, Release 5.x .

Ensure that you are in the correct VDC (or use the switchto vdc command).

DETAILED STEPS

To enable the HSRP feature in a VDC, use the following command in global configuration mode:

Command

Purpose

feature hsrp

Example :

switch(config)# feature hsrp

Enables HSRP.

To disable the HSRP feature in a VDC and remove all associated configuration, use the following command in global configuration mode:

Command

Purpose

no feature hsrp

Example :

switch(config)# no feature hsrp

Disables HSRP for all groups in a VDC.

Using the HSRP Template

You can use the HSRP template to configure a base set of common parameters that Cisco NX-OS uses across all HSRP groups. You can override these values by configuring the same parameters within an individual HSRP group.

To enter the HSRP template configuration mode, use the following command in global configuration mode:

Command

Purpose

hsrp-template

Example :

switch(config)# hsrp-template

switch(config-hsrp-template)#

Enters HSRP template configuration mode

Configuring the HSRP Version

You can configure the HSRP version. If you change the version for existing groups, Cisco NX-OS reinitializes HSRP for those groups because the virtual MAC address changes. The HSRP version applies to all groups on the interface.

Note IPv6 HSRP groups must be configured as HSRP version 2.

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > HSRP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure HSRP on.

The system highlights the HSRP row in the Summary pane, and tabs update in the Details pane.

Step 3 From the highlighted Interface field, select the interface that you want to configure an HSRP group on from the drop-down list.

Step 4 From the Details pane, click the Interface Settings tab.

The Interface Settings tab appears.

Step 5 From the Interface Settings tab, in the HSRP Version field, enter 1 for HSRP version 1 or enter 2 for HSRP version 2.

Step 6 From the menu bar, choose File > Deploy to apply your changes to the device.

To configure the HSRP version, use the following command in interface configuration mode:

Command

Purpose

hsrp version { 1 | 2 }

Example :

switch(config-if)# hsrp version 2

Configures the HSRP version. Version 1 is the default.

Configuring an HSRP Group for IPv4

You can configure an HSRP group on an IPv4 interface and configure the virtual IP address and virtual MAC address for the HSRP group.

BEFORE YOU BEGIN

Ensure that you have enabled the HSRP feature (see the “Enabling the HSRP Feature” section).

Cisco NX-OS enables an HSRP group once you configure the virtual IP address on any member interface in the group. You should configure HSRP attributes such as authentication, timers, and priority before you enable the HSRP group.

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. interface type number

3. ip ip-address/length

4. hsrp group-number [ ipv4 ]

5. ip [ ip-address [ secondary ]]

6. exit

7. no shutdown

8. show hsrp [group group-number ] [ ipv4 ]

9. copy running-config startup-config

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > HSRP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure HSRP on.

Step 3 Right-click and choose New IPv4 GroupSetting .

Step 4 From the Interface drop-down list, select the interface or group of interfaces that you want to configure an HSRP group on.

Step 5 From the Group ID field, enter the group number for this group.

The range is from 0 to 255.

Step 6 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 7 From the Group Details tab, expand the Group Details section.

The basic group information appears in the Details pane.

Step 8 (Optional) From the Group Name field, enter a name for this HSRP group member.

Step 9 (Optional) From the Virtual IP Address Settings Area, check Learn Virtual IP from Members of Group to learn the virtual IP address from another HSRP group member.

Step 10 (Optional) From the Virtual IP Address Settings Area, in the Virtual IP Address field, enter an IPv4 address.

Step 11 (Optional) From the Virtual IP Address Settings Area, in the Secondary IP Address field, enter an IPv4 address for the secondary IP address.

Step 12 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Configuring an HSRP Group for IPv6

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

interface type number

Example:

switch(config)# interface ethernet 1/2

switch(config-if)#

Enters interface configuration mode.

Step 3

ip ip-address/length

Example :

switch(config-if)# ip 192.0.2.2/8

Configures the IPv4 address of the interface.

Step 4

hsrp group-number [ ipv4 ]

Example :

switch(config-if)# hsrp 2

switch(config-if-hsrp)#

Creates an HSRP group and enters hsrp configuration mode. The range for HSRP version 1 is from 0 to 255. The range is for HSRP version 2 is from 0 to 4095. The default value is 0.

Step 5

ip [ ip-address [ secondary ]]

Example :

switch(config-if-hsrp)# ip 192.0.2.1

Configures the virtual IP address for the HSRP group and enables the group. This address should be in the same subnet as the IPv4 address of the interface.

Step 6

exit

Example :

switch(config-if-hsrp)# exit

Exits HSRP configuration mode.

Step 7

no shutdown

Example :

switch(config-if)# no shutdown

Enables the interface.

Step 8

show hsrp [ group group-number ] [ ipv4 ]

Example :

switch(config-if)# show hsrp group 2

(Optional) Displays HSRP information.

Step 9

copy running-config startup-config

Example:

switch(config-if)# copy running-config startup-config

(Optional) Saves this configuration change.

Note You should use the no shutdown command to enable the interface after you finish the configuration.

The following example shows how to configure an HSRP group on Ethernet 1/2:

switch# config t

switch(config)# interface ethernet 1/2

switch(config-if)# ip 192.0.2.2/8

switch(config-if)# hsrp 2

switch(config-if-hsrp)# ip 192.0.2.1

switch(config-if-hsrp)# exit

switch(config-if)# no shutdown

switch(config-if)# copy running-config startup-config

Using the HSRP Template

You can use the HSRP template to configure a base set of common parameters that Cisco NX-OS uses across all HSRP groups. You can override these values by configuring the same parameters within an individual HSRP group.

To enter the HSRP template configuration mode, use the following command in global configuration mode:

Command

Purpose

hsrp-template

Example :

switch(config)# hsrp-template

switch(config-hsrp-template)#

Enters HSRP template configuration mode

Configuring an HSRP Group for IPv6

You can configure an HSRP group on an IPv6 interface and configure the virtual MAC address for the HSRP group.

When you configure an HSRP group for IPv6, HSRP generates a link-local address from the link-local prefix. HSRP also generates a modified EUI-64 format interface identifier in which the EUI-64 interface identifier is created from the relevant HSRP virtual MAC address.

There are no HSRP IPv6 secondary addresses.

BEFORE YOU BEGIN

Ensure that you have enabled the HSRP feature (see the “Enabling the HSRP Feature” section).

Ensure that you have enabled HSRP version 2 on the interface that you want to configure an IPv6 HSRP group on.

Ensure that you have configured HSRP attributes such as authentication, timers, and priority before you enable the HSRP group.

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. interface type number

3. ipv6 address ipv6-address/length

4. hsrp version 2

5. hsrp group-number ipv6

6. ip ipv6-address

or

ip autoconfig

7. no shutdown

8. show hsrp [group group-number ] [ ipv6 ]

9. copy running-config startup-config

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > HSRP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure HSRP on.

Step 3 Right-click and choose New IPv6 GroupSetting .

Step 4 From the Interface drop-down list, select the interface or group of interfaces that you want to configure an HSRP group on.

Step 5 From the Group ID field, enter the group number for this group.

Step 6 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 7 From the Group Details tab, expand the Interfaces section.

The HSRP interface information appears in the Details pane.

Step 8 From the HSRP Version field, enter 2 for HSRP version 2.

Step 9 From the Group Details tab, expand the Group Details section.

The basic group information appears in the Details pane.

Step 10 (Optional) From the Group Name field, enter a name for this HSRP group member.

Step 11 (Optional) From the Virtual IP Address Settings Area, check Autoconfigure IP address to configure the virtual IPv6 address from the link-local address and the HSRP virtual MAC address.

Step 12 (Optional) From the Virtual IP Address Settings Area, check Learn Virtual IP from Members of Group to learn the virtual IP address from another HSRP group member.

Step 13 (Optional) From the Virtual IP Address Settings Area, in the Virtual IPv6 Address field, enter an IPv6 address.

Step 14 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Configuring an HSRP Group for IPv4

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

interface type number

Example:

switch(config)# interface ethernet 3/2

switch(config-if)#

Enters interface configuration mode.

Step 3

ipv6 address ipv6-address/length

Example :

switch(config-if)# ipv6 address 2001:0DB8:0001:0001:/64

Configures the IPv6 address of the interface.

Step 4

hsrp version 2

Example :

switch(config-if-hsrp)# hsrp version 2

Configures this group for HSRP version 2.

Step 5

hsrp group-number ipv6

Example :

switch(config-if)# hsrp 10 ipv6

switch(config-if-hsrp)#

Creates an IPv6 HSRP group and enters hsrp configuration mode. The range for HSRP version 2 is from 0 to 4095. The default value is 0.

Step 6

ip [ ipv6-address [ secondary ]]

Example :

switch(config-if-hsrp)# ip 2001:DB8::1

Configures the virtual IPv6 address for the HSRP group and enables the group.

Step 7

ip autoconfig

Example :

switch(config-if-hsrp)# ip autoconfig

Autoconfigures the virtual IPv6 address for the HSRP group from the calculated link-local virtual IPv6 address and enables the group.

Step 8

no shutdown

Example :

switch(config-if-hsrp)# no shutdown

Enables the interface.

Step 9

show hsrp [ group group-number ] [ ipv6 ]

Example :

switch(config-if-hsrp)# show hsrp group 10

(Optional) Displays HSRP information.

Step 10

copy running-config startup-config

Example:

switch(config-if-hsrp)# copy running-config startup-config

(Optional) Saves this configuration change.

Note You should use the no shutdown command to enable the interface after you finish the configuration.

The following example shows how to configure an IPv6 HSRP group on Ethernet 3/2:

switch# config t

switch(config)# interface ethernet 3/2

switch(config-if)# ipv6 address 2001:0DB8:0001:0001:/64

switch(config-if)# hsrp 2 ipv6

switch(config-if-hsrp)# exit

switch(config-if)# no shutdown

switch(config-if)# copy running-config startup-config

Configuring the HSRP Virtual MAC Address

You can override the default virtual MAC address that HSRP derives from the configured group number.

Note You must configure the same virtual MAC address on both vPC peers of a vPC link.

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > HSRP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure HSRP on.

The system highlights the HSRP row in the Summary pane, and tabs update in the Details pane.

Step 3 From the highlighted Interface field, select the interface that you want to configure an HSRP group on from the drop-down list.

Step 4 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 5 From the Group Details tab, expand the Group Details section.

The basic group information appears in the Details pane.

Step 6 From the Virtual MAC Address field, enter the virtual MAC address.

The string uses the standard MAC address format (xxxx.xxxx.xxxx).

Step 7 From the menu bar, choose File > Deploy to apply your changes to the device.

You can configure HSRP to use the burned-in MAC address as the virtual MAC address on an interface.

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > HSRP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure HSRP on.

The system highlights the HSRP row in the Summary pane, and tabs update in the Details pane.

Step 3 From the highlighted Interface field, select the interface that you want to configure an HSRP group on from the drop-down list.

Step 4 From the Details pane, click the Interface Settings tab.

The Interface Settings tab appears.

Step 5 From the Interface Settings tab, check Use Burned In Address (use-bia) .

Step 6 (Optional) To use the burned-in address for all groups, check Apply Use Burned In Address (use-bia) to all Groups.

Step 7 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Configuring an HSRP Group for IPv4

- Configuring an HSRP Group for IPv6

To manually configure the virtual MAC address for an HSRP group, use the following command in hsrp configuration mode:

Command

Purpose

mac-address string

Example :

switch(config-if-hsrp)# mac-address 5000.1000.1060

Configures the virtual MAC address for an HSRP group. The string uses the standard MAC address format (xxxx.xxxx.xxxx).

To configure HSRP to use the burned-in MAC address of the interface for the virtual MAC address, use the following command in interface configuration mode:

Command

Purpose

hsrp use-bia [ scope interface ]

Example :

switch(config-if)# hsrp use-bia

Configures HSRP to use the burned-in MAC address of the interface for the HSRP virtual MAC address. You can optionally configure HSRP to use the burned-in MAC address for all groups on this interface by using the scope interface keywords.

Authenticating HSRP

You can configure HSRP to authenticate the protocol using cleartext or MD5 digest authentication. MD5 authentication uses a key chain (see the Cisco Nexus 7000 Series NX-OS Security Configuration Guide, Release 5.x ).

BEFORE YOU BEGIN

Ensure that you have enabled the HSRP feature (see the “Enabling the HSRP Feature” section).

You must configure the same authentication and keys on all members of the HSRP group.

Ensure that you have created the key chain if you are using MD5 authentication.

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. interface interface- type slot/port

3. hsrp group- number [ ipv4 | ipv6 ]

4. authentication text string

or

authentication md5 { key-chain key-chain | key-string { 0 | 7 } text [ timeout seconds ]}

5. show hsrp [ group group-number ]

6. copy running-config startup-config

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > HSRP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure HSRP on.

The system highlights the HSRP row in the Summary pane, and tabs update in the Details pane.

Step 3 From the highlighted Interface field, select the interface that you want to configure an HSRP group on from the drop-down list.

Step 4 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 5 From the Group Details tab, expand the Authentication, Router Preemption section.

The authentication information appears in the Details pane.

Step 6 From the Authentication area, from the Method drop-down list, choose the authentication method.

Step 7 (Optional) For text authentication, in the password field, enter the password string.

Step 8 (Optional) For MD5 authentication, choose either Key or Key Chain .

Step 9 (Optional) For the Key option, in the key field, enter the key string, time-out value, and check Encrypted for an encrypted key string.

Step 10 (Optional) For the Key Chain option, from the key chain drop-down list, choose the key chain that you want to use.

Step 11 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Configuring an HSRP Group for IPv4

- Configuring an HSRP Group for IPv6

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

interface interface-type slot/port

Example:

switch(config)# interface ethernet 1/2

switch(config-if)#

Enters interface configuration mode.

Step 3

hsrp group-number [ ipv4 | ipv6 ]

Example :

switch(config-if)# hsrp 2

switch(config-if-hsrp)#

Creates an HSRP group and enters HSRP configuration mode.

Step 4

authentication text string

Example :

switch(config-if-hsrp)# authentication text mypassword

Configures cleartext authentication for HSRP on this interface.

authentication md5 { key-chain key-chain | key-string { 0 | 7 } text [ timeout seconds ]}

Example :

switch(config-if-hsrp)# authentication md5 key-chain hsrp-keys

Configures MD5 authentication for HSRP on this interface. You can use a key chain or key string. If you use a key string, you can optionally set the timeout for when HSRP will only accept a new key. The range is from 0 to 32767 seconds.

Step 5

show hsrp [ group group-number ]

Example :

switch(config-if-hsrp)# show hsrp group 2

(Optional) Displays HSRP information.

Step 6

copy running-config startup-config

Example:

switch(config-if-hsrp)# copy running-config startup-config

(Optional) Saves this configuration change.

The following example shows how to configure MD5 authentication for HSRP on Ethernet 1/2 after creating the key chain:

switch# config t

switch(config)# key chain hsrp-keys

switch(config-keychain)# key 0

switch(config-keychain-key)# key-string 7 zqdest

switch(config-keychain-key) accept-lifetime 00:00:00 Jun 01 2008 23:59:59 Sep 12 2008

switch(config-keychain-key) send-lifetime 00:00:00 Jun 01 2008 23:59:59 Aug 12 2008

switch(config-keychain-key) key 1

switch(config-keychain-key) key-string 7 uaeqdyito

switch(config-keychain-key) accept-lifetime 00:00:00 Aug 12 2008 23:59:59 Dec 12 2008

switch(config-keychain-key) send-lifetime 00:00:00 Sep 12 2008 23:59:59 Nov 12 2008

switch(config-keychain-key)# interface ethernet 1/2

switch(config-if)# hsrp 2

switch(config-if-hsrp)# authenticate md5 key-chain hsrp-keys

switch(config-if-hsrp)# copy running-config startup-config

Configuring Preemption

You can configure HSRP to preempt another active router based on the configured priority.

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > HSRP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure HSRP on.

The system highlights the HSRP row in the Summary pane, and tabs update in the Details pane.

Step 3 From the highlighted Interface field, select the interface that you want to configure an HSRP group on from the drop-down list.

Step 4 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 5 From the Group Details tab, expand the Authentication, Router Preemption section.

The authentication information appears in the Details pane.

Step 6 Check Router Preemption .

Step 7 From the Minimum Delay(sec) field, enter the minimum delay time.

Step 8 From the Sync Delay(sec) field, enter the sync delay time.

Step 9 From the Reload Delay(sec) field, enter the reload delay time.

Step 10 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Configuring an HSRP Group for IPv4

- Configuring an HSRP Group for IPv6

- Configuring HSRP Object Tracking

Configuring HSRP Object Tracking

You can configure an HSRP group to adjust its priority based on the availability of other interfaces or routes. The priority of a device can change dynamically if it has been configured for object tracking and the object that is being tracked goes down.

The tracking process periodically polls the tracked objects and notes any value change. The value change triggers HSRP to recalculate the priority. The HSRP interface with the higher priority becomes the active router if you configure the HSRP interface for preemption. For more information on object tracking, see the “Configuring Preemption” section.

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > HSRP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure HSRP on.

The system highlights the HSRP row in the Summary pane, and tabs update in the Details pane.

Step 3 From the highlighted Interface field, select the interface that you want to configure an HSRP group on from the drop-down list.

Step 4 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 5 From the Group Details tab, expand the Object Tracking section.

The object tracking information appears in the Details pane.

Step 6 Right-click and choose Add Track Object .

Step 7 From the object ID drop-down list, choose the object ID that you want to use to modify the HSRP priority value with.

Step 8 In the Decrement field, enter the value that you want to decrement the HSRP priority with if the tracked object state goes down.

Step 9 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Configuring an HSRP Group for IPv4

- Configuring an HSRP Group for IPv6

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

track object-id interface interface-type number {{ ip | ipv6 } routing | line-protocol }

Example:

switch(config)# track 1 interface ethernet 2/2 line-protocol

switch(config-track#

Configures the interface that this HSRP interface tracks. Changes in the state of the interface affect the priority of this HSRP interface as follows:

- You configure the interface and corresponding object number that you use with the track command in hsrp configuration mode.

- The line-protocol keyword tracks whether the interface is up. The ip keyword also checks that IP routing is enabled on the interface and an IP address is configured.

track object-id { ip | ipv6 } route ip-prefix/length reachability

Example:

switch(config)# track 2 ip route 192.0.2.0/8 reachability

switch(config-track#

Creates a tracked object for a route and enters tracking configuration mode. The object-id range is from 1 to 500.

Step 3

interface interface-type slot/port

Example:

switch(config)# interface ethernet 1/2

switch(config-if)#

Enters interface configuration mode.

Step 4

hsrp group-number [ ipv4 | ipv6 ]

Example :

switch(config-if)# hsrp 2

switch(config-if-hsrp)#

Creates an HSRP group and enters hsrp configuration mode.

Step 5

priority [ value ]

Example:

switch(config-if-hsrp)# priority 254

Sets the priority level used to select the active router in an HSRP group. The range is from 0 to 255. The default is 100.

Step 6

track object-number [ decrement value ]

Example:

switch(config-if-hsrp)# track 1 decrement 20

Specifies an object to be tracked that affects the weighting of an HSRP interface.

The value argument specifies a reduction in the priority of an HSRP interface when a tracked object fails. The range is from 1 to 255. The default is 10.

Step 7

preempt [ delay [ minimum seconds ] [ reload seconds ] [ sync seconds ]]

Example:

switch(config-if-hsrp)# preempt delay minimum 60

Configures the router to take over as the active router for an HSRP group if it has a higher priority than the current active router. This command is disabled by default. The range is from 0 to 3600 seconds.

Step 8

show hsrp interface interface-type number

Example:

switch(config-if-hsrp)# show hsrp interface ethernet 1/2

(Optional) Displays HSRP information for an interface.

Step 9

copy running-config startup-config

Example:

switch(config-if-hsrp)# copy running-config startup-config

(Optional) Saves this configuration change.

The following example shows how to configure HSRP object tracking on Ethernet 1/2:

switch# config t

switch(config)# track 1 interface ethernet 2/2 line-protocol

switch(config)# interface ethernet 1/2

switch(config-if)# hsrp 2

switch(config-if-hsrp)# track 1 decrement 20

switch(config-if-hsrp)# copy running-config startup-config

Configuring the HSRP Priority

You can configure the HSRP priority on an interface. HSRP uses the priority to determine which HSRP group member acts as the active router. If you configure HSRP on a vPC-enabled interface, you can optionally configure the upper and lower threshold values to control when to fail over to the vPC trunk If the standby router priority falls below the lower threshold, HSRP sends all standby router traffic across the vPC trunk to forward through the active HSRP router. HSRP maintains this scenario until the standby HSRP router priority increases above the upper threshold.

For IPv6 HSRP groups, if all group members have the same priority, HSRP selects the active router based on the IPv6 link-local address.

DETAILED STEPS

To configure the HSRP priority, use the following command in interface configuration mode:

Command

Purpose

priority level [ forwarding-threshold lower lower-value upper upper-value ]

Example:

switch(config-if-hsrp)# priority 60 forwarding-threshold lower 40 upper 50

Sets the priority level used to select the active router in an HSRP group. The level range is from 0 to 255. The default is 100. Optionally, sets the upper and lower threshold values used by vPC to determine when to fail over to the vPC trunk. The lower-value range is from 1 to 255. The default is 1. The upper-value range is from 1 to 255. The default is 255.

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > HSRP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure the HSRP priority on.

The system highlights the HSRP row in the Summary pane, and tabs update in the Details pane.

Step 3 From the highlighted Interface field, select the interface that you want to configure the HSRP priority on from the drop-down list.

Step 4 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 5 From the Group Details tab, expand the Group Details section.

The basic group information appears in the Details pane.

Step 6 (Optional) From the Configured Priority field, enter the priority for this HSRP group member.

The range is from 1 to 255. The default is 100.

Step 7 (Optional) Check Forwarding Threshold and set the upper and lower threshold values used by vPC to determine when to fail over to the vPC trunk.

The range is from 1 to 255. The lower threshold default is 1. The upper threshold default is 100.

Step 8 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Configuring an HSRP Group for IPv4

- Configuring an HSRP Group for IPv6

Customizing HSRP

You can optionally customize the behavior of HSRP. Be aware that as soon as you enable an HSRP group by configuring a virtual IP address, that group is now operational. If you first enable an HSRP group before customizing HSRP, the router could take control over the group and become the active router before you finish customizing the feature. If you plan to customize HSRP, you should do so before you enable the HSRP group.

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > HSRP .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure HSRP on.

The system highlights the HSRP row in the Summary pane, and tabs update in the Details pane.

Step 3 From the highlighted Interface field, select the interface that you want to configure an HSRP group on from the drop-down list.

Step 4 From the Details pane, click the Group Details tab.

The Group Details tab appears.

Step 5 From the Group Details tab, expand the Timers section.

The HSRP timers information appears in the Details pane.

Step 6 From the Configured Timers area, in the Hello Time field, enter the hello time.

Step 7 Choose sec or msec from the drop-down list.

Step 8 From the Configured Timers area, in the Hold Time field, enter the hold time.

Step 9 Choose sec or msec from the drop-down list.

Step 10 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Configuring an HSRP Group for IPv4

- Configuring an HSRP Group for IPv6

To customize HSRP, use the following commands in hsrp configuration mode:

Command

Purpose

name string

Example:

switch(config-if-hsrp)# name HSRP-1

Specifies the IP redundancy name for an HSRP group. The string is from 1 to 255 characters. The default string has the following format:

hsrp-<interface-short-name>-<group-id>. For example, hsrp-Eth2/1-1.

preempt [ delay [ minimum seconds ] [ reload seconds ] [ sync seconds ]]

Example:

switch(config-if-hsrp)# preempt delay minimum 60

Configures the router to take over as an active router for an HSRP group if it has a higher priority than the current active router. This command is disabled by default. The range is from 0 to 3600 seconds.

timers [ msec ] hellotime [ msec ] holdtime

Example:

switch(config-if-hsrp)# timers 5 18

Configures the hello and hold time for this HSRP member as follows:

- hellotime —The interval between successive hello packets sent. The range is from 1 to 254 seconds.

- holdtime —The interval before the information in the hello packet is considered invalid. The range is from 3 to 255.

The optional msec keyword specifies that the argument is expressed in milliseconds, instead of the default seconds. The timer ranges for milliseconds are as follows:

- hellotime —The interval between successive hello packets sent. The range is from 255 to 999 milliseconds.

- holdtime —The interval before the information in the hello packet is considered invalid. The range is from 750 to 3000 milliseconds.

To customize HSRP, use the following commands in interface configuration mode:

Command or Action

Purpose

hsrp delay minimum seconds

Example:

switch(config-if)# hsrp delay minimum 30

Specifies the minimum amount of time that HSRP waits after a group is enabled before participating in the group. The range is from 0 to 10000 seconds. The default is 0.

hsrp delay reload seconds

Example:

switch(config-if)# hsrp delay reload 30

Specifies the minimum amount of time that HSRP waits after reload before participating in the group. The range is from 0 to 10000 seconds. The default is 0.

Configuring Extended Hold Timers for HSRP

You can configure HSRP to use extended hold timers to support extended NSF during a controlled (graceful) switchover or ISSU, including software upgrades and supervisor switchovers.You should configure extended hold timers on all HSRP routers (see the “High Availability and Extended Nonstop Forwarding” section).

Note You must configure extended hold timers on all HSRP routers if you configure extended hold timers. If you configure a nondefault hold timer, you should configure the same value on all HSRP routers when you configure HSRP extended hold timers.

Note HSRP extended hold timers are not applied if you configure millisecond HSRP hello and hold timers.

To configure HSRP extended hold timers, use the following command in global configuration mode:

Command

Purpose

hsrp timers extended-hold [ timer ]

Example :

switch(config)# hsrp timers extended-hold

Sets the HSRP extended hold timer, in seconds. The timer range is from 10 to 255. The default is 10.

Use the show hsrp command or the show running-config hsrp command to display the extended hold time.

Verifying the HSRP Configuration

To display HSRP configuration information, perform one of the following tasks:

Command

Purpose

show hsrp [group group-number]

Displays the HSRP status for all groups or one group.

show hsrp delay [interface interface-type slot/port]

Displays the HSRP delay value for all interfaces or one interface.

show hsrp [interface interface-type slot/port]

Displays the HSRP status for an interface.

show hsrp [group group-number] [interface interface-type slot/port] [active] [all] [init] [learn] [listen] [speak] [standby]

Displays the HSRP status for a group or interface for virtual forwarders in the active, init, learn, listen, or standby state. Use the all keyword to see all states, including disabled.

show hsrp [group group-number] [interface interface-type slot/port] active] [all] [init] [learn] [listen] [speak] [standby] brief

Displays a brief summary of the HSRP status for a group or interface for virtual forwarders in the active, init, learn, listen, or standby state. Use the all keyword to see all states, including disabled.

Configuration Examples for HSRP

The following example shows how to enable HSRP on an interface with MD5 authentication and interface tracking:

key chain hsrp-keys

key 0

key-string 7 zqdest

accept-lifetime 00:00:00 Jun 01 2008 23:59:59 Sep 12 2008

send-lifetime 00:00:00 Jun 01 2008 23:59:59 Aug 12 2008

key 1

key-string 7 uaeqdyito

accept-lifetime 00:00:00 Aug 12 2008 23:59:59 Dec 12 2008

send-lifetime 00:00:00 Sep 12 2008 23:59:59 Nov 12 2008

feature hsrp

track 2 interface ethernet 2/2 ip

interface ethernet 1/2

ip address 192.0.2.2/8

hsrp 1

authenticate md5 key-chain hsrp-keys

priority 90

track 2 decrement 20

ip-address 192.0.2.10

no shutdown

Field Descriptions for HSRP

This section includes the following field descriptions for HSRP:

- HSRP: Group Details Tab: Group Details Section

- HSRP: Group Details Tab: Authentication, Router Preemption Section

- HSRP: Group Details Tab: Timers Section

- HSRP: Group Details Tab: Object Tracking Section

- HSRP: Interface Settings Tab

HSRP: Group Details Tab: Group Details Section

Table 5-3 HSRP: Group Details: Group Details

Field

Description

Router

Group ID

Display only. Group number for the HSRP group.

Group Name

Name of the HSRP group.

Configured Priority

Configured priority for the group.

Virtual MAC Address

MAC address of the virtual router.

Active Priority

Display only. Priority for the group.

Router State

Display only. State of the group.

State Change Count

Display only. Number of state changes for the group.

Last State Change

Display only. Time of the last state change for the group.

IP Address Settings

Autoconfigure IP address

Configures the virtual IPv6 address from the link-local address and the HSRP virtual MAC address.

Learn Virtual IP from Members of Group

Learns the virtual IPv4 or IPv6 address from other members of the HSRP group.

Virtual IP Address

IPv4 address of the virtual router.

Secondary IP Address

Secondary IPv4 address of the virtual router.

Forwarding Threshold

Forwarding Threshold

Enables threshold values for vPC.

Lower Threshold

Lower forwarding threshold value.

Upper Threshold

Upper forwarding threshold value.

Active Router

IP Address

Display only. IPv4 or IPv6 address of the active router.

Priority

Display only. Priority of the active router.

Standby Router

IP Address

Display only. IPv4 or IPv6 address of the standby router.

Priority

Display only. Priority of the standby router.

HSRP: Group Details Tab: Authentication, Router Preemption Section

Table 5-4 HSRP: Group Details: Authentication, Router Preemption

Field

Description

Authentication

Method

Authentication method for this HSRP group.

Password

Password if text authentication is selected.

Key Chain

Key chain name if key-chain authentication is selected.

Key

Password if key-chain authentication is not selected.

Encrypted

Encrypts the password for this HSRP group.

Router Preemption

Router Preemption

Enables router preemption.

Minimum Delay

Minimum time that router preemption can be delayed.

Sync Delay

Maximum time to allow IP redundancy clients to prevent router preemption.

Reload Delay

Time after a router reload occurs before HSRP detects an interface up event.

HSRP: Group Details Tab: Timers Section

Table 5-5 HSRP: Group Details:Timers

Field

Description

Active Timer Values

Hello Time

Display only. Hello time for this HSRP group.

Hold Time

Display only. Hold time for this HSRP group.

Configured Timer s

Hello Time

Hello time for this HSRP group.

Hold Time

Hold time for this HSRP group.

sec/msec

Unit of time for the configured timer.

HSRP: Group Details Tab: Object Tracking Section

Table 5-6 HSRP: Group Details: Object Tracking

Field

Description

Track ID

Object tracking identifier.

Tracked Object

Display only. Name of the tracked object.

Decrement

Value to decrement the HSRP group priority if tracked object status is down.

HSRP: Interface Settings Tab

Table 5-7 HSRP:Interface Settings Tab

Field

Description

HSRP Version

Version of HSRP for all groups on this interface.

Minimum Delay

Minimum time to delay HSRP group initialization after this interface comes up.

Reload Delay

Time to delay after a router reload occurs before HSRP detects this interface is up.

Use Burned In Address

Use the burned-in MAC address of this interface instead of the HSRP virtual MAC address.

Additional References

For additional information related to implementing HSRP, see the following sections:

- Related Documents

- MIBs

Related Documents

Related Topic

Document Title

Configuring the Gateway Load Balancing protocol

Chapter 4, “Configuring GLBP”

HSRP CLI commands

Cisco Nexus 7000 Series NX-OS Unicast Routing Command Reference

Configuring high availability

Cisco Nexus 7000 Series NX-OS High Availability and Redundancy Guide, Release 5.x

MIBs

MIBs

MIBs Link

CISCO-HSRP-MIB

To locate and download MIBs, go to the following URL:

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

Feature History for HSRP

Table 5-8 lists the release history for this feature.

Table 5-8 Feature History for HSRP

Feature Name

Releases

Feature Information

BFD

5.0(2)

Added support for BFD. See the Cisco Nexus 7000 Series NX-OS Interfaces Configuration Guide, Release 5.x , for more information.

IPv6

5.0(2)

Added support for IPv6.

Object track lists

4.2(1)

Added support for object track lists.

Extended hold timers

4.2(1)

Added support for extended hold timers for extended NSF support.

CISCO-HSRP-MIB

4.2(1)

Added support for CISCO-HSRP-MIB.

Priority thresholds

4.1(3)

Added support for vPC threshold values on HSRP priority.

DCNM support

4.1(2)

Added support for HSRP to DCNM.

HSRP

4.0(1)

This feature was introduced.

Configuring Object Tracking

This chapter describes how to configure object tracking on the Cisco DC-OS Cisco NX-OS device.

This chapter includes the following sections:

- Information About Object Tracking

- Licensing Requirements for Object Tracking

- Prerequisites for Object Tracking

- Guidelines and Limitations

- Default Settings

- Platform Support

- Configuring Object Tracking

- Verifying the Object Tracking Configuration

- Viewing Client Details

- Configuration Examples for Object Tracking

- Related Topics

- Field Descriptions for Object Tracking

- Field Descriptions for Object Tracking

- Feature History for Object Tracking

Information About Object Tracking

Object tracking allows you to track specific objects on the device, such as the interface line protocol state, IP routing, and route reachability, and to take action when the tracked object’s state changes. This feature allows you to increase the availability of the network and shorten recovery time if an object state goes down.

System-message logging levels for the Object Tracking feature must meet or exceed Cisco DCNM requirements. During device discovery, Cisco DCNM detects inadequate logging levels and raises them to the minimum requirements. Cisco Nexus 7000 Series switches that run Cisco NX-OS Release 4.0 are an exception. For Cisco NX-OS Release 4.0, prior to device discovery, use the command-line interface to configure logging levels to meet or exceed Cisco DCNM requirements. For more information, see the Fundamentals Configuration Guide, Cisco DCNM for LAN, Release 5.x .

This section includes the following topics:

- Object Tracking Overview

- Object Track List

- High Availability

- Virtualization Support

Object Tracking Overview

The object tracking feature allows you to create a tracked object that multiple clients can use to modify the client behavior when a tracked object changes. Several clients register their interest with the tracking process, track the same object, and take different actions when the object state changes.

Clients include the following features:

- Embedded Event Manager (EEM)

- Gateway Load Balancing Protocol (GLBP)

- Hot Standby Redundancy Protocol (HSRP)

- Virtual port channel (vPC)

- Virtual Router Redundancy Protocol (VRRP)

The object tracking monitors the status of the tracked objects and communicates any changes made to interested clients. Each tracked object is identified by a unique number that clients can use to configure the action to take when a tracked object changes state.

Cisco NX-OS tracks the following object types:

- Interface line protocol state—Tracks whether the line protocol state is up or down.

- Interface IP routing state—Tracks whether the interface has an IPv4 or IPv6 address and if IPv4 or IPv6 routing is enabled and active.

- IP route reachability—Tracks whether an IPv4 or IPv6 route exists and is reachable from the local device.

For example, you can configure HSRP to track the line protocol of the interface that connects one of the redundant routers to the rest of the network. If that link protocol goes down, you can modify the priority of the affected HSRP router and cause a switchover to a backup router that has better network connectivity.

Object Track List

An object track list allows you to track the combined states of multiple objects. Object track lists support the following capabilities:

- Boolean "and" function—Each object defined within the track list t must be in an up state so that the track list object can become up.

- Boolean "or" function—At least one object defined within the track list must be in an up state so that the tracked object can become up.

- Threshold percentage—The percentage of up objects in the tracked list must be greater than the configured up threshold for the tracked list to be in the up state. If the percentage of down objects in the tracked list is above the configured track list down threshold, the tracked list is marked as down.

- Threshold weight—Assign a weight value to each object in the tracked list, and a weight threshold for the track list. If the combined weights of all up objects exceeds the track list weight up threshold, the track list is in an up state. If the combined weights of all the down objects exceeds the track list weight down threshold, the track list is in the down state.

Other entities, such as virtual Port Channels (vPCs) can use an object track list to modify the state of a vPC based on the state of the multiple peer links that create the vPC. See the Cisco Nexus 7000 Series NX-OS Interfaces Configuration Guide, Release 5.x , for more information on vPCs.

See the “Configuring an Object Track List with a Boolean Expression” section for more information on track lists.

High Availability

Object tracking supports high availability through stateful restarts. A stateful restart occurs when the object tracking process crashes. Object tracking also supports a stateful switchover on a dual supervisor system. Cisco NX-OS applies the runtime configuration after the switchover.

You can also use object tracking to modify the behavior of a client to improve overall network availability.

Virtualization Support

Object tracking supports Virtual Routing and Forwarding (VRF) instances. VRFs exist within virtual device contexts (VDCs). By default, Cisco NX-OS places you in the default VDC and default VRF unless you specifically configure another VDC and VRF. By default, Cisco NX-OS tracks the route reachability state of objects in the default VRF. If you want to track objects in another VRF, you must configure the object to be a member of that VRF (see the “Configuring Object Tracking for a Nondefault VRF” section).

Licensing Requirements for Object Tracking

The following table shows the licensing requirements for this feature:

Product

License Requirement

Cisco DCNM

Object tracking requires a LAN Enterprise license. For a complete explanation of the Cisco DCNM licensing scheme and how to obtain and apply licenses, see the Cisco DCNM Installation and Licensing Guide, Release 5.x.

Cisco NX-OS

Object tracking requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. For an explanation of the Cisco NX-OS licensing scheme for your platform, see the licensing guide for your platformFor a complete explanation of the Cisco NX-OS licensing scheme, see the Cisco NX-OS Licensing Guide .

Prerequisites for Object Tracking

Object tracking has the following prerequisites:

- System-message logging levels for the Object Tracking feature must meet or exceed Cisco DCNM requirements. During device discovery, Cisco DCNM detects inadequate logging levels and raises them to the minimum requirements. Cisco Nexus 7000 Series switches that run Cisco NX-OS Release 4.0 are an exception. For Cisco NX-OS Release 4.0, prior to device discovery, use the command-line interface to configure logging levels to meet or exceed Cisco DCNM requirement.

Note For a full list of feature-specific prerequisites, see the platform-specific documentation.

- If you configure VDCs, install the Advanced Services license and enter the desired VDC (see the Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide, Release 5.x).

Guidelines and Limitations

Object tracking has the following configuration guidelines and limitations:

- Supports up to 500 tracked objects per VDC.

- Supports Ethernet, subinterfaces, tunnels, port channels, loopback interfaces, and VLAN interfaces.

- Supports one tracked object per HSRP group or GLBP group.

Default Settings

Table 6-1 lists the default settings for object tracking parameters.

Table 6-1 Default Object Tracking Parameters

Parameters

Default

Tracked Object VRF

Member of default VRF

Platform Support

The following platform supports this feature. For platform-specific information, including guidelines and limitations, system defaults, and configuration limits, see the corresponding documentation.

Platform

Documentation

Cisco Nexus 7000 Series switches

Cisco Nexus 7000 Series Switches Documentation

Configuring Object Tracking

You can access object tracking from the Routing feature selection.

For more information about the Data Center Network Manager features, see the Fundamentals Configuration Guide, Cisco DCNM for LAN, Release 5.x .

This section includes the following topics:

- Configuring Object Tracking for an Interface

- Configuring Object Tracking for an IPv6 Interface

- Deleting an Interface IPv6 Object Tracking

- Creating a New IP Route IPv6 Object Tracking

- Deleting an IP Route IPv6 Object Tracking

- Configuring Object Tracking for Route Reachability

- Configuring an Object Track List with a Boolean Expression

- Configuring an Object Track List with a Percentage Threshold

- Configuring an Object Track List with a Weight Threshold

- Configuring an Object Tracking Delay

- Configuring Object Tracking for a Nondefault VRF

Note If you are familiar with the Cisco IOS CLI, be aware that the Cisco NX-OS commands for this feature might differ from the Cisco IOS commands that you would use.

Configuring Object Tracking for an Interface

You can configure Cisco NX-OS to track the line protocol or IPv4 or IPv6 routing state of an interface.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. track object- id interface interface-type number {{ ip | ipv6 } routing | line-protocol }

3. show track [ object- id ]

4. copy running-config startup-config

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > Object Tracking .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure object tracking on.

Step 3 From the menu bar, choose Actions > New Track Object .

The system highlights the new tracked object row in the Summary pane, and tabs update in the Details pane.

Step 4 From the highlighted Track Object ID field, enter the object ID.

Step 5 From the Details pane, click the Object Tracking Details tab.

The Object Tracking Details tab appears.

Step 6 From the Object Tracking Details tab, in the Tracking Object Type drop-down list, choose Interface .

Step 7 From the Instance drop-down list, choose the interface that you want to track.

Step 8 From the Parameter drop-down list, choose either IP Routing , IPv6 Routing , or Line Protocol .

Step 9 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Configuring Object Tracking for Route Reachability

- Viewing Client Details

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

track object-id interface interface-type number {{ ip | ipv6 } routing | line-protocol }

Example:

switch(config)# track 1 interface ethernet 1/2 line-protocol

switch(config-track#

Creates a tracked object for an interface and enters tracking configuration mode. The object-id range is from 1 to 500.

Step 3

show track [ object-id ]

Example :

switch(config-track)# show track 1

(Optional) Displays object tracking information.

Step 4

copy running-config startup-config

Example:

switch(config-track)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to configure object tracking for the line protocol state on Ethernet 1/2:

switch# config t

switch(config)# track 1 interface ethernet 1/2 line-protocol

switch(config-track)# copy running-config startup-config

This example shows how to configure object tracking for the IPv4 routing state on Ethernet 1/2:

switch# config t

switch(config)# track 2 interface ethernet 1/2 ip routing

switch(config-track)# copy running-config startup-config

This example shows how to configure object tracking for the IPv6 routing state on Ethernet 1/2:

switch# config t

switch(config)# track 3 interface ethernet 1/2 ipv6 routing

switch(config-track)# copy running-config startup-config

Configuring Object Tracking for an IPv6 Interface

You can configure Cisco NX-OS to track the line protocol or IPv6 routing state of an interface.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. track object- id interface interface-type number { ipv6 routing }

3. show track [ object- id ]

4. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

track object-id interface interface-type number { ipv6 routing }

Example:

switch(config)# track 1 interface ethernet 1/2 line-protocol

switch(config-track#

Creates a tracked object for an interface and enters tracking configuration mode. The object-id range is from 1 to 500.

Step 3

show track [ object-id ]

Example :

switch(config-track)# show track 1

Track 1

IPv6 Route 1::2/64 Reachability

Reachability is DOWN

0 changes, last change never

(Optional) Displays object tracking information.

Step 4

copy running-config startup-config

Example:

switch(config-track)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to configure object tracking for the IPv6 routing state on Ethernet 1/2:

switch# config t

switch(config)# track 3 interface ethernet 1/2 ipv6 routing

switch(config-track)# copy running-config startup-config

You can configure Cisco NX-OS to track the line protocol or IPv6 routing state of an interface.

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > Object Tracking.

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure object tracking on.

Step 3 From the menu bar, choose Actions > New Track Object.

The system highlights the new tracked object row in the Summary pane, and tabs update in the Details pane.

Step 4 From the highlighted Track Object ID field, enter the object ID.

Step 5 From the Details pane, click the Object Tracking Details tab.

The Object Tracking Details tab appears.

Step 6 From the Object Tracking Details tab, in the Tracking Object Type drop-down list, choose Interface.

Step 7 From the Instance drop-down list, choose the interface that you want to track.

Step 8 From the Parameter drop-down list, choose IPv6 Routing.

Step 9 From the menu bar, choose File > Deploy to apply your changes to the device.

Deleting an Interface IPv6 Object Tracking

You can delete an interface IPv6 object tracking.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. no track object- id interface interface-type number { ipv6 routing }

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > Object Tracking .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure object tracking on.

Step 3 From the menu bar, choose Actions > New Track Object .

The system highlights the new tracked object row in the Summary pane, and tabs update in the Details pane.

Step 4 From the highlighted Track Object ID field, enter the object ID.

Step 5 From the Details pane, click the Object Tracking Details tab.

The Object Tracking Details tab appears.

Step 6 From the Object Tracking Details tab, in the Tracking Object Type drop-down list, choose Interface .

Step 7 From the Instance drop-down list, choose the interface that you want to track.

Step 8 From the Parameter drop-down list, choose IPv6 Routing .

Step 9 Right-click on IPv6 Routing, choose Track Object.

A pop-up dialog box appears.

Step 10 Choose Yes or No to apply your changes to the device.

RELATED TOPICS

- Configuring Object Tracking for an Interface

- Deleting an Interface IPv6 Object Tracking

- Creating a New IP Route IPv6 Object Tracking

- Deleting an IP Route IPv6 Object Tracking

- Configuring Object Tracking for Route Reachability

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

no track object-id interface interface-type number { ipv6 routing }

Example:

switch(config)# no track 1 interface ethernet 1/2 line-protocol

switch(config-track#

Deletes a tracked object for an interface. The object-id range is from 1 to 500.

This example shows how to delete object tracking for the IPv6 routing state on Ethernet 1/2:

switch# config t

switch(config)# no track 3 interface ethernet 1/2 ipv6 routing

switch(config-track)# copy running-config startup-config

Creating a New IP Route IPv6 Object Tracking

You can create a new IP route IPv6 object tracking.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. track object- id ipv6 route routev6 prefix

3. show track [ object- id ]

4. copy running-config startup-config

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > Object Tracking .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure object tracking on.

Step 3 From the menu bar, choose Actions > New Track Object .

The system highlights the new tracked object row in the Summary pane, and tabs update in the Details pane.

Step 4 From the highlighted Track Object ID field, enter the object ID.

Step 5 From the Details pane, click the Object Tracking Details tab.

The Object Tracking Details tab appears.

Step 6 From the Object Tracking Details tab, in the Tracking Object Type drop-down list, choose IP Route .

Step 7 In the Instance field, enter the prefix and network mask length that you want to track.

For IPv6, the format is A:B:C::D/length.

Step 8 (Optional) From the VRF name drop-down list, choose the VRF where this route exists.

The default is the default VRF.

Step 9 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Configuring Object Tracking for an Interface

- Deleting an Interface IPv6 Object Tracking

- Creating a New IP Route IPv6 Object Tracking

- Deleting an IP Route IPv6 Object Tracking

- Configuring Object Tracking for Route Reachability

- Viewing Client Details

Use the show run track command to display the IP route IPv6 object tracking configuration.

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

track object-id ipv6 route route prefix

Example:

switch# config t

switch(config-track)# track 1 ipv6 route 1::2/64 reachability

Creates a tracked object for IPv6 route and enters tracking configuration mode. The object-id range is from 1 to 500.

Step 3

track object-id vrf member vrf-name

Example:

switch(config-track)# track 1 vrf member abc

Creates a tracked object for nondefault VRF IP route IPv6. The object-id range is from 1 to 500.

Step 4

show track [ object-id ]

Example :

switch(config-track)# show track 1

Track 1

IPv6 Route 1::2/64 Reachability

Reachability is DOWN

0 changes, last change never

(Optional) Displays object tracking information.

Step 5

copy running-config startup-config

Example:

switch(config-track)# copy running-config startup-config

(Optional) Saves this configuration change.

Deleting an IP Route IPv6 Object Tracking

You can delete a IP route IPv6 object tracking.

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > Object Tracking .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure object tracking on.

Step 3 From the menu bar, choose Actions > New Track Object .

The system highlights the new tracked object row in the Summary pane, and tabs update in the Details pane.

Step 4 From the highlighted Track Object ID field, enter the object ID.

Step 5 From the Details pane, click the Object Tracking Details tab.

The Object Tracking Details tab appears.

Step 6 From the Object Tracking Details tab, in the Tracking Object Type drop-down list, choose Interface .

Step 7 From the Instance drop-down list, choose the interface that you want to track.

Step 8 From the Parameter drop-down list, choose IP Routing .

Step 9 Right-click and choose Track Object.

A pop-up dialog box appears.

Step 10 Choose Yes or No to apply your changes to the device.

RELATED TOPICS

- Configuring Object Tracking for an Interface

- Deleting an Interface IPv6 Object Tracking

- Creating a New IP Route IPv6 Object Tracking

- Deleting an IP Route IPv6 Object Tracking

- Configuring Object Tracking for Route Reachability

- Viewing Client Details

Configuring Object Tracking for Route Reachability

You can configure Cisco NX-OS to track the existence and reachability of an IP route.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. track object- id { ip | ipv6 } route prefix/length reachability

3. show track [ object- id ]

4. copy running-config startup-config

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > Object Tracking .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to configure object tracking on.

Step 3 From the menu bar, choose Actions > New Track Object .

The system highlights the new tracked object row in the Summary pane, and tabs update in the Details pane.

Step 4 From the highlighted Track Object ID field, enter the object ID.

Step 5 From the Details pane, click the Object Tracking Details tab.

The Object Tracking Details tab appears.

Step 6 From the Object Tracking Details tab, in the Tracking Object Type drop-down list, choose IP Route .

Step 7 In the Instance field, enter the prefix and network mask length that you want to track.

For IPv4, the format is A.B.C.D/length. For IPv6, the format is A:B:C::D/length.

Step 8 (Optional) From the VRF name drop-down list, choose the VRF where this route exists.

The default is the default VRF.

Step 9 From the menu bar, choose File > Deploy to apply your changes to the device.

RELATED TOPICS

- Configuring Object Tracking for an Interface

- Viewing Client Details

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

track object-id { ip | ipv6 } route prefix/length reachability

Example:

switch(config)# track 2 ip route 192.0.2.0/8 reachability

switch(config-track)#

Creates a tracked object for a route and enters tracking configuration mode. The object-id range is from 1 to 500. The prefix format for IP is A.B.C.D/length, where the length range is from 1 to 32. The prefix format for IPv6 is A:B::C:D/length, where the length range is from 1 to 128.

Step 3

show track [ object-id ]

Example :

switch(config-track)# show track 1

(Optional) Displays object tracking information.

Step 4

copy running-config startup-config

Example:

switch(config-track)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to configure object tracking for an IPv4 route in the default VRF.

switch# config t

switch(config)# track 4 ip route 192.0.2.0/8 reachability

switch(config-track)# copy running-config startup-config

This example shows how to configure object tracking for an IPv6 route in the default VRF.

switch# config t

switch(config)# track 5 ipv6 route 10::10/128 reachability

switch(config-track)# copy running-config startup-config

Configuring an Object Track List with a Boolean Expression

You can configure an object track list that contains multiple tracked objects. A tracked list contains one or more objects. The Boolean expression enables two types of calculation by using either "and" or "or" operators. For example, when tracking two interfaces using the "and" operator, up means that both interfaces are up, and down means that either interface is down.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. track track-number list boolean { and | or }

3. object object-number [ not ]

4. show track

5. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

track track-number list boolean { and | or }

Example:

switch(config)# track 1 list boolean and

switch(config-track#

Configures a tracked list object and enters tracking configuration mode. Specifies that the state of the tracked list is based on a Boolean calculation. The keywords are as follows:

- and —Specifies that the list is up if all objects are up, or down if one or more objects are down. For example when tracking two interfaces, up means that both interfaces are up, and down means that either interface is down.

- or —Specifies that the list is up if at least one object is up. For example, when tracking two interfaces, up means that either interface is up, and down means that both interfaces are down.

The track-number range is from 1 to 500.

Step 3

object object-id [ not ]

Example:

switch(config-track)# object 10

Adds a tracked object to the track list. The object-id range is from 1 to 500. The not keyword optionally negates the tracked object state.

Note The example means that when object 10 is up, the tracked list detects object 10 as down.

Step 4

show track

Example :

switch(config-track)# show track

(Optional) Displays object tracking information.

Step 5

copy running-config startup-config

Example:

switch(config-track)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to configure a track list with multiple objects as a Boolean “and”:

switch# config t

switch(config)# track 1 list boolean and

switch(config-track)# object 10

switch(config-track)# object 20 not

Configuring an Object Track List with a Percentage Threshold

You can configure an object track list that contains a percentage threshold. A tracked list contains one or more objects. The percentage of up objects must exceed the configured track list up percent threshold before the track list is in an up state. For example, if the tracked list has three objects, and you configure an up threshold of 60%, two of the objects must be in the up state (66% of all objects) for the track list to be in the up state.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. track track-number list threshold percentage

3. threshold percentage up up-value down down-value

4. object object-number

5. show track

6. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

track track-number list threshold percentage

Example:

switch(config)# track 1 list threshold percentage

switch(config-track#

Configures a tracked list object and enters tracking configuration mode. Specifies that the state of the tracked list is based on a configured threshold percent.

The track-number range is from 1 to 500.

Step 3

threshold percentage up up-value down down-value

Example:

switch(config-track)# threshold percentage up 70 down 30

Configures the threshold percent for the tracked list. The range from 0 to 100 percent.

Step 4

object object-id

Example:

switch(config-track)# object 10

Adds a tracked object to the track list. The object-id range is from 1 to 500.

Step 5

show track

Example :

switch(config-track)# show track

(Optional) Displays object tracking information.

Step 6

copy running-config startup-config

Example:

switch(config-track)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to configure a track list with an up threshold of 70% and a down threshold of 30%:

switch# config t

switch(config)# track 1 list threshold percentage

switch(config-track)# threshold percentage up 70 down 30

switch(config-track)# object 10

switch(config-track)# object 20

switch(config-track)# object 30

Configuring an Object Track List with a Weight Threshold

You can configure an object track list that contains a weight threshold. A tracked list contains one or more objects. The combined weight of up objects must exceed the configured track list up weight threshold before the track list is in an up state. For example, if the tracked list has three objects with the default weight of 10 each, and you configure an up threshold of 15, two of the objects must be in the up state (combined weight of 20) for the track list to be in the up state.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. track track-number list threshold weight

3. threshold weight up up-value down down-value

4. object object-number weight value

5. show track

6. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

track track-number list threshold weight

Example:

switch(config)# track 1 list threshold weight

switch(config-track#

Configures a tracked list object and enters tracking configuration mode. Specifies that the state of the tracked list is based on a configured threshold weight.

The track-number range is from 1 to 500.

Step 3

threshold weight up up-value down down-value

Example:

switch(config-track)# threshold weight up 30 down 10

Configures the threshold weight for the tracked list. The range from 1 to 255.

Step 4

object object-id weight value

Example:

switch(config-track)# object 10 weight 15

Adds a tracked object to the track list. The object-id range is from 1 to 500. The value range is from 1 to 255. The default weight value is 10.

Step 5

show track

Example :

switch(config-track)# show track

(Optional) Displays object tracking information.

Step 6

copy running-config startup-config

Example:

switch(config-track)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to configure a track list with an up weight threshold of 30 and a down threshold of 10:

switch# config t

switch(config)# track 1 list threshold weight

switch(config-track)# threshold weight up 30 down 10

switch(config-track)# object 10 weight 15

switch(config-track)# object 20 weight 15

switch(config-track)# object 30

In this example, the track list is up if object 10 and object 20 are up, and the track list goes to the down state if all three objects are down.

Configuring an Object Tracking Delay

You can configure a delay for a tracked object or an object track list that delays when the object or list triggers a stage change. The tracked object or track list starts the delay timer when a state change occurs but does not recognize a state change until the delay timer expires. At that point, Cisco NX-OS checks the object state again and records a state change only if the object or list currently has a changed state. Object tracking ignores any intermediate state changes before the delay timer expires.

For example, for an interface line-protocol tracked object that is in the up state with a 20 second donw delay, the delay timer starts when the line protocol goes down. The object is not in the down state unless the line protocol is down 20 seconds later.

You can configure independent up delay and down delay for a tracked object or track list. When you delete the delay , object tracking deletes both the up and down delay.

You can change the delay at any point. If the object or list is already counting down the delay timer from a triggered event, the new delay is computed as the following:

- If the new configuration value is less than the old configuration value, the timer starts with the new value.

- If the new configuration value is more than the old configuration value, the timer is calculated as the new configuration value minus the current timer countdown minus the old configuration value.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. track object- id { parameters }

or

track track-number list { parameters }

3. delay { up up-time [ down down-time ] | down down-time [ up up-time ]}

4. show track

5. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

track object-id { parameters }

Example:

switch(config)# track 2 ip route 192.0.2.0/8 reachability

switch(config-track)#

Creates a tracked object for a route and enters tracking configuration mode. The object-id range is from 1 to 500. The prefix format for IP is A.B.C.D/length, where the length range is from 1 to 32. The prefix format for IPv6 is A:B::C:D/length, where the length range is from 1 to 128.

Step 3

track track-number list { parameters }

Example:

switch(config)# track 1 list threshold weight

switch(config-track#

Configures a tracked list object and enters tracking configuration mode. Specifies that the state of the tracked list is based on a configured threshold weight.

The track-number range is from 1 to 500.

Step 4

delay { up up-time [ down down-time ] | down down-time [ up up-time ]}

Example :

switch(config-track)# delay up 20 down 30

Configures the object delay timers. The range is from 0 to 180 seconds.

Step 5

show track

Example :

switch(config-track)# show track 3

(Optional) Displays object tracking information.

Step 6

copy running-config startup-config

Example:

switch(config-track)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to configure object tracking for a route and use delay timers:

switch# config t

switch(config)# track 2 ip route 209.165.201.0/8 reachability

switch(config-track)# delay up 20 down 30

switch(config-track)# copy running-config startup-config

This example shows how to configure a track list with an up weight threshold of 30 and a down threshold of 10 with delay timers:

switch# config t

switch(config)# track 1 list threshold weight

switch(config-track)# threshold weight up 30 down 10

switch(config-track)# object 10 weight 15

switch(config-track)# object 20 weight 15

switch(config-track)# object 30

switch(config-track)# delay up 20 down 30

This example shows the delay timer in the show track command output before and after an interface is shut down:

switch(config-track)# show track

Track 1

Interface loopback1 Line Protocol

Line Protocol is UP

1 changes, last change 00:00:13

Delay down 10 secs

qadc3-fhrp-ind45(config-track)# interface loopback 1

qadc3-fhrp-ind45(config-if)# shutdown

qadc3-fhrp-ind45(config-if)# show track

Track 1

Interface loopback1 Line Protocol

Line Protocol is delayed DOWN (8 secs remaining) <------- delay timer counting down

1 changes, last change 00:00:22

Delay down 10 secs

Configuring Object Tracking for a Nondefault VRF

You can configure Cisco NX-OS to track an object in a specific VRF.

BEFORE YOU BEGIN

Ensure that you are in the correct VDC (or use the switchto vdc command).

SUMMARY STEPS

1. config t

2. track object- id { ip | ipv6 } route prefix/length reachability

3. vrf member vrf-name

4. show track [ object- id ]

5. copy running-config startup-config

DETAILED STEPS

Command

Purpose

Step 1

config t

Example:

switch# config t

switch(config)#

Enters configuration mode.

Step 2

track object-id { ip | ipv6 } route prefix/length reachability

Example:

switch(config)# track 2 ip route 192.0.2.0/8 reachability

switch(config-track)#

Creates a tracked object for a route and enters tracking configuration mode. The object-id range is from 1 to 500. The prefix format for IP is A.B.C.D/length, where the length range is from 1 to 32. The prefix format for IPv6 is A:B::C:D/length, where the length range is from 1 to 128.

Step 3

vrf member vrf-name

Example :

switch(config-track)# vrf member Red

Configures the VRF to use for tracking the configured object.

Step 4

show track [ object-id ]

Example :

switch(config-track)# show track 3

(Optional) Displays object tracking information.

Step 5

copy running-config startup-config

Example:

switch(config-track)# copy running-config startup-config

(Optional) Saves this configuration change.

This example shows how to configure object tracking for a route and use VRF Red to look up reachability information for this object:

switch# config t

switch(config)# track 2 ip route 209.165.201.0/8 reachability

switch(config-track)# vrf member Red

switch(config-track)# copy running-config startup-config

This example shows how to modify tracked object 2 to use VRF Blue instead of VRF RED to look up reachability information for this object:

switch# config t

switch(config)# track 2

switch(config-track)# vrf member Blue

switch(config-track)# copy running-config startup-config

Verifying the Object Tracking Configuration

To display object tracking configuration information, perform one the following tasks:

Command

Purpose

show track [ object-id ] [ brief ]

Displays the object tracking information for one or more objects.

show track [ object-id ] interface [ brief ]

Displays the interface-based object tracking information.

show track [ object-id ] { ip | ipv6 } route [ brief ]

Displays the IPv4 or IPv6 route-based object tracking information.

show trun track

Displays the IP route IPv6 object tracking configuration information.

Viewing Client Details

You can view client details for a tracked object.

DETAILED STEPS

Step 1 From the Feature Selector pane, choose Routing > Gateway Redundancy > Object Tracking .

The available devices appear in the Summary pane.

Step 2 From the Summary pane, click the device that you want to view tracked objects on.

Step 3 Click the tracked object that you want to view clients for.

The system highlights the tracked object row in the Summary pane, and tabs update in the Details pane.

Step 4 From the Details pane, click the Object Tracking Details tab.

The Object Tracking Details tab appears.

Step 5 From the Object Tracking Details tab, click the Client Details section.

The client details appear.

RELATED TOPICS

- Configuring Object Tracking for an Interface

- Configuring Object Tracking for Route Reachability

Configuration Examples for Object Tracking

This example shows how to configure object tracking for route reachability and use VRF Red to look up reachability information for this route:

switch# config t

switch(config)# track 2 ip route 209.165.201.0/8 reachability

switch(config-track)# vrf member Red

switch(config-track)# copy running-config startup-config

Related Topics

See the following topics for information related to object tracking:

- Chapter 4, “Configuring GLBP”

- Chapter 5, “Configuring HSRP”

Field Descriptions for Object Tracking

This section includes the following field descriptions for Object Tracking:

- Object Tracking: Details Tab: Object Tracking Details Section

- Object Tracking: Details Tab: Client Details Section

Object Tracking: Details Tab: Object Tracking Details Section

Table 6-2 Object Tracking: Details: Object Tracking Details

Field

Description

Track Object ID

Display only. Object number for the tracked object.

Tracking Object Type

Type of object to track.

Instance

IPv4 or IPv6 address or interface to track for this object.

VRF

VRF that the tracked interface exists in.

Parameter

Parameter type to track for this object.

Tracking Status

Display only. Status of the tracked object parameter.

Last status Change Time

Display only. Time the parameter last changed status for this object.

Object Tracking: Details Tab: Client Details Section

Table 6-3 Object Tracking: Details: Client Details

Field

Description

Client Name

Display only. Name of the feature that uses this tracked object.

Client Interface

Interface that uses this tracked object for the named client feature.

Client Group-ID

Display only. ID for the group that uses this tracked object for the named client feature.

Additional References

For additional information related to implementing object tracking, see the following sections:

- Related Documents

- Standards

Related Documents

Related Topic

Document Title

Object Tracking CLI commands

Cisco Nexus 7000 Series NX-OS Unicast Routing Command Reference

Configuring the Embedded Event Manager

Cisco Nexus 7000 Series NX-OS System Management Configuration Guide, Release 5.x

Standards

Standards

Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.

—

Feature History for Object Tracking

Table 6-4 lists the release history for this feature.

Table 6-4 Feature History for Object Tracking

Feature Name

Releases

Feature Information

IPv6 support

5.0(2)

Added support for IPv6.

Tracking delay

4.2(4)

Added support for delaying a tracked object update.

Object track list

4.2(1)

Added support for object track lists and Boolean expressions.

Object tracking

4.0(1)

This feature was introduced.

IETF RFCs supported by Cisco NX-OS Unicast Features, Release 7.0x

This appendix lists the IETF RFCs supported in Cisco NX-OS Release 7.0.x.

BGP RFCs

RFCs

Title

RFC 1997

BGP Communities Attribute

RFC 2385

Protection of BGP Sessions via the TCP MD5 Signature Option

RFC 2439

BGP Route Flap Damping

RFC 2519

A Framework for Inter-Domain Route Aggregation

RFC 2545

Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing

RFC 2858

Multiprotocol Extensions for BGP-4

RFC 3065

Autonomous System Confederations for BGP

RFC 3392

Capabilities Advertisement with BGP-4

RFC 4271

A Border Gateway Protocol 4 (BGP-4)

RFC 4273

Definitions of Managed Objects for BGP-4

RFC 4456

BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)

RFC 4486

Subcodes for BGP Cease Notification Message

RFC 4724

Graceful Restart Mechanism for BGP

RFC 4893

BGP Support for Four-octet AS Number Space

RFC 5004

Avoid BGP Best Path Transitions from One External to Another

draft-ietf-idr-bgp4-mib-15.txt

BGP4-MIB

draft-kato-bgp-ipv6-link-local-00.txt

BGP4+ Peering Using IPv6 Link-local Address

First-Hop Redundancy Protocols RFCs

RFCs

Title

RFC 2281

Hot Standby Redundancy Protocol

RFC 3768

Virtual Router Redundancy Protocol

IP Services RFCs

RFCs

Title

RFC 786

UDP

RFC 791

IP

RFC 792

ICMP

RFC 793

TCP

RFC 826

ARP

RFC 1027

Proxy ARP

RFC 1591

DNS Client

RFC 1812

IPv4 routers

IPv6 RFCs

RFCs

Title

RFC 1981

Path MTU Discovery for IP version 6

RFC 2373

IP Version 6 Addressing Architecture

RFC 2374

An Aggregatable Global Unicast Address Format

RFC 2460

Internet Protocol, Version 6 (IPv6) Specification

RFC 2461

Neighbor Discovery for IP Version 6 (IPv6)

RFC 2462

IPv6 Stateless Address Autoconfiguration

RFC 2463

Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

RFC 2464

Transmission of IPv6 Packets over Ethernet Networks

RFC 3152

Delegation of IP6.ARPA

RFC 3162

RADIUS and IPv6

RFC 3513

Internet Protocol Version 6 (IPv6) Addressing Architecture

RFC 3596

DNS Extensions to Support IP version 6

RFC 4193

Unique Local IPv6 Unicast Addresses

IS-IS RFCs

RFCs

Title

RFC 1142

OSI 10589 Intermediate system to intermediate system intra-domain routing exchange protocol

RFC 1195

Use of OSI IS-IS for routing in TCP/IP and dual environment

RFC 2763

Dynamic Hostname Exchange Mechanism for IS-IS

RFC 2966

Domain-wide Prefix Distribution with Two-Level IS-IS

RFC 2972

IS-IS Mesh Groups

RFC 3273

Three-Way Handshake for IS-IS Point-to-Point Adjacencies

RFC 3277

IS-IS Transient Blackhole Avoidance

RFC 3567

IS-IS Cryptographic Authentication

RFC 3847

Restart Signaling for IS-IS

draft-ietf-isis-igp-p2p-over-lan-06.txt

Internet Draft Point-to-point operation over LAN in link-state routing protocols

OSPF RFCs

RFCs

Title

RFC 2328

OSPF Version 2

RFC 2740

OSPF for IPv6

RFC 3623

Graceful OSPF Restart

RFC 3101

The OSPF Not-So-Stubby Area (NSSA) Option

RFC 2370

The OSPF Opaque LSA Option

RFC 3137

OSPF Stub Router Advertisement

draft-ietf-ospf-ospfv3-graceful-restart-04.txt

OSPFv3 Graceful Restart

RIP RFCs

RFCs

Title

RFC 2453

RIP Version 2

RFC 2082

RIP-2 MD5 Authentication

Cisco Prime DCNM Unicast Management Guide, Release 7.0.x

April, 2015

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2015 Cisco Systems, Inc. All rights reserved.