RE: BGP OSPF sync with Route Reflecter

From: Howard C. Berkowitz (hcb@xxxxxxxxxxxx)
Date: Mon Apr 29 2002 - 17:52:50 GMT-3


   
At 3:10 PM -0500 4/29/02, DAN DORTON wrote:
>I usually work under the idea that if there is a route-reflector
>invloved & I cannot turn off sync then look at using confederations.
>
>With a single P2P IBGP link you can get away with injecting the
>networks into the IGP, but when route-reflectors come into play more &
>more problems can arise (depending on your IGP & it's confguration).
>
>Rick is right in that there is no true solution for the problem he just
>presented under the rules applied to it.
>
>(At least if you need to get the routes there via BGP. Otherwise you
>could use NAT, policy routing, etc)
>
>I think what peter means is that in a real world situation a
>configuration like this would not make any sense.
>
>Although fully meshing a large IBGP scenario might be a bit out of
>reach financially for some customers, so you might still need RR's.

Full mesh starts to break down when you have more than 15-20 BGP
speakers. You can safely assume that real world iBGP networks of any
appreciable size use confederations, reflectors, or hierarchies of
reflectors (or for that matter hierarchies of confederations). The
hierarchies can get a little tricky unless you are extremely careful
with route preferences, so you always prefer intra-cluster routes
just as OSPF always prefers intra-area.

>
>In any case in a "real world" situation turning off sync would be
>entirely up to you & if you trust you locally routed domain then there
>would not be a problem.
>
>The CCIE lab is designed to make damn sure that you know how/why & when
>a technology works, or doesn't.
>
>Sometimes in order to test it properly it must be presented in a
>ridiculas fashion.

True enough. I just finished a QoS scenario for Certzone. While I did
set up some tests with extended pings and telnets, it's really hard
to test QoS features without real hosts (ideally real traffic
generators) being involved. AFAIK, the lab looks for realistic
configurations rather than actually demonstrating the QoS.



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:58:22 GMT-3