Comments on: Troubleshooting Lab #1

By: shodown

shodown — Mon, 07 Jun 2010 01:50:55 +0000

I just ran debug ip bgp. Seen the problem right away. I didn’t know a Default router wouldnt’ work. Thank god for debugs, but I have to get more knowledge. Running Debugs can be impossible in production networks at times.

By: Colby

Colby — Mon, 19 Apr 2010 19:25:21 +0000

That wouldn’t fix this one.

By: rose

rose — Mon, 19 Apr 2010 18:24:50 +0000

remove “ebgp-multihop 2″ statement from both routers. The peers will come up.

By: zero

zero — Tue, 30 Mar 2010 15:44:46 +0000

Oups i forgot R2
On R2:
ip route 1.1.1.1 255.255.255.255 10.1.1.2

By: zero

zero — Tue, 30 Mar 2010 15:41:50 +0000

On R1:
ip route 2.2.2.2 255.255.255.255 10.1.1.3
Et voilà!

By: drakonblayde

drakonblayde — Sat, 06 Mar 2010 06:50:35 +0000

If you debug the above configuration, BGP will tell you specifically that it has no route to it’s peer, despite the fact that it can find it via the default route (ie, pings will succeed). BGP will purposely ignore default routes for the purpose of initiating a peering connection

By: Stuart Howlette

Stuart Howlette — Sat, 06 Mar 2010 03:07:21 +0000

I believe it’s because there’s no route to the loopback interfaces, therefore it wont be able to establish a neighbour relationship to an IP/neighbour it has no idea exists.

By: drakonblayde

drakonblayde — Fri, 05 Mar 2010 19:58:38 +0000

The default routes are the problem. Despite the fact that you can ping both loopbacks with the above configuration, a BGP speaker will not use a default route to establish a peering relationship, it has to have a more specific route to it’s peer.

You only need to change the route on one side, as BGP operates like a client/server application. Only the side that’s initiating the peering session needs the specific route, the other side can respond to the peering connection over the default route. This is a bad idea, however, as it leaves only one side capable of establishing the relationship.

The solution is to pull both default routes and have each router nail up a static route to it’s peer.

As far as the interfaces being shut down issue – Yes, the running config does show the status of an interface if it’s shutdown:

!
interface Ethernet0/0
no ip address
shutdown
half-duplex

So if you do not see the shutdown present in the interfaces configuration, it has had no shut issued on it

By: Colby

Colby — Fri, 05 Mar 2010 07:09:34 +0000

@Daniel: no shutting the serial interfaces should be implied. Everything else you put is wrong (or not applicable in this case).

By: Jared

Jared — Fri, 05 Mar 2010 07:09:07 +0000

Haha, yes that’s true, the serial interfaces are indeed shut down. However that’s because Cisco doesn’t include the status (shut/no shut) in the running config.

The /31 won’t cause any issues either as BGP doesn’t broadcast anything. It runs directly on TCP and will use the interface addresses to send it’s info, as far as I know anyways.