From: Jim Terry (jtixthus@attbi.com)
Date: Tue Nov 05 2002 - 21:59:03 GMT-3
I have more questions on my NBMA network with r7 as a hub and R10 and r11 as
spokes. Both spokes are in the same AS but a diff AS than the hub.
I have ruled out my redistribution problems. I am running OSPF between all
serial interfaces and Loopback0 on each router in the NBMA network.
I can ping the Loopback1 on R10 from R11 but not the Loopback1 on R11 from
r10. Both loopback1s are advertised via network commands in bgp.
here is the sh ip bgp 144.144.144.144 on all all 3 routers.
(144.144.144.144 is the loopback 1 address on R11):
hub router:
r7#sh ip bgp 144.144.144.144
BGP routing table entry for 144.144.144.0/24, version 164
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
4799
11.11.11.11 (metric 65) from 11.11.11.11 (111.111.111.111)
Origin IGP, localpref 100, valid, external, best
r10#sh ip bgp 144.144.144.144
BGP routing table entry for 144.144.144.0/24, version 75
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
22.22.22.22 33.33.33.33 55.55.55.55 150.50.15.111
Local, (Received from a RR-client)
44.44.44.44 (metric 129) from 44.44.44.44 (144.144.144.144)
Origin IGP, metric 0, localpref 100, valid, internal, best
r10#
r11#sh ip bgp 111.111.111.111
BGP routing table entry for 111.111.111.0/24, version 4
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
150.50.46.6
Local
11.11.11.11 (metric 129) from 11.11.11.11 (111.111.111.111)
Origin IGP, metric 0, localpref 100, valid, internal, best
r11#
Any ideas?
Thanks,
JT
----- Original Message -----
From: "Hamele Kassa" <hkassa@attrmc.net>
To: "Joe Martin" <jmartin@capitalpremium.net>; "peter" <pvo@usermail.com>;
"Jim Terry" <jtixthus@attbi.com>
Cc: <ccielab@groupstudy.com>
Sent: Tuesday, November 05, 2002 4:15 PM
Subject: Re: BGP on NBMA
> neighbor x.x.x.x next-hop self" should be used for IBGP peers.
>
> HK
> ----- Original Message -----
> From: "Joe Martin" <jmartin@capitalpremium.net>
> To: "peter" <pvo@usermail.com>; "Jim Terry" <jtixthus@attbi.com>
> Cc: <ccielab@groupstudy.com>
> Sent: Tuesday, November 05, 2002 6:10 PM
> Subject: RE: BGP on NBMA
>
>
> > Peter,
> >
> > If I understand your statement on the use of next-hop self command, I
> should
> > always use the command "neighbor x.x.x.x next-hop self" for all EBGP
> peers.
> > Is this a correct statement? If so, does this also apply to
> > inter-confederation peers?
> >
> > Thanks in advance.
> >
> > Joe Martin
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> > peter
> > Sent: Tuesday, November 05, 2002 10:12 AM
> > To: Jim Terry
> > Cc: ccielab@groupstudy.com
> > Subject: Re: BGP on NBMA
> >
> >
> > On Tue, 2002-11-05 at 16:03, Jim Terry wrote:
> > > Hi all/Pete,
> > >
> > > 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?
> >
> > Next-Hop Self is used on EBGP learned prefixes to enable IBGP
> > reachability so it might be somewhat ambiguous in various definations.
> > My comment was that it wasn't going to help extra AS routers resolve
> > next hops from a given router.
> >
> > By reset I was referring the fact that a bgp speaker must reset the BGP
> > next-hop attribute with his address upon transmission. In other words,
> > when sending an EBGP update, it is normal and indeed mandatory to do
> > "next-hop self" whereas on an IBGP update, it is optional.
> >
> > Pete
> >
> >
> >
> > > Thanks,
> > >
> > > JT
> > >
> > > ----- Original Message -----
> > > From: "Peter van Oene" <pvo@usermail.com>
> > > To: <ccielab@groupstudy.com>
> > > 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
> > > topology
> > > > 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
> > > ping
> > > > >the loopbacks that are advertised in BGP with the network command.
> It
> > > does
> > > > >not matter if I am pinging spoke to spoke(same AS) or spoke to
> > > hub(different
> > > > >AS)
> > > >
> > > > 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.
> > > In
> > > > 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.
> > > >
> > > > >JT
> > > >
> > > > Pete
This archive was generated by hypermail 2.1.4 : Tue Dec 03 2002 - 07:22:53 GMT-3