bgp route-map

Mailman List Mirror (Read Only)
1

Hi all,

Wondering if anyone would know whether such feature in IOS exists or not...

Most of the time, people use route-maps on bgp neighbors or peer-groups to set
an attribute,etc on a prefix that is being announced OUTbound or INbound.

However: On prefixes being announced to me INBOUND, is there a feature to set
in route-map so that it checks whether the advertised prefix is already existing
in local RIB?

Like for example, I am one of the users who receive bogon advertisements from
Rob's route-server.

Now, when I receive prefixes either from my upstream AS or my customers doing
bgp with me, I can setup a route-map on the neighbor so that it compares the
prefix being announced by neighborAS with existing Rob's bogon prefix in the RIB
with bogon route-server community 65333:888.

If the prefix being announced gets a match with existing prefix with 65333:888
already in the router, the route-map would cause a DENY. Thus, making Rob's
bogon announcement from his route-server, a bogon route filtering list for me
to use on my customers/peers..

If you are not understanding what I am saying, feel free to yell at me to clear
up..

This would make it much easier to create dynamic bgp-based route filtering list
in my opinion... I am not here to discuss the feasibility of whether doing or
inventing this dynamic method of filtering bgp routes; I am rather asking this
question to see if anyone is doing something similar to this as it may be useful.

Thanks!

-hc

2

I don't think what you are suggesting is directly possible, although I can think of
something that accomplishes the same thing, and only requires extra configuration on
the peering session with the route server.

For prefixes recieved from the bogon route server, apply a route map that will (1)
send traffic to a Null0 bit sink and (2) set the local preference for these routes to a
value suitably large so that the same prefixes learned from other peers never get
used.

-w

3

Yes, I've tried that too.. But what I am thinking of doing is, using a route-map/bgp-announcement based version of building 'prefix-list' or 'distribute-list' to decide whether to accept route or not..

But as you said, I don't think that is possible heh..

Thanks!
-hc

4

Yes, I've tried that too.. But what I am thinking of doing is, using a route-map/bgp-announcement based version of building 'prefix-list' or 'distribute-list' to decide whether to accept route or not..

But as you said, I don't think that is possible heh..

Except that what you are proposing would allow your customer to announce 2 /16's just fine from within one of rob's bogon /8's, as the 2 /16's wouldn't be in your rib.

5

Of course; since there isn't a feature, let's propose another idea: an
option to enable "le 24" or "le 32/whatever" to cover specific
announcements.

-hc

6

This reminds me of something I've wanted to bring up to the community
for a long time. I'd like to see a "route programming language" that
gets implemented in a multi-vendor way. No, I'm not talking about like
RPSL, but rather, let me give some examples:

1) Pull out session details via "variables":

      route-statement foo {
          if ($route has community(1234:$session{'asn'})) {
              set_asprepend($route, "1234 1234")
          }
      }

2) Check for the route in other routing tables:

      route-statement bar {
          if ($route in ospf) {
             set_localpref($route, 10)
          }
          if ($route in bgp && $route has communty(1234:666))
             drop($route)
          }
          set_localpref($route, 100)
      }

3) Scan other route tables:

      route-statement baz {
          if ($route supernet-in bgp) {
              drop($route);
          }
      }

4) Other weird stuff:

      route-statement hack {
          if ($route = "1.2.3.0/24") {
              announce_route("1.2.3.10/32", "192.168.1.1")
          }
      }

