[c-nsp] iBGP - Multihoming ideas

[Mark Tinka]

On Friday 28 January 2005 07:57, John Gitau wrote:

> No not full internet routes, actually come to think of it I dont
> think even my upstream provider gets those, so we point a default
> route to them at the HQ, we only run BGP with them so they can
> further advertise our routes to whomever they get their bandwidth
> from.

That's fine!

> Im fishing for ideas on how to go about the whole setup. By
> everything I meant everything B and HQ have,...

Okay, from your topology, HQ has routes received from Jambonet (AS12455), 
either full or partial, whatever you have agreed to receive, and it also has 
routes received from B (which include routes from the exchange, as well as 
routes received from A).

You could configure B to accept all routes learned by HQ (including routes HQ 
has learned from A).

As you mentioned in a previous post, using a route reflector to maintain your 
iBGP sessions, and allow for future expansion, is a good idea. Having a 
redundant RR isn't such a bad idea either.

> then Router A 
> decides how best to send the traffic.

Why don't you use a link state routing protocol to map out your 
infrastructure, like OSPF? You can then let (i)BGP run on top of that, 
advertising your (internal) prefixes across your network accordingly. Others 
might say let OSPF carry your internal prefixes, rather than iBGP, but I 
advocate the former.

If A were to send traffic to the exchange, the best route would be via B, as 
it's only 2 hops away. If A were to send traffic to the Internet, the best 
route would be via HQ, as that's only 1 hop away.

Other alternate routes would be in case of primary link failure. BGP isn't a 
link state routing protocol, so any link congestion management to be handled 
by the routing protocol would be via OSPF, although there are several other 
ways.

> The only problem in this 
> case is since those two routers don't have full internet routes
> either, they'd need to both send/announce a default route to
> router A (thats for anyone trying to reach a destination not on
> HQ and B's routing tables) Which works okay at the moment.

Well, I don't see a problem with this, as you already stated that both HQ and 
B don't have full routes. Proving default-information to A would be the best 
way forward, then.

> I was 
> just worried for when I need to add more routers.

Well, using the RR's will help you scale your network - any new routers would 
simply peer with the RR's and receive the best paths. You can also announce 
default-information from/via your RR.

Mark.

>
> **gitau