optimizacion1

MODULE 5 : ROUTE OPTIMIZATION

Overview

Dynamic routing, even in small internetworks, can involve much more than just enabling the default behavior of a routing protocol. Some of these behaviors may lead to inefficient use of bandwidth, security risks, or suboptimal routing.

For example, routing updates compete with user data for bandwidth and router resources. In some cases, the updates may not be required and yet are still advertised by default, contributing to bandwidth waste and increasing security risks. During route redistribution between IP routing domains, suboptimal routing can occur without manipulation.

Routing can be optimized in a network by controlling when a router exchanges routing updates and what those updates contain. To ensure that the network operates efficiently, you must control and tune routing updates. Information about networks must be sent where it is needed and filtered from where it is not needed.

This module examines the key IOS route optimization features, including route redistribution, routing update control, and policy-based routing. In addition, an overview of DHCP and how to configure support for it is covered.

5.1 Operating a Network Using Multiple Routing Protocols
5.1.1 Using Multiple Routing Protocols

Simple routing protocols work well for simple networks, but networks grow and become more complex. While running a single routing protocol throughout your entire IP internetwork is desirable, multiprotocol routing is common for a number of reasons, including company mergers, multiple departments managed by multiple network administrators, multivendor environments, or simply because the original routing protocol is no longer the best choice.

For example, Routing Information Protocol (RIP) periodically sends entire routing tables in updates. As a network grows larger, the traffic from those updates can slow the network down, indicating that a change to a more scalable routing protocol may be necessary. Another reason could be if a company is using Enhanced IGRP (EIGRP) but now needs a protocol that supports multiple vendors, or the company implements a policy that specifies a particular routing protocol.

Running a multiple protocol environment is often part of a network design, and network administrators must conduct migration from one routing protocol to another carefully and thoughtfully. Often the transition between routing protocols takes place gradually, so multiple routing protocols are operating in the network for variable lengths of time. It is important for network administrators to understand what must be changed and to create a detailed plan before making any changes. An accurate topology map of the network and an inventory of all network devices are also critical for success.

Link-state routing protocols, such as Open Shortest Path First (OSPF) and Intermediate System-to-Intermediate System (IS-IS), require a hierarchical network structure. Network administrators need to decide which routers will reside in the backbone area and how to divide the other routers into areas. While EIGRP does not require a hierarchical structure, it operates much more effectively within one.

Using a routing protocol to advertise routes that are learned by some other means, such as by another routing protocol, static routes, or directly connected routes, is called route redistribution.

Differences in routing protocol characteristics, such as metrics, administrative distance, classful and classless capabilities, can affect redistribution.
Hierarchical routing

5.1.2 Defining Route Redistribution

Multiple routing protocols may be necessary in the following situations:

• When you are migrating from an older interior gateway protocol (IGP) to a new IGP. Multiple redistribution boundaries may exist until the new protocol has completely
displaced the old protocol.

• When the use of another protocol is desired, but the old routing protocol is needed for host systems. This is common in environments with UNIX host-based routers running RIP.
• Some departments might not want to upgrade their routers to support a new routing protocol.

• In a mixed-router vendor environment, you can use a routing protocol specific to Cisco, such as EIGRP in the Cisco portion of the network, and a common standards-based routing protocol, like OSPF, to communicate with devices from other vendors.

When multiple routing protocols are running in different parts of the network, there may be a need for hosts in one part of the network to reach hosts in the other part. One solution is to advertise a default route into each routing protocol, but that is not always the best policy. The network design may not allow default routes.

If there is more than one way to get to a destination network, routers may need information about routes in other parts of the network to determine the best path to that destination.

Additionally, if there are multiple paths, a router must have sufficient information to determine a loop-free path to the remote networks.

Cisco routers allow internetworks using different routing protocols, referred to as routing domains or autonomous systems, to exchange routing information through a feature called route redistribution.
Redistribution is how routers connect different routing domains so that they can exchange and advertise routing information between the different autonomous systems.

Note
The term autonomous system as used here denotes internetworks using different routing protocols. These routing protocols may be IGPs or exterior gateway protocols (EGPs), which is a different use of autonomous system when referring to Border Gateway Protocol (BGP).

5.1.3 Redistributing Route Information

Within each autonomous system, the internal routers have complete knowledge about their network. The router that interconnects the autonomous systems is called a boundary router.

