Subject: [babel] Babel filtering: routing policies

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 24 Jul 2019 23:36:54 +0200

Dear Barbara, dear Mahesh,

All distance-vector routing protocols, including BGP and Babel,
intrinsically support flexible routing policies.  In the Babel community,
we consider the way of defining such policies as an implementation
feature, and they are not part of the protocol definition.

The following therefore applies to babeld, the "reference" implementation.

In babeld, we speak about filter chains.  A route goes through each filter
in a filter chain at four points in Babel:

  "in" chain, when the route is learnt from a neighbour;
  "install" chain, when the route is installed in the kernel;
  "redistribute" chain, when the route is learnt from the kernel;
  "out" chain, when the route is announced to a neighbour.

When a filter chain is applied, the individual filters in a chain are
checked, and the first filter that applies to the route is executed.
A filter can perfrom the following actions:

  "allow" -- pass the route unchanged, equivalent to "metric 0";
  "deny" -- drop the route;
  "metric nnn" -- add nnn to the metric value.

There exist other actions, more specialised -- see the manual page for
details.

Babeld implements a rich language for matching routes -- it can match on
next-hop address, on destination prefix, on destination prefix length, on
the router-id of the originating router, etc.  Again, see the manual page
for details.

Examples
========

## Default filters

    in allow

    out allow

    redistribute local allow
    redistribute deny

    install allow

These are the default chains if no filters are defined, and are suitable
for a mesh node with no attached prefixes.  They say that babeld is
promiscuous (it learns all routes and announces all routes), it only
redistributes local node addresses, and installs any routes that it learns
unchanged.

## Traditional router

  redistribute proto 2 allow
  redistribute deny

This overrides the default to not redistribute any local addresses, but to
redistribute any locally attached prefixes.  This is the default behaviour
or a traditional router.

## Traditional router with redistribution

  redistribute proto 2 allow
  redistribute proto 11 metric 32384
  redistribute deny

This says to additionally redistribute any routes learned from
Zebra/Quagga/FRR, but to attach them with a higher metric -- Babel routes
will thus be preferred to FRR routes.

## Stub router

  redistribute proto 2 allow
  redistribute deny
  
  out ip 192.168.42.0/24 allow
  out ip 2001:db8:4242::/48 allow
  out deny

This says to learn routes promiscuously, but to only reannounce routes in
the given prefixes.  This is typical of a stub router, that only announces
routes in the local prefixes.

## Default router

  out ip 0.0.0.0/0 le 0 allow
  out ip ::/0 le 0 allow
  out deny

This router only announces default routes.

## IPv6 border router

  in ip ::/0 allow
  in deny

  out if eth0 ip 2001:db8:4242::/48 le 48 allow
  out if eth0 deny

  out if eth1 ip 2001:db8:5757::/48 le 48 allow
  out if eth1 deny

This router sits at the interface between two networks, and only announces
a route summarising a whole network to the other network.  This reduces
the amount of traffic, at the cost of non-optimal routing.

## Ignoring bad routers

  in if eth0 nh fe80::1 deny
  in router-id 12:34:56:78:9a:bc deny
  in allow

This router ignores routes from a given next hop as well as routes
originated by a given router-id.  This can be used to temporarily
blackhole a mis-configured router, before it is fixed.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 25 Jul 2019 12:56:00 +0200

> The following therefore applies to babeld, the "reference"

I'll add that the Bird implementation uses Bird's filtering language,
which allows filtering similar to that but has a whole different syntax
and semantics. See https://bird.network.cz/?get_doc&v=20&f=bird-5.html
for details.

-Toke