From: Michael Snyder (msnyder@xxxxxxx)
Date: Tue Mar 12 2002 - 15:21:17 GMT-3
The reason I came up with that question is both RRC (route reflector
client) and NHS (next hop self) seem designed to overcome that fact that
IBGP routes are not updated between IBGP neighbors.
Doesn't the RR have to set the next hop to the RR address in order to
pass the valid IBGP routes to the RRC? I assumed it did. (I'm still
working on getting a home lab to test such issues)
While NHS would seem to allow IBGP routes to passed like EBGP routes
because the other IBGP neighbors would have a valid next hop.
In other words, both commands seem to overcome the IBGP full mesh
requirement.
Let's say that I'm completely in left field (hence the reason for the
question), is there a scenario where you have to use both NHS & RRC at
the same time?
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Edmund Roche-Kelly
Sent: Tuesday, March 12, 2002 9:21 AM
To: Michael Snyder
Cc: CCIELAB@groupstudy.com
Subject: Re: Route Reflection vs. Next Hop Self, Functional Difference?
Setting a neighbor as a route reflector client allows you to advertise
routes learned over other IBGP connections to that IBGP neighbor. I
don't see how setting next-hop-self would achieve this.
Ed
Michael Snyder wrote:
>
> I've been reading up on BGP lately, and have come up with a question.
>
> Is there a functional difference between setting a neighbor as a route
> reflector client, or setting a neighbor as next hop self? Assuming
'no
> sync', to my mind these commands seem to do the same thing. The same
> network topology and limits seem to apply to each command.
>
> Michael Snyder
> Lead Engineer
> Revolution Computer Systems
> CCNP/DP MCSE NT/2000
> (270) 443-7400
> (Fax) 443-7070
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Peter van Oene
> Sent: Monday, March 11, 2002 9:12 PM
> To: Stephen Oliver; ccielab@groupstudy.com
> Subject: Re: BGP and OSPF synchronization
>
> BGP synch is long dead and gone. Further, it may have been dead
before
> route reflection became commonplace. Given 1403 (bgp to OSPF
> interaction)
> predates 1863 (first hint of RR technology) by two years, it occurs to
> me
> that possibly interaction with BGP synch wasn't a tested feature of RR
> code, particularly wrt to 1403 operation. This would make sense since
> one
> wouldn't run into IBGP scaling issues if one were running a non full
> IBGP
> mesh transit AS. The two features indirectly solve the same problem.
>
> It's a sad state of affairs when intelligent folks have to waste
quality
>
> time learning useless features.
>
> At 07:13 PM 3/11/2002 +0000, Stephen Oliver wrote:
> >I have 3 routers in a frame relay hub and spoke ospf configuration.
> >
> >The ospf is working fine and I have set the router IDs to the router
> >number. R1 is 1.1.1.1 etc.
> >
> > r1 ---------r5-----------r2
> >
> >I have configured BGP in AS 13 on all the routers with r5 as a
> >route-reflector to both r1 and r2. Next I add a loopback on r1 and
r2
> and
> >include them in OSPF. They are reachable everywhere. I then add the
> >loops into BGP. When they get to R5 they are unsync because of the
> >OSPF/BGP router ID issue so I change the router IDs on R1 and R2 to
> match
> >OSPF and hey presto R5 syncs the loopbacks.
> >
> >Now when I look at the spoke routers even though they get each others
> >loopbacks into their BGP tables they have marked them as unsync
because
>
> >they are sourced from R5 for BGP and from the other end router for
> >OSPF. Another RID mismatch.
> >
> >I can overcome this by simply adding a network statement for the
> unsynced
> >prefixes on each spoke router.
> >
> >Is this a valid solution to the problem ?
> >
> >The whole scenario is just a test to see OSPF/BGP interactions.
> >
> >Thanks, Stephen.
> >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:57:02 GMT-3