Cipro Ute

CHAPT ER 1 9
Configuring IP Routing Protocols

This chapter describes how to configure the various Internet Protocol (IP) routing protocols. For a
complete description of the commands listed in this chapter, refer to the “IP Routing Protocols
Commands” chapter of the Router Products Command Reference publication. For information on
configuring the IP protocol, refer to the “Configuring IP” chapter of this manual.
Cisco’s Implementation of IP Routing Protocols

Cisco’s implementation of each of the IP routing protocols is discussed in detail at the beginning of
the individual protocol sections throughout this chapter.
IP routing protocols are divided into two classes: Interior Gateway Protocols (IGPs) and Exterior
Gateway Protocols (EGPs). The IGPs and EGPs that Cisco supports are listed in the following
sections.
Note Many routing protocol specifications refer to routers as gateways, so the word gateway often
appears as part of routing protocol names. However, a router usually is defined as a Layer 3
internetworking device, whereas a protocol translation gateway usually is defined as a Layer 7
internetworking device. The reader should understand that whether a routing protocol name contains
the word “gateway” or not, routing protocol activities occur at Layer 3 of the OSI reference model.
Interior Gateway Protocols

Interior protocols are used for routing networks that are under a common network administration. All
IP interior gateway protocols must be specified with a list of associated networks before routing
activities can begin. A routing process listens to updates from other routers on these networks and
broadcasts its own routing information on those same networks. The interior routing protocols
supported are as follows:
• Internet Gateway Routing Protocol (IGRP)
• Enhanced Internet Gateway Routing Protocol (Enhanced IGRP)
• Open Shortest Path First (OSPF)
• Routing Information Protocol (RIP)
• Intermediate System-to-Intermediate System (IS-IS)
Configuring IP Routing Protocols 19-1

Cisco’s Implementation of IP Routing Protocols
Exterior Gateway Protocols

Exterior protocols are used to exchange routing information between networks that do not share a
common administration. IP exterior gateway protocols require three sets of information before
routing can begin:
• A list of neighbor (or peer) routers with which to exchange routing information
• A list of networks to advertise as directly reachable
• The autonomous system number of the local router
The supported exterior gateway protocols are as follows:
• Border Gateway Protocol (BGP)
• Exterior Gateway Protocol (EGP)
Router Discovery Protocols

Our routers also support two router discovery protocols, Gateway Discovery Protocol (GDP) and
ICMP Router Discovery Protocol (IRDP), which allow hosts to locate routers.
GDP was developed by Cisco and is not an industry standard. Unsupported example GDP clients
can be obtained upon request from Cisco. Our IRDP implementation fully conforms to the router
discovery protocol outlined in RFC 1256.
Multiple Routing Protocols

You can configure multiple routing protocols in a single router to connect networks that use different
routing protocols. You can, for example, run RIP on one subnetted network, IGRP on another
subnetted network, and exchange routing information between them in a controlled fashion. The
available routing protocols were not designed to interoperate with one another, so each protocol
collects different types of information and reacts to topology changes in its own way. For example,
RIP uses a hop-count metric and IGRP uses a five-element vector of metric information. In the case
where routing information is being exchanged between different networks that use different routing
protocols, there are many configuration options that allow you to filter the exchange of routing
information.
Our routers can handle simultaneous operation of up to 30 dynamic IP routing processes. The
combination of routing processes on a router can consist of the following protocols (with the limits
noted):
• Up to 30 IGRP routing processes
• Up to 30 OSPF routing processes
• One RIP routing process
• One IS-IS process
• One BGP routing process
• Up to 30 EGP routing processes
19-2 Router Products Configuration Guide

IP Routing Protocols Task List
IP Routing Protocols Task List

With any of the IP routing protocols, you need to create the routing process, associate networks with
the routing process, and customize the routing protocol for your particular network.
You will need to perform some combination of the tasks in the following sections to configure IP
routing protocols:
• Determine a Routing Process
• Configure IGRP
• Configure Enhanced IGRP
• Configure OSPF
• Configure RIP
• Configure IS-IS
• Configure BGP
• Configure EGP
• Configure GDP
• Configure IRDP
• Configure IP Multicast Routing
• Configure Routing Protocol-Independent Features
• Monitor and Maintain the IP Network
See the end of this chapter for IP routing protocol configuration examples.
Determine a Routing Process

Choosing a routing protocol is a complex task. When choosing a routing protocol, consider (at least)
the following:
• Internetwork size and complexity
• Support for variable-length subnet masks (VLSM); IS-IS, static routes, and OSPF support
VLSM.
• Internetwork traffic levels
• Security needs
• Reliability needs
• Internetwork delay characteristics
• Organizational policies
• Organizational acceptance of change
The following sections describe the configuration tasks associated with each supported routing
protocol. This publication does not provide in-depth information on how to choose routing
protocols; you must choose routing protocols that best suit your needs.

Configure IGRP
Configure IGRP
The Interior Gateway Routing Protocol (IGRP) is a dynamic distance-vector routing protocol
designed by Cisco Systems in the mid-1980s for routing in an autonomous system that contains
large, arbitrarily complex networks with diverse bandwidth and delay characteristics.
Cisco’s IGRP Implementation

IGRP uses a combination of user-configurable metrics including internetwork delay, bandwidth,
reliability, and load.
IGRP also advertises three types of routes: interior, system, and exterior, as shown in Figure 19-1.
Interior routes are routes between subnets in the network attached to a router interface. If the network
attached to a router is not subnetted, IGRP does not advertise interior routes.
Figure 19-1 Interior, System, and Exterior Routes

Autonomous
Autonomous system 1 system 2
System
Subnet B
Exterior
Interior
Router Router Router

Subnet A
S1019a
System routes are routes to networks within an autonomous system. The router derives system routes
from directly connected network interfaces and system route information provided by other
IGRP-speaking routers. System routes do not include subnet information.
Exterior routes are routes to networks outside the autonomous system that are considered when
identifying a gateway of last resort. The router chooses a gateway of last resort from the list of
exterior routes that IGRP provides. The router uses the gateway (router) of last resort if it does not
have a better route for a packet and the destination is not a connected network. If the autonomous
system has more than one connection to an external network, different routers can choose different
exterior routers as the gateway of last resort.

Configure IGRP
IGRP Updates
By default, a router running IGRP sends an update broadcast every 90 seconds. It declares a route
inaccessible if it does not receive an update from the first router in the route within three update
periods (270 seconds). After seven update periods (630 seconds), the router removes the route from
the routing table.
IGRP uses flash update and poison reverse updates to speed up the convergence of the routing
algorithm. Flash update is the sending of an update sooner than the standard periodic update interval
of notifying other routers of a metric change. Poison reverse updates are intended to defeat larger
routing loops caused by increases in routing metrics. The poison reverse updates are sent to remove
a route and place it in holddown, which keeps new routing information from being used for a certain
period of time.
IGRP Configuration Task List

To configure IGRP, perform the tasks in the following sections. It is only mandatory to create the
IGRP routing process; the other tasks described are optional.
• Create the IGRP Routing Process
• Allow Point-to-Point Updates for IGRP
• Define Unequal-Cost Load Balancing
• Control Traffic Distribution
• Adjust the IGRP Metric Weights
• Disable Holddown
• Enforce a Maximum Network Diameter
• Validate Source IP Addresses
Create the IGRP Routing Process

To create the IGRP routing process, perform the following required tasks starting in global
configuration mode:
Task Command
Step 1 Enable an IGRP routing process, which router igrp autonomous-system
places you in router configuration mode.
Step 2 Associate networks with an IGRP network network-number
routing process.
IGRP sends updates to the interfaces in the specified networks. If an interface’s network is not
specified, it will not be advertised in any IGRP update.
It is not necessary to have a registered autonomous system number to use IGRP. If you do not have
a registered number, you are free to create your own. We recommend that if you do have a registered
number, you use it to identify the IGRP process.

Configure IGRP
Allow Point-to-Point Updates for IGRP

Because IGRP is normally a broadcast protocol, in order for IGRP routing updates to reach
point-to-point or nonbroadcast networks, you must configure the router to permit this exchange of
routing information.
To permit information exchange, perform the following task in router configuration mode:
Task Command
Define a neighboring router with which to neighbor ip-address
exchange point-to-point routing information.
To control the set of interfaces that you want to exchange routing updates with, you can disable the
sending of routing updates on specified interfaces by configuring the passive-interface command.
See the discussion on filtering in the section in this chapter titled “Filter Routing Information.”
Define Unequal-Cost Load Balancing

IGRP can simultaneously use an asymmetric set of paths for a given destination. This feature is
known as unequal-cost load balancing. Unequal-cost load balancing allows traffic to be distributed
among multiple (up to four) unequal-cost paths to provide greater overall throughput and reliability.
Alternate path variance (that is, the difference in desirability between the primary and alternate
paths) is used to determine the feasibility of a potential route. An alternate route is feasible if the next
router in the path is closer to the destination (has a lower metric value) than the current router and if
the metric for the entire alternate path is within the variance. Only paths that are feasible can be used
for load balancing and included in the routing table. These conditions limit the number of cases in
which load balancing can occur, but ensure that the dynamics of the network will remain stable.
The following general rules apply to IGRP unequal-cost load balancing:
• IGRP will accept up to four paths for a given destination network.
• The local best metric must be greater than the metric learned from the next router; that is, the
next-hop router must be closer (have a smaller metric value) to the destination than the local best
metric.
• The alternative path metric must be within the specified variance of the local best metric. The
multiplier times the local best metric for the destination must be greater than or equal to the
metric through the next router.
If these conditions are met, the route is deemed feasible and can be added to the routing table.
By default, the amount of variance is set to one (equal-cost load balancing). You can define how
much worse an alternate path can be before that path is disallowed by performing the following task
in router configuration mode:
Task Command
Define the variance associated with a particular variance multiplier
path.
Note By using the variance feature, the router can balance traffic across all feasible paths and can
immediately converge to a new path if one of the paths should fail.

Configure IGRP
See the “IP Routing Protocol Configuration Examples” section at the end of this chapter for an
example of configuring IGRP feasible successor.
Control Traffic Distribution

If variance is configured as described in the preceding section “Define Unequal-Cost Load
Balancing,” IGRP or Enhanced IGRP will distribute traffic among multiple routes of unequal cost to
the same destination. If you want to have faster convergence to alternate routes but you do not want
to send traffic across inferior routes in the normal case, you might prefer to have no traffic flow along
routes with higher metrics.
To control how traffic is distributed among multiple routes of unequal cost, perform the following
task in router configuration mode:
Task Command
Distribute traffic proportionately to the ratios of traffic-share {balanced | min}
metrics, or by the minimum-cost route.
Adjust the IGRP Metric Weights

You have the option of altering the default behavior of IGRP routing and metric computations. This
allows, for example, tuning system behavior to allow for transmissions via satellite. Although IGRP
metric defaults were carefully selected to provide excellent operation in most networks, you can
adjust the IGRP metric. Adjusting IGRP metric weights can dramatically affect network
performance, however, so ensure you make all metric adjustments carefully.
To adjust the IGRP metric weights, perform the following task in router configuration mode. Due to
the complexity of this task, we recommend that you only perform it with guidance from an
experienced system designer.
Task Command
Adjust the IGRP metric. metric weights tos k1 k2 k3 k4 k5
By default, the IGRP composite metric is a 24-bit quantity that is a sum of the segment delays
and the lowest segment bandwidth (scaled and inverted) for a given route. For a network of
homogeneous media, this metric reduces to a hop count. For a network of mixed media (FDDI,
Ethernet, and serial lines running from 9600 bps to T1 rates), the route with the lowest metric reflects
the most desirable path to a destination.
Disable Holddown
When a router learns that a network is at a greater distance than was previously known, or it learns
the network is down, the route to that network is placed into holddown. During the holddown period,
the route is advertised, but incoming advertisements about that network from any router other than
the one that originally advertised the network’s new metric will be ignored. This mechanism is often
used to help avoid routing loops in the network, but has the effect of increasing the topology
convergence time. To disable holddowns with IGRP, perform the following task in router
configuration mode. All routers in an IGRP autonomous system must be consistent in their use of
holddowns.
Task Command
Disable the IGRP holddown period. no metric holddown

Configure Enhanced IGRP
Enforce a Maximum Network Diameter

The router enforces a maximum diameter to the IGRP network. Routes whose hop counts exceed
this diameter will not be advertised. The default maximum diameter is 100 hops. The maximum
diameter is 255 hops.
To configure the maximum diameter, perform the following task in router configuration mode:
Task Command
Configure the maximum network diameter. metric maximum-hops hops
Validate Source IP Addresses

To disable the default function that validates the source IP addresses of incoming routing updates,
perform the following task in router configuration mode:
Task Command
Disable the checking and validation of the source no validate-update-source
IP address of incoming routing updates.

Enhanced IGRP is an enhanced version of the Interior Gateway Routing Protocol (IGRP) developed
by Cisco Systems, Inc. Enhanced IGRP uses the same distance vector algorithm and distance
information as IGRP. However, the convergence properties and the operating efficiency of Enhanced
IGRP have improved significantly over IGRP.
The convergence technology is based on research conducted at SRI International and employs an
algorithm referred to as the Diffusing Update Algorithm (DUAL). This algorithm guarantees
loop-free operation at every instant throughout a route computation and allows all routers involved
in a topology change to synchronize at the same time. Routers that are not affected by topology
changes are not involved in recomputations. The convergence time with DUAL rivals that of any
other existing routing protocol.
Cisco’s Enhanced IGRP Implementation

IP Enhanced IGRP provides the following features:
• Automatic redistribution. IP IGRP routes can be automatically redistributed into Enhanced
IGRP, and IP Enhanced IGRP routes can be automatically redistributed into IGRP. If desired, you
can turn off redistribution. You can also completely turn off IP Enhanced IGRP and IP IGRP on
the router or on individual interfaces.
• Increased network width. With IP RIP, the largest possible width of your network is 15 hops.
When IP Enhanced IGRP is enabled, the largest possible width is 224 hops. Because the
Enhanced IGRP metric is large enough to support thousands of hops, the only barrier to
expanding the network is the transport layer hop counter. Cisco works around this problem by
incrementing the transport control field only when an IP packet has traversed 15 routers and the
next hop to the destination was learned via Enhanced IGRP. When a RIP route is being used as
the next hop to the destination, the transport control field is incremented as usual.

Enhanced IGRP offers the following features:

• Fast convergence. The DUAL algorithm allows routing information to converge as quickly as any
currently available routing protocol.
• Partial updates. Enhanced IGRP sends incremental updates when the state of a destination
changes, instead of sending the entire contents of the routing table. This feature minimizes the
bandwidth required for Enhanced IGRP packets.
• Less CPU usage than IGRP. This occurs because full update packets do not have to be processed
each time they are received.
• Neighbor discovery mechanism. This is a simple hello mechanism used to learn about
neighboring routers. It is protocol-independent.
• Variable-length subnet masks.
• Arbitrary route summarization.
• Scaling. Enhanced IGRP scales to large networks.
Enhanced IGRP has four basic components:
• Neighbor discovery/recovery
• Reliable transport protocol
• DUAL finite state machine
• Protocol-dependent modules
Neighbor discovery/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/recovery is achieved with low overhead by
periodically sending small hello packets. As long as hello packets are received, a router can
determine that a neighbor is alive and functioning. Once this status is determined, the neighboring
routers can exchange routing information.
The reliable transport protocol is responsible for guaranteed, ordered delivery of Enhanced IGRP
packets to all neighbors. It supports intermixed transmission of multicast and unicast packets. Some
Enhanced IGRP packets must be transmitted reliably and others need not be. For efficiency,
reliability is provided only when necessary. For example, on a multiaccess network that has
multicast capabilities, such as Ethernet, it is not necessary to send hellos reliably to all neighbors
individually. Therefore, Enhanced IGRP 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, and this is indicated in the packet. The reliable transport
has a provision to send multicast packets quickly when there are unacknowledged packets pending.
Doing so helps ensure that convergence time remains low in the presence of varying speed links.
The DUAL finite state machine embodies the decision process for all route computations. It tracks
all routes advertised by all neighbors. DUAL 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.
This is the process whereby a new successor is determined. The amount of time it takes to recompute
the route affects the convergence time. Even though the recomputation is not processor intensive, it
is advantageous to avoid recomputation if it is not necessary. When a topology change occurs,
DUAL will test for feasible successors. If there are feasible successors, it will use any it finds in order
to avoid unnecessary recomputation.

The protocol-dependent modules are responsible for network layer protocol-specific tasks. An
example is the IP Enhanced IGRP module, which is responsible for sending and receiving Enhanced
IGRP packets that are encapsulated in IP. It is also responsible for parsing Enhanced IGRP packets
and informing DUAL of the new information received. IP Enhanced IGRP asks DUAL to make
routing decisions, but the results are stored in the IP routing table. Also, IP Enhanced IGRP is
responsible for redistributing routes learned by other IP routing protocols.
Enhanced IGRP Configuration Task List

To configure IP Enhanced IGRP, complete the tasks in the following sections. At a minimum, you
must enable IP Enhanced IGRP. The remaining tasks are optional.
• Enable IP Enhanced IGRP
• Transition from IGRP to Enhanced IGRP
• Configure IP Enhanced IGRP-Specific Parameters
• Configure Protocol-Independent Parameters
See the end of this chapter for configuration examples.
Enable IP Enhanced IGRP

To create an IP Enhanced IGRP routing process, perform the following tasks:
Task Command
Step 1 Enable an IP Enhanced IGRP routing router eigrp autonomous-system
process in global configuration mode.
Step 2 Associate networks with an IP Enhanced network network-number
IGRP routing process in router
configuration mode.
IP Enhanced IGRP sends updates to the interfaces in the specified network(s). If you do not specify
an interface’s network, it will not be advertised in any IP Enhanced IGRP update.
Transition from IGRP to Enhanced IGRP

If you have routers on your network that are configured for IGRP and you want to make a transition
to routing Enhanced IGRP, you need to designate transition routers that have both IGRP and
Enhanced IGRP configured. In these cases, perform the tasks as noted in the previous section,
“Enable IP Enhanced IGRP,” and also read the section on configuring IGRP in this chapter. You
must use the same autonomous system number in order for routes to be redistributed automatically.
Configure IP Enhanced IGRP-Specific Parameters

To configure IP Enhanced IGRP-specific parameters, perform one or more of the following tasks:
• Define Unequal-Cost Load Balancing
• Adjust the IP Enhanced IGRP Metric Weights
• Disable Route Summarization
• Configure Summary Aggregate Addresses

Define Unequal-Cost Load Balancing

IP Enhanced IGRP can simultaneously use an asymmetric set of paths for a given destination. This
feature is known as unequal-cost load balancing. Unequal-cost load balancing allows traffic to be
distributed among up to four unequal-cost paths to provide greater overall throughput and reliability.
Alternate path variance (the difference in desirability between the primary and alternate paths) is
used to determine the feasibility of a potential route. An alternate route is feasible if the next router
in the path is closer to the destination (has a lower metric value) than the current router and if the
metric for the entire alternate path is within the variance. Only paths that are feasible can be used for
load balancing and included in the routing table. These conditions limit the number of cases in which
load balancing can occur, but ensure that the dynamics of the network will remain stable.
The following general rules apply to IP Enhanced IGRP unequal-cost load balancing:
• IP Enhanced IGRP will accept up to four paths for a given destination network.
• The local best metric must be greater than the metric learned from the next router; that is, the
next-hop router must be closer (have a smaller metric value) to the destination than the local best
metric.
• The alternative path metric must be within the specified variance of the local best metric. The
multiplier times the local best metric for the destination must be greater than or equal to the
metric through the next router.
If these conditions are met, the route is deemed feasible and can be added to the routing table.
By default, the amount of variance is set to one (equal-cost load balancing). To change the variance
to define how much worse an alternate path can be before that path is disallowed, perform the
following task in router configuration mode:
Task Command
Define the variance associated with a particular variance multiplier
path.
Note By using the variance feature, the router can balance traffic across all feasible paths and can
immediately converge to a new path if one of the paths should fail.
Adjust the IP Enhanced IGRP Metric Weights

You can adjust the default behavior of IP Enhanced IGRP routing and metric computations. For
example, this allows you to tune system behavior to allow for satellite transmission. Although IP
Enhanced IGRP metric defaults have been carefully selected to provide excellent operation in most
networks, you can adjust the IP Enhanced IGRP metric. Adjusting IP Enhanced IGRP metric
weights can dramatically affect network performance, so be careful if you adjust them.
To adjust the IP Enhanced IGRP metric weights, perform the following task in router configuration
mode:
Task Command
Adjust the IP Enhanced IGRP metric. metric weights tos k1 k2 k3 k4 k5
Note Because of the complexity of this task, it is not recommended unless it is done with guidance
from an experienced network designer.

By default, the IP Enhanced IGRP composite metric is a 32-bit quantity that is a sum of the segment
delays and the lowest segment bandwidth (scaled and inverted) for a given route. For a network of
homogeneous media, this metric reduces to a hop count. For a network of mixed media (FDDI,
Ethernet, and serial lines running from 9600 bps to T1 rates), the route with the lowest metric reflects
the most desirable path to a destination.
Disable Route Summarization

You can configure IP Enhanced IGRP to perform automatic summarization of subnet routes into
network-level routes. For example, you can configure subnet 131.108.1.0 to be advertised as
131.108.0.0 over interfaces that have subnets of 192.31.7.0 configured. Automatic summarization is
performed when there are two or more network router configuration commands configured for the
IP Enhanced IGRP process. By default, this feature is enabled.
To disable automatic summarization, perform the following task in router configuration mode:
Task Command
Disable automatic summarization. no auto-summary
Route summarization works in conjunction with the ip summary-address eigrp interface

configuration command, in which additional summarization can be performed. If auto-summary is
in effect, there usually is no need to configure network level summaries using the ip
summary-address eigrp command.
Configure Summary Aggregate Addresses

You can configure a summary aggregate address for a specified interface. If there are any
more-specific routes in the routing table, IP Enhanced IGRP will advertise the summary address out
the interface with a metric equal to the minimum of all more-specific routes.
To configure a summary aggregate address, perform the following task in interface configuration
mode:
Task Command
Configure a summary aggregate address. ip summary-address eigrp
autonomous-system-number address mask
Configure Protocol-Independent Parameters

To configure protocol-independent parameters, perform one or more of the following tasks:
• Redistribute Routing Information
• Set Metrics for Redistributed Routes
• Filter Routing Information
• Adjust the Interval between Hello Packets and the Hold Time
• Disable Split Horizon

Redistribute Routing Information

In addition to running multiple routing protocols simultaneously, the router can redistribute
information from one routing protocol to another. For example, you can instruct the router to
readvertise IP Enhanced IGRP-derived routes using the RIP protocol, or to readvertise static routes
using the IP Enhanced IGRP protocol. This capability applies to all the IP-based routing protocols.
You may also conditionally control the redistribution of routes between routing domains by defining
a method known as route maps between the two domains.
To redistribute routes from one protocol into another, perform the following task in router
configuration mode:
Task Command
Redistribute routes from one routing protocol redistribute protocol autonomous-system-number
into another. [route-map map-tag]
To define route maps, perform the following task in global configuration mode:
Task Command
Define any route maps needed to control route-map map-tag [permit | deny] [sequence-number]
redistribution.
By default, the redistribution of default information between IP Enhanced IGRP processes is

enabled. To disable the redistribution, perform the following task in router configuration mode:
Task Command
Disable the redistribution of default no default-information allowed {in | out}
information between IP Enhanced IGRP
processes.
Set Metrics for Redistributed Routes

The metrics of one routing protocol do not necessarily translate into the metrics of another. For
example, the RIP metric is a hop count and the IP Enhanced IGRP metric is a combination of five
quantities. In such situations, an artificial metric is assigned to the redistributed route. Because of
this unavoidable tampering with dynamic information, carelessly exchanging routing information
between different routing protocols can create routing loops, which can seriously degrade network
operation.
To set metrics for redistributed routes, perform the first task when redistributing from IP Enhanced
IGRP, and perform the second task when redistributing into IP Enhanced IGRP. Each task is done in
router configuration mode.
Task Command
Cause the current routing protocol to use the default-metric number
same metric value for all redistributed routes.
Cause the IP Enhanced IGRP routing protocol default-metric bandwidth delay reliability loading mtu
to use the same metric value for all non-IGRP
redistributed routes.

