[c-nsp] Re: Good practices for peering

[Danny McPherson]

On Dec 30, 2005, at 7:33 PM, Daniel Roesen wrote:
>
> Big drawback: you don't see route leaks anymore that don't pass your
> filters.

Nor do you see the associated stability or churn, which can
quickly become a factor - and was my primary concern.

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

Right, and if you're not filtering explicitly and prefer customer
routes over peers, in this instance, your customer instantly becomes
the preferred path to that full set of Internet destinations.  I recall
once in ~1994 when a DS1 BGP customer of ours at iMCI was
advertising the full Internet routing table to us per they were multi-
homed to Sprint and since we preferred customer routes over
peers (and had not yet pushed out an explicit prefix-based input
route policy for the peer), their DS1 became the preferred
interconnect for all traffic from iMCI destined to non-iMCI Internet
destinations.  As you might imagine, there was slightly more than
1.5M of traffic between iMCI and "the rest of the Internet" at the time
and this created a bit of a problem.  This is when we implemented
the safety net AS path filtering policies that were required to be
employed before a peer was activated, as well as explicit prefix
filter generation and deployment for customer peers, and a few
other related processes...

Beyond alerting the customer to some misconfiguration on their
end, which can be obviated (at least as far as impacting data path
forwarding and extraneous memory consumption) by simply
denying the routes in ingress on your side, you're consuming a
significant amount of resources to maintain the table - which can
become quite considerable as more and more peers are provisioned.

I suppose the next step would be for you to employ ORF (outbound
route filters) in order to advertise your ingress policy to the peer  
such
that they can apply it on egress and spare the update generation
cycles, enabling them to explicitly drop routes before you receive them
from the mis-configured peer, but that still masked their brokenness
(oh well :-)

I do understand your point, it's just that I'd prefer not to consume
memory or CPU cycles during steady state periods in order to debug
something that could be avoided with very little resources ongoing  
(i.e.,
input policy and BGP Route Refresh).

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

I agree, as are the max prefix filter polices.  OTOH, you're certainly
better off denying them then allowing them to consume resources on
your routers, IMO.

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

Folks start aggregating multiple /8s to /7s and shorter, really[?]   
(I don't
see anything longer than /8 in the current Internet routing table) - and
they withdrew the more-specific /8s?  I don't recall this actually  
occurring,
nor would I recommend it if I were them, though I'd be interested in
reading more on the incident, do you have any additional details?

The reason I proposed this was in order to avoid accepting defaults (and
slightly longer prefixes) and related cruft - I seriously doubt  
you'll see valid
advertisements of this length (</8) in today's Internet.

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

For sake of clarification - "IBGP leaks ***that results in EBGP prefix
advertisement***" is what we're referring to here.  As for the IRR thing
- I'm a HUGE proponent of explicit IRR-based filtering everywhere -
if you can make it work with the accuracy of today's IRRs AND
apply said policies to both customers and peers - the former of
which is barely plausible today, much less, the latter (much to my
own dismay).

This is extremely difficult to accomplish in today's Internet, in
particular when attempting to build said import policies for peers
(customers are the easy part).  The only actual implementation
of explicit prefix filtering on ALL eBGP sessions in the network I'm
aware of was ANS, circa 1995, and it came with huge overhead
(e.g., not incrementally updatable prefix filters, had to bounce a
route or reset a session to execute new import policies as no
soft-reconfig or route refresh existed, etc..).

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

I've seen spammers in the past 18 months advertise unallocated
space, send a zillion spam messages, and then withdraw the
routes.  If you have mechanisms in place to support dynamic updating
of bogon associated route policies it's better than accepting all
prefixes with your eyes shut.

With that said, I do agree with your caution here that if you're not
going to actively maintain route and packet bogon filters, you're
probably better off not using them in the first place, per when new
prefixes are "activated" you'll end up breaking connectivity for those
addresses, which so often seems to be the case.

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

I've read the negating arguments but still tend to side with
stability - to each his own :-)

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

Likewise, I think the elaboration on these and other commonly
employed tactics are important as folks need to determine what's
best for their operating environments.

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

Hrmmm, great - I think  :-)

-danny