[c-nsp] Converting OSPF backbone to iBGP

[Pete Templin]

Garry wrote:

> after years of running very smoothly and without any problems (and not
> expecting any), we have decided to move our backbone from OSPF (single
> area) to iBGP as far as "best practice" recommendations go ... I've been
> trying to find decent write-ups about certain things, but haven't been
> too successful as far as certain details go ... maybe somebody has some
> good pointers for me ...

My biggest recommendation is to use the opportunity to add a symbolic 
community to EVERY route injected into BGP.  We use this to streamline 
our filtering: customer routes, whether redistributed or learned via 
eBGP, are installed with a community such as 11457:30100 (redist) or 
11457:20100 (eBGP).  At our upstream edge, we only pass routes marked as 
11457:2.... or 11457:3...., so we know that we're only passing routes 
learned from customers.

Reason: we got bit when we had InterNAP and InterNAP as our provider(s). 
  A customer was bringing their own space, so we opened our 'announce' 
filters to allow the prefix.  We were learning the prefix over one of 
the InterNAP connections, and happily passing it to our other InterNAP 
connection, since it matched the prefix list.  With community-based 
filtering, that route would have been tagged 11457:6.... and would have 
been denied for propagation.

Our community structure is essentially (ASN):ABCDE, where ABCDE means:

A:	Type of route (1=internal, 2=customer, 3=redist/agg, 6=transit)
BC:	POP of origin (01 is first POP, 02, 03...)
D:	Tuning preference (0=provider, 1=default, 8=maintenance, 9=null)
E:	Georouting (0=distributed aggregate, 1=cold-potato, 2=hot-potato)

We use BC&E to automatically tweak MED towards our transits.

pt