Basically all the data on the box would be made available via global
variables (eg, session IP, session ASN, bgp version, etc), and all
dynamic data would have interfaces (eg scan other routing tables,
acl's, etc). You'd write a "function" which would get passed a
route object, and act on it. Functions could further pass that
route on calling other functions (allowing you to create common
policy).

Sadly, while I can think of many cool things you could do, I know
little about how to really design a languge. I also have no idea
how bad other people want this, how hard it would be to get vendors
to implement, etc. Feel free to add your support, or call me a
crackpot.

7

http://bird.network.cz/

does pretty much what you want.

-Dan

8

Hello,

The reason for me to come up with this idea/question was so that IRR information
can be used on a seperate box acting as a "Prefix-list server", which would be
basically a route server that distributes prefixes that should be filtered on
inbound announcements..

It would be great for integration with RPSL perhaps; RtConfig already does it,
but need something that's distributed/dynamic/automated; publishing filtering
information over BGP sounds interesting to me..

-hc

9

Date: Mon, 25 Aug 2003 15:30:01 -0400
From: Matt Levine

Except that what you are proposing would allow your customer
to announce 2 /16's just fine from within one of rob's bogon
/8's, as the 2 /16's wouldn't be in your rib.

Unless the route server processed all routes (several providers
will do multihop EBGP over one extra hop) and delivered the
"finished" RIB back to the border routers.

Alternatively, the route server could wait for bogon routes to
appear, then reactively inject a null route with higher
local-pref... but having two RIB entries for every bogon prefix
doesn't sound terribly enticing.

Routers are good at forwarding, but not terribly flexible when it
comes to manipulating the RIB. Considering certain routers' lack
of CPU power, it becomes even more tempting to offload RIB
processing...

My kooky $0.02,
Eddy

10

In a message written on Mon, Aug 25, 2003 at 01:11:56PM -0700, Dan Hollis wrote:

http://bird.network.cz/

does pretty much what you want.

Yeah, their filter stuff is going in the right general direction.

Of course, for it to be of real interest at least Cisco and Juniper need
to support it (and preferably the same "it). :slight_smile:

11

This reminds me of something I've wanted to bring up to the community
for a long time. I'd like to see a "route programming language" that
gets implemented in a multi-vendor way. No, I'm not talking about like
RPSL, but rather, let me give some examples:

I'll half agree with this. If you can't get the necessary functionality
out of your existing policy language, you probably need a better policy
language. However, if all you're going to do is "if" and "then", an actual
programming language is probably not going to be in your best interests.

Let's just discard Cisco route-maps as nearly useless for the moment, and
talk about Juniper policies for a second. They're mostly reasonable as a
policy language... They do if-then, subroutines, chained statements, and
they let you write some fairly complex things which mostly get the job
done. Slapping an if () {} around it probably isn't going to do much to
improve things, as the areas that need improvement are not (mainly) based
in the syntax.

Let's take an example of something that they need to add... Say I have a
BGP community structure which let's a customer tag a route with a specific
community to make it do a specific thing (lower localpref, only announce
to certain people, set nexthop to something that discards, whatever). Now
let's say that I want to extend this functionality so that they can do
similar things on a per-ASN basis, as in let them specify two out of five
transits or peers which they don't want to announce the route to. Under
the current policy language, you would have to either write a policy
statement per ASN (as well as an as-path statement) and apply it to every
session, or add a term to a policy statement which is applied to a policy
statement which is applies to every session. There is no way to have the
policy parse "6461:666" into "6461" and "666", check against the
configured asn of the peer this policy is being applied to, and correctly
take action.

Now, nothing about the above example requires if () { }, variables, memory
allocation, or anything else even halfway complicated. All it requires is
a little bit more thought in the design of the existing policy language,
and of course the common sense to realize that maybe you should listen to
all those engineers on nanog 'cause they might actually know something
about operating networks.

Sadly, while I can think of many cool things you could do, I know
little about how to really design a languge. I also have no idea
how bad other people want this, how hard it would be to get vendors
to implement, etc. Feel free to add your support, or call me a
crackpot.

Be my luck some tard would write it in perl or tcl anyways...

12

Foundry supports a feature called Cooperative BGP4 Route Filtering
(http://www.foundrynetworks.com/services/documentation/ecmg/BGP4.html#63462)
                                                                                
Some digging around at juniper.net reveals that Juniper also supports
ORFs but only on the ERX platform
(http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-routing-vol2/html/
+bgp-config9.html).
                                                                                
Cisco also supports it since 12.0
(http://www.cisco.com/en/US/products/sw/iosswrel/ps1612/products_feature_guide09
+186a008008088c.html)
                                                                                
It basically sends filters defined in prefix-lists in route refresh
messages.
                                                                                
A more formal definition of it can be found in the following draft
(http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-09.txt)

13

Again...

If folks were to implement explicit prefix filtering
*everywhere* it wouldn't be necessary to filter only
bogons and other miscellany explicitly. Something of
this sort would only "lower the lazy bar" (is it
possible?) for the clueless and/or lazy (those which
Rob's list currently accommodates, which is better than
nothing, BUT.. -- no offense Rob, I'm pretty sure our
beliefs are aligned here :-).

If folks want to filter, please, please, PLEASE, employ IRR
infrastructure and filter customers *AND* peers explicitly.
If your vendors have issues with this, push them to fix it.
Then you don't have to worry about bogons, max-prefixes,
route hijacking, de-aggregation, or...

Then we can worry about IRR infrastructure hardening and
accuracy and derive explicit data plane filters from the
output, as well as other tangible benefits.

Is it really that hard?

-danny

14

Hi, NANOGers.

] If folks were to implement explicit prefix filtering
] *everywhere* it wouldn't be necessary to filter only
] bogons and other miscellany explicitly.