Filter Routing Information

You can filter routing protocol information by performing the following tasks:
• Suppress the sending of routing updates on a particular router interface. Doing so prevents other
systems on an interface from learning about routes dynamically.
• Suppress networks from being advertised in routing updates. Doing so prevents other routers
from learning a particular router’s interpretation of one or more routes.
• Suppress a routing protocol from both sending and receiving updates on a particular interface.
You usually perform this task when a wildcard command has been used to configure the routing
protocol for more router interfaces than is desirable.
• Suppress networks listed in updates from being accepted and acted upon by a routing process.
Doing so keeps a router from using certain routes.
• Filter on the source of routing information. You perform this task to prioritize routing
information from different sources, because the accuracy of the routing information can vary.
• Apply an offset to routing metrics. Doing so provides a local mechanism for increasing the value
of routing metrics.
Use the information in the following sections to perform these tasks.
Prevent Routing Updates through an Interface

To prevent other routers on a local network from learning about routes dynamically, you can keep
routing update messages from being sent through a router interface. This feature applies to all
IP-based routing protocols except BGP and EGP.
To prevent routing updates through a specified interface, perform the following task in router
configuration mode:
Task Command
Suppress the sending of routing updates passive-interface type number
through a router interface.
Control the Advertising of Routes in Routing Updates

To control which routers learn about routes, you can control the advertising of routes in routing
updates. To do this, perform the following task in router configuration mode:
Task Command
Control the advertising of routes in routing distribute-list access-list-number out [interface-name |
updates. routing-process | autonomous-system-number]
Control the Processing of Routing Updates

To control the processing of routes listed in incoming updates, perform the following task in router
configuration mode:
Task Command
Control which incoming route updates are distribute-list access-list-number in [interface-name]
processes.

Apply Offsets to Routing Metrics

To provide a local mechanism for increasing the value of routing metrics, you can apply an offset to
routing metrics. To do so, perform the following task in router configuration mode:
Task Command
Apply an offset to routing metrics. offset-list [access-list-number] {in | out} offset
Filter Sources of Routing Information

An administrative distance is a rating of the trustworthiness of a routing information source, such as
an individual router or a group of routers. In a large network, some routing protocols and some
routers can be more reliable than others as sources of routing information. Also, when multiple
routing processes are running in the same router for IP, the same route may be advertised by more
than one routing process. Specifying administrative distance values enables the router to
discriminate between sources of routing information. The router always picks the route whose
routing protocol has the lowest administrative distance.
There are no general guidelines for assigning administrative distances, because each network has its
own requirements. You must determine a reasonable matrix of administrative distances for the
network as a whole. Table 19-1 shows the default administrative distance for various routing
information sources.
Table 19-1 Default Administrative Distances
Route Source Default Distance

Connected interface 0
Static route 1
Enhanced IGRP summary route 5
External BGP 20
Internal Enhanced IGRP 90
IGRP 100
OSPF 110
IS-IS 115
RIP 120
EGP 140
External Enhanced IGRP 170
Internal BGP 200
Unknown 255
For example, consider a router using IP Enhanced IGRP and RIP. Suppose you trust the IP Enhanced
IGRP-derived routing information more than the RIP-derived routing information. Because the
default IP Enhanced IGRP administrative distance is lower than that for RIP, the router uses the IP
Enhanced IGRP-derived information and ignores the RIP-derived information. However, if you lose
the source of the IP Enhanced IGRP-derived information (for example, because of a power
shutdown), the router uses the RIP-derived information until the IP Enhanced IGRP-derived
information reappears.

Note You can also use administrative distance to rate the routing information from routers running
the same routing protocol. This application is generally discouraged if you are unfamiliar with this
particular use of administrative distance, since it can result in inconsistent routing information,
including forwarding loops.
To filter sources of routing information, perform the following tasks in router configuration mode:
Task Command
Filter on routing information sources. distance eigrp internal-distance external-distance
Adjust the Interval between Hello Packets and the Hold Time
You can adjust the interval between hello packets and the hold time.
Routers periodically send hello packets to each other to dynamically learn of other routers on their
directly attached networks. The routers use this information to discover who their neighbors are and
to learn when their neighbors become unreachable or inoperative.
By default, hello packets are sent every 5 seconds. The exception is on low speed, nonbroadcast,
mutiaccess (NBMA) media, where the default hello interval is 60 seconds. Low speed is considered
to be a rate of T1 or slower, as specified with the bandwidth interface configuration command. The
default hello interval remains 5 seconds for high speed NBMA networks. Note that for the purposes
of Enhanced IGRP, Frame Relay and SMDS networks may or may not be considered to be NBMA.
These networks are considered NBMA if the interface has not been configured to use physical
multicasting; otherwise they are considered not to be NBMA.
You can configure the hold time on a specified interface for a particular IP Enhanced IGRP routing
process designated by the autonomous system number. The hold time is advertised in hello packets
and indicates to neighbors the length of time they should consider the sender valid. The default hold
time is three times the hello interval, or 15 seconds. For slow speed NBMA networks, the default
hold time is 180 seconds.
To change the interval between hello packets, perform the following task in interface configuration
mode:
Task Command
Configure the hello interval for an IP Enhanced ip hello-interval eigrp autonomous-system-number
IGRP routing process. seconds
On very congested and large networks, the default hold time might not be sufficient time for all
routers to receive hello packets from their neighbors. In this case, you may want to increase the hold
time.
To change the hold time, perform the following task in interface configuration mode:
Task Command
Configure the hold time for an IP Enhanced ip hold-time eigrp autonomous-system-number seconds
IGRP routing process.
Note Do not adjust the hold time without advising technical support.

Configure OSPF
Disable Split Horizon

Split horizon controls the sending of IP Enhanced IGRP update and query packets. When split
horizon is enabled on an interface, these packets are not sent for destinations for which this interface
is the next hop. This reduces the possibility of routing loops.
By default, split horizon is enabled on all interfaces.
Split horizon blocks information about routes from being advertised by a router out any interface
from which that information originated. This behavior usually optimizes communications among
multiple routers, particularly when links are broken. However, with nonbroadcast networks, such as
Frame Relay and SMDS, situations can arise for which this behavior is less than ideal. For these
situations, you may wish to disable split horizon.
To disable split horizon, perform the following task in interface configuration mode:
Task Command
Disable split horizon. no ip split-horizon eigrp autonomous-system-number
Configure OSPF
Open Shortest Path First (OSPF) is an IGP developed by the OSPF working group of the Internet
Engineering Task Force (IETF). Designed expressly for IP networks, OSPF supports IP subnetting
and tagging of externally derived routing information. OSPF also allows packet authentication and
uses IP multicast when sending/receiving packets.
We support RFC 1253, Open Shortest Path First (OSPF) MIB, August 1991. The OSPF MIB defines
an IP routing protocol that provides management information related to OSPF and is supported by
Cisco routers.
Cisco’s OSPF Implementation

Cisco’s implementation conforms to the OSPF Version 2 specifications detailed in the Internet
RFC 1583. The list that follows outlines key features supported in Cisco’s OSPF implementation:
• Stub areas—Definition of stub areas is supported.
• Route redistribution—Routes learned via any IP routing protocol can be redistributed into any
other IP routing protocol. At the intradomain level, this means that OSPF can import routes
learned via IGRP, RIP, and IS-IS. OSPF routes can also be exported into IGRP, RIP, and IS-IS.
At the interdomain level, OSPF can import routes learned via EGP and BGP. OSPF routes can
be exported into EGP and BGP.
• Authentication—Simple and MD5 authentication among neighboring routers within an area is
supported.
• Routing interface parameters—Configurable parameters supported include interface output cost,
retransmission interval, interface transmit delay, router priority, router “dead” and hello intervals,
and authentication key.
• Virtual links—Virtual links are supported.
Note In order to take advantage of the OSPF stub area support, default routing must be used in the
stub area.

Configure OSPF
OSPF Configuration Task List

OSPF typically requires coordination among many internal routers, area border routers (routers
connected to multiple areas), and autonomous system boundary routers. At a minimum, OSPF-based
routers can be configured with all default parameter values, no authentication, and interfaces
assigned to areas. If you intend to customize your environment, you must ensure coordinated
configurations of all routers.
To configure OSPF, complete the tasks in the following sections. Enabling OSPF is mandatory; the
other tasks are optional but might be required for your application.
• Enable OSPF
• Configure OSPF Interface Parameters
• Configure OSPF over Different Physical Networks
• Configure OSPF Area Parameters
• Configure Route Summarization between OSPF Areas
• Configure Route Summarization when Redistributing Routes into OSPF
• Create Virtual Links
• Generate a Default Route
• Configure Lookup of DNS Names
• Force the Router ID Choice with a Loopback Interface
• Disable Default OSPF Metric Calculation Based on Bandwidth
• Configure OSPF on Simplex Ethernet Interfaces
• Configure Route Calculation Timers
In addition, you can specify route redistribution; see the task “Redistribute Routing Information”
later in this chapter for information on how to configure route redistribution.
Enable OSPF
As with other routing protocols, 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 of IP addresses. Perform the following tasks, starting in global
configuration mode:
Task Command
Step 1 Enable OSPF routing, which places you router ospf process-id
in router configuration mode.
Step 2 Define an interface on which OSPF runs network address wildcard-mask area area-id
and define the area ID for that interface.
Configure OSPF Interface Parameters

Our OSPF implementation allows you to alter certain interface-specific OSPF parameters, as
needed. You are not required to alter any of these parameters, but some interface parameters must be
consistent across all routers in an attached network. Those are the parameters set by the ip ospf
hello-interval, ip ospf dead-interval, and ip ospf authentication-key commands. Therefore, be
sure that if you do configure any of these parameters, the configurations for all routers on your
network have compatible values.
Configure OSPF
In interface configuration mode, specify any of the following interface parameters as needed for your
network:
Task Command
Explicitly specify the cost of sending a packet on ip ospf cost cost
an OSPF interface.
Specify the number of seconds between link state ip ospf retransmit-interval seconds
advertisement retransmissions for adjacencies
belonging to an OSPF interface.
Set the estimated number of seconds it takes to ip ospf transmit-delay seconds
transmit a link state update packet on an OSPF
interface.
Set router priority to help determine the OSPF ip ospf priority number
designated router for a network.
Specify the length of time, in seconds, between ip ospf hello-interval seconds
the hello packets that a router sends on an OSPF
interface.
Set the number of seconds that a router’s hello ip ospf dead-interval seconds
packets must not have been seen before its
neighbors declare the OSPF router down.
Assign a specific password to be used by ip ospf authentication-key key
neighboring OSPF routers on a network segment
that is using OSPF’s simple password
authentication.
Enable OSPF MD5 authentication. ip ospf message-digest-key keyid md5 key
Configure OSPF over Different Physical Networks

OSPF classifies different media into three types of networks by default:
• Broadcast networks (Ethernet, Token Ring, FDDI)
• Nonbroadcast multiaccess networks (SMDS, Frame Relay, X.25)
• Point-to-point networks (HDLC, PPP)
You can configure your network as either a broadcast or a nonbroadcast multiaccess network.
X.25 and Frame Relay provide an optional broadcast capability that can be configured in the map to
allow OSPF to run as a broadcast network. See the x25 map and frame-relay map command
descriptions in the Router Products Command Reference publication for more detail.
Configure Your OSPF Network Type

You have the choice of configuring your OSPF network type as either broadcast or nonbroadcast
multiaccess, regardless of the default media type. Using this feature, you can configure broadcast
networks as nonbroadcast multiaccess networks when, for example, you have routers in your
network that do not support multicast addressing. You also can configure nonbroadcast multiaccess
networks, such as X.25, Frame Relay, and SMDS, as broadcast networks. This feature saves you
from having to configure neighbors, as described in the section “Configure OSPF for Nonbroadcast
Networks.”
Configuring nonbroadcast, multiaccess networks as either broadcast or nonbroadcast assumes that
there are virtual circuits from every router to every router or fully-meshed network. This is not true
for some cases, for example, due to cost constraints or when you have only a partially-meshed

Configure OSPF
network. In these cases, you can configure the OSPF network type as a point-to-multipoint network.
Routing between two routers that are not directly connected will go through the router that has
virtual circuits to both routers. Note that you do not need to configure neighbors when using this
feature.
An OSPF point-to-multipoint interface is defined as a numbered point-to-point interface having one
or more neighbors. It creates multiple host routes. An OSPF point-to-multipoint network has the
following benefits compared to nonbroadcast multiaccess and point-to-point networks:
• Point-to-multipoint is easier to configure because it requires no configuration of neighbor
commands, it consumes only one IP subnet, and it requires no designated router election.
• It costs less because it does not require a fully-meshed topology.
• It is more reliable because it maintains connectivity in the event of virtual circuit failure.
To configure your OSPF network type, perform the following task in interface configuration mode:
Task Command
Configure the OSPF network type for a specified ip ospf network {broadcast | non-broadcast |
interface. point-to-multipoint}
For an example of an OSPF point-to-multipoint network, see the section “OSPF Point-to-Multipoint
Example” at the end of this chapter.
Configure OSPF for Nonbroadcast Networks

Because there might be many routers attached to an OSPF network, a designated router is selected
for the network. It is necessary to use special configuration parameters in the designated router
selection if broadcast capability is not configured.
These parameters need only be configured in those routers that are themselves eligible to become
the designated router or backup designated router (in other words, routers with a nonzero router
priority value).
To configure routers that interconnect to nonbroadcast networks, perform the following task in router
configuration mode
Task Command
Configure routers interconnecting to neighbor ip-address [priority number] [poll-interval
nonbroadcast networks. seconds]
You can specify the following neighbor parameters, as required:

• Priority for a neighboring router
• Nonbroadcast poll interval
• Interface through which the neighbor is reachable
Configure OSPF Area Parameters

Our OSPF software allows you to configure several area parameters. These area parameters, shown
in the following table, include authentication, defining stub areas, and assigning specific costs to the
default summary route. Authentication allows password-based protection against unauthorized
access to an area.

Configure OSPF
Stub areas are areas into which information on external routes is not sent. Instead, there is a default
external route generated by the area border router into the stub area for destinations outside the
autonomous system. To further reduce the number of link state advertisements (LSA) sent into a stub
area, you can configure no-summary on the Area Border Router (ABR) to prevent it from sending
summary link advertisement (LSA type 3) into the stub area.
In router configuration mode, specify any of the following area parameters as needed for your
network:
Task Command
Enable authentication for an OSPF area. area area-id authentication
Enable MD5 authentication for an OSPF area. area area-id authentication message-digest
Define an area to be a stub area. area area-id stub [no-summary]
Assign a specific cost to the default summary area area-id default-cost cost
route used for the stub area.
Configure Route Summarization between OSPF Areas

Route summarization is the consolidation of advertised addresses. This feature causes a single
summary route to be advertised to other areas by an area border router. In OSPF, an area border
router will advertise networks in one area into another area. If the network numbers in an area are
assigned in a way such that they are contiguous, you can configure the area border router to advertise
a summary route that covers all the individual networks within the area that fall into the specified
range.
To specify an address range, perform the following task in router configuration mode:
Task Command
Specify an address range for which a single route area area-id range address mask
will be advertised.
Configure Route Summarization when Redistributing Routes into OSPF

