Troubleshooting BGP Route Not Installing in Routing Table
This section discusses issues related to BGP routes not getting installed in the IP routing table. If a router must forward an IP packet by looking at the IP destination address in IP packet, the router must have an IP routing table entry for the subnet of the IP destination address.
If the BGP process fails to create an IP routing table entry, all traffic destined for missing IP subnets in the routing table will be dropped. This is a generic behavior of hop-by-hop IP packet forwarding done by routers.
Problems in this section assume that the BGP table has all the updates for IP prefixes but that BGP is not installing them in IP routing table.
Following is the list of all problems discussed in this section:
- An IBGP-learned route is not getting installed in the IP routing table.
- An EBGP-learned route is not getting installed in the IP routing table.
Problem: IBGP-Learned Route Not Getting Installed in IP Routing Table
The most common causes of this problem are as follows:
- IBGP routes are not synchronized.
- The BGP next hop is not reachable.
The sections that follow discuss these causes and how to resolve the problem based on the cause.
IBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: IBGP Routes Are Not Synchronized
IBGP will not install or propagate a route to other BGP speakers unless IBGP-learned routes are synchronized. Synchronization means that for an IBGP-learned route, there must exist an identical route in the IP routing table provided by an IGP (OSPF, IS-IS, and so on).
This means that the IGP must hold all external BGP routing information. This can be accomplished by redistributing EBGP into an IGP at the border routers of an AS.
In Figure 15-18, R1 is originating 100.100.100.0/24 to its IBGP neighbor, R2 (13.108.10.2). R2 is configured to form IBGP neighbors with R1 and is originating nothing.
Figure 15-19 shows the flowchart to follow to resolve this problem.
Debugs and Verification
Example 15-40 is the relevant BGP configuration needed in R1 and R2 to originate and receive 100.100.100.0/24 through IBGP.
Example 15-40 Configuring R1 and R2 to Originate and Receive 100.100.100.0/24 Through IBGP
R1# router bgp 109 network 100.100.100.0 mask 255.255.255.0 neighbor 131.108.10.2 remote-as 109 neighbor 131.108.10.2 update-source Loopback0 ip route 100.100.100.0 255.255.255.0 Null0 _____________________________________________________________________________________ R2# router bgp 109 neighbor 131.108.10.1 remote-as 109 neighbor 131.108.10.1 update-source Loopback0
Example 15-41 shows that R2 has received an IBGP update for 100.100.100.0/24.
Example 15-41 R2’s BGP Routing Table Entry Indicates That an IBGP Update Was Received for 100.100.100.0/24
R2#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 3 Paths: (1 available, no best path) Flag: 0x208 Not advertised to any peer Local 131.108.10.1 from 131.108.10.1 (131.108.10.1) Origin IGP, metric 0, localpref 100, valid, internal, not synchronized R2#show ip route 100.100.100.0 % Network not in table
The output in Example 15-41 also explains that BGP finds no best-path candidate to be installed in IP routing table. The reason is that this particular BGP update is not synchronized.
Solution
A network operator can choose to work around this problem in two ways:
- Synchronize all BGP routes.
- Turn off synchronization.
Synchronizing All IBGP Routes
The solution of turning off synchronization needs no further explanation. Synchronizing all BGP routes, however, requires some more detailed coverage.
To synchronize 100.100.100.0/24, R1 must advertise this route in its IGP so that R2 can receive it through both IBGP and IGP. Example 15-42 shows that R1 is advertising this route by redistributing static routes in OSPF, and R2 receives it as an external OSPF route and in normal IBGP as well.
Example 15-42 Configuration Needed to Advertise All Routes Advertised Through IBGP and IGP (OSPF)
R1# router ospf 1 redistribute static subnets network 131.108.1.0 0.0.0.255 area 0 R1# router bgp 109 network 100.100.100.0 mask 255.255.255.0 neighbor 131.108.10.2 remote-as 109 neighbor 131.108.10.2 update-source Loopback0 ip route 100.100.100.0 255.255.255.0 Null0
The configuration in Example 15-42 shows that OSPF is redistributing static routes; the only static route shown is 100.100.100.0/24. BGP is also advertising the same prefix to R2, as demonstrated in Example 15-43.
Example 15-43 Output to Show R2 Is Receiving a Synchronized IBGP Route from R1
R2#show ip route 100.100.100.0 Routing entry for 100.100.100.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10 Redistributing via ospf 1 Last update from 131.108.1.1 on Ethernet0, 00:07:21 ago Routing Descriptor Blocks: * 131.108.1.1, from 131.108.10.1, 00:07:21 ago, via Ethernet0 Route metric is 20, traffic share count is 1 R2#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 4 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208 Not advertised to any peer Local 131.108.10.1 from 131.108.10.1 (131.108.10.1) Origin IGP, me tric 0, localpref 100, valid, internal, synchronized, best
In Example 15-43, BGP now marks this route as synchronized and will install this route in its IP routing table. It also will propagate this route to other BGP speakers. In Example 15-43, the routing table chooses the OSPF route instead of the IBGP route because of the lower administrative distance of 110 over 200.
NOTE
In the case of OSPF, Cisco IOS Software expects the OSPF router ID (RID) and the BGP RID for R1, the advertising router, to be identical for synchronization to work properly. There is no such restriction for any other IGPs.
Turning Off Synchronization
This method is widely used in almost all BGP networks.
Example 15-44 provides the necessary configuration to accomplish this.
Example 15-44 Turning Off Synchronization
R2# router bgp 109 no synchronization
As seen in the previous section, all routes in BGP must also be redistributed in IGP to have synchronization in the IBGP network.
With the size of BGP tables these days (more than 110,000 entries), it is not recommended that you redistribute all BGP routes into an IGP. Therefore, it becomes common practice to turn off synchronization instead.
IBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: IBGP Next Hop Not Reachable
The cause of this problem is most common in IBGP-learned routes where BGP next-hop address should have been learned through an Interior Gateway Protocol (IGP). Failure to reach the next hop is an IGP problem, and BGP is merely a victim. With BGP, when IP prefixes are advertised to an IBGP neighbor, the NEXT-HOP attribute of the prefix does not change. The IBGP receiver must have an IP route to reach this next hop.
Figure 15-20 shows the flowchart to follow to resolve this problem.
Figure 15-21 shows that NEXT-HOP of BGP routes advertised to IBGP neighbors are not changed and might result in route installation failure.
Debugs and Verification
Example 15-45 shows that R8 is advertising the 100.100.100.0/24 route to its EBGP peer R1, which will advertise this route to R2. However, on R2, the problem of the next hop appears.
Example 15-45 shows the relevant configuration of R8, R1, and R2.
Example 15-45 Configuration Needed in R1, R2, and R8 to Form Neighbor Relationship and Originate and Propagate 100.100.100.0/24
R8# router bgp 110 no synchronization network 100.100.100.0 mask 255.255.255.0 neighbor 206.56.89.2 remote-as 109 ip route 100.100.100.0 255.255.255.0 Null0 _____________________________________________________________________________________ R1# router bgp 109 no synchronization neighbor 131.108.10.2 remote-as 109 neighbor 131.108.10.2 update-source Loopback0 neighbor 206.56.89.1 remote-as 110 _____________________________________________________________________________________ R2# router bgp 109 no synchronization neighbor 131.108.10.1 remote-as 109 neighbor 131.108.10.1 update-source Loopback0
The configuration in Example 15-45 shows that R8 has one EBGP neighbor, R1, which has R8 and R2 as EBGP and IBGP neighbors, respectively. R2 has R1 as an IBGP neighbor.
R8 is advertising 100.100.100.0/24 to R1, and R1 will propagate that to R2 as an IBGP advertisement.
Example 15-46 shows that R1 receives this route, installs it in its routing table, and propagates it to R2 131.108.10.2.
Example 15-46 R1 Receives the Route and Propagates It to R2
R1#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 131.108.10.2 110 206.56.89.1 from 206.56.89.1 (100.100.100.8) Origin IGP, metric 0, localpref 100, valid, external, best R1#show ip route 100.100.100.0 Routing entry for 100.100.100.0/24 Known via "bgp 109", distance 20, metric 0 Tag 110, type external Last update from 206.56.89.1 00:04:50 ago Routing Descriptor Blocks: * 206.56.89.1, from 206.56.89.1, 00:04:50 ago Route metric is 0, traffic share count is 1 AS Hops 1
The highlighted output shows that R1 is advertising 100.100.100.0/24 to 131.108.10.2, which is R2.
In Figure 15-21, R2 is an IBGP peer of R1, which advertises 100.100.100.0 /24 to R2. Then R2 receives this BGP route with a Next-hop of 206.56.89.1 but fails to install 100.100.100.0/24 in its routing table, as demonstrated in Example 15-47.
Example 15-47 R2 Fails to Install the 100.100.100.0 /24 Route in Its Routing Table
R2#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 0 Paths: (1 available, no best path) Not advertised to any peer 110 206.56.89.1 (inaccessible) from 131.108.10.1 (131.108.10.1) Origin IGP, metric 0, localpref 100, valid, internal R2#show ip route 100.100.100.0 % Network not in table
Notice that 206.56.89.1 is inaccessible because R2 does not have a route to reach it in its IP routing table, as confirmed by Example 15-48.
Example 15-48 R2’s IP Routing Table Confirms an Inaccessible Route
R2#show ip route 206.56.89.1 % Network not in table
This might be because R1 is not advertising 206.56.89.1 to R2 through its IGP (OSPF) or R2 is not installing 206.56.89.1 for any other reason.
Solution
BGP requires the next hop of any BGP route to resolve to a physical interface. This might or might not require multiple recursive lookups in the IP routing table. Two common solutions exist for addressing this problem:
- Announce the EBGP next hop through an IGP using a static route or redistribution.
- Change the next hop to an internal peering address.
- Announce the EBGP Next Hop Through an IGP Using a Static Route or Redistribution
This solution simply requires that the subnet 206.56.89.0/30 be advertised by R1 in its IGP—OSPF, in this example.
Example 15-49 shows the necessary configuration in R1 to accomplish this and shows R2 receiving this route through an IGP.
Example 15-49 Configuring R1 to Advertise EBGP Next Hop Through OSPF
R1# router ospf 1 network 206.56.89.0 0.0.0.7 area 0
The output in Example 15-50 shows that R2 receives this route through OSPF.
Example 15-50 R2’s IP Route Table Confirms Receipt of the EBGP Next-Hop Route Advertisement Through OSPF
R2# show ip route 206.56.89.0 255.255.255.252 Routing entry for 206.56.89.0/30 Known via "ospf 1", distance 110, metric 74, type intra area Redistributing via ospf 1 Last update from 131.108.1.1 on Ethernet0, 00:03:17 ago Routing Descriptor Blocks: * 131.108.1.1, from 1.1.1.1, 00:03:17 ago, via Ethernet0 Route metric is 74, traffic share count is 1
Note that 131.108.1.1 resolves to interface Ethernet0.
Change the Next Hop to an Internal Peering Address
This solution suggests that R1 change the BGP next hop to its loopback address when advertising IBGP routes to R2.
Example 15-51 shows that the configuration in R1 requires the BGP next hop to be changed to its own loopback address.
Example 15-51 Configuring R1 So That the BGP Next Hop Is Its Own Loopback Address
R1# router bgp 109 neighbor 131.108.10.2 remote-as 109 neighbor 131.108.10.2 update-source Loopback0 neighbor 131.108.10.2 next-hop-self neighbor 206.56.89.1 remote-as 110
The command neighbor 131.108.10.2 next-hop-self changes the Next-hop to its own loop-back 0 (131.108.10.1). The neighbor-131.108.10.2 update-source loopback 0 command makes R1’s loopback 0 the source of all BGP packets sent to R2.
Example 15-52 shows this change reflected in R2.
Example 15-52 R2’s BGP Route Table Confirms That R1’s Loopback Address Is the Next Hop of All BGP Updates Sent to R2
R2#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 110 131.108.10.1 from 131.108.10.1 (131.108.10.1) Origin IGP, metric 0, localpref 100, valid, internal, best R2#show ip route 100.100.100.0 Routing entry for 100.100.100.0/24 Known via "bgp 109", distance 200, metric 0 Tag 110, type internal Last update from 131.108.10.1 00:00:25 ago Routing Descriptor Blocks: * 131.108.10.1, from 131.108.10.1, 00:00:25 ago Route metric is 0, traffic share count is 1 AS Hops 1
The exterior Next-Hop changed to the loopback of R1, 131.108.10.1.
This solution is more widely used and is the preferred method of announcing the next hop to IBGP peer. In the simple example of Figure 15-21, the solution of changing the next hop to an internal peering address allows one less IP subnet to go in the IP routing table. In addition, it helps in troubleshooting because network operators recall their internal loopback addresses quicker than external IP subnets, such as that used in the EBGP connection.
Problem: EBGP-Learned Route Not Getting Installed in IP Routing Table
Just as with IBGP, EBGP routes might not get installed in the IP routing table, resulting in a lack of IP traffic reachability to those routes. Multiple causes of this problem might exist, depending on which EBGP scenario is being looked at.
The most common causes of EBGP routes not getting installed are as follows:
- BGP routes are dampened.
- The BGP next hop is not reachable in case of multihop EBGP.
- The multiexit discriminator (MED) value is infinite.
The sections that follow discuss these causes and how to resolve the problem based on the cause.
EBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: BGP Routes Are Dampened
Dampening is the way to minimize instability in a local BGP network caused by unstable BGP routes from EBGP neighbors. RFC 2439, “BGP Route Flap Damping,” describes in detail how dampening works. In short, dampening is the way to assign a penalty for a flapping BGP route. A withdrawal of a prefix is considered a flap. A penalty of 1000 is assigned for each flap; if the flap penalty reaches the suppress limit because of continued flaps (default 2000), the BGP path is suppressed and is taken out of the routing table. This penalty is decayed exponentially based on the half-life time (default 15 minutes). When the penalty reaches the reuse value (default 750), the path is unsuppressed and is installed in the routing table and advertised to other BGP neighbors. Any dampened path can be suppressed only until the max suppress time (default 60 minutes). Dampening is applied only to EBGP neighbors, not to IBGP neighbors.
BGP dampening is off by default; the following BGP command turns on dampening:
router bgp 109 bgp dampening
Cisco IOS Softare allows dampening parameters to be changed and are defined as follows:
router bgp 1009 bgp dampening half-life-time reuse suppress maximum-suppress-time
Here, the value range for the options is as follows:
- half-life-time— Range is 1 to 45 minutes. Current default is 15 minutes.
- reuse— Range is 1 to 20,000. Default is 750.
- suppress— Range is 1 to 20,000. Default is 2000.
- max-suppress-time— Maximum duration that a route can be suppressed. Range is 1 to 255. Default is four times half-life-time.
Figure 15-22 shows the flowchart to follow to resolve this problem.
Debugs and Verification
Figure 15-23 shows a simple EBGP setup between R1 and R2 in AS 109 and AS 110, respectively. R2 has advertised 100.100.100.0/24 to R1. To show how dampening works, R2 is made to flap 100.100.100.0/24 multiple times. Removing the route in R2’s routing table and putting it back can simulate flapping. R1 receives these flaps and, if configured with dampening, assigns penalties per flap.
shows the necessary debugs run to observe the dampening feature in R1 running Cisco IOS Software.
Example 15-53 Observing the BGP Dampening Feature
R1#debug ip bgp dampening 1 R1#debug ip bgp updates 1 access-list 1 permit 100.100.100.0 0.0.0.0
Most of the BGP debugs can be run along with an access list to limit the output created by these debugs. Access list 1 is permitting only 100.100.100.0.
Example 15-54 shows the debug output and flap statistics in BGP output.
Example 15-54 Debugs to Verify Dampening of 100.100.100.0/24
Dec 13 03:33:57.966 MST: BGP(0): 131.108.1.2 rcv UPDATE about 100.100.100.0/24 -- withdrawn Dec 13 03:33:57.966 MST: BGP(0): charge penalty for 100.100.100.0/24 path 110 with halflife-time 15 reuse/suppress 750/2000 Dec 13 03:33:57.966 MST: BGP(0): flapped 4 times since 00:02:58. New penalty is 3838 R1#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 17 Paths: (1 available, no best path) Flag: 0x208 Not advertised to any peer 110, (suppressed due to dampening) 131.108.1.2 from 131.108.1.2 (10.0.0.3) Origin IGP, metric 0, localpref 100, valid, external Dampinfo: penalty 3793, flapped 4 times in 00:03:13, reuse in 00:35:00
Highlighted debug and show command output shows that 100.100.100.0/24 has flapped four times in 3 minutes and 13 seconds. For each flap, a penalty of 1000 is assigned; because the suppress limit of 2000 has been exceeded, 100.100.100.0/24 is suppressed and removed from the routing table.
Solution
If R1 wants to reinstall 100.100.100.0/24, it can do the following:
- Wait for the penalty to go below the reuse limit (750).
- Remove dampening altogether from the BGP configuration.
- Clear the flap statistics.
Example 15-55 shows how the dampened path can be cleared and immediately get installed in the routing table. debug ip bgp update 1 is on to display the activity in the BGP process.
Example 15-55 Clearing BGP Dampening Through a Command Line with Debugs On
R1#clear ip bgp dampening 100.100.100.0 Dec 13 03:36:56.205 MST: BGP(0): Revise route installing 100.100.100.0/24 -> 131.108.1.2 to main IP table
The output in Example 15-55 came from debug ip bgp update 1 running to display activity of 100.100.100.0/24 going into the IP routing table. Example 15-56 shows the final BGP routing table entries.
Example 15-56 BGP Routing Table Entries
R1#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 18 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208 Not advertised to any peer 110 131.108.1.2 from 131.108.1.2 (10.0.0.3) Origin IGP, metric 0, localpref 100, valid, external, best R1#show ip route 100.100.100.0 Routing entry for 100.100.100.0/24 Known via "bgp 109", distance 20, metric 0 Tag 110, type external Last update from 131.108.1.2 00:02:45 ago Routing Descriptor Blocks: * 131.108.1.2, from 131.108.1.2, 00:02:45 ago Route metric is 0, traffic share count is 1 AS Hops 1, BGP network version 0
EBGP-Learned Route Not Getting Installed in IP Routing Table—Cause: BGP Next Hop Not Reachable in Case of Multihop EBGP
In a multihop EBGP session, EBGP speakers are not directly connected. Peering between loopback addresses of adjacent routers also is considered multihop.
This problem of an EBGP multihop route not getting installed in an IP routing table is identical to the IBGP next hop issue; however, most of the commonly seen problems occur when the router fails to resolve the next-hop address to an interface.
In this problem, the multihop EBGP next hop is reachable through a BGP route whose next hop is again the original multihop BGP next hop. For example, to reach prefix A, the next hop is prefix B; to reach prefix B, the next hop is again B. This is considered a recursion problem in which a router cannot resolve to an interface to reach the next hop B.
Figure 15-24 shows how R2 will not install routes from R1 whose next hop cannot be resolved to an interface.
Figure 15-25 shows the flowchart to follow to resolve this problem.
Debugs and Verification
R1 and R2 are peering to each other’s Loopback addresses. R1 is advertising 100.100.100.0/24 to its multihop EBGP neighbor R2 with a next hop of 131.108.10.1.
R2 has a default route that it uses to form a BGP neighbor relationship with R1, but failure to resolve the next hop to an interface results in routes not getting installed in the routing table.
Example 15-49 shows that R2 is receiving 100.100.100.0/24 from R1 with the next hop of 131.108.10.1. However, this next hop is advertised by R1 to R2 only through BGP. Notice in the output of Example 15-57 that the next hop for BGP update of 131.108.10.1/32 is 131.108.10.1. R2 can never resolve the reachability for 131.108.10.1 through any physical interface. In Cisco IOS Software, BGP can detect this behavior and marks 100.100.100.0/24 as an unacceptable route to go in Best Path calculation and thus never go in the IP routing table.
Example 15-57 EBGP Multihop Will Not Be Capable of Resolving the Next Hop
R2#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208 Not advertised to any peer 109 131.108.10.1 from 131.108.10.1 (131.108.10.1) Origin IGP, metric 0, localpref 100, valid, external, best R2#show ip bgp 131.108.10.1 BGP routing table entry for 131.108.10.1/32, version 5 Paths: (1 available, no best path) Flag: 0x208 Not advertised to any peer 109 131.108.10.1 (inaccessible) from 131.108.10.1 (131.108.10.1) Origin IGP, metric 0, localpref 100, valid, external R2#show ip route 131.108.10.1 Routing entry for 131.108.10.1/32 Known via "bgp 110", distance 20, metric 0 Tag 109, type external Last update from 131.108.10.1 00:00:38 ago Routing Descriptor Blocks: * 131.108.10.1, from 131.108. 10.1,00:00:38 ago Route metric is 0, traffic share count is 1 AS Hops 1 R2#show ip route 131.108.10.1 Routing entry for 131.108.10.1/32 Known via "bgp 110", distance 20, metric 0 Tag 109, type external Last update from 131.108.10.1 00:00:38 ago Routing Descriptor Blocks: * 131.108.10.1, from 131.108. 10.1,00:00:04 ago Route metric is 0, traffic share count is 1 AS Hops 1
Note the time stamp in IP route output; it is resetting every minute.
This route in Example 15-57 will keep coming and going every minute as the Cisco IOS Software BGP scanner process detects such inconsistencies in the BGP next hop and removes that route.
Solution
The solution to this problem based on this cause is to simply have a more specific route for the next-hop address. In the case of EBGP, this is commonly done by having a static route for the multihop EBGP peering address.
This instance is observed in the case of multihop EBGP sessions when the next-hop address is not directly connected and the IP routing table must have an explicit route to the next-hop address.
The simple solution lies in creating a static route from R2 to reach the R1 loopback, which is the next hop of all prefixes advertised by R1 to R2. This can be done with the following command on R2:
ip route 131.108.10.1 255.255.255.255 131.108.1.1
The static route 131.108.10.1 is the loopback address of R1, and 131.108.1.1 is the physical interface address of R1.
EBGP-Learned Route Not Getting Installed in the Routing Table—Cause: Multiexit Discriminator (MED) Value Is Infinite
In Cisco IOS Software, if a multiexit discriminator (MED) is set to infinite 4294967295, the router will not install this route in the routing table.
Figure 15-26 shows the flowchart to follow to resolve this problem.
Debugs and Verification
In Cisco IOS Software, an infinite MED in a BGP update makes it incapable of entering the routing table. This rare occurrence is typically the result of misconfiguration.
Example 15-58 shows the output of the BGP table for prefix 100.100.100.0/24. Notice the metric value of 4.29 billion, which Cisco IOS Software considers as infinite. Example 15-58 also shows how R2 can be configured to set the MED value equal to 4.29 billion. The infinite metric sometimes is used in route servers, which provide a mirror view of the Internet BGP table. Setting the metric to infinity prohibits such routes from going in the IP routing table, so no IP traffic will use those routes. This case is discussed here just to show a corner case of a BGP path not getting installed in the routing table. Such a configuration is not seen in real BGP networks.
Example 15-58 BGP Route Table for Prefix 100.100.100.0/24 Indicates a Metric Set to Infinity
R2#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 0 Paths: (1 available, no best path) Not advertised to any peer 1 172.16.126.1 from 172.16.126.1 (172.16.1.1) Origin IGP, metric 4294967295, localpref 100, valid, external R2#show ip route 100.100.100.0 % Network not in table R2# router bgp 2 no synchronization neighbor 172.16.126.1 remote-as 1 neighbor 172.16.126.1 route-map SET_MED in R2#show route-map SET_MED route-map SET_MED, permit, sequence 10 Match clauses: Set clauses: metric 4294967295 Policy routing matches: 0 packets, 0 bytes