Agreed! Simple edge filters make this problem go away. While
I and the rest of Team Cymru are happy to provide this service,
we will gladly find other things to do if folks ubiquitously
employ edge prefix filters. :slight_smile: We attempt to convey this sort
of thing in our templates. If folks need assistance building
their filters, feel free to ping on us. We charge only the
occasional cup of coffee. :slight_smile:

   <http://www.cymru.com/Documents/secure-bgp-template.html>
   <http://www.qorbit.net/documents/junos-bgp-appnote.htm>

] ...no offense Rob, I'm pretty sure our beliefs are aligned here :-).

None taken, I completely agree.

Thanks,
Rob, not just the "bogon guy." :slight_smile:

15

Hey,

You ARE correct. If everyone employs IRR and put explicit filters everywhere,
it'd be the perfect world..

I don't consider this as lazy. I'd rather consider it as efficiency.
Managing a filter list on one or a few route-servers rather than an
AS with hundred edge routers is so much time saving and less humanerror-prone.

IRR is great, and it should be used to maximum extent as possible. I've seen
people filtering accordingly to IRR properly, and also seen people creating
their own manageable applications that work beatifully on *nix boxes.

Announcing filtering list over BGP inside an AS would be efficient management
to an extent however...

-hc

16

... if everybody used the IRR to build explicit filters everywhere, if everybody kept their objects in the IRR up-to-date, and if there was some appropriate authorisation scheme in place to allow you to trust the data in the IRR implicitly, it'd be a perfect world.

The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial.

Joe

17

Joe,

  You of course are correct with the trusting of the data, but
we are in a somewhat of a chicken and egg situation. If people don't
trust the IRR, they don't filter on it, and then the data is
allowed to get out of date. But people who maliciously add bogus
(or excessive route objects for example) are easy to track down. This
is what the maintainer objects are for and why the IRR software keeps
logs of the messages (including headers) that are submitted.

  I think the key here is that filtering is a good thing(tm).
People who are not using it as their baseline (with their own
custom additions for their own AS based policy decisions of course)
are asking for trouble. Hardly a month (or even a week) goes by
where I don't see that one of our peers has attempted to leak
the routing table to us. max-prefix and peer filtering help
mitigate the risks to our network.

  If you don't trust other IRRs, run your own where you do have
a stricter trust model via pgp/gpg.

  these are both tools that can be used in conjunction with each
other and should be.

  Effort put into the automation of these will pay for itself.
Customers will be able to update route objects via the web or
via email. Reduced support costs in handling and authenticating
requests manually, as well as the ability to audit these either
realtime or in a delayed fashion.

  - Jared

18

I fully agree with the cart/horse chicken/egg analogy.

If SPs began employing IRRs more fully and more work
went into commercialization of IRR infrastructure and
tools (and perhaps some RIR feedback loop were created)
they'd improve.

Instead, folks are running about designing new protocols
far more complex than BGP already is, that *still* require
some "authority". When in reality, 99% of the
vulnerabilities could have been solved with what was in
place 10 years ago.

Folks are striving for "perfect security", which is fine,
but they've ignored the reasons why we don't even have
"crappy" security.

-danny

19

>
> >You ARE correct. If everyone employs IRR and put explicit filters
> >everywhere,
> >it'd be the perfect world..
>
> ... if everybody used the IRR to build explicit filters everywhere, if
> everybody kept their objects in the IRR up-to-date, and if there was
> some appropriate authorisation scheme in place to allow you to trust
> the data in the IRR implicitly, it'd be a perfect world.
>
> The IRR is currently a reasonable tool to use to avoid listening to
> routes which are advertised by mistake from peers who populate the IRR
> accurately. It's not a reasonable tool for avoiding maliciously bogus
> routes, since sticking maliciously bogus information in the IRR is
> trivial.

        Joe,

        You of course are correct with the trusting of the data, but
we are in a somewhat of a chicken and egg situation. If people don't
trust the IRR, they don't filter on it, and then the data is
allowed to get out of date.

The trick is for IXPs and NAPs to have terms that *require* people to:-
         1) put their routes in an IRR
         2) keep them accurate

The LINX in London does (1) as a joining requirement and contractual obligation, and applies pressure where (2) cause a problem. How many others follow similar practices?

20

Well, I don't think it's particularly easy. Generating the filters isn't the hard part, but getting them inside routers has always been quite a challenge. But that should be better than it used to be now.

By the way, you don't mention filtering based on routing registry information in your book. (I do mention it in mine but don't explain how to do it as I have never done it myself.)