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.)

Example 10-1 Adding a Statement to an Existing Access List and Verifying the Access List

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>

0 0

Post a comment