Examples That Demonstrate Correction of Network Layer Problems
So that you can practice correcting a network layer problem that has already been isolated, this section continues and corrects the two cases that were started in the previous chapter. To refresh your memory, both cases begin with the background information.
Correcting an Access List to Stop a Router from Rejecting a Prefix Sent from a BGP Peer
You are the second-level network engineer responsible for sites in Washington, Baltimore, and Columbia. (The routers in each city are named after the city names.) The devices are arranged and connected as shown in Figure 10-2.
Figure 10-2 Network You Are Responsible For, and Connections to ISP1 and ISP2
Figure 10-2 Network You Are Responsible For, and Connections to ISP1 and ISP2
You have determined that the route 198.133.219.0/24 that belongs to Cisco Systems is not in the routing tables for any of your devices. This prefix is supposed to be in the routing table for all devices. As a result of your investigation and review of the access lists on Washington, you have discovered that the Cisco network 198.133.219.0/24 is not permitted by the access list called CIT. The access list CIT is applied to the BGP neighbors of Washington in the inbound direction using the distribution-list in command. To correct the problem, you need to expand the CIT access list to permit 198.133.219.0/24. You go into configuration mode and update the access list. (See the top of Example 10-1.) You then verify that the access list was updated. (See the bottom of Example 10-1.)
|
Washington(config)#ip access-list standard CIT | |||
|
Washington(config-std-nacl)# remark Include Cisco network as |
well | ||
|
Washington(config-std-nacl)# permit 198 |
133.219.0 0 |
0.0.255 | |
|
Washington(config-std-nacl)#exit | |||
|
Washington# | |||
|
Oct 27 14:19:48: %SYS-5-CONFIG_I: Configured from console by |
console | ||
|
Washington#show access-lists | |||
|
Standard IP access list 21 | |||
|
permit 172.28.128.7 | |||
|
permit 172.28.128.8 | |||
|
permit 172.27.227.7 | |||
|
permit 172.27.227.8 | |||
|
permit 172.22.0.0, wildcard bits 0.G |
1.255.255 | ||
|
Standard IP access list CIT | |||
|
permit 172.21.0.0, wildcard bits 0.C |
1.255.255 (4 |
matches) |
check=158 |
|
permit 172.23.0.0, wildcard bits 0.C |
1.255.255 (6 |
matches) |
check=152 |
|
permit 172.24.0.0, wildcard bits 0.C |
1.255.255 (1 |
matches) |
check=142 |
|
permit 172.25.0.0, wildcard bits 0.C |
1.255.255 (8 |
matches) |
check=134 |
|
permit 172.26.0.0, wildcard bits 0.C |
1.255.255 (8 |
matches) |
check=126 |
|
permit 198.133.219.0, wildcard bits |
0.0.0.255 | ||
|
Washington# | |||
You now check to see if the Cisco Systems route is in the BGP table on Washington. The network 198.133.219.0 is not yet present. You need to clear the BGP session when you change the inbound or outbound policy for the session. Changing the inbound access list changes the inbound policy for a BGP session. You use the debug ip routing command to watch for routing updates and then clear the BGP session with the corporate core neighbors in AS 77. (See the top of Example 10-2.) You know that the 198.133.219.0 route has been added when you see the line "RT: Nexthop for 198.133.219.0/24 updated." Now you verify that the Cisco Systems route is in the BGP table on Washington. (See the middle of Example 10-2.) You verify that the Cisco Systems address is also in the IP routing table by entering the show ip route command. (See the bottom of Example 10-2.) The 198.133.219.0 route is now present in the routing table on Washington.
Example 10-2 Output of debug ip routing, show ip bgp, and show ip route After Clearing the BGP Session
Washington#debug ip routing Washington#clear ip bgp 77
Oct 27 14:23:46: %BGP-5-ADJCHANGE: neighbor 172.27.227.7 Down User reset Oct 27 14:23:46: %BGP-5-ADJCHANGE: neighbor 172.28.128.8 Down User reset
Oct 27 14:24:05: %BGP-5-ADJCHANGE: neighbor 172.27.227.7 Up Oct 27 14:24:05.475: RT: Nexthop for 198.133.219.0/24 updated Washington#no debug all
All possible debugging has been turned off Washington#
Washington#show ip bgp
BGP table version is 38, local router ID is 172.22.129.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
198.133.219.0 172.28.128.8 0 77 222 111 i
Washington#
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
172.28.0.0/28 is subnetted, 1 subnets C 172.28.128.0 is directly connected, Vlan28
B 198.133.219.0/24 [20/0] via 172.27.227.7, 00:03:15 S* 0.0.0.0/0 [1/0] via 172.28.128.8 Washington#
As a final validation that the network layer issue has been resolved, you use the show ip route command on Baltimore and Columbia to verify that those routers also have the 198.133.219.0/24 route in their routing table (see Example 10-3). The Cisco Systems route has been restored to all your devices. You have resolved the network layer issue and restored your baseline configuration.
Example 10-3 Checking Routing Tables of Baltimore and Columbia
Baltimore> show ip route
|
D |
EX |
172 |
25.C |
5.0/16 [170/284160] via 172.22 |
128.130 |
00 |
05 |
06 |
FastEthernet0/0 |
|
D |
EX |
172 |
24.C |
5.0/16 [170/284160] via 172.22 |
128.130 |
00 |
05 |
06 |
FastEthernet0/0 |
|
D |
EX |
172 |
26.C |
5.0/16 [170/284160] via 172.22 |
128.130 |
00 |
05 |
06 |
FastEthernet0/0 |
|
D |
EX |
198 |
133 |
219.0/24 [170/284160] via 172 |
22.128. |
130, |
00 |
05 |
06, FastEthernet0/0 |
D*EX 0.0.0.0/0 [170/28416] via 172.22.128.130, 3d22h, FastEthernet0/0 Baltimore>
D*EX 0.0.0.0/0 [170/28416] via 172.22.128.130, 3d22h, FastEthernet0/0 Baltimore>
Columbia> show ip route
|
D |
EX |
172 |
25.C |
5.0/16 [170/3873280] via 172.22 |
126.2, |
00 |
06 |
48 |
Serial0/0:0 |
|
D |
EX |
172 |
24.« |
5.0/16 [170/3873280] via 172.22 |
126.2, |
00 |
06 |
48 |
Serial0/0:0 |
|
D |
EX |
172 |
26.« |
5.0/16 [170/3873280] via 172.22 |
126.2, |
00 |
06 |
48 |
Serial0/0:0 |
|
D |
EX |
198 |
133 |
219.0/24 [170/3873280] via 172 |
22.126 |
2, |
00 |
06 |
48, Serial0/0:0 |
D*EX 0.0.0.0/0 [170/3847936] via 172.22.126.2, 3d22h, Serial0/0:0 Columbia>
D*EX 0.0.0.0/0 [170/3847936] via 172.22.126.2, 3d22h, Serial0/0:0 Columbia>
Correcting a Duplicate IP Address Problem
Moving on to the second case from Chapter 9, assume that you are the second-level network engineer for the offices of a corporation that has locations in Washington, Baltimore, and Columbia. The routers at each location are named after the cities in which they reside. One day, Network Operations calls to report that it can't ping or Telnet into the access switch named Columbia_SW from Washington. Network Operations does not recall changing any of the configurations. Figure 10-3 focuses on the local devices of the network examined in the previous example.
You have determined that a duplicate IP address 172.22.121.1 exists on the FastEthernet between Columbia and Columbia_SW. You know from the baseline that Columbia should have an IP address of 172.22.121.1/26 on FastEthernet 0/0.1 and Columbia_SW should use 172.22.121.2/26. To correct the problem, Network Operations needs to modify the IP address on Columbia_SW. As a good practice, it should also restore console logging. Network Operations goes into configuration mode and tries to update the IP address on FastEthernet 0/1 on Columbia_SW. Network Operations calls you back, stating that it cannot configure the IP address on FastEthernet 0/1 because it is a switched interface (see Example 10-4).
Figure 10-3 Network Diagram Displaying the Columbia Access Router, the ColumbiaSW Access Switch, and the End Devices
Figure 10-3 Network Diagram Displaying the Columbia Access Router, the ColumbiaSW Access Switch, and the End Devices
Example 10-4 Attempt to Configure the IP Address on a Layer 2 (Switching) Interface of a Switch
Columbia_SW>enable Columbia_SW#configure terminal
Enter configuration commands, one per line. End with CNTL/Z. Columbia_SW(config)#interface fastethernet 0/1 Columbia_SW(config-if)#ip address 172.22.121.2 255.255.255.192
% IP addresses may not be configured on L2 links.
Columbia_SW(config-if)#exit Columbia_SW(config)#logging console
Oct 27 17:33:43: %IP-4-DUPADDR: Duplicate address 172.22.121.1 on Vlan901, sourced by 0007.8580.a157
You ask Network Operations to enter the show running-config interface FastEthernet 0/1 command from the Privileged Exec mode and look for the native VLAN for the 2950 switch. The results (see the top of Example 10-5) tell you that the interface FastEthernet 0/1 is a switch port in trunk mode and its native VLAN is vlan 901. You then ask Network Operations to enter the show ip interface brief command and confirm that this interface (vlan 901) is active. (See the middle of Example 10-5.) Finally, you direct Network Operations to change the IP address on the vlan 901 interface. (See the bottom of Example 10-5.)
Example 10-5 Output of show running-config and show ip interface brief commands and Changing the IP Address of a VLAN Interface
|
Columbia_SW#show running-config interface fastEthernet 0/1 | |
|
Building configuration... | |
|
Current configuration : 310 bytes ! | |
|
interface FastEthernet0/1 | |
|
switchport trunk native vlan 901 | |
|
switchport mode trunk | |
|
no ip address | |
|
duplex full | |
|
speed 100 | |
|
storm-control broadcast level 1.00 0.50 | |
|
storm-control multicast level 10.00 5.00 | |
|
storm-control unicast level 10.00 5.00 | |
|
storm-control action shutdown | |
|
storm-control action trap | |
|
end | |
|
Columbia_SW# | |
|
Columbia_SW#show ip interface brief | |
|
Interface IP-Address OK? Method Status |
Protocol |
|
Vlan1 unassigned YES manual administratively |
down down |
|
Vlan901 172.22.121.1 YES manual up |
up |
|
FastEthernet0/1 unassigned YES unset up |
up |
|
Columbia_SW# | |
|
Columbia_SW#configure terminal | |
|
Columbia_SW(config)#interface vlan901 | |
|
Columbia_SW(config-if)#ip address 172.22.121.2 255.255.255.192 | |
|
Columbia_SW(config-if)#end | |
|
Columbia_SW# | |
|
.Oct 27 17:33:58: %SYS-5-CONFIG_I: Configured from console by console | |
To test that the new configuration will work, Network Operations verifies that Columbia_SW can reach Columbia. (See the top of Example 10-6.) You then verify that Columbia and Washington routers can reach Columbia_SW. (See the bottom of Example 10-6.) The duplicate IP address has been replaced with the proper IP address. You have resolved the network layer issue and restored your baseline configuration.
Example 10-6 Verifying Connectivity Between Routers Using ping
Columbia_SW>ping Columbia Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.22.125.1, timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Columbia_SW>
Columbia>ping columbia_SW
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.22.121.2, timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Columbia>
Washington>ping columbia_sw
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.22.121.2, timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/32/36 ms Washington>
Post a comment