The boundary router must be running all the routing protocols that are exchanging routes.

When a router redistributes routes, it allows a routing protocol to advertise routes that were not learned through that routing protocol. These redistributed routes could have been learned via a different routing protocol, such as when redistributing between EIGRP and OSPF, from static routes, or by a direct connection to a network.

Routers can redistribute static and connected routes, and routes from other routing protocols.

Redistribution is always performed outbound. The router doing redistribution does not change its routing table. When redistribution between OSPF and EIGRP is configured, the OSPF process on the boundary router takes the EIGRP routes in the routing table and advertises them as OSPF routes to its OSPF neighbors.

Likewise, the EIGRP process on the boundary router takes the OSPF routes in the routing table and advertises them as EIGRP routes to its EIGRP neighbors. As a result, both autonomous systems know about the routes of the other, and each autonomous system can then make informed routing decisions for these networks.

EIGRP neighbors use the EIGRP external (D EX) listing to route traffic destined for the other autonomous system via the boundary router. The boundary router must have the OSPF routes for that destination network in its routing table to forward the traffic.

For this reason, routes must be in the routing table for them to be redistributed. This requirement may seem self-evident, but it can also be a source of confusion.

For instance, if a router learns about a network via EIGRP and OSPF, only the EIGRP route is put in the routing table because it has a lower administrative distance. Suppose RIP is also running on this router, and you want to redistribute OSPF routes into RIP. That network is not redistributed into RIP because it is in the routing table as an EIGRP route, not as an OSPF route.

Factors that have the most impact on redistribution include:

• Metrics
• Administrative distance
• Classful/classless capabilities of the protocols

These factors will be discussed in various sections of this module.
• Redistributing Route Information

5.1.4 Using Seed Metrics

Each routing protocol defines a metric for each route. The metric value determines the shortest or “best” path to an IP network. When a router redistributes routes from one routing domain to another, this information cannot be translated from one routing protocol to another. For example, a RIP hop cannot be dynamically recalculated to an OSPF cost by the router doing redistribution. Therefore, a seed metric artificially sets the distance, cost, and so on, to each external (redistributed) network from the redistribution point.

Seed Metrics Example

For example, if a boundary router receives a RIP route, the route has a hop count as a metric. To redistribute the route into OSPF, the router must translate the hop count into a cost metric that the OSPF router understands. This seed metric, also referred to as the default metric, is defined during redistribution configuration. When the seed metric for a redistributed route is established, the metric increasesin increments normally within the autonomous system.

Note
The exception to this rule is OSPF E2 routes, which hold their initial metric regardless of how far they are propagated across an autonomous system.

The default-metric command, used in routing process configuration mode, establishes the seed metric for all redistributed routes.

Cisco routers also allow the seed metric to be specified as part of the redistribution command, either with the metric option or by using a route map.

Whichever way it is done, the initial seed metric should be set to a value larger than the largest metric within the receiving autonomous system to help prevent suboptimal routing and routing loops.

Figure lists protocol names with the default seed metrics for the various protocols.


5.1.5 Seed Metrics Example

Figure illustrates a seed metric of 30 implemented by OSPF on the redistributed RIP routes.

The link cost of the Ethernet link to router D is 100. Therefore, the cost for networks 1.0.0.0, 2.0.0.0, and 3.0.0.0 on router D is the seed metric (30) plus the link cost (100) = 130. Notice that the metrics of the three networks in the RIP cloud are irrelevant in the OSPF cloud, because the objective is to have each OSPF router forward traffic for the three networks to the border (redistributing) router.

A metric of infinity tells the router that the route is unreachable, and therefore, it should not be advertised. When redistributing routes into RIP and EIGRP, you must specify a default metric.

For OSPF, the redistributed routes have a default type 2 metric of 20, except for redistributed BGP routes, which have a default type 2 metric of 1. For IS-IS, the redistributed routes have a default metric of 0. But unlike RIP or EIGRP, IS-IS does not treat a seed metric of 0 as unreachable. Configuring a seed metric for redistribution into IS-IS is recommended. For BGP, the redistributed routes maintain the IGP routing metrics.


5.1.6 Defining Administrative Distance

Most routing protocols have metric structures and algorithms that are not compatible with other protocols. It is critical for a network using multiple routing protocols to have seamless exchange of route information and the ability to select the best path across multiple protocols.

