[c-nsp] BGP next-hop, default routes and more!

[Phil Bedard]

Multi-hop EBGP was created for this kind of scenario...

Alternatively use next-hop-self on outgoing advertisements to the CPE  
which somewhat accomplishes the
same thing.

You still would want a /32 pointing out the outgoing interface to  
that neighbor, usually
done via a static route.  Your BGP peer config is already set to that  
static IP, so if you end up changing
IPs you are going to have to change the CPE config anyways...

Phil


On Jan 10, 2007, at 3:25 PM, Jee Kay wrote:

> I am currently trying to set up the following routing for our CPE  
> bits:
>
> CPE--PE--Aggregation--Core
>
> The Core device generates our aggregate routes and does BGP RR magic.
> Our Aggregation connects to said RR magic, and the CPE then connects
> to the Aggregation layer via IBGP to learn various routes. In
> addition, the CPE has a static default configured pointing at the
> remote PE interface.
>
> So far so good..
>
> The problem is that that the aggregation device loopback is in the
> address space covered by the aggregate routes advertised by the core.
> As far as I can tell, this leads to:
>
> a) CPE uses default route to set up IBGP session with Aggr. so far  
> so good.
> b) CPE sees IBGP route which is 'better' (than default) for our
> aggregate address space. Protocol next-hop is the Core device. Actual
> next hop is obviously the PE.
> c) Best route to Aggregation device suddenly becomes the IBGP  
> learnt route
> d) Endless cycling of routes as BGP routes alternately become
> cyclic/inaccessible, are removed, are re-learnt, become cyclic, are
> removed, etc.
>
> at this point it all goes a bit wrong and the routing table basically
> ends up in constant churn.
>
> The question is.... how do I avoid this? The only real way I can think
> of is to configure static /32 routes for the aggregate RRs and the
> core RRs so that there is always a next-hop for both the BGP peering
> and for any core generated routes. This sort of sucks though as it
> would involve reconfiguring all CPE should the core addresses ever
> change.
>
> I assume I'm not the first one to run into this so... help? :)
>
> Thanks,
> Ras
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/