BGP Path Filtering

I'm having a hard time finding best practices for filtering outbound bgp
announcements when providing transit to bgp-speaking customers. While we
currently multi-home to several providers it appears we will soon need to
provide transit for customers with their own AS's.

I find lots of references (and understand) the basic

ip as-path access-list 3 permit ^$

and it would seem that should we wish to provide transit for a bgp customer
AS12345 we would use:

ip as-path access-list 3 permit ^12345$

but I think this breaks if AS12345 prepends their advertisement.

Next up is:

ip as-path access-list 3 permit ^12345_[0-9]$*

Which seems correct to me. Is this still best practice (or even correct)?

Mark Radabaugh
Amplex
(419) 720-3635

I'd probably err on the most cautious side and use strict inbound prefix
filters, only using outbound as-path filters toward upstreams as a sanity
check.

Unless you're a legacy peer with large networks, chances are you'll be
expected to arrange for acl mods with your peers/upstreams to propagate
your clients' announcements anyway.

hth,
Brian

ps - you're correct - there doesn't appear to be a BCP. Common sense,
tempered by a healthy dose of skepticism regarding one's clients'
competency would seem to steer the solution :slight_smile:

I like using BGP communities:
   o filter announcements you receive from downstreams based on your
      criteria of choice
   o set a specific BGP community (yourAS:whatever) on announcements which
      are to be propagated to various places (upstream providers, etc.)
   o do output filtering based on the communities you set
Make sure you clear yourAS:whatever in announcements from your BGP peers.

You can use this same technique for prefixes you originate, so that all your
outbound BGP filtering is based on communities.

I'm having a hard time finding best practices for filtering outbound bgp
announcements when providing transit to bgp-speaking customers. While we
currently multi-home to several providers it appears we will soon need to
provide transit for customers with their own AS's.

I find lots of references (and understand) the basic

ip as-path access-list 3 permit ^$

and it would seem that should we wish to provide transit for a bgp customer
AS12345 we would use:

ip as-path access-list 3 permit ^12345$

but I think this breaks if AS12345 prepends their advertisement.

yes it will

Next up is:

ip as-path access-list 3 permit ^12345_[0-9]$*

Which seems correct to me. Is this still best practice (or even correct)?

no, perhaps you mean ..[0-9]*$ but that still wont allow multiple prepends as it
wont match the space only the numbers

try

ip as-path access-list 3 permit ^(_12345_)+$

which will allow one or more of their as's

ASN is pretty crude tho, consider using a prefix list to filter each prefix and
include length

Steve

In a message written on Thu, May 15, 2003 at 10:29:18PM -0400, Mark Radabaugh wrote:

I'm having a hard time finding best practices for filtering outbound bgp
announcements when providing transit to bgp-speaking customers. While we
currently multi-home to several providers it appears we will soon need to
provide transit for customers with their own AS's.

I strongly recomend you prefix list filter your customers, rather
than AS path filter them. While AS path filters to prevent some
kinds of abuse and accidental mistake, they still allow your customer
to hijack any address space in your network (and possibly beyond)
at any time.

ip as-path access-list 3 permit ^12345$

but I think this breaks if AS12345 prepends their advertisement.

Probably you want something more like:

ip as-path access-list 3 permit ^(12345_)+$
ip as-path access-list 3 permit ^(12345_)+(6789_)+$

Giving both the customer, and customer with a customer case. That is
both specific, and allows for prepends. Your example has a couple of
problems:

ip as-path access-list 3 permit ^12345_[0-9]$*

First, it's not a valid regex ($* need to be *$), second, it allows any
(single) AS behind 12345, so it's hardly a useful filter.

I like using BGP communities:
   o filter announcements you receive from downstreams based on your
      criteria of choice
   o set a specific BGP community (yourAS:whatever) on
announcements which
      are to be propagated to various places (upstream providers, etc.)
   o do output filtering based on the communities you set
Make sure you clear yourAS:whatever in announcements from your BGP peers.

You can use this same technique for prefixes you originate, so
that all your
outbound BGP filtering is based on communities.

I am hijacking this thread a bit. Setting communities is excellent advice
especially if you are just starting out with downstream ASes.

The question is that changing your communities down the road might be a big
headache depending on whether you'll come to need more advanced ways of
filtering your announcements than coarse communities allow. Especially when
going (through growth or acquisition) from a single metro network to a
multi-metro or national/international one.