Cisco routers use a value called administrative distance to select the best path when they learn two or more routes to the same destination from different routing protocols. Administrative distance rates the believability of a routing protocol. Cisco has assigned a default administrative distance value to each routing protocol supported on its routers.

Each routing protocol is prioritized in the order of most believable to least believable. Some examples of prioritization are as follows:

• Prefer manually configured routes (static routes) to dynamically learned routes
• Prefer protocols with sophisticated metrics to protocols with more deterministic metrics
• Prefer External Border Gateway Protocol (EBGP) to most other dynamic protocols

In Figure , the table lists the default administrative distance of the protocols that Cisco supports. The administrative distance is a value between 0 and 255. The lower the administrative distance value, the higher the believability of the protocol.


Note
IGRP is no longer supported as of Cisco IOS Software Release 12.3.
For example, in Figure , if router A receives a route to network 10.0.0.0 from RIP and receives a route to the same network from OSPF, the router compares the administrative distance of RIP (120) with the administrative distance of OSPF (110). The router determines that OSPF is more reliable and adds the OSPF version of the route to the routing table.


Prefix Lengths
Varying prefix lengths of routes from different routing protocols can also affect routing decisions.
The prefix length is the number of bits set in the subnet mask. Longer prefixes are always preferred over shorter ones when forwarding a packet, regardless of routing protocols.

For example, assume that a router has four routing processes running on it, and each process
has received these routes:

• EIGRP (internal): 192.168.32.0/26
• RIP: 192.168.32.0/24
• OSPF: 192.168.32.0/19

Which of these routes will be installed in the routing table? Since EIGRP internal routes have the best administrative distance, you might assume that the first one is installed. However, since each of these routes has a different prefix length (subnet mask), they are considered different destinations. Therefore, they are all installed in the routing table.

If a packet arrives on a router interface destined for 192.168.32.1, which route would the router choose? It depends on the prefix length, or the number of bits set in the subnet mask. Longer prefixes are always preferred over shorter ones when forwarding a packet. In this case, a packet destined to 192.168.32.1 is directed toward 10.1.1.1, because 192.168.32.1 falls within the 192.168.32.0/26 network (192.168.32.0 to 192.168.32.63). It also falls within the other two routes available, but the 192.168.32.0/26 has the longest prefix within the routing table (26 bits versus 24 or 19 bits).

Likewise, if a packet destined for 192.168.32.100 arrives on one of the router’s interfaces, it is forwarded to 10.1.1.2, because 192.168.32.100 does not fall within 192.168.32.0/26 (192.168.32.0 through 192.168.32.63), but it does fall within the 192.168.32.0/24 destination (192.168.32.0 through 192.168.32.255). Again, it also falls into the range covered by 192.168.32.0/19, but 192.168.32.0/24 has a longer prefix length.


Interactive Media Activity .
Drag and Drop: Administrative Distance

I also pasted this so that you know you should go to the conmputer and get that
interactive media actitivity done.


5.1.7 Modifying Administrative Distances

In some cases, a router selects a suboptimal path if it believes a routing protocol with a better administrative distance, even though it is actually a routing protocol with a worse route.

Assigning an undesired routing protocol a larger administrative distance ensures that routers select routes from the desired routing protocol. You can use the distance command to change the default administrative distance for all protocols, except EIGRP and BGP. Figure describes the command parameters.

For EIGRP, use the distance eigrp command. EIGRP assigns different administrative distance values to routes learned natively through EIGRP and to routes redistributed in from other sources.

By default, EIGRP natively learned routes have an administrative distance of 90, but external routes have an administrative distance of 170.

For BGP, use the distance bgp command. BGP assigns different administrative distance
values to routes learned through IBGP and routes learned through EBGP.

bgp4

6.4.4 Configuring a Peer Group
In BGP, neighboring routers are often configured with the same update policies. For example, the neighboring routers may have the same filtering applied. On Cisco routers, neighboring routers with the same update policies can be grouped into peer groups to simplify configuration and to make updating more efficient and improve performance.

Members of the peer group inherit all the configuration options of the peer group. You can configure the router to override these options for some members if these options affect inbound advertisements but not outbound updates.

Peer groups are more efficient because updates are generated only once per peer group rather than repetitiously for each neighboring router. The generated update is replicated for each neighbor that is part of the internal peer group. Peer groups save processing time in generating the updates for all IBGP neighbors. The peer group name is local to the router on which it is configured, and it is not passed to any other router. Peer groups make the router configuration easier to read and manage.

