[c-nsp] A little confusion: OSPF and iBGP

Mark Tinka mtinka at globaltransit.net
Tue Feb 3 12:58:24 EST 2009


On Tuesday 03 February 2009 09:31:49 pm Steve Bertrand 
wrote:

> For the prefixes at the client access edge that are put
> in place statically, I advertise them to the other
> internal peers via iBGP. Would it be best to leave it
> this way, or to put this address space into the IGP
> instead, and have BGP only announce the actual eBGP
> learnt routes?

Best to keep your IGP carrying only your Loopbacks, and iBGP 
handling your customer prefixes.

Doing this affords you the filtering capabilities of BGP and 
allows you to operationalize your routing policy better.

> Also, should all of my routers have a pull-up route for
> the entire /21, or just for the prefixes that they house?

Normally, I'd recommend the aggregates be originated by a 
very stable device in the network. We do this using our 
route reflectors, and change the NEXT_HOP attribute of the 
aggregates to point to the Null/Discard interface on all 
peripheral routers.

These edge routers would then be configured to re-announce 
the aggregates to remote eBGP peers (customers, transit 
providers, public/private peers, e.t.c.).

For customer aggregation edge routers, prefixes used to 
assign /30 (/126 for v6, or whatever you use for this 
purpose) point-to-point addresses, as well as assignments 
for their own use on their LAN's, from your own blocks, 
would be included in your iBGP running on these router. 
Typically, we assign whole /24's or more for this purpose, 
and announce a shorter block within our network; keeps our 
iBGP table as small as possible (can't have little /30's or 
/126's running around in your iBGP, now can you :-)).

So far, you seem to be on the right track.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090204/d8c07e3c/attachment.bin>


More information about the cisco-nsp mailing list