|
Table Of Contents
Configuring IP Unicast Routing
Default Addressing Configuration
Assigning IP Addresses to Network Interfaces
Configuring Address Resolution Methods
Routing Assistance When IP Routing is Disabled
ICMP Router Discovery Protocol (IRDP)
Configuring Broadcast Packet Handling
Enabling Directed Broadcast-to-Physical Broadcast Translation
Forwarding UDP Broadcast Packets and Protocols
Establishing an IP Broadcast Address
Monitoring and Maintaining IP Addressing
Configuring Basic RIP Parameters
Configuring RIP Authentication
Configuring Basic OSPF Parameters
Configuring OSPF Network Types
Configuring OSPF for Nonbroadcast Networks
Configuring Network Types for OSPF Interfaces
Configuring OSPF Area Parameters
Configuring Other OSPF Parameters
Configuring a Loopback Interface
Configuring Basic EIGRP Parameters
Configuring EIGRP Route Authentication
Configuring EIGRP Stub Routing
Monitoring and Maintaining EIGRP
Managing Routing Policy Changes
BFD Support for Static Routing
Configuring BGP Decision Attributes
Configuring BGP Filtering with Route Maps
Configuring BGP Filtering by Neighbor
Configuring Prefix Lists for BGP Filtering
Configuring BGP Community Filtering
Configuring BGP Neighbors and Peer Groups
Configuring Aggregate Addresses
Configuring Routing Domain Confederations
Monitoring and Maintaining BGP
Configuring IS-IS Dynamic Routing
Configuring IS-IS Global Parameters
Configuring IS-IS Interface Parameters
Monitoring and Maintaining IS-IS
Default BFD Configuration Guidelines
Configuring BFD Session Parameters on an Interface
Enabling BFD Routing Protocol Clients
Configuring BFD for Port-Channel
Configuring BFD Support for SVI
Configuring BFD Support for Static Routing
Configuring BFD Support for RIP
Default Multi-VRF CE Configuration
Multi-VRF CE Configuration Guidelines
Configuring VRF-Aware Services
User Interface for FTP and TFTP
Configuring a VPN Routing Session
Configuring BGP PE to CE Routing Sessions
Multi-VRF CE Configuration Example
Displaying Multi-VRF CE Status
Configuring Protocol-Independent Features
Configuring Cisco Express Forwarding
Configuring the Number of Equal-Cost Routing Paths
Configuring Static Unicast Routes
Specifying Default Routes and Networks
Using Route Maps to Redistribute Routing Information
Controlling Advertising and Processing in Routing Updates
Filtering Sources of Routing Information
Monitoring and Maintaining the IP Network
Configuring IP Unicast Routing
This chapter describes how to configure IP Version 4 (IPv4) unicast routing on the Cisco ME 3800X and ME 3600X switch. For more detailed IPv4 unicast configuration information, see the IP Addressing: IPv4 Addressing Configuration Guide, Cisco IOS Release 15.x. For complete syntax and usage information for the commands used in this chapter, see Cisco IOS IP Addressing Services Command Reference.
This chapter has these sections:
•Steps for Configuring Routing
•Enabling IPv4 Unicast Routing
•Configuring Protocol-Independent Features
•Monitoring and Maintaining the IP Network
Understanding IP Routing
In an IP network, each subnetwork is mapped to an individual VLAN. However, network devices in different VLANs cannot communicate with one another without a Layer 3 device (router) to route traffic between the VLAN, referred to as inter-VLAN routing. You configure one or more routers to route traffic to the appropriate destination VLAN.
Figure 37-1 shows a basic routing topology. Switch A is in VLAN 10, and Switch B is in VLAN 20. The router has an interface in each VLAN.
Figure 37-1 Routing Topology Example
When Host A in VLAN 10 needs to communicate with Host B in VLAN 10, it sends a packet addressed to that host. Switch A forwards the packet directly to Host B, without sending it to the router.
When Host A sends a packet to Host C in VLAN 20, Switch A forwards the packet to the router, which receives the traffic on the VLAN 10 interface. The router checks the routing table, finds the correct outgoing interface, and forwards the packet on the VLAN 20 interface to Switch B. Switch B receives the packet and forwards it to Host C.
Types of Routing
Routers and Layer 3 switches can route packets in three different ways:
•By using default routing—sending traffic with a destination unknown to the router to a default outlet or destination.
•By using preprogrammed static routes for the traffic
Static unicast routing forwards packets from predetermined ports through a single path into and out of a network. Static routing does not automatically respond to changes in the network and therefore, might result in unreachable destinations.
•By dynamically calculating routes by using a routing protocol
Steps for Configuring Routing
By default, IPv4 routing is disabled on the switch, and you must enable it before routing can take place. For detailed IP routing configuration information, see the Cisco IOS IP Configuration Guide, Release 12.2
In the following procedures, the specified interface must be one of these Layer 3 interfaces:
•A routed port: a physical port configured as a Layer 3 port by using the no switchport interface configuration command.
•A switch virtual interface (SVI): a VLAN interface created by using the interface vlan vlan_id global configuration command and by default a Layer 3 interface.
•An EtherChannel port channel in Layer 3 mode: a port-channel logical interface created by using the interface port-channel port-channel-number global configuration command and binding the Ethernet interface into the channel group. For more information, see the "Configuring Layer 3 EtherChannels" section.
Note The switch does not support tunnel interfaces for unicast routed traffic.
All Layer 3 interfaces on which routing will occur must have IP addresses assigned to them. See the "Assigning IP Addresses to Network Interfaces" section.
Configuring IPv4g routing consists of several main procedures:
•To support VLAN interfaces, create and configure VLANs on the switch, and assign VLAN membership to Layer 2 interfaces. For more information, see Chapter 11 "Configuring VLANs."
•Configure Layer 3 interfaces.
•Enable IPv4 routing on the switch.
•Assign IPv4 addresses to the Layer 3 interfaces.
•Enable selected routing protocols on the switch.
•Configure routing protocol parameters (optional).
Configuring IP Addressing
IP routing requires that Layer 3 network interfaces are assigned IP addresses to enable the interfaces and to allow communication with the hosts on interfaces that use IP. These sections describe how to configure various IP addressing features. Assigning IP addresses to the interface is required; the other procedures are optional.
•Default Addressing Configuration
•Assigning IP Addresses to Network Interfaces
•Configuring Address Resolution Methods
•Routing Assistance When IP Routing is Disabled
•Configuring Broadcast Packet Handling
•Monitoring and Maintaining IP Addressing
Default Addressing Configuration
Assigning IP Addresses to Network Interfaces
An IP address identifies a location to which IP packets can be sent. An interface can have one primary IP 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 referred to as a subnet mask. To receive an assigned network number, contact your Internet service provider.
Beginning in privileged EXEC mode, follow these steps to assign an IP address and a network mask to a Layer 3 interface:
Use of Subnet Zero
Subnetting with a subnet address of zero is strongly discouraged because of the problems that can arise if a network and a subnet have the same addresses. For example, if network 131.108.0.0 is subnetted as 255.255.255.0, subnet zero would be written as 131.108.0.0, which is the same as the network address.
You can use the all ones subnet (131.108.255.0) and even though it is discouraged, you can enable the use of subnet zero if you need the entire subnet space for your IP address.
Beginning in privileged EXEC mode, follow these steps to enable subnet zero:
Use the no ip subnet-zero global configuration command to restore the default and disable the use of subnet zero.
Classless Routing
By default, classless routing behavior is enabled on the switch when it is configured to route. With classless routing, if a router receives packets for a subnet of a network with no default route, the router forwards the packet to the best supernet route. A supernet consists of contiguous blocks of Class C address spaces used to simulate a single, larger address space and is designed to relieve the pressure on the rapidly depleting Class B address space.
In Figure 37-2, classless routing is enabled. When the host sends a packet to 120.20.4.1, instead of discarding the packet, the router forwards it to the best supernet route. If you disable classless routing and a router receives packets destined for a subnet of a network with no network default route, the router discards the packet.
Figure 37-2 IP Classless Routing
In Figure 37-3, the router in network 128.20.0.0 is connected to subnets 128.20.1.0, 128.20.2.0, and 128.20.3.0. If the host sends a packet to 120.20.4.1, because there is no network default route, the router discards the packet.
Figure 37-3 No IP Classless Routing
To prevent the switch from forwarding packets destined for unrecognized subnets to the best supernet route possible, you can disable classless routing behavior.
Beginning in privileged EXEC mode, follow these steps to disable classless routing:
To restore the default and have the switch forward packets destined for a subnet of a network with no network default route to the best supernet route possible, use the ip classless global configuration command.
Configuring Address Resolution Methods
You can control interface-specific handling of IP by using address resolution. A device using IP can have both a local address or MAC address, which uniquely defines the device on its local segment or LAN, and a network address, which identifies the network to which the device belongs. To communicate with a device on Ethernet, the software must learn the MAC address of the device. The process of learning the MAC address from an IP address is called address resolution. The process of learning the IP address from the MAC address is called reverse address resolution.
The switch can use these forms of address resolution:
•Address Resolution Protocol (ARP) is used to associate IP address with MAC addresses. Taking an IP address as input, ARP learns the associated MAC address and then stores the IP address/MAC address association in an ARP cache for rapid retrieval. Then the IP datagram is encapsulated in a link-layer frame and sent over the network. Encapsulation of IP datagrams and ARP requests or replies on IEEE 802 networks other than Ethernet is specified by the Subnetwork Access Protocol (SNAP).
•Proxy ARP helps hosts with no routing tables learn the MAC addresses of hosts on other networks or subnets. If the switch (router) receives an ARP request for a host that is not on the same interface as the ARP request sender, and if the router has all of its routes to the host through other interfaces, it generates a proxy ARP packet giving its own local data link address. The host that sent the ARP request then sends its packets to the router, which forwards them to the intended host.
The switch also uses the Reverse Address Resolution Protocol (RARP), which functions the same as ARP does, except that the RARP packets request an IP address instead of a local MAC address. Using RARP requires a RARP server on the same network segment as the router interface. Use the ip rarp-server address interface configuration command to identify the server.
For more information on RARP, see the IP Addressing: ARP Configuration Guide, Cisco IOS Release 15.x.
You can perform these tasks to configure address resolution:
Define a Static ARP Cache
ARP and other address resolution protocols provide dynamic mapping between IP addresses and MAC addresses. Because most hosts support dynamic address resolution, you usually do not need to specify static ARP cache entries. If you must define a static ARP cache entry, you can do so globally, which installs a permanent entry in the ARP cache that the switch uses to translate IP addresses into MAC addresses. Optionally, you can also specify that the switch respond to ARP requests as if it were the owner of the specified IP address. If you do not want the ARP entry to be permanent, you can specify a timeout period for the ARP entry.
Beginning in privileged EXEC mode, follow these steps to provide static mapping between IP addresses and MAC addresses:
To remove an entry from the ARP cache, use the no arp ip-address hardware-address type global configuration command. To remove all nonstatic entries from the ARP cache, use the clear arp-cache privileged EXEC command.
Set ARP Encapsulation
By default, Ethernet ARP encapsulation (represented by the arpa keyword) is enabled on an IP interface. You can change the encapsulation methods to SNAP if required by your network.
Beginning in privileged EXEC mode, follow these steps to specify the ARP encapsulation type:
To disable an encapsulation type, use the no arp arpa or no arp snap interface configuration command.
Enable Proxy ARP
By default, the switch uses proxy ARP to help hosts learn MAC addresses of hosts on other networks or subnets.
Beginning in privileged EXEC mode, follow these steps to enable proxy ARP if it has been disabled:
To disable proxy ARP on the interface, use the no ip proxy-arp interface configuration command.
Routing Assistance When IP Routing is Disabled
These mechanisms allow the switch to learn about routes to other networks when it does not have IP routing enabled:
•ICMP Router Discovery Protocol (IRDP)
Proxy ARP
Proxy ARP, the most common method for learning about other routes, enables an Ethernet host with no routing information to communicate with hosts on other networks or subnets. The host assumes that all hosts are on the same local Ethernet and that they can use ARP to learn their MAC addresses. If a switch receives an ARP request for a host that is not on the same network as the sender, the switch evaluates whether it has the best route to that host. If it does, it sends an ARP reply packet with its own Ethernet MAC address, and the host that sent the request sends the packet to the switch, which forwards it to the intended host. Proxy ARP treats all networks as if they are local and performs ARP requests for every IP address.
Proxy ARP is enabled by default. To enable it after it has been disabled, see the "Enable Proxy ARP" section. Proxy ARP works as long as other routers support it.
Default Gateway
Another method for locating routes is to define a default router or default gateway. All nonlocal packets are sent to this router, which either routes them appropriately or sends an IP Control Message Protocol (ICMP) redirect message back, defining which local router the host should use. The switch caches the redirect messages and forwards each packet as efficiently as possible. A limitation of this method is that there is no means of detecting when the default router has gone down or is unavailable.
Beginning in privileged EXEC mode, follow these steps to define a default gateway (router) when IP routing is disabled:
Use the no ip default-gateway global configuration command to disable this function.
ICMP Router Discovery Protocol (IRDP)
Router discovery allows the switch to dynamically learn about routes to other networks using IRDP. IRDP allows hosts to locate routers. When operating as a client, the switch generates router discovery packets. When operating as a host, the switch receives router discovery packets. The switch can also listen to Routing Information Protocol (RIP) routing updates and use this information to infer locations of routers. The switch does not actually store the routing tables sent by routing devices; it merely keeps track of which systems are sending the data. The advantage of using IRDP is that it allows each router to specify both a priority and the time after which a device is assumed to be down if no further packets are received.
Each device discovered becomes a candidate for the default router, and a new highest-priority router is selected when a higher priority router is discovered, when the current default router is declared down, or when a TCP connection is about to time out because of excessive retransmissions.
The only required task for IRDP routing on an interface is to enable IRDP processing on that interface. When enabled, the default parameters apply. You can optionally change any of these parameters.
Beginning in privileged EXEC mode, follow these steps to enable and configure IRDP on an interface:
If you change the maxadvertinterval value, the holdtime and minadvertinterval values also change, so it is important to first change the maxadvertinterval value, before manually changing either the holdtime or minadvertinterval values.
Use the no ip irdp interface configuration command to disable IRDP routing.
Configuring Broadcast Packet Handling
After configuring an IP interface address, you can enable routing and configure one or more routing protocols, or you can configure the way the switch responds to network broadcasts. A broadcast is a data packet destined for all hosts on a physical network. The switch supports two kinds of broadcasting:
•A directed broadcast packet is sent to a specific network or series of networks. A directed broadcast address includes the network or subnet fields.
•A flooded broadcast packet is sent to every network.
Note You can also limit broadcast, unicast, and multicast traffic on Layer 2 interfaces by using the storm-control interface configuration command to set traffic suppression levels. For more information, see Chapter 24 "Configuring Traffic Control."
Routers provide some protection from broadcast storms by limiting their extent to the local cable. Bridges (including intelligent bridges), because they are Layer 2 devices, forward broadcasts to all network segments, thus propagating broadcast storms. The best solution to the broadcast storm problem is to use a single broadcast address scheme on a network. In most modern IP implementations, you can set the address to be used as the broadcast address. The switch supports several addressing schemes for forwarding broadcast messages.
•Enabling Directed Broadcast-to-Physical Broadcast Translation
•Forwarding UDP Broadcast Packets and Protocols
•Establishing an IP Broadcast Address
Enabling Directed Broadcast-to-Physical Broadcast Translation
By default, IP-directed broadcasts are not forwarded; they are dropped to make routers less susceptible to denial-of-service attacks. You can enable forwarding of IP-directed broadcasts on an interface where the broadcast becomes a physical (MAC-layer) broadcast. Only those protocols configured by using the ip forward-protocol global configuration command are forwarded.
You can specify an access list to control which broadcasts are forwarded. Only those IP packets permitted by the access list are eligible to be translated from directed broadcasts to physical broadcasts. For more information on access lists, see Chapter 31 "Configuring Network Security with ACLs."
Beginning in privileged EXEC mode, follow these steps to enable forwarding of IP-directed broadcasts on an interface:
Use the no ip directed-broadcast interface configuration command to disable translation of directed broadcast to physical broadcasts. Use the no ip forward-protocol global configuration command to remove a protocol or port.
Forwarding UDP Broadcast Packets and Protocols
User Datagram Protocol (UDP) is an IP host-to-host layer protocol that provides a low-overhead, connectionless session between two end systems and does not provide for acknowledgment of received datagrams. Network hosts occasionally use UDP broadcasts to find address, configuration, and name information. If such a host is on a network segment that does not include a server, UDP broadcasts are normally not forwarded. You can configure an interface on a router to forward certain classes of broadcasts to a helper address. You can use more than one helper address per interface.
You can specify a UDP destination port to control which UDP services are forwarded. You can specify multiple UDP protocols. You can also specify the Network Disk (ND) protocol, which is used by older diskless Sun workstations and the network security protocol SDNS.
By default, both UDP and ND forwarding are enabled if a helper address has been defined for an interface. The description for the ip forward-protocol interface configuration command in the Cisco IOS IP Application Services Command Reference lists the ports that are forwarded by default if you do not specify any UDP ports.
If you do not specify any UDP ports when you configure the forwarding of UDP broadcasts, you are configuring the router to act as a BOOTP forwarding agent. BOOTP packets carry DHCP information.
Beginning in privileged EXEC mode, follow these steps to enable forwarding UDP broadcast packets on an interface and specify the destination address:
Use the no ip helper-address interface configuration command to disable the forwarding of broadcast packets to specific addresses. Use the no ip forward-protocol global configuration command to remove a protocol or port.
Establishing an IP Broadcast Address
The most popular IP broadcast address (and the default) is an address consisting of all ones (255.255.255.255). However, the switch can be configured to generate any form of IP broadcast address.
Beginning in privileged EXEC mode, follow these steps to set the IP broadcast address on an interface:
To restore the default IP broadcast address, use the no ip broadcast-address interface configuration command.
Flooding IP Broadcasts
You can allow IP broadcasts to be flooded throughout your internetwork in a controlled fashion by using the database created by the bridging STP. Using this feature also prevents loops. To support this capability, bridging must be configured on each interface that is to participate in the flooding. If bridging is not configured on an interface, the interface can receive broadcasts but it never forwards the broadcasts it receives, and the router never uses that interface to send broadcasts received on a different interface.
Packets that are forwarded to a single network address using the IP helper-address mechanism can be flooded. Only one copy of the packet is sent on each network segment.
To be considered for flooding, packets must meet these criteria. (Note that these are the same conditions used to consider packet forwarding using IP helper addresses.)
•The packet must be a MAC-level broadcast.
•The packet must be an IP-level broadcast.
•The packet must be a TFTP, DNS, Time, NetBIOS, ND, or BOOTP packet, or a UDP specified by the ip forward-protocol udp global configuration command.
•The time-to-live (TTL) value of the packet must be at least two.
A flooded UDP datagram is given the destination address specified with the ip broadcast-address interface configuration command on the output interface. The destination address can be set to any address so it might change as the datagram propagates through the network. The source address is never changed. The TTL value is decremented.
When a flooded UDP datagram is sent out an interface (and the destination address possibly changed), the datagram is handed to the normal IP output routines and is, therefore, subject to access lists, if they are present on the output interface.
Beginning in privileged EXEC mode, follow these steps to use the bridging spanning-tree database to flood UDP datagrams:
Use the no ip forward-protocol spanning-tree global configuration command to disable the flooding of IP broadcasts.
In the switch, the majority of packets are forwarded in hardware; most packets do not go through the switch CPU. For those packets that do go to the CPU, you can speed up spanning tree-based UDP flooding by a factor of about four to five times by using turbo-flooding. This feature is supported over Ethernet interfaces configured for ARP encapsulation.
Beginning in privileged EXEC mode, follow these steps to increase spanning-tree-based flooding:
To disable this feature, use the no ip forward-protocol turbo-flood global configuration command.
Monitoring and Maintaining IP Addressing
When the contents of a particular cache, table, or database have become or are suspected to be invalid, you can remove all its contents by using the clear privileged EXEC commands.
You can display specific statistics, such as the contents of IP routing tables, caches, and databases; the reachability of nodes; and the routing path that packets are taking through the network.
Enabling IPv4 Unicast Routing
By default, the switch is in Layer 2 switching mode and IP routing is disabled. To use the Layer 3 capabilities of the switch, you must enable IP routing.
Beginning in privileged EXEC mode, follow these steps to enable IP routing:
Use the no ip routing global configuration command to disable routing.
This example shows how to enable IP routing using RIP as the routing protocol:
Switch# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Switch(config)# ip routingSwitch(config)# router ripSwitch(config-router)# network 10.0.0.0Switch(config-router)# endYou can now set up parameters for the selected routing protocols as described in these sections:
•Configuring Protocol-Independent Features (optional)
Configuring RIP
The Routing Information Protocol (RIP) is an interior gateway protocol (IGP) used in small, homogeneous networks. It is a distance-vector routing protocol that uses broadcast User Datagram Protocol (UDP) data packets to exchange routing information. You can find detailed information about RIP in IP Routing Fundamentals, published by Cisco Press.
Using RIP, the switch sends routing information updates (advertisements) every 30 seconds. If a router does not receive an update from another router for 180 seconds or more, it marks the routes served by that router as unusable. If there is still no update after 240 seconds, the router removes all routing table entries for the non-updating router.
RIP uses hop counts to rate the value of different routes. The hop count is the number of routers that can be traversed in a route. A directly connected network has a hop count of zero; a network with a hop count of 16 is unreachable. This small range (0 to 15) makes RIP unsuitable for large networks.
If the router has a default network path, RIP advertises a route that links the router to the pseudonetwork 0.0.0.0. The 0.0.0.0 network does not exist, but is treated by RIP as a network to implement default routing. The switch advertises the default network if a default was learned by RIP or if the router has a gateway of last resort and RIP is configured with a default metric. RIP sends updates to the interfaces in specified networks. If an interface's network is not specified, it is not advertised in any RIP update.
These sections contain this configuration information:
•Configuring Basic RIP Parameters
•Configuring RIP Authentication
Default RIP Configuration
Configuring Basic RIP Parameters
To configure RIP, you enable RIP routing for a network and optionally configure other parameters. On the Cisco ME switch, RIP configuration commands are ignored until you configure the network number.
Beginning in privileged EXEC mode, follow these steps to enable and configure RIP:
To turn off the RIP routing process, use the no router rip global configuration command.
To display the parameters and current state of the active routing protocol process, use the show ip protocols privileged EXEC command. Use the show ip rip database privileged EXEC command to display summary address entries in the RIP database.
Configuring RIP Authentication
RIP Version 1 does not support authentication. If you are sending and receiving RIP Version 2 packets, you can enable RIP authentication on an interface. The key chain specifies the set of keys that can be used on the interface. If a key chain is not configured, no authentication is performed, not even the default. Therefore, you must also perform the tasks in the "Managing Authentication Keys" section.
The switch supports two modes of authentication on interfaces for which RIP authentication is enabled: plain text and MD5. The default is plain text.
Beginning in privileged EXEC mode, follow these steps to configure RIP authentication on an interface:
To restore clear text authentication, use the no ip rip authentication mode interface configuration command. To prevent authentication, use the no ip rip authentication key-chain interface configuration command.
Configuring Split Horizon
Routers connected to broadcast-type IP networks and using distance-vector routing protocols normally use the split-horizon mechanism to reduce the possibility of routing loops. Split horizon blocks information about routes from being advertised by a router on any interface from which that information originated. This feature can optimize communication among multiple routers when links are broken.
Note In general, Cisco does not recommend disabling split horizon unless you are certain that your application requires it to properly advertise routes.
Beginning in privileged EXEC mode, follow these steps to disable split horizon on the interface:
To enable the split horizon mechanism, use the ip split-horizon interface configuration command.
Configuring Summary Addresses
To configure an interface running RIP to advertise a summarized local IP address pool on a network access server for dial-up clients, use the ip summary-address rip interface configuration command.
Note If split horizon is enabled, neither autosummary nor interface IP summary addresses are advertised.
Beginning in privileged EXEC mode, follow these steps to set an interface to advertise a summarized local IP address and to disable split horizon on the interface:
To disable IP summarization, use the no ip summary-address rip router configuration command.
In this example, the major net is 10.0.0.0. The summary address 10.2.0.0 overrides the autosummary address of 10.0.0.0 so that 10.2.0.0 is advertised out interface Gigabit Ethernet port 2, and 10.0.0.0 is not advertised. If the interface is in Layer 2 mode (the default), you must enter a no switchport interface configuration command before entering the ip address interface configuration command.
Note If split horizon is enabled, neither autosummary nor interface summary addresses (those configured with the ip summary-address rip router configuration command) are advertised.
Switch(config)# router ripSwitch(config-router)# interface gi0/2Switch(config-if)# no switchportSwitch(config-if)# ip address 10.1.5.1 255.255.255.0Switch(config-if)# ip summary-address rip 10.2.0.0 255.255.0.0Switch(config-if)# no ip split-horizonSwitch(config-if)# exitSwitch(config)# router ripSwitch(config-router)# network 10.0.0.0Switch(config-router)# neighbor 2.2.2.2 peer-group mygroupSwitch(config-router)# endConfiguring OSPF
Open Shortest Path First (OSPF) is an Interior Gateway Protocol (IGP) designed expressly for IP networks, supporting IP subnetting and tagging of externally derived routing information. OSPF also allows packet authentication and uses IP multicast when sending and receiving packets.
This section briefly describes how to configure O SPF. For a complete description of the OSPF commands, see the Cisco IOS IP Routing: OSPF Command Reference.
Note OSPF classifies different media into broadcast, nonbroadcast multiaccess (NBMA), or point-to-point networks. Broadcast and nonbroadcast networks can also be configured as point-to-multipoint networks. The switch supports all these network types.
The Cisco implementation conforms to the OSPF Version 2 specifications with these key features:
•Definition of stub areas is supported.
•Routes learned through any IP routing protocol can be redistributed into another IP routing protocol. At the intradomain level, this means that OSPF can import routes learned through EIGRP and RIP. OSPF routes can also be exported into RIP.
•Plain text and MD5 authentication among neighboring routers within an area is supported.
•Configurable routing interface parameters include interface output cost, retransmission interval, interface transmit delay, router priority, router dead and hello intervals, and authentication key.
•Virtual links are supported.
•Not-so-stubby-areas (NSSAs) per RFC 1587are supported.
OSPF typically requires coordination among many internal routers, area border routers (ABRs) connected to multiple areas, and autonomous system boundary routers (ASBRs). The minimum configuration would use all default parameter values, no authentication, and interfaces assigned to areas. If you customize your environment, you must ensure coordinated configuration of all routers.
These sections contain this configuration information:
•Configuring OSPF Network Types
•Configuring OSPF Area Parameters
•Configuring Other OSPF Parameters
•Configuring a Loopback Interface
Default OSPF Configuration
Table 37-5 Default OSPF Configuration
Feature Default SettingInterface parameters
Cost: No default cost predefined.
Retransmit interval: 5 seconds.
Transmit delay: 1 second.
Priority: 1.
Hello interval: 10 seconds.
Dead interval: 4 times the hello interval.
No authentication.
No password specified.
MD5 authentication disabled.
Area
Authentication type: 0 (no authentication).
Default cost: 1.
Range: Disabled.
Stub: No stub area defined.
NSSA: No NSSA area defined.
Auto cost
100 Mbps.
Default-information originate
Disabled. When enabled, the default metric setting is 10, and the external route type default is Type 2.
Default metric
Built-in, automatic metric translation, as appropriate for each routing protocol.
Distance OSPF
dist1 (all routes within an area): 110.
dist2 (all routes from one area to another): 110.
and dist3 (routes from other routing domains): 110.OSPF database filter
Disabled. All outgoing link-state advertisements (LSAs) are flooded to the interface.
IP OSPF name lookup
Disabled.
Log adjacency changes
Enabled.
Neighbor
None specified.
Neighbor database filter
Disabled. All outgoing LSAs are flooded to the neighbor.
Network area
Disabled.
NSF1 awareness
Enabled2 . Allows Layer 3 switches to continue forwarding packets from a neighboring NSF-capable router during hardware or software changes.
Router ID
No OSPF routing process defined.
Summary address
Disabled.
Timers LSA group pacing
240 seconds.
Timers shortest path first (spf)
spf delay: 5 seconds.
spf-holdtime: 10 seconds.
Virtual link
No area ID or router ID defined.
Hello interval: 10 seconds.
Retransmit interval: 5 seconds.
Transmit delay: 1 second.
Dead interval: 40 seconds.
Authentication key: no key predefined.
Message-digest key (MD5): no key predefined.
1 NSF = Nonstop forwarding
2 OSPF NSF awareness is enabled for IPv4 on switches running the metro IP access image
Nonstop Forwarding Awareness
The OSPF NSF Awareness feature is supported for IPv4 in the metro IP access image. When the neighboring router is NSF-capable, the Layer 3 switch continues to forward packets from the neighboring router during the interval between the primary Route Processor (RP) in a router crashing and the backup RP taking over, or while the primary RP is manually reloaded for a non-disruptive software upgrade.
This feature cannot be disabled. For more information on this feature see the IP Routing: OSPF Configuration Guide, Cisco IOS Release 15.x.
Configuring Basic OSPF Parameters
Enabling OSPF requires that you create an OSPF routing process, specify the range of IP addresses to be associated with the routing process, and assign area IDs to be associated with that range.
Beginning in privileged EXEC mode, follow these steps to enable OSPF:
To terminate an OSPF routing process, use the no router ospf process-id global configuration command.
This example shows how to configure an OSPF routing process and assign it a process number of 109:
Switch(config)# router ospf 109Switch(config-router)# network 131.108.0.0 255.255.255.0 area 24Configuring OSPF Interfaces
You can use the ip ospf interface configuration commands to modify interface-specific OSPF parameters. You are not required to modify any of these parameters, but some interface parameters (hello interval, dead interval, and authentication key) must be consistent across all routers in an attached network. If you modify these parameters, be sure all routers in the network have compatible values.
Note The ip ospf interface configuration commands are all optional.
Beginning in privileged EXEC mode, follow these steps to modify OSPF interface parameters:
Use the no form of these commands to remove the configured parameter value or return to the default value.
Configuring OSPF Network Types
OSPF classifies different media into the three types of networks by default:
•Broadcast networks (Ethernet, Token Ring, and FDDI)
•Nonbroadcast multiaccess (NBMA) networks (Switched Multimegabit Data Service [SMDS], Frame Relay, and X.25)
•Point-to-point networks (High-Level Data Link Control [HDLC], PPP)
You can also configure network interfaces as either a broadcast or an NBMA network and as point-to point or point-to-multipoint, regardless of the default media type.
Configuring OSPF for Nonbroadcast Networks
Because many routers might be attached to an OSPF network, a designated router is selected for the network. If broadcast capability is not configured in the network, the designated router selection requires special configuration parameters. You need to configure these parameters only for devices that are eligible to become the designated router or backup designated router (in other words, routers with a nonzero router priority value).
Beginning in privileged EXEC mode, follow these steps to configure routers that interconnect to nonbroadcast networks:
On point-to-multipoint, nonbroadcast networks, you then use the neighbor router configuration command to identify neighbors. Assigning a cost to a neighbor is optional.
Configuring Network Types for OSPF Interfaces
You can configure network interfaces as either broadcast or NBMA and as point-to point or point-to-multipoint, regardless of the default media type.
An OSPF point-to-multipoint interface is defined as a numbered point-to-point interface with one or more neighbors. On point-to-multipoint broadcast networks, specifying neighbors is optional. When you configure an interface as point-to-multipoint when the media does not support broadcast, you should use the neighbor command to identify neighbors.
Beginning in privileged EXEC mode, follow these steps to configure OSPF network type for an interface:
Use the no form of the ip ospf network command to return to the default network type for the media.
Configuring OSPF Area Parameters
You can optionally configure several OSPF area parameters. These parameters include authentication for password-based protection against unauthorized access to an area, stub areas, and not-so-stubby-areas (NSSAs). Stub areas are areas into which information on external routes is not sent. Instead, the area border router (ABR) generates a default external route into the stub area for destinations outside the autonomous system (AS). An NSSA does not flood all LSAs from the core into the area, but can import AS external routes within the area by redistribution.
Route summarization is the consolidation of advertised addresses into a single summary route to be advertised by other areas. If network numbers are contiguous, you can use the area range router configuration command to configure the ABR to advertise a summary route that covers all networks in the range.
Note The OSPF area router configuration commands are all optional.
Beginning in privileged EXEC mode, follow these steps to configure area parameters:
Use the no form of these commands to remove the configured parameter value or to return to the default value.
Configuring Other OSPF Parameters
You can optionally configure other OSPF parameters in router configuration mode.
•Route summarization: When redistributing routes from other protocols as described in the "Using Route Maps to Redistribute Routing Information" section, each route is advertised individually in an external LSA. To help decrease the size of the OSPF link state database, you can use the summary-address router configuration command to advertise a single router for all the redistributed routes included in a specified network address and mask.
•Virtual links: In OSPF, all areas must be connected to a backbone area. You can establish a virtual link in case of a backbone-continuity break by configuring two Area Border Routers as endpoints of a virtual link. Configuration information includes the identity of the other virtual endpoint (the other ABR) and the nonbackbone link that the two routers have in common (the transit area). Virtual links cannot be configured through a stub area.
•Default route: When you specifically configure redistribution of routes into an OSPF routing domain, the route automatically becomes an autonomous system boundary router (ASBR). You can force the ASBR to generate a default route into the OSPF routing domain.
•Domain Name Server (DNS) names for use in all OSPF show privileged EXEC command displays makes it easier to identify a router than displaying it by router ID or neighbor ID.
•Default Metrics: OSPF calculates the OSPF metric for an interface according to the bandwidth of the interface. The metric is calculated as ref-bw divided by bandwidth, where ref is 10 by default, and bandwidth (bw) is specified by the bandwidth interface configuration command. For multiple links with high bandwidth, you can specify a larger number to differentiate the cost on those links.
•Administrative distance is a rating of the trustworthiness of a routing information source, an integer between 0 and 255, with a higher value meaning a lower trust rating. An administrative distance of 255 means the routing information source cannot be trusted at all and should be ignored. OSPF uses three different administrative distances: routes within an area (interarea), routes to another area (interarea), and routes from another routing domain learned through redistribution (external). You can change any of the distance values.
•Passive interfaces: Because interfaces between two devices on an Ethernet represent only one network segment, to prevent OSPF from sending hello packets for the sending interface, you must configure the sending device to be a passive interface. Both devices can identify each other through the hello packet for the receiving interface.
•Route calculation timers: You can configure the delay time between when OSPF receives a topology change and when it starts the shortest path first (SPF) calculation and the hold time between two SPF calculations.
•Log neighbor changes: You can configure the router to send a syslog message when an OSPF neighbor state changes, providing a high-level view of changes in the router.
Beginning in privileged EXEC mode, follow these steps to configure these OSPF parameters:
Command PurposeStep 1
configure terminal
Enter global configuration mode.
Step 2
router ospf process-id
Enable OSPF routing, and enter router configuration mode.
Step 3
summary-address address mask
(Optional) Specify an address and IP subnet mask for redistributed routes so that only one summary route is advertised.
Step 4
area area-id virtual-link router-id [hello-interval seconds] [retransmit-interval seconds] [trans] [[authentication-key key] | message-digest-key keyid md5 key]]
(Optional) Establish a virtual link and set its parameters. See the "Configuring OSPF Interfaces" section for parameter definitions and Table 37-5 for virtual link defaults.
Step 5
default-information originate [always] [metric metric-value] [metric-type type-value] [route-map map-name]
(Optional) Force the ASBR to generate a default route into the OSPF routing domain. Parameters are all optional.
Step 6
ip ospf name-lookup
(Optional) Configure DNS name lookup. The default is disabled.
Step 7
ip auto-cost reference-bandwidth ref-bw
(Optional) Specify an address range for which a single route will be advertised. Use this command only with area border routers.
Step 8
distance ospf {[inter-area dist1] [inter-area dist2] [external dist3]}
(Optional) Change the OSPF distance values. The default distance for each type of route is 110. The range is 1 to 255.
Step 9
passive-interface type number
(Optional) Suppress the sending of hello packets through the specified interface.
Step 10
timers throttle spf spf-delay spf-holdtime spf-wait
(Optional) Configure route calculation timers.
•spf-delay—Delay between receiving a change to SPF calculation. The range is from 1 to 600000. miliseconds.
•spf-holdtime—Delay between first and second SPF calculation. The range is form 1 to 600000 in milliseconds.
•spf-wait—Maximum wait time in milliseconds for SPF calculations. The range is from 1 to 600000 in milliseconds.
Step 11
ospf log-adj-changes
(Optional) Send syslog message when a neighbor state changes.
Step 12
end
Return to privileged EXEC mode.
Step 13
show ip ospf [process-id [area-id]] database
Display lists of information related to the OSPF database for a specific router. For some of the keyword options, see the "Monitoring OSPF" section.
Step 14
copy running-config startup-config
(Optional) Save your entries in the configuration file.
Changing LSA Group Pacing
The OSPF LSA group pacing feature allows the router to group OSPF LSAs and pace the refreshing, check-summing, and aging functions for more efficient router use. This feature is enabled by default with a 4-minute default pacing interval, and you will not usually need to modify this parameter. The optimum group pacing interval is inversely proportional to the number of LSAs the router is refreshing, check-summing, and aging. For example, if you have approximately 10,000 LSAs in the database, decreasing the pacing interval would benefit you. If you have a very small database (40 to 100 LSAs), increasing the pacing interval to 10 to 20 minutes might benefit you slightly.
Beginning in privileged EXEC mode, follow these steps to configure OSPF LSA pacing:
To return to the default value, use the no timers lsa-group-pacing router configuration command.
Configuring a Loopback Interface
OSPF uses the highest IP address configured on the interfaces as its router ID. If this interface is down or removed, the OSPF process must recalculate a new router ID and resend all its routing information out its interfaces. If a loopback interface is configured with an IP address, OSPF uses this IP address as its router ID, even if other interfaces have higher IP addresses. Because loopback interfaces never fail, this provides greater stability. OSPF automatically prefers a loopback interface over other interfaces, and it chooses the highest IP address among all loopback interfaces.
Beginning in privileged EXEC mode, follow these steps to configure a loopback interface:
Use the no interface loopback 0 global configuration command to disable the loopback interface.
Monitoring OSPF
You can display specific statistics such as the contents of IP routing tables, caches, and databases.
Table 37-6 lists some of the privileged EXEC commands for displaying statistics. For more show ip ospf database privileged EXEC command options and for explanations of fields in the resulting display, see the Cisco IOS IP Routing: OSPF Command Reference.
Configuring EIGRP
Enhanced IGRP (EIGRP) is a Cisco proprietary enhanced version of the IGRP. EIGRP uses the same distance vector algorithm and distance information as IGRP; however, the convergence properties and the operating efficiency of EIGRP are significantly improved.
The convergence technology employs an algorithm referred to as the Diffusing Update Algorithm (DUAL), which guarantees loop-free operation at every instant throughout a route computation and allows all devices involved in a topology change to synchronize at the same time. Routers that are not affected by topology changes are not involved in recomputations.
IP EIGRP provides increased network width. With RIP, the largest possible width of your network is 15 hops. Because the EIGRP metric is large enough to support thousands of hops, the only barrier to expanding the network is the transport-layer hop counter. EIGRP increments the transport control field only when an IP packet has traversed 15 routers and the next hop to the destination was learned through EIGRP.
EIGRP has these four basic components:
•Neighbor discovery and recovery is the process that routers use to dynamically learn of other routers on their directly attached networks. Routers must also discover when their neighbors become unreachable or inoperative. Neighbor discovery and recovery is achieved by periodically sending small hello packets. As long as hello packets are received, the neighbor is alive and functioning. When this status is determined, the neighboring routers exchange routing information.
•The reliable transport protocol is responsible for guaranteed, ordered delivery of EIGRP packets to all neighbors. It supports intermixed transmission of multicast and unicast packets. Some EIGRP packets must be sent reliably, and others need not be. For efficiency, reliability is provided only when necessary. For example, on a multiaccess network that has multicast capabilities, it is not necessary to send hellos reliably to all neighbors individually. Therefore, EIGRP sends a single multicast hello with an indication in the packet informing the receivers that the packet need not be acknowledged. Other types of packets (such as updates) require acknowledgment, which is shown in the packet. To ensure low convergence time, the reliable transport sends multicast packets quickly when there are unacknowledged packets pending.
•The DUAL finite state machine handles the decision process for all route computations. It tracks all routes advertised by all neighbors and uses the distance information (known as a metric) to select efficient, loop-free paths. DUAL selects routes to be inserted into a routing table based on feasible successors. A successor is a neighboring router used for packet forwarding that has a least-cost path to a destination that is guaranteed not to be part of a routing loop.
When there are no feasible successors, but there are neighbors advertising the destination, a recomputation must occur to determine a new successor. The amount of time it takes to recompute the route affects the convergence time. When a topology change occurs, DUAL tests for feasible successors to avoid unnecessary recomputation.
•The protocol-dependent modules are responsible for network layer protocol-specific tasks. An example is the IP EIGRP module, which is responsible for sending and receiving EIGRP packets that are encapsulated in IP. It is also responsible for parsing EIGRP packets and informing DUAL of the new information received. Routing decisions are stored in the IP routing table. EIGRP also redistributes routes learned by other IP routing protocols.
These sections contain this configuration information:
•Configuring Basic EIGRP Parameters
•Configuring EIGRP Route Authentication
•Configuring EIGRP Stub Routing
•Monitoring and Maintaining EIGRP
Default EIGRP Configuration
Table 37-7, Part 1 Default EIGRP Configuration
Feature Default SettingAuto summary
Enabled. Subprefixes are summarized to the classful network boundary when crossing classful network boundaries.
Default-information
Exterior routes are accepted and default information is passed between EIGRP processes when doing redistribution.
Default metric
Only connected routes and interface static routes can be redistributed without a default metric. The metric includes:
•Bandwidth: 0 or greater kbps.
•Delay (tens of microseconds): 0 or any positive number that is a multiple of 39.1 nanoseconds.
•Reliability: any number between 0 and 255 (255 means 100 percent reliability).
•Loading: effective bandwidth as a number between 0 and 255 (255 is 100 percent loading).
•MTU: maximum transmission unit size of the route in bytes. 0 or any positive integer.
Distance
Internal distance: 90.
External distance: 170.
EIGRP log-neighbor changes
Disabled. No adjacency changes logged.
IP authentication key-chain
No authentication provided.
IP authentication mode
No authentication provided.
IP bandwidth-percent
50 percent.
IP hello interval
For low-speed nonbroadcast multiaccess (NBMA) networks: 60 seconds; all other networks: 5 seconds.
IP hold-time
For low-speed NBMA networks: 180 seconds; all other networks: 15 seconds.
IP split-horizon
Enabled.
IP summary address
No summary aggregate addresses are predefined.
Metric weights
tos: 0; k1 and k3: 1; k2, k4, and k5: 0
Network
None specified.
NSF1 Awareness
Enabled2 . Allows Layer 3 switches to continue forwarding packets from a neighboring NSF-capable router during hardware or software changes.
Offset-list
Disabled.
Router EIGRP
Disabled.
Set metric
No metric set in the route map.
Traffic-share
Distributed proportionately to the ratios of the metrics.
Variance
1 (equal-cost load balancing).
1 NSF = Nonstop Forwarding
2 EIGRP NSF awareness is enabled for IPv4 on switches running the metro IP access image.
To create an EIGRP routing process, you must enable EIGRP and associate networks. EIGRP sends updates to the interfaces in the specified networks. If you do not specify an interface network, it is not advertised in any EIGRP update.
Nonstop Forwarding Awareness
The EIGRP NSF Awareness feature is supported for IPv4 in the metro IP access image. When the neighboring router is NSF-capable, the Layer 3 switch continues to forward packets from the neighboring router during the interval between the primary Route Processor (RP) in a router failing and the backup RP taking over, or while the primary RP is manually reloaded for a nondisruptive software upgrade.
This feature cannot be disabled. For more information on this feature, see the EIP Routing EIGRP Configuration Guide, Cisco IOS Release 15.x.
Configuring Basic EIGRP Parameters
Beginning in privileged EXEC mode, follow these steps to configure EIGRP. Configuring the routing process is required; other steps are optional:
Use the no forms of these commands to disable the feature or return the setting to the default value.
Configuring EIGRP Interfaces
Other optional EIGRP parameters can be configured on an interface basis.
Beginning in privileged EXEC mode, follow these steps to configure EIGRP interfaces:
Use the no forms of these commands to disable the feature or return the setting to the default value.
Configuring EIGRP Route Authentication
EIGRP route authentication provides MD5 authentication of routing updates from the EIGRP routing protocol to prevent the introduction of unauthorized or false routing messages from unapproved sources.
Beginning in privileged EXEC mode, follow these steps to enable authentication:
Use the no forms of these commands to disable the feature or to return the setting to the default value.
Configuring EIGRP Stub Routing
The EIGRP stub routing feature reduces resource utilization by moving routed traffic closer to the end user. In a network using EIGRP stub routing, the only allowable route for IP traffic to the user is through a switch that is configured with EIGRP stub routing. The switch sends the routed traffic to interfaces that are configured as user interfaces or are connected to other devices.
When using EIGRP stub routing, you need to configure the distribution and remote routers to use EIGRP and to configure only the switch as a stub. Only specified routes are propagated from the switch. The switch responds to all queries for summaries, connected routes, and routing updates.
Note EIGRP stub routing only advertises connected or summary routes from the routing tables to other switches in the network. The switch uses EIGRP stub routing at the access layer to eliminate the need for other types of routing advertisements. If you try to configure multi-VRF-CE and EIGRP stub routing at the same time, the configuration is not allowed.
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.
In Figure 37-4, switch B is configured as an EIGRP stub router. Switches A and C are connected to the rest of the WAN. Switch B advertises connected, static, redistribution, and summary routes to switch A and C. Switch B does not advertise any routes learned from switch A (and the reverse).
Figure 37-4 EIGRP Stub Router Configuration
For more information about EIGRP stub routing, see IP Routing EIGRP Configuration Guide, Cisco IOS Release 15.x.
Beginning in privileged EXEC mode, follow these steps to configure a remote or spoke router for EIGRP stub routing:
Enter the show ip eigrp neighbor detail privileged EXEC command from the distribution router to verify the configuration.
Monitoring and Maintaining EIGRP
You can delete neighbors from the neighbor table. You can also display various EIGRP routing statistics. Table 37-8 lists the privileged EXEC commands for deleting neighbors and displaying statistics. For explanations of fields in the resulting display, see the Cisco IOS IP Routing: EIGRP Command Reference.
Configuring BGP
The Border Gateway Protocol (BGP) is an exterior gateway protocol used to set up an interdomain routing system for loop-free exchanges of routing information between autonomous systems. Autonomous systems are made up of routers that operate under the same administration and that run Interior Gateway Protocols (IGPs), such as RIP or OSPF, within their boundaries and that interconnect by using an Exterior Gateway Protocol (EGP). BGP Version 4 is the standard EGP for interdomain routing in the Internet.
You can find detailed information about BGP in Internet Routing Architectures, published by Cisco Press, and in the IP Routing: BGP Configuration Guide, Cisco IOS Release 15.x.
For details about BGP commands and keywords, see the Cisco IOS IP Routing: BGP Command Reference. For a list of BGP commands that are visible but not supported by the switch, see "Unsupported Commands in Cisco IOS Release 15.3(1)S."
Routers that belong to the same autonomous system (AS) and that exchange BGP updates run internal BGP (IBGP), and routers that belong to different autonomous systems and that exchange BGP updates run external BGP (EBGP). Most configuration commands are the same for configuring EBGP and IBGP. The difference is that the routing updates are exchanged either between autonomous systems (EBGP) or within an AS (IBGP). Figure 37-5 shows a network that is running both EBGP and IBGP.
Figure 37-5 EBGP, IBGP, and Multiple Autonomous Systems
Before exchanging information with an external AS, BGP ensures that networks within the AS can be reached by defining internal BGP peering among routers within the AS and by redistributing BGP routing information to IGPs that run within the AS, such as IGRP and OSPF.
Routers that run a BGP routing process are often referred to as BGP speakers. BGP uses the Transmission Control Protocol (TCP) as its transport protocol (specifically port 179). Two BGP speakers that have a TCP connection to each other for exchanging routing information are known as peers or neighbors. In Figure 37-5, Routers A and B are BGP peers, as are Routers B and C and Routers C and D. The routing information is a series of AS numbers that describe the full path to the destination network. BGP uses this information to construct a loop-free map of autonomous systems.
The network has these characteristics:
•Routers A and B are running EBGP, and Routers B and C are running IBGP. Note that the EBGP peers are directly connected and that the IBGP peers are not. As long as there is an IGP running that allows the two neighbors to reach one another, IBGP peers do not have to be directly connected.
•All BGP speakers within an AS must establish a peer relationship with each other. That is, the BGP speakers within an AS must be fully meshed logically. BGP4 provides two techniques that reduce the requirement for a logical full mesh: confederations and route reflectors.
•AS 200 is a transit AS for AS 100 and AS 300—that is, AS 200 is used to transfer packets between AS 100 and AS 300.
BGP peers initially exchange their full BGP routing tables and then send only incremental updates. BGP peers also exchange keepalive messages (to ensure that the connection is up) and notification messages (in response to errors or special conditions).
In BGP, each route consists of a network number, a list of autonomous systems that information has passed through (the autonomous system path), and a list of other path attributes. The primary function of a BGP system is to exchange network reachability information, including information about the list of AS paths, with other BGP systems. This information can be used to determine AS connectivity, to prune routing loops, and to enforce AS-level policy decisions.
A router or switch running Cisco IOS does not select or use an IBGP route unless it has a route available to the next-hop router and it has received synchronization from an IGP (unless IGP synchronization is disabled). When multiple routes are available, BGP bases its path selection on attribute values. See the "Configuring BGP Decision Attributes" section for information about BGP attributes.
BGP Version 4 supports classless interdomain routing (CIDR) so you can reduce the size of your routing tables by creating aggregate routes, resulting in supernets. CIDR eliminates the concept of network classes within BGP and supports the advertising of IP prefixes.
•Managing Routing Policy Changes
•Configuring BGP Decision Attributes
•Configuring BGP Filtering with Route Maps
•Configuring BGP Filtering by Neighbor
•Configuring Prefix Lists for BGP Filtering
•Configuring BGP Community Filtering
•Configuring BGP Neighbors and Peer Groups
•Configuring Aggregate Addresses
•Configuring Routing Domain Confederations
•Monitoring and Maintaining BGP
For detailed descriptions of BGP configuration, see IP Routing: BGP Configuration Guide, Cisco IOS Release 15.x. For details about specific commands, see the Cisco IOS IP Routing: BGP Command Reference. For a list of BGP commands that are visible but not supported by the switch, see "Unsupported Commands in Cisco IOS Release 15.3(1)S."
Default BGP Configuration
Table 37-9 Default BGP Configuration
Feature Default SettingAggregate address
Disabled: None defined.
AS path access list
None defined.
Auto summary
Enabled.
Best path
•The router considers as-path in choosing a route and does not compare similar routes from external BGP peers.
•Compare router ID: Disabled.
BGP community list
•Number: None defined. When you permit a value for the community number, the list defaults to an implicit deny for everything else that has not been permitted.
•Format: Cisco default format (32-bit number).
BGP confederation identifier/peers
•Identifier: None configured.
•Peers: None identified.
BGP Fast external fallover
Enabled.
BGP local preference
100. The range is 0 to 4294967295 with the higher value preferred.
BGP network
None specified; no backdoor route advertised.
BGP route dampening
Disabled by default. When enabled:
•Half-life is 15 minutes.
•Re-use is 750 (10-second increments).
•Suppress is 2000 (10-second increments).
•Max-suppress-time is 4 times half-life; 60 minutes.
BGP router ID
The IP address of a loopback interface if one is configured or the highest IP address configured for a physical interface on the router.
Default information originate (protocol or network redistribution)
Disabled.
Default metric
Built-in, automatic metric translations.
Distance
•External route administrative distance: 20 (acceptable values are from 1 to 255).
•Internal route administrative distance: 200 (acceptable values are from 1 to 255).
•Local route administrative distance: 200 (acceptable values are from 1 to 255).
Distribute list
•In (filter networks received in updates): Disabled.
•Out (suppress networks from being advertised in updates): Disabled.
Internal route redistribution
Disabled.
IP prefix list
None defined.
Multi exit discriminator (MED)
•Always compare: Disabled. Does not compare MEDs for paths from neighbors in different autonomous systems.
•Best path compare: Disabled.
•MED missing as worst path: Disabled.
•Deterministic MED comparison is disabled.
Neighbor
•Advertisement interval: 30 seconds for external peers; 5 seconds for internal peers.
•Change logging: Enabled.
•Conditional advertisement: Disabled.
•Default originate: No default route is sent to the neighbor.
•Description: None.
•Distribute list: None defined.
•External BGP multihop: Only directly connected neighbors are allowed.
•Filter list: None used.
•Maximum number of prefixes received: No limit.
Neighbor
•Next hop (router as next hop for BGP neighbor): Disabled.
•Password: Disabled.
•Peer group: None defined; no members assigned.
•Prefix list: None specified.
•Remote AS (add entry to neighbor BGP table): No peers defined.
•Private AS number removal: Disabled.
•Route maps: None applied to a peer.
•Send community attributes: None sent to neighbors.
•Shutdown or soft reconfiguration: Not enabled.
•Timers: keepalive: 60 seconds; holdtime: 180 seconds.
•Update source: Best local address.
•Version: BGP Version 4.
•Weight: Routes learned through BGP peer: 0; routes sourced by the local router: 32768.
NSF1 Awareness
Disabled2 . Allows Layer 3 switches to continue forwarding packets from a neighboring NSF-capable router during hardware or software changes.
Route reflector
None configured.
Synchronization (BGP and IGP)
Enabled.
Table map update
Disabled.
Timers
Keepalive: 60 seconds; holdtime: 180 seconds.
1 NSF = Nonstop Forwarding
2 BGP NSF Awareness can be enabled for IPv4 on switches with the metro IP access image by enabling Graceful Restart.
Nonstop Forwarding Awareness
The BGP NSF Awareness feature is supported for IPv4 in the metro IP access image. To enable this feature with BGP routing, you need to enable Graceful Restart. When the neighboring router is NSF-capable, and this feature is enabled, the Layer 3 switch continues to forward packets from the neighboring router during the interval between the primary Route Processor (RP) in a router failing and the backup RP taking over, or while the primary RP is manually reloaded for a nondisruptive software upgrade.
For more information, see the IP Routing: BGP Configuration Guide, Cisco IOS Release 15.x.
Enabling BGP Routing
To enable BGP routing, you establish a BGP routing process and define the local network. Because BGP must completely recognize the relationships with its neighbors, you must also specify a BGP neighbor.
BGP supports two kinds of neighbors: internal and external. Internal neighbors are in the same AS; external neighbors are in different autonomous systems. External neighbors are usually adjacent to each other and share a subnet, but internal neighbors can be anywhere in the same AS.
The switch supports the use of private AS numbers, usually assigned by service providers and given to systems whose routes are not advertised to external neighbors. The private AS numbers are from 64512 to 65535. You can configure external neighbors to remove private AS numbers from the AS path by using the neighbor remove-private-as router configuration command. Then when an update is passed to an external neighbor, if the AS path includes private AS numbers, these numbers are dropped.
If your AS must pass traffic through it from another AS to a third AS, it is important to be consistent about the routes it advertises. If BGP advertises a route before all routers in the network learn about the route through the IGP, the AS might receive traffic that some routers can not yet route. To prevent this from happening, BGP must wait until the IGP has propagated information across the AS so that BGP is synchronized with the IGP. Synchronization is enabled by default. If your AS does not pass traffic from one AS to another AS, or if all routers in your autonomous systems are running BGP, you can disable synchronization, which allows your network to carry fewer routes in the IGP and allows BGP to converge more quickly.
Beginning in privileged EXEC mode, follow these steps to enable BGP routing, establish a BGP routing process, and specify a neighbor:
Use the no router bgp autonomous-system global configuration command to remove a BGP AS. Use the no network network-number router configuration command to remove the network from the BGP table. Use the no neighbor {ip-address | peer-group-name} remote-as number router configuration command to remove a neighbor. Use the no neighbor {ip-address | peer-group-name} remove-private-as router configuration command to include private AS numbers in updates to a neighbor. Use the synchronization router configuration command to re-enable synchronization.
These examples show how to configure BGP on the routers in Figure 37-5.
Router A:
Switch(config)# router bgp 100Switch(config-router)# neighbor 129.213.1.1 remote-as 200Router B:
Switch(config)# router bgp 200Switch(config-router)# neighbor 129.213.1.2 remote-as 100Switch(config-router)# neighbor 175.220.1.2 remote-as 200Router C:
Switch(config)# router bgp 200Switch(config-router)# neighbor 175.220.212.1 remote-as 200Switch(config-router)# neighbor 192.208.10.1 remote-as 300Router D:
Switch(config)# router bgp 300Switch(config-router)# neighbor 192.208.10.2 remote-as 200To verify that BGP peers are running, use the show ip bgp neighbors privileged EXEC command. This is the output of this command on Router A:
Switch# show ip bgp neighbors
BGP neighbor is 129.213.1.1, remote AS 200, external linkBGP version 4, remote router ID 175.220.212.1BGP state = established, table version = 3, up for 0:10:59Last read 0:00:29, hold time is 180, keepalive interval is 60 secondsMinimum time between advertisement runs is 30 secondsReceived 2828 messages, 0 notifications, 0 in queueSent 2826 messages, 0 notifications, 0 in queueConnections established 11; dropped 10Anything other than state = established means that the peers are not running. The remote router ID is the highest IP address on that router (or the highest loopback interface). Each time the table is updated with new information, the table version number increments. A table version number that continually increments means that a route is flapping, causing continual routing updates.
For exterior protocols, a reference to an IP network from the network router configuration command controls only which networks are advertised. This is in contrast to Interior Gateway Protocols (IGPs), such as EIGRP, which also use the network command to specify where to send updates.
For detailed descriptions of BGP configuration, see the IP Routing: BGP Configuration Guide, Cisco IOS Release 15.x. For details about specific commands, see the Cisco IOS IP Routing: BGP Command Reference. See "Unsupported Commands in Cisco IOS Release 15.3(1)S," for a list of BGP commands that are visible but not supported by the switch.
Managing Routing Policy Changes
Routing policies for a peer include all the configurations that might affect inbound or outbound routing table updates. When you have defined two routers as BGP neighbors, they form a BGP connection and exchange routing information. If you later change a BGP filter, weight, distance, version, or timer, or make a similar configuration change, you must reset the BGP sessions so that the configuration changes take effect.
There are two types of reset, hard reset and soft reset. The switch supports a soft reset without any prior configuration when both BGP peers support the soft route refresh capability, which is advertised in the OPEN message sent when the peers establish a TCP session. A soft reset allows the dynamic exchange of route refresh requests and routing information between BGP routers and the subsequent re-advertisement of the respective outbound routing table.
•When soft reset generates inbound updates from a neighbor, it is called dynamic inbound soft reset.
•When soft reset sends a set of updates to a neighbor, it is called outbound soft reset.
A soft inbound reset causes the new inbound policy to take effect. A soft outbound reset causes the new local outbound policy to take effect without resetting the BGP session. As a new set of updates is sent during outbound policy reset, a new inbound policy can also take effect.
Beginning in privileged EXEC mode, follow these steps to learn if a BGP peer supports the route refresh capability and to reset the BGP session:
BFD Support for Static Routing
Unlike dynamic routing protocols, such as OSPF and BGP, static routing has no method of peer discovery. Therefore, when BFD is configured, the reachability of the gateway is completely dependent on the state of the BFD session to the specified neighbor. Unless the BFD session is up, the gateway for the static route is considered unreachable, and therefore, the affected routes will not be installed in the appropriate Routing Information Base (RIB).
For a BFD session to be successfully established, BFD must be configured on the interface on the peer and a BFD client must be registered on the peer for the address of the BFD neighbor. When an interface is used by dynamic routing protocols, the latter requirement is usually met by configuring the routing protocol instances on each neighbor for BFD. When an interface is used exclusively for static routing, this requirement must be met by configuring static routes on the peers.
If a BFD configuration is removed from the remote peer while the BFD session is in the Up state, the updated state of the BFD session is not signaled to IPv4 static. This causes the static route to remain in the RIB. The only workaround is to remove the IPv4 static BFD neighbor configuration so that the static route no longer tracks the BFD session state. Also, if you change the encapsulation type on a serial interface to one that is unsupported by BFD, BFD will be in a Down state on that interface. The workaround is to shut down the interface, change to a supported encapsulation type, and then reconfigure BFD.
A single BFD session can be used by an IPv4 static client to track the reachability of next hops through a specific interface. You can assign a BFD group for a set of BFD-tracked static routes. Each group must have one active static BFD configuration, one or more passive BFD configurations, and the corresponding static routes to be tracked for BFD. Non group entries are BFD-tracked static routes for which a BFD group is not assigned. A BFD group must accommodate static BFD configurations that can be part of different VRFs. Effectively, the passive static BFD configurations need not be in the same VRF as that of the active configuration.
For each BFD group, there can be only one active static BFD session. You can configure the active BFD session by adding a static BFD configuration and a corresponding static route that uses the BFD configuration. The BFD session in a group is created only when there is an active static BFD configuration and a static route that uses the static BFD configuration. When the active static BFD configuration or the active static route is removed from a BFD group, all the passive static routes are withdrawn from the RIB. Effectively, all the passive static routes are inactive until an active static BFD configuration and a static route to be tracked by the active BFD session are configured in the group.
Similarly, for each BFD group, there can be one or more passive static BFD configurations and the corresponding static routes to be tracked for BFD. Passive static session routes take effect only when the active BFD session state is reachable. Though the active BFD session state of the group is reachable, the passive static route is added to the RIB only if the corresponding interface state is Up. When a passive BFD session is removed from a group, it will not affect the active BFD session, if one exists, or the BFD group reachability status.
Configuring BGP Decision Attributes
When a BGP speaker receives updates from multiple autonomous systems that describe different paths to the same destination, it must choose the single best path for reaching that destination. The decision is based on the value of attributes that the update contains and other BGP-configurable factors. The selected path is entered into the BGP routing table and propagated to its neighbors.
When a BGP peer learns two EBGP paths for a prefix from a neighboring AS, it chooses the best path and inserts that path in the IP routing table. If BGP multipath support is enabled and the EBGP paths are learned from the same neighboring autonomous systems, multiple paths are installed in the IP routing table. Then, during packet switching, per-packet or per-destination load balancing is performed among the multiple paths. The maximum-paths router configuration command controls the number of paths allowed.
These factors summarize the order in which BGP evaluates the attributes for choosing the best path:
1. If the path specifies a next hop that is inaccessible, drop the update. The BGP next-hop attribute, automatically determined by the software, is the IP address of the next hop that is going to be used to reach a destination. For EBGP, this is usually the IP address of the neighbor specified by the neighbor remote-as router configuration command. You can disable next-hop processing by using route maps or the neighbor next-hop-self router configuration command.
2. Prefer the path with the largest weight (a Cisco proprietary parameter). The weight attribute is local to the router and not propagated in routing updates. By default, the weight attribute is 32768 for paths that the router originates and zero for other paths. You can use access lists, route maps, or the neighbor weight router configuration command to set weights.
3. Prefer the route with the highest local preference. Local preference is part of the routing update and exchanged among routers in the same AS. The default value of the local preference attribute is 100. You can set local preference by using the bgp default local-preference router configuration command or by using a route map.
4. Prefer the route that was originated by BGP running on the local router.
5. Prefer the route with the shortest AS path.
6. Prefer the route with the lowest origin type. An interior route or IGP is lower than a route learned by EGP, and an EGP-learned route is lower than one of unknown origin or learned in another way.
7. Prefer the route with the lowest multi-exit discriminator (MED) metric attribute if the neighboring AS is the same for all routes considered. You can configure the MED by using route maps or by using the default-metric router configuration command. When an update is sent to an IBGP peer, the MED is included.
8. Prefer the external (EBGP) path over the internal (IBGP) path.
9. Prefer the route that can be reached through the closest IGP neighbor (the lowest IGP metric). This means that the router will prefer the shortest internal path within the AS to reach the destination (the shortest path to the BGP next-hop).
10. If these conditions are all true, insert the route for this path into the IP routing table:
•Both the best route and this route are external.
•Both the best route and this route are from the same neighboring autonomous system.
•Maximum-paths is enabled.
11. If multipath is not enabled, prefer the route with the lowest IP address value for the BGP router ID. The router ID is usually the highest IP address on the router or the loopback (virtual) address, but might be implementation-specific.
Beginning in privileged EXEC mode, follow these steps to configure some decision attributes:
Use the no form of each command to return to the default state.
Configuring BGP Filtering with Route Maps
Within BGP, you can use route maps to control and to modify routing information and to define the conditions by which routes are redistributed between routing domains. See the "Using Route Maps to Redistribute Routing Information" section for more information about route maps. Each route map has a name that identifies the route map (map tag) and an optional sequence number.
Beginning in privileged EXEC mode, follow these steps to use a route map to disable next-hop processing:
Use the no route-map map-tag command to delete the route map. Use the no set ip next-hop ip-address command to re-enable next-hop processing.
Configuring BGP Filtering by Neighbor
You can filter BGP advertisements by using AS-path filters, such as the as-path access-list global configuration command and the neighbor filter-list router configuration command. You can also use access lists with the neighbor distribute-list router configuration command. Distribute-list filters are applied to network numbers. See the "Controlling Advertising and Processing in Routing Updates" section for information about the distribute-list command.
You can use route maps on a per-neighbor basis to filter updates and to modify various attributes. A route map can be applied to either inbound or outbound updates. Only the routes that pass the route map are sent or accepted in updates. On both inbound and outbound updates, matching is supported based on AS path, community, and network numbers. Autonomous-system path matching requires the match as-path access-list route-map command, community-based matching requires the match community-list route-map command, and network-based matching requires the ip access-list global configuration command.
Beginning in privileged EXEC mode, follow these steps to apply a per-neighbor route map:
Use the no neighbor distribute-list command to remove the access list from the neighbor. Use the no neighbor route-map map-tag router configuration command to remove the route map from the neighbor.
Another method of filtering is to specify an access list filter on both incoming and outbound updates, based on the BGP autonomous system paths. Each filter is an access list based on regular expressions. (For more information on forming regular expressions, see the IP Routing: BGP Configuration Guide, Cisco IOS Release 15.x.) To use this method, define an autonomous system path access list, and apply it to updates to and from particular neighbors.
Beginning in privileged EXEC mode, follow these steps to configure BGP path filtering:
Configuring Prefix Lists for BGP Filtering
You can use prefix lists as an alternative to access lists in many BGP route filtering commands, including the neighbor distribute-list router configuration command. Filtering by a prefix list involves matching the prefixes of routes with those listed in the prefix list, as when matching access lists. When there is a match, the route is used. Whether a prefix is permitted or denied is based upon these rules:
•An empty prefix list permits all prefixes.
•An implicit deny is assumed if a given prefix does not match any entries in a prefix list.
•When multiple entries of a prefix list match a given prefix, the sequence number of a prefix list entry identifies the entry with the lowest sequence number.
By default, sequence numbers are generated automatically and incremented in units of five. If you disable the automatic generation of sequence numbers, you must specify the sequence number for each entry. You can specify sequence values in any increment. If you specify increments of one, you cannot insert additional entries into the list; if you choose very large increments, you might run out of values.
You do not need to specify a sequence number when removing a configuration entry. Show commands include the sequence numbers in their output.
Before using a prefix list in a command, you must set up the prefix list. Beginning in privileged EXEC mode, follow these steps to create a prefix list or to add an entry to a prefix list:
To delete a prefix list and all of its entries, use the no ip prefix-list list-name global configuration command. To delete an entry from a prefix list, use the no ip prefix-list seq seq-value global configuration command. To disable automatic generation of sequence numbers, use the no ip prefix-list sequence number command; to reenable automatic generation, use the ip prefix-list sequence number command. To clear the hit-count table of prefix list entries, use the clear ip prefix-list privileged EXEC command.
Configuring BGP Community Filtering
One way that BGP controls the distribution of routing information based on the value of the COMMUNITIES attribute. A community is a group of destinations that share some common attribute. Each destination can belong to multiple communities. AS administrators can define to which communities a destination belongs. By default, all destinations belong to the general Internet community. The community is identified by the COMMUNITIES attribute, an optional, transitive, global attribute in the numerical range from 1 to 4294967200. These are some predefined, well-known communities:
•internet—Advertise this route to the Internet community. All routers belong to it.
•no-export—Do not advertise this route to EBGP peers.
•no-advertise—Do not advertise this route to any peer (internal or external).
•local-as—Do not advertise this route to peers outside the local autonomous system.
Based on the community, you can control which routing information to accept, prefer, or distribute to other neighbors. A BGP speaker can set, append, or modify the community of a route when learning, advertising, or redistributing routes. When routes are aggregated, the resulting aggregate has a COMMUNITIES attribute that contains all communities from all the initial routes.
You can use community lists to create groups of communities to use in a match clause of a route map. As with an access list, a series of community lists can be created. Statements are checked until a match is found. As soon as one statement is satisfied, the test is concluded.
To set the COMMUNITIES attribute and match clauses based on communities, see the match community-list and set community route-map configuration commands in the "Using Route Maps to Redistribute Routing Information" section.
By default, no COMMUNITIES attribute is sent to a neighbor. You can specify that the COMMUNITIES attribute be sent to the neighbor at an IP address by using the neighbor send-community router configuration command.
Beginning in privileged EXEC mode, follow these steps to create and to apply a community list:
Configuring BGP Neighbors and Peer Groups
Often many BGP neighbors are configured with the same update policies (that is, the same outbound route maps, distribute lists, filter lists, update source, and so on). Neighbors with the same update policies can be grouped into peer groups to simplify configuration and to make updating more efficient. When you have configured many peers, we recommend this approach.
To configure a BGP peer group, you create the peer group, assign options to the peer group, and add neighbors as peer group members. You configure the peer group by using the neighbor router configuration commands. By default, peer group members inherit all the configuration options of the peer group, including the remote-as (if configured), version, update-source, out-route-map, out-filter-list, out-dist-list, minimum-advertisement-interval, and next-hop-self. All peer group members also inherit changes made to the peer group. Members can also be configured to override the options that do not affect outbound updates.
To assign configuration options to an individual neighbor, specify any of these router configuration commands by using the neighbor IP address. To assign the options to a peer group, specify any of the commands by using the peer group name. You can disable a BGP peer or peer group without removing all the configuration information by using the neighbor shutdown router configuration command.
Beginning in privileged EXEC mode, use these commands to configure BGP peers:
To disable an existing BGP neighbor or neighbor peer group, use the neighbor shutdown router configuration command. To enable a previously existing neighbor or neighbor peer group that had been disabled, use the no neighbor shutdown router configuration command.
Configuring Aggregate Addresses
Classless interdomain routing (CIDR) enables you to create aggregate routes (or supernets) to minimize the size of routing tables. You can configure aggregate routes in BGP either by redistributing an aggregate route into BGP or by creating an aggregate entry in the BGP routing table. An aggregate address is added to the BGP table when there is at least one more specific entry in the BGP table.
Beginning in privileged EXEC mode, use these commands to create an aggregate address in the routing table:
To delete an aggregate entry, use the no aggregate-address address mask router configuration command. To return options to the default values, use the command with keywords.
Configuring Routing Domain Confederations
One way to reduce the IBGP mesh is to divide an autonomous system into multiple subautonomous systems and to group them into a single confederation that appears as a single autonomous system. Each autonomous system is fully meshed within itself and has a few connections to other autonomous systems in the same confederation. Even though the peers in different autonomous systems have EBGP sessions, they exchange routing information as if they were IBGP peers. Specifically, the next hop, MED, and local preference information is preserved. You can then use a single IGP for all of the autonomous systems.
To configure a BGP confederation, you must specify a confederation identifier that acts as the autonomous system number for the group of autonomous systems. Beginning in privileged EXEC mode, use these commands to configure a BGP confederation:
Configuring Route Dampening
Route flap dampening minimizes the propagation of flapping routes across an internetwork. A route is considered to be flapping when it is repeatedly available, then unavailable, then available, then unavailable, and so on. When route dampening is enabled, a numeric penalty value is assigned to a route when it flaps. When a route's accumulated penalties reach a configurable limit, BGP suppresses advertisements of the route, even if the route is running. The reuse limit is a configurable value that is compared with the penalty. If the penalty is less than the reuse limit, a suppressed route that is up is advertised again.
Dampening is not applied to routes that are learned by IBGP. This policy prevents the IBGP peers from having a higher penalty for routes external to the AS.
Beginning in privileged EXEC mode, use these commands to configure BGP route dampening:
To disable flap dampening, use the no bgp dampening router configuration command without keywords. To set dampening factors back to the default values, use the no bgp dampening router configuration command with values.
Monitoring and Maintaining BGP
You can remove all contents of a particular cache, table, or database. This might be necessary when the contents of the particular structure have become or are suspected to be invalid.
You can display specific statistics, such as the contents of BGP routing tables, caches, and databases. You can use the information to get resource utilization and solve network problems. You can also display information about node reachability and discover the routing path your device's packets are taking through the network.
Table 37-8 lists the privileged EXEC commands for clearing and displaying BGP. For explanations of the display fields, see the Cisco IOS IP Routing: BGP Command Reference.
You can also enable the logging of messages generated when a BGP neighbor resets, comes up, or goes down by using the bgp log-neighbor changes router configuration command.
Configuring ISO CLNS Routing
The International Organization for Standardization (ISO) Connectionless Network Service (CLNS) protocol is a standard for the network layer of the Open System Interconnection (OSI) model. Addresses in the ISO network architecture are referred to as network service access point (NSAP) addresses and network entity titles (NETs). Each node in an OSI network has one or more NETs. In addition, each node has many NSAP addresses.
When you enable connectionless routing on the switch by using the clns routing global configuration command, the switch makes only forwarding decisions, with no routing-related functionality. For dynamic routing, you must also enable a routing protocol. The switch supports the Intermediate System-to-Intermediate System (IS-IS) dynamic routing protocols for ISO CLNS networks: This routing protocol supports the concept of areas. Within an area, all routers know how to reach all the system IDs. Between areas, routers know how to reach the proper area. IS-IS supports two levels of routing: station routing (within an area) and area routing (between areas).
The key difference between the ISO IGRP and IS-IS NSAP addressing schemes is in the definition of area addresses. Both use the system ID for Level 1 routing (routing within an area). However, they differ in the way addresses are specified for area routing. An ISO IGRP NSAP address includes three separate fields for routing: the domain, area, and system ID. An IS-IS address includes two fields: a single continuous area field (comprising the domain and area fields) and the system ID.
Note For more detailed information about ISO CLNS, see the Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS and XNS Configuration Guide, Release 12.2. For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS and XNS Command Reference, Release 12.2, use the IOS command reference master index, or search online.
Configuring IS-IS Dynamic Routing
IS-IS is an ISO dynamic routing protocol. Enabling IS-IS requires that you create an IS-IS routing process and assign it to a specific interface, rather than to a network. You can specify more than one IS-IS routing process per Layer 3 switch or router by using the multiarea IS-IS configuration syntax. You then configure the parameters for each instance of the IS-IS routing process.
Small IS-IS networks are built as a single area that includes all the routers in the network. As the network grows larger, it is usually reorganized into a backbone area made up of the connected set of all Level 2 routers from all areas, which is in turn connected to local areas. Within a local area, routers know how to reach all system IDs. Between areas, routers know how to reach the backbone, and the backbone routers know how to reach other areas.
Routers establish Level 1 adjacencies to perform routing within a local area (station routing). Routers establish Level 2 adjacencies to perform routing between Level 1 areas (area routing).
A single Cisco router can participate in routing in up to 29 areas and can perform Level 2 routing in the backbone. In general, each routing process corresponds to an area. By default, the first instance of the routing process configured performs both Level 1and Level 2 routing. You can configure additional router instances, which are automatically treated as Level 1 areas. You must configure the parameters for each instance of the IS-IS routing process individually.
For IS-IS multiarea routing, you can configure only one process to perform Level 2 routing, although you can define up to 29 Level 1 areas for each Cisco unit. If Level 2 routing is configured on any process, all additional processes are automatically configured as Level 1. You can configure this process to perform Level 1 routing at the same time. If Level 2 routing is not desired for a router instance, remove the Level 2 capability using the is-type global configuration command. Use the is-type command also to configure a different router instance as a Level 2 router.
Note For more detailed information about IS-IS, see the IP Routing: ISIS Configuration Guide, Cisco IOS Release 15.x. For complete syntax and usage information for the commands used in this section, see the Cisco IOS IP Routing: ISIS Command Reference.
This section briefly describes how to configure IS-IS routing. It includes this information:
•Configuring IS-IS Global Parameters
•Configuring IS-IS Interface Parameters
Default IS-IS Configuration
Table 37-12 Default IS-IS Configuration
Feature Default SettingIgnore link-state PDU (LSP) errors
Enabled.
IS-IS type
Conventional IS-IS: the router acts as both a Level 1 (station) and a Level 2 (area) router.
Multiarea IS-IS: the first instance of the IS-IS routing process is a Level 1-2 router. Remaining instances are Level 1 routers.
Default-information originate
Disabled.
Log IS-IS adjacency state changes.
Disabled.
LSP generation throttling timers
Maximum interval between two consecutive occurrences: 5 seconds.
Initial LSP generation delay: 50 ms.
Hold time between the first and second LSP generation: 5000 ms.
LSP maximum lifetime (without a refresh)
1200 seconds (20 minutes) before t.he LSP packet is deleted.
LSP refresh interval
Send LSP refreshes every 900 seconds (15 minutes).
Maximum LSP packet size
1497 bytes.
NSF1 Awareness
Enabled2 . Allows Layer 3 switches to continue forwarding packets from a neighboring NSF-capable router during hardware or software changes.
Partial route computation (PRC) throttling timers
Maximum PRC wait interval: 5 seconds.
Initial PRC calculation delay after a topology change: 2000 ms.
Hold time between the first and second PRC calculation: 5000 ms.
Partition avoidance
Disabled.
Password
No area or domain password is defined, and authentication is disabled.
Set-overload-bit
Disabled. When enabled, if no arguments are entered, the overload bit is set immediately and remains set until you enter the no set-overload-bit command.
Shortest path first (SPF) throttling timers
Maximum interval between consecutive SFPs: 10 seconds.
Initial SFP calculation after a topology change: 5500 ms.
Holdtime between the first and second SFP calculation: 5500 ms.
Summary-address
Disabled.
1 NSF = Nonstop Forwarding
2 IS-IS NSF awareness is enabled for IPv4 on switches running the metro IP access image.
Nonstop Forwarding Awareness
The integrated IS-IS NSF Awareness feature is supported for IPv4 in the metro IP access image. The feature allows customer premises equipment (CPE) routers that are NSF-aware to help NSF-capable routers perform nonstop forwarding of packets. The local router is not necessarily performing NSF, but its awareness of NSF allows the integrity and accuracy of the routing database and link-state database on the neighboring NSF-capable router to be maintained during the switchover process.
This feature is automatically enabled and requires no configuration. For more information on this feature, see the IP Routing: ISIS Configuration Guide, Cisco IOS Release 15.x.
Enabling IS-IS Routing
To enable IS-IS, you specify a name and NET for each routing process. You then enable IS-IS routing on the interface and specify the area for each instance of the routing process.
Beginning in privileged EXEC mode, follow these steps to enable IS-IS and specify the area for each instance of the IS-IS routing process:
To disable IS-IS routing, use the no router isis area-tag router configuration command.
This example shows how to configure three routers to run conventional IS-IS as an IP routing protocol. In conventional IS-IS, all routers act as Level 1 and Level 2 routers (by default).
Router A
Switch(config)# clns routingSwitch(config)# router isisSwitch(config-router)# net 49.0001.0000.0000.000a.00Switch(config-router)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# ip router isisSwitch(config-if)# clns router isisSwitch(config)# interface gigabitethernet0/2Switch(config-if)# ip router isisSwitch(config-if)# clns router isisSwitch(config-router)# exitRouter B
Switch(config)# clns routingSwitch(config)# router isisSwitch(config-router)# net 49.0001.0000.0000.000b.00Switch(config-router)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# ip router isisSwitch(config-if)# clns router isisSwitch(config)# interface gigabitethernet0/2Switch(config-if)# ip router isisSwitch(config-if)# clns router isisSwitch(config-router)# exitRouter C
Switch(config)# clns routingSwitch(config)# router isisSwitch(config-router)# net 49.0001.0000.0000.000c.00Switch(config-router)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# ip router isisSwitch(config-if)# clns router isisSwitch(config)# interface gigabitethernet0/2Switch(config-if)# ip router isisSwitch(config-if)# clns router isisSwitch(config-router)# exitConfiguring IS-IS Global Parameters
•You can force a default route into an IS-IS routing domain by configuring a default route controlled by a route map. You can also specify other filtering options configurable under a route map.
•You can configure the router to ignore IS-IS LSPs that are received with internal checksum errors or to purge corrupted LSPs, which causes the initiator of the LSP to regenerate it.
•You can assign passwords to areas and domains.
•You can create aggregate addresses that are represented in the routing table by a summary address (route-summarization). Routes learned from other routing protocols can also be summarized. The metric used to advertise the summary is the smallest metric of all the specific routes.
•You can set an overload bit.
•You can configure the LSP refresh interval and the maximum time that an LSP can remain in the router database without a refresh
•You can set the throttling timers for LSP generation, shortest path first computation, and partial route computation.
•You can configure the switch to generate a log message when an IS-IS adjacency changes state (up or down).
•If a link in the network has a maximum transmission unit (MTU) size of less than 1500 bytes, you can lower the LSP MTU so that routing will still occur.
•The partition avoidance router configuration command prevents an area from becoming partitioned when full connectivity is lost among a Level1-2 border router, adjacent Level 1 routers, and end hosts.
Beginning in privileged EXEC mode, follow these steps to configure IS-IS parameters:
To disable default route generation, use the no default-information originate router configuration command. Use the no area-password or no domain-password router configuration command to disable passwords. To disable LSP MTU settings, use the no lsp mtu router configuration command. To return to the default conditions for summary addressing, LSP refresh interval, LSP lifetime, LSP timers, SFP timers, and PRC timers, use the no form of the commands. Use the no partition avoidance router configuration command to disable the output format.
Configuring IS-IS Interface Parameters
You can optionally configure certain interface-specific IS-IS parameters, independently from other attached routers. However, if you change some values from the defaults, such as multipliers and time intervals, it makes sense to also change them on multiple routers and interfaces. Most of the interface parameters can be configured for level 1, level 2, or both.
Interface level parameters:
•The default metric on the interface, which is used as a value for the IS-IS metric and assigned when there is no quality of service (QoS) routing performed.
•The hello interval (length of time between hello packets sent on the interface) or the default hello packet multiplier used on the interface to determine the hold time sent in IS-IS hello packets. The hold time determines how long a neighbor waits for another hello packet before declaring the neighbor down. This determines how quickly a failed link or neighbor is detected so that routes can be recalculated. Change the hello-multiplier in circumstances where hello packets are lost frequently and IS-IS adjacencies are failing unnecessarily. You can raise the hello multiplier and lower the hello interval correspondingly to make the hello protocol more reliable without increasing the time required to detect a link failure.
•Other time intervals:
–Complete sequence number PDU (CSNP) interval. CSNPs are sent by the designated router to maintain database synchronization
–Retransmission interval. This is the time between retransmission of IS-IS LSPs for point-to-point links.
–IS-IS LSP retransmission throttle interval. This is the maximum rate (number of milliseconds between packets) at which IS-IS LSPs are re-sent on point-to-point links This interval is different from the retransmission interval, which is the time between successive retransmissions of the same LSP
•Designated router election priority, which allows you to reduce the number of adjacencies required on a multiaccess network, which in turn reduces the amount of routing protocol traffic and the size of the topology database.
•The interface circuit type, which is the type of adjacency desired for neighbors on the specified interface
•Password authentication for the interface
Beginning in privileged EXEC mode, follow these steps to configure IS-IS interface parameters:
To return to the default settings, use the no forms of the commands.
Monitoring and Maintaining IS-IS
You can remove all contents of a CLNS cache or remove information for a particular neighbor or route. You can display specific CLNS or IS-IS statistics, such as the contents of routing tables, caches, and databases. You can also display information about specific interfaces, filters, or neighbors.
Table 37-13 lists the privileged EXEC commands for clearing and displaying ISO CLNS and IS-IS routing. For explanations of the display fields, see the Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS and XNS Command Reference. Use the Cisco IOS command reference master index, or search online.
Configuring BFD
The Bidirectional Forwarding Detection (BFD) Protocol quickly detects forwarding-path failures for a variety of media types, encapsulations, topologies, and routing protocols. It operates in a unicast, point-to-point mode on top of any data protocol being forwarded between two systems to track IPv4 connectivity between directly connected neighbors. BFD packets are encapsulated in UDP packets with a destination port number of 3784 or 3785.
In EIGRP, IS-IS, and OSPF deployments, the closest alternative to BFD is the use of modified failure-detection mechanisms. Although reducing the EIGRP, IS-IS, and OSPF timers can result in a failure-detection rate of 1 to 2 seconds, BFD can provide failure detection in less than 1 second. BFD can be less CPU-intensive than the reduced timers and, because it is not tied to any particular routing protocol, it can be used as a generic and consistent failure detection mechanism for multiple routing protocols.
To create a BFD session, you must configure BFD on both systems (BFD peers). Enabling BFD at the interface and routing protocol level on BFD peers creates a BFD session. BFD timers are negotiated and the BFD peers send control packets to each other at the negotiated intervals. If the neighbor is not directly connected, BFD neighbor registration is rejected.
Figure 37-6 shows a simple network with two routers running OSPF and BFD. When OSPF discovers a neighbor (1), it sends a request to the BFD process to initiate a BFD neighbor session with the neighbor OSPF router (2), establishing the BFD neighbor session (3).
Figure 37-6 Establishing a BFD Session
Figure 37-7 shows what happens when a failure occurs in the network (1). The BFD neighbor session with the OSPF neighbor closes (2). BFD notifies the OSPF process that the BFD neighbor is no longer reachable, and the OSPF process breaks the OSPF neighbor relationship (4). If an alternative path is available, the routers start converging on it.
Figure 37-7 Breaking an OSPF Neighbor Relationship
BFD clients are routing protocols that register neighbors with BFD. The switch supports ISIS, OSPF v1 and v2, BGP, EIGRP, and HSRP clients. You can use one BFD session for multiple client protocols. For example, if a network is running OSPF and EIGRP across the same link to the same peer, you need to create only one BFD session, and information is shared with both routing protocols.
The switch supports BFD version 0 and version 1. BFD neighbors automatically negotiate the version and the protocol always runs at the higher version. The default version is version 1.
By default, BFD neighbors exchange both control packets and echo packets for detecting forwarding failures. The switch sends echo packets at the configured BFD interval rate (from 50 to 999 ms), and control packets at the BFD slow-timer rate (from 1000 to 3000 ms).
Failure-rate detection can be faster in BFD echo mode, which is enabled by default when you configure BFD session. In this mode, the switch sends echo packets from the BFD software layer, and the BFD neighbor responds to the echo packets through its fast-switching layer. The echo packets do not reach the BFD neighbor software layer, but are reflected back over the forwarding path for failure detection. You configure the rate at which each BFD interface sends BFD echo packets by entering the bfd interval interface configuration command.
To reduce bandwidth consumption, you can disable the sending of echo packets by entering the no bfd echo interface configuration command. When echo mode is disabled, control packets are used to detect forwarding failures. BFD interval is used to exchange control. In bfd no echo mode, configured BFD interval values (from 50 to 999 ms) are negotiated at the slow-timer rate and the BFD peers send control packets to each other at the negotiated intervals. Failure detection time can be between interval values (from 50 to 999 ms). You configure the slow timer rate by entering the bfd slow-timer global configuration command. The range is from 1000 to 3000 ms; the default rate is every 1000 ms.
You can enable or disable echo processing at a switch interface independent of the BFD neighbor configuration. Disabling echo mode only disables the sending of echo packets by the interface. The fast-switching layer that receives an echo packet always reflects it back to the sender.
To run BFD on a switch, you need to configure basic BFD interval parameters on BFD interfaces, enable routing on the switch, and enable one or more one routing protocol clients for BFD. You also need to confirm that Cisco Express Forwarding (CEF) is enabled (the default) on participating switches.
For more detailed configuration, see the Bidirectional Forwarding Detection feature module at this URL:
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fs_bfd.html
For details on the commands, use the Master Index to the Cisco IOS Command List for Release 15.x at this URL:
http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html
These sections describe configuring BFD:
•Default BFD Configuration Guidelines
•Configuring BFD Session Parameters on an Interface
•Enabling BFD Routing Protocol Clients
Default BFD Configuration
No BFD sessions are configured. BFD is disabled on all interfaces.
When configured, BFD version 1 is the default, but switches negotiate for version. Version 0 is also supported.
Standby BFD (for HSRP) is enabled by default.
Asynchronous BFD echo mode is enabled when a BFD session is configured.
Default BFD Configuration Guidelines
The switch supports multiple BFD sessions at one time. The number of BFD session supported is dependant on the timer value
•50BFD sessions with 50ms interval
•150 BFD sessions with 150ms interval
•200 BFD session with 300ms interval
•250 BFD sessions with 600ms interval
To run BFD on a switch:•Configure basic BFD interval parameters on each interface over which you want to run BFD sessions.
•Enable routing on the switch. You can configure BFD without enabling routing, but BFD sessions do not become active unless routing is enabled on the switch and on the BFD interfaces.
•Enable one or more one routing protocol clients for BFD. You should implement fast convergence for the routing protocol that you are using. See the IP routing documentation in this chapter or in the IP Routing BFD Configuration Guide, Cisco IOS Release 15.x, for information on configuring fast convergence.
Note We recommend that you configure the BFD interval parameters on an interface before configuring the routing protocol commands, especially when using EIGRP.
Confirm that CEF is enabled on participating switches (the default) as well as IP routing.
BFD is supported on physical interfaces that are configured as routing interfaces. It is not supported on Layer 2 interfaces and pseudowires.
BFD is supported on Etherchannel.
Although you can configure BFD interface commands on a Layer 2 port, BFD sessions do not operate on the interface unless it is configured as a Layer 3 interface and assigned an IP address.
In HSRP BFD, standby BFD is enabled globally by default and on all interfaces. If you disable it on an interface, you then must disable and reenable it globally for BFD sessions to be active.
When using BFD echo mode (the default), you should disable sending of ICMP redirect messages by entering the no ip redirects interface configuration command on the BFD interface.
BFD is not supported over MPLS with TE/FRR.
Multi-hop BFD is not supported.
ME-3600X-24CX switch supports BFD only in Asynchronous mode or no echo mode.
BFD is supported over Port Channels.
Configuring BFD Session Parameters on an Interface
Before you can start a BFD session on an interface, you must put the interface into Layer 3 mode and set the baseline BFD parameters on it.
Note Although you can configure BFD on Layer 2 interfaces, a BFD session cannot start until both interfaces are in Layer 3 mode and routing is enabled on the switch.
Beginning in privileged EXEC mode, follow these steps to configure BFD parameters on any interface participating in a BFD session:
To remove the BFD parameter configuration, enter the no bfd interval interface configuration command.
Enabling BFD Routing Protocol Clients
After you configure BFD parameters on an interface, you can start a BFD session for one or more routing protocols. You must first enable routing by entering the ip routing global configuration command on the switch. Note that there can be more than one way to start a BFD session on an interface, depending on the routing protocol.
•Configuring BFD for Port-Channel
•Configuring BFD Support for SVI
•Configuring BFD Support for Static Routing
•Configuring BFD Support for RIP
Configuring BFD for Port-Channel
Perform the steps in this procedure to configure BFD for Port-channel.
Configuring BFD Support for SVI
Perform the steps in this procedure to configure BFD over SVI on a VLAN SVI interface by setting the baseline BFD session parameters on an interface. Repeat the steps in this procedure for each interface over which you want to run BFD sessions to BFD neighbors.
Configuring BFD for OSPF
When you start BFD sessions for OSPF, OSPF must be running on all participating devices.You can enable BFD support for OSPF by enabling it globally on all OSPF interfaces or by enabling it on one or more interfaces.
Configuring BFD for OSPF Globally
Beginning in privileged EXEC mode, follow these steps to configure OSFP BFD globally, and to optionally disable it on specific interfaces:
To disable OSPF BFD on all interfaces, enter the no bfd all-interfaces router configuration command.To disable it on an interface, enter the no ip osfp bfd or the ip ospf bfd disable interface configuration command on the interface.
If you want to run OSPF BFD on only one or a few interfaces, you can enter the ip ospf bfd interface configuration command on those interfaces instead of enabling it globally. See the next procedure.
Note If you try to configure OSPF BFD on a Layer 2 interface, the configuration is not recognized.
This is an example of configuring BFD for OSPF on all OSPF interfaces:
Switch(config)# router ospf 109Switch(config-router)# bfd all-interfacesSwitch(config-router)# exitConfiguring BFD for OSPF on an Interface
Beginning in privileged EXEC mode, follow these steps to configure OSFP BFD on an individual interface:
To disable OSPF BFD on an interface, enter the no ip osfp bfd or the ip ospf bfd disable interface configuration command on the interface.
This is an example of configuring BFD for OSPF on a single interface:
Switch(config)# router ospf 109Switch(config-router)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# ip ospf bfdConfiguring BFD for IS-IS
When you start BFD sessions for IS-IS, IS-IS must be running on all devices participating in BFD. You can enable BFD support for IS-IS by enabling it globally on all IS-IS interfaces or by enabling it on one or more interfaces.
Configuring BFD for IS-IS Globally
Beginning in privileged EXEC mode, follow these steps to configure IS-IS BFD globally, and to optionally disable it on specific interfaces:
To disable IS-IS BFD on all interfaces, enter the no bfd all-interfaces router configuration command. To disable it on the specified interface, enter the no isis bfd or the isis bfd disable interface configuration command on the interface.
If you only want to run IS-IS BFD on a few interfaces, instead of enabling it globally, you can enter the isis bfd interface configuration command on those interfaces. See the next procedure.
Note Although IS-IS BFD operates only on Layer 3 interfaces, you can configure it on interfaces in Layer 2 or Layer 3 mode. When you enable it, you see this message:
%ISIS BFD is reverting to router mode configuration, and remains disabled.
This is an example of setting fast convergence and configuring BFD for IS-IS on all IS-IS interfaces:
Switch(config)# router is-is tag1Switch(config-router)# bfd all-interfacesSwitch(config-router)# exitConfiguring BFD for IS-IS on an Interface
Beginning in privileged EXEC mode, follow these steps to configure IS-IS BFD on an individual interface:
To disable IS-IS BFD on an interface, enter the no isis bfd or the isis bfd disable interface configuration command on the interface.
This is an example of configuring BFD for IS-IS on a single interface:
Switch(config)# router is-is tag1Switch(config-router)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# isis bfdConfiguring BFD for BGP
When you start BFD sessions for BGP, BGP must be running on all participating devices. You enter the IP address of the BFD neighbor to enable BFD for BGP.
Beginning in privileged EXEC mode, follow these steps to enable BGP BFD:
To disable BGP BFD, enter the no neighbor ip-address fall-over bfd router configuration command.
Configuring BFD for EIGRP
When you start BFD sessions for EIGRP, EIGRP must be running on all participating devices.You can enable BFD support for EIGRP by globally enabling it on all EIGRP interfaces or by enabling it on one or more interfaces.
Beginning in privileged EXEC mode, follow these steps follow these to configure EIGRP BFD:
To disable EIGRP BFD on all interfaces, enter the no bfd all-interfaces router configuration command. To disable it on an interface, enter the no bfd interface interface-id router configuration command.
Configuring BFD for HSRP
HSRP supports BFD by default; it is globally enabled on all interfaces. If HSRP support has been manually disabled, you can reenable it in interface or global configuration mode. All participating devices must have HSRP enabled and CEF enabled (the default).
Beginning in privileged EXEC mode, follow these steps to reenable HSRP BFD:
To disable HSRP support for BFD on all interfaces, enter the no standby bfd all-interfaces global configuration command. To disable it on an interface, enter the no standby bfd interface configuration command.
Note If you disable standby BFD on an interface by entering the no standby bfd interface configuration command, to activate BFD sessions on other interfaces, you must disable and reenable it globally by entering the no standby bfd all-interfaces global configuration command followed by the standby bfd all-interfaces global configuration command.
Configuring BFD Support for Static Routing
Perform this procedure to configure BFD support for static routing. Repeat the steps in this procedure on each BFD neighbor.
Disabling BFD Echo Mode
When you configure a BFD session, BFD echo mode is enabled by default on BFD interfaces. You can disable echo mode on an interface so it sends no echo packets and but only sends back echo packets received from a neighbor. When echo mode is disabled, control packets are used detect forwarding failures. You can configure slow timers to reduce the frequency of BFD control packets.
Beginning in privileged EXEC mode, follow these steps to disable echo mode on a BFD device and to set the slow timer rate:
To disable reenable echo mode on the switch, enter the bfd echo global configuration command.
Configuring BFD Support for RIP
The BFD for RIPv2 Support feature is used to facilitate an alternate path selection when a neighboring router is inactive.
Routing Information Protocol (RIP) uses the timeout of prefixes of a particular neighbor to identify if a neighbor is inactive. By default, the timeout is 180 seconds; that is, although the next-hop router is inactive, the RIP router will still broadcast prefixes for up to 180 seconds.
Bidirectional Forward Detection (BFD) is a protocol that provides subsecond failure detection using a single, common standardized mechanism that is independent of media and routing protocols.
Prerequisites for BFD support for RIP
BFD is independent of RIPv2 and must be enabled and functional on the router.
Perform this procedure to configure BFD support for RIP.
Configuring Multi-VRF CE
Virtual Private Networks (VPNs) provide a secure way for customers to share bandwidth over an ISP backbone network. A VPN is a collection of sites sharing a common routing table. A customer site is connected to the service-provider network by one or more interfaces, and the service provider associates each interface with a VPN routing table, called a VPN routing/forwarding (VRF) table.
The switch supports multiple VPN routing/forwarding (multi-VRF) instances in customer edge (CE) devices (multi-VRF CE). With Multi-VRF CE, a service provider can support two or more VPNs with overlapping IP addresses.
•Default Multi-VRF CE Configuration
•Multi-VRF CE Configuration Guidelines
•Configuring VRF-Aware Services
•Configuring a VPN Routing Session
•Configuring BGP PE to CE Routing Sessions
•Multi-VRF CE Configuration Example
•Displaying Multi-VRF CE Status
Understanding Multi-VRF CE
Multi-VRF CE allows a service provider to support two or more VPNs, where IP addresses can be overlapped among the VPNs. Multi-VRF CE uses input interfaces to distinguish routes for different VPNs and forms virtual packet-forwarding tables by associating one or more Layer 3 interfaces with each VRF. Interfaces in a VRF can be either physical, such as Ethernet ports, or logical, such as VLAN SVIs, but an interface cannot belong to more than one VRF at any time.
Note Multi-VRF CE interfaces must be Layer 3 interfaces.
Multi-VRF CE includes these devices:
•Customer edge (CE) devices provide customers access to the service-provider network over a data link to one or more provider edge routers. The CE device advertises the site local routes to the router and learns the remote VPN routes from it. The Cisco ME 3400 switch can be a CE.
•Provider edge (PE) routers exchange routing information with CE devices by using static routing or a routing protocol such as BGP, RIPv2, OSPF, or EIGRP. The PE is only required to maintain VPN routes for those VPNs to which it is directly attached, eliminating the need for the PE to maintain all of the service-provider VPN routes. Each PE router maintains a VRF for each of its directly connected sites. Multiple interfaces on a PE router can be associated with a single VRF if all of these sites participate in the same VPN. Each VPN is mapped to a specified VRF. After learning local VPN routes from CEs, a PE router exchanges VPN routing information with other PE routers by using internal BGP (IBPG).
•Provider routers or core routers are any routers in the service provider network that do not attach to CE devices.
With multi-VRF CE, multiple customers can share one CE, and only one physical link is used between the CE and the PE. The shared CE maintains separate VRF tables for each customer and switches or routes packets for each customer based on its own routing table. Multi-VRF CE extends limited PE functionality to a CE device, giving it the ability to maintain separate VRF tables to extend the privacy and security of a VPN to the branch office.
Figure 37-8 shows a configuration using Cisco ME switches as multiple virtual CEs. This scenario is suited for customers who have low bandwidth requirements for their VPN service, for example, small companies. In this case, multi-VRF CE support is required in the Cisco ME switches. Because multi-VRF CE is a Layer 3 feature, each interface in a VRF must be a Layer 3 interface.
Figure 37-8 Switches Acting as Multiple Virtual CEs
When the CE switch receives a command to add a Layer 3 interface to a VRF, it sets up the appropriate mapping between the VLAN ID and the policy label (PL) in multi-VRF-CE-related data structures and adds the VLAN ID and PL to the VLAN database.
When multi-VRF CE is configured, the Layer 3 forwarding table is conceptually partitioned into two sections:
•The multi-VRF CE routing section contains the routes from different VPNs.
•The global routing section contains routes to non-VPN networks, such as the Internet.
VLAN IDs from different VRFs are mapped into different policy labels, which are used to distinguish the VRFs during processing. If no route is found in the multi-VRF CE section of the Layer 3 forwarding table, the global routing section is used to determine the forwarding path. For each new VPN route learned, the Layer 3 setup function retrieves the policy label by using the VLAN ID of the ingress port and inserts the policy label and new route to the multi-VRF CE routing section. If the packet is received from a routed port, the port internal VLAN ID number is used; if the packet is received from an SVI, the VLAN number is used.
This is the packet-forwarding process in a multi-VRF-CE-enabled network:
•When the switch receives a packet from a VPN, the switch looks up the routing table based on the input policy label number. When a route is found, the switch forwards the packet to the PE.
•When the ingress PE receives a packet from the CE, it performs a VRF lookup. When a route is found, the router adds a corresponding MPLS label to the packet and sends it to the MPLS network.
•When an egress PE receives a packet from the network, it strips the label and uses the label to identify the correct VPN routing table. Then it performs the normal route lookup. When a route is found, it forwards the packet to the correct adjacency.
•When a CE receives a packet from an egress PE, it uses the input policy label to look up the correct VPN routing table. If a route is found, it forwards the packet within the VPN.
To configure VRF, you create a VRF table and specify the Layer 3 interface associated with the VRF. Then configure the routing protocols in the VPN and between the CE and the PE. BGP is the preferred routing protocol used to distribute VPN routing information across the provider's backbone. The multi-VRF CE network has three major components:
•VPN route target communities—lists of all other members of a VPN community. You need to configure VPN route targets for each VPN community member.
•Multiprotocol BGP peering of VPN community PE routers—propagates VRF reachability information to all members of a VPN community. You need to configure BGP peering in all PE routers within a VPN community.
•VPN forwarding—transports all traffic between all VPN community members across a VPN service-provider network.
Default Multi-VRF CE Configuration
Table 37-14 shows the default VRF configuration.
Multi-VRF CE Configuration Guidelines
These are considerations when configuring VRF in your network:
•A switch with multi-VRF CE is shared by multiple customers, and each customer has its own routing table.
•Because customers use different VRF tables, the same IP addresses can be reused. Overlapped IP addresses are allowed in different VPNs.
•Multi-VRF CE lets multiple customers share the same physical link between the PE and the CE. Trunk ports with multiple VLANs separate packets among customers. Each customer has its own VLAN.
•Multi-VRF CE does not support all MPLS-VRF functionality. It does not support label exchange, LDP adjacency, or labeled packets.
•For the PE router, there is no difference between using multi-VRF CE or using multiple CEs. In Figure 37-8, multiple virtual Layer 3 interfaces are connected to the multi-VRF CE device.
•The switch supports configuring VRF by using physical ports, VLAN SVIs, or a combination of both. The SVIs can be connected through an access port or a trunk port.
•A customer can use multiple VLANs as long as they do not overlap with those of other customers. A customer's VLANs are mapped to a specific routing table ID that is used to identify the appropriate routing tables stored on the switch.
•The switch supports one global network and up to 128 VRFs.
•Most routing protocols (BGP, OSPF, RIP, EIGRP, and static routing) can be used between the CE and the PE. However, we recommend using external BGP (EBGP) for these reasons:
–BGP does not require multiple algorithms to communicate with multiple CEs.
–BGP is designed for passing routing information between systems run by different administrations.
–BGP makes it easy to pass attributes of the routes to the CE.
•Multi-VRF CE does not affect the packet switching rate.
•A multicast VRF cannot coexist with private VLANs on the same interface.
•A maximum of 1000 multicast routes is supported and can be shared on all VRFs.
•If no VRFs are configured, up to 105 policies can be configured.
•If even one VRF is configured than 41 policies can be configured.
•If more than 41 policies are configured then VRF cannot be configured.
•VRF and private VLANs are mutually-exclusive. You cannot enable VRF on a private VLAN. Similarly, you cannot enable private VLAN on a VLAN with VRF configured on the VLAN interface.
•VRF and policy-based routing (PBR) are mutually-exclusive on a switch interface. You cannot enable VRF when PBR is enabled on an interface. In contrast, you cannot enable PBR when VRF is enabled on an interface.
Configuring VRFs
Beginning in privileged EXEC mode, follow these steps to configure one or more VRFs. For complete syntax and usage information for the commands, refer to the switch command reference for this release and the Cisco IOS Master Command List, All Releases.
Use the no ip vrf vrf-name global configuration command to delete a VRF and to remove all interfaces from it. Use the no ip vrf forwarding interface configuration command to remove an interface from the VRF.
Configuring Multicast VRFs
Beginning in privileged EXEC mode, follow these steps to configure a multicast within a VRF table. For complete syntax and usage information for the commands, see the switch command reference for this release and the Cisco IOS Master Command List, All Releases.
For more information about configuring a multicast within a Multi-VRF CE, see the Multicast Configuration Guides, Cisco IOS Release 15.x.
Configuring VRF-Aware Services
IP services can be configured on global interfaces, and these services run within the global routing instance. IP services are enhanced to run on multiple routing instances; they are VRF-aware. Any configured VRF in the system can be specified for a VRF-aware service.
VRF-Aware services are implemented in platform-independent modules. VRF means multiple routing instances in Cisco IOS. Each platform has its own limit on the number of VRFs it supports.
VRF-aware services have the following characteristics:
•The user can ping a host in a user-specified VRF.
•ARP entries are learned in separate VRFs. The user can display Address Resolution Protocol (ARP) entries for specific VRFs.
These services are VRF-Aware:
•ARP
•Ping
•Simple Network Management Protocol (SNMP)
•Hot Standby Router Protocol (HSRP)
•Syslog
•Traceroute
•FTP and TFTP
Note VRF-Aware services are not supported for Unicast Reverse Path Forwarding (uRPF).
User Interface for ARP
Beginning in privileged EXEC mode, follow these steps to configure VRF-aware services for ARP. For complete syntax and usage information for the commands, refer to the switch command reference for this release and the Cisco IOS Master Command List, All Releases.
User Interface for PING
Beginning in privileged EXEC mode, follow these steps to configure VRF-aware services for ping. For complete syntax and usage information for the commands, refer to the switch command reference for this release and the Cisco IOS Master Command List, All Releases.
User Interface for SNMP
Beginning in privileged EXEC mode, follow these steps to configure VRF-aware services for SNMP. For complete syntax and usage information for the commands, refer to the switch command reference for this release and the Cisco IOS Master Command List, All Releases.
User Interface for HSRP
HSRP support for VRFs ensures that HSRP virtual IP addresses are added to the correct IP routing table.
Beginning in privileged EXEC mode, follow these steps to configure VRF-aware services for HSRP. For complete syntax and usage information for the commands, refer to the switch command reference for this release and the Cisco IOS Master Command List, All Releases.
User Interface for Syslog
Beginning in privileged EXEC mode, follow these steps to configure VRF-aware services for Syslog. For complete syntax and usage information for the commands, refer to the switch command reference for this release and the Cisco IOS Master Command List, All Releases.
User Interface for Traceroute
Beginning in privileged EXEC mode, follow these steps to configure VRF-aware services for traceroute. For complete syntax and usage information for the commands, refer to the switch command reference for this release and the Cisco IOS Master Command List, All Releases.
Command Purposetraceroute vrf vrf-name ipaddress
Specify the name of a VPN VRF in which to find the destination address.
User Interface for FTP and TFTP
So that FTP and TFTP are VRF-aware, you must configure some FTP/TFTP CLIs. For example, if you want to use a VRF table that is attached to an interface, say E1/0, you need to configure the CLI ip [t]ftp source-interface E1/0 to inform [t]ftp to use a specific routing table. In this example, the VRF table is used to look up the destination IP address. These changes are backward-compatible and do not affect existing behavior. That is, you can use the source-interface CLI to send packets out a particular interface even if no VRF is configured on that interface.
To specify the source IP address for FTP connections, use the ip ftp source-interface show mode command. To use the address of the interface where the connection is made, use the no form of this command.
To specify the IP address of an interface as the source address for TFTP connections, use the ip tftp source-interface show mode command. To return to the default, use the no form of this command.
Configuring a VPN Routing Session
Routing within the VPN can be configured with any supported routing protocol (RIP, OSPF, EIGRP, or BGP) or with static routing. The configuration shown here is for OSPF, but the process is the same for other protocols.
Note To configure an EIGRP routing process to run within a VRF instance, you must configure an autonomous-system number by entering the autonomous-system autonomous-system-number address-family configuration mode command.
Beginning in privileged EXEC mode, follow these steps to configure OSPF in the VPN:
Use the no router ospf process-id vrf vrf-name global configuration command to disassociate the VPN forwarding table from the OSPF routing process.
Configuring BGP PE to CE Routing Sessions
Beginning in privileged EXEC mode, follow these steps to configure a BGP PE to CE routing session:
Use the no router bgp autonomous-system-number global configuration command to delete the BGP routing process. Use the command with keywords to delete routing characteristics.
Multi-VRF CE Configuration Example
Figure 37-9 is a simplified example of the physical connections in a network similar to that in Figure 37-8. OSPF is the protocol used in VPN1, VPN2, and the global network. BGP is used in the CE to PE connections. The examples following the illustration show how to configure a Cisco ME 3400 switch as CE Switch A, and the VRF configuration for customer switches D and F. Commands for configuring CE Switch C and the other customer switches are not included but would be similar. The example also includes commands for configuring traffic to Switch A for a Catalyst 6000 or Catalyst 6500 switch acting as a PE router.
Figure 37-9 Multi-VRF CE Configuration Example
Configuring Switch A
On Switch A, enable routing and configure VRF.
Switch# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Switch(config)# ip routingSwitch(config)# ip vrf v11Switch(config-vrf)# rd 800:1Switch(config-vrf)# route-target export 800:1Switch(config-vrf)# route-target import 800:1Switch(config-vrf)# exitSwitch(config)# ip vrf v12Switch(config-vrf)# rd 800:2Switch(config-vrf)# route-target export 800:2Switch(config-vrf)# route-target import 800:2Switch(config-vrf)# exitConfigure the loopback and physical interfaces on Switch A. Gigabit Ethernet port 1 is a trunk connection to the PE. Fast Ethernet ports 8 and 11 connect to VPNs:
Switch(config)# interface loopback1Switch(config-if)# ip vrf forwarding v11Switch(config-if)# ip address 8.8.1.8 255.255.255.0Switch(config-if)# exitSwitch(config)# interface loopback2Switch(config-if)# ip vrf forwarding v12Switch(config-if)# ip address 8.8.2.8 255.255.255.0Switch(config-if)# exitSwitch(config)# interface gigabitethernet0/5Switch(config-if)# switchport trunk encapsulation dot1qSwitch(config-if)# switchport mode trunkSwitch(config-if)# no ip addressSwitch(config-if)# exitSwitch(config)# interface fastethernet0/8Switch(config-if)# no shutdownSwitch(config-if)# switchport access vlan 208Switch(config-if)# no ip addressSwitch(config-if)# exitSwitch(config)# interface fastethernet0/11Switch(config-if)# no shutdownSwitch(config-if)# switchport trunk encapsulation dot1qSwitch(config-if)# switchport mode trunkSwitch(config-if)# no ip addressSwitch(config-if)# exitConfigure the VLANs used on Switch A. VLAN 10 is used by VRF 11 between the CE and the PE. VLAN 20 is used by VRF 12 between the CE and the PE. VLANs 118 and 208 are used for the VPNs that include Switch F and Switch D, respectively:
Switch(config)# interface vlan10Switch(config-if)# ip vrf forwarding v11Switch(config-if)# ip address 38.0.0.8 255.255.255.0Switch(config-if)# exitSwitch(config)# interface vlan20Switch(config-if)# ip vrf forwarding v12Switch(config-if)# ip address 83.0.0.8 255.255.255.0Switch(config-if)# exitSwitch(config)# interface vlan118Switch(config-if)# ip vrf forwarding v12Switch(config-if)# ip address 118.0.0.8 255.255.255.0Switch(config-if)# exitSwitch(config)# interface vlan208Switch(config-if)# ip vrf forwarding v11Switch(config-if)# ip address 208.0.0.8 255.255.255.0Switch(config-if)# exitConfigure OSPF routing in VPN1 and VPN2.
Switch(config)# router ospf 1 vrf vl1Switch(config-router)# redistribute bgp 800 subnetsSwitch(config-router)# network 208.0.0.0 0.0.0.255 area 0Switch(config-router)# exitSwitch(config)# router ospf 2 vrf vl2Switch(config-router)# redistribute bgp 800 subnetsSwitch(config-router)# network 118.0.0.0 0.0.0.255 area 0Switch(config-router)# exitConfigure BGP for CE to PE routing.
Switch(config)# router bgp 800Switch(config-router)# address-family ipv4 vrf vl2Switch(config-router-af)# redistribute ospf 2 match internalSwitch(config-router-af)# neighbor 83.0.0.3 remote-as 100Switch(config-router-af)# neighbor 83.0.0.3 activateSwitch(config-router-af)# network 8.8.2.0 mask 255.255.255.0Switch(config-router-af)# exitSwitch(config-router)# address-family ipv4 vrf vl1Switch(config-router-af)# redistribute ospf 1 match internalSwitch(config-router-af)# neighbor 38.0.0.3 remote-as 100Switch(config-router-af)# neighbor 38.0.0.3 activateSwitch(config-router-af)# network 8.8.1.0 mask 255.255.255.0Switch(config-router-af)# endConfiguring Switch D
Switch D belongs to VPN 1. Configure the connection to Switch A by using these commands.
Switch# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Switch(config)# ip routingSwitch(config)# interface fastethernet0/2Switch(config-if)# no shutdownSwitch(config-if)# no switchportSwitch(config-if)# ip address 208.0.0.20 255.255.255.0Switch(config-if)# exitSwitch(config)# router ospf 101Switch(config-router)# network 208.0.0.0 0.0.0.255 area 0Switch(config-router)# endConfiguring Switch F
Switch F belongs to VPN 2. Configure the connection to Switch A by using these commands.
Switch# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Switch(config)# ip routingSwitch(config)# interface fastethernet0/1Switch(config-if)# no shutdownSwitch(config-if)# switchport trunk encapsulation dot1qSwitch(config-if)# switchport mode trunkSwitch(config-if)# no ip addressSwitch(config-if)# exitSwitch(config)# interface vlan118Switch(config-if)# ip address 118.0.0.11 255.255.255.0Switch(config-if)# exitSwitch(config)# router ospf 101Switch(config-router)# network 118.0.0.0 0.0.0.255 area 0Switch(config-router)# endConfiguring the PE Switch B
On Switch B (the PE router), these commands configure only the connections to the CE device, Switch A.
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip vrf v1Router(config-vrf)# rd 100:1Router(config-vrf)# route-target export 100:1Router(config-vrf)# route-target import 100:1Router(config-vrf)# exitRouter(config)# ip vrf v2Router(config-vrf)# rd 100:2Router(config-vrf)# route-target export 100:2Router(config-vrf)# route-target import 100:2Router(config-vrf)# exitRouter(config)# ip cefRouter(config)# interface Loopback1Router(config-if)# ip vrf forwarding v1Router(config-if)# ip address 3.3.1.3 255.255.255.0Router(config-if)# exitRouter(config)# interface Loopback2Router(config-if)# ip vrf forwarding v2Router(config-if)# ip address 3.3.2.3 255.255.255.0Router(config-if)# exitRouter(config)# interface gigabitthernet0.10Router(config-if)# encapsulation dot1q 10Router(config-if)# ip vrf forwarding v1Router(config-if)# ip address 38.0.0.3 255.255.255.0Router(config-if)# exitRouter(config)# interface gigabitethernet0.20Router(config-if)# encapsulation dot1q 20Router(config-if)# ip vrf forwarding v2Router(config-if)# ip address 83.0.0.3 255.255.255.0Router(config-if)# exitRouter(config)# router bgp 100Router(config-router)# address-family ipv4 vrf v2Router(config-router-af)# neighbor 83.0.0.8 remote-as 800Router(config-router-af)# neighbor 83.0.0.8 activateRouter(config-router-af)# network 3.3.2.0 mask 255.255.255.0Router(config-router-af)# exitRouter(config-router)# address-family ipv4 vrf vlRouter(config-router-af)# neighbor 38.0.0.8 remote-as 800Router(config-router-af)# neighbor 38.0.0.8 activateRouter(config-router-af)# network 3.3.1.0 mask 255.255.255.0Router(config-router-af)# endDisplaying Multi-VRF CE Status
You can use the privileged EXEC commands in Table 37-15 to display information about multi-VRF CE configuration and status.
For more information about the information in the displays, refer to the Cisco IOS Master Command List, All Releases.
Configuring Protocol-Independent Features
This section describes how to configure IP routing protocol-independent features. For a complete description of the IP routing protocol-independent commands in this chapter, see the Cisco IOS IP Routing: Protocol-Independent Command Reference.
These sections contain this configuration information:
•Configuring Cisco Express Forwarding
•Configuring the Number of Equal-Cost Routing Paths
•Configuring Static Unicast Routes
•Specifying Default Routes and Networks
•Using Route Maps to Redistribute Routing Information
•Filtering Routing Information
Configuring Cisco Express Forwarding
Cisco Express Forwarding (CEF) is a Layer 3 IP switching technology used to optimize network performance. CEF implements an advanced IP look-up and forwarding algorithm to deliver maximum Layer 3 switching performance. CEF is less CPU-intensive than fast switching route caching, allowing more CPU processing power to be dedicated to packet forwarding. In dynamic networks, fast switching cache entries are frequently invalidated because of routing changes, which can cause traffic to be process switched using the routing table, instead of fast switched using the route cache. CEF use the Forwarding Information Base (FIB) lookup table to perform destination-based switching of IP packets.
The two main components in CEF are the distributed FIB and the distributed adjacency tables.
•The FIB is similar to a routing table or information base and maintains a mirror image of the forwarding information in the IP routing table. When routing or topology changes occur in the network, the IP routing table is updated, and those changes are reflected in the FIB. The FIB maintains next-hop address information based on the information in the IP routing table. Because the FIB contains all known routes that exist in the routing table, CEF eliminates route cache maintenance, is more efficient for switching traffic, and is not affected by traffic patterns.
•Nodes in the network are said to be adjacent if they can reach each other with a single hop across a link layer. CEF uses adjacency tables to prepend Layer 2 addressing information. The adjacency table maintains Layer 2 next-hop addresses for all FIB entries.
Because the switch uses Application Specific Integrated Circuits (ASICs) to achieve Gigabit-speed line rate IP traffic, CEF forwarding applies only to the software-forwarding path, that is, traffic that is forwarded by the CPU.
CEF is enabled globally by default. If for some reason it is disabled, you can re-enable it by using the ip cef global configuration command.
The default configuration is CEF enabled on all Layer 3 interfaces. Entering the no ip route-cache cef interface configuration command disables CEF for traffic that is being forwarded by software. This command does not affect the hardware forwarding path. Disabling CEF and using the debug ip packet detail privileged EXEC command can be useful to debug software-forwarded traffic. To enable CEF on an interface for the software-forwarding path, use the ip route-cache cef interface configuration command.
Caution Although the no ip route-cache cef interface configuration command to disable CEF on an interface is visible in the CLI, we strongly recommend that you do not disable CEF on interfaces except for debugging purposes.
Beginning in privileged EXEC mode, follow these steps to enable CEF globally and on an interface for software-forwarded traffic if it has been disabled:
Configuring the Number of Equal-Cost Routing Paths
When a router has two or more routes to the same network with the same metrics, these routes can be thought of as having an equal cost. The term parallel path is another way to see occurrences of equal-cost routes in a routing table. If a router has two or more equal-cost paths to a network, it can use them concurrently. Parallel paths provide redundancy in case of a circuit failure and also enable a router to load balance packets over the available paths for more efficient use of available bandwidth.
Although the router automatically learns about and configures equal-cost routes, you can control the maximum number of parallel paths supported by an IP routing protocol in its routing table.
Beginning in privileged EXEC mode, follow these steps to change the maximum number of parallel paths installed in a routing table from the default:
Use the no maximum-paths router configuration command to restore the default value.
Configuring Static Unicast Routes
Static unicast routes are user-defined routes that cause packets moving between a source and a destination to take a specified path. Static routes can be important if the router cannot build a route to a particular destination and are useful for specifying a gateway of last resort to which all unroutable packets are sent.
Beginning in privileged EXEC mode, follow these steps to configure a static route:
Use the no ip route prefix mask {address | interface} global configuration command to remove a static route.
The switch retains static routes until you remove them. However, you can override static routes with dynamic routing information by assigning administrative distance values. Each dynamic routing protocol has a default administrative distance, as listed in Table 37-16. If you want a static route to be overridden by information from a dynamic routing protocol, set the administrative distance of the static route higher than that of the dynamic protocol.
Static routes that point to an interface are advertised through RIP, IGRP, and other dynamic routing protocols, whether or not static redistribute router configuration commands were specified for those routing protocols. These static routes are advertised because static routes that point to an interface are considered in the routing table to be connected and hence lose their static nature. However, if you define a static route to an interface that is not one of the networks defined in a network command, no dynamic routing protocols advertise the route unless a redistribute static command is specified for these protocols.
When an interface goes down, all static routes through that interface are removed from the IP routing table. When the software can no longer find a valid next hop for the address specified as the forwarding router's address in a static route, the static route is also removed from the IP routing table.
Specifying Default Routes and Networks
A router might not be able to learn the routes to all other networks. To provide complete routing capability, you can use some routers as smart routers and give the remaining routers default routes to the smart router. (Smart routers have routing table information for the entire internetwork.) These default routes can be dynamically learned or can be configured in the individual routers. Most dynamic interior routing protocols include a mechanism for causing a smart router to generate dynamic default information that is then forwarded to other routers.
If a router has a directly connected interface to the specified default network, the dynamic routing protocols running on that device generate a default route. In RIP, it advertises the pseudonetwork 0.0.0.0.s
A router that is generating the default for a network also might need a default of its own. One way a router can generate its own default is to specify a static route to the network 0.0.0.0 through the appropriate device.
Beginning in privileged EXEC mode, follow these steps to define a static route to a network as the static default route:
Use the no ip default-network network number global configuration command to remove the route.
When default information is passed through a dynamic routing protocol, no further configuration is required. The system periodically scans its routing table to choose the optimal default network as its default route. In IGRP networks, there might be several candidate networks for the system default. Cisco routers use administrative distance and metric information to set the default route or the gateway of last resort.
If dynamic default information is not being passed to the system, candidates for the default route are specified with the ip default-network global configuration command. If this network appears in the routing table from any source, it is flagged as a possible choice for the default route. If the router has no interface on the default network, but does have a path to it, the network is considered as a possible candidate, and the gateway to the best default path becomes the gateway of last resort.
Using Route Maps to Redistribute Routing Information
The switch can run multiple routing protocols simultaneously, and it can redistribute information from one routing protocol to another. Redistributing information from one routing protocol to another applies to all supported IP-based routing protocols.
You can also conditionally control the redistribution of routes between routing domains by defining enhanced packet filters or route maps between the two domains. The match and set route-map configuration commands define the condition portion of a route map. The match command specifies that a criterion must be matched. The set command specifies an action to be taken if the routing update meets the conditions defined by the match command. Although redistribution is a protocol-independent feature, some of the match and set route-map configuration commands are specific to a particular protocol.
One or more match commands and one or more set commands follow a route-map command. If there are no match commands, everything matches. If there are no set commands, nothing is done, other than the match. Therefore, you need at least one match or set command.
Note A route map with no set route-map configuration commands is sent to the CPU, which causes high CPU utilization.
You can also identify route-map statements as permit or deny. If the statement is marked as a deny, the packets meeting the match criteria are sent back through the normal forwarding channels (destination-based routing). If the statement is marked as permit, set clauses are applied to packets meeting the match criteria. Packets that do not meet the match criteria are forwarded through the normal routing channel.
You can use the BGP route map continue clause to execute additional entries in a route map after an entry is executed with successful match and set clauses. You can use the continue clause to configure and organize more modular policy definitions so that specific policy configurations need not be repeated within the same route map. The switch supports the continue clause for outbound policies. For more information about using the route map continue clause, see the IP Routing: BGP Configuration Guide, Cisco IOS Release 15.x.
Note Although each of Steps 3 through 14 in the following section is optional, you must enter at least one match route-map configuration command and one set route-map configuration command.
Beginning in privileged EXEC mode, follow these steps to configure a route map for redistribution:
To delete an entry, use the no route-map map tag global configuration command or the no match or no set route-map configuration commands.
You can distribute routes from one routing domain into another and control route distribution.
Beginning in privileged EXEC mode, follow these steps to control route redistribution. Note that the keywords are the same as defined in the previous procedure.
To disable redistribution, use the no form of the commands.
The metrics of one routing protocol do not necessarily translate into the metrics of another. In these situations, an artificial metric is assigned to the redistributed route. Uncontrolled exchanging of routing information between different routing protocols can create routing loops and seriously degrade network operation.
If you have not defined a default redistribution metric that replaces metric conversion, some automatic metric translations occur between routing protocols:
•RIP can automatically redistribute static routes. It assigns static routes a metric of 1 (directly connected).
•Any protocol can redistribute other routing protocols if a default mode is in effect.
Filtering Routing Information
You can filter routing protocol information by performing the tasks described in this section.
Note When routes are redistributed between OSPF processes, no OSPF metrics are preserved.
Setting Passive Interfaces
To prevent other routers on a local network from dynamically learning about routes, you can use the passive-interface router configuration command to keep routing update messages from being sent through a router interface. When you use this command in the OSPF protocol, the interface address you specify as passive appears as a stub network in the OSPF domain. OSPF routing information is neither sent nor received through the specified router interface.
In networks with many interfaces, to avoid having to manually set them as passive, you can set all interfaces to be passive by default by using the passive-interface default router configuration command and manually setting interfaces where adjacencies are desired.
Beginning in privileged EXEC mode, follow these steps to configure passive interfaces:
Use a network monitoring privileged EXEC command such as show ip ospf interface to verify the interfaces that you enabled as passive, or use the show ip interface privileged EXEC command to verify the interfaces that you enabled as active.
To re-enable the sending of routing updates, use the no passive-interface interface-id router configuration command. The default keyword sets all interfaces as passive by default. You can then configure individual interfaces where you want adjacencies by using the no passive-interface router configuration command. The default keyword is useful in Internet service provider and large enterprise networks where many of the distribution routers have more than 200 interfaces.
Controlling Advertising and Processing in Routing Updates
You can use the distribute-list router configuration command with access control lists to suppress routes from being advertised in routing updates and to prevent other routers from learning one or more routes. When used in OSPF, this feature applies to only external routes, and you cannot specify an interface name.
You can also use a distribute-list router configuration command to avoid processing certain routes listed in incoming updates. (This feature does not apply to OSPF.)
Beginning in privileged EXEC mode, follow these steps to control the advertising or processing of routing updates:
Use the no distribute-list in router configuration command to change or cancel a filter. To cancel suppression of network advertisements in updates, use the no distribute-list out router configuration command.
Filtering Sources of Routing Information
Because some routing information might be more accurate than others, you can use filtering to prioritize information coming from different sources. An administrative distance is a rating of the trustworthiness of a routing information source, such as a router or group of routers. In a large network, some routing protocols can be more reliable than others. By specifying administrative distance values, you enable the router to intelligently discriminate between sources of routing information. The router always picks the route whose routing protocol has the lowest administrative distance. Table 37-16 shows the default administrative distances for various routing information sources.
Because each network has its own requirements, there are no general guidelines for assigning administrative distances.
Beginning in privileged EXEC mode, follow these steps to filter sources of routing information:
To remove a distance definition, use the no distance router configuration command.
Managing Authentication Keys
Key management is a method of controlling authentication keys used by routing protocols. Not all protocols can use key management. Authentication keys are available for EIGRP and RIP Version 2.
Before you manage authentication keys, you must enable authentication. See the appropriate protocol section to see how to enable authentication for that protocol. To manage authentication keys, define a key chain, identify the keys that belong to the key chain, and specify how long each key is valid. Each key has its own key identifier (specified with the key number key chain configuration command), which is stored locally. The combination of the key identifier and the interface associated with the message uniquely identifies the authentication algorithm and Message Digest 5 (MD5) authentication key in use.
You can configure multiple keys with life times. Only one authentication packet is sent, regardless of how many valid keys exist. The software examines the key numbers in order from lowest to highest, and uses the first valid key it encounters. The lifetimes allow for overlap during key changes. Note that the router must know these lifetimes.
Beginning in privileged EXEC mode, follow these steps to manage authentication keys:
To remove the key chain, use the no key chain name-of-chain global configuration command.
Monitoring and Maintaining the IP Network
You can remove all contents of a particular cache, table, or database. You can also display specific statistics. Use the privileged EXEC commands in Table 37-17 to clear routes or display status: