Case Study: A Protocol Conflict

CIS 185 Advanced Routing (CCNP 1)

Spring 2006
Rick Graziani

Based on Chapter 3: Static Routing, Routing TCP/IP 2nd

Edition, Jeff Doyle and Jennifer Carroll
 Resources

• Information for this presentation is

largely based on the following book:
• Routing TCP/IP, Volume 1, 2nd Edition
By Jeff Doyle, Jennifer DeHaven Carroll
ISBN: 1587052024
• Thank you to Jeff Doyle, Jennifer
Carroll, and Cisco Press for the use of
their graphics and other materials for
this presentation.

Rick Graziani graziani@cabrillo.edu 2

 Resources

• For more in depth information and

especially for instructors, I highly
recommend the following book:
• Cisco IP Routing: Packet Forwarding &
Intra-domain Routing Protocols
by Alex Zinin
ISBN: 0201604736
• Thank you to Alex Zinin for the use of
his materials for this presentation.

Rick Graziani graziani@cabrillo.edu 3

Note to instructors

• This presentation is not solely based on information from

the Cisco Academy CCNP 1 curriculum.
• Much of the information for this presentation is from
Routing TCP/IP, Volume 1, 2nd Edition
By Jeff Doyle and Jennifer Carroll.
• Alex Zinin’s book, Cisco IP Routing, has also been very
helpful in creating this presentation.
• I feel the information in this book does a more adequate
job of discussing the objectives and outcomes necessary
for understanding the concepts, implementation, and
troubleshooting of routing protocols, whether it is for
university academics, certification, or professional
advancement.

Rick Graziani graziani@cabrillo.edu 4

Case Study: A Protocol Conflict
Routing TCP/IP, p. 112

• Good example of troubleshooting techniques.

• Good example of how changes on one router can affect
other routers and other parts of the network.

Rick Graziani graziani@cabrillo.edu 5

Current traffic to Milne

• Current traffic to Milne working fine.

Rick Graziani graziani@cabrillo.edu 6

 Milne is a mission critical server

• Host Milne is a mission critical

server.
• Everything is working fine.
• Network Administrator worried
about traffic from Roo to Milne
delayed by the bridge/switch.
• Adds a static route on Roo,
sending packets to Milne, via
Kanga.

Rick Graziani graziani@cabrillo.edu 7

Solution is not working

• Solution is not working.

• Packets from Roo now no Not arriving
longer reach server.
• Also, packets from Kanga no
longer reach server.
Not arriving
• No changes were made on
Kanga.

Rick Graziani graziani@cabrillo.edu 8

First Step: Check Routing Table on Roo

• Roo’s Routing table looks

correct

Rick Graziani graziani@cabrillo.edu 9

Second Step: Trace from Roo

• Trace shows a routing

loop between Roo and
Kanga.
• The problem seems to
be at Kanga.
• Kanga should be
forwarding the packet out
its directly connected
network, E0.
• Suspicion falls on the
data link layer of Kanga.

Rick Graziani graziani@cabrillo.edu 10

Third Step: Kanga’s ARP Table

• IP Address for Milne is

correct, but the MAC address
is not.
• The MAC address is for Roo.
• Notice the first 6 hex digits
(OUI) for all entries are the 00e0.1e58.dc39
same – this is a Cisco OUI.
• Kanga has somehow acquired 0002.6779.0f4c
the wrong MAC address for
172.16.20.75.
• This is where the loop is
taking place.

Rick Graziani graziani@cabrillo.edu 11

Problem: Proxy ARP
• There is a problem with ARP.
• Specifically, Proxy ARP
(Routing TCP/IP, p.35). ARP Request
• Kanga first receives packet,
does an ARP Request for IP
address 172.16.20.75.
00e0.1e58.dc39 ARP Reply
• Milne responds (ARP Reply)
with its MAC. 0002.6779.0f4c
• Roo also receives ARP
Request.
• Because Roo has a route to
this IP address on a different
network (static route) from the
one it received the ARP
Request, Roo issues a proxy
ARP in reply.

Rick Graziani graziani@cabrillo.edu 12

Problem: Proxy ARP

• Kanga receives Milne’s ARP

Reply first and updates its
ARP Table. ARP Request
• Kanga then receives Roo’s
ARP Reply and updates its 2
ARP Table, replacing previous 00e0.1e58.dc39 ARP Reply 1
entry.
0002.6779.0f4c
• The Roo ARP Reply is
delayed because of the
bridge/switch. (This can be
argued, but let’s assume the
Roo ARP Request arrives
second.)

Rick Graziani graziani@cabrillo.edu 13

Solution 1: Disable Proxy ARP on Roo

• One solution is to
disable Proxy ARP
on Roo.

00e0.1e58.dc39
0002.6779.0f4c

Rick Graziani graziani@cabrillo.edu 14

Solution 2: Configure Static ARP on
Kanga

• Another solution is to create

a static ARP entry on Kanga
for Milne.
• This entry will not be
overwritten by any ARP 00e0.1e58.dc39
Reply, including from Roo.
0002.6779.0f4c

Rick Graziani graziani@cabrillo.edu 15

Best Solution

1 – Disable Proxy ARP

2 – Add Static ARP entry

Solutions:
2. If there is no need to use
Proxy ARP, is the best
solution.
3. The problem with a static
ARP entry is if the NIC on 00e0.1e58.dc39
Milne is replaced or the IP
Address is changed, the 0002.6779.0f4c
static ARP entry needs to be
changed.
Rick Graziani graziani@cabrillo.edu 16
Moral of this story…

The moral of this story is:

• Don’t limit yourself to
troubleshooting from one
device.
• Look at the outputs and
know: 00e0.1e58.dc39
– If the information is 0002.6779.0f4c
correct.
– If there is anything
missing.
– If there is something that
is there that should not
be there.
• Understanding and analysis
instead of memorizing.

Rick Graziani graziani@cabrillo.edu 17

 Case Study: A Protocol Conflict

CIS 185 Advanced Routing (CCNP 1)

Spring 2006
Rick Graziani

Based on Chapter 3: Static Routing, Routing TCP/IP 2nd

Edition, Jeff Doyle and Jennifer Carroll