[c-nsp] Re: Good practices for peering

Daniel Roesen dr at cluenet.de
Fri Dec 30 21:33:17 EST 2005


Hi Danny,

On Fri, Dec 30, 2005 at 05:45:23PM -0700, Danny McPherson wrote:
> 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.

Big drawback: you don't see route leaks anymore that don't pass your
filters. I cannot count the number of BGP customers who did send full
table on initial turnup (and sometimes later). You won't see that
problem without adj-rib-in anymore. The counters in "sh ip bg nei ..."
might help for large leaks (I didn't explore the actual behaviour of the
"prefix activity / current rcvd" and "Local Policy Denied Prefixes
Inbound" counters yet), but won't give you a good idea about small
leaks. Automatically checking rejected prefixes from customers is
usually a good idea.

> o Don't allow shorter than /8,

Why? This measure can only harm (when /8 folks start aggregating, or a
/7 or larger gets allocated - IIRC both happened already, with ugly
results).

> longer than /24 in (or out?).

Or both. But it should be clear that this is only a crude hack at an
arbitrary prefix length to get rid of IBGP leaks. Better to filter via
IRR everywhere. I tend to not recommend this kind of filtering anymore,
as long as one has proper other filtering in place.

> 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.

I think filtering unallocated space is kinda futile. You don't get rid
of any real problem with that anymore. But it _would_ get ya if you
don't update filters quickly, regularily and for eternity. I'm neither a
fan of outsourcing such filters in realtime to anybody.

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

This is highly debatable. "Flap dampening considered harmful" in more
and more places. :-)

Other than those, I fully agree with your recommendations and thank you
for sharing them here.


Best regards,
Daniel (who learned BGP from The Bi^WBook co-authored by you)

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0


More information about the cisco-nsp mailing list