Resolving Problems at the Network Layer

You learned in Chapter 9, "Isolating a Problem at the Network Layer," that common and possible symptoms of network layer problems include the following:

■ On the failing link, no component appears to be functional above the network layer.

■ The network is operating, but it is operating either consistently or intermittently below the baseline level.

■ The transport layer cannot transfer data or achieve connectivity.

■ Routing tables are empty, inconsistent, or incomplete.

■ Routing behavior is unexpected.

■ Packets are not delivered/forwarded to correct destinations; pings are either fully or partially unsuccessful.

■ Console, system log, or management system alarms indicate failures/problems.

Chapter 9 lists some valuable Cisco IOS commands that you can use to isolate network layer problems, such as routing issues. A few examples of such commands follow.

The following command displays a summary of router interfaces, along with their IP address and status:

show ip interface [brief] The following command displays the current content of the IP routing table: show ip route

The following command displays useful information about the active IP routing protocols:

show ip protocols The following command displays the content of the BGP table: show ip bgp

The following command lists the neighbors of the local router's BGP process, along with some information about each one of those neighbors, such as the status of their neighbor relationship with the local BGP router:

show ip bgp summary

The following command builds and displays the current configuration of the local router in text format:

show running-config

To practice using the guidelines and commands for isolating problems at the network layer, consider that you have been given a troubleshooting assignment. The assignment is based on the network diagram depicted in Figure 13-4.

Figure 13-4 Network Diagram of eBGP Relations Among Autonomous Systems 111, 222, 77, and 21

Figure 13-4 Network Diagram of eBGP Relations Among Autonomous Systems 111, 222, 77, and 21

Users in autonomous system 21 have reported that they can no longer access resources in network 198.133.219.0. Using the Cisco IOS show ip route command, examine the content of Columbia, Baltimore, and Washington routers' routing table and notice that neither of those routers has the prefix 198.133.219.0 in its routing table. Knowing that Washington is supposed to learn the route from its external BGP neighbor (Lenexa) in autonomous system 77, examine the content of Washington router's BGP table and see if the prefix is present. You can display the IP routing table by using the command show ip route, and you can display the BGP table by using the show ip bgp command. The results are displayed in Example 13-7.

Example 13-7 Content of Washington Router's BGP Table

Washington#show ip route

Codes: C - connected, S - static, I - IGRP, 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, E - EGP i - IS-IS, 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

Gateway of last resort is not set

172.17.0.0 255.255.255.255 is subnetted, 2 subnets C 172.17.12.3 is directly connected, Loopback0

S 172.17.12.2 is directly connected, Serial0/0.1

B 77.0.0.0 255.0.0.0 [20/0] via 172.17.12.2, 00:00:42

Washington#show ip bgp

BGP table version is 3, local router ID is 172.17.12.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

Network *> 21.0.0.0 *> 77.0.0.0 * 198.133.219.0

Washington#

Metric LocPrf Weight Path 0 32768 ?

When you examine Washington router's BGP table, you notice that the prefix 198.133.219.0 is present in the BGP table. However, when you examined Washington's IP routing table, the entry was not present. In the BGP table, you notice that the entry for 198.133.219.0 does not have a > sign behind it; in other words, the entry is not chosen as a best route. Now you understand why the route was not offered to the IP routing table and hence, it was not installed in Washington's IP routing table.

You are curious to find out why BGP still doesn't mark 198.133.219.0 as the best route even though it has only one path to it. You think of BGP's path selection process and recall that the first step in BGP's path selection states that the next-hop value of a prefix must be reachable. The next-hop value of 172.17.12.1 on the 198.133.219.0 entry is not reachable from Washington, and that explains why this entry is not selected as a best route by BGP and is not offered to IP. Example 13-8 shows the result of issuing a ping. As you can see, Washington can ping Lenexa's address (172.17.12.2), but it cannot ping 172.17.12.1, which is the next-hop value on the route (198.133.219.0) received from Lenexa via eBGP.

Example 13-8 Results of Testing Reachability of BGP Next-Hop Values from Washington

Washington#ping 172.17.12.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to !!!!!

172.17

12.2

timeout is

2

seconds:

Success rate is 100 percent (5/5)

round

trip

min/avg/max

=

60/71/100 ms

Washington#ping 172.17.12.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to

172.17

12.1

timeout is

2

seconds:

Success rate is 0 percent (0/5)

Washington#

Finally, you ask yourself why the Washington router's eBGP neighbor (Lenexa) in autonomous system 77 is not attaching its own address on the next-hop attribute of the 198.133.219.0 prefix when it sends the update toward Washington. When you notice that the router learned the route from another eBGP neighbor over Frame Relay, you remember that not altering the next-hop in this case (over multiaccess network) is the normal behavior. To change this behavior and effectively rectify the problem at hand, the administrator of Washington router's eBGP neighbor (Lenexa in autonomous system 77) must manually force the next-hop value to be replaced by its own IP address (using the BGP configuration command neighbor address next-hop-self). The alternative solution is to enter a static route for 172.17.12.1 in the Washington router (via its Frame Relay serial interface) and effectively make that address reachable on Washington. The network layer problem is isolated. You must now document and report the isolated network layer problem and the possible rectification options.

0 0

Post a comment