Use the neighbor peer-group-name peer-group command to create a peer group and define the name for linking similar neighboring routers together.

Use the neighbor ip-address peer-group peer-group-name command to link the address of a neighboring router to a specific peer group name. A neighboring router can be part of only one peer group. This command allows you to enter the peer group name instead of entering the IP address in other commands, for example, to link a policy to the group of neighboring routers. You must enter the neighbor peer-group-name peer-group command before the router will accept this command.

Note
Recent releases of Cisco IOS software contain a BGP Dynamic Update Peer-Groups Using Peer Templates feature to dynamically optimize update groups of neighbors for shared outbound policies. More information on this feature can be found on Cisco.com.

6.4.5 Configuring a Peer Group Example
In Figure , AS 65100 has four routers running IBGP. All these IBGP neighbors are peering with each other using the loopback 0 interface of each, and are using the IP address of their loopback 0 interface as the source IP address for all BGP packets. Each router is using one of its own IP addresses as the next-hop address for each network advertised through BGP. These are outbound policies.

In addition, router C has an outbound distribution list associated with each IBGP neighbor. This outbound filter performs the same function as the distribute-list command that you use for internal routing protocols. However, it is linked to a specific neighbor for use with BGP. The ISP behind router C may be announcing RFC 1918 private address space to router C. Router C does not want to pass these networks to other routers running BGP in AS 65100.

To accomplish this goal, access list 20 might look like the following:

access-list 20 deny 10.0.0.0 0.255.255.255
access-list 20 deny 172.16.0.0 0.31.255.255
access-list 20 deny 192.168.0.0 0.0.255.255
access-list 20 permit any

Notice the configuration of router C when it is not using a peer group. All IBGP neighbors have the outbound distribute list link to them individually. If router C receives a change from AS 65101, it must generate an individual update for each IBGP neighbor and run each update against distribute list 20. If router C has a large number of IBGP neighbors, the processing power needed to inform the IBGP neighbors of the changes in AS 65101 could be extensive. The figure also shows the configuration on router C when it is using a peer group called “internal.” The update-source, next-hop-self, and distribute-list 20 out commands are all linked to peer group internal, which in turn is linked to each of the IBGP neighbors.

If router C receives a change from AS 65101, it creates a single update and processes it through distribute list 20 once, which saves processing time. The update is replicated for each neighbor that is part of the internal peer group.

Thus, the use of peer groups can improve efficiency when processing updates for BGP neighbors that have a common outbound BGP policy.

Adding a new neighbor to router C using a peer group with the same policies of the other IBGP neighbors requires adding only a single neighbor statement to link the new neighbor to the peer group internal. Adding that same neighbor to router C without a peer group requires four neighbor statements.

Using a peer group also makes the configuration easier to read and change when necessary. If you need to add a new policy, such as a route map, to all IBGP neighbors on router C using a peer group, you only need to link the route map to peer group internal. For router C without a peer group, you need to add the new policy to each neighbor.

6.4.6 BGP Peering
The show ip bgp summary command is one way to verify the neighbor relationship. Figure presents the output from this command, which contains the following:

• BGP router ID: IP address that all other BGP speakers recognize as representing this router.
• BGP table version: Increases in increments when the BGP table changes.
• Main routing table version: Last version of the BGP database that was injected into the main routing table.
• Neighbor: IP address that is used in the neighbor statement with which this router has a relationship.
• Version (V): Version of BGP that this router is running with the listed neighbor.
• AS: Autonomous system number of the listed neighbor.
• Messages received (MsgRcvd): Number of BGP messages that have been received from this neighbor.
• Messages sent (MsgSent): Number of BGP messages sent to this neighbor.
• Table version (TblVer): BGP table version.
• In queue (InQ): Number of messages waiting to be processed from this neighbor.
• Out queue (OutQ): Number of messages queued and waiting to be sent to this neighbor. TCP flow control prevents this router from overwhelming a neighbor with a large update.
• Up/Down: Length of time that this neighbor has been in the current BGP state (established, active, or idle).
• State (established, active, idle, open sent, open confirm, or idle [admin]): BGP state. You can set a neighbor to administratively shut down (admin state) by using the neighbor shutdown router configuration command.
• Prefix received (PfxRcd): When the session is in the established state, this value
represents the number of BGP network entries received from the listed neighbor.

6.4.7 Configuring BGP Authentication
You can configure BGP neighbor authentication on a router so that the router authenticates the source of each routing update packet that it receives. This is accomplished by exchanging an authenticating key (sometimes referred to as a password) that is known to both the sending and the receiving router.

BGP supports MD5 neighbor authentication. MD5 sends a message digest (also called a hash) that is created using the key and a message. The message digest is then sent instead of the key to prevent the key from being read by an eavesdropper while it is being transmitted.
To enable MD5 authentication on a TCP connection between two BGP peers, use the
neighbor {ip-address | peer-group-name} password string router configuration
command. Figure displays the parameters.

You can configure MD5 authentication between two BGP peers, meaning that each segment sent on the TCP connection between the peers is verified. MD5 authentication must be configured with the same password on both BGP peers; otherwise, the connection between them is not made. Configuring MD5 authentication causes Cisco IOS software to generate and check the MD5 digest of every segment sent on the TCP connection.

Caution
If the authentication string is configured incorrectly, the BGP peering session is not established. It is recommended that you enter the authentication string carefully and verify that the peering session is established after authentication is configured.

If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group inherit the characteristic configured with this command.
If a router has a password configured for a neighbor but the neighbor router does not, a message such as the following appears on the console when the routers attempt to send BGP messages between themselves:

%TCP-6-BADAUTH: No MD5 digest from 10.1.0.2(179) to 10.1.0.1(20236) Similarly, if the two routers have different passwords configured, a message such as the following appears on the screen:

%TCP-6-BADAUTH: Invalid MD5 digest from 10.1.0.1(12293) to 10.1.0.2(179)

If you configure or change the password or key used for MD5 authentication between two BGP peers, the local router does not tear down the existing session after you configure the password. The local router attempts to maintain the peering session using the new password until the BGP hold-down timer expires. The default time period is 180 seconds. If the password is not entered or changed on the remote router before the timer expires, the session times out.

Note

If you change the hold down value, it takes effect only after the session has been reset. You cannot change the hold-down timer to avoid resetting the BGP session.

The example in Figure configures MD5 authentication for the BGP peering session between routers A and B. The same password must be configured on the remote peer before the hold down timer expires.

6.4.8 Troubleshooting BGP
Use the show ip bgp command to display the BGP topology database (BGP table).
Figure displays a partial sample output of the show ip bgp command. The status codes are shown at the beginning of each line of output, and the origin codes are shown at the end of each line.

In this output, there is an asterisk (*) in most of the entries in the first column. This means that the next-hop address (in the fifth column) is valid. The next-hop address is not always the router that is directly connected to this router. Other options for the first column are as follows:

• s: Specified routes are suppressed (usually because routes have been summarized and only the summary route is being sent).
• d: Route is being dampened (penalized) for going up and down too often. Although the route might be up right now, it is not advertised until the penalty has expired.
• h: Route is unavailable and is probably down. Historic information about the route exists, but a best route does not exist.
• r: Route was not installed in the routing information base (RIB). The reason that the route is not installed can be displayed using the show ip bgp rib-failure command.
• S: Route is stale (this symbol is used in the nonstop forwarding-aware router).

The second column shows “>” when BGP has selected the path as the best path to a network. The third column is either blank or shows “i.” If it is blank, BGP learned that route from an external peer. An “i” indicates that an IBGP neighbor advertised this path to the router. The fourth column lists the networks that the router learned.

The Next Hop column lists all the next-hop addresses for each route. This column may contain the entry 0.0.0.0, which signifies that this router is the originator of the route.
The three columns to the left of the Path column list three BGP path attributes that are associated with the path: metric (multi-exit discriminator [MED]), local preference, and weight.

The column with the Path header may contain a sequence of autonomous systems in the path.
From left to right, the first autonomous system listed is the adjacent autonomous system that this network was learned from. The last number (the rightmost autonomous system number) is the originating autonomous system of this network. The autonomous system numbers between these two represent the exact path that a packet takes back to the originating autonomous system. If the path column is blank, the route is from the current autonomous system.

The last column signifies how this route was entered into BGP on the original router. If the last column contains an “i”, the originating router probably used a network statement to introduce this network into BGP.

If the character is an “e,” the originating router learned this network from EGP, which is the historical predecessor to BGP. A question mark (?) signifies that BGP cannot absolutely verify the availability of this network because it is redistributed from an IGP into BGP.

Use the show ip bgp rib-failure command to display BGP routes that were not installed in the RIB and the reason that they were not installed.

The example in Figure shows that the displayed routes were not installed because a route or routes with a better administrative distance already exist in the RIB.

6.4.9 Clearing the BGP Session
BGP can potentially handle huge volumes of routing information. When a policy configuration change occurs, the router cannot go through the huge table of BGP information and recalculate which entry is no longer valid in the local table. Nor can the router determine which routes should be withdrawn from a neighbor.

There is an obvious risk that the first configuration change will be immediately followed by a second, which would cause the whole process to start all over again. To avoid such a problem, Cisco IOS software applies changes only to those updates that are received or transmitted after the BGP policy configuration change has been performed. The new policy, enforced by the new filters, is applied only on routes that are received or sent after the change.

A network administrator who would like the policy change to be applied to all routes, must trigger an update to force the router to let all routes pass through the new filter. If the filter is applied on outgoing information, the router has to resend the BGP table through the new filter. If the filter is applied on incoming information, the router needs its neighbor to resend its BGP table so that it passes through the new filters.

There are three ways to trigger an update: with a hard reset, soft reset, or route refresh.

6.4.10 Hard Reset of BGP Sessions
Resetting a session is a method of informing neighbors of a policy change. If BGP sessions are reset, all information received on those sessions is invalidated and removed from the BGP table. Also, the remote neighbor detects a BGP session down state and invalidates the routes that were received. After 30 to 60 seconds, the BGP sessions are reestablished automatically, and the BGP table is exchanged again but through the new filters. However, resetting the BGP session disrupts packet forwarding.

The two commands shown in Figure both cause a hard reset of the BGP neighbors that are involved. A hard reset means that the router issuing either of these commands closes the appropriate TCP connections, reestablishes those TCP sessions as appropriate, and resends all information to each of the neighbors affected by the particular command that is used.

The clear ip bgp * command causes the BGP forwarding table on the router that issued this command to be completely deleted, and all networks must be relearned from every neighbor. If a router has multiple neighbors, this action is a very dramatic event. This command forces all neighbors to resend their entire tables simultaneously. You should use this command with extreme caution, and it is not normally used in a production environment.

For example, consider a situation in which router A has eight neighbors, and each neighbor has
a full Internet table of about 32 MB in size. If router A issues the clear ip bgp * command, all eight routers resend their 32 MB tables at the same time. To hold all these updates, router A would need 256 MB of RAM, and would also need to be able to process all of this information.

Processing 256 MB of updates would take a considerable number of CPU cycles, further delaying the routing of user data.

If the clear ip bgp [neighbor-address] command is used instead, one neighbor is reset at a time. The impact is less severe on the router that is issuing this command. However, it takes longer to change policy for all the neighbors, because each must be done individually rather than all at once as with the clear ip bgp * command. The clear ip bgp [neighbor-address] command still performs a hard reset and must reestablish the TCP session with the specified address, but it affects only a single neighbor at a time.

6.4.11 Soft Reset of BGP Sessions
The clear ip bgp soft out command causes BGP to do a soft reset for outbound updates. The router issuing the command does not reset the BGP session. Instead, the router creates a new update and sends the entire table to the specified neighbors.

This update includes withdrawal commands for the networks that the other neighbor will no longer see based on the new outbound policy.

Note
The soft keyword is optional; clear ip bgp out does a soft reset for outbound updates.
There are two ways to perform an inbound soft reconfiguration:

• Using stored routing update information
• Dynamically

Enter the neighbor command to inform BGP to save all updates that were learned from the neighbor specified. The BGP router retains an unfiltered table of what that neighbor has sent.
When the inbound policy is changed, use the clear ip bgp command. The stored unfiltered table generates new inbound updates, and the results are placed in the BGP forwarding database. Thus, if you make changes, you do not have to force the other side to resend everything.

Cisco IOS Software Release 12.0(2)S and 12.0(6)T introduced a BGP soft reset enhancement feature, also known as route refresh, that provides automatic support for dynamic soft reset of inbound BGP routing table updates, and is not dependent upon stored routing table update information. The clear ip bgp soft in command implements this feature. This method requires no preconfiguration and needs significantly less memory than the previous soft method for inbound routing table updates.

Note
The clear ip bgp soft command performs a soft reconfiguration of both inbound and outbound updates.

The soft in option generates new inbound updates without resetting the BGP session, but it can be memory-intensive. BGP does not allow a router to force another BGP speaker to resend its entire table. If you change the inbound BGP policy and you do not want to complete a hard reset, configure the router to perform a soft reconfiguration.

Note
To determine whether a BGP router supports this route refresh capability, use the show ip bgp neighbors command. The following message is displayed in the output if the router supports the route refresh capability:

Received route refresh capability from peer.
If all BGP routers support route refresh, use the clear ip bgp {* | address | peergroup- name} in command. You do not have to use the soft keyword, because soft reset is automatically assumed.

6.4.12 The debug ip bgp Command
Figure shows partial output from the debug ip bgp updates command on router A after the clear ip bgp command was issued to clear BGP sessions with its IBGP neighbor 10.1.0.2.

After the neighbor adjacency is reestablished, router A creates and sends updates to 10.1.0.2.
he first update highlighted in the figure, “10.1.1.0/24, next 10.1.0.1,” is an update about network 10.1.1.0/24, with a next hop of 10.1.0.1, which is the address of router A.

The second update highlighted in the figure, “10.97.97.0/24, next 172.31.11.4,” is an update about network 10.97.97.0/24, with a next hop of 172.31.11.4, which is the address of one of router A’s EBGP neighbors. The EBGP next-hop address is being carried into IBGP.

Router A later receives updates from 10.1.0.2. The update highlighted in the figure contains a path to two networks: 10.1.2.0/24 and 10.1.0.0/24. The attributes shown in this update are described in the next lesson.

Note
Debugging uses up router resources and should be turned on only when necessary

6.5 Selecting a BGP Path
6.5.1 Characteristics of BGP Attributes
BGP routers send BGP update messages about destination networks to other BGP routers. The update messages contain one or more routes and a set of BGP metrics, which are called path attributes, attached to the routes.

An attribute is either well-known or optional, mandatory or discretionary, and transitive or nontransitive. An attribute may also be partial.

Not all combinations of these characteristics are valid. Path attributes fall into the following four categories:

• Well-known mandatory
• Well-known discretionary
• Optional transitive
• Optional nontransitive

Only optional transitive attributes can be marked as partial.
All BGP routers must recognize a well-known attribute and propagate it to the other BGP neighbors.

Well-known attributes are either mandatory or discretionary. A well-known mandatory attribute must be present in all BGP updates. A well-known discretionary attribute does not have to be present in all BGP updates.

Attributes that are not well-known are called optional. BGP routers do not have to support an optional attribute. Optional attributes are either transitive or nontransitive.

The following statements apply to optional attributes:

• BGP routers that implement the optional attribute may propagate it to the other BGP neighbors, based on its meaning.
• BGP routers that do not implement an optional transitive attribute should pass it to other BGP routers untouched and mark the attribute as partial.
• BGP routers that do not implement an optional nontransitive attribute must delete the attribute and must not pass it to other BGP routers.

6.5.2 BGP Attributes
The following is a list of the common BGP attributes according to categories that they belong to:

• Well-known mandatory attributes
o Autonomous system path
o Next hop
o Origin

• Well-known discretionary attributes
o Local preference
o Atomic aggregate

• Optional transitive attribute
o Aggregator

• Optional nontransitive attribute
o Multi-exit discriminator (MED)

Note
In addition, Cisco defines a weight attribute for BGP. The weight is configured locally on a router and is not propagated to any other BGP routers.

Note
The attributes in this list are detailed in the following topics, except for the atomic aggregate and aggregator attributes. These two attributes relate to BGP summarization (or aggregation), and you can find more information on them on Cisco.com

Interactive Media Activity
Point and Click: Classify the Attributes

6.5.3 AS Path Attribute
The AS path is a well-known mandatory attribute. Whenever a route update passes through an autonomous system, the autonomous system number is prepended (added) to that update when it is advertised to the next EBGP neighbor.

The AS path attribute is actually the list of autonomous system numbers that a route has traversed to reach a destination, with the number of the autonomous system that originated the route at the end of the list.

In Figure , router A in AS 64520 advertises network 192.168.1.0. When that route traverses AS 65500, router C prepends its own autonomous system number to it. When 192.168.1.0
reaches router B, it has two autonomous system numbers attached to it. From router B’s
perspective, the path to reach 192.168.1.0 is (65500, 64520).