What criteria does the community think should be used when specifying
communities. IMO, overspecificity [sp?] doesn't hurt, but others may (and
have) disagreed. What's the BCP?

Thanks,

Deepak Jain
AINET

To take a crack at it...

- Route origin - customer, peer, transit provider, other (dial, etc)
- Route geography - depends on your network, but some have seperate
communities for POP, Country, Region, etc
- Customer originated information - tweaks by your customers to
selectively prepend, change local pref, not send to peers, or what not
- Source AS - simply your AS:peer AS that the route was learned from

There was an Internet Draft, last year, that summarized some of the
approachs. I suspect overspecificity in this case has never done any harm,
while lack of specificity has probably caused some heartache.

- Daniel Golding

I don't know that this is "best", but I like it:

  + decide on a set of characteristics that will help make routing policy decisions today
  + allocate one unique 16-bit number to each of those characteristics (N)
  + apply corresponding community string attributes (THIS_AS:N) to routes in sensible places
  + configure your route export policy based on community string attributes present on routes
  + worry about other characteristics as and when they become useful/necessary, and not before

Examples of characteristics I have seen in the wild are:

  + I was learnt from a peer
  + I was learnt from a transit provider
  + I was learnt from a customer
  + I was learnt over an exchange point
  + I was learnt over a private peering connection

These are all markers to be used in setting internal policy, so the choice of numbers really doesn't matter. You can add or remove characteristics from your list when necessary without having to renumber anything. You can (and probably should) strip all these attributes before sending routes to EBGP peers, so nobody else has to see them.

Specifying a list of characteristics that seem like they might one day be useful but which today do nothing to influence routing policy seems like a waste of effort. People might better spend their time checking that all their customer sessions have accurate import prefix filters.

Joe

You can & definitely should strip those community values on announcements you
receive from EBGP peers. Interesting things happen if you let others turn
your routing policy knobs when you think they can't reach them.

Agreed.

Likewise, when you receive communities (and MEDs, ugh!) [if possible] you
should reset them (v. employing 'additive'). Unnecessary propagation and/or
uniqueness of many attributes (especially transitive) can that go unnoticed
often have a significant impact on efficiencies of BGP update packing --
which subsequently impacts convergence, CPU & memory resource utilization,
etc...

-danny

> You can & definitely should strip those community values on announcements you
> receive from EBGP peers. Interesting things happen if you let others turn
> your routing policy knobs when you think they can't reach them.\

Agreed.

Likewise, when you receive communities (and MEDs, ugh!) [if possible] you
should reset them (v. employing 'additive'). Unnecessary propagation and/or

Hmm.. assuming you're interconnecting at multiple points with the same ASN they
will probably want to indicate to you where to send traffic to them using MEDs,
if you go stripping them out you lose that info, check the peering policy.. this
may put you in breach.

Even without a breach of policy the MED will help find the best path to a route
thats identical at two points and if you take it out you lose that.

Altho I'd agree if you'd say to clear the communities and MEDs on egress, thats
an okay thing to do.

Steve

Perhaps folks are foolish enough to put "MUST accept MEDs" in a bilateral
peering agreement (note that if money is attached the circumstance change,
but routing breaks all the same). They should be cautious, however, not
only are MEDs the most obvious trigger for persistent route oscillation,
they _very often break with aggregation (unless you're foolish enough to
accept more-specifics as well!) and if compared between multiple ASes (or
even in the same AS) often turn your "cold-potato routing" into
"mashed-potato-routing" because of disjoint policies between different
domains, or downright stupid MED-derivation mechanisms.

Not intending to turn this into an MED rant, but more than a few of us have
experienced brokenness on account of MEDs in the past .. NANOG and IDR WG
archives have addressed these concerns a number of times.

-danny

Practical implementation note:

The vast majority of the internet is completely incapable of setting
correct MEDs. Even if they wanted to, it is often technical impossible due
to aggregation. Realistically, MEDS usually break more than they help. If
you want to improve connectivity, peer more.

comments inline...

>
> > You can & definitely should strip those community values on announcements you
> > receive from EBGP peers. Interesting things happen if you let others turn
> > your routing policy knobs when you think they can't reach them.\
>
> Agreed.
>
> Likewise, when you receive communities (and MEDs, ugh!) [if possible] you
> should reset them (v. employing 'additive'). Unnecessary propagation and/or

Hmm.. assuming you're interconnecting at multiple points with the same ASN they
will probably want to indicate to you where to send traffic to them using MEDs,
if you go stripping them out you lose that info, check the peering policy.. this
may put you in breach.

