CCNAExploration:AccessingtheWAN

Chapter3CaseStudy
Objectives:
Troubleshooting EIGRP Routing over Frame Relay.

Intro:
T5 is having network connectivity problems. According to the person who called you, T5 is not able to
reach networks outside their own network.

The Scenario:
T5 has two offices in USA: The main office is located in New York City and the branch office in Phoenix,
AZ. Each site has its own router called NYC and PHX, respectively. NYC and PHX are connected by a
Frame Relay circuit hired from an ISP.
The PHX router is responsible for routing packets to/from the Phoenix branch office computers and
devices while the NYC router is responsible for routing packets to/from the New York main office
computers and devices.
NYC also has a shared connection to the Internet, which is also used by Phoenix-based employees.
As mentioned before, NYC and PHX are connected via Frame Relay and use EIGRP as the routing
protocol.
T5 states the network was working fine until an equipment upgrade was done after which the technician
implemented EIGRP in the network. Since the upgrade the network has presented connectivity problems.

Topology:

2009 Cisco Learning Institute

CCNAExploration:AccessingtheWAN
Chapter3CaseStudy
Identifying the problem
Since the reports sent to you dont help, you decide to play a visit to one of T5s offices and you pick the
Phoenix office because you are located in Phoenix.
Once in the office, you go take a look at the PHX router. You connect your laptop to its console port and
gain access to it. No error messages are being displayed at the console window.
At a first glance, PHX configuration looks good: all the interfaces have correct IP addresses and are
properly configured. EIGRP configuration look ok too and the Frame Relay link seems to be up.
To ensure the link is up and running, you issue a few pings from PHX to different parts of T5s network.
Below is a summary of the pings:

PHX#ping 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
PHX#
PHX#ping 10.10.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/44/48 ms
PHX#
PHX#ping 192.168.100.27
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.27, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
PHX#

2009 Cisco Learning Institute

CCNAExploration:AccessingtheWAN
Chapter3CaseStudy
PHX#ping 192.168.200.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.200.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/45/48 ms
PHX#
PHX#ping 192.168.200.42
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.200.42, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/45/48 ms
PHX#

As the outputs above show, relevant pings issued to internal T5 addresses are all successful and,
because of that you assume the Frame Relay circuit works fine. Just to make sure, you double check the
status of the Frame Relay circuit with a show frame-relay pvc command. Below is the output of it:

PHX#sh frame-relay pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)
Active

Inactive

Deleted

Static

Local

Switched

Unused

DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/2/0
input pkts 2613

output pkts 1551

in bytes 146990

out bytes 102562

dropped pkts 0

in pkts dropped 0

out pkts dropped 0

in FECN pkts 0

out bytes dropped 0

in BECN pkts 0

2009 Cisco Learning Institute

out FECN pkts 0

CCNAExploration:AccessingtheWAN
Chapter3CaseStudy
out BECN pkts 0

in DE pkts 0

out bcast pkts 1415

out bcast bytes 90548

out DE pkts 0

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 21:50:57, last time pvc status changed 21:48:35

You also check the Frame Relay portion of the configuration file. It also looks correct:
interface Serial0/0
ip address 10.10.10.1 255.255.255.252
encapsulation frame-relay
frame-relay map ip 10.10.10.2 201 broadcast
no frame-relay inverse-arp

Question 1:
The first ping listed failed (ping 10.10.10.1). Why? Shouldnt it be considered a problem?
Answer: No, it is not a problem. 10.10.10.1 is the IP address assigned to PHXs serial 0/2/0 interface.
This interface was configured to encapsulate frames with frame-relay. Frame Relay interfaces require a
DLCI -> Layer3 address mapping before they can forward frames. While a DLCI -> destination layer3
address mapping is required for Frame Relay frame forwarding the absence of such mapping is common.
If no local mapping exists, the router is not able to ping its own frame-relay interfaces.
You issue a few pings to an address outside of T5s network:

PHX#ping cisco.com
Translating "cisco.com"...domain server (24.25.5.149)
% Unrecognized host or address, or protocol not running.
PHX#ping 198.133.219.25
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 198.133.219.25, timeout is 2 seconds:
.....

2009 Cisco Learning Institute

CCNAExploration:AccessingtheWAN
Chapter3CaseStudy
Success rate is 0 percent (0/5)
PHX#
As shown above, pings sent to cisco.com failed. In order to ensure there is no DNS problem, you resolve
the name cisco.com and ping directly the IP address associated with it but it fails as well.
You decide to check PHXs routing table to ensure EIGRP is working properly. Below is PHX routing
table:
PHX#sh ip route
Codes: 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
Gateway of last resort is not set
S

192.168.200.0/24 [1/0] via 10.10.10.2

10.0.0.0/30 is subnetted, 1 subnets

10.10.10.0 is directly connected, Serial0/0

192.168.100.0/24 is directly connected, Loopback1

PHX#

PHXs routing table makes it clear: there is no EIGRP-learnt routes in it and no default route was defined
either. The lack of proper routes keeps PHX from full connectivity.

2009 Cisco Learning Institute

CCNAExploration:AccessingtheWAN
Chapter3CaseStudy
Question 2:
If PHX has no default route why are all pings to 192.168.100.0/24 successful?
Answer: PHX has a static route to 192.168.100.0/24 via 10.10.10.2 (NYC)
You check the EIGRP configuration in PHX once more but even though everything looks good, NYC is
not listed as an EIGRP neighbor in PHX:

PHX#sh ip eigrp neighbors

IP-EIGRP neighbors for process 100
PHX#
Seems like the NYC router is causing the problem
Since the Frame Relay link is operational, you issue a telnet from PHX to NYC and log into NYC.
Because you are troubleshooting via telnet, you set NYC to print console messages on your telnet
session window as well. The command used for that is listed below:
NYC# terminal monitor
You go straight to the EIGRP configuration section within NYCs configuration file but nothing seems to
be wrong. Below is the EIGRP configuration currently present in NYC:
router eigrp 100
network 10.10.10.0 0.0.0.255
network 192.168.200.0
no auto-summary
You check NYCs EIGRP neighbors. PHX is listed as a neighbor:
NYC#sh ip eigrp neighbors
IP-EIGRP neighbors for process 100
H

Address

10.10.10.1

Interface

Se0/1/0

Hold Uptime

SRTT

(sec)

(ms)

127 00:00:52

NYC#

2009 Cisco Learning Institute

RTO

Seq

Cnt Num
5000

CCNAExploration:AccessingtheWAN
Chapter3CaseStudy
Even though PHX shows up as a neighbor, EIGRP neighbor state between NYC and PHX is not stable, it
flaps. While logged into NYC, you are able to see many messages about PHX: NYC tries to establish
adjacency with PHX but looses it right after. The messages are shown below:

NYC#
*Jun 10 22:41:25.498: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.10.10.1
(Serial0/1/0) is up: new adjacency
*Jun 10 22:44:30.010: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.10.10.1
(Serial0/1/0) is down: retry limit exceeded
*Jun 10 22:45:06.546: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.10.10.1
(Serial0/1/0) is up: new adjacency
You decide to take a look at the Frame Realy circuit to ensure it was properly configured in NYC. The
current Frame Relay configuration is shown below:
interface Serial0/1/0
ip address 10.10.10.2 255.255.255.252
encapsulation frame-relay
no fair-queue
frame-relay map ip 10.10.10.1 102
no frame-relay inverse-arp