When redistributing routes from other protocols into OSPF (as described in the section “Configure
Routing Protocol-Independent Features” later in this chapter, each route is advertised individually
in an external link state advertisement (LSA). However, you can configure the router to advertise a
single route for all the redistributed routes that are covered by a specified network address and mask.
Doing so helps decrease the size of the OSPF link state database.
To have the router advertise one summary route for all redistributed routes covered by a network
address and mask, perform the following task in router configuration mode:
Task Command
Specify an address and mask that covers summary-address address mask
redistributed routes, so only one summary route is
advertised.
Create Virtual Links

In OSPF, all areas must be connected to a backbone area. If there is a break in backbone continuity,
or the backbone is purposefully partitioned, you can establish a virtual link. The two end points of a
virtual link are Area Border Routers. The virtual link must be configured in both routers. The

Configure OSPF
configuration information in each router consists of the other virtual endpoint (the other Area Border
Router), and the nonbackbone area that the two routers have in common (called the transit area).
Note that virtual links cannot be configured through stub areas.
To establish a virtual link, perform the following task in router configuration mode:
Task Command
Establish a virtual link. area area-id virtual-link router-id [hello-interval seconds]
[retransmit-interval seconds] [transmit-delay seconds]
[dead-interval seconds] [[authentication-key key] |
[message-digest-key keyid md5 key]]
To display information about virtual links, use the show ip ospf virtual-links EXEC command. To
display the router ID of an OSPF router, use the show ip ospf EXEC command.
Generate a Default Route

You can force an autonomous system boundary router to generate a default route into an OSPF
routing domain. Whenever you specifically configure redistribution of routes into an OSPF routing
domain, the router automatically becomes an autonomous system boundary router. However, an
autonomous system boundary router does not, by default, generate a default route into the OSPF
routing domain.
To force the autonomous system boundary router to generate a default route, perform the following
Task Command
Force the autonomous system boundary router default-information originate [always] [metric
to generate a default route into the OSPF metric-value] [metric-type type-value] [route-map
routing domain. map-name]
See also the discussion of redistribution of routes in the “Configure Routing Protocol-Independent
Features” section later in this chapter.
Configure Lookup of DNS Names

You can configure OSPF to look up Domain Name System (DNS) names for use in all OSPF show
command displays. This feature makes it easier to identify a router, because it is displayed by name
rather than by its router ID or neighbor ID.
To configure DNS name lookup, perform the following task in global configuration mode:
Task Command
Configure DNS name lookup. ip ospf name-lookup
Force the Router ID Choice with a Loopback Interface

OSPF uses the largest IP address configured on the router’s interfaces as its router ID. If the interface
associated with this IP address is ever brought down, or if the address is removed, the OSPF process
must recalculate a new router ID and resend all of its routing information out its interfaces.

Configure OSPF
If a loopback interface is configured with an IP address, the router will use this IP address as its
router ID, even if other interfaces have larger IP addresses. Since loopback interfaces never go down,
greater stability in the routing table is achieved.
OSPF automatically prefers a loopback interface over any other kind, and it chooses the highest IP
address among all loopback interfaces in the router. If no loopback interfaces are present, the highest
IP address in the router is chosen. You cannot tell OSPF to use any particular interface.
To configure an IP address on a loopback interface, perform the following tasks, starting in global
configuration mode:
Task Command
Step 1 Create a loopback interface, which interface loopback 01
places you in interface configuration
mode.
Step 2 Assign an IP address to this interface. ip address address mask2
1. This command is documented in the “Interface Commands” chapter of the Router Products Command Reference
publication.
2. This command is documented in the “IP Commands” chapter of the Router Products Command Reference publication.
Disable Default OSPF Metric Calculation Based on Bandwidth

In Cisco IOS Release 10.2 and earlier, OSPF assigned default OSPF metrics to interfaces regardless
of the interface bandwidth. It gave both 64K and T1 links the same metric (1562), and thus required
an explicit ip ospf cost command in order to take advantage of the faster link.
In Cisco IOS Release 10.3, by default, OSPF calculates the OSPF metric for an interface according
to the bandwidth of the interface. For example, a 64K link gets a metric of 1562, while a T1 link gets
a metric of 64. To disable this feature, perform the following task in router configuration mode:
Task Command
Disable default OSPF metric calculations based on no ospf auto-cost-determination
interface bandwidth, resulting in a fixed default
metric assignment.
Configure OSPF on Simplex Ethernet Interfaces

Because simplex interfaces between two routers on an Ethernet represent only one network segment,
for OSPF you have to configure the transmitting interface to be a passive interface. This prevents
OSPF from sending hello packets for the transmitting interface. Both routers are able to see each
other via the hello packet generated for the receiving interface.
To configure OSPF on simplex Ethernet interfaces, perform the following task in router
configuration mode:
Task Command
Suppress the sending of hello packets through passive-interface type number
the specified interface.

Configure RIP
Configure Route Calculation Timers

You can configure the delay time between when OSPF receives a topology change and when it starts
a Shortest Path First (SPF) calculation. You can also configure the hold time between two
consecutive SPF calculations. To do this, perform the following task in router configuration mode:
Task Command
Configure route calculation timers. timers spf spf-delay spf-holdtime
Configure RIP
The Routing Information Protocol (RIP) is a relatively old but still commonly used IGP created for
use in small, homogeneous networks. It is a classical distance-vector routing protocol.
RIP uses broadcast User Datagram Protocol (UDP) data packets to exchange routing information.
Each router sends routing information updates every 30 seconds; this process is termed advertising.
If a router does not receive an update from another router for 180 seconds or more, it marks the
routes served by the nonupdating router as being unusable. If there is still no update after 240
seconds, the router removes all routing table entries for the nonupdating router.
The measure, or metric, that RIP uses to rate the value of different routes is the hop count. The hop
count is the number of routers that can be traversed in a route. A directly connected network has a
metric of zero; an unreachable network has a metric of 16. This small range of metrics makes RIP
unsuitable as a routing protocol 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 network 0.0.0.0 does not
exist; RIP treats 0.0.0.0 as a network to implement the default routing feature. Our routers will
advertise 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 the specified networks. If an interface’s network is not
specified, it will not be advertised in any RIP update.
For information about filtering RIP information, see the “Filter Routing Information” section later
in this chapter. RIP is documented in RFC 1058.
To configure RIP, perform the following tasks, starting in global configuration mode:
Task Command
Step 1 Enable a RIP routing process, which router rip
Step 2 Associate a network with a RIP routing network network-number
process.
Running IGRP and RIP Concurrently

It is possible to run IGRP and RIP concurrently. The IGRP information will override the RIP
information by default because of IGRP’s administrative distance.
However, running IGRP and RIP concurrently does not work well when the network topology
changes. Because IGRP and RIP have different update timers and because they require different
amounts of time to propagate routing updates, one part of the network will end up believing IGRP
routes and another part will end up believing RIP routes. This will result in routing loops. Even
though these loops do not exist for very long, the time to live (TTL) will quickly reach zero, and
ICMP will send a “TTL exceeded” message. This message will cause most applications to stop
attempting network connections.

Configure IS-IS
Validate Source IP Addresses

To disable the default function that validates the source IP addresses of incoming routing updates,
Task Command
Disable the checking and validation of the source no validate-update-source
IP address of incoming routing updates.
Allow Point-to-Point Updates for RIP

Because RIP is normally a broadcast protocol, in order for RIP routing updates to reach
point-to-point or nonbroadcast networks, you must configure the router to permit this exchange of
routing information.
You configure the router to permit this exchange of routing information by performing the following
Task Command
Define a neighboring router with which to neighbor ip-address
exchange point-to-point routing information.
To control the set of interfaces that you want to exchange routing updates with, you can disable the
sending of routing updates on specified interfaces by configuring the passive-interface command.
See the discussion on filtering in the section in this chapter titled “Filter Routing Information.”
Configure Interpacket Delay

By default, the software adds no delay between packets in a multiple-packet RIP update being sent.
If you have a high-end router sending to a low-speed router, you might want to add such interpacket
delay to RIP updates, in the range of 8 to 50 milliseconds. To do so, perform the following task in
router configuration mode:
Task Command
Add interpacket delay for RIP updates sent. output-delay delay
Configure IS-IS
IS-IS, which stands for Intermediate System-to-Intermediate System, is an International
Organization for Standardization (ISO) dynamic routing specification. IS-IS is described in
ISO 10589. Cisco’s implementation of IS-IS allows you to configure IS-IS as an IP routing protocol
on your router.
IS-IS Configuration Task List

To configure IS-IS, complete the tasks in the following sections. Only enabling IS-IS is required; the
remainder of the tasks are optional although you might be required to perform them depending upon
your specific application.
• Enable IS-IS
• Configure IS-IS Interface Parameters
• Configure Miscellaneous IS-IS Parameters
Configure IS-IS
In addition, you can filter routing information (see the task “Filter Routing Information” later in this
chapter for information on how to do this), and specify route redistribution (see the task
“Redistribute Routing Information” later in this chapter for information on how to do this).
Enable IS-IS
As with other routing protocols, enabling IS-IS requires that you create an IS-IS routing process and
assign it to specific networks. You can specify only one IS-IS process per router. Only one IS-IS
process is allowed whether you run it in integrated mode, ISO CLNS only, or IP only.
Network Entity Titles (NETs) define the area addresses for the IS-IS area. Multiple NETs per router
are allowed, up to a maximum of three. Refer to the “Configuring ISO CLNS” chapter for a more
detailed discussion of NETs.
To enable IS-IS on the router, perform the following tasks starting in global configuration mode:
Task Command
Step 1 Enable IS-IS routing and specify an router isis [tag]
IS-IS process for IP, which places you in
router configuration mode.
Step 2 Configure NETs for the routing process; net network-entity-title
you can specify a name for a NET as
well as an address.
Step 3 Enter interface configuration mode. interface type number
Step 4 Specify the interfaces that should be ip router isis [tag]
actively routing IS-IS.
See the section “Configuring IS-IS as an IP Routing Protocol Example” at the end of this chapter.
Configure IS-IS Interface Parameters

Our IS-IS implementation allows you to alter certain interface-specific IS-IS parameters. You can do
the following:
• Configure IS-IS link state metrics
• Set the advertised hello interval
• Set the advertised CSNP interval
• Set the retransmission interval
• Specify designated router election
• Specify the interface circuit type
• Assign a password for an interface
You are not required to alter any of these parameters, but some interface parameters must be
consistent across all routers in an attached network. Therefore, be sure that if you do configure any
of these parameters, the configurations for all routers on the network have compatible values.

Configure IS-IS
Configure IS-IS Link-State Metrics

You can configure a cost for a specified interface. The only metric that is supported by the router and
that you can configure is the default-metric, which you can configure for Level 1 and/or Level 2
routing. The other metrics currently are not supported.
To configure the metric for the specified interface, perform the following task in interface
configuration mode:
Task Command
Configure the metric (or cost) for the specified isis metric default-metric [delay-metric [expense-metric
interface. [error-metric]]] {level-1 | level-2}
Set the Advertised Hello Interval

You can specify the length of time, in seconds, between hello packets that the router sends on the
interface.
To specify the length of time between hello packets for the specified interface, perform the following
task in interface configuration mode:
Task Command
Specify the length of time, in seconds, between isis hello-interval seconds {level-1 | level-2}
hello packets the router sends on the specified
interface.
The hello interval can be configured independently for Level 1 and Level 2, except on serial
point-to-point interfaces. (Because there is only a single type of hello packet sent on serial links, it
is independent of Level 1 or Level 2.) Specify an optional level for X.25, SMDS, and Frame Relay
multiaccess networks.
Set the Advertised CSNP Interval

Complete Sequence Number PDUs (CSNPs) are sent by the designated router to maintain database
synchronization. You can configure the IS-IS CSNP interval for the interface.
To configure the CSNP interval for the specified interface, perform the following task in interface
configuration mode:
Task Command
Configure the IS-IS CSNP interval for the isis csnp-interval seconds {level-1 | level-2}
specified interface.
This feature does not apply to serial point-to-point interfaces. It applies to WAN connections if the
WAN is viewed as a multiaccess meshed network.
Set the Retransmission Interval

You can configure the number of seconds between retransmission of IS-IS link state PDUs (LSPs)
for point-to-point links.

Configure IS-IS
To set the retransmission level, perform the following task in interface configuration mode:
Task Command
Configure the number of seconds between isis retransmit-interval seconds
retransmission of IS-IS LSPs for point-to-point
links.
The value you specify should be an integer greater than the expected round-trip delay between any
two routers on the attached network. The setting of this parameter should be conservative, or
needless retransmission will result. The value should be larger for serial lines and virtual links.
Specify Designated Router Election

You can configure the priority to use for designated router election. Priorities can be configured for
Level 1 and Level 2 individually.
To specify the designated router election, perform the following task in interface configuration
mode:
Task Command
Configure the priority to use for designated isis priority value {level-1 | level-2}
router election.
Specify the Interface Circuit Type

You can specify adjacency levels on a specified interface. This parameter is also referred to as the
interface circuit type.
To specify the interface circuit type, perform the following task in interface configuration mode:
Task Command
Configure the type of adjacency desired for isis circuit-type {level-1 | level-1-2 | level-2-only}
neighbors on the specified interface (the
interface circuit type).
Assign a Password for an Interface

You can assign different passwords for different routing levels. Specifying Level 1 or Level 2
configures the password for only Level 1 or Level 2 routing, respectively. If you do not specify a
level, the default is Level 1. By default, authentication is disabled.
To configure a password for the specified level, perform the following task in interface configuration
mode:
Task Command
Configure the authentication password for a isis password password {level-1 | level-2}
specified interface.
Configure Miscellaneous IS-IS Parameters

You can configure the following miscellaneous, optional IS-IS parameters:
• Generate a Default Route

Configure IS-IS
• Specify Router-Level Support

• Configure IS-IS Authentication Passwords
• Summarize Address Ranges
Generate a Default Route

You can force a default route into an IS-IS routing domain. Whenever you specifically configure
redistribution of routes into an IS-IS routing domain, the router does not, by default, generate a
default route into the IS-IS routing domain. The following feature allows you to force the boundary
router do this.
To generate a default route, perform the following task in router configuration mode:
Task Command
Force a default route into the IS-IS routing default-information originate [route-map map-name]
domain.
See also the discussion of redistribution of routes in the “Configure Routing Protocol-Independent
Features” section later in this chapter.
Specify Router-Level Support

You can configure the router to act as a Level 1 (intra-area) router, as both a Level 1 router and a
Level 2 (interarea) router, or as an interarea router only.
To specify router level support, perform the following task in router configuration mode:
Task Command
Configure the level at which the router should is-type {level-1 | level-1-2 | level-2-only}
operate.
Configure IS-IS Authentication Passwords

You can assign passwords to areas and domains.
The area authentication password is inserted in Level 1 (station router level) LSPs, CSNPs, and
Partial Sequence Number PDUs (PSNPs). The routing domain authentication password is inserted
in Level 2 (the area router level) LSP, CSNP, and PSNPs.
To configure either area or domain authentication passwords, perform the following tasks in router
configuration mode:
Task Command
Configure the area authentication password. area-password password
Configure the routing domain authentication domain-password password
password.
Summarize Address Ranges

You can create aggregate addresses that are represented in the routing table by a summary address.
This process is called route summarization. One summary address can include multiple groups of
addresses for a given level. Routes learned from other routing protocols also can be summarized. The
metric used to advertise the summary is the smallest metric of all the more specific routes.

Configure BGP
To create a summary of addresses for a given level, perform the following task in router
configuration mode:
Task Command
Create a summary of addresses for a given summary-address address mask {level-1 | level-1-2 |
level. level-2}
Configure BGP
The Border Gateway Protocol (BGP), as defined in RFCs 1163 and 1267, allows you to set up an
interdomain routing system that automatically guarantees the loop-free exchange of routing
information between autonomous systems.
Cisco’s BGP Implementation

In BGP, each route consists of a network number, a list of autonomous systems that information has
passed through (called the autonomous system path), and a list of other path attributes. We support
BGP Versions 2, 3, and 4, as defined in RFCs 1163, 1267, and 1771, respectively.
The primary function of a BGP system is to exchange network reachability information with other
BGP systems, including information about the list of autonomous system paths. This information
can be used to construct a graph of autonomous system connectivity from which routing loops can
be pruned and with which autonomous system-level policy decisions can be enforced.
You can configure the value for the Multi Exit Discriminator (MED) metric attribute using route
maps. (The name of this metric for BGP Versions 2 and 3 is INTER_AS_METRIC.) When an update
is sent to an IBGP peer, the MED is passed along without any change. This action enables all the
peers in the same autonomous system to make a consistent path selection.
A third-party next-hop router address is used in the NEXT_HOP attribute, regardless of the
autonomous system of that third-party router. The router automatically calculates the value for this
attribute.
Transitive, optional path attributes are passed along to other BGP-speaking routers.
BGP Version 4 supports classless interdomain routing (CIDR), which lets you 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. CIDR routes can be
carried by OSPF, EIGRP, and ISIS-IP.
See the section “BGP Route Map Examples” for examples of how to use route maps to redistribute
BGP Version 4 routes.
How BGP Selects Paths

A router running Cisco IOS Release 12.0 or later does not select or use an IBGP route unless both
of the following are true:
• the router has a route available to the next-hop router
• the router has received synchronization via an IGP (unless IGP synchronization has been
disabled)
BGP bases its decision process on the attribute values. When faced with multiple routes to the same
destination, BGP chooses the best route for routing traffic toward the destination. The following
process summarizes how BGP chooses the best route.

Configure BGP
1 If the next hop is inaccessible, do not consider it.
This is why it is important to have an IGP route to the next hop.

2 If the path is internal, synchronization is enabled, and the route is not in the IGP, do not consider
the route.
3 Prefer the path with the largest weight (weight is a Cisco proprietary parameter).
4 If the routes have the same weight, prefer the route with the largest local preference.
5 If the routes have the same local preference, prefer the route that was originated by the local
router.
For example, a route might be originated by the local router using the network bgp command,
or through redistribution from an IGP.
6 If the local preference is the same, or if no route was originated by the local router, prefer the
route with the shortest autonomous system path.
7 If the autonomous system path length is the same, prefer the route with the lowest origin code
(IGP < EGP < INCOMPLETE).
8 If the origin codes are the same, prefer the route with the lowest Multi Exit Discriminator (MED)
metric attribute.
This comparison is only done if the neighboring autonomous system is the same for all routes
considered, unless bgp always-compare-med is enabled.
9 Prefer an external (EBGP) path over an internal (IBGP) path.
All confederation paths are considered internal paths.

10 Prefer the route that can be reached through the closest IGP neighbor (the lowest IGP metric).
This means the router will prefer the shortest internal path within the autonomous system to reach
the destination (the shortest path to the BGP next-hop).
11 If the following 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.
Note EBGP load sharing can occur at this point, which means that multiple paths can be
installed in the forwarding table.
12 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.
BGP Configuration Task List

The tasks in this section are divided into basic and advanced BGP configuration tasks. The first three
basic tasks are required to configure BGP; the remaining basic and advanced tasks are optional.

Configure BGP
Basic BGP Configuration Tasks

• Enable BGP Routing
• Configure BGP Neighbors
• Reset BGP Connections
• Configure BGP Interactions with IGPs
• Configure BGP Administrative Weights
• Configure BGP Route Filtering by Neighbor
• Configure BGP Path Filtering by Neighbor
• Disable Next-Hop Processing on BGP Updates
• Configure the BGP Version
• Set the Network Weight
• Configure the Multi Exit Discriminator Metric
Advanced BGP Configuration Tasks

• Use Route Maps to Modify Updates
• Configure BGP Neighbor Templates
• Reset EBGP Connections Immediately Upon Link Failure
• Configure Aggregate Addresses
• Disable Automatic Summarization of Network Numbers
• Configure BGP Community Filtering
• Configure a Routing Domain Confederation
• Configure Neighbor Options
• Configure BGP Peer Groups
• Indicate Backdoor Routes
• Modify Parameters While Updating the IP Routing Table
• Set Administrative Distance
• Adjust BGP Timers
• Change the Local Preference Value
• Redistribute Network 0.0.0.0
• Base Path Selection on MEDs from Other Autonomous Systems
Basic BGP Tasks

This section describes the basic BGP configuration tasks.

Configure BGP
Enable BGP Routing

To enable BGP routing, establish a BGP routing process on the router by performing the following
steps starting in global configuration mode:
Task Command
Step 1 Enable a BGP routing process, which router bgp autonomous-system
Step 2 Flag a network as local to this network network-number [mask network-mask]
autonomous system and enter it to the
BGP table.
Note 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 (IGP), such as IGRP, which also use the network command to determine where to send
updates.
Note The network command is used to inject IGP routes into the BGP table. The network-mask
portion of the command allows supernetting and subnetting. A maximum of 200 entries of the
command are accepted. Alternatively, you could use the redistribute command to achieve the same
result.
Configure BGP Neighbors

Like other Exterior Gateway Protocols (EGPs), BGP must completely understand the relationships
it has with its neighbors. BGP supports two kinds of neighbors: internal and external. Internal
neighbors are in the same autonomous system; external neighbors are in different autonomous
systems. Normally, external neighbors are adjacent to each other and share a subnet, while internal
neighbors may be anywhere in the same autonomous system.
To configure BGP neighbors, perform the following task in router configuration mode:
Task Command
Specify a BGP neighbor. neighbor {ip-address | peer-group-name}
remote-as number
See an example of configuring BGP neighbors in the section “BGP Neighbor Configuration
Examples“ at the end of this chapter.
Reset BGP Connections

Once you have defined two routers to be BGP neighbors, they will form a BGP connection and
exchange routing information. If you subsequently change a BGP filter, weight, distance, version, or
timer, or make a similar configuration change, you need to reset BGP connections for the
configuration change to take effect. Perform either of the following tasks in EXEC mode to reset
BGP connections:
Task Command
Reset a particular BGP connection. clear ip bgp address

Configure BGP
Reset all BGP connections. clear ip bgp *
Log changes in neighbor status

You can specify that the system log a message when a BGP neighbor system’s status changes. The
neighbor status information shown in the log can be useful for troubleshooting network connectivity
problems and measuring network stability. Perform the following task in router configuration mode
to enable the logging of messages generated when a BGP neighbor resets, comes up, or goes down:
Task Command
Enable neighbor changes logging. bgp log-neighbor-changes
Use the show logging command to display the log for the BGP neighbor changes.
Configure BGP Interactions with IGPs

If your autonomous system will be passing traffic through it from another autonomous system to a
third autonomous system, it is very important that your autonomous system be consistent about the
routes that it advertises. For example, if your BGP were to advertise a route before all routers in your
network had learned about the route through your IGP, your autonomous system could receive traffic
that some routers cannot yet route. To prevent this from happening, BGP must wait until the IGP has
propagated routing information across your autonomous system. This causes BGP to be
synchronized with the IGP. Synchronization is enabled by default.
In some cases, you do not need synchronization. If you will not be passing traffic from a different
autonomous system through your autonomous system, or if all routers in your autonomous system
will be running BGP, you can disable synchronization. Disabling this feature can allow you to carry
fewer routes in your IGP and allow BGP to converge more quickly. To disable synchronization,
Task Command
Disable synchronization between BGP and an IGP. no synchronization
When you disable synchronization, you should also clear BGP sessions using the clear ip bgp
command.
See the section “BGP Synchronization Example” at the end of this chapter for an example of
synchronization.
In general, you will not want to redistribute most BGP routes into your IGP. A common design is to
redistribute one or two routes and to make them exterior routes in IGRP or have your BGP speaker
generate a default route for your autonomous system. When redistributing from BGP into IGP, only
the routes learned using EBGP get redistributed.
In most circumstances, you also will not want to redistribute your IGP into BGP. Just list the
networks in your autonomous system with network router configuration commands and your
networks will be advertised. Networks that are listed this way are referred to as local networks and
have a BGP origin attribute of “IGP.” They must appear in the main IP routing table and can have
any source; for example, they can be directly connected or learned via an IGP. The BGP routing
process periodically scans the main IP routing table to detect the presence or absence of local
networks, updating the BGP routing table as appropriate.

Configure BGP
If you do perform redistribution into BGP, you must be very careful about the routes that can be in
your IGP, especially if the routes were redistributed from BGP into the IGP elsewhere. This creates
a situation where BGP is potentially injecting information into the IGP and then sending such
information back into BGP and vice versa.
Networks that are redistributed into BGP from the EGP protocol will be given the BGP origin
attribute “EGP.” Other networks that are redistributed into BGP will have the BGP origin attribute
of “incomplete.” The origin attribute in our implementation is only used in the path selection
process.
Configure BGP Administrative Weights

An administrative weight is a number that you can assign to a path so that you can control the path
selection process. The administrative weight is local to the router. A weight can be a number from 0
to 65535. Paths that the router originates have weight 32768 by default, other paths have weight zero.
If you have particular neighbors that you want to prefer for most of your traffic, you can assign a
higher weight to all routes learned from that neighbor.
Perform the following task in router configuration mode to configure BGP administrative weights:
Task Command
Specify a weight for all routes from a neighbor. neighbor {ip-address | peer-group-name} weight weight
In addition, you can assign weights based on autonomous system path access lists. A given weight
becomes the weight of the route if the autonomous system path is accepted by the access list. Any
number of weight filters are allowed.
To assign weights based on autonomous system path access lists, perform the following tasks
starting in global configuration mode:
Task Command
Step 1 Define a BGP-related access list. ip as-path access-list access-list-number {permit |
deny} as-regular-expression
Step 2 Enter router configuration mode. router bgp autonomous-system
Step 3 Configure administrative weight on all neighbor ip-address filter-list access-list-number weight
incoming routes matching an weight
autonomous system path filter.
Configure BGP Route Filtering by Neighbor

If you want to restrict the routing information that the router learns or advertises, you can filter BGP
routing updates to and from particular neighbors. To do this, define an access list and apply it to the
updates. Distribute-list filters are applied to network numbers and not autonomous system paths.
To filter BGP routing updates, perform the following task in router configuration mode:
Task Command
Filter BGP routing updates to/from neighbors neighbor {ip-address | peer-group-name} distribute-list
as specified in an access list. access-list-number {in | out}

Configure BGP
Configure BGP Path Filtering by Neighbor

In addition to filtering routing updates based on network numbers, you can 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. To do this, define an autonomous system path
access list and apply it to updates to and from particular neighbors. See the “Regular Expressions”
appendix in the Router Products Command Reference publication for more information on forming
regular expressions.
To configure BGP path filtering, perform the following tasks starting in global configuration mode:
Task Command
Step 1 Define a BGP-related access list. ip as-path access-list access-list-number {permit |
deny} as-regular-expression
Step 2 Enter router configuration mode. router bgp autonomous-system
Step 3 Establish a BGP filter. neighbor {ip-address | peer-group-name} filter-list
access-list-number {in | out | weight weight}
See the example in the section “BGP Path Filtering by Neighbor Example” at the end of this chapter.
Disable Next-Hop Processing on BGP Updates

You can configure the router to disable next-hop processing for BGP updates to a neighbor. This
might be useful in non-meshed networks such as Frame Relay or X.25 where BGP neighbors might
not have direct access to all other neighbors on the same IP subnet.
To disable next-hop processing, perform the following task in router configuration mode:
Task Command
Disable next-hop processing on BGP updates to a neighbor {ip-address | peer-group-name}
neighbor. next-hop-self
Configuring the above command causes the current router to advertise itself as the next hop for the
specified neighbor. Therefore other BGP neighbors will forward to it packets for that address. This
is useful in a nonmeshed environment, since you know that a path exists from the present router to
that address. In a fully meshed environment, this is not useful since it will result in unnecessary extra
hops, because there might be a direct access through the fully meshed cloud with fewer hops.
Configure the BGP Version

By default, BGP sessions begin using BGP Version 4 and negotiating downward to earlier versions
if necessary. To prevent negotiation and force the BGP version used to communicate with a neighbor,
Task Command
Specify the BGP version to use when neighbor {ip-address | peer-group-name} version
communicating with a neighbor. value

Configure BGP
Set the Network Weight

Weight is a parameter that affects the best path selection process. To set the absolute weight for a
network, perform the following task in router configuration mode:
Task Command
Set the weight for a network. network address weight weight
Configure the Multi Exit Discriminator Metric

BGP uses the Multi Exit Discriminator (MED) metric as a hint to external neighbors about preferred
paths. (The name of this metric for BGP Versions 2 and 3 is INTER_AS_METRIC.) You can set the
MED of the redistributed routes by performing the following task. All of the routes without a MED
will also be set to this value. Perform the following task in router configuration mode:
Task Command
Set a multi exit discriminator. default-metric number
Alternatively, you can set the MED using the route-map command. See the section “BGP Route
Map Examples” at the end of this chapter.
Advanced BGP Configuration Tasks

This section contains advanced BGP configuration tasks.
Use Route Maps to Modify Updates

You can use a route map on a per neighbor basis to filter updates and 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 the inbound updates, we support matching on autonomous system path and community. On the
outbound updates, we support matching based on autonomous system path, community, and
network numbers. Autonomous system path matching requires the as-path access-list command,
community based matching requires the community-list command and network-based matching
requires the ip access-list command.
Perform the following task in router configuration mode:
Task Command
Apply a route map to incoming or outgoing routes. neighbor {ip-address | peer-group-name}
route-map route-map-name {in | out}
For examples, see the section “BGP Route Map Examples” at the end of this chapter.
Configure BGP Neighbor Templates

You can configure neighbor templates that use a word argument rather than an IP address to
configure BGP neighbors. During the initiation of a BGP session, the IP address of the neighbor is
checked against the access list and it must pass the access list to start the BGP session. You must

Configure BGP
keep in mind that the router configured with the template name is in a passive state for these
neighbors, which means it will not initiate sessions; rather it waits until a session is initiated to it and
then verifies based on the criteria mentioned above.
If you use the neighbor configure-neighbors command, all the neighbors that initiate a session to
the router and pass the neighbor-list are permanently entered into the configuration (NVRAM) upon
issuing the write memory command. (Note that the write memory command has been replaced by
the copy running-config startup-config command.)
Perform the following tasks in router configuration mode to configure BGP neighbor templates:
Task Command
Support anonymous neighbor peers by neighbor template-name neighbor-list
configuring a neighbor template. access-list-number
Treat neighbors that have been accepted by a neighbor template-name configure-neighbors
template as if they were configured by hand.
See the example in the section “Using Access Lists to Specify Neighbors” at the end of this chapter.
Reset EBGP Connections Immediately Upon Link Failure

Usually when a link between external neighbors goes down, the BGP session will not be reset
immediately. If you want the EBGP session to be reset as soon as an interface goes down, perform
the following task in router configuration mode:
Task Command
Automatically reset EBGP sessions. bgp fast-external-fallover
Configure Aggregate Addresses

Classless interdomain routing (CIDR) lets you 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 using the conditional aggregation feature described in the next task
table. An aggregate address will be added to the BGP table if there is at least one more specific entry
in the BGP table.
To create an aggregate address in the routing table, perform one or more of the following tasks in
Task Command
Create an aggregate entry in the BGP routing aggregate-address address mask
table.
Generate an aggregate with AS-SET. aggregate-address address mask as-set
Advertise summary addresses only. aggregate-address address-mask summary-only
Suppress selected, more specific routes. aggregate-address address mask suppress-map
map-name
For an example, see the section “BGP Aggregate Route Examples” at the end of this chapter.

Configure BGP
Disable Automatic Summarization of Network Numbers

In BGP Version 3, when a subnet is redistributed from an IGP into BGP, only the network route is
injected into the BGP table. By default, this automatic summarization is enabled. To disable
automatic network number summarization, perform the following task in router configuration mode:
Task Command
Disable automatic network summarization. no auto-summary
Configure BGP Community Filtering

BGP supports transit policies via controlled distribution of routing information. The distribution of
routing information is based on one of three values:
• IP address (see the section “Configure BGP Route Filtering by Neighbor” earlier in this chapter).
• The value of the AS_PATH attribute (see the section “Configure BGP Path Filtering by
Neighbor” earlier in this chapter).
• The value of the COMMUNITIES attribute (as described in this section).
The COMMUNITIES attribute is a way to group destinations into communities and apply routing
decisions based on the communities. This method simplifies a BGP speaker’s configuration that
controls distribution of routing information.
A community is a group of destinations that share some common attribute. Each destination can
belong to multiple communities. Autonomous system administrators can define which communities
a destination belongs to. By default, all destinations belong to the general Internet community. The
community is carried as the COMMUNITIES attribute.
The COMMUNITIES attribute is an optional, transitive, global attribute in the numerical range from
1 to 4,294,967,200. Along with Internet community, there are a few predefined, well-known
communities, as follows:
• 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).
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 you
learn, advertise, or redistribute routes. When routes are aggregated, the resulting aggregate has a
COMMUNITIES attribute that contains all communities from all the initial routes.
Community lists are used to create groups of communities to use in a match clause of a route map.
Just like 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 create a community list, perform the following task in global configuration mode:
Task Command
Create a community list. ip community-list community-list-number {permit |
deny} community-number
To set the COMMUNITIES attribute and match clauses based on communities, see the match
community-list and set community commands in the section “Redistribute Routing Information”
later in this chapter.