Even without a breach of policy the MED will help find the best path to a route
thats identical at two points and if you take it out you lose that.

All a matter of perspective. I would assume most people want to use
closest exit on their networks. Imagine how nice it would be if you could
hand off traffic to a peer that is your closest exit, then force them to
carry the traffic back to you at that same point from across the country
or across the globe!

Altho I'd agree if you'd say to clear the communities and MEDs on egress, thats
an okay thing to do.

Spank me if I'm wrong here, but you don't pass MEDs on transitively
anyway. And if you strip communities off, you limit your
peers/customers/providers from being able to use the same control that you
are asking for.

Guy Tal

In a message written on Fri, May 16, 2003 at 05:28:37PM -0500, Guy Tal wrote:

All a matter of perspective. I would assume most people want to use
closest exit on their networks. Imagine how nice it would be if you could
hand off traffic to a peer that is your closest exit, then force them to
carry the traffic back to you at that same point from across the country
or across the globe!

Since this started off talking about customers, I must also point
out:

Many customers want MEDs to be honored. They don't want their
transit provider, who they are paying money to carry the bits where
they want them to be, to be closest exiting to them.

I would think the most common configuration in large networks is to
honor meds from customers, not honor them from peers, but send them
to peers. Note I said common, and not majority.

Do MEDs have their problems? Sure. Are they worse than the
alternatives? I don't think so. A lot of people do a lot of
handwaving about how dangerous it is to use meds. I find that
funny, working on a global network that uses them without major
problem. Do you have to avoid some situations, sure...but that's
no different than if you don't use them. I know more than a few
networks that avoid MPLS traffic engineering through clever use of
meds, for instance, a good trade off in my book.

At the end of the day the best advice I have is to be mindful of
what you do with MEDS. Too many people like to ignore them, and
that is a problem. Don't want to send them, fine, but be religous
about getting rid of them everywhere or you'll cause problems.
Want to use them, fine, but make sure they mean something and
aren't garbage. Ignoring the consequences of meds in your config
choices _will_ cause you problems.

Spank me if I'm wrong here, but you don't pass MEDs on transitively
anyway.

Correct. As a matter of fact, even advertising MEDs to IBGP is left as "an
implementation issue", not a protocol requirement.

And if you strip communities off, you limit your peers/customers/
providers from being able to use the same control that you are
asking for.

As everyone has different policies, they're likely stripped or ignored on
ingress (or somewhere across the world) anyways. Given, you'd accept them
on ingress from transit peers for RFC1998ish stuff, and perhaps under
special circumstances from bilateral peers, but that doesn't mean you ever
need to carry them past the ingress BGP router into your own network.

The effects of propagating what's essentially garbage needlessly have real
impacts on the convergence and stability characteristics of the global
routing system. It essentially falls back Postel's robustness principle
with "[...] be conservative in what you send".

Though I've never put anything formal together (for general consumption), I
have performed testing and seen the effects the presence of needless
attributes have on efficiencies of BGP update packing (and all things
subsequent), and they are very real.

-danny

Since this started off talking about customers, I must also point
out:

Many customers want MEDs to be honored. They don't want their
transit provider, who they are paying money to carry the bits where
they want them to be, to be closest exiting to them.

They want another feature, and someone sold them with the "we'll accept MEDs
from you and not do closest-exit like your peers" line. They forgot to
mention route oscillation might occur, or if the customer does any form of
intelligent aggregation MEDs are probably broken, or if things aren't
tweaked perfectly things can be worse than closest-exit, etc.., etc..

I've seen MEDs work "as advertised" (no pun intended :wink: in several
configurations, but in general I've seen them break things first-hand in 3
very large networks.

I would think the most common configuration in large networks is to
honor meds from customers, not honor them from peers, but send them
to peers. Note I said common, and not majority.

"most common" would imply majority. I doubt that's the case.

At the end of the day the best advice I have is to be mindful of
what you do with MEDS. Too many people like to ignore them, and
that is a problem. Don't want to send them, fine, but be religous
about getting rid of them everywhere or you'll cause problems.

You'll fix more problems then you'll cause, guaranteed. Folks are
mesmerized by tuning yet another knob and assuming everything is dandy
because they can ping some destination. It's more than that, much more.
Take the update packing comments earlier as yet another effect.

Want to use them, fine, but make sure they mean something and
aren't garbage.

