Re: [babel] Babel filtering: routing policies

[Mahesh Jethanandani <[e-mail]>]

Hi Juliusz,

Following up on this e-mail to understand how to implement the routing policies for Babel.

> On Jul 24, 2019, at 2:36 PM, Juliusz Chroboczek <[e-mail]> wrote:
> 
> 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.

In order to make sure we are talking the same language, would you say a given chain is equivalent of a “defined set” as defined by draft-ietf-rtgwg-policy-model <https://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-06>? I understand that these are babel specific, so I will extend the policy model to add these chains as “defined sets". I am also assuming that there is one instance of each chain (or defined set). In other words, we are not looking at multiple “in” chains, as an example.

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

I see two more, src-prefix and table. Is there more?

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

I am looking at the following conditions (in the routing policy model language) specified in the man page.

       ip prefix
              This entry only applies to routes in the given prefix.

       eq plen
              This entry only applies to routes with a prefix length equal to plen.

       le plen
              This entry only applies to routes with a prefix length less or equal to plen.

       ge plen
              This entry only applies to routes with a prefix length greater or equal to plen.

       src-ip prefix
              This entry only applies to routes with a source prefix in the given prefix.

       src-eq plen
              This entry only applies to routes with a source prefix length equal to plen.

       src-le plen
              This  entry  only  applies  to  routes with a source prefix length less or equal to
              plen.

       src-ge plen
              This entry only applies to routes with a source prefix length greater or  equal  to
              plen.

       neigh address
              This  entry only applies to routes learned from a neighbour with link-local address
              address.

       id id  This entry only applies to routes originated by a router with router-id id.

       proto p
              This entry only applies to kernel routes with kernel protocol number p.  If neither
              proto  nor  local  is  specified, this entry applies to all non-local kernel routes
              with a protocol different from "boot".

       local  This entry only applies to local addresses.

       if interface
              For an input filter, this specifies the interface over which the route is  learned.
              For  an  output  filter,  this  specifies  the  interface  over which this route is
              advertised.  For a redistribute statement, this specifies the interface over  which
              the route forwards packets.
Note, the policy module defines a default set of conditions like prefix sets, so some of your examples should be take care of with them.

Anything else that I am missing?

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

Mahesh Jethanandani
[e-mail]