Home page logo
/

nanog logo nanog mailing list archives

Re: Route Programming (was Re: bgp route-map)
From: Haesu <haesu () towardex com>
Date: Mon, 25 Aug 2003 16:12:13 -0400


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

-- 
Sincerely,
  Haesu C.
  TowardEX Technologies, Inc.
  WWW: http://www.towardex.com
  E-mail: haesu () towardex com
  Cell: (978) 394-2867

On Mon, Aug 25, 2003 at 04:02:22PM -0400, Leo Bicknell wrote:

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.

-- 
       Leo Bicknell - bicknell () ufp org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request () tmbg org, www.tmbg.org




  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault