Troubleshooting Suboptimal Routing Caused by Redistribution

When redistributing routes from one routing source into another routing source, the original routing source’s information is lost when the seed metric is injected at the redistribution point. Therefore, overall network visibility is lost or hidden from the destination routing source. This is not an issue when there is only one point of redistribution between two sources. However, if there are multiple points of redistribution between two sources, as shown in Figure 17-1, the suboptimal path may be chosen to reach networks.

In Figure 17-1, focus on R1 and R2. The optimal path to reach 192.168.2.0/24 is from R2 because the 1 Gbps link is much faster than the 10 Mbps link. When you perform redistribution on R1 and R2 into EIGRP, EIGRP does not know that the 10 Mbps link or the 1 Gbps link exists in the OSPF domain. Therefore, if an inappropriate seed metric is used during redistribution on R1 and R2, the traffic from 10.1.1.0/24 destined for 192.168.2.0/24 may take the suboptimal path through R1. However, realize that, according to the EIGRP AS, it is the best path because all it sees is the seed metric and the 1 Gbps and 100 Mbps link in the EIGRP autonomous system. Therefore, if the seed metrics you define are the same on R1 and R2 when you redistribute into EIGRP, the 1 Gbps link in the EIGRP autonomous system is preferred, and traffic goes to R1. Then R1 sends it across the 10 Mbps link to 192.168.2.0/24, which is suboptimal. It works, but it is suboptimal.

You can recognize this issue from a topological diagram and also by using the traceroute command. In Figure 17-1, if the result of the traceroute from 10.1.1.0/24 to 192.168.2.0/24 goes through R1, you know that suboptimal routing is occurring because of redistribution.

You can solve this issue by providing different seed metrics on the boundary routers (R1 and R2 in this case) to ensure that a certain path is preferred because it has a lower overall metric. So, R2’s EIGRP seed metric must be significantly better than R1’s EIGRP seed metric to ensure that R3 chooses the path through R2, even though it is a slower link between R3 and R2 than between R3 and R1. The key is to make sure the traffic avoids the 10 Mbps link.

Going in reverse, when redistributing from EIGRP into OSPF, the redistributed routes have a default seed metric of 20 and are classified as E2 routes; therefore, the metric remains as 20 throughout the OSPF domain. At first, you might think that load balancing will occur from R4 to R1 and R2 when sending traffic from 192.168.2.0/24 to 10.1.1.0/24. You would be correct only if the forwarding metric to reach the ASBRs are equal in addition to the E2 seed metric being equal as well. In this case, the forward metrics are not equal. The 10 Mbps link has a much higher cost than the 1 Gbps link. Therefore, all the traffic from 192.168.2.0/24 to 10.1.1.0/24 goes through R2 across the 1 Gbps link—a lower metric to reach the autonomous system boundary router (ASBR) in the OSPF domain. However, if the seed metric is set higher than 20 on R2 and is left at 20 on R1, R1 is used as the path because it now has the lower seed metric, but in this case it is the suboptimal path. Therefore, if the metric type is E2, you can simply make the preferred ASBR advertise the lowest seed metric to ensure that optimal routing is achieved. If you are using metric type E1, the cost of the links within the network is added to the cost of the seed metric to come up with the overall cost to reach the destination network. Therefore, if suboptimal routing is occurring, you need to determine which seed metrics are most appropriate with E2 to ensure that the optimal path is chosen, or you can use metric type E1 so that internal costs are used with the seed metric to determine the overall cost.

When troubleshooting suboptimal routing caused by redistribution, keep in mind the following:

• Based on the topology, you need to be able to recognize that mutual redistribution is occurring at multiple points in the network.

• Based on the connections, you need to be able to recognize the different speeds of the links.

• Based on the routing protocols in use, you need to be able to identify how the seed metric is determined and how it behaves for the different protocols.

• Based on the business requirements, you need to know how to fix the suboptimal routing by manipulating the metrics on the boundary routers with the default-metric command, the metric parameter in the redistribute command, or within a route map.

Troubleshooting Routing Loops Caused by Redistribution

Examine Figure 17-2. The 10.1.1.0/24 network is redistributed into the EIGRP autonomous system, and then it is redistributed into the OSPF domain on R1 and R2. This does not appear to be an issue; however, it is an issue because of administrative distance (AD). Let’s explore what happens.

When the 10.1.1.0/24 network is redistributed from RIPv2 into EIGRP autonomous system 100, it is classified as an external route in the EIGRP autonomous system. R1 and R2 place the route in the routing table with the code D EX and an AD of 170, as shown in Figure 17-3.

When R1 and R2 redistribute the 10.1.1.0/24 network in the OSPF domain, by default, the Type 5 link-state advertisement (LSA) is advertising 10.1.1.0/24 as an O E2 route, with an AD of 110, as shown in Figure 17-4. Don’t forget that it’s flooded through the area. Therefore, R1 will receive R2’s LSA, and R2 will receive R1’s LSA, which creates the problem. Look closely at R1’s two options for 10.1.1.0/24. Which one will be preferred? It is the OSPF route because it has a lower AD. Therefore, R1 points to R2 through the OSPF domain to reach 10.1.1.0/24. Look closely at R2’s two options for 10.1.1.0/24. Which one is preferred? It is the OSPF route because it has a lower AD. Therefore, R2 points to R1 through the OSPF domain to reach 10.1.1.0/24.

Now when traffic is sent from 192.168.2.0/24 to 10.1.1.0/24, it bounces back and forth between R1 and R2, and this is classified as a routing loop.

However, this scenario gets worse because of how redistribution works. Remember that to redistribute a route from one routing source to another (EIGRP into OSPF, for example), that route must be in the routing table as an entry for the routing source that you are redistributing the route from.

With all this in mind, consider Figure 17-4 again. When R1 and R2 originally learned about the network 10.1.1.0/24 from R3, it was an EIGRP external route. There was no other source of information in the routing table at the time for 10.1.1.0/24; therefore, it was considered the best source and installed in the routing table as an EIGRP route. Because redistribution is occurring from EIGRP into OSPF, the 10.1.1.0/24 network is redistributed from the routing table into the OSPF process and advertised. Now, when R1 and R2 learn about the OSPF 10.1.1.0/24 route from each other, they notice that it is a better source of information because the AD is lower (110) than the one for EIGRP (170) that is currently in the routing table. Therefore, the OSPF route replaces the EIGRP route. What happens now? Well, because the EIGRP route is still in the topology table but not in the routing table, it is no longer available for redistribution into OSPF, and therefore, there are no more Type 5 LSAs to advertise in the OSPF domain. As a result, R1 and R2 have to notify the routers in the OSPF domain that 10.1.1.0/24 no longer exists. When this happens, R1 and R2 no longer have the 10.1.1.0/24 network that they learned through OSPF from each other in the routing table. What does this cause? The EIGRP external route 10.1.1.0/24 is reinstalled in the routing table, and because redistribution from EIGRP into OSPF is occurring, the issue repeats all over again. As you can see, the routing table is not stable because routes are inserted and removed and inserted and removed over and over again. You can see this happening with the debug ip routing command, which displays changes as they occur to the routing table.

Let’s take this example even further. Examine Figure 17-5, which shows the 10.1.1.0/24 network being redistributed back into the EIGRP autonomous system on R1 and R2 when the OSPF route is in the routing table on R1 and R2. This is known as route feedback. Now R3 thinks that 10.1.1.0/24 is reachable through the boundary router (R5) between the RIPv2 domain and the EIGRP autonomous system, as well as through R1 and R2 between EIGRP and OSPF. Depending on the metric for each of the learned paths to 10.1.1.0/24, R3 may choose the correct path to the RIP domain or the path through R1 or R2, which would eventually blackhole the traffic.

This is definitely a bad situation to be in. You can recognize this type of situation by analyzing a diagram and understanding the protocols in use. You don’t even need to use any show commands. In addition, the symptoms are wide ranging. For example, a user might have a connection from 192.168.2.0/24 to 10.1.1.0/24 for one moment and then the connection is lost, then it is back, then lost, all because the routes are being added and removed over and over again, causing a loop, and then no loop, and so on. Therefore, you need to be able to look at the topology and identify where this type of issue might occur and implement the necessary measures to stop it from happening. Or, if it is happening, you need to identify why it is happening and propose how to fix it.

Remember that this issue was caused by AD; 110 is better than 170. Therefore, you need to either lower the AD of the EIGRP external routes on R1 and R2 for 10.1.1.0/24 or increase the AD of the OSPF Type 5 learned routes on R1 and R2 for 10.1.1.0/24. Your goal is to make sure the EIGRP learned route is the preferred route. Regardless of what you choose to do, you need to use the distance command on R1 and R2 and specify what the AD will be for the 10.1.1.0/24 network. If you lower the EIGRP AD, it needs to be 109 or lower, and if you decide to increase the OSPF AD, it needs to be 171 or higher.

EIGRP already differentiates between routes learned from within the autonomous system and routes learned from outside the autonomous system by assigning different administrative distance:

• Internal EIGRP: 90

• External EIGRP: 170

To modify the default administrative distance on IOS routers, use the EIGRP configuration command distance eigrp ad-internal ad-external. Valid values for the AD are between 1 and 255; a value of 255 stops the installation of the route into the Routing Information Base (RIB).

Cisco IOS routers also allow selective AD modification for specific internal networks with this command:

Click here to view code image

distance ad source-ip source-ip-wildcard [acl-number | acl-name]

The source-ip option restricts the modification of routes in the EIGRP table that were learned from a specific router, and the optional acl restricts to a specific network prefix. Note that EIGRP does not allow the selective AD modification based on prefixes for external EIGRP routes.

Example 17-1 demonstrates how to configure R1 and R2 in Figure 17-5 so they have an AD set to 109 for all learned external EIGRP routes, which is lower than the AD for the OSPF learned routes. Therefore, the EIGRP routes will be installed in the routing tables of R1 and R2.

Example 17-1 EIGRP AD Manipulation Configuration

R1(config)# router eigrp 100
R1(config-rtr)# distance eigrp 90 109
R1(config-rtr)# end

R2(config)# router eigrp 100
R2(config-rtr)# distance eigrp 90 109
R2(config-rtr)# end

OSPF uses the same default AD 110 value for routes learned within the OSPF routing domain and routes learned outside the OSPF routing domain. On IOS routers, you modify the default AD with this OSPF configuration command:

Click here to view code image

distance ospf {external | inter-area | intra-area} ad

The command allows you to set a different AD for each OSPF network type.

IOS routers allow selective AD modification for specific networks with this command:

Click here to view code image

distance ad source-ip source-ip-wildcard [acl-number | acl-name]

The source-ip option restricts the modification to routes in the OSPF link-state database (LSDB) learned from the advertising router of the LSA. The source-ip-wildcard address fields match the router ID (RID) for the advertising route. The optional acl is used to restrict to a specific network prefix.

Example 17-2 demonstrates how to modify R1 and R2 so that OSPF external routes are set with an AD of 171, which is higher than the AD of external EIGRP routes (170). This ensures that the EIGRP routes are preferred over the OSPF routes for 10.0.0.0/24 in Figure 17-5 and installed in the routing tables of R1 and R2.

Example 17-2 OSPF Customized AD Configuration

R1(config)# router ospf 1
R1(config-rtr)# distance ospf external 171
R1(config-rtr)#

R2(config)# router ospf 1
R2(config-rtr)# distance ospf external 171
R2(config-rtr)#

BGP differentiates between routes learned from internal BGP (iBGP) peers, routes learned from external BGP (eBGP) peers, and routes learned locally. On IOS routers, you use the BGP configuration command distance bgp external-ad internal-ad local-routes to set the AD for each BGP network type and the address family command distance ad source-ip source-wildcard [acl-number | acl-name] to modify AD for routes received from a specific neighbor.

For example, the BGP command distance 44 55 66 sets the AD for eBGP routes to 44, the AD for iBGP routes to 55, and the AD for locally learned routes to 66.

There is another way to solve the issue presented in Figure 17-5. You could attach a distribute list to the OSPF process on R1 and R2. When a distribute list is used with OSPF, it can control what routes are installed in the routing table from the OSPF database. Therefore, if you deny the 10.1.1.0/24 route in the OSPF database with an AD of 110 from being installed in the routing table with a distribute list on R1 and R2, the EIGRP route with an AD of 170 is installed in the routing table instead.

Example 17-3 shows how you can configure R1 and R2 to accomplish this.

Example 17-3 Using a Distribute List to Control OSPF Routes Installed in the Routing Table

R1(config)# ip prefix-list PREFER_EIGRP seq 10 deny 10.1.1.0/24
R1(config)# ip prefix-list PREFER_EIGRP seq 20 permit 0.0.0.0/0 le 32
R1(config)# router ospf 1
R1(config-rtr)# distribute-list prefix PREFER_EIGRP in
R1(config-rtr)#

R2(config)# ip prefix-list PREFER_EIGRP seq 10 deny 10.1.1.0/24
R2(config)# ip prefix-list PREFER_EIGRP seq 20 permit 0.0.0.0/0 le 32
R2(config)# router ospf 1
R2(config-rtr)# distribute-list prefix PREFER_EIGRP in
R2(config-rtr)#

Finally, you do not want the routes that are redistributed from EIGRP into OSPF to be redistributed back into the EIGRP autonomous system or vice versa. Such redistribution can cause routing issues such as loops, which prevent packets from being correctly delivered to their destination (in addition to wasting CPU and memory resources on various devices in the network). The most robust way to deal with this is to use route tags. Figure 17-6 shows how R1 and R2 can add a tag (which is just an arbitrary value that can be used to identify the route) when the route is redistributed. This is accomplished with route maps. In this example, when R1 redistributes the 10.1.1.0/24 route into the OSPF domain, it adds the tag 10. When R2 redistributes the 10.1.1.0/24 route into the OSPF domain, it adds the tag 20.

Example 17-4 shows the commands that you could use to tag the 10.1.1.0/24 routes as they are redistributed on R1 and R2. First, you must define the routes you want to tag with an ACL or a prefix list. Then you create a route map that has a sequence that matches the ACL or prefix list created, and will set the desired tag when there is a match. In this case, R1 sets a tag of 10, and R2 sets a tag of 20. Do not forget about all the other routes you want to redistribute without a tag. That is what sequence 20 is for in the route map. If you forget it, all other routes are denied and not redistributed because of the implicit deny sequence at the end of a route map. You then attach the route map to the redistribution command.

Example 17-4 Tagging Routes as They Are Being Redistributed

R1#
ip prefix-list TAG_10.1.1.0/24 seq 5 permit 10.1.1.0/24
!
route-map REDIS_EIGRP_TO_OSPF permit 10
 match ip address prefix-list TAG_10.1.1.0/24
 set tag 10
route-map REDIS_EIGRP_TO_OSPF permit 20
!
router ospf 1
 redistribute eigrp 100 subnets route-map REDIS_EIGRP_TO_OSPF
R2#
ip prefix-list TAG_10.1.1.0/24 seq 5 permit 10.1.1.0/24
!
route-map REDIS_EIGRP_TO_OSPF permit 10
 match ip address prefix-list TAG_10.1.1.0/24
 set tag 20
route-map REDIS_EIGRP_TO_OSPF permit 20
!
router ospf 1
 redistribute eigrp 100 subnets route-map REDIS_EIGRP_TO_OSPF

You are not done yet. To prevent R1 and R2 from redistributing the OSPF-learned 10.1.1.0/24 routes with their tags back into EIGRP, you deny the routes based on their tags. As shown in Figure 17-7, on R1 you deny the routes with the tag 20 from being redistributed into the EIGRP autonomous system, and on R2 you deny the routes with the tag 10 from being redistributed into the EIGRP autonomous system.

Example 17-5 shows the commands that can be used to ensure that R1 and R2 do not redistribute the 10.1.1.0/24 networks back into the EIGRP autonomous system. Notice the very first sequence in this route map. In this case, it is deny, and when deny is used with redistribution, it indicates that matches are not redistributed. Therefore, R1 does not redistribute from OSPF into EIGRP any routes that have the tag 20, as shown in sequence 10, and sequence 20 allows all other routes to be redistributed. R2 does not redistribute any routes with the tag 10 from OSPF into EIGRP based on sequence 10, and all other routes are redistributed based on sequence 20.

Example 17-5 Using Route Tags to Prevent Routes from Being Reinjected

R1#
route-map REDIS_OSPF_INTO_EIGRP deny 10
 match tag 20
route-map REDIS_OSPF_INTO_EIGRP permit 20
!
router eigrp 100
 redistribute ospf 1 metric 100000 100 255 1 1500 route-map REDIS_OSPF_INTO_EIGRP

R2#
route-map REDIS_OSPF_INTO_EIGRP deny 10
 match tag 10
route-map REDIS_OSPF_INTO_EIGRP permit 20
!
router eigrp 100
 redistribute ospf 1 metric 100000 100 255 1 1500 route-map REDIS_OSPF_INTO_EIGRP

So, to wrap up the coverage on advanced redistribution scenarios, keep these points in mind:

• Internal prefix information should always be preferred over external prefix information.

• Prefixes should never be redistributed back into a routing domain from which they were originally redistributed.

• A topological diagram is mandatory if you expect to solve the issues quickly and efficiently.

Route Redistribution Review

A router that connects two or more routing domains and that will be the point of redistribution is known as a boundary router (see Figure 17-8). A boundary router can redistribute static routes, connected routes, and routes learned through one routing protocol into another routing protocol.

Redistribution occurs from the routing table into a routing protocol’s data structure (such as the EIGRP topology table or the OSPF LSDB), as shown in Figure 17-9. This is a key concept for troubleshooting purposes because if the route is not in the routing table, it cannot be redistributed. Keep in mind that if it is not in the routing table, you need to troubleshoot some other underlying issue in order to get redistribution to work. For example, if you are redistributing EIGRP into OSPF, and the EIGRP route is not in the routing table, that is not a redistribution problem; it is an EIGRP problem, and it must be solved first.

Different routing protocols use different types of metrics, as illustrated in Figure 17-10. Therefore, when a route is redistributed into a routing protocol, a metric used by the destination routing protocol needs to be associated with the route being redistributed.

The metric assigned to a route being redistributed into another routing process is called a seed metric. The seed metric is needed to communicate relative levels of reachability between dissimilar routing protocols. A seed metric can be defined in one of three ways:

• Using the default-metric command

• Using the metric parameter with the redistribute command

• Applying a route map configuration to the redistribute command

If multiple seed metrics are defined with the commands, the order of preference is (1) metric defined in the route map that was applied to the redistribute command; (2) metric parameter defined with the redistribute command; (3) metric defined with the default-metric command.

If a seed metric is not specified, a default seed metric is used. Keep in mind that EIGRP has a default seed metric that is considered unreachable. Therefore, if you do not manually configure a seed metric when redistributing routes into EIGRP, the redistributed route is not reachable and is therefore not advertised to other routers in the routing domain. OSPF has a default seed metric of 20, unless it is a BGP route being redistributed, in which case it has a seed metric of 1. When redistributing into BGP, BGP uses the exact metric of the Interior Gateway Protocol (IGP).

Some routing protocols (for example, EIGRP and OSPF) can tag routes as either internal (that is, routes locally configured or connected) or external (that is, routes learned from another routing process) and can give priority to internal routes over external routes. The capability to distinguish between internal and external routes can help prevent a potential routing loop, where two routing protocols continually redistribute the same routes into one another at multiple redistribution points.

Keep in mind that two prerequisites must be met for the routes of one IP routing protocol to be redistributed into another IP routing protocol:

• The route needs to be installed in the IP routing table of the border router (the router performing redistribution) by the protocol being redistributed.

• The destination IP routing protocol needs a reachable metric to assign to the redistributed routes.

Based on these two prerequisites, Table 17-2 lists various redistribution troubleshooting targets and recommendations for dealing with them.

Troubleshooting Redistribution into EIGRP

When redistributing into EIGRP for IPv4, you can apply a metric with the metric keyword or a route map with the route-map keyword. If you are redistributing OSPF into EIGRP, as shown in Example 17-6, you also have the option to specify the match option, which allows you to match just internal routes, just external routes, just nssa-external routes, or a combination of them.

The most common issue you will run into when redistributing into EIGRP for IPv4 is related to the metric. Remember that the seed metric is, by default, set to infinity (unreachable). Therefore, if you fail to manually set the metric using any of the options listed earlier in the chapter, routes will not be advertised to the other routers in the EIGRP autonomous system. Keep in mind that you must consider whether the metrics you specify will cause suboptimal routing if you have multiple redistribution points in the routing domain.

Also, if the wrong route map is applied, or if there is an error in the route map, routes will not be redistributed properly.

Example 17-6 EIGRP for IPv4 Redistribution Options

R1(config)# router eigrp 1
R1(config-router)# redistribute ospf 1 ?
 match Redistribution of OSPF routes
 metric Metric for redistributed routes
 route-map Route map reference
 <cr>

With EIGRP for IPv6, you have the same match, metric, and route-map keywords, as well as the include-connected keyword. By default, with EIGRP for IPv4, the networks associated with the local interfaces participating in the redistributed routing process are redistributed as well. However, with EIGRP for IPv6, the networks associated with the local interfaces participating in the redistributed routing process are not redistributed. Therefore, if you want to include the networks associated with the local interfaces participating in the routing process that is being redistributed, you need to use the include-connected keyword, as shown in Example 17-7.

Example 17-7 EIGRP for IPv6 Redistribution Options

R1(config)# ipv6 router eigrp 1
R1(config-rtr)# redistribute ospf 1 ?
 include-connected Include connected
 match Redistribution of OSPF routes
 metric Metric for redistributed routes
 route-map Route map reference
 <cr>

On the boundary router, you can verify which protocols are being redistributed into EIGRP for IPv4 with the show ip protocols command. Example 17-8 shows that OSPF routes are being redistributed into EIGRP for IPv4.

Example 17-8 Verifying Protocols That Are Being Redistributed into EIGRP for IPv4

R2# show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 100"
 Outgoing update filter list for all interfaces is not set
 Incoming update filter list for all interfaces is not set
 Default networks flagged in outgoing updates
 Default networks accepted from incoming updates
 Redistributing: ospf
 EIGRP-IPv4 Protocol for AS(100)
 Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
...output omitted...

When reviewing the EIGRP for IPv4 topology table with the show ip eigrp topology command, you can identify the routes that have been injected into the EIGRP process via redistribution because the output states via Redistributed, as shown in Example 17-9.

Example 17-9 Verifying Routes Redistributed into EIGRP for IPv4 (Topology Table)

R2# show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(203.0.113.1)
     Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
            r - reply Status, s - sia Status

P 10.1.12.0/24, 1 successors, FD is 2560000256
     via Redistributed (2560000256/0)
P 10.1.14.0/24, 1 successors, FD is 2560000256
     via Redistributed (2560000256/0)
P 10.1.3.0/24, 1 successors, FD is 3072
     via 10.1.23.3 (3072/2816), GigabitEthernet1/0
P 10.1.23.0/24, 1 successors, FD is 2816
     via Connected, GigabitEthernet1/0
P 10.1.1.0/24, 1 successors, FD is 2560000256
     via Redistributed (2560000256/0)

When examining a redistributed route in the routing table on the boundary router, as shown in Example 17-10, with the show ip route ip-address command, the output indicates how the route is known, how it is being redistributed, and the EIGRP metric values that are being used at the redistribution point.

Example 17-10 Verifying Routes Redistributed into EIGRP for IPv4 (Routing Table)

R2# show ip route 10.1.1.0
Routing entry for 10.1.1.0/24
 Known via "ospf", distance 110, metric 1
 Redistributing via eigrp 100, ospf
 Advertised by eigrp 100 metric 1 1 1 1 1
 Last update from 10.1.12.1 on GigabitEthernet0/0, 00:00:19 ago
 Routing Descriptor Blocks:
 * 10.1.12.1, from 10.1.12.1, 00:00:19 ago, via GigabitEthernet0/0
 Route metric is 1, traffic share count is 1

When examining the routing tables on other routers (not the boundary router) in the EIGRP for IPv4 autonomous system, the redistributed routes have an AD of 170 by default and the code D EX, as shown in Example 17-11.

Example 17-11 Examining EIGRP for IPv4 Redistributed Routes in a Routing Table

R3# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
      D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
      N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
      E1 - OSPF external type 1, E2 - OSPF external type 2
      i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
      ia - IS-IS inter area, * - candidate default, U - per-user static route
      o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
      + - replicated route, % - next hop override

Gateway of last resort is not set

 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D EX 10.1.1.0/24
        [170/2560000512] via 10.1.23.2, 00:04:38, GigabitEthernet1/0
C 10.1.3.0/24 is directly connected, GigabitEthernet0/0
L 10.1.3.3/32 is directly connected, GigabitEthernet0/0
D EX 10.1.12.0/24
        [170/2560000512] via 10.1.23.2, 00:04:38, GigabitEthernet1/0
D EX 10.1.14.0/24
        [170/2560000512] via 10.1.23.2, 00:04:38, GigabitEthernet1/0
C 10.1.23.0/24 is directly connected, GigabitEthernet1/0
L 10.1.23.3/32 is directly connected, GigabitEthernet1/0

For EIGRP for IPv6, the show ipv6 protocols output is more detailed for redistribution, as shown in Example 17-12. Notice that it states the protocol, the seed metric, and whether connected networks are included.

Example 17-12 Verifying EIGRP for IPv6 Redistribution with show ipv6 protocols

R2# show ipv6 protocols
...output omitted...
IPv6 Routing Protocol is "eigrp 100"
EIGRP-IPv6 Protocol for AS(100)
 Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
 NSF-aware route hold timer is 240
 Router-ID: 203.0.113.1
 Topology : 0 (base)
 Active Timer: 3 min
 Distance: internal 90 external 170
 Maximum path: 16
Maximum hopcount 100
 Maximum metric variance 1

 Interfaces:
   GigabitEthernet1/0
 Redistribution:
   Redistributing protocol OSPF 1 with metric 1 1 1 1 1 include-connected

The output of show ipv6 eigrp topology on the boundary router also indicates which routes are redistributed, as shown in Example 17-13.

Example 17-13 Verifying EIGRP for IPv6 Redistribution with show ipv6 eigrp topology

R2# show ipv6 eigrp topology
EIGRP-IPv6 Topology Table for AS(100)/ID(203.0.113.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
 r - reply Status, s - sia Status

P 2001:DB8:0:1::/64, 1 successors, FD is 2560000256
        via Redistributed (2560000256/0)
P 2001:DB8:0:3::/64, 1 successors, FD is 3072
        via FE80::C804:10FF:FE2C:1C (3072/2816), GigabitEthernet1/0
P 2001:DB8:0:12::/64, 1 successors, FD is 2560000256
        via Redistributed (2560000256/0)
P 2001:DB8:0:23::/64, 1 successors, FD is 2816
        via Connected, GigabitEthernet1/0

When examining the routing tables on other routers besides the boundary router in the EIGRP for IPv6 autonomous system, the redistributed routes have an administrative distance of 170 by default and the code EX, as shown in Example 17-14.

Example 17-14 Verifying EIGRP for IPv6 Redistributed Routes

R3# show ipv6 route
IPv6 Routing Table - default - 7 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
 B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
 I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
 EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
 NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
EX 2001:DB8:0:1::/64 [170/2560000512]
    via FE80::C802:AFF:FE88:1C, GigabitEthernet1/0
C 2001:DB8:0:3::/64 [0/0]
    via GigabitEthernet0/0, directly connected
L 2001:DB8:0:3::3/128 [0/0]
    via GigabitEthernet0/0, receive
EX 2001:DB8:0:12::/64 [170/2560000512]
    via FE80::C802:AFF:FE88:1C, GigabitEthernet1/0
C 2001:DB8:0:23::/64 [0/0]
    via GigabitEthernet1/0, directly connected
L 2001:DB8:0:23::3/128 [0/0]
    via GigabitEthernet1/0, receive
L FF00::/8 [0/0]
    via Null0, receive

Troubleshooting Redistribution into OSPF

When redistributing into OSPF, you have more options than you have with other routing protocols, as shown in Example 17-15. The metric option allows you to provide a seed metric at the redistribution point. The default seed metric is 20 with OSPF; therefore, providing a metric is not mandatory. If you forget to provide a metric, redistributed routes are still advertised to other routers in the OSPF domain. The metric-type option is used to define the type of OSPF external route the redistributed route will be. By default, it will be Type 2, which is represented as E2 in the routing table. With E2, each router preserves the seed metric for the external routes. Type 1, which is represented as E1 in the routing table, allows each router to add to the seed metric all the other link costs to reach the redistribution point in the domain. Therefore, each router has a metric that is a combination of the seed metric and the total cost to reach the redistribution router. With the nssa-only option, you can limit redistributed routes to the not-so-stubby area (NSSA) only, and with the route-map option, you can reference a route map that provides more granular control over the routes that are being redistributed. The subnets keyword is an extremely important option. Without the subnets keyword, only classful networks are redistributed (for example, a Class A address with a /8 mask, a Class B address with a /16 mask, and a Class C address with a /24 mask). With the subnets keyword, all classless and classful networks are redistributed. Therefore, if you have any subnets that you want to redistribute, the subnets keyword is mandatory. The tag keyword can be used to add a numeric ID (tag) to the route so the route can be referenced by the tag at a later point for filtering or manipulation purposes.

Example 17-15 OSPFv2 Redistribution Options

R1(config)# router ospf 1
R1(config-router)# redistribute eigrp 100 ?
 metric      Metric for redistributed routes
 metric-type OSPF/IS-IS exterior metric type for redistributed routes
 nssa-only   Limit redistributed routes to NSSA areas
 route-map   Route map reference
 subnets     Consider subnets for redistribution into OSPF
 tag Set     tag for routes redistributed into OSPF
 <cr>

Look closely at Example 17-16, which displays the options available when redistributing into OSPFv3. What has been added and what is missing when to when using OSPFv2? The include-connected keyword has been added. By default, with OSPFv2, the networks associated with the local interfaces that are participating in the routing process that is being redistributed are redistributed as well. However, with OSPFv3, they are not. Therefore, if you want to include the networks associated with the interfaces participating in the routing protocol that is being redistributed on the ASBR, you need to use the include-connected keyword.

The subnets keyword is not an option with OSPFv3 because the concepts classful and classless do not exist with IPv6.

Example 17-16 OSPFv3 Redistribution Options

R1(config)# ipv6 router ospf 1
R1(config-rtr)# redistribute eigrp 100 ?
 include-connected  Include connected
 metric             Metric for redistributed routes
 metric-type        OSPF/IS-IS exterior metric type for redistributed routes
 nssa-only          Limit redistributed routes to NSSA areas
 route-map          Route map reference
 tag                Set tag for routes redistributed into OSPF
 <cr>

The show ip protocols command enables you to verify which routing protocols are being redistributed into the OSPFv2 process. In Example 17-17, you can see that EIGRP 100 routes, including subnets, are being redistributed into the OSPFv2 process.

Example 17-17 Verifying Protocols Being Redistributed into OSPFv2

R2# show ip protocols
...output omitted...
Routing Protocol is "ospf 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 203.0.113.1
  It is an autonomous system boundary router
 Redistributing External Routes from,
    eigrp 100, includes subnets in redistribution
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    10.1.12.2 0.0.0.0 area 0
  Routing Information Sources:
    Gateway         Distance    Last Update
    10.1.14.1       110         00:19:48
  Distance: (default is 110)

Routes redistributed into an OSPFv2 normal area are advertised within a Type 5 LSA. Routes redistributed into an OSPFv2 NSSA or totally NSSA area are advertised within a Type 7 LSA and then converted to a Type 5 LSA at an area border router (ABR). You can view the redistributed routes that are injected into the OSPFv2 LSDB with the show ip ospf database command, as shown in Example 17-18. In this example, the 10.1.3.0 and 10.1.23.0 networks have been redistributed into the OSPFv2 routing process.

Example 17-18 Verifying Redistributed Routes in the OSPFv2 LSDB

R2# show ip ospf database

            OSPF Router with ID (203.0.113.1) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age    Seq#       Checksum    Link count
10.1.14.1       10.1.14.1       738    0x80000003 0x009AEA    3
203.0.113.1     203.0.113.1     596    0x80000003 0x005829    1

                Net Link States (Area 0)

Link ID         ADV Router      Age    Seq#       Checksum
10.1.12.1       10.1.14.1       738    0x80000002 0x001F8F

                Type-5 AS External Link States

Link ID         ADV Router      Age    Seq#       Checksum   Tag
10.1.3.0        203.0.113.1     596    0x80000002 0x00EB67   0
10.1.23.0       203.0.113.1     596    0x80000002 0x000F300

When examining a redistributed route in the routing table on the boundary router (autonomous system boundary router [ASBR]), as shown in Example 17-19, with the show ip route ip_address command, the output indicates how the route is known, how it is being redistributed, and how it is being advertised. In this case, the route is known through EIGRP 100 and is being redistributed into the OSPF 1 process with the subnets keyword.

Example 17-19 Verifying Redistributed Routes in the ASBR’s Routing Table

R2# show ip route 10.1.3.0
Routing entry for 10.1.3.0/24
  Known via "eigrp 100", distance 90, metric 3072, type internal
  Redistributing via eigrp 100, ospf 1
  Advertised by ospf 1 subnets
  Last update from 10.1.23.3 on GigabitEthernet1/0, 00:50:19 ago
  Routing Descriptor Blocks:
  * 10.1.23.3, from 10.1.23.3, 00:50:19 ago, via GigabitEthernet1/0
      Route metric is 3072, traffic share count is 1
      Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

When examining the routing table on other routers (not the ASBR) in the OSPFv2 domain, by default the redistributed routes have an AD of 110 and the code O E2, as shown in Example 17-20. If you change the metric type to E1, the routes appear with the code E1. Within an NSSA or a totally NSSA, the routes will appear as O N1 or O N2.

Example 17-20 Examining OSPFv2 Redistributed Routes in a Routing Table

R1# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
      D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
      N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
      E1 - OSPF external type 1, E2 - OSPF external type 2
      i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
      ia - IS-IS inter area, * - candidate default, U - per-user static route
      o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
      + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C        10.1.1.0/24 is directly connected, GigabitEthernet0/0
L        10.1.1.1/32 is directly connected, GigabitEthernet0/0
O E2     10.1.3.0/24 [110/20] via 10.1.12.2, 00:49:11, GigabitEthernet1/0
C        10.1.12.0/24 is directly connected, GigabitEthernet1/0
L        10.1.12.1/32 is directly connected, GigabitEthernet1/0
C        10.1.14.0/24 is directly connected, FastEthernet3/0
L        10.1.14.1/32 is directly connected, FastEthernet3/0
O E2     10.1.23.0/24 [110/20] via 10.1.12.2, 00:49:11, GigabitEthernet1/0

For OSPFv3, the show ipv6 protocols output is shown in Example 17-21. Notice that it states the protocol, the seed metric, and whether connected networks are included.

Example 17-21 Verifying OSPFv3 Redistribution with show ipv6 protocols

R2# show ipv6 protocols
...output omitted...
IPv6 Routing Protocol is "ospf 1"
  Router ID 2.2.2.2
  Autonomous system boundary router
  Number of areas: 1 normal, 0 stub, 0 nssa
  Interfaces (Area 0):
    GigabitEthernet0/0
  Redistribution:
    Redistributing protocol eigrp 100 with metric 10 include-connected

The output of show ipv6 ospf database on the ASBR identifies the external Type 5 routes just as OSPFv2 does, as shown in Example 17-22.

Example 17-22 Verifying OSPFv3 Redistribution with show ipv6 ospf database

R2# show ipv6 ospf database

            OSPFv3 Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

ADV Router       Age         Seq#          Fragment ID   Link count Bits
 1.1.1.1         1429        0x80000004    0             1          B
 2.2.2.2         1446        0x80000003    0             1          E

                Net Link States (Area 0)

ADV Router       Age         Seq#          Link ID       Rtr count
 1.1.1.1         1429        0x80000002    4             2

                Inter Area Prefix Link States (Area 0)

ADV Router       Age         Seq#          Prefix
 1.1.1.1         1693        0x80000002    2001:DB8:0:14::/64

                Link (Type-8) Link States (Area 0)

ADV Router       Age         Seq#          Link ID   Interface
 1.1.1.1         1693        0x80000002    4         Gi0/0
 2.2.2.2         1446        0x80000002    3         Gi0/0

                Intra Area Prefix Link States (Area 0)

ADV Router       Age         Seq#          Link ID Ref-lstype Ref-LSID
 1.1.1.1         1429        0x80000006    0       0x2001     0
 1.1.1.1         1429        0x80000002    4096    0x2002     4

                Type-5 AS External Link States

ADV Router       Age         Seq#          Prefix
 2.2.2.2         46          0x80000003    2001:DB8:0:3::/64
 2.2.2.2         46          0x80000003    2001:DB8:0:23::/64

When examining the routing table on other routers (not the ASBR) in the OSPFv3 domain, by default the redistributed routes have an administrative distance of 110 and the code OE2, as shown in Example 17-23. If the metric type is changed to Type 1, the code is OE1. In an NSSA or a totally NSSA, the redistributed routes are listed as ON1 or ON2.

Example 17-23 Verifying OSPFv3 Redistributed Routes

R1# show ipv6 route
IPv6 Routing Table - default - 9 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
 B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
 I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
 EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
 NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
C   2001:DB8:0:1::/64 [0/0]
     via GigabitEthernet0/0, directly connected
L   2001:DB8:0:1::1/128 [0/0]
     via GigabitEthernet0/0, receive
OE2 2001:DB8:0:3::/64 [110/10]
     via FE80::C802:AFF:FE88:8, GigabitEthernet1/0
C   2001:DB8:0:12::/64 [0/0]
     via GigabitEthernet1/0, directly connected
L   2001:DB8:0:12::1/128 [0/0]
     via GigabitEthernet1/0, receive
C   2001:DB8:0:14::/64 [0/0]
     via FastEthernet3/0, directly connected
L   2001:DB8:0:14::1/128 [0/0]
     via FastEthernet3/0, receive
OE2 2001:DB8:0:23::/64 [110/10]
     via FE80::C802:AFF:FE88:8, GigabitEthernet1/0
L   FF00::/8 [0/0]
     via Null0, receive

Note that if you are redistributing from BGP into OSPF, EIGRP, or RIP, only eBGP routes are redistributed by default. If you want iBGP routes to be redistributed, you must issue the bgp redistribute-internal command in router BGP configuration mode.

Troubleshooting Redistribution into BGP

When redistributing EIGRP into BGP for IPv4, you have the same options as when redistributing into EIGRP. You can apply a metric with the metric keyword or a route map with the route-map keyword. If you are redistributing OSPF into BGP, as shown in Example 17-24, you also have the option to specify the match option, which allows you to match just internal routes, just external routes, just nssa-external routes, or a combination of them. With BGP, only internal OSPF routes are redistributed by default. If you want external OSPF routes to be redistributed, you must indicate so during redistribution.

The metric keyword is not required because BGP uses the IGP metric by default. If the wrong route map is applied, or if there is an error in the route map, routes are not redistributed properly.

Example 17-24 BGP for IPv4 Redistribution Options

R1(config)# router bgp 65001
R1(config-router)# address-family ipv4 unicast
R1(config-router-af)# redistribute ospf 1 ?
 match      Redistribution of OSPF routes
 metric     Metric for redistributed routes
 route-map  Route map reference
 vrf        VPN Routing/Forwarding Instance
 <cr>

With BGP for IPv6, you have the same match, metric, and route-map keywords, as well as the include-connected keyword. By default, with BGP for IPv4, the networks of the local interfaces participating in the routing protocol that is being redistributed on the border router are redistributed as well. However, with BGP for IPv6, they are not. Therefore, if you want to redistribute the networks associated with the local interfaces participating in the routing process being redistributed into BGP for IPv6, you need to use the include-connected keyword, as shown in Example 17-25.

Example 17-25 BGP for IPv6 Redistribution Options

R1(config)# router bgp 65001
R1(config-router) # address-family ipv6 unicast
R1(config-router-af) # redistribute ospf 1 ?
 include-connected   Include connected
 match               Redistribution of OSPF routes
 metric              Metric for redistributed routes
 route-map           Route map reference
 <cr>

Using the commands show ip protocols and show ipv6 protocols, you can verify which protocols are being redistributed into the BGP routing process, as shown in Example 17-26.

Example 17-26 Verifying Protocols Being Redistributed into BGP

R2# show ip protocols
...output omitted...
Routing Protocol is "bgp 65500"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  IGP synchronization is disabled
  Automatic route summarization is disabled
  Redistributing: ospf 1 (internal)

 Neighbor(s):
   Address     FiltIn FiltOut DistIn DistOut Weight RouteMap
   10.1.23.3
 Maximum path: 1
Routing Information Sources:
   Gateway         Distance     Last Update
 Distance: external 20 internal 200 local 200

R2# show ipv6 protocols
...output omitted...
IPv6 Routing Protocol is "bgp 65500"
  IGP synchronization is disabled
  Redistribution:
    Redistributing protocol ospf 1 (internal) include-connected
  Neighbor(s):
  Address FiltIn FiltOut Weight RoutemapIn RoutemapOut
  2001:DB8:0:23::3

In the BGP table, redistributed routes appear with a question mark (?) under the Path column, as shown in Example 17-27.

Example 17-27 Verifying Redistributed Routes in the BGP Table

R2# show bgp all
For address family: IPv4 Unicast

BGP table version is 4, local router ID is 203.0.113.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

 Network             Next Hop    Metric LocPrf Weight Path
 *> 10.1.1.0/24      10.1.12.1        2         32768 ?
 *> 10.1.12.0/24     0.0.0.0          0         32768 ?
 *> 10.1.14.0/24     10.1.12.1        2         32768 ?

For address family: IPv6 Unicast

BGP table version is 4, local router ID is 203.0.113.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

 Network                Next Hop    Metric    LocPrf   Weight Path
 *> 2001:DB8:0:1::/64   ::               2              32768 ?
 *> 2001:DB8:0:12::/64  ::               0              32768 ?
 *> 2001:DB8:0:14::/64  ::               2              32768 ?

…output omitted…

Troubleshooting Redistribution with Route Maps

When applying a route map with the redistribution command, you have a few extra items to verify during the troubleshooting process:

• Is the correct route map applied?

• Is permit or deny specified for the sequence, and is it correct? A permit sequence indicates that what is matched is redistributed. A deny sequence indicates that what is matched is not redistributed.

• If there is an access list or a prefix list being used in the match statement, you need to verify that they are correct by using the show {ip | ipv6} access-list command or the show {ip | ipv6} prefix-list command.

• If there are set statements, you need to verify that the correct values have been specified to accomplish the desired goal.

• If a route does not match any of the match statements in any of the sequences, it falls into the implicit deny sequence at the end of the route map and is not redistributed.

• If a route map is attached to the redistribution command but that route map does not exist, none of the routes are redistributed.

Trouble Ticket 17-1

Problem: Users in the IPv4 Branch site indicate that they are not able to access any resources outside the Branch office.

On Branch, you first check the routing table to see which routes Branch knows; you do this by using the show ip route command, as shown in Example 17-28. The output indicates that Branch only knows about connected and local routes.

Example 17-28 Verifying the Routing Table on Branch

Branch# show ip route
...output omitted...
      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.1.4.0/24 is directly connected, GigabitEthernet0/0
L        10.1.4.4/32 is directly connected, GigabitEthernet0/0
C        10.1.14.0/24 is directly connected, FastEthernet1/0
L        10.1.14.4/32 is directly connected, FastEthernet1/0

You decide that an EIGRP neighbor relationship might not have been formed with R1. Therefore, you issue the show ip eigrp neighbors command on Branch to confirm. As shown in Example 17-29, the device with IP address 10.1.14.1 has formed an adjacency with Branch. The show cdp neighbors detail command reveals that the IP address belongs to R1, as shown in the same example.

Example 17-29 Verifying EIGRP Neighbors on Branch

Branch# show ip eigrp neighbors
EIGRP-IPv4 VR(TSHOOT) Address-Family Neighbors for AS(100)
H   Address                 Interface         Hold Uptime   SRTT RTO  Q  Seq
                                              (sec)         (ms)     Cnt Num
0   10.1.14.1               Fa1/0               12 01:40:12  62  372  0   6

Branch# show cdp neighbors detail
-------------------------
Device ID: R1
Entry address(es):
  IP address: 10.1.14.1
  IPv6 address: 2001:DB8:0:14::1 (global unicast)
  IPv6 address: FE80::C801:AFF:FE88:54 (link-local)
...output omitted...

Because R1 and Branch are neighbors, but Branch is not learning any routes from R1, you decide to check whether there are any incoming route filters configured on Branch by using the show ip protocols command. The output shown in Example 17-30 indicates that there are no route filters.

Example 17-30 Verifying Route Filters on Branch

Branch# show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 100"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
...output omitted...

Next, you decide to check for outbound route filters on R1 by using show ip protocols. As shown in Example 17-31, there are no route filters.

Example 17-31 Verifying Route Filters on R1

R1# show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 100"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  Redistributing: ospf 1
  EIGRP-IPv4 Protocol for AS(100)
  Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  NSF-aware route hold timer is 240
...output omitted...

Because Figure 17-11 shows that R1 is a boundary router performing redistribution, you shift your attention to R1’s redistribution configuration to make sure the OSPF routes are being redistributed into EIGRP. In Example 17-32, the output of show ip protocols indicates that OSPF process 1 is being redistributed into EIGRP autonomous system 100. However, so far all your troubleshooting efforts are indicating that Branch is not learning any redistributed routes.

Example 17-32 Verifying That OSPF Is Being Redistributed into EIGRP

R1# show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 100"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  Redistributing: ospf 1
  EIGRP-IPv4 Protocol for AS(100)
    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
    NSF-aware route hold timer is 240
...output omitted...

You now issue the show ip eigrp topology command on R1 to determine whether routes are truly being redistributed from OSPF into EIGRP. As shown in Example 17-33, none of the OSPF routes are being redistributed into the EIGRP autonomous system.

Example 17-33 Verifying That Redistributed Routes Are in the EIGRP Topology Table

R1# show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(10.1.14.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 10.1.14.0/24, 1 successors, FD is 28160
        via Connected, FastEthernet3/0
P 10.1.4.0/24, 1 successors, FD is 28416
        via 10.1.14.4 (28416/2816), FastEthernet3/0

You recall that for routes to be redistributed, they have to be in the routing table. Therefore, on R1 you issue the show ip route command, as shown in Example 17-34, and confirm that there are routes in the routing table that should be redistributed.

Example 17-34 Verifying That Routes to Be Redistributed Are in the Routing Table

R1# show ip route
...output omitted...
      10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C        10.1.1.0/24 is directly connected, GigabitEthernet0/0
L        10.1.1.1/32 is directly connected, GigabitEthernet0/0
D        10.1.4.0/24 [90/28416] via 10.1.14.4, 02:05:59, FastEthernet3/0
C        10.1.12.0/24 is directly connected, GigabitEthernet1/0
L        10.1.12.1/32 is directly connected, GigabitEthernet1/0
C        10.1.14.0/24 is directly connected, FastEthernet3/0
L        10.1.14.1/32 is directly connected, FastEthernet3/0
O        10.1.23.0/24 [110/2] via 10.1.12.2, 02:02:11, GigabitEthernet1/0
      192.0.2.0/32 is subnetted, 1 subnets
O E2     192.0.2.1 [110/1] via 10.1.12.2, 01:03:22, GigabitEthernet1/0

Next, you review the redistribute command configured on R1 for the EIGRP process by using the show run | section router eigrp command, as shown in Example 17-35. You notice the command redistribute ospf 1; however, you quickly realize that the metric is missing. The metric is mandatory with EIGRP. If you fail to specify one with the default-metric command, with the metric command, or in a route map, the routes to be redistributed will be unreachable and not redistributed. You have located the issue.

Example 17-35 Verifying the redistribute Command on R1

R1# show run | section router eigrp
router eigrp 100
 network 10.1.14.1 0.0.0.0
 redistribute ospf 1
ipv6 router eigrp 100
 redistribute ospf 1 metric 100000 100 255 1 1500 include-connected

To solve the issue, you reissue the redistribute ospf 1 command with the metric values 100000 100 255 1 1500. You then issue the show ip eigrp topology command, as shown in Example 17-36, and confirm that routes are now redistributed.

Example 17-36 Verifying That Routes to Be Redistributed Are in the R1 Topology Table

R1# show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(10.1.14.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 10.1.12.0/24, 1 successors, FD is 51200
        via Redistributed (51200/0)
P 10.1.14.0/24, 1 successors, FD is 28160
        via Connected, FastEthernet3/0
P 10.1.23.0/24, 1 successors, FD is 51200
        via Redistributed (51200/0)
P 10.1.4.0/24, 1 successors, FD is 28416
        via 10.1.14.4 (28416/2816), FastEthernet3/0
P 192.0.2.1/32, 1 successors, FD is 51200
        via Redistributed (51200/0)
P 10.1.1.0/24, 1 successors, FD is 51200
        via Redistributed (51200/0)

Using the show ip route command on Branch, as shown in Example 17-37, allows you to conclude that the problem is solved because there are now external EIGRP routes learned by Branch, and users can successfully connect to resources outside the Branch office.

Example 17-37 Verifying That Routes to Be Redistributed Are in the Branch Routing Table

Branch# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D EX     10.1.1.0/24 [170/614400] via 10.1.14.1, 00:02:58, FastEthernet1/0
C        10.1.4.0/24 is directly connected, GigabitEthernet0/0
L        10.1.4.4/32 is directly connected, GigabitEthernet0/0

D EX     10.1.12.0/24 [170/614400] via 10.1.14.1, 00:02:58, FastEthernet1/0
C        10.1.14.0/24 is directly connected, FastEthernet1/0
L        10.1.14.4/32 is directly connected, FastEthernet1/0
D EX     10.1.23.0/24 [170/614400] via 10.1.14.1, 00:02:58, FastEthernet1/0
      192.0.2.0/32 is subnetted, 1 subnets
D EX     192.0.2.1 [170/614400] via 10.1.14.1, 00:02:58, FastEthernet1/0

Trouble Ticket 17-2

Problem: Users in the 10.1.23.0/24 network indicate that they are not able to access resources in the 10.1.4.0/24 network.

You begin troubleshooting by verifying the problem on R2. You issue a ping to 10.1.4.4 from 10.1.23.2, but it fails, as shown in Example 17-38. Because R2 is not able to ping the destination network, you confirm that the clients in 10.1.23.0/24 are not able to connect with resources in 10.1.4.0/24.

Example 17-38 Verifying the Problem from R2

R2# ping 10.1.4.4 source 10.1.23.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.4.4, timeout is 2 seconds:
Packet sent with a source address of 10.1.23.2
.....
Success rate is 0 percent (0/5)

On R2, you decide to issue a traceroute to help identify where the issue might be. The trace to 10.1.4.4 from 10.1.23.2, as shown in Example 17-39, is headed toward 203.0.113.2, which is out interface GigabitEthernet 2/0, as confirmed in the output of show ip interface brief in Example 17-40.

Example 17-39 Issuing a Trace to Identify Where the Issue Might Be

R2# traceroute 10.1.4.4 source 10.1.23.2
Type escape sequence to abort.
Tracing the route to 10.1.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 203.0.113.2 28 msec 44 msec 32 msec
  2 * * *
...output omitted...

Example 17-40 Verifying Interface IP Addresses

R2# show ip interface brief
Interface            IP-Address   OK? Method Status                Protocol
Ethernet0/0          unassigned   YES NVRAM  administratively down down
GigabitEthernet0/0   10.1.12.2    YES NVRAM  up                    up
GigabitEthernet1/0   10.1.23.2    YES NVRAM  up                    up
GigabitEthernet2/0   203.0.113.1  YES NVRAM  up                    up

Next, you decide to issue the show ip route 10.1.4.4 command on R2, and the result, as shown in Example 17-41, is that the subnet is not in the table.

Example 17-41 Verifying the Route on R2

R2# show ip route 10.1.4.4
% Subnet not in table

You shift your attention to R1 and issue the show ip route 10.1.4.4 command, as shown in Example 17-42, and the result indicates that 10.1.4.4 is reachable using EIGRP out interface FastEthernet 3/0. In addition, based on the topology, it should be redistributed into the OSPF process for the OSPF domain to have routes to it. Based on Example 17-42, it is being redistributed into OSPF process 1.

Example 17-42 Verifying the Route on R1

R1# show ip route 10.1.4.4
Routing entry for 10.1.4.0/24
  Known via "eigrp 100", distance 90, metric 28416, type internal
  Redistributing via eigrp 100, ospf 1
  Last update from 10.1.14.4 on FastEthernet3/0, 2d14h ago
  Routing Descriptor Blocks:
  * 10.1.14.4, from 10.1.14.4, 2d14h ago, via FastEthernet3/0
      Route metric is 28416, traffic share count is 1
      Total delay is 110 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

You double-check the OSPF database on R1, as shown in Example 17-43, and notice that 10.1.4.0 is not listed as an external Type 5 LSA. This means that it is not being successfully redistributed into the OSPF process.

Example 17-43 Verifying the OSPF database on R1

R1# show ip ospf database

            OSPF Router with ID (10.1.14.1) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#        Checksum Link count
10.1.14.1       10.1.14.1       1698        0x8000007D  0x0064CD 2
203.0.113.1     203.0.113.1     1274        0x80000084  0x005972 2

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#        Checksum
10.1.12.2       203.0.113.1     1274        0x8000007C  0x0010FE

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#        Checksum Tag
192.0.2.1       203.0.113.1     1274        0x8000007C  0x00FD38 0

You issue the show run | section router ospf command on R1 to verify the OSPF configuration on R1. As shown in Example 17-44, the redistribute eigrp 100 command is listed in the configuration. However, as you discovered earlier, the EIGRP routes are not being redistributed. You double-check to make sure the correct EIGRP autonomous system is being redistributed by issuing the show run | section router eigrp command, as shown in Example 17-45. This output confirms that the correct EIGRP autonomous system is being redistributed.

Example 17-44 Verifying the OSPF Configuration on R1

R1# show run | section router ospf
router ospf 1
 redistribute eigrp 100
 network 10.1.1.1 0.0.0.0 area 0
 network 10.1.12.1 0.0.0.0 area 0
ipv6 router ospf 1
 redistribute eigrp 100 include-connected

Example 17-45 Verifying the EIGRP Configuration on R1

R1# show run | section router eigrp
router eigrp 100
 network 10.1.14.1 0.0.0.0
 redistribute ospf 1 metric 100000 100 255 1 1500
ipv6 router eigrp 100
 redistribute ospf 1 metric 100000 100 255 1 1500 include-connected

After some thought, you realize that the 10.1.4.0/24 network is a classless network and that the current redistribute eigrp 100 command redistributes only classful networks. You need to add the subnets keyword to the redistribute command, as shown in Example 17-46, to redistribute classless networks. By issuing the show ip ospf database command, as shown in Example 17-47, you confirm that the OSPF database is now learning the EIGRP route 10.1.4.0/24.

Example 17-46 Adding the subnets Keyword to the redistribute Command

R1# config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# router ospf 1
R1(config-router)# redistribute eigrp 100 subnets

Example 17-47 Verifying That the 10.1.4.0 Route Is in the OSPF Database on R1

R1# show ip ospf database

            OSPF Router with ID (10.1.14.1) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#        Checksum Link count
10.1.14.1       10.1.14.1       1698        0x8000007D  0x0064CD 2
203.0.113.1     203.0.113.1     1274        0x80000084  0x005972 2

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#        Checksum
10.1.12.2       203.0.113.1     1274        0x8000007C  0x0010FE

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#        Checksum Tag
10.1.4.0        10.1.14.1       17          0x80000001  0x006215 0
10.1.14.0       10.1.14.1       17          0x80000001  0x00F379 0
192.0.2.1       203.0.113.1     1923        0x8000007C  0x00FD380

Next, you visit R2 and issue the show ip route 10.1.4.4 command and confirm that the route has been added, as shown in Example 17-48.

Example 17-48 Verifying That R2 Now Knows About the 10.1.4.0 Network

R2# show ip route 10.1.4.4
Routing entry for 10.1.4.0/24
 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1
 Redistributing via bgp 65500
 Advertised by bgp 65500 match internal external 1 & 2
 Last update from 10.1.12.1 on GigabitEthernet0/0, 00:04:52 ago
 Routing Descriptor Blocks:
 * 10.1.12.1, from 10.1.14.1, 00:04:52 ago, via GigabitEthernet0/0
     Route metric is 20, traffic share count is 1

Finally, you confirm that the problem is solved with a ping from 10.1.23.2 to 10.1.4.4, and it is successful, as shown in Example 17-49.

Example 17-49 Successful Ping

R2# ping 10.1.4.4 source 10.1.23.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.4.4, timeout is 2 seconds:
Packet sent with a source address of 10.1.23.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/55/72 ms

Trouble Ticket 17-3

Problem: IPv6 users in the 2001:db8:0:4::/64 network report that they are not able to access resources in the 2001:db8:0:1::/64 network.

You begin troubleshooting by confirming the problem on Branch. As shown in Example 17-50, the ping from 2001:db8:0:4::4 to 2001:db8:0:1::1 fails.

Example 17-50 Confirming the Problem with a Ping

Branch# ping 2001:db8:0:1::1 source 2001:db8:0:4::4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:1::1, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:0:4::4
.....
Success rate is 0 percent (0/5)

While gathering further information, you decide to ping an IPv6 address in the 2001:db8:0:23::/64 network. As shown in Example 17-51, the ping is successful. Therefore, you conclude that only some of the routes in the IPv6 OSPF domain are being redistributed into the IPv6 EIGRP domain. You issue the show ipv6 route command on Branch, as shown in Example 17-52, and the output confirms that only two external routes are being learned by Branch: 2001:db8:0:23::/64 and 2001:db8:f::/64.

Example 17-51 Gathering More Information with a Ping

Branch# ping 2001:db8:0:23::2 source 2001:db8:0:4::4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:23::2, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:0:4::4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/47/120 ms

Example 17-52 Verifying Routes on Branch

Branch# show ipv6 route
...output omitted...
C   2001:DB8:0:4::/64 [0/0]
     via GigabitEthernet0/0, directly connected
L   2001:DB8:0:4::4/128 [0/0]
     via GigabitEthernet0/0, receive
C   2001:DB8:0:14::/64 [0/0]
     via FastEthernet1/0, directly connected
L   2001:DB8:0:14::4/128 [0/0]
     via FastEthernet1/0, receive
EX  2001:DB8:0:23::/64 [170/614400]
     via FE80::C801:AFF:FE88:54, FastEthernet1/0
EX  2001:DB8:F::/64 [170/614400]
     via FE80::C801:AFF:FE88:54, FastEthernet1/0
L   FF00::/8 [0/0]
     via Null0, receive

Based on the information you have gathered, you decide to check whether redistribution is being performed on R1. You issue the show ipv6 protocols command on R1, as shown in Example 17-53. In the output, you focus on the EIGRP section and review the redistribution information. It clearly indicates that redistribution from OSPF process 1 into EIGRP autonomous system 100 is occurring. In addition, the metric values have been applied (which is mandatory for redistribution into EIGRP), and internal and external routes are being redistributed. You think that a route map might be controlling the routes that are being redistributed. However, you notice that a route map is not listed under the Redistribution section of the show ipv6 protocols command. Therefore, that is not the issue.

Example 17-53 Verifying IPv6 Redistribution on R1

R1# show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "ND"
IPv6 Routing Protocol is "eigrp 100"
EIGRP-IPv6 Protocol for AS(100)
  Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  NSF-aware route hold timer is 240
  Router-ID: 10.1.14.1
  Topology : 0 (base)
    Active Timer: 3 min
    Distance: internal 90 external 170
    Maximum path: 16
    Maximum hopcount 100
    Maximum metric variance 1
 Interfaces:
    FastEthernet3/0
  Redistribution:
    Redistributing protocol ospf 1 with metric 100000 100 255 1 1500 (internal,
external 1 & 2, nssa-external 1 & 2)
IPv6 Routing Protocol is "ospf 1"
  Router ID 10.1.14.1
  Autonomous system boundary router
  Number of areas: 1 normal, 0 stub, 0 nssa
  Interfaces (Area 0):
    GigabitEthernet1/0
    GigabitEthernet0/0
  Redistribution:
    Redistributing protocol eigrp 100 include-connected

On R1, you issue the show ipv6 eigrp topology command to confirm whether the routes are being redistributed into EIGRP from OSPF. As shown in Example 17-54, only the routes 2001:db8:0:23::/64 and 2001:db8:f::/64 are being redistributed.

Example 17-54 Reviewing R1’s EIGRP Topology

R1# show ipv6 eigrp topology
EIGRP-IPv6 Topology Table for AS(100)/ID(10.1.14.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 2001:DB8:0:4::/64, 1 successors, FD is 28416
        via FE80::C800:CFF:FEE4:1C (28416/2816), FastEthernet3/0
P 2001:DB8:F::/64, 1 successors, FD is 51200
        via Redistributed (51200/0)
P 2001:DB8:0:14::/64, 1 successors, FD is 28160
        via Connected, FastEthernet3/0
P 2001:DB8:0:23::/64, 1 successors, FD is 51200
        via Redistributed (51200/0)

You check the output of show ipv6 route on R1 and note that 2001:db8:0:1::/64 and 2001:db8:0:12::/64 are both in R1’s routing table as connected routes, as shown in Example 17-55. Therefore, for them to be redistributed, they either have to be redistributed as connected routes or participating in the OSPF process because R1 is configured to redistribute OSPF into EIGRP. Therefore, on R1, you issue the show ipv6 ospf interface brief command, as shown in Example 17-56, and confirm that both Gig0/0 and Gig1/0 are participating in the OSPF process. However, based on your information gathering so far, you have determined that the routes are still not being redistributed.

Example 17-55 Reviewing R1’s IPv6 Routing Table

R1# show ipv6 route
...output omitted...
C   2001:DB8:0:1::/64 [0/0]
     via GigabitEthernet0/0, directly connected
L   2001:DB8:0:1::1/128 [0/0]
     via GigabitEthernet0/0, receive
D   2001:DB8:0:4::/64 [90/28416]
     via FE80::C800:CFF:FEE4:1C, FastEthernet3/0
C   2001:DB8:0:12::/64 [0/0]
     via GigabitEthernet1/0, directly connected
L   2001:DB8:0:12::1/128 [0/0]
     via GigabitEthernet1/0, receive
C   2001:DB8:0:14::/64 [0/0]
     via FastEthernet3/0, directly connected
L   2001:DB8:0:14::1/128 [0/0]
     via FastEthernet3/0, receive
O   2001:DB8:0:23::/64 [110/2]
     via FE80::C802:AFF:FE88:8, GigabitEthernet1/0
OE2 2001:DB8:F::/64 [110/1]
     via FE80::C802:AFF:FE88:8, GigabitEthernet1/0
L   FF00::/8 [0/0]
     via Null0, receive

Example 17-56 Reviewing R1’s IPv6 OSPF Interfaces

R1# show ipv6 ospf interface brief
Interface  PID   Area  Intf ID   Cost State Nbrs F/C
Gi1/0      1     0     4         1    BDR   1/1
Gi0/0      1     0     3         1    DR    0/0

At this point, you recall that IPv6 redistribution behaves differently from IPv4 redistribution with directly connected networks. IPv6 directly connected networks are not redistributed by default. You need to use the include-connected keyword to force the directly connected networks to be redistributed. By reviewing the Redistribution section in the show ipv6 protocols output of Example 17-53 again, you confirm that the include-connected keyword was not included in the command.

On R1, you issue the command redistribute ospf 1 metric 100000 100 255 1 1500 include-connected in IPv6 EIGRP configuration mode, as shown in Example 17-57, to fix the issue.

Example 17-57 Modifying the redistribute Command

R1# config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# ipv6 router eigrp 100
R1(config-rtr)# redistribute ospf 1 metric 100000 100 255 1 1500 include-connected

You reissue the show ipv6 protocols command and the show ipv6 eigrp topology command and confirm that the directly connected routes are now being redistributed, as shown in Example 17-58.

Example 17-58 Verifying That Routes Are Redistributed After Changes

R1# show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "ND"
IPv6 Routing Protocol is "eigrp 100"
EIGRP-IPv6 Protocol for AS(100)
  Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
...output omitted...
  Redistribution:
    Redistributing protocol ospf 1 with metric 100000 100 255 1 1500 (internal,
external 1 & 2, nssa-external 1 & 2) include-connected
...output omitted...

R1# show ipv6 eigrp topology
EIGRP-IPv6 Topology Table for AS(100)/ID(10.1.14.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 2001:DB8:0:4::/64, 1 successors, FD is 28416
        via FE80::C800:CFF:FEE4:1C (28416/2816), FastEthernet3/0
P 2001:DB8:0:1::/64, 1 successors, FD is 51200
        via Redistributed (51200/0)
P 2001:DB8:F::/64, 1 successors, FD is 51200
        via Redistributed (51200/0)
P 2001:DB8:0:14::/64, 1 successors, FD is 28160
        via Connected, FastEthernet3/0
P 2001:DB8:0:12::/64, 1 successors, FD is 51200
        via Redistributed (51200/0)
P 2001:DB8:0:23::/64, 1 successors, FD is 51200
        via Redistributed (51200/0)

Going back to Branch, you issue the show ipv6 route command and notice that there are entries in the routing table for 2001:db8:0:1::/64 and 2001:db8:0:12::/64 now, as shown in Example 17-59.

Example 17-59 Verifying That Routes Are Learned by Branch

Branch# show ipv6 route
IPv6 Routing Table - default - 9 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
     B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
     I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
     EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
     NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
     OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
EX   2001:DB8:0:1::/64 [170/614400]
      via FE80::C801:AFF:FE88:54, FastEthernet1/0
C    2001:DB8:0:4::/64 [0/0]
      via GigabitEthernet0/0, directly connected
L    2001:DB8:0:4::4/128 [0/0]
      via GigabitEthernet0/0, receive
EX   2001:DB8:0:12::/64 [170/614400]
      via FE80::C801:AFF:FE88:54, FastEthernet1/0
C    2001:DB8:0:14::/64 [0/0]
      via FastEthernet1/0, directly connected
L    2001:DB8:0:14::4/128 [0/0]
      via FastEthernet1/0, receive
EX   2001:DB8:0:23::/64 [170/614400]
      via FE80::C801:AFF:FE88:54, FastEthernet1/0
EX   2001:DB8:F::/64 [170/614400]
      via FE80::C801:AFF:FE88:54, FastEthernet1/0
L    FF00::/8 [0/0]
      via Null0, receive

You verify that the problem is solved with a ping from Branch at 2001:db8:0:4::4 to 2001:db8:0:1::1, as shown in Example 17-60. The ping is successful, and the problem is solved.

Example 17-60 Verifying That the Problem Is Solved with a Successful Ping

Branch# ping 2001:db8:0:1::1 source 2001:db8:0:4::4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:1::1, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:0:4::4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/32/44 ms

Trouble Ticket 17-4

Problem: A junior administrator has approached you, asking for help. He claims that users in BGP autonomous system 65500 are unable to access IPv4 resources in the IPv4 EIGRP autonomous system 100. However, they can access resources in the OSPFv2 domain. Because access to routers in BGP autonomous system 65500 is limited to only R2, the junior administrator has asked you for help.

You start by reviewing Figure 17-11 to confirm which local router is running BGP. It is R2. You issue the show bgp ipv4 unicast summary command on R2 to confirm whether R2 has any BGP neighbors. As shown in Example 17-61, 203.0.113.2 is listed as a neighbor, and because the State/PfxRcd column has a number, it is an established neighborship. To further confirm, you issue the show bgp ipv4 unicast neighbors | include BGP command, as shown in Example 17-62, and the output indicates that 203.0.113.2 is an established neighbor.

Example 17-61 Verifying BGP Neighbors

R2# show bgp ipv4 unicast summary
BGP router identifier 203.0.113.1, local AS number 65500
BGP table version is 33, main routing table version 33
4 network entries using 576 bytes of memory
4 path entries using 320 bytes of memory
3/3 BGP path/bestpath attribute entries using 408 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1304 total bytes of memory
BGP activity 28/18 prefixes, 30/20 paths, scan interval 60 secs

Neighbor      V   AS    MsgRcvd MsgSent TblVer InQ OutQ Up/Down  State/PfxRcd
203.0.113.2   4   65500 496     500     33     0   0    07:26:42        1

Example 17-62 Verifying an Established BGP Neighbor

R2# show bgp ipv4 unicast neighbors | include BGP
BGP neighbor is 203.0.113.2, remote AS 65500, internal link
  BGP version 4, remote router ID 192.0.2.1
  BGP state = Established, up for 07:31:19
  BGP table version 33, neighbor version 33/0
  Last reset 07:31:29, due to BGP Notification received of session 1, header syn-
chronization problems

Next, you verify whether any routes are being advertised to the neighbor at 203.0.113.2 by issuing the show bgp ipv4 unicast neighbors 203.0.113.2 advertised-routes command. In Example 17-63, you can see that three routes are being advertised to 203.0.113.2 from R2. The routes are 10.1.1.0/24, 10.1.12.0/24, and 10.1.23.0/24. Figure 17-11 indicates that the EIGRP networks are 10.1.14.0/24 and 10.1.4.0/24 and that they are not listed as routes being advertised.

Example 17-63 Verifying Advertised BGP Routes

R2# show bgp ipv4 unicast neighbors 203.0.113.2 advertised-routes
BGP table version is 33, local router ID is 203.0.113.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

      Network        Next Hop    Metric    LocPrf     Weight    Path
 *>   10.1.1.0/24    10.1.12.1        2                         32768 ?
 *>   10.1.12.0/24   0.0.0.0          0                         32768 ?
 *>   10.1.23.0/24   0.0.0.0          0                         32768 ?

Total number of prefixes 3

You issue the show ip protocols command on R2, as shown in Example 17-64, to verify the BGP configuration. You notice that there are no filters, no distribute lists, and no route maps applied to neighbor 203.0.113.2 that could be preventing routes from being advertised. However, you notice that only OSPF internal routes are being redistributed in the output. You issue the show ip route command on R2, as shown in Example 17-65, and confirm that 10.1.4.0/24 and 10.1.14.0/24 are both external OSPF routes. You conclude that the problem is related to BGP not redistributing OSPF external routes.

Example 17-64 Verifying BGP Configuration with show ip protocols

R2# show ip protocols
*** IP Routing is NSF aware ***
...output omitted...
Routing Protocol is "bgp 65500"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  IGP synchronization is disabled
  Automatic route summarization is disabled
  Redistributing: ospf 1 (internal)

  Neighbor(s):
    Address         FiltIn FiltOut DistIn DistOut Weight RouteMap
    203.0.113.2
  Maximum path: 1
  Routing Information Sources:
    Gateway         Distance    Last Update
    203.0.113.2     200         07:54:48
  Distance: external 20 internal 200 local 200

Example 17-65 Verifying IPv4 Routes on R2

R2# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
      ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is 203.0.113.2 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 203.0.113.2
      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
O        10.1.1.0/24 [110/2] via 10.1.12.1, 4d20h, GigabitEthernet0/0
O E2     10.1.4.0/24 [110/20] via 10.1.12.1, 1d23h, GigabitEthernet0/0
C        10.1.12.0/24 is directly connected, GigabitEthernet0/0
L        10.1.12.2/32 is directly connected, GigabitEthernet0/0
O E2     10.1.14.0/24 [110/20] via 10.1.12.1, 1d23h, GigabitEthernet0/0
C        10.1.23.0/24 is directly connected, GigabitEthernet1/0
L        10.1.23.2/32 is directly connected, GigabitEthernet1/0
      192.0.2.0/32 is subnetted, 1 subnets
B        192.0.2.1 [200/0] via 203.0.113.2, 08:00:48
      203.0.113.0/24 is variably subnetted, 2 subnets, 2 masks
C        203.0.113.0/29 is directly connected, GigabitEthernet2/0
L        203.0.113.1/32 is directly connected, GigabitEthernet2/0

On R2, you issue the show run | section router bgp command, as shown in Example 17-66, to verify the BGP configuration. Under the IPv4 address family, you notice that the redistribute ospf 1 command has been issued. However, that only redistributes internal OSPF routes. It does not redistribute OSPF external routes by default.

Example 17-66 Verifying BGP configuration on R2

R2# show run | section router bgp
router bgp 65500
 bgp log-neighbor-changes
 neighbor 2001:DB8:0:A::A remote-as 65500
 neighbor 203.0.113.2 remote-as 65500
 !
 address-family ipv4
  bgp redistribute-internal
  redistribute ospf 1
  no neighbor 2001:DB8:0:A::A activate
  neighbor 203.0.113.2 activate
 exit-address-family
 !
 address-family ipv6
  redistribute ospf 1 match internal external 1 external 2 include-connected
  bgp redistribute-internal
  neighbor 2001:DB8:0:A::A activate
 exit-address-family

Because the routes are external Type 2 OSPF routes, you issue the command redistribute ospf 1 match internal external 2 in IPv4 BGP address family configuration mode, as shown in Example 17-67. You then issue the command show ip protocols to verify that external Type 2 routes are now being redistributed as well. As shown in Example 17-68, they are.

Example 17-67 Modifying the redistribute Command in IPv4 Address Family Configuration Mode

R2# config t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# router bgp 65500
R2(config-router)# address-family ipv4 unicast
R2(config-router-af)# redistribute ospf 1 match internal external 2

Example 17-68 Verifying the Types of OSPF Routes Being Advertised into BGP

R2# show ip protocols
...output omitted...
Routing Protocol is "bgp 65500"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  IGP synchronization is disabled
  Automatic route summarization is disabled
  Redistributing: ospf 1 (internal, external 2)

  Neighbor(s):
    Address            FiltIn FiltOut DistIn DistOut Weight RouteMap
    203.0.113.2
  Maximum path: 1
  Routing Information Sources:
    Gateway         Distance     Last Update
    203.0.113.2     200         1d07h
  Distance: external 20 internal 200 local 200

You then reissue the show bgp ipv4 unicast neighbors 203.0.113.2 advertised-routes command to verify that 10.1.14.0/24 and 10.1.4.0/24 are being advertised in BGP autonomous system 65500. As shown in Example 17-69, they are.

Example 17-69 Verifying That OSPF Routes Are Advertised to the BGP Neighbor

R2# show bgp ipv4 unicast neighbors 203.0.113.2 advertised-routes
BGP table version is 35, local router ID is 203.0.113.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

 Network            Next Hop       Metric LocPrf Weight Path
 *> 10.1.1.0/24     10.1.12.1           2               32768 ?
 *> 10.1.4.0/24     10.1.12.1          20               32768 ?
 *> 10.1.12.0/24    0.0.0.0 0                           32768 ?
 *> 10.1.14.0/24    10.1.12.1          20               32768 ?
 *> 10.1.23.0/24    0.0.0.0 0                           32768 ?

Total number of prefixes 5

Next, you pick up the phone and call the administrator of the other routers in BGP autonomous system 65500 and confirm that those users can access the resources in EIGRP autonomous system 100. He states that they can; therefore, you have solved the issue.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple choices for exam preparation: the exercises here, Chapter 24, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep software. The questions that follow present a bigger challenge than the exam itself because they use an open-ended question format. By using this more difficult format, you can exercise your memory better and prove your conceptual and factual knowledge of this chapter. You can find the answers to these questions in the appendix.