A similar process applies for the paths to networks 192.168.2.0 and 192.168.3.0. The path from router A to 192.168.2.0 is (65500, 65000), which means traverse AS 65500 and then AS 65000. Router C must traverse path (65000) to reach 192.168.2.0, and path (64520) to reach
192.168.1.0.

6.5.4 Next-Hop Attribute
The BGP next-hop attribute is a well-known mandatory attribute that indicates the next-hop IP
address that is to be used to reach a destination.
BGP routes autonomous system by autonomous system, not router by router. The next-hop attribute defines the IP address of the border router that should be used as the next hop to the destination.

For EBGP, the next hop is the IP address of the neighbor that sent the update. In Figure , router A advertises 172.16.0.0 to router B, with a next hop of 10.10.10.3, and router B advertises 172.20.0.0 to router A, with a next hop of 10.10.10.1.

For IBGP, the protocol states that the next hop that is advertised by EBGP should be carried into IBGP. Because of that rule, router B advertises 172.16.0.0 to its IBGP peer router C with a next hop of 10.10.10.3 (router A’s address). Therefore, router C knows that the next hop to reach 172.16.0.0 is 10.10.10.3, not 172.20.10.1, as you might expect.

It is very important for router C to know how to reach the 10.10.10.0 subnet, either via an IGP or a static route. Otherwise, it will drop packets destined to 172.16.0.0, because it cannot get to the next-hop address for that network.

Alternatively, router B can change the next-hop attribute to itself if you use the neighbor next-hop-self command.

6.5.5 Origin Attribute
The origin attribute defines the origin of the path information. The origin attribute can be one of these three values:

• IGP: The route is interior to the originating autonomous system. This value normally results when the network command is used to advertise the route via BGP. An origin of IGP is indicated with an “i” in the BGP table.

• EGP: The route has been learned via EGP. This value is indicated with an “e” in the BGP table. EGP is considered a historical routing protocol and is not supported on the Internet because it performs only classful routing and does not support classless interdomain routing.

• Incomplete: The origin of the route is unknown or has been learned by some other means. This value usually results when a route is redistributed into BGP. An incomplete origin is indicated with a question mark (?) in the BGP table.

Figure shows example output of the show ip bgp command. The origin code, reflecting the origin attribute, is in the last column at the end of each line. In this example, all origin codes are “i,” indicating an origin attribute of IGP; the routes are interior to the originating autonomous system.

6.5.6 Local Preference Attribute
Local preference is a well-known discretionary attribute that provides an indication to routers in the autonomous system about which path is preferred to exit the autonomous system. A path with a higher local preference is preferred.

The local preference is an attribute that is configured on a router and exchanged among routers within the same autonomous system only. The default value for local preference on a Cisco router is 100.

In Figure , AS 64520 receives updates about network 172.16.0.0 from two directions. The local preference on router A for network 172.16.0.0 is set to 200, and the local preference on router B for network 172.16.0.0 is set to 150.

Because the local preference information is exchanged within AS 64520, all traffic in AS 64520 addressed to network 172.16.0.0 is sent to router A as an exit point from autonomous system 64520 (because of its higher local preference).

6.5.7 MED Attribute
The MED attribute, also called the metric, is an optional nontransitive attribute.
The MED is an indication to EBGP neighbors about the preferred path into an autonomous system. The MED attribute is a dynamic way to influence another autonomous system about which path that it should choose to reach a certain route in their autonomous system when multiple entry points exist. A lower metric is preferred.

Unlike local preference, the MED is exchanged between autonomous systems. The MED is sent to EBGP peers. Those routers propagate the MED within their autonomous system, and the routers within the autonomous system use the MED but do not pass it on to the next autonomous system. When the same update is passed on to another autonomous system, the metric is set back to the default of 0.

MED influences inbound traffic to an autonomous system, and local preference influences outbound traffic.
By default, a router compares the MED attribute only for paths from neighbors in the same autonomous system.

Note
The MED attribute means that BGP is the only protocol that can affect how routes are sent into an autonomous system.

In Figure , the router B MED attribute is set to 150, and the router C MED attribute is set to 200. When router A receives updates from routers B and C, it chooses router B as the best next hop because its MED of 150 is less than router C.