[c-nsp] Good practices for peering

[Danny McPherson]

On Dec 28, 2005, at 8:53 AM, Vincent De Keyzer wrote:

>
> what are the configuration good practices when setting-up a peering  
> with
> another AS ?
> I would do something like this:

> router bgp <my_as>
>  neighbor 194.88.108.33 remote-as <his_as>
>  neighbor 194.88.108.33 password <some-password>
>  neighbor 194.88.108.33 soft-reconfiguration inbound
>  neighbor 194.88.108.33 filter-list 1 out
>  neighbor 194.88.108.33 filter-list 2 in
>
> ip as-path access-list 1 permit ^$
> ip as-path access-list 2 permit ^<his_as>$
>
> List 1 is to announce only my routes; list 2 is to make sure that  
> the other
> guy does not leak any route towards me.
>
> Does it look good?
>

Some other things worth considering here:

I'd nuke the soft-reconfiguration stuff, most BGP speakers today
support BGP capabilities and BGP Route Refresh, which allows
you to accomplish the same thing without burning all that RAM
storing unaltered Adj-RIBs-In from peers before input policy is
applied.

I agree with the route-map recommendation for both ingress and
egress route policy as well.  Some of the route-map enabled policies
I'd recommend include:

o Don't allow shorter than /8, longer than /24 in (or out?).  This is
trivial to accomplish with prefix filters (which I'd definitely  
recommend
over ACLs for route policy)

o Don't accept more specific prefixes of your own aggregates from
your peers (unless only as one-offs for multi-homed customers).

o It's a good idea to filter bogons (RFC1918, unallocated, etc..)
from peers, else they could be used for spam or other malicious
activity.  However, if you do this, you probably want to automate
the filter generation in some manner.  The Team Cymru bogon
list is a good place to start.

o Unless you're accepting MEDs and know exactly what you're
doing with them, I'd reset MEDs learned from all eBGP peers to
some fixed value on ingress (e.g., 0 or 1).

  o If you've got a pretty static set of prefixes you'll be advertising
filter them explicitly.  Otherwise, employ some community-based
model for your routes that you intend to advertise to peers and
permit only those communities outbound (deny all other
communities - communities which you'd tag internal-only routes
with).

o Mark routes from your peers with some community so that
when you enable other peers you don't advertise a third peers
routes to them.  Peer-groups will certainly help you scale
this down the road, and you'll begin to appreciate a BGP
community-based model then as well.

o You like want to set up some route preference model such
that customer and internal routes are preferred over routes
learned from peers.  Communities and local preference seem
to be the de facto way of doing this - RFC 1998 is a great place
to start for this.

o I'd explicitly set next-hop-self on the sessions

o Enabling route flap dampening might be a good idea as well

o Employ some max prefix limit on the peer (if possible)

o The safety net AS path access-lists are fine, but they require
updating when new peers are enabled and you need an
accurate source from which to obtain your peers transit ASNs.

There are probably other things II'm missing, but this should
keep you busy for a bit.  There's lots of great tutorial information
out there on how and why to do most of this stuff..

HTH,

-danny