On Sat, 2005-01-08 at 00:20, Robert Crowe wrote:

Yes, an iBGP session is possible between A & C. Route Reflectors main purpose was to reduce the iBGP full mesh requirement, thus providing for BGP scalability. If you only have 3 BGP speakers then there is no need, unless you are expecting BGP speaker growth. I would address the lack of redundancy for your BGP sessions.

Correct, route reflector's main advantage is scalability and if you're thinking to evolve into a larger network with dedicated access and core routers, route reflectors are a far better option than full mesh, though perhaps not from the start. Redundancy is a good point, since in the route reflector diagram you have a single route reflector with single sessions to your edges. If iBGP link A-B goes down, the rest of your network looses 1 transit ISP and customer 1 is cut off from the rest of your network, basically leaving him with a default route out to ISP A and the rest of your network having to rely on transit to reach your own customer. Also depends on the actual physical paths to the customer ofcourse (redundant?), but seems a bit risky, while customer 2 is looking a lot safer. Cheers, Erik -- --- Erik Haagsman Network Architect We Dare BV tel: +31.10.7507008 fax: +31.10.7507005 http://www.we-dare.nl

On Tue, 2005-01-11 at 02:03, Eric Kagan wrote:

Does anyone have any input on when this does make sense ? We have 3 Main IP pops with upstream BGP at each and 4 internal BGP sessions. I am looking to add 2 new routers so there will be about 7 sessions on each border router.

This seems to be a case where it does make sense. If you set up two route reflectors you could do with providing each border router only two iBGP links. You could for instance split your network into two logical clusters with 1 route reflector each and link the two route reflectors so they bounce routes to each other as well and provide your border routers with BGP links to both for good redundancy and a less complex network layout. Transition isn't that hard really, assuming your border routers already have iBGP links to the routers that will become reflectors it's a matter of configuring the reflectors right and making sure the border routers are connected as route reflector clients, and then start tearing down the remaining sessions. This isn't the only possible option using route reflector and full/partial mesh ofcourse and you'll have to decide what works for your network, but route reflectors would seem to be useful in your set-up. Cheers, -- --- Erik Haagsman Network Architect We Dare BV tel: +31(0)10 7507008 fax:+31(0)10 7507005 http://www.we-dare.nl

On Tue, Jan 11, 2005 at 09:51:36PM +1000, Philip Smith wrote:

Many of the ISPs I've worked with around the world have followed this path - and they are quite happy. I really think there is absolutely no need to consider full mesh iBGP any more. I wouldn't go as far as saying it's history, but I find it very hard to make an operational case for deploying full mesh iBGP any more.

One of the main problems of route reflection is that the best path decision is done centrally. The best route is not seen as from the router making the forwarding decision, but from the route reflector's point of view. Depending on network topology, geographic spread end peering/transit topo, this might/will have significant negative effects. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Are you sure? RR should just distribute routes. RR do not make any route decisions, and (btw) iBGP do not make route decisions - they are mostly based on IGP routing. All iBGP + RR are doing is: - tie external routes to internal IP; - distribute this information using iBGP mesh, RR's etc. - receive this information and set up routing using internal IP (which are routed by IGP protocls). End routers receives iBGP routes and uses IGP (OSPF or EIGRP or anything you use) for route decisions (of course, we can image exceptions, but normally , it works so that all decisions are based on IGP routing). Most important decisions are done , where routes are emitted from EBGP into iBGP, others - by iGP; which decisions are done by RR's themself?

On Tue, 2005-01-11 at 13:09, Daniel Roesen wrote:

...

One of the main problems of route reflection is that the best path decision is done centrally. The best route is not seen as from the router making the forwarding decision, but from the route reflector's point of view. Depending on network topology, geographic spread end peering/transit topo, this might/will have significant negative effects.

This is where good use of clusters and logical network design are necessary, but I don't think this is a route-reflector specific problem, more a general networking problem once your network starts groing and you start deploying a more complex edge/core based topology. I don't think this is a reason to not use reflection as oppossed to full mesh.

Cheers,

-- --- Erik Haagsman Network Architect We Dare BV tel: +31(0)10 7507008 fax:+31(0)10 7507005 http://www.we-dare.nl

On Wed, 2005-01-12 at 12:20, Iljitsch van Beijnum wrote:

(Obviously the IGP metric will be different at the client, but the client doesn't see the other routes, so it can't make a different decision. The real fun starts when the next (intra-AS) hop isn't a reflector client and the packet now takes a different path than the reflector client thought it would take.)

Yep, policing IGP and i/eBGP route distribution correctly so traffic flows logically through the best path over the network as seen from both the RR clients as intra-AS hops further down the path can be a bit challenging, though you'd want every non-RR router to be a RR client and every RR to behave like an RR client to RR's in other clusters, so you'd have a reasonably uniform view of the network. Cheers, -- --- Erik Haagsman Network Architect We Dare BV tel: +31(0)10 7507008 fax:+31(0)10 7507005 http://www.we-dare.nl

--- Alexei Roudnev <alex@relcom.net> wrote:

Are you sure? RR should just distribute routes.

RR do not make any route decisions, and (btw) iBGP do not make route decisions - they are mostly based on IGP routing. All iBGP + RR are doing is: - tie external routes to internal IP; - distribute this information using iBGP mesh, RR's etc. - receive this information and set up routing using internal IP (which are routed by IGP protocls).

End routers receives iBGP routes and uses IGP (OSPF or EIGRP or anything you use) for route decisions (of course, we can image exceptions, but normally , it works so that all decisions are based on IGP routing). Most important decisions are done , where routes are emitted from EBGP into iBGP, others - by iGP; which decisions are done by RR's themself?

The primary decision made by a route-reflector is the same decision which would be made by multiple routers in an iBGP full-mesh: which exit point should this router use to reach a specific netblock. Leaving aside for the moment any manipulation of multipath, each router will run the BGP route selection algorithm on each route learned. If multiple routes are learned to a given destination, only one will be inserted into the RIB. The standard behavior for a router is to only pass on those routes which have been accepted into the RIB. So if you have this network C1 -R1--R2-C2 | | C1 -R3--R4-C3 And R1 is the only route-reflector (yeah, yeah, bad design - it's just an example), R4 will only learn about the path to C1 through R1, and might route traffic along the R4->R2->R1->C1 path rather than along the R4->R3->C1 path which would be preferred by an iBGP full-mesh. The upshot of this is the following (drumroll): route reflectors are a wonderful thing, but make sure that their topology reflects and respects your underlying IP network topology. If you don't, you can get unpleasant consequences. ===== David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

On 11-jan-05, at 12:51, Philip Smith wrote:

Well, my preference is to start with route reflectors pretty much from day one. Let's face it, one day you will have to migrate that full mesh iBGP to route reflector. Why do the work of migration when you can start off at the beginning using route reflectors. One less job to do, one less potential network disruption, happy customers,...

You're assuming it's disruptive to add route reflection... The trouble with doing this very early is that the reflectors may end up in inconvenient places. And since you need at least two for redundancy, you don't save much in a three or four router setup.

As for guidelines for transition, check out the BGP tutorials which have been given at the recent NANOGs. It's really very simple to do, and you are lucky as you have relatively few routers to migrate.

Yup, very simple: just create two peergroups on the reflectors: one for reflectors and permanently non-client peers and another one for clients. Then assign iBGP peers to the peergroups and you're done. You'll still have some now unnecessary iBGP links between clients but that's ok: no need to remove them.