How exactly do you make sure you're peers MEDs aren't garbage? Accept
more-specifics? Configure and maintain their routers? And if they're
multi-homed to another network and accept MEDs from them do you simply
configure "always-compare-med" in your router and assume things are great?
They're probably not.

Most folks seem to have enough of a problem deriving their own.

Ignoring the consequences of meds in your config
choices _will_ cause you problems.

Yes, that's why you remove them and understand the consequences of not doing
so. RFC 3345 provides one such example, though I'm certain that aggregation
breaks MEDs more often than anything.

MEDs will work to influence route selection, no doubt, but you'd better read
the fine print and between the lines.

-danny

> >
> > > You can & definitely should strip those community values on announcements you
> > > receive from EBGP peers. Interesting things happen if you let others turn
> > > your routing policy knobs when you think they can't reach them.\
> >
> > Agreed.
> >
> > Likewise, when you receive communities (and MEDs, ugh!) [if possible] you
> > should reset them (v. employing 'additive'). Unnecessary propagation and/or
>
> Hmm.. assuming you're interconnecting at multiple points with the same ASN they
> will probably want to indicate to you where to send traffic to them using MEDs,
> if you go stripping them out you lose that info, check the peering policy.. this
> may put you in breach.
>
> Even without a breach of policy the MED will help find the best path to a route
> thats identical at two points and if you take it out you lose that.

All a matter of perspective. I would assume most people want to use
closest exit on their networks. Imagine how nice it would be if you could
hand off traffic to a peer that is your closest exit, then force them to
carry the traffic back to you at that same point from across the country
or across the globe!

Okay perhaps I didnt add enough detail, I'm not suggesting that you should
accept them without sanity but within a city or region it helps to know where
the best exit point is for that route.

In my own situation I peer with some networks several times within the same
building and its nice for them to hint to me where they want my traffic and vice
versa, if I want to distribute load I send my hints to them.

> Altho I'd agree if you'd say to clear the communities and MEDs on egress, thats
> an okay thing to do.

Spank me if I'm wrong here, but you don't pass MEDs on transitively
anyway. And if you strip communities off, you limit your
peers/customers/providers from being able to use the same control that you
are asking for.

Hmm is the first bit optional? :wink: Okay again I perhaps wasnt specific enough,
I'm suggesting the MEDs and communities are useful between two peers who may be
peering at multiple points, so this is engineering choices when the two paths
are identical and all you have is the entry/exit point to choose.

Steve

The first bit definitely wasn't RFC compliant and is probably not AUP
compliant either. :confused:

But on to more serious matters, you just have to be very careful that your
policy is implemented uniformly. And don't forget that there are other
factors that are examined before MED is looked at.

Guy

There are several different methods possible, however be careful with
using the same sledge hammer for every sized project.

Small ISPs with only a few eBGP neighbors (i.e. less than a dozen) and
a few network prefixes (i.e. less than a 100) probablly should stick with
hardcoded, explicit prefix and as-path filters. Coordinate the occasional
updates to the filters with your upstreams (since they should be
filtering your announcements on ingress anyway). You are less likely to
mess things up, and its simplier to understand if another network
engineer needs to debug things later. You also tickle fewer software
paths (and potential bugs) through the router code.

Large ISPS (more than 500 eBGP neighbors and 5000 prefixes) are going to
need some automated and dynamic mechanisms. You should always ingress
filter announcements from downstream neighbors and customers with an
explicit, positive prefix and AS filter (a bogon filter is not
sufficient). ANS was the only major commercial provider I knew which
explicitly configured BGP announcement filters for every network prefix
from every source. According to studies, about 70% of large ISPs
dynamically tag prefixes with community attributes to distinguish between
different types of prefixes (e.g. customer, peer, internal, etc).

Because community attributes are dynamic, and sometimes subtle, they
have been responsible for some huge network leaks. Unfortunately, most
vendors' implemenation of eBGP results in the announcement all network
prefixes in the BGP table by default. Its up to you to prevent the
default behaivor. If you use communities, I would suggest you configure
the default to block the network announcement. That way if you
accidently misconfigure something else, somewhere else, sometime later,
and forget to set the correct community, the network announcement will get
dropped.

Large ISPs probably also want to use a few insanity filters. Its not
generally practical to customize hardcoded filters across a large network.
So they tend to be limited to just the perpetually insane.

If you are a medium sized ISP, you are in the awkard stage. Stick with
the simple stuff until you have a good reason to change to more
complicated methods.