Kevin Dorrell, CCIE #20765

25 Apr 2008

NMC 17.8 BGP – Routing loop

Filed under: BGP — dorreke @ 20:02

The BGP in this lab is definitely worth a mention.  I allowed myself 40 minutes in the time plan, but that was not nearly enough given the complexity of the topology.  It was the only task in that lab I overran on, taking slightly over an hour, and still not being sure I was all right.

Even though routes are truning up in all the routers, and meeting the spec, I still do not have complete pingability.  Most inconveniently, the NMC pingability chart does not cover the BGP addresses in this lab, so I wonder if reachability is really required.  Let us assume it is for the moment.

There are four things that are likely to affect pingability in this sort of topology:

  1. Is synchronisation switched on.  No it isn’t; I disabled it on the CATs.
  2. Does every router have a reachable next-hop to the NLRI of each prefix?
  3. Does the path to any next-hop that is through a router that doesn’t speak BGP?
  4. Do we have any circular next-hop paths?

One thing that should sound alarm bells is “Do we have any BGP peerings that are not direct neighbors?”  Yes we do.  We have R1 and R2 which are peered in AS 100, but which are not directly connected.  To make matters worse, the route between R1 and R2 goes through R3, which is in AS 10.  This sounds like a recipe for a forwarding loop.

In fact, let us try and trace from R1 to

Protocol [ip]:
Target IP address:
Source address:
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]: 8
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to
  1 8 msec 12 msec 12 msec
  2 24 msec 24 msec 28 msec
  3 24 msec 24 msec 28 msec
  4 20 msec 20 msec 25 msec
  5 40 msec 36 msec 40 msec
  6 36 msec 36 msec 36 msec
  7 36 msec 32 msec 32 msec
  8 48 msec 52 msec 52 msec

Mmm, we seem to have a loop R1, R3, R4, R1, R3, R4, R1, etc.  According to the peerings, we should be going R1, R2, R5, CAT1.  SHOWiT does not support the trace command, so I shall do a trace by hand according to the SHOWiT routing tables:

R1 to, via, recursively via  So the next hop is R2.  Or is it?  In fact, it is via DLCI 103, so the next hop is actually R3.

R3 to, via  The next IP hop is R1, but that is via DLCI 304, so via R4.

So it looks rather like they have the same loop as I have.  In fact, I think the only way to make this address reachable is to build a tunnel to make up for the missing R1 <–> R2 link.  To traffic to pass between R1 and R2 without being intercepted by R3.  It took a lot of experimentation, but this is what I ended up with:

R1#show run int Tu21
Building configuration...
Current configuration : 132 bytes
interface Tunnel21
 ip unnumbered Loopback101
 ip ospf cost 19
 tunnel source Serial0/0.123
 tunnel destination
R2#show run int Tu21
Building configuration...
Current configuration : 132 bytes
interface Tunnel21
 ip unnumbered Loopback102
 ip ospf cost 19
 tunnel source Serial0/0.123
 tunnel destination

That’s better.  I ran a full pingability check on all routers, and found everything was OK … drat! … except R5 could not reach to  That is because R5’s next hop is so it is sourcing the ping from  That’s fine for CAT1, but CAT2 does not have a route back to it.  If I source the ping from Lo105 instead, ( –>, then I get a response.



Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: