Re: BGP on NBMA posted 11/05/2002
It looks like this is slowly being solved.
#1-First it was a problem with my layer 2 connectivity. I had my frame map
statements entered incorrectly on my NBMA network
#2- I appear to have a loop in my routing table caused by a triple
redistribution problem on one of the routers and no distribute list to stop
the feedback :( .
3- curious still as to your comment on the next hop self pertaining to IBGP
and not EBGP. I specifically got the next hop self from the BGP Case Study
#2 on CCO about multiple ASs in an NBMA network. Did I read that
incorrectly? Are you saying that you only use the next hops self command
w/in IBGP? What do you mean by reset next hop for EBGP?
----- Original Message -----
From: "Peter van Oene" <pvo@xxxxxxxxxxxx>
Sent: Tuesday, November 05, 2002 5:48 AM
Subject: Re: BGP on NBMA
> At 11:23 AM 11/4/2002 -0800, Jim Terry wrote:
> >Hi all,
> >I have another BGP question on an NBMA network.
> BGP runs over TCP and so long as you have IP reach ability, the L2
> shouldn't matter
> >All spokes and hub are running OSPF and there is proper connectivity.
> >The hub is one AS and the spokes are in a different AS.
> I must say this is a bizarre setup.
> >I can ping the loopbacks for all OSPF advertised interfaces but cannot
> >the loopbacks that are advertised in BGP with the network command. It
> >not matter if I am pinging spoke to spoke(same AS) or spoke to
> As with your last example, did you verify:
> a) appropriate routes are in the bgp table (show ip bgp)
> b) BGP next-hop is reachable
> c) appropriate routes are in the local rib (show ip route)
> Keep in mind this is bi-directional and you'll need to make sure that your
> destinations can respond to the source of your pings.
> >I do have in BGP the next-hop-self from the hub to one spoke. That one
> >spoke is the route-reflector for the other spokes. Spoke to spoke
> >connectivity is only via the serial links in the NBMA through the hub.
> Next-hop Self is an IBGP function and does not relate to EBGP peering.
> EBGP, you must reset next-hop. Are your spoke to spoke peerings
> established? What do the adj-rib in/outs look like (show ip bgp neighbor
> x.x.x.x. advertised-routes / received routes)
> >Does anyone have any ideas?
> You really need to step through a logical debugging process here much like
> you would any reach ability problems. BGP adds the additional steps of
> verifying peering, route advertisement / reception, BGP next-hop
> resolution, and sync if you have it enabled.