Configure BGP
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 performing the following task
in router configuration mode:
Task Command
Specify that the COMMUNITIES attribute be sent neighbor {ip-address | peer-group-name}
to the neighbor at this IP address. send-community
Configure a Routing Domain Confederation

One way to reduce the IBGP mesh is to divide an autonomous system into multiple autonomous
systems and group them into a single confederation. To the outside world, the confederation looks
like 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.
This enables to us to retain a single Interior Gateway Protocol (IGP) for all of the autonomous
systems.
To configure a BGP confederation, you must specify a confederation identifier. To the outside world,
the group of autonomous systems will look like a single autonomous system with the confederation
identifier as the autonomous system number. To configure a BGP confederation identifier, perform
the following tasks in router configuration mode:
Task Command
Configure a BGP confederation. bgp confederation identifier autonomous-system
In order to treat the neighbors from other autonomous systems within the confederation as special
EBGP peers, perform the following task in router configuration mode:
Task Command
Specify the autonomous systems that belong to the bgp confederation peers autonomous-system
confederation. [autonomous-system ...]
See the example configuration of several peers in a confederation in the section “BGP Confederation
Example“ at the end of this chapter.
Configure Neighbor Options

To provide BGP routing information to a large number of neighbors, you can configure BGP to
accept neighbors based on an access list. If a neighbor attempts to initiate a BGP connection, its
address must be accepted by the access list for the connection to be accepted. If you do this, the
router will not attempt to initiate a BGP connection to these neighbors, so the neighbors must be
explicitly configured to initiate the BGP connection. If no access list is specified, all connections are
accepted.
External BGP peers normally must reside on a directly connected network. Sometimes it is useful
to relax this restriction in order to test BGP; do so by specifying the neighbor ebgp-multihop
command.

Configure BGP
For internal BGP, you might want to allow your BGP connections to stay up regardless of which
interface is used to reach a neighbor. To do this, you first configure a loopback interface and assign
it an IP address. Next, configure the BGP update source to be the loopback interface. Finally,
configure your neighbor to use the address on the loopback interface. Now the IBGP session will be
up as long as there is a route, irrespective of any interface.
You can set the minimum interval of time between BGP routing updates.
You can invoke MD5 authentication between two BGP peers, meaning that each segment sent on the
TCP connection between them is verified. This feature must be configured with the same password
on both BGP peers; otherwise, the connection between them will not be made. The authentication
feature uses the MD5 algorithm. Invoking authentication causes the router to generate and check the
MD5 digest of every segment sent on the TCP connection. If authentication is invoked and a segment
fails authentication, a message appears on the console.
Configure any of the following neighbor options in router configuration mode:
Task Command
Specify an access list of BGP neighbors. neighbor any [access-list-number]
Allow internal BGP sessions to use any neighbor {ip-address | peer-group-name}
operational interface for TCP connections. update-source interface
Allow BGP sessions even when the neighbor is neighbor {ip-address | peer-group-name}
not on a directly connected segment. ebgp-multihop
Set the minimum interval between sending neighbor {ip-address | peer-group-name}
BGP routing updates. advertisement-interval seconds
Invoke MD5 authentication on a TCP neighbor {ip-address | peer-group-name} password
connection to a BGP peer. string
Configure BGP Peer Groups