The Frame Relay configuration in NYC reveals the problem: there is no broadcast present in the framerelay map command!
Frame Relay is a non-broadcast environment but a protocol like EIGRP relies on multicast packets to
work. Because the broadcast keyword is missing, no broadcast or multicast packets were being sent
through the Frame Relay circuit from NYC to PHX.
Since NYC couldnt send multicast EIGRP hello packets to PHX, PHX never establish EIGRP adjacency
with NYC.
On the other hand, PHX was properly configured with the broadcast keyword and was sending multicast
EIGRP hellos to NYC but since no answer came from NYC, PHX reset the adjacency and tried again,
starting the process over.
You add the missing keyword in NYC and watch EIGRP adjacency being established. The command and
console messages are listed below:

2009 Cisco Learning Institute

CCNAExploration:AccessingtheWAN
Chapter3CaseStudy
NYC#conf t
Enter configuration commands, one per line.

End with CNTL/Z.

NYC(config)#int se 0/1/0
NYC(config-if)#frame-relay map ip 10.10.10.1 102 broadcast
NYC(config-if)#^Z
NYC#
NYC#
NYC#
*Jun 10 23:04:09.158: %SYS-5-CONFIG_I: Configured from console by cisco on
console
*Jun 10 23:04:22.286:
incoming UPDATE packet

IP-EIGRP(Default-IP-Routing-Table:100):

Processing

*Jun 10 23:04:25.442:
incoming UPDATE packet

IP-EIGRP(Default-IP-Routing-Table:100):

Processing

*Jun
10
23:04:25.442:
IP-EIGRP(Default-IP-Routing-Table:100):
192.168.100.0/24 M 2297856 - 1657856 640000 SM 128256 - 256 128000

Int

*Jun 10 23:04:25.442: IP-EIGRP(Default-IP-Routing-Table:100): route installed

for 192.168.100.0 ()
*Jun 10 23:04:25.450: IP-EIGRP(Default-IP-Routing-Table:100): 10.10.10.0/30 do advertise out Serial0/1/0
*Jun
10
23:04:25.450:
IP-EIGRP(Default-IP-Routing-Table:100):
192.168.200.0/24 - do advertise out Serial0/1/0
*Jun
10
23:04:25.450:
IP-EIGRP(Default-IP-Routing-Table:100):
192.168.200.0/24 metric 128256 - 256 128000

Int

*Jun
10
23:04:25.490:
IP-EIGRP(Default-IP-Routing-Table:100):
192.168.100.0/24 metric 2297856 - 1657856 640000

Int

*Jun
10
23:06:41.350:
IP-EIGRP(Default-IP-Routing-Table:100):
200.200.200.0/24 - do advertise out Serial0/1/0
*Jun
10
23:06:41.350:
200.200.200.0/24
metric

IP-EIGRP(Default-IP-Routing-Table:100):
Int
128256
256
128000

2009 Cisco Learning Institute

CCNAExploration:AccessingtheWAN
Chapter3CaseStudy
You move back to the PHX router and check its routing table once more. Once the EIGRP adjacency was
established, all the expected routes are listed in PHY routing table:

PHX#sh ip route
Codes: 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
Gateway of last resort is 10.10.10.2 to network 200.200.200.0
D*

200.200.200.0/24 [90/20640000] via 10.10.10.2, 00:02:43, Serial0/2/0

192.168.200.0/24 [1/0] via 10.10.10.2

10.0.0.0/30 is subnetted, 1 subnets

C
C

10.10.10.0 is directly connected, Serial0/2/0

192.168.100.0/24 is directly connected, Loopback1

Once more you issue pings from PHX to devices inside T5s network and to outside networks. All pings
are successful:

PHX#ping 10.10.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/44/48 ms
PHX#
PHX#ping 192.168.100.27

2009 Cisco Learning Institute

CCNAExploration:AccessingtheWAN
Chapter3CaseStudy
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.27, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
PHX#
PHX#ping 192.168.200.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.200.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/45/48 ms
PHX#
PHX#ping 192.168.200.42
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.200.42, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/45/48 ms
PHX#
PHX#ping google.com
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 72.14.207.99, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/68/84 ms
PHX#

2009 Cisco Learning Institute