Often in a BGP speaker, there are many neighbors configured with the same update policies (that is,
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 make updating
more efficient.
There are three steps to configuring a BGP peer group: creating the peer group, assigning
configuration options to the peer group, and making neighbors members of the peer group.
To create a BGP peer group, perform the following task in router configuration mode:
Task Command
Create a BGP peer group. neighbor peer-group-name peer-group
After you create a peer group, you configure the peer group with neighbor commands. By default,
members of the peer group inherit all of the configuration options of the peer group. Members can
also be configured to override the options that do not affect outbound updates.
Peer group members will always inherit the following: remote-as (if configured), version,
update-source, out-route-map, out-filter-list, out-dist-list, minimum-advertisement-interval, and
next-hop-self. All of the peer group members will inherit changes made to the peer group.

Configure BGP
To assign configuration options to the peer group, perform any of the following tasks in router
configuration mode:
Task Command
Specify that the COMMUNITIES attribute be sent neighbor {ip-address | peer-group-name}
to the neighbor at this IP address. send-community
Allow internal BGP sessions to use any operational neighbor {ip-address | peer-group-name}
interface for TCP connections. update-source interface
Allow BGP sessions even when the neighbor is not neighbor {ip-address | peer-group-name}
on a directly connected segment. ebgp-multihop
Set the minimum interval between sending BGP neighbor {ip-address | peer-group-name}
routing updates. advertisement-interval seconds
Invoke MD5 authentication on a TCP connection to neighbor {ip-address | peer-group-name}
a BGP peer. password string
Specify a BGP neighbor. neighbor {ip-address | peer-group-name}
remote-as number
Specify a weight for all routes from a neighbor. neighbor {ip-address | peer-group-name} weight
weight
Filter BGP routing updates to/from neighbors as neighbor {ip-address | peer-group-name}
specified in an access list. distribute-list access-list-number {in | out}
Establish a BGP filter. neighbor {ip-address | peer-group-name}
filter-list access-list-number {in | out | weight
weight}
Disable next-hop processing on BGP updates to a neighbor {ip-address | peer-group-name}
neighbor. next-hop-self
Specify the BGP version to use when neighbor {ip-address | peer-group-name} version
communicating with a neighbor. value
Apply a route map to incoming or outgoing routes. neighbor {ip-address | peer-group-name}
route-map route-map-name {in | out}
If a peer group is not configured with a remote-as, the members can be configured with the
neighbor ip-address | peer-group-name remote-as command. This allows you to create peer groups
containing EBGP neighbors.
Finally, to configure a BGP neighbor to be a member of that BGP peer group, perform the following
task in router configuration mode, using the same peer group name:
Task Command
Make a BGP neighbor a member of the peer group. neighbor ip-address peer-group peer-group-name
For examples of IBGP and EBGP peer groups, see the section “BGP Peer Group Examples” at the
end of this chapter.

Configure BGP
Indicate Backdoor Routes

You can indicate which networks are reachable using a backdoor route that the border router should
use. A backdoor network is treated as a local network, except that it is not advertised. To configure
backdoor routes, perform the following task in router configuration mode:
Task Command
Indicate reachable networks through backdoor network address backdoor
routes.
Modify Parameters While Updating the IP Routing Table

By default, when a BGP route is put into the IP routing table, the MED is converted to an IP route
metric, the BGP next hop is used as the next hop for the IP route, and the tag is not set. However,
you can use a route map to perform mapping. To modify metric and tag information when the IP
routing table is updated with BGP learned routes, perform the following task in router configuration
mode:
Task Command
Apply route-map to routes when updating the table-map route-map name
IP routing table.
Set Administrative Distance

Administrative distance is a measure of the preference of different routing protocols. BGP uses three
different administrative distances—external, internal, and local. Routes learned through external
BGP are given the external distance, routes learned with internal BGP are given the internal distance,
and routes that are part of this autonomous system are given the local distance. To assign a BGP
administrative distance, perform the following task in router configuration mode:
Task Command
Assign a BGP administrative distance. distance bgp external-distance internal-distance
local-distance
Changing the administrative distance of BGP routes is considered dangerous and generally is not
recommended. The external distance should be lower than any other dynamic routing protocol, and
the internal and local distances should be higher than any other dynamic routing protocol.
Adjust BGP Timers

BGP uses certain timers to control periodic activities such as the sending of keepalive messages and
the interval after not receiving a keepalive message after which the router declares a peer dead. You
can adjust these timers. When a connection is started, BGP will negotiate the hold time with the
neighbor. The smaller of the two hold times will be chosen. The keepalive timer is then set based on
the negotiated holdtime and the configured keepalive time. To adjust BGP timers, perform the
Task Command
Adjust BGP timers. timers bgp keepalive holdtime

Configure EGP
Change the Local Preference Value

You can define a particular path as more or less preferable than other paths by changing the default
local preference value of 100. To assign a different default local preference value, perform the
Task Command
Change the default local preference value. bgp default local-preference value
You can use route maps to change the default local preference of specific paths. See the section
“BGP Route Map Examples” for examples.
Redistribute Network 0.0.0.0

By default, you are not allowed to redistribute network 0.0.0.0. To permit the redistribution of
network 0.0.0.0, perform the following task in router configuration mode:
Task Command
Allow the redistribution of network 0.0.0.0 into default-information originate
BGP.
Base Path Selection on MEDs from Other Autonomous Systems

The MED is one of the parameters that is considered when selecting the best path among many
alternative paths. The path with a lower MED is preferred over a path with a higher MED.
By default, during the best path selection process, MED comparison is done only among paths from
the same autonomous system. You can allow comparison of MEDs among paths regardless of the
autonomous system from which the paths are received. To do so, perform the following task in router
configuration mode:
Task Command
Allow the comparison of MEDs for paths from bgp always-compare-med
neighbors in different autonomous systems.
Configure EGP
The Exterior Gateway Protocol (EGP), specified in RFC 904, is an older EGP used for
communicating with certain routers in the Defense Data Network (DDN) that the U.S. Department
of Defense designates as core routers. EGP also was used extensively when attaching to the National
Science Foundation Network (NSFnet) and other large backbone networks.
An exterior router uses EGP to advertise its knowledge of routes to networks within its autonomous
system. It sends these advertisements to the core routers, which then readvertise their collected
routing information to the exterior router. A neighbor or peer router is any router with which the
router communicates using EGP.
Cisco’s EGP Implementation

Cisco’s implementation of EGP supports three primary functions, as specified in RFC 904:
• Routers running EGP establish a set of neighbors, and these neighbors share reachability
information.

Configure EGP
• EGP routers poll their neighbors periodically to see if they are “alive.”
• EGP routers send update messages containing information about the reachability of networks
within their autonomous systems.
EGP Configuration Task List

To enable EGP routing on your router, complete the tasks in the following sections. The tasks in the
first two sections are mandatory; the remaining tasks are optional.
• Enable EGP Routing
• Configure EGP Neighbor Relationships
• Adjust EGP Timers
• Configure Third-Party EGP Support
• Configure Backup Routers
• Configure Default Routes
• Define a Central Routing Information Manager (Core Gateway)
Enable EGP Routing

To enable EGP routing, you must specify an autonomous system number, generate an EGP routing
process, and indicate the networks for which the EGP process will operate.
To enable EGP routing, perform the following tasks starting in global configuration mode:
Task Command
Step 1 Specify the autonomous system that the autonomous-system local-as
router resides in for EGP.
Step 2 Enable an EGP routing process, which router egp remote-as
Step 3 Specify a network to be advertised to the network network-number
EGP peers of an EGP routing process.
Note For exterior gateway protocols, a reference to an IP network from the network router
configuration command that is learned by another routing protocol does not require a redistribute
router configuration command. This is in contrast to interior gateway protocols, such as IGRP, which
require the use of the redistribute command.
Configure EGP Neighbor Relationships

A router using EGP cannot dynamically determine its neighbor or peer routers. You must therefore
provide a list of neighbor routers.
To specify an EGP neighbor, perform the following task in router configuration mode:
Task Command
Specify an EGP neighbor. neighbor ip-address

Configure EGP
Adjust EGP Timers

The EGP timers consist of a hello timer and a poll time interval timer. The hello timer determines
the frequency in seconds with which the router sends hello messages to its peer. The poll time is how
frequently to exchange updates. Our implementation of EGP allows these timers to be adjusted by
the user.
To adjust EGP timers, perform the following task in router configuration mode:
Task Command
Adjust EGP timers. timers egp hello polltime
Configure Third-Party EGP Support

EGP supports a third-party mechanism in which EGP tells an EGP peer that another router (the third
party) on the shared network is the appropriate router for some set of destinations.
To specify third-party routers in updates, perform the following task in router configuration mode:
Task Command
Specify a third-party through which certain neighbor ip-address third-party third-party-ip-address
destinations can be achieved. [internal | external]
See the “Third-Party EGP Support Example” section at the end of this chapter for an example of
configuring third-party EGP support.
Configure Backup Routers

You might want to provide backup in the event of site failure by having a second router belonging
to a different autonomous system act as a backup to the EGP router for your autonomous system. To
differentiate between the primary and secondary EGP routers, the two routers will advertise network
routes with differing EGP distances or metrics. A network with a low metric is generally favored
over a network with a high metric.
Networks declared as local are always announced with a metric of zero. Networks that are
redistributed will be announced with a metric specified by the user. If no metric is specified,
redistributed routes will be advertised with a metric of three. All redistributed networks will be
advertised with the same metric. The redistributed networks can be learned from static or dynamic
routes. See also the “Redistribute Routing Information” section later in this chapter.
See the “Backup EGP Router Example” section at the end of this chapter for an example of
configuring backup routers.
Configure Default Routes

You also can designate network 0.0.0.0 as a default route. If the next hop for the default route can be
advertised as a third party, it will be included as a third party.
To enable the use of default EGP routes, perform the following task in router configuration mode:
Task Command
Configure EGP to generate a default route. default-information originate

Configure GDP
Define a Central Routing Information Manager (Core Gateway)

Normally, an EGP process expects to communicate with neighbors from a single autonomous
system. Because all neighbors are in the same autonomous system, the EGP process assumes that
these neighbors all have consistent internal information. Therefore, if the EGP process is informed
about a route from one of its neighbors, it will not send it out to other neighbors.
With core EGP, the assumption is that all neighbors are from different autonomous systems, and all
have inconsistent information. In this case, the EGP process distributes routes from one neighbor to
all others (but not back to the originator). This allows the EGP process to be a central clearinghouse
for information with a single, central manager of routing information (sometimes called a core
gateway). To this end, one core gateway process can be configured for each router.
To define a core gateway process, perform the following tasks starting in global configuration mode:
Task Command
Step 1 Allow a specific router to act as a peer router egp 0
with any reachable autonomous system.
Step 2 Define how an EGP process determines neighbor any [access-list-number]
which neighbors will be treated as peers.
or
Allow the specified address to be used as
the next hop in EGP advertisements. neighbor any third-party ip-address [internal |
external]
The EGP process defined in this way can act as a peer with any autonomous system, and information
is interchanged freely between autonomous systems.
See the “EGP Core Gateway Example” section at the end of this chapter for an example of
configuring an EGP core gateway.
Note Split horizon is performed only on a per-gateway basis (in other words, if an external router
informs the router about a specific network, and that router is the best path, the router will not inform
the originating external router about that path). Our routers can also perform per-gateway split
horizon on third-party updates.
Configure GDP
The Gateway Discovery Protocol (GDP), designed by Cisco to address customer needs, allows hosts
to dynamically detect the arrival of new routers, as well as determine when a router goes down. You
must have host software to take advantage of this protocol.
For ease of implementation on a variety of host software, GDP is based on the User Datagram
Protocol (UDP). The UDP source and destination ports of GDP datagrams are both set to 1997
(decimal).
There are two types of GDP messages: report and query. On broadcast media, report message
packets are periodically sent to the IP broadcast address announcing that the router is present and
functioning. By listening for these report packets, a host can detect a vanishing or appearing router.
If a host issues a query packet to the broadcast address, the routers each respond with a report sent
to the host’s IP address. On nonbroadcast media, routers send report message packets only in
response to query message packets. The protocol provides a mechanism for limiting the rate at which
query messages are sent on nonbroadcast media.

Configure GDP
Figure 19-2 shows the format of the GDP report message packet format. A GDP query message
packet has a similar format, except that the count field is always zero and no address information is
present.
Figure 19-2 GDP Report Message Packet Format

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Version Opcode Count Reserved
Address 1
Priority 1 Hold time 1
Address 2
Priority 2 Hold time 2
Address / priority / Hold time fields repeated count times
S1029a
The fields in the Report and Query messages are as follows:
• Version—8-bit field containing the protocol version number. The current GDP version number
is 1. If an unrecognized version number is found, the GDP message must be ignored.
• Opcode—8-bit field that describes the GDP message type. Unrecognized opcodes must be
ignored. Opcode 1 is a report message and opcode 2 is a query message.
• Count—8-bit field that contains the number of address, priority, and hold time types in this
message. A query message has a Count field value of zero. A report message has a count field
value of 1 or greater.
• Reserved—8-bit reserved field; it must be set to zero.
• Address—32-bit fields containing the IP address of a router on the local network segment. There
are no other restrictions on this address. If a host encounters an address that it believes is not on
its local network segment, it should ignore that address.
• Priority—16-bit fields that indicate the relative quality of the associated address. The
numerically larger the value in the priority field, the better the address should be considered.
• Hold Time—16-bit fields. On broadcast media, the number of seconds the associated address
should be used as a router without hearing further report messages regarding that address. On
nonbroadcast media such as X.25, this is the number of seconds the requester should wait before
sending another query message.
Numerous actions can be taken by the host software listening to GDP packets. One possibility is to
flush the host’s ARP cache whenever a router appears or disappears. A more complex possibility is
to update a host routing table based on the coming and going of routers. The particular course of
action taken depends on the host software and your network requirements.

Configure IRDP
To enable GDP routing and other optional GDP tasks as required for your network, perform the
following tasks in interface configuration mode:
Task Command
Enable GDP processing on an interface. ip gdp
Set the relative quality of the associated address. ip gdp priority number
Set the GDP report period. ip gdp reporttime seconds
Set the length of time the associated address ip gdp holdtime seconds
should be used as a router without hearing further
report messages regarding that address.
Configure IRDP
Like GDP, the ICMP Router Discovery Protocol (IRDP) allows hosts to locate routers. When
operating as a client, router discovery packets are generated, and when operating as a host, router
discovery packets are received.
The only required task for configuring IRDP routing on a specified interface is to enable IRDP
processing on an interface. Perform the following task in interface configuration mode:
Task Command
Enable IRDP processing on an interface. ip irdp
When you enable IRDP processing, the default parameters will apply. You can optionally change
any of these IRDP parameters. Perform the following tasks in interface configuration mode:
Task Command
Send IRDP advertisements to the all-systems ip irdp multicast
multicast address (224.0.0.1) on a specified
interface.
Set the IRDP period for which advertisements are ip irdp holdtime seconds
valid.
Set the IRDP maximum interval between ip irdp maxadvertinterval seconds
advertisements.
Set the IRDP minimum interval between ip irdp minadvertinterval seconds
advertisements.
Set a router’s IRDP preference level. ip irdp preference number
Specify an IRDP address and preference to ip irdp address address [number]
proxy-advertise.
A router can proxy-advertise other machines that use IRDP; however, this is not recommended
because it is possible to advertise nonexistent machines or machines that are down.

Configure IP Multicast Routing

Traditional IP communication allows a host to send packets to a single host (unicast transmission)
or to all hosts (broadcast transmission). IP multicast provides a third scheme, allowing a host to send
packets to a subset of all hosts (group transmission). These hosts are known as group members.
Packets delivered to group members are identified by a single multicast group address. Multicast
packets are delivered to a group using best-effort reliability just like IP unicast packets.
The multicast environment consists of senders and receivers. Any host, whether it is a member of a
group or not, can send to a group. However, only the members of a group receive the message.
A multicast address is chosen for the receivers in a multicast group. Senders use that address as the
destination address of a datagram to reach all members of the group.
Membership in a multicast group is dynamic; hosts can join and leave at any time. There is no
restriction on the location or number of members in a multicast group. A host can be a member of
more than one multicast group at a time.
How active a multicast group is and what members it has can vary from group to group and from
time to time. A multicast group can be active for a long time, or it may be very short-lived.
Membership in a group can change constantly. A group that has members may have no activity.
Routers executing a multicast routing protocol, such as PIM, maintain forwarding tables to forward
multicast datagrams. Routers use the Internet Group Management Protocol (IGMP) to learn whether
members of a group are present on their directly attached subnets. Hosts join multicast groups by
sending IGMP report messages.
Cisco’s Implementation of IP Multicast Routing

The Cisco IOS software supports three protocols to implement IP multicast routing:
• Internet Group Management Protocol (IGMP). IGMP is used between hosts on a LAN and the
router(s) on that LAN to track which multicast groups the hosts are members of.
• Protocol-Independent Multicast (PIM). PIM is used between routers so they can track which
multicast packets to forward to each other and to their directly connected LANs.
• Distance Vector Multicast Routing Protocol (DVMRP). DVMRP is the protocol used on the
MBONE. Cisco routers support PIM to DVMRP interaction.
Internet Group Management Protocol (IGMP)

IP hosts use IGMP to report their group membership to directly connected multicast routers. IGMP
is an integral part of IP. IGMP is defined in RFC 1112, Host Extensions for IP Multicasting.
IGMP uses group addresses, which are Class D IP addresses. The high-order four bits of a Class D
address are 1110. This means that host group addresses can be in the range 224.0.0.0 to
239.255.255.255. The address 224.0.0.0 is guaranteed not to be assigned to any group. The address
224.0.0.1 is assigned to all systems on a subnet. The address 224.0.0.2 is assigned to all routers on
a subnet.
Protocol-Independent Multicast (PIM) Protocol

The PIM protocol maintains the current IP multicast service mode of receiver-initiated membership.
It is not dependent on a specific unicast routing protocol.
PIM is defined in the following IETF Internet drafts:

• Protocol Independent Multicast (PIM): Motivation and Architecture

• Protocol Independent Multicast (PIM), Dense Mode Protocol Specification
• Protocol Independent Multicast (PIM), Sparse Mode Protocol Specification
• IGMP Router Extensions for Routing to Dense Multicast Groups
• IGMP Router Extensions for Routing to Sparse Multicast Groups
PIM can operate in two modes: dense mode and sparse mode.
In dense mode, a router assumes that all other routers want to forward multicast packets for a group.
If a router receives a multicast packet and has no directly connected members or PIM neighbors
present, a prune message is sent back to the source. Subsequent multicast packets are not flooded to
this router on this pruned branch. PIM builds source-based multicast distribution trees.
In sparse mode, a router assumes that other routers do not want to forward multicast packets for a
group unless there is an explicit request for the traffic. When hosts join a multicast group, the directly
connected routers send PIM Join messages to the rendezvous point (RP). The RP keeps track of
multicast groups. Hosts that send multicast packets are registered with the RP by that host’s first-hop
router. The RP then sends joins toward the source. At this point, packets are forwarded on a shared
distribution tree. If the multicast traffic from a specific source is sufficient, the receiver’s first-hop
router may send joins toward the source to build a source-based distribution tree.
Distance Vector Multicast Routing Protocol (DVMRP)

DVMRP builds a parent-child database using a constained multicast model to build a forwarding tree
rooted at the source of the multicast packets. Multicast packets are initially flooded down this source
tree. If there are redundant paths on the source-tree, packets are not forwarded along those paths.
Forwarding occurs until Prune messages are received on those parent-child links, which further
constrain the broadcast of multicast packets.
DVMRP is implemented in the equipment of many vendors and is based on the public domain
mrouted program. Cisco routers use PIM and know enough about DVMRP to communicate with
DVMRP neighbors.
Cisco routers support dynamic discovery of DVMRP routers and can interoperate with them over
traditional media, such as Ethernet and FDDI, or over DVMRP-specific tunnels.
IP Multicast Routing Configuration Task List

To configure IP multicast routing, perform the required tasks described in the following sections:
• Enable IP Multicast Routing on the Router
• Enable PIM on an Interface
You can also perform the optional tasks described in the following sections:
• Increase Control over RPs
• Configure a Router to Be a Member of a Group
• Modify the IGMP Host-Query Message Interval
• Control Access to IP Multicast Groups
• Modify the PIM Router-Query Message Interval
• Configure the TTL Threshold
• Configure DVMRP Interoperability
• Advertise Network 0.0.0.0 to DVMRP Neighbors

• Configure a DVMRP Tunnel
• Enable DVMRP Unicast Routing
• Limit the Number of DVMRP Routes Advertised
• Change the DVMRP Route Threshold
• Add a Metric Offset to the DVMRP Route
• Reject a DVMRP Non-Pruning Neighbor
• Configure an IP Multicast Static Route
• Disable Fast Switching of IP Multicast
• Control the Transmission Rate to a Multicast Group
• Enable PIM Nonbroadcast, Multiaccess (NBMA) Mode
• Enable SD Listener Support
See the section “IP Multicast Routing Configuration Examples” at the end of this chapter.
Enable IP Multicast Routing on the Router

Enabling IP multicast routing on the router allows the router to forward multicast packets. To enable
IP multicast routing on the router, perform the following task in global configuration mode:
Task Command
Enable IP multicast routing on the router. ip multicast-routing
Enable PIM on an Interface

Enabling PIM on an interface also enables IGMP operation on that interface. An interface can be
configured to be in dense mode or sparse mode. The mode describes how the router populates its
multicast routing table and how the router forwards multicast packets it receives from its directly
connected LANs.
In populating the multicast routing table, dense-mode interfaces are always added to the table.
Sparse-mode interfaces are added to the table only when periodic join messages are received from
downstream routers or there is a directly connected member on the interface. When forwarding from
a LAN, sparse-mode operation occurs if there is an RP known for the group. If so, the packets are
encapsulated and sent toward the RP. When no RP is known, the packet is flooded in a dense-mode
fashion. If the multicast traffic from a specific source is sufficient, the receiver’s first-hop router may
send joins toward the source to build a source-based distribution tree.
There is no default mode setting. By default, multicast routing is disabled on an interface.
To configure PIM on an interface to be in dense mode, perform the following task in interface
configuration mode:
Task Command
Enable dense-mode PIM on the interface. ip pim dense-mode
For an example of how to configure a PIM interface in dense mode, see the section “Configure a
Router to Operate in Dense Mode Example” later in this chapter.

To configure PIM on an interface to be in sparse mode, perform the following task in interface
configuration mode:
Task Command
Enable sparse-mode PIM on the interface. ip pim sparse-mode
For an example of how to configure a PIM interface in sparse mode, see the section “Configure a
Router to Operate in Sparse Mode Example” later in this chapter.
If you configure the router to operate in sparse mode, you must also choose one or more routers to
be RPs. You do not have to configure the routers to be RPs; they learn this themselves. RPs are used
by senders to a multicast group to announce their existence and by receivers of multicast packets to
learn about new senders. A router can be configured so that packets for a single multicast group can
use one or more RPs.
You must configure the IP address of RPs in leaf routers only. Leaf routers are those routers that are
directly connected either to a multicast group member or to a sender of multicast messages.
The RP address is used by first-hop routers to send PIM register messages on behalf of a host sending
a packet to the group. The RP address is also used by last-hop routers to send PIM join/prune
messages to the RP to inform it about group membership. The RP does not need to know it is an RP.
You need to configure the RP address only on first-hop and last-hop routers (leaf routers).
A PIM router can be an RP for more than one group. A group can have more than one RP. The
conditions specified by the access-list determine for which groups the router is an RP.
To configure the address of the RP, perform the following task in global configuration mode:
Task Command
Configure the address of a PIM rendezvous ip pim rp-address ip-address [access-list-number]
point (RP).
Increase Control over RPs

You can take a defensive measure to prevent a misconfigured leaf router from interrupting PIM
service to the rest of a network. To do so, configure the local router to accept Join messages only if
they contain the RP address specified, when the group is in the group range specified by the access
list. To configure this feature, perform the following task in global configuration mode:
Task Command
Control which RPs the local router will accept Join ip pim accept-rp {address | auto-rp}
messages to. [access-list-number]
Configure a Router to Be a Member of a Group

Cisco routers can be configured to be members of a multicast group. This is useful for determining
multicast reachability in a network. If a router is configured to be a group member and supports the
protocol that is being transmitted to the group, it can respond. An example is ping. A router will
respond to ICMP echo request packets addressed to a group for which it is a member. Another
example is the multicast traceroute tools provided in the Cisco IOS software.

To have a router join a multicast group and turn on IGMP on the router, perform the following task
in interface configuration mode:
Task Command
Join a multicast group. ip igmp join-group group-address
Modify the IGMP Host-Query Message Interval

Multicast routers send IGMP host-query messages to discover which multicast groups are present
on attached networks. These messages are sent to the all-systems group address of 224.0.0.1 with a
TTL of 1.
Multicast routers send host-query messages periodically to refresh their knowledge of memberships
present on their networks. If, after some number of queries, the router discovers that no local hosts
are members of a multicast group, the router stops forwarding onto the local network multicast
packets from remote origins for that group and sends a prune message upstream toward the source.
Multicast routers elect a PIM designated router for the LAN (subnet). This is the router with the
highest IP address. The designated router is responsible for sending IGMP host-query messages to
all hosts on the LAN. In sparse mode, the designated router also sends PIM register and PIM join
messages towards the RP router.
By default, the designated router sends IGMP host-query messages once a minute in order to keep
the IGMP overhead on hosts and networks very low. To modify this interval, perform the following
task in interface configuration mode:
Task Command
Configure the frequency at which the designated ip igmp query-interval seconds
router sends IGMP host-query messages.
Control Access to IP Multicast Groups

Multicast routers send IGMP host-query messages to determine which multicast groups have
members of the router’s attached local networks. The routers then forward to these group members
all packets addressed to the multicast group. You can place a filter on each interface that restricts the
multicast groups that hosts on the subnet serviced by the interface can join.
To filter multicast groups allowed on an interface, perform the following task in interface
configuration mode:
Task Command
Control the multicast groups that hosts on the ip igmp access-group access-list-number
subnet serviced by an interface can join.
Modify the PIM Router-Query Message Interval

Route-query messages are used to elect a PIM designated router. The designated router is
responsible for sending IGMP host-query messages. By default, multicast routers send PIM
router-query messages every 30 seconds. To modify this interval, perform the following task in
interface configuration mode:
Task Command
Configure the frequency at which multicast ip pim query-interval seconds
routers send PIM router-query messages.

Configure the TTL Threshold

The time-to-live (TTL) value controls whether packets are forwarded out of an interface. You specify
the TTL value in hops. Only multicast packets with a TTL greater than the interface TTL threshold
are forwarded on the interface. The default value is 0, which means that all multicast packets are
forwarded on the interface. To change the default TTL threshold value, perform the following task
in interface configuration mode:
Task Command
Configure the TTL threshold of packets being ip multicast ttl-threshold ttl
forwarded out an interface.
Configure DVMRP Interoperability

Cisco multicast routers using PIM can interoperate with non-Cisco multicast routers that use the
Distance Vector Multicast Routing Protocol (DVMRP).
PIM routers dynamically discover DVMRP multicast routers on attached networks. Once a DVMRP
neighbor has been discovered, the router periodically transmits DVMRP report messages advertising
the unicast sources reachable in the PIM domain. By default, directly connected subnets and
networks are advertised. The router forwards multicast packets that have been forwarded by
DVMRP routers and in turn forwards multicast packets to DVMRP routers.
You can configure what sources are advertised and what metrics are used by using the ip dvmrp
metric command. You can also direct all sources learned via a particular unicast routing process to
be advertised into DVMRP.
The mrouted protocol is a public domain implementation of DVMRP. It is necessary to use mrouted
version 2.2 (which implements a nonpruning version of DVMRP) or version 3.2 (which implements
a pruning version of DVMRP) when Cisco routers are directly connected to DVMRP routers or
interoperate with DVMRP routers over an MBONE tunnel. DVMRP advertisements produced by
Cisco routers can cause older versions of mrouted to corrupt their routing tables and those of their
neighbors.
To configure the sources that are advertised and the metrics that are used when transmitting DVMRP
report messages, perform the following task in interface configuration mode:
Task Command
Configure the metric associated with a set of ip dvmrp metric metric [list access-list-number]
destinations for DVMRP reports. [protocol process-id] | [dvmrp]
Responding to MRINFO Requests

Our routers answer mrinfo requests sent by mrouted systems. The router returns information about
neighbors on DVMRP tunnels. This information includes the metric, which is always set to 1, the
configured TTL threshold, and the status of the tunnel.
For an example of how to configure a PIM router to interoperate with a DVMRP router, see the
section “Configure DVMRP Interoperability Examples” later in this chapter.
Advertise Network 0.0.0.0 to DVMRP Neighbors

The mrouted protocol is a public domain implementation of DVMRP. If your router is a neighbor to
an mrouted version 3.6 machine, you can configure the router to advertise network 0.0.0.0 to the
DVMRP neighbor. You must specify whether only route 0.0.0.0 is advertised or other routes can also
be specified.
To advertise network 0.0.0.0 to DVMRP neighbors on an interface, perform the following task in
Task Command
Advertise network 0.0.0.0 to DVMRP neighbors. ip dvmrp default-information {originate | only}
Configure a DVMRP Tunnel

Cisco routers can support DVMRP tunnels to the MBONE. (The MBONE is the multicast backbone
of the Internet.) You can configure a DVMRP tunnel on a router if the other end is running DVMRP.
The router then sends and receives multicast packets over the tunnel. This allows a PIM domain to
connect to the DVMRP router in the case where all routers on the path do not support multicast
routing.
When a Cisco router runs DVMRP over a tunnel, it advertises sources in DVMRP report messages
much as it does on real networks. In addition, DVMRP report messages received are cached on the
router and are used as part of its Reverse Path Forwarding (RPF) calculation. This allows multicast
packets received over the tunnel to be forwarded by the router.
When you configure a DVMRP tunnel, you should assign a tunnel an address for two reasons:
• To enable the sending of IP packets over the tunnel
• To indicate whether the Cisco IOS software should perform DVMRP summarization
You can assign an IP address either by using the ip address interface configuration command or by
using the ip unnumbered interface configuration command to configure the tunnel to be
unnumbered. Either of these two methods allows IP multicast packets to flow over the tunnel. The
Cisco IOS software will not advertise subnets over the tunnel if the tunnel has a different network
number from the subnet. In this case, the Cisco IOS software advertises only the network number
over the tunnel.
To configure a DVMRP tunnel, perform the following tasks:
Task Command
Step 1 Specify a tunnel interface in global interface tunnel number1
configuration mode. This puts the router
into interface configuration mode.
Step 2 Set the tunnel interface’s source address. tunnel source ip-address1
This is the IP address of the interface on
the router.
Step 3 Set the tunnel interface’s destination tunnel destination ip-address1
address. This is the IP address of the
mrouted multitask router.
Step 4 Configure a DVMRP tunnel. tunnel mode dvmrp1
Step 5 Assign an IP address to the interface. ip address address mask2
or
Configure the interface as unnumbered. ip unnumbered type number2
Step 6 Configure PIM on the interface. ip pim [dense-mode | sparse-mode]
Step 7 Configure an acceptance filter for ip dvmrp accept-filter access-list-number [distance]
incoming DVMRP reports.
1. This command is documented in the “Interface Commands” chapter of the Router Products Command Reference
publication.
2. This command is documented in the “IP Commands” chapter of the Router Products Command Reference publication.

For an example of how to configure a DVMRP interoperability over a tunnel interface, see the
section “Configure DVMRP Interoperability Examples” later in this chapter.
Enable DVMRP Unicast Routing

Since policy for multicast routing and unicast routing require separate topologies, PIM must follow
the multicast topology to build loopless distribution trees. Using DVMRP unicast routing, Cisco
routers and mrouted-based machines exchange DVMRP unicast routes, which PIM can then RPF to.
Cisco routers do not perform DVMRP multicast routing among each other, but they can exchange
DVMRP routes. The DVMRP routes provide a multicast topology that may differ from the unicast
topology. This allows PIM to run over the multicast topology, thereby allowing sparse-mode PIM
over the MBONE topology.
When DVMRP unicast routing is enabled, the router caches routes learned in DVMRP Report
messages in a DVMRP routing table. PIM prefers DVMRP routes to unicast routes by default, but
that preference can be configured.
DVMRP unicast routing can run on all interfaces, including GRE tunnels. On DVMRP tunnels, it
runs by virtue of DVMRP multicast routing. This feature does not enable DVMRP multicast routing
among Cisco routers. However, if there is a DVMRP-capable multicast router, the Cisco router will
do PIM/DVMRP multicast routing interaction.
To enable DVMRP unicast routing, perform the following task in interface configuration mode:
Task Command
Enable DVMRP unicast routing. ip dvmrp unicast-routing
Limit the Number of DVMRP Routes Advertised

By default, only 7000 DVMRP routes will be advertised over an interface enabled to run DVMRP
(that is, a DVMRP tunnel, an interface where a DVMRP neighbor has been discovered, or an
interface configured to run ip dvmrp unicast-routing).
To change this limit, perform the following task in global configuration mode:
Task Command
Change the number of DVMRP routes ip dvmrp route-limit count
advertised over an interface enabled to run
DVMRP.
Change the DVMRP Route Threshold

By default, 10,000 DVMRP routes may be received per interface within a 1-minute interval. When
that rate is exceeded, a syslog message is issued, warning that there might be a route surge occurring.
The warning is typically used to detect quickly when people have misconfigured their routers to
inject a large number of routes into the MBONE.
To change the threshold number of routes that trigger the warning, perform the following task in
global configuration mode:
Task Command
Configure the number of routes that trigger a ip dvmrp routehog-notification route-count
syslog message.

Use the show ip igmp interface command to display a running count of routes. When the count is
exceeded, “*** ALERT ***” is appended to the line.
Add a Metric Offset to the DVMRP Route

By default, the router adds 1 to the metric of a DVMRP route advertised in incoming DVMRP
reports. You can change the metric if you want to favor or not favor a certain route. The DVMRP
metric is a hop-count. Therefore, a very slow serial line of one hop is preferred over a route that is
two hops over FDDI or another fast medium.
For example, perhaps a route is learned by Router A and the the same route is learned by Router B
with a higher metric. If you want to use the path through Router B because it is a faster path, you can
apply a metric offset to the route learned by Router A to make it larger than the metric learned by
Router B, allowing you to choose the path through Router B.
To change the default metric, perform the following task in interface configuration mode:
Task Command
Change the metric added to DVMRP routes ip dvmrp metric-offset [in | out] increment
advertised in incoming reports.
• When you specify in or no keyword, the increment is added to incoming DVMRP reports and is
reported in mrinfo replies. The default value for in is 1.
• When you specify out, the increment is added to outgoing DVMRP reports for routes from the
DVMRP routing table. The default value for out is 0.
This is similar to the metric keyword in mrouted configuration files.
Reject a DVMRP Non-Pruning Neighbor

By default, Cisco routers accept all DVMRP neighbors as peers, regardless of their DVMRP
capability or lack thereof. However, some non-Cisco machines run old versions of DVMRP that
cannot prune, so they will continuously receive forwarded packets unnecessarily, wasting
bandwidth. Figure 19-3 shows this scenario.

Figure 19-3 Leaf Non-Pruning DVMRP Neighbor
Source or RP
RP PIM dense mode
Router A
Valid
multicast
traffic Receiver
Router B
Router C
Wasted
multicast
traffic
Leaf non-pruning
DVMRP machine
S6235
Stub LAN with no members
You can prevent a router from peering (communicating) with a DVMRP neighbor if that neighbor
does not support DVMRP pruning or grafting. To do so, configure Router C, which is a neighbor to
the leaf, non-pruning DVMRP machine, with the ip dvmrp reject-non-pruners command on the
interface to the non-pruning machine. Figure 19-4 illustrates this scenario. In this case, when the
router receives a DVMRP Probe or Report message without the Prune-Capable flag set, the router
logs a syslog message and discards the message.

Figure 19-4 Router Rejects Non-Pruning DVMRP Neighbor
Source or RP
RP
Router A
Multicast
traffic gets
to receiver, Receiver
not to leaf Router B
DVMRP
machine
Router C ip dvmrp reject-non-pruners
S6236
Leaf non-pruning DVMRP machine
Note that the ip dvmrp reject-non-pruners command prevents peering with neighbors only. If there
are any non-pruning routers multiple hops away (downstream toward potential receivers) that are not
rejected, then a non-pruning DVMRP network might still exist.
To prevent peering with non-pruning DVMRP neighbors, perform the following task in interface
configuration mode:
Task Command
Prevent peering with non-pruning DVMRP ip dvmrp reject-non-pruners
neighbors.
Configure an IP Multicast Static Route

IP multicast static routes (mroutes) allow you to have multicast paths diverge from the unicast paths.
When using PIM, the router expects to receive packets on the same interface where it sends unicast
packets back to the source. This is beneficial if your multicast and unicast topologies are congruent.
However, you might want unicast packets to take one path and multicast packets to take another.
The most common reason for using separate unicast and multicast paths is tunneling. When a path
between a source and a destination does not support multicast routing, a solution is to configure two
routers with a GRE tunnel between them. In Figure 19-5, the UR routers support unicast packets
only; the MR routers support multicast packets.

Figure 19-5 A Tunnel for Multicast Packets
MR 1 UR 1 UR 2 MR 2
S3740
Source Destination
link
tunnel
In Figure 19-5, Source delivers multicast packets to Destination by using MR1 and MR2. MR2
accepts the multicast packet only if it thinks it can reach Source over the tunnel. If this is true, when
Destination sends unicast packets to Source, MR2 sends them over the tunnel. This could be slower
than natively sending the unicast packet through UR2, UR1, and MR1.
Prior to multicast static routes, the configuration in Figure 19-6 was used to overcome the problem
of both unicasts and multicasts using the tunnel. In this figure, MR1 and MR2 are used as multicast
routers only. When Destination sends unicast packets to Source, it uses the (UR3,UR2,UR1) path.
When Destination sends multicast packets, the UR routers do not understand or forward them. But
the MR routers forward the packets.
Figure 19-6 Separate Paths for Unicast and Multicast Packets
UR 1 UR 2 UR 3
Source Destination
S3741
MR 1 MR 2
link
tunnel
To make the configuration in Figure 19-6 work, MR1 and MR2 must run another routing protocol
(typically a different instantiation of the same protocol running in the UR routers), so that paths from
sources are learned dynamically.
A multicast static route allows you to use the configuration in Figure 19-5 by configuring a static
multicast source. The router uses the configuration information instead of the unicast routing table.
This allows multicast packets to use the tunnel without having unicast packets use the tunnel.
To configure a multicast static route, perform the following task in global configuration mode:
Task Command
Configure an IP multicast static route. ip mroute source mask [protocol as-number]
{rpf-address | type number} [distance]
Disable Fast Switching of IP Multicast

Fast switching of IP multicast packets is enabled by default on all interfaces, with one exception. It
is disabled and not supported over X.25 encapsulated interfaces.

• If fast switching is disabled on an incoming interface for a multicast routing table entry, the
packet is sent at process level for all interfaces in the outgoing interface list.
• If fast switching is disabled on an outgoing interface for a multicast routing table entry, the packet
is process-level switched for that interface, but might be fast switched for other interfaces in the
outgoing interface list.
You might want to disable fast switching if you want to log debug messages, because when fast
switching is enabled, debug messages are not logged.
To disable fast switching of IP multicast, perform the following task in interface configuration mode:
Task Command
Disable fast switching of IP multicast. no ip mroute-cache
Control the Transmission Rate to a Multicast Group

By default, there is no limit to how fast a sender can transmit packets to a multicast group. You can
control the rate that the sender from the source list can send to a multicast group in the group list by
performing the following task in interface configuration mode:
Task Command
Control transmission rate to a multicast group. ip multicast rate-limit {in | out} [group-list
access-list] [source-list access-list] kbps
Enable PIM Nonbroadcast, Multiaccess (NBMA) Mode

PIM nonbroadcast, multiaccess mode allows the router to replicate packets for each neighbor on the
NBMA network. Traditionally, Cisco routers replicate multicast and broadcast packets to all
"broadcast" configured neighbors. This might be inefficient when not all neighbors want packets for
certain multicast groups. NBMA mode allows you to reduce bandwidth on links leading into the
NBMA network, as well as CPU cycles in switches and attached neighbors.
Configure this feature on ATM, Frame Relay, SMDS, or X.25 networks only, especially when these
media do not have native multicast available. Do not use this feature on multicast-capable LANs
such as Ethernet or FDDI.
We encourage you to use sparse-mode PIM with this feature. Therefore, when each Join is received
from NBMA neighbors, PIM stores each neighbor IP address/interface in the outgoing interface list
for the group. When a packet is destined for the group, the router replicates the packet and unicasts
(data-link unicasts) it to each neighbor that has joined the group.
To enable PIM nonbroadcast, multicaccess mode on your serial link, perform the following task in
Task Command
Enable PIM nonbroadcast, multiaccess mode. ip pim nbma-mode
Consider the following two factors before enabling PIM NBMA mode:
• If the number of neighbors grows, the outgoing interface list will get large. This will cost memory
and replication time.
• If the network (Frame Relay, SMDS, or ATM) supports multicast natively, we encourage you to
use it so that replication is performed at optimal points in the network.

Configure Routing Protocol-Independent Features
Enable SD Listener Support

The Multicast Backbone (Mbone) allows efficient, many-to-many communication and is widely
used for multimedia conferencing. To help announce multimedia conference sessions and provide
the necessary conference setup information to potential participants, the session directory (sd) tool
was written. A session directory client announcing a conference session periodically multicasts an
announcement packet on a well-known multicast address and port.
To enable session directory listener support, perform the following task in interface configuration
mode:
Task Command
Enable sd listener support. ip sd listen

Previous sections addressed configurations of specific routing protocols. Complete the
protocol-independent tasks described in the following sections as needed:
• Use Variable-Length Subnet Masks
• Configure Static Routes
• Specify Default Routes
• Change the Maximum Number of Paths
• Redistribute Routing Information
• Filter Routing Information
• Enable Policy Routing
• Adjust Timers
• Enable or Disable Split Horizon
Use Variable-Length Subnet Masks

OSPF, static routes, and IS-IS support variable-length subnet masks (VLSMs). With VLSMs, you
can use different masks for the same network number on different interfaces, which allows you to
conserve IP addresses and more efficiently use available address space. However, using VLSMs also
presents address assignment challenges for the network administrator and ongoing administrative
challenges.
Refer to RFC 1219 for detailed information about VLSMs and how to correctly assign addresses.
Note Consider your decision to use VLSMs carefully. It is easy to make mistakes in address
assignments and it is generally more difficult to monitor your network using VLSMs.
The best way to implement VLSMs is to keep your existing numbering plan in place and gradually
migrate some networks to VLSMs to recover address space. See the “Variable-Length Subnet Masks
Example” section at the end of this chapter for an example of using VLSMs.

Configure Static Routes

Static 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. They are also useful for specifying a gateway of last resort to which all unroutable
packets will be sent.
To configure static routes, perform the following task in global configuration mode:
Task Command
Establish a static route. ip route network [mask] {address | interface} [distance]
See the “Overriding Static Routes with Dynamic Protocols Example” section at the end of this
chapter for an example of configuring static routes.
The router remembers static routes until you remove them (using the no form of the ip route global
configuration command). However, you can override static routes with dynamic routing information
through prudent assignment of administrative distance values. Each dynamic routing protocol has a
default administrative distance, as listed in Table 19-2. If you would like a static route to be
overridden by information from a dynamic routing protocol, simply ensure that the administrative
distance of the static route is higher than that of the dynamic protocol.
Static routes that point to an interface will be advertised via RIP, IGRP, and other dynamic routing
protocols, regardless of whether redistribute static commands were specified for those routing
protocols. This is 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 will
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. Also, when the router 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 removed from the IP routing table.

Static route 1
External BGP 20
IGRP 100
OSPF 110
IS-IS 115
RIP 120
EGP 140
Internal BGP 200
Unknown 255

Specify Default Routes

A router might not be able to determine the routes to all other networks. To provide complete routing
capability, the common practice is to 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 passed along dynamically or can be configured into the
individual routers.
Most dynamic interior routing protocols include a mechanism for causing a smart router to generate
dynamic default information that is then passed along to other routers.
Specify a Default Network

If a router has a directly connected interface onto the specified default network, the dynamic routing
protocols running on that router will generate or source a default route. In the case of RIP, it will
advertise the pseudonetwork 0.0.0.0. In the case of IGRP, the network itself is advertised and flagged
as an exterior route.
A router that is generating the default for a network also may need a default of its own. One way of
doing this is to specify a static route to the network 0.0.0.0 through the appropriate router.
To define a static route to a network as the static default route, perform the following task in global
configuration mode:
Task Command
Specify a default network. ip default-network network-number
Gateway of Last Resort

When default information is being passed along through a dynamic routing protocol, no further
configuration is required. The system will periodically scan its routing table to choose the optimal
default network as its default route. In the case of RIP, it will be only one choice, network 0.0.0.0.
In the case of IGRP, there might be several networks that can be candidates for the system default.
The router uses both administrative distance and metric information to determine the default route
(gateway of last resort). The selected default route appears in the gateway of last resort display of
the show ip route EXEC command.
If dynamic default information is not being passed to the router, candidates for the default route can
be specified with the ip default-network command. In this usage, ip default-network takes an
unconnected network as an argument. If this network appears in the routing table from any source
(dynamic or static), it is flagged as a candidate default route and is a possible choice as the default
route for the router.
If the router has no interface on the default network but does have a route to it, it will consider this
network as a candidate default path. The route candidates will be examined and the best one will be
chosen based on administrative distance and metric. The gateway to the best default path will
become the gateway of last resort for the router.
Change the Maximum Number of Paths

By default, most IP routing protocols install a maximum of four parallel routes in a routing table.
The exception is BGP, which allows only one path to a destination.

The range of maximum paths for protocols other than BGP is 1 to 6 paths. To change the maximum
number of parallel paths allowed (for a protocol other than BGP), perform the following task in
Task Command
Configure the maximum number of parallel paths maximum-paths maximum
allowed in a routing table.
Redistribute Routing Information

In addition to running multiple routing protocols simultaneously, the router can redistribute
information from one routing protocol to another. For example, you can instruct the router to
readvertise IGRP-derived routes using the RIP protocol, or to readvertise static routes using the
IGRP protocol. This applies to all of the IP-based routing protocols.
You also can conditionally control the redistribution of routes between routing domains by defining
a method known as route maps between the two domains.
The following four tables list tasks associated with route redistribution. Although redistribution is a
protocol-independent feature, some of the match and set commands are specific to a particular
protocol.
To define a route map for redistribution, perform the following task in global configuration mode:
Task Command
Define any route maps needed to control route-map map-tag [permit | deny] [sequence-number]
redistribution.
One or more match commands and one or more set commands must follow a route-map command.
To define conditions for redistributing routes from one routing protocol into another, perform at least
one of the following tasks in route-map configuration mode:
Task Command
Match a BGP autonomous system path access match as-path path-list-number
list.
Match a BGP community list. match community-list community-list-number [exact]
Match a standard access list. match ip address
access-list-number...access-list-number
Match the specified metric. match metric metric-value
Match a next-hop router address passed by one match ip next-hop
of the access lists specified. access-list-number...access-list-number
Match the specified tag value. match tag tag-value...tag-value
Match the specified next hop route out one of match interface type number...type number
the interfaces specified.
Match the address specified by the specified match ip route-source
advertised access lists. access-list-number...access-list-number
Match the specified route type. match route-type {local | internal | external [type-1 |
type-2] | level-1 | level-2}

One or more match commands and one or more set commands must follow a route-map command.
To define conditions for redistributing routes from one routing protocol into another, perform at least
one of the following tasks in route-map configuration mode:
Task Command
Set the COMMUNITIES attribute. set community {community-number [additive]} | none
Assign a value to a local BGP path. set local-preference value
Specify the BGP weight for the routing table. set weight weight
Set the BGP origin code. set origin {igp | egp as | incomplete}
Modify the BGP autonomous system path. set as-path {tag | prepend as-path-string}
Specify the address of the next hop. set next-hop next-hop
Enable automatic computing of tag table. set automatic-tag
For routes that are advertised into the specified set level {level-1 | level-2 | level-1-2 | stub-area |
area of the routing domain. backbone}
Set the metric value to give the redistributed set metric metric-value
routes (for any protocol except IGRP or IP
Enhanced IGRP).
Set the metric value to give the redistributed set metric bandwidth delay reliability loading mtu
routes (for IGRP or IP Enhanced IGRP only).
Set the MED value on prefixes advertised to set metric-type internal
EBGP neighbor to match the IGP metric of the
next hop.
Set the metric type to give redistributed routes. set metric-type {internal | external | type-1 | type-2}
Set the tag value to associate with the set tag tag-value
For examples of BGP route maps, see the section “BGP Route Map Examples” at the end of this
chapter. For examples of BGP communities and route maps, see the section “BGP Community
Examples with Route Maps.”
To distribute routes from one routing domain into another and to control route redistribution,
perform the following tasks in router configuration mode:
Task Command
Redistribute routes from one routing protocol redistribute protocol [process-id] {level-1 | level-1-2 |
to another routing protocol. level-2} [metric metric-value] [metric-type type-value]
[match internal | external type-value] [tag tag-value]
[route-map map-tag] [weight weight] [subnets]
Cause the current routing protocol to use the default-metric number
same metric value for all redistributed routes
(BGP, EGP, OSPF, RIP).
Cause the IGRP or Enhanced IGRP routing default-metric bandwidth delay reliability loading mtu
protocol to use the same metric value for all
Disable the redistribution of default no default-information allowed {in | out}
information between IGRP processes. This is
enabled by default.

The metrics of one routing protocol do not necessarily translate into the metrics of another. For
example, the RIP metric is a hop count and the IGRP metric is a combination of five quantities. In
such situations, an artificial metric is assigned to the redistributed route. Because of this unavoidable
tampering with dynamic information, carelessly exchanging routing information between different
routing protocols can create routing loops, which can seriously degrade network operation.
See the “IP Routing Protocol Configuration Examples” section at the end of this chapter for
examples of configuring redistribution and route maps.
Supported Metric Translations

This section describes supported automatic metric translations between the routing protocols. The
following descriptions assume that you have not defined a default redistribution metric that replaces
metric conversions.
• RIP can automatically redistribute static routes. It assigns static routes a metric of 1 (directly
connected).
• EGP can automatically redistribute static routes and all dynamically derived routes. EGP assigns
the metric 3 to all static and derived routes.
• BGP does not normally send metrics in its routing updates.
• IGRP can automatically redistribute static routes and information from other IGRP-routed
autonomous systems. IGRP assigns static routes a metric that identifies them as directly
connected. IGRP does not change the metrics of routes derived from IGRP updates from other
autonomous systems.
• Note that any protocol can redistribute other routing protocols if a default metric is in effect.
Filter Routing Information

You can filter routing protocol information by performing the following tasks:
• Suppress the sending of routing updates on a particular router interface. This is done to prevent
other systems on an interface from learning about routes dynamically.
• Suppress networks from being advertised in routing updates. This is done to prevent other routers
from learning a particular router’s interpretation of one or more routes.
• Suppress networks listed in updates from being accepted and acted upon by a routing process.
This is done to keep a router from using certain routes.
• Filter on the source of routing information. This is done to prioritize routing information from
different sources, because some pieces of routing information may be more accurate than others.
• Apply an offset to routing metrics. This is done to provide a local mechanism for increasing the
value of routing metrics.
Note When routes are redistributed between OSPF processes, no OSPF metrics are preserved.
The following sections describe these tasks.

Suppress Routing Updates through an Interface

To prevent other routers on a local network from learning about routes dynamically, you can keep
routing update messages from being sent through a router interface. This feature applies to all
IP-based routing protocols except BGP and EGP.
OSPF and IS-IS behaviors are somewhat different. In OSPF, 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 IS-IS, the specified IP addresses are advertised
without actually running IS-IS on those interfaces.
To prevent routing updates through a specified interface, perform the following task in router
configuration mode:
Task Command
Suppress the sending of routing updates passive-interface type number
through the specified router interface.
See the “Passive Interface Examples” section at the end of this chapter for examples of configuring
passive interfaces.
Suppress Routes from Being Advertised in Routing Updates

To prevent other routers from learning one or more routes, you can suppress routes from being
advertised in routing updates. You cannot specify an interface name in OSPF. When used for OSPF,
this feature applies only to external routes.
To suppress routes from being advertised in routing updates, perform the following task in router
configuration mode:
Task Command
Permit or deny routes from being advertised in distribute-list access-list-number out [interface-name |
routing updates depending upon the action routing-process]
listed in the access list.
Suppress Routes Listed in Updates from Being Processed

You might want to avoid processing certain routes listed in incoming updates. This feature does not
apply to OSPF or IS-IS. Perform the following task in router configuration mode:
Task Command
Suppress routes listed in updates from being distribute-list access-list-number in [interface-name]
processed.
Apply Offsets to Routing Metrics

An offset list is the mechanism for increasing incoming and outgoing metrics to routes learned via
RIP and IGRP. Optionally, you can limit the offset list with either an access list or an interface. To
increase the value of routing metrics, perform the following task in router configuration mode:
Task Command
Apply an offset to routing metrics. offset-list [access-list-number] {in | out} offset [type
number]

Filter Sources of Routing Information

An administrative distance is a rating of the trustworthiness of a routing information source, such as
an individual router or a group of routers. In a large network, some routing protocols and some
routers can be more reliable than others as sources of routing information. Also, when multiple
routing processes are running in the same router for IP, it is possible for the same route to be
advertised by more than one routing process. By specifying administrative distance values, you
enable the router to intelligently discriminate between sources of routing information. The router
will always pick the route whose routing protocol has the lowest administrative distance.
To filter sources of routing information, perform the following task in router configuration mode:
Task Command
Filter on routing information sources. distance weight [address-mask [access-list-number]] [ip]
For example, consider a router using IGRP and RIP. Suppose you trust the IGRP-derived routing
information more than the RIP-derived routing information. In this example, because the default
IGRP administrative distance is lower than the default RIP administrative distance, the router uses
the IGRP-derived information and ignores the RIP-derived information. However, if you lose the
source of the IGRP-derived information (to a power shutdown in another building, for example), the
router uses the RIP-derived information until the IGRP-derived information reappears.
Note You also can use administrative distance to rate the routing information from routers running
the same routing protocol. This application is generally discouraged if you are unfamiliar with this
particular use of administrative distance, because it can result in inconsistent routing information,
including forwarding loops.
Assigning administrative distances is a problem unique to each network and is done in response to
the greatest perceived threats to the network. Even when general guidelines exist, the network
manager must ultimately determine a reasonable matrix of administrative distances for the network
as a whole. Table 19-3 shows the default administrative distance for various sources of routing
information.

Static route 1
Enhanced IGRP summary route 5
External BGP 20
Internal Enhanced IGRP 90
IGRP 100
OSPF 110
IS-IS 115
RIP 120
EGP 140
External Enhanced IGRP 170


Internal BGP 200
Unknown 255
See the “Administrative Distance Examples” section at the end of this chapter for examples of
setting administrative distances.
Enable Policy Routing

Policy routing is a more flexible mechanism for routing packets than destination routing. It is a
process whereby the router puts packets through a route map before routing them. The route map
determines which packets are routed to which router next. You might enable policy routing if you
want certain packets to be routed some way other than the obvious shortest path. Some possible
applications for policy routing are to provide equal access, protocol-sensitive routing,
source-sensitive routing, routing based on interactive versus batch traffic, or routing based on
dedicated links.
To enable policy routing, you must identify which route map to use for policy routing and create the
route map. The route map itself specifies the match criteria and the resulting action if all of the match
clauses are met. These steps are described in the next three task tables.
To enable policy routing on an interface, indicate which route map the router should use by
performing the following task in interface configuration mode. All packets arriving on the specified
interface will subject to policy routing. This command disables fast switching of all packets arriving
on this interface.
Task Command
Identify the route map to use for policy routing. ip policy route-map map-tag
You must also define the route map to be used for policy routing. Perform the following task in
global configuration mode:
Task Command
Define a route map to control where packets are route-map map-tag [permit | deny]
output. [sequence-number]
The next step is to define the criteria by which packets are examined to see if they will be policy
routed. No match clause in the route map indicates all packets. Perform one or more of the following
tasks in route-map configuration mode:
Task Command
Match the Level 3 length of the packet. match length min max
Match the destination IP address that is permitted match ip address
by one or more standard or extended access lists. access-list-number...access-list-number
The last step is to specify where the packets that pass the match criteria are output. To do so, perform
one or more of the following tasks in route-map configuration mode:
Task Command
Specify the next hop to route the packet to (it need set ip next-hop ip-address [... ip-address]
not be adjacent).

Task Command
Specify the output interface for the packet. set interface type number [... type number]
Specify the next hop to route the packet to, if there set ip default next-hop ip-address [... ip-address]
is no explicit route for this destination.
Specify the output interface for the packet, if there set default interface type number [... type number]
is no explicit route for this destination.
The set commands can be used in conjunction with each other. They are evaluated in the order shown
in the task table above. A usable next hop implies an interface. Once the local router finds a next hop
and a usable interface, it routes the packet.
For an example, see the section “Policy Routing Example” at the end of this chapter.
Enable Local Policy Routing

Packets that are generated by the router are not normally policy-routed. To enable local policy
routing for such packets, indicate which route map the router should use by performing the following
task in global configuration mode. All packets originating on the router will then be subject to local
policy routing.
Task Command
Identify the route map to use for local policy ip local policy route-map map-tag
routing.
Use the show ip local policy command to display the route map used for local policy routing, if one
exists.
Adjust Timers
Routing protocols use a variety of timers that determine such variables as the frequency of routing
updates, the length of time before a route becomes invalid, and other parameters. You can adjust
these timers to tune routing protocol performance to better suit your internetwork needs.
For IGRP and RIP, you can make the following timer adjustments:
• The rate (time in seconds between updates) at which routing updates are sent
• The interval of time (in seconds) after which a route is declared invalid
• The interval (in seconds) during which routing information regarding better paths is suppressed
• The amount of time (in seconds) that must pass before a route is removed from the routing table
• The amount of time for which routing updates will be postponed
EGP and BGP have their own timers commands, although some EGP timers might be set with the
timers basic command. See the EGP and BGP sections, respectively.
It also is possible to tune the IP routing support in the software to enable faster convergence of the
various IP routing algorithms and hence, quicker fallback to redundant routers. The total effect is to
minimize disruptions to end users of the network in situations where quick recovery is essential.
To adjust RIP or IGRP timers, perform the following task in router configuration mode:
Task Command
Adjust RIP or IGRP timers. timers basic update invalid holddown flush [sleeptime]

Monitor and Maintain the IP Network
Enable or Disable Split Horizon

Normally, routers that are connected to broadcast-type IP networks and that use distance-vector
routing protocols employ the split horizon mechanism to reduce the possibility of routing loops.
Split horizon blocks information about routes from being advertised by a router out any interface
from which that information originated. This behavior usually optimizes communications among
multiple routers, particularly when links are broken. However, with nonbroadcast networks, such as
Frame Relay and SMDS, situations can arise for which this behavior is less than ideal. For these
situations, you might want to disable split horizon. This applies to IGRP and RIP.
If an interface is configured with secondary IP addresses and split horizon is enabled, updates might
not be sourced by every secondary address. One routing update is sourced per network number
unless split horizon is disabled.
To enable or disable split horizon, perform the following tasks in interface configuration mode:
Task Command
Enable split horizon. ip split-horizon
Disable split horizon. no ip split-horizon
Split horizon for Frame Relay and SMDS encapsulation is disabled by default. Split horizon is not
disabled by default for interfaces using any of the X.25 encapsulations. For all other encapsulations,
split horizon is enabled by default.
See the section “Split Horizon Examples” at the end of this chapter for examples of using split
horizon.
Note In general, changing the state of the default is not recommended unless you are certain that
your application requires making a change in order to advertise routes properly. Remember: If split
horizon is disabled on a serial interface (and that interface is attached to a packet-switched network),
you must disable split horizon for all routers in any relevant multicast groups on that network.

You can remove all contents of a particular cache, table, or database. You also can display specific
router statistics. The following sections describe each of these tasks.
Clear Caches, Tables, and Databases

You can remove all contents of a particular cache, table, or database. Clearing a cache, table, or
database can become necessary when the contents of the particular structure have become or are
suspected to be invalid.
The following table lists the tasks associated with clearing caches, tables, and databases for IP
routing protocols. Perform these tasks in EXEC mode:
Task Command
Clear the IP ARP cache and the fast-switching clear arp-cache
cache.
Reset a particular BGP connection. clear ip bgp address
Reset all BGP connections. clear ip bgp *

Task Command
Remove all members of a BGP peer group. clear ip bgp peer-group tag
Delete routes from the DVMRP routing table. clear ip dvmrp route { * | route}
Delete neighbors from the neighbor table. clear ip eigrp neighbors [ip-address | interface]
Delete entries from the IGMP cache. clear ip igmp group [group-name | group-address |
interface]
Delete entries from the IP multicast routing clear ip mroute {* | group [source]}
table.
Clear one or more routes from the IP routing clear ip route {network [mask] | *}
table.
Delete session directory cache entries. clear ip sd [group-address | “session-name”]
Display System and Network Statistics

You can display specific router statistics such as the contents of IP routing tables, caches, and
databases. Information provided can be used to determine resource utilization and solve network
problems. You can also display information about node reachability and discover the routing path
your router’s packets are taking through the network.
To display various router statistics, perform the following tasks in EXEC mode:
Task Command
Trace a branch of a multicast tree for a specific mbranch group-address branch-address [ttl]
group.
Trace a branch of a multicast tree for a group in mrbranch group-address branch-address [ttl]
the reverse direction.
Query a multicast router about which mrinfo [hostname-or-address]
neighboring multicast routers are peering with [source-address-or-interface]
it.
Display IP multicast packet rate and loss mstat source [destination] [group]
information.
Trace the path from a source to a destination mtrace source [destination] [group]
branch for a multicast distribution tree for a
given group.
Send an ICMP Echo Request to a multicast ping [group-address-or-name]
group address.
Display all BGP routes that contain subnet and show ip bgp cidr-only
supernet network masks.
Display routes that belong to the specified show ip bgp community community-number [exact]
communities.
Display routes that are permitted by the show ip bgp community-list community-list-number
community list. [exact]
Display routes that are matched by the show ip bgp filter-list access-list-number
specified autonomous system path access list.
Display the routes with inconsistent originating show ip bgp inconsistent-as
autonomous systems.
Display the routes that match the specified show ip bgp regexp regular-expression
regular expression entered on the command
line.

Task Command
Display the contents of the BGP routing table. show ip bgp [network] [network-mask] [subnets]
Display detailed information on the TCP and show ip bgp neighbors [address]
BGP connections to individual neighbors.
Display routes learned from a particular BGP show ip bgp neighbors address [routes | paths]
neighbor.
Display all BGP paths in the database. show ip bgp paths
Display information about BGP peer groups. show ip bgp peer-group [tag] [summary]
Display the status of all BGP connections. show ip bgp summary
Display the syslog, including neighbor state show logging
changes.
Display the entries in the DVMRP routing show ip dvmrp route [ip-address]
table.
Display statistics on EGP connections and show ip egp
neighbors.
Display the IP Enhanced IGRP discovered show ip eigrp neighbors [type number]
neighbors.
Display the IP Enhanced IGRP topology table show ip eigrp topology [autonomous-system-number |
for a given process. [[ip-address] mask]]
Display the number of packets sent and show ip eigrp traffic [autonomous-system-number]
received for all or a specified IP Enhanced
IGRP process.
Display the multicast groups that are directly show ip igmp groups [group-name | group-address | type
connected to the router and that were learned number]
via IGMP.
Display multicast-related information about an show ip igmp interface [type number]
interface.
Display IRDP values. show ip irdp
Display the local policy route map, if any. show ip local policy
Display the contents of the IP fast switching show ip mcache [group [source]]
cache.
Display the contents of the IP multicast routing show ip mroute [group-name | group-address] [source]
table. [summary] [count] [active kbps]
Display general information about OSPF show ip ospf [process-id]
routing processes in a particular router.

Task Command
Display lists of information related to the OSPF show ip ospf [process-id area-id] database
database for a specific router. show ip ospf [process-id area-id] database [router]
[link-state-id]
show ip ospf [process-id area-id] database [network]
[link-state-id]
show ip ospf [process-id area-id] database [summary]
[link-state-id]
show ip ospf [process-id area-id] database
[asb-summary] [link-state-id]
show ip ospf [process-id] database [external]
[link-state-id]
show ip ospf [process-id area-id] database
[database-summary]
Display the internal OSPF routing table entries show ip ospf border-routers
to Area Border Router (ABR) and Autonomous
System Boundary Router (ASBR).
Display OSPF-related interface information. show ip ospf interface [interface-name]
Display OSPF-neighbor information on a show ip ospf neighbor [interface-name] [neighbor-id]
per-interface basis. detail
Display a list of all LSAs requested by a router. show ip ospf request-list [nbr] [intf] [intf-nbr]
Display a list of all LSAs waiting to be show ip ospf retransmission-list [nbr] [intf] [intf-nbr]
retransmitted.
Display OSPF-related virtual links information. show ip ospf virtual-links
Display information about interfaces show ip pim interface [type number]
configured for PIM.
List the PIM neighbors discovered by the show ip pim neighbor [type number]
router.
Display the RP routers associated with a show ip pim rp [group-name | group-address]
sparse-mode multicast group.
Display policy route maps. show ip policy
Display the parameters and current state of the show ip protocols
active routing protocol process.
Display the current state of the routing table. show ip route [address [mask]] | [protocol [process-id]]
Display the current state of the routing table in show ip route summary
summary form.
Display supernets. show ip route supernets-only
Display how the router is doing Reverse-Path show ip rpf source-address-or-name
Forwarding (that is, from the unicast routing
table, DVMRP routing table, or static mroutes).
Display the contents of the session directory. show ip sd [group | “session-name” | detail]
Display the IS-IS link state database. show isis database [level-1] [level-2] [l1] [l2] [detail]
[lspid]
Display all route maps configured or only the show route-map [map-name]
one specified.

IP Routing Protocol Configuration Examples

The following sections provide IP routing protocol configuration examples:
• Variable-Length Subnet Masks Example
• Overriding Static Routes with Dynamic Protocols Example
• OSPF Point-to-Multipoint Example
• Configuring IS-IS as an IP Routing Protocol Example
• Static Routing Redistribution Example
• IGRP Redistribution Example
• RIP and IGRP Redistribution Example
• IP Enhanced IGRP Redistribution Examples
• RIP and IP Enhanced IGRP Redistribution Examples
• IP Multicast Routing Configuration Examples
• OSPF Routing and Route Redistribution Examples
• BGP Route Advertisement and Redistribution Examples
• Default Metric Values Redistribution Example
• Route-Map Examples
• IGRP Feasible Successor Relationship Example
• BGP Neighbor Configuration Examples
• BGP Synchronization Example
• BGP Path Filtering by Neighbor Example
• BGP Route Map Examples
• BGP Community Examples with Route Maps
• TCP MD5 Authentication for BGP Example
• BGP Aggregate Route Examples
• BGP Confederation Example
• BGP Peer Group Examples
• Third-Party EGP Support Example
• Backup EGP Router Example
• EGP Core Gateway Example
• Autonomous System within EGP Example
• Passive Interface Examples
• Administrative Distance Examples
• Policy Routing Example
• Split Horizon Examples

Variable-Length Subnet Masks Example

OSPF, static routes, and IS-IS support variable-length subnet masks (VLSMs). With VLSMs, you
can use different masks for the same network number on different interfaces, which allows you to
conserve IP addresses and more efficiently use available address space.
In the following example, a 30-bit subnet mask is used, leaving two bits of address space reserved
for serial line host addresses. There is sufficient host address space for two host endpoints on a
point-to-point serial link.
interface ethernet 0
ip address 131.107.1.1 255.255.255.0
! 8 bits of host address space reserved for ethernets
interface serial 0
ip address 131.107.254.1 255.255.255.252
! 2 bits of address space reserved for serial lines
! Router is configured for OSPF and assigned AS 107

router ospf 107
! Specifies network directly connected to the router
network 131.107.0.0 0.0.255.255 area 0.0.0.0
Overriding Static Routes with Dynamic Protocols Example

In the following example, packets for network 10.0.0.0 from Router B, where the static route is
installed, will be routed through 131.108.3.4 if a route with an administrative distance less than 110
is not available. Figure 19-7 illustrates this point. The route learned by a protocol with an
administrative distance of less than 110 might cause Router B to send traffic destined for network
10.0.0.0 via the alternate path—through Router D.
ip route 10.0.0.0 255.0.0.0 131.108.3.4 110

Figure 19-7 Overriding Static Routes
Router A
Router B 131.108.3.4
Router C
10.0.0.0
S1269a
Router D
OSPF Point-to-Multipoint Example

In Figure 19-8, Mollie uses DLCI 201 to communicate with Neon, DLCI 202 to Jelly, and DLCI 203
to Platty. Neon uses DLCI 101 to communicate with Mollie and DLCI 102 to communicate with
Platty. Platty communicates with Neon (DLCI 401) and Mollie (DLCI 402). Jelly communicates
with Mollie (DLCI 301).
Figure 19-8 OSPF Point-to-Multipoint Example

Mollie
Neon 201
10.0.0.1 101
203 202
102
401 301
Platty Jelly
10.0.0.4
S3775
402
Mollie’s Configuration
hostname mollie
!
interface serial 1
ip address 10.0.0.2 255.0.0.0
ip ospf network point-to-multipoint
encapsulation frame-relay
frame-relay map ip 10.0.0.1 201 broadcast
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0

Neon’s Configuration
hostname neon
!
interface serial 0
ip address 10.0.0.1 255.0.0.0
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
Platty’s Configuration
hostname platty
!
interface serial 3
ip address 10.0.0.4 255.0.0.0
clockrate 1000000
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
Jelly’s Configuration
hostname jelly
!
interface serial 2
ip address 10.0.0.3 255.0.0.0
clockrate 2000000
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0

Configuring IS-IS as an IP Routing Protocol Example

The following example shows how you would configure three routers to run IS-IS as an IP routing
protocol. Figure 19-9 illustrates the example configuration.
Figure 19-9 Illustration of IS-IS Routing

E0 E0
Router A S0 Router B
E1
Router C
S2582
E2
Configuration for Router A

router isis
net 49.0001.0000.0000.000a.00
ip router isis
interface serial 0
ip router isis
Configuration for Router B

router isis
net 49.0001.0000.0000.000b.00
ip router isis
ip router isis
interface serial 0
ip router isis
Configuration for Router C

router isis
net 49.0001.0000.0000.000c.00
ip router isis
ip router isis

Static Routing Redistribution Example

In the example that follows, three static routes are specified, two of which are to be advertised. Do
this by specifying the redistribute static router configuration command, then specifying an access
list that allows only those two networks to be passed to the IGRP process. Any redistributed static
routes should be sourced by a single router to minimize the likelihood of creating a routing loop.
ip route 192.1.2.0 255.255.255.0 192.31.7.65
ip route 193.62.5.0 255.255.255.0 192.31.7.65
ip route 131.108.0.0 255.255.255.0 192.31.7.65
access-list 3 permit 192.1.2.0
!
router igrp 109
network 192.31.7.0
default-metric 10000 100 255 1 1500
redistribute static
distribute-list 3 out static
IGRP Redistribution Example

Each IGRP routing process can provide routing information to only one autonomous system; the
router must run a separate IGRP process and maintain a separate routing database for each
autonomous system it services. However, you can transfer routing information between these
routing databases.
Suppose the router has one IGRP routing process for network 15.0.0.0 in autonomous system 71 and
another for network 192.31.7.0 in autonomous system 109, as the following commands specify:
router igrp 71
network 15.0.0.0
router igrp 109
network 192.31.7.0
To transfer a route to 192.31.7.0 into autonomous system 71 (without passing any other information
about autonomous system 109), use the command in the following example:
router igrp 71
redistribute igrp 109
distribute-list 3 out igrp 109
RIP and IGRP Redistribution Example

Consider a WAN at a university that uses RIP as an interior routing protocol. Assume that the
university wants to connect its wide-area network to a regional network, 128.1.0.0, which uses IGRP
as the routing protocol. The goal in this case is to advertise the networks in the university network
to the routers on the regional network. The commands for the interconnecting router are listed in the
example that follows:
router igrp 109
network 128.1.0.0
redistribute rip
default-metric 10000 100 255 1 1500
distribute-list 10 out rip

In this example, the router global configuration command starts an IGRP routing process. The
network router configuration command specifies that network 128.1.0.0 (the regional network) is to
receive IGRP routing information. The redistribute router configuration command specifies that
RIP-derived routing information be advertised in the routing updates. The default-metric router
configuration command assigns an IGRP metric to all RIP-derived routes.
The distribute-list router configuration command instructs the router to use access list 10 (not
defined in this example) to limit the entries in each outgoing update. The access list prevents
unauthorized advertising of university routes to the regional network.
IP Enhanced IGRP Redistribution Examples

Each IP Enhanced IGRP routing process can provide routing information to only one autonomous
system; the router must run a separate IP Enhanced IGRP process and maintain a separate routing
database for each autonomous system it services. However, you can transfer routing information
between these routing databases.
Suppose the router has one IP Enhanced IGRP routing process for network 15.0.0.0 in autonomous
system 71 and another for network 192.31.7.0 in autonomous system 109, as the following
commands specify:
router eigrp 71
network 15.0.0.0
router eigrp 109
network 192.31.7.0
To transfer a route from 192.31.7.0 into autonomous system 71 (without passing any other
information about autonomous system 109), use the command in the following example:
router eigrp 71
redistribute eigrp 109 route-map 109-to-71
route-map 109-to-71 permit
match ip address 3
set metric 10000 100 1 255 1500
The following example is an alternative way to transfer a route to 192.31.7.0 into autonomous
system 71. Unlike the previous configuration, this one does not allow you to arbitrarily set the
metric.
router eigrp 71
redistribute eigrp 109
distribute-list 3 out eigrp 109
RIP and IP Enhanced IGRP Redistribution Examples

This sections provides two examples of RIP and IP Enhanced IGRP redistribution, a simple one and
a complex one.
Example 1: Simple Redistribution

Consider a wide-area network at a university that uses RIP as an interior routing protocol. Assume
that the university wants to connect its wide-area network to a regional network, 128.1.0.0, which
uses IP Enhanced IGRP as the routing protocol. The goal in this case is to advertise the networks in
the university network to the routers on the regional network. The commands for the interconnecting
router are listed in the example that follows:

router eigrp 109

network 128.1.0.0
redistribute rip
default-metric 10000 100 255 1 1500
In this example, the router global configuration command starts an IP Enhanced IGRP routing
process. The network router configuration command specifies that network 128.1.0.0 (the regional
network) is to send and receive IP Enhanced IGRP routing information. The redistribute router
configuration command specifies that RIP-derived routing information be advertised in the routing
updates. The default-metric router configuration command assigns an IP Enhanced IGRP metric to
all RIP-derived routes.
The distribute-list router configuration command instructs the router to use access list 10 (not
defined in this example) to limit the entries in each outgoing update. The access list prevents
unauthorized advertising of university routes to the regional network.
Example 2: Complex Redistribution

The most complex redistribution case is one in which mutual redistribution is required between an
IGP (in this case IP Enhanced IGRP) and BGP.
Suppose that BGP is running on a router somewhere else in autonomous system 1, and that the BGP
routes are injected into IP Enhanced IGRP routing process 1. You must use filters to ensure that the
proper routes are advertised. The example configuration for router R1 illustrates use of access filters
and a distribution list to filter routes advertised to BGP neighbors. This example also illustrates
configuration commands for redistribution between BGP and IP Enhanced IGRP.
! Configuration for router R1:
router bgp 1
network 131.108.0.0
neighbor 192.5.10.1 remote-as 2
redistribute eigrp 1
distribute-list 1 out eigrp 1
!
! All networks that should be advertised from R1 are controlled with access lists:
!
!
router eigrp 1
network 131.108.0.0
network 192.5.10.0
redistribute bgp 1
IP Multicast Routing Configuration Examples

This section provides the following IP multicast routing configuration examples:
• Configure a Router to Operate in Dense Mode Example
• Configure a Router to Operate in Sparse Mode Example
• Configure DVMRP Interoperability Examples

Configure a Router to Operate in Dense Mode Example

The following example configures dense-mode PIM on an Ethernet interface of the router:
ip multicast-routing
ip pim dense-mode
Configure a Router to Operate in Sparse Mode Example

The following example configures the router to operate in sparse-mode PIM. The RP router is the
router whose address is 10.8.0.20.
!
ip pim rp-address 10.8.0.20 1
ip pim sparse-mode
Configure DVMRP Interoperability Examples

The following example configures DVMRP interoperability for configurations when the PIM router
and the DVMRP router are on the same network segment. In this example, access list 1 advertises
the networks (98.92.35.0, 198.92.36.0, 198.92.37.0, 131.108.0.0, and 150.136.0.0 to the DVMRP
router, and access list 2 is used to prevent all other networks from being advertised (ip dvmrp metric
0).
ip address 131.119.244.244 255.255.255.0
ip pim dense-mode
ip dvmrp metric 1 list 1
ip dvmrp metric 0 list 2
access-list 1 permit 198.92.35.0 0.0.0.255

access-list 1 deny 0.0.0.0 255.255.255.255
The following example configures DVMRP interoperability over a tunnel interface:

!
!
interface tunnel 0
ip unnumbered ethernet 0
ip pim dense-mode
tunnel source ethernet 0
tunnel destination 192.70.92.133
tunnel mode dvmrp
!
description Universitat DMZ-ethernet
ip address 192.76.243.2 255.255.255.0
ip pim dense-mode

OSPF Routing and Route Redistribution Examples

OSPF typically requires coordination among many internal routers, area border routers, and
autonomous system boundary routers. At a minimum, OSPF-based routers can be configured with
all default parameter values, with no authentication, and with interfaces assigned to areas.
Three examples follow:
• The first is a simple configuration illustrating basic OSPF commands.
• The second example illustrates a configuration for internal, area border, and autonomous system
boundary routers within a single, arbitrarily assigned, OSPF autonomous system.
• The third example illustrates a more complex configuration and the application of various tools
available for controlling OSPF-based routing environments.
Example 1: Basic OSPF Configuration

The following example illustrates a simple OSPF configuration that enables OSPF routing process
9000, attaches Ethernet 0 to area 0.0.0.0, and redistributes RIP into OSPF, and OSPF into RIP:
ip address 130.93.1.1 255.255.255.0
ip ospf cost 1
!
ip address 130.94.1.1 255.255.255.0
!
router ospf 9000
network 130.93.0.0 0.0.255.255 area 0.0.0.0
redistribute rip metric 1 subnets
!
router rip
network 130.94.0.0
redistribute ospf 9000
default-metric 1
Example 2: Another Basic OSPF Configuration

The following example illustrates the assignment of four area IDs to four IP address ranges. In the
example, OSPF routing process 109 is initialized, and four OSPF areas are defined: 10.9.50.0, 2, 3,
and 0. Areas 10.9.50.0, 2, and 3 mask specific address ranges, while Area 0 enables OSPF for all
other networks.
router ospf 109
network 131.108.20.0 0.0.0.255 area 10.9.50.0
network 131.108.0.0 0.0.255.255 area 2
network 131.109.10.0 0.0.0.255 area 3
network 0.0.0.0 255.255.255.255 area 0
!
! Interface Ethernet0 is in area 10.9.50.0:
ip address 131.108.20.5 255.255.255.0
!
! Interface Ethernet1 is in area 2:
ip address 131.108.1.5 255.255.255.0
!
ip address 131.108.2.5 255.255.255.0
!


ip address 131.109.10.5 255.255.255.0
!
ip address 131.109.1.1 255.255.255.0
!
ip address 10.1.0.1 255.255.0.0
Each network router configuration command is evaluated sequentially, so the specific order of these
commands in the configuration is important. The router sequentially evaluates the
address/wildcard-mask pair for each interface. See the “IP Routing Protocols Commands” chapter
of the Router Products Command Reference publication for more information.
Consider the first network command. Area ID 10.9.50.0 is configured for the interface on which
subnet 131.108.20.0 is located. Assume that a match is determined for interface Ethernet 0. Interface
Ethernet 0 is attached to Area 10.9.50.0 only.
The second network command is evaluated next. For Area 2, the same process is then applied to all
interfaces (except interface Ethernet 0). Assume that a match is determined for interface Ethernet 1.
OSPF is then enabled for that interface and Ethernet 1 is attached to Area 2.
This process of attaching interfaces to OSPF areas continues for all network commands. Note that
the last network command in this example is a special case. With this command all available
interfaces (not explicitly attached to another area) are attached to Area 0.
Example 3: Internal, Area Border, and Autonomous System Boundary Routers

The following example outlines a configuration for several routers within a single OSPF
autonomous system. Figure 19-10 provides a general network map that illustrates this example
configuration.

Figure 19-10 Sample OSPF Autonomous System Network Map

AS 109
Area 1
Router A Router B
E1 E2 Interface address:
Interface address:
131.108.1.1 131.108.1.2
Network: 131.108.1.0
Interface address:
E3 131.108.1.3
Router C
S0 Interface address:
131.108.2.3
Network: 131.108.2.0
S1 Area 0
Interface address:
Router D 131.108.2.4
E4
Interface address:
10.0.0.4
Network: 10.0.0.0 Interface address:
10.0.0.5
E5
Interface address: Remote address:
Router E S2 11.0.0.5 11.0.0.6
in AS 110
Network: 11.0.0.0
S1030a
In this configuration, five routers are configured in OSPF autonomous system 109:
• Router A and Router B are both internal routers within Area 1.
• Router C is an OSPF area border router; note that for Router C, Area 1 is assigned to E3 and
Area 0 is assigned to S0.
• Router D is an internal router in Area 0 (backbone area); in this case, both network router
configuration commands specify the same area (Area 0, or the backbone area).
• Router E is an OSPF autonomous system boundary router; note that BGP routes are redistributed
into OSPF and that these routes are advertised by OSPF.

Note It is not necessary to include definitions of all areas in an OSPF autonomous system in the
configuration of all routers in the autonomous system. You need only define the directly connected
areas. In the example that follows, routes in Area 0 are learned by the routers in Area 1 (Router A
and Router B) when the area border router (Router C) injects summary link state advertisements
(LSAs) into Area 1.
Autonomous system 109 is connected to the outside world via the BGP link to the external peer at
IP address 11.0.0.6.
Router A—Internal Router

ip address 131.108.1.1 255.255.255.0
router ospf 109

network 131.108.0.0 0.0.255.255 area 1
Router B—Internal Router

ip address 131.108.1.2 255.255.255.0
router ospf 109

network 131.108.0.0 0.0.255.255 area 1
Router C—Area Border Router

ip address 131.108.1.3 255.255.255.0
interface serial 0
ip address 131.108.2.3 255.255.255.0
router ospf 109

network 131.108.1.0 0.0.0.255 area 1
network 131.108.2.0 0.0.0.255 area 0
Router D—Internal Router

ip address 10.0.0.4 255.0.0.0
interface serial 1
ip address 131.108.2.4 255.255.255.0
router ospf 109

network 131.108.2.0 0.0.0.255 area 0
network 10.0.0.0 0.255.255.255 area 0
Router E—Autonomous System Boundary Router

ip address 10.0.0.5 255.0.0.0
interface serial 2
ip address 11.0.0.5 255.0.0.0

router ospf 109

network 10.0.0.0 0.255.255.255 area 0
redistribute bgp 109 metric 1 metric-type 1
router bgp 109

network 131.108.0.0
network 10.0.0.0
Example 4: Complex OSPF Configuration

The following example configuration accomplishes several tasks in setting up an area border router.
These tasks can be split into two general categories:
• Basic OSPF configuration
• Route redistribution
The specific tasks outlined in this configuration are detailed briefly in the following descriptions.
Figure 19-11 illustrates the network address ranges and area assignments for the interfaces.
Figure 19-11 Interface and Area Specifications for OSPF Example Configuration
Network address range:

192.42.110.0 through 192.42.110.255
Area ID: 192.42.110.0

Router A E0 131.119.251.0 through 131.119.251.255
Area ID: 0
E3 E1 Configured as backbone area
E2

36.56.0.0 through 35.56.255.255
Area ID: 36.0.0.0 Network address range:
Configured as stub area 131.119.254.0 through 131.254.255
S1031a
Area ID: 0
Configured as backbone area
The basic configuration tasks in this example are as follows:

• Configure address ranges for Ethernet 0 through Ethernet 3 interfaces.
• Enable OSPF on each interface.
• Set up an OSPF authentication password for each area and network.
• Assign link state metrics and other OSPF interface configuration options.
• Create a stub area with area id 36.0.0.0. (Note that the authentication and stub options of the
area router configuration command are specified with separate area command entries, but can
be merged into a single area command.)
• Specify the backbone area (Area 0).

Configuration tasks associated with redistribution are as follows:

• Redistribute IGRP and RIP into OSPF with various options set (including metric-type, metric,
tag, and subnet).
• Redistribute IGRP and OSPF into RIP.
The following is an example OSPF configuration:

ip address 192.42.110.201 255.255.255.0
ip ospf authentication-key abcdefgh
ip ospf cost 10
!
ip address 131.119.251.201 255.255.255.0
ip ospf authentication-key ijklmnop
ip ospf cost 20
ip ospf retransmit-interval 10
ip ospf transmit-delay 2
ip ospf priority 4
!
ip address 131.119.254.201 255.255.255.0
ip ospf authentication-key abcdefgh
ip ospf cost 10
!
ip address 36.56.0.201 255.255.0.0
ip ospf authentication-key ijklmnop
ip ospf cost 20
ip ospf dead-interval 80
OSPF is on network 131.119.0.0:

router ospf 201
network 36.0.0.0 0.255.255.255 area 36.0.0.0
network 192.42.110.0 0.0.0.255 area 192.42.110.0
network 131.119.0.0 0.0.255.255 area 0
area 0 authentication
area 36.0.0.0 stub
area 36.0.0.0 authentication
area 36.0.0.0 default-cost 20
area 192.42.110.0 authentication
area 36.0.0.0 range 36.0.0.0 255.0.0.0
area 192.42.110.0 range 192.42.110.0 255.255.255.0
area 0 range 131.119.251.0 255.255.255.0
area 0 range 131.119.254.0 255.255.255.0
redistribute igrp 200 metric-type 2 metric 1 tag 200 subnets

redistribute rip metric-type 2 metric 1 tag 200
IGRP autonomous system 200 is on 131.119.0.0:

router igrp 200
network 131.119.0.0
!
! RIP for 192.42.110
!
router rip
network 192.42.110.0
redistribute igrp 200 metric 1
redistribute ospf 201 metric 1

BGP Route Advertisement and Redistribution Examples

The following examples illustrate configurations for advertising and redistributing BGP routes. The
first example details the configuration for two neighboring routers that run IGRP within their
respective autonomous systems and that are configured to advertise their respective BGP routes
between each other. The second example illustrates route redistribution of BGP into IGRP and IGRP
into BGP.
Example 1: Simple BGP Route Advertisement

This example provides the required configuration for two routers (R1 and R2) that are intended to
advertise BGP routes to each other and to redistribute BGP into IGRP.
Configuration for Router R1

! Assumes autonomous system 1 has network number 131.108.0.0
router bgp 1
network 131.108.0.0
!
router igrp 1
network 131.108.0.0
network 192.5.10.0
redistribute bgp 1
! Note that IGRP is not redistributed into BGP

router bgp 2
network 150.136.0.0
!
router igrp 2
network 150.136.0.0
network 192.5.10.0
redistribute bgp 2
Example 2: Mutual Route Redistribution

The most complex redistribution case is one in which mutual redistribution is required between an
IGP (in this case IGRP) and BGP.
Suppose that EGP is running on a router somewhere else in autonomous system 1, and that the EGP
routes are injected into IGRP routing process 1. You must filter to ensure that the proper routes are
advertised. The example configuration for router R1 illustrates use of access filters and a distribution
list to filter routes advertised to BGP neighbors. This example also illustrates configuration
commands for redistribution between BGP and IGRP. Only routes learned using the EBGP session
with neighbors 192.5.10.1 and 192.5.10.24 are redistributed into IGRP.

router bgp 1
network 131.108.0.0
! External peer or neighbor
! Same AS; therefore internal neighbor

! A second External neighbor

redistribute igrp 1
distribute-list 1 out igrp 1
!
! All networks that should be
! advertised from R1 are
! controlled with access lists:
!
!
router igrp 1
network 131.108.0.0
network 192.5.10.0
redistribute bgp 1
Default Metric Values Redistribution Example

The following example shows a router in autonomous system 109 using both the RIP and the IGRP
routing protocols. The example advertises IGRP-derived routes using the RIP protocol and assigns
the IGRP-derived routes a RIP metric of 10.
router rip
default-metric 10
redistribute igrp 109
Route-Map Examples
The examples in this section illustrate the use of redistribution, with and without route maps.
Examples from both the IP and CLNS routing protocols are given.
The following example redistributes all OSPF routes into IGRP:
router igrp 109
redistribute ospf 110
The following example redistributes RIP routes with a hop count equal to 1 into OSPF. These routes
will be redistributed into OSPF as external link state advertisements with a metric of 5, metric type
of Type 1, and a tag equal to 1.
router ospf 109
redistribute rip route-map rip-to-ospf
!
route-map rip-to-ospf permit
match metric 1
set metric 5
set metric-type type1
set tag 1
The following example redistributes OSPF learned routes with tag 7 as a RIP metric of 15:
router rip
redistribute ospf 109 route-map 5
!
route-map 5 permit
match tag 7
set metric 15

The following example redistributes OSPF intra-area and interarea routes with next-hop routers on
serial interface 0 into BGP with an INTER_AS metric of 5:
router bgp 109
!
route-map 10 permit
match route-type internal
match interface serial 0
set metric 5
The following example redistributes two types of routes into the integrated IS-IS routing table
(supporting both IP and CLNS). The first are OSPF external IP routes with tag 5; these are inserted
into Level 2 IS-IS LSPs with a metric of 5. The second are ISO-IGRP derived CLNS prefix routes
that match CLNS access list 2000. These will be redistributed into IS-IS as Level 2 LSPs with a
metric of 30.
router isis
redistribute iso-igrp nsfnet route-map 3
!
route-map 2 permit
match route-type external
match tag 5
set metric 5
set level level-2
!
route-map 3 permit
match address 2000
set metric 30
With the following configuration, OSPF external routes with tags 1, 2, 3, and 5 are redistributed into
RIP with metrics of 1, 1, 5, and 5, respectively. The OSPF routes with a tag of 4 are not redistributed.
router rip
!
route-map 1 permit
match tag 1 2
set metric 1
!
route-map 1 permit
match tag 3
set metric 5
!
route-map 1 deny
match tag 4
!
route map 1 permit
match tag 5
set metric 5
Given the following configuration, a RIP learned route for network 160.89.0.0 and an ISO-IGRP
learned route with prefix 49.0001.0002 will be redistributed into an IS-IS Level 2 LSP with a metric
of 5:
router isis
redistribute rip route-map 1
redistribute iso-igrp remote route-map 1
!
route-map 1 permit
match ip address 1
match clns address 2
set metric 5

set level level-2

!
clns filter-set 2 permit 49.0001.0002...
The following configuration example illustrates how a route map is referenced by the
default-information router configuration command. This is called conditional default origination.
OSPF will originate the default route (network 0.0.0.0) with a Type 2 metric of 5 if 140.222.0.0 is
in the routing table.
route-map ospf-default permit
match ip address 1
set metric 5
set metric-type type-2
!
access-list 1 140.222.0.0 0.0.255.255
!
router ospf 109
default-information originate route-map ospf-default
See more route map examples in the sections “BGP Route Map Examples” and “BGP Community
Examples with Route Maps.”
IGRP Feasible Successor Relationship Example

In Figure 19-12, the assigned metrics meet the conditions required for a feasible successor
relationship, so the paths in this example can be included in routing tables and used for load
balancing.
Figure 19-12 Assigning Metrics for IGRP Path Feasibility
Route to Network A Route to Network A

Metric = m = 10876 Metric = p = 10776
S1068 c
Router C1 Router C2
Route to Network A
Metric = n = 12776
The feasibility test would work as follows:

Assume that Router C1 already has a route to Network A with metric m and has just received an
update about Network A from C2. The best metric at C2 is p. The metric that C1 would use through
C2 is n.
If both of the following two conditions are met, the route to network A through C2 will be included
in C1’s routing table:
• If m is greater than p.
• If the multiplier (value specified by the variance router configuration command) times m is
greater than or equal to n.
The configuration for Router C1 would be as follows:
router igrp 109
variance 10

A maximum of four paths can be in the routing table for a single destination. If there are more than
four feasible paths, the four best feasible paths are used.
BGP Neighbor Configuration Examples

In the following example, a BGP router is assigned to autonomous system 109, and two networks
are listed as originating in the autonomous system. Then the addresses of three remote routers (and
their autonomous systems) are listed. The router being configured will share information about
networks 131.108.0.0 and 192.31.7.0 with the neighbor routers. The first router listed is in a different
autonomous system; the second neighbor command specifies an internal neighbor (with the same
autonomous system number) at address 131.108.234.2; and the third neighbor command specifies
a neighbor on a different autonomous system.
router bgp 109
network 131.108.0.0
network 192.31.7.0
In Figure 19-13, Router A is being configured. The internal BGP neighbor is not directly linked to
Router A. External neighbors (in autonomous system 167 and autonomous system 99) must be
linked directly to Router A.
Figure 19-13 Assigning Internal and External BGP Neighbors
Router Router
Router
Router A Router
Internal BGP
AS 109 131.108.234.2
131.108.0.0
192.31.7.0
Router Router
S1270a
131.108.200.1 150.136.64.19
AS 167 AS 99

Using Access Lists to Specify Neighbors

In the following example, the router is configured to allow connections from any router that has an
IP address in access list 1; that is, any router with a 192.31.7.x address. Neighbors not explicitly
specified as neighbors can connect to the router, but the router will not attempt to connect to them if
the connection is broken. Continuing with the preceding sample configuration, the configuration is
as follows:
router bgp 109
network 131.108.0.0
network 192.31.7.0
neighbor internal-ethernet neighbor-list 1
BGP Synchronization Example

In the configuration shown in Figure 19-14, with synchronization on, Router B does not advertise
network 198.92.68.0 to Router A until an IGRP route for network 198.92.68.0 exists. If you specify
the no synchronization router configuration command, Router B advertises network 198.92.68.0 as
soon as possible. However, because routing information still must be sent to interior peers, you must
configure a full internal BGP mesh.
Figure 19-14 BGP Synchronization Configuration
AS
Router IGRP
Router A Router B Router
Router
Physical connectivity
EGBP connections
IBGP connections
Router
S2566
Network 198.92.68.0
BGP Path Filtering by Neighbor Example

The following is an example of BGP path filtering by neighbor. The routes that pass as-path access
list 1 will get weight 100. Only the routes that pass as-path access list 2 will be sent to 193.1.12.10.
Similarly, only routes passing access list 3 will be accepted from 193.1.12.10.

router bgp 200

neighbor 193.1.12.10 filter-list 1 weight 100
neighbor 193.1.12.10 filter-list 2 out
neighbor 193.1.12.10 filter-list 3 in
ip as-path access-list 1 permit _109_
ip as-path access-list 2 permit _200$
ip as-path access-list 2 permit ^100$
ip as-path access-list 3 deny _690$
ip as-path access-list 3 permit .*
BGP Route Map Examples

The following example shows how you can use route maps to modify incoming data from a
neighbor. Any route received from 140.222.1.1 that matches the filter parameters set in autonomous
system access list 200 will have its weight set to 200 and its local preference set to 250 and will be
accepted.
router bgp 100
!
neighbor 140.222.1.1 route-map fix-weight in
!
route-map fix-weight permit 10
match as-path 200
set local-preference 250
set weight 200
!
ip as-path access-list 200 permit ^690$
ip as-path access-list 200 permit ^1800
In the following example, route map freddy marks all paths originating from autonomous system 690
with a Multi Exit Discriminator (MED) metric attribute of 127. The second permit clause is required
so that routes not matching autonomous system path list 1 will still be sent to neighbor 1.1.1.1.
router bgp 100
neighbor 1.1.1.1 route-map freddy out
!
ip as-path access-list 1 permit ^690_
!
route-map freddy permit 10
match as-path 1
set metric 127
!
route-map freddy permit 20
match as-path 2
The following example shows how you can use route maps to modify incoming data from the IP
forwarding table:
router bgp 100
redistribute igrp 109 route-map igrp2bgp
!
route-map igrp2bgp
match ip address 1
set metric 127
set weight 30000
set next-hop 192.92.68.24
set origin igp
!


It is proper behavior to not accept any autonomous system path not matching the match clause of
the route map. This means that you will not set the metric and the router will not accept the route.
However, you can configure the router to accept autonomous system paths not matched in the match
clause of the route map command by using multiple maps of the same name, some without
accompanying set commands.
route-map fnord permit 10
match as-path 1
!
route-map fnord permit 20
match as-path 2
The following example shows how you can use route maps in a reverse operation to set the route tag
(as defined by the BGP/OSPF interaction document, RFC 1403) when exporting routes from BGP
into the main IP routing table:
router bgp 100
table-map set_ospf_tag
!
route-map set_ospf_tag
match as-path 1
set automatic-tag
!
In the following example, the route map called set-as-path is applied to outbound updates to the
neighbor 200.69.232.70. The route map will prepend the autonomous system path “100 100” to
routes that pass access list 1. The second part of the route map is to permit the advertisement of other
routes.
router bgp 100
network 171.60.0.0
network 172.60.0.0
neighbor 200.69.232.70 route-map set-as-path out
!
route-map set-as-path 10 permit
match address 1
set as-path prepend 100 100
!
route-map set-as-path 20 permit
match address 2
!
!
BGP Community Examples with Route Maps

This section contains three examples of the use of BGP communities with route maps.
In the first example, the route map set-community is applied to the outbound updates to the neighbor
171.69.232.50. The routes that pass access list 1 have the special community attribute value
“no-export.” The remaining routes are advertised normally. This special community value
automatically prevents the advertisement of those routes by the BGP speakers in autonomous
system 200.
router bgp 100


neighbor 171.69.232.50 send-community
neighbor 171.69.232.50 route-map set-community out
!
!
route-map set-community 10 permit
match address 1
set community no-export
!
match address 2
In the second example, the route map set-community is applied to the outbound updates to neighbor
171.69.232.90. All the routes that originate from AS 70 have the community values 200 200 added
to their already existing values. All other routes are advertised as normal.
route-map bgp 200
neighbor 171.69.232.90 send-community
neighbor 171.69.232.90 route-map set-community out
!
match as-path 1
set community 200 200 additive
!
match as-path 2
!
ip as-path access-list 1 permit 70$
In the third example, community-based matching is used to selectively set MED and
local-preference for routes from neighbor 171.69.232.55. All the routes that match community list 1
get the MED set to 8000. This includes any routes that have the communities “100 200 300” or
“900 901.” These routes could have other community values also.
All the routes that pass community list 2 get the local preference set to 500. This includes the routes
that have community values 88 or 90. If they belong to any other community, they will not be
matched by community list 2.
All the routes that match community list 3 get the local-preference set to 50. Community list 3 will
match all the routes because all the routes are members of the Internet community. Thus all the
remaining routes from neighbor 171.69.232.55 get a local preference 50.
router bgp 200
neighbor 171.69.232.55 route-map filter-on-community in
!
route-map filter-on-community 10 permit
match community 1
set metric 8000
!
match community 2 exact-match
!
match community 3
!
ip community-list 1 permit 100 200 300
ip community-list 1 permit 900 901
!
ip community-list 2 permit 88

ip community-list 2 permit 90
!
ip community-list 3 permit internet
TCP MD5 Authentication for BGP Example

The following example specifies that the router and its BGP peer at 145.2.2.2 invoke MD5
authentication on the TCP connection between them:
router bgp 109
neighbor 145.2.2.2 password v61ne0qkel33&
BGP Aggregate Route Examples

The following examples show how you can use aggregate routes in BGP either by redistributing an
aggregate route into BGP or by using the conditional aggregate routing feature.
In the following example, the redistribute static command is used to redistribute aggregate route
193.*.*.*:
ip route 193.0.0.0 255.0.0.0 null 0
!
router bgp 100
redistribute static
The following configuration creates an aggregate entry in the BGP routing table when there is at least
one specific route that falls into the specified range. The aggregate route will be advertised as coming
from your autonomous system and has the atomic aggregate attribute set to show that information
might be missing. (By default, atomic aggregate is set unless you use the as-set keyword in the
aggregate-address command.)
router bgp 100
aggregate-address 193.0.0.0 255.0.0.0
The following example creates an aggregate entry using the same rules as in the previous example,
but the path advertised for this route will be an AS_SET consisting of all elements contained in all
paths that are being summarized:
router bgp 100
aggregate-address 193.0.0.0 255.0.0.0 as-set
The following example not only creates the aggregate route for 193.*.*.*, but will also suppress
advertisements of more specific routes to all neighbors:
router bgp 100
aggregate-address 193.0.0.0 255.0.0.0 summary-only
BGP Confederation Example

The following is a sample configuration from several peers in a confederation. The confederation
consists of three internal autonomous systems with autonomous system numbers 6001, 6002, and
6003. To the BGP speakers outside the confederation, the confederation looks like a normal
autonomous system with autonomous system number 666 (specified via the bgp confederation
identifier command).

In a BGP speaker in autonomous system 6001, the bgp confederation peers command marks the
peers from autonomous systems 6002 and 6003 as special EBGP peers. Hence peers 171.69.232.55
and 171.69.232.56 will get the local-preference, next-hop and MED unmodified in the updates. The
router at 160.69.69.1 is a normal EBGP speaker and the updates received by it from this peer will be
just like a normal EBGP update from a peer in autonomous system 666.
router bgp 6001
bgp confederation identifier 666
bgp confederation peers 6002 6003
In a BGP speaker in autonomous system 6002, the peers from autonomous systems 6001 and 6003
are configured as special EBGP peers. 170.70.70.1 is a normal IBGP peer and 199.99.99.2 is a
normal EBGP peer from autonomous system 700.
router bgp 6002
In a BGP speaker in autonomous system 6003, the peers from autonomous systems 6001 and 6002
are configured as special EBGP peers. 200.200.200.200.200 is a normal EBGP peer from
autonomous system 701.
router bgp 6003
The following is a part of the configuration from the BGP speaker 200.200.200.205 from
autonomous system 701. Neighbor 171.69.232.56 is configured as a normal EBGP speaker from
autonomous system 666. The internal division of the autonomous system into multiple autonomous
systems is not known to the peers external to the confederation.
router bgp 701
BGP Peer Group Examples

This section contains an IBGP peer group example and an EBGP peer group example.
Example for an IBGP Peer Group

In the following example, the peer group named internal configures the members of the peer group
to be IBGP neighbors. By definition, this is an IBGP peer group because the router bgp command
and the neighbor remote-as command indicate the same autonomous system (in this case, AS 100).
All the peer group members use loopback 0 as the update source and use set-med as the outbound
route-map. The example also shows that, except for the neighbor at address 171.69.232.55, all the
neighbors have filter-list 2 as the inbound filter list.
router bgp 100
neighbor internal peer-group

neighbor internal remote-as 100

neighbor internal update-source loopback 0
neighbor internal route-map set-med out
neighbor internal filter-list 1 out
neighbor internal filter-list 2 in
neighbor 171.69.232.53 peer-group internal
Example for an EBGP Peer Group

In the following example, the peer group external-peers is defined without the neighbor remote-as
command. This is what makes it an EBGP peer group. Each member of the peer group is configured
with its respective autonomous system number separately. Thus the peer group consists of members
from autonomous systems 200, 300, and 400. All the peer group members have set-metric route map
as an outbound route map and filter-list 99 as an outbound filter list. Except for neighbor
171.69.232.110, all of them have 101 as the inbound filter list.
router bgp 100
neighbor external-peers peer-group
neighbor external-peers route-map set-metric out
neigbhor external-peers filter-list 99 out
neighbor external-peers filter-list 101 in
neighbor 171.69.232.90 peer-group external-peers
Third-Party EGP Support Example

In the following example configuration, the router is in autonomous system 110 communicating with
an EGP neighbor in autonomous system 109 with address 131.108.6.5. Network 131.108.0.0 is
advertised as originating within autonomous system 110. The configuration specifies that two
routers, 131.108.6.99 and 131.108.6.100, should be advertised as third-party sources of routing
information for those networks that are accessible through those routers. The global configuration
commands also specify that those networks should be flagged as internal to autonomous system 110.
autonomous-system 110
router egp 109
network 131.108.0.0
neighbor 131.108.6.5
neighbor 131.108.6.5 third-party 131.108.6.99 internal
neighbor 131.108.6.5 third-party 131.108.6.100 internal

Backup EGP Router Example

The following example configuration illustrates a router that is in autonomous system 110
communicating with an EGP neighbor in autonomous system 109 with address 131.108.6.5.
Network 131.108.0.0 is advertised with a distance of 1, and networks learned by RIP are being
advertised with a distance of 5. Access list 3 filters which RIP-derived networks are allowed in
outgoing EGP updates.
router egp 109
network 131.108.0.0
neighbor 131.108.6.5
redistribute rip
default-metric 5
EGP Core Gateway Example

The following example illustrates how an EGP core gateway can be configured.
Figure 19-15 illustrates an environment with three routers (designated C1, C2, and C3) attached to
a common X.25 network. The routers are intended to route information using EGP. With the
following configuration (on the router designated Core), C1, C2, and C3 cannot route traffic directly
to each other via the X.25 network:
! global access list assignment
router egp 0
neighbor any 1
This configuration specifies that an EGP process on any router on network 10.0.0.0 can act as a peer
with the Core router. All traffic in this configuration will flow through the Core router.
Third-party advertisements allow traffic to bypass the Core router and go directly to the router that
advertised reachability to the Core.
! global access list assignment
router egp 0
neighbor any 2
neighbor any third-party 10.1.1.1

Figure 19-15 Core EGP Third-Party Update Configuration Example
Core Router
X.25 PDN
Net address:
10.0.0.0
Interface Address:
10.1.1.1
Router C1 Router C2 Router C3
S1066a
Net address: Net address: Net address:
1.0.0.0 2.0.0.0 3.0.0.0
Autonomous System within EGP Example

The following example illustrates a typical configuration for an EGP router process. The router is in
autonomous system 109 and is peering with routers in autonomous system 164, as shown in
Figure 19-16. It will advertise the networks 131.108.0.0 and 192.31.7.0 to the router in autonomous
system 164, 10.2.0.2. The information sent and received from peer routers can be filtered in various
ways, including blocking information from certain routers and suppressing the advertisement of
specific routes.
router egp 164
network 131.108.0.0
network 192.31.7.0
neighbor 10.2.0.2

Figure 19-16 Router in AS 164 Peers with Router in AS 109
Router 131.108.0.0
10.0.0.0
Router 192.31.7.0
Router
S1025a
AS164 AS109
Passive Interface Examples

The following example sends IGRP updates to all interfaces on network 131.108.0.0 except interface
Ethernet 1. Figure 19-17 shows this configuration.
router igrp 109
network 131.108.0.0
passive-interface ethernet 1
Figure 19-17 Filtering IGRP Updates
IGRP router
S1067a
E1
No routing updates
sent to this interface
As in the first example, IGRP updates are sent to all interfaces on network 131.108.0.0 except
interface Ethernet 1 in the following example. However, in this case a neighbor router configuration
command is included. This command permits the sending of routing updates to specific neighbors.
One copy of the routing update is generated per neighbor.
router igrp 109
network 131.108.0.0
neighbor 131.108.20.4

In OSPF, hello packets are not sent on an interface that is specified as passive. Hence, the router will
not be able to discover any neighbors, and none of the OSPF neighbors will be able to see the router
on that network. In effect, this interface will appear as a stub network to the OSPF domain. This is
useful if you want to import routes associated with a connected network into the OSPF domain
without any OSPF activity on that interface.
The passive-interface router configuration command typically is used when the wildcard
specification on the network router configuration command configures more interfaces than is
desirable. The following configuration causes OSPF to run on all subnets of 131.108.0.0:
ip address 131.108.1.1 255.255.255.0
ip address 131.108.2.1 255.255.255.0
ip address 131.108.3.1 255.255.255.0
!
router ospf 109
network 131.108.0.0 0.0.255.255 area 0
If you do not want OSPF to run on 131.108.3.0, enter the following commands:
router ospf 109
network 131.108.0.0 0.0.255.255 area 0
Administrative Distance Examples

In the following example, the router igrp global configuration command sets up IGRP routing in
autonomous system 109. The network router configuration commands specify IGRP routing on
networks 192.31.7.0 and 128.88.0.0. The first distance router configuration command sets the
default administrative distance to 255, which instructs the router to ignore all routing updates from
routers for which an explicit distance has not been set. The second distance command sets the
administrative distance to 90 for all routers on the Class C network 192.31.7.0. The third distance
command sets the administrative distance to 120 for the router with the address 128.88.1.3.
router igrp 109
network 192.31.7.0
network 128.88.0.0
distance 255
distance 90 192.31.7.0 0.0.0.255
distance 120 128.88.1.3 0.0.0.0
The following example assigns the router with the address 192.31.7.18 an administrative distance of
100, and all other routers on subnet 192.31.7.0 an administrative distance of 200:
distance 100 192.31.7.18 0.0.0.0
distance 200 192.31.7.0 0.0.0.255
However, if you reverse the order of these commands, all routers on subnet 192.31.7.0 are assigned
an administrative distance of 200, including the router at address 192.31.7.18:
distance 200 192.31.7.0 0.0.0.255
distance 100 192.31.7.18 0.0.0.0
Assigning administrative distances is a problem unique to each network and is done in response to
the greatest perceived threats to the connected network. Even when general guidelines exist, the
network manager must ultimately determine a reasonable matrix of administrative distances for the
network as a whole.

In the following example, the distance value for IP routes learned is 90. Preference is given to these
IP routes rather than routes with the default administrative distance value of 110.
router isis
distance 90 ip
Policy Routing Example

The following example provides two sources with equal access to two different service providers.
Packets arriving on async interface 1 from the source 1.1.1.1 are sent to the router at 6.6.6.6 if the
router has no explicit route for the packet's destination. Packets arriving from the source 2.2.2.2 are
sent to the router at 7.7.7.7 if the router has no explicit route for the packet's destination. All other
packets for which the router has no explicit route to the destination are discarded.
access-list 1 permit ip 1.1.1.1 0.0.0.0
access-list 2 permit ip 2.2.2.2 0.0.0.0
!
interface async 1
ip policy route-map equal-access
!
route-map equal-access permit 10
match ip address 1
set ip default next-hop 6.6.6.6
match ip address 2
set ip default next-hop 7.7.7.7
set default interface null0
Split Horizon Examples

Two examples of configuring split horizon are provided.
Example 1
The following sample configuration illustrates a simple example of disabling split horizon on a serial
link. In this example, the serial link is connected to an X.25 network.
interface serial 0
encapsulation x25
no ip split-horizon
Example 2
In the next example, Figure 19-18 illustrates a typical situation in which the no ip split-horizon
interface configuration command would be useful. This figure depicts two IP subnets that are both
accessible via a serial interface on Router C (connected to Frame Relay network). In this example,
the serial interface on Router C accommodates one of the subnets via the assignment of a secondary
IP address.
The Ethernet interfaces for Router A, Router B, and Router C (connected to IP networks 12.13.50.0,
10.20.40.0, and 20.155.120.0) all have split horizon enabled by default, while the serial interfaces
connected to networks 128.125.1.0 and 131.108.1.0 all have split horizon disabled by default. The
partial interface configuration specifications for each router that follow Figure 19-18 illustrate that
the ip split-horizon command is not explicitly configured under normal conditions for any of the
interfaces.

In this example, split horizon must be disabled in order for network 128.125.0.0 to be advertised into
network 131.108.0.0, and vice versa. These subnets overlap at Router C, interface S0. If split horizon
were enabled on serial interface S0, it would not advertise a route back into the Frame Relay network
for either of these networks.
Figure 19-18 Disabled Split Horizon Example for Frame Relay Network
Network address: Network address:

10.20.40.0 20.155.120.0
Interface address: Interface address:
10.20.40.1 20.155.120.1
E0 E2
S0 S2
CS C CS B
Network address:
12.13.50.0
Interface address: Secondary
Interface address: interface address: Interface address:
12.13.50.1 131.108.1.2
128.125.1.1 131.108.1.1
E1
Network
S1 address:
Network 131.108.1.0
CS A address:
Interface address: 128.125.1.0
128.125.1.2
Frame Relay
network
S1069a
Configuration for Router A
ip address 12.13.50.1
!
interface serial 1
no ip split-horizon
Configuration for Router B

ip address 20.155.120.1
!
interface serial 2
no ip split-horizon
Configuration for Router C

!
interface serial 0

ip address 131.108.1.1 secondary


Cipro Ute

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cipro Ute

Uploaded by

Copyright:

Available Formats

CHAPT ER 1 9

Configuring IP Routing Protocols

Cisco’s Implementation of IP Routing Protocols

Interior Gateway Protocols

Configuring IP Routing Protocols 19-1

Exterior Gateway Protocols

Router Discovery Protocols

Multiple Routing Protocols

19-2 Router Products Configuration Guide

IP Routing Protocols Task List

Determine a Routing Process

Configuring IP Routing Protocols 19-3

Cisco’s IGRP Implementation

Figure 19-1 Interior, System, and Exterior Routes

Router Router Router

19-4 Router Products Configuration Guide

IGRP Configuration Task List

Create the IGRP Routing Process

Configuring IP Routing Protocols 19-5

Allow Point-to-Point Updates for IGRP

Define Unequal-Cost Load Balancing

19-6 Router Products Configuration Guide

Control Traffic Distribution

Adjust the IGRP Metric Weights

Configuring IP Routing Protocols 19-7

Enforce a Maximum Network Diameter

Validate Source IP Addresses

Configure Enhanced IGRP

Cisco’s Enhanced IGRP Implementation

19-8 Router Products Configuration Guide

Enhanced IGRP offers the following features:

Configuring IP Routing Protocols 19-9

Enhanced IGRP Configuration Task List

Enable IP Enhanced IGRP

Transition from IGRP to Enhanced IGRP

Configure IP Enhanced IGRP-Specific Parameters

19-10 Router Products Configuration Guide

Define Unequal-Cost Load Balancing

Adjust the IP Enhanced IGRP Metric Weights

Configuring IP Routing Protocols 19-11

Disable Route Summarization

Route summarization works in conjunction with the ip summary-address eigrp interface

Configure Summary Aggregate Addresses

Configure Protocol-Independent Parameters

19-12 Router Products Configuration Guide

Redistribute Routing Information

By default, the redistribution of default information between IP Enhanced IGRP processes is

Set Metrics for Redistributed Routes

Configuring IP Routing Protocols 19-13

Filter Routing Information

Prevent Routing Updates through an Interface

Control the Advertising of Routes in Routing Updates

Control the Processing of Routing Updates

19-14 Router Products Configuration Guide

Apply Offsets to Routing Metrics

Filter Sources of Routing Information

Table 19-1 Default Administrative Distances

Route Source Default Distance

Configuring IP Routing Protocols 19-15

19-16 Router Products Configuration Guide

Disable Split Horizon

Cisco’s OSPF Implementation

Configuring IP Routing Protocols 19-17

OSPF Configuration Task List