Re: [homenet] source routing requirements for routing protocols

On Tue, Aug 6, 2013 at 4:12 AM, David Lamparter <equinox@diac24.net> wrote:
> On Sat, Aug 03, 2013 at 03:42:44PM +0200, Teco Boot wrote:
>> I tested SADR with Linux IPv6_SUBTREES, with disappointing outcome.
>> I posted my results on devnet, http://www.spinics.net/lists/netdev/msg245231.html
>> Can you verify?
>> I included the posting for convenience.
>
> Indeed I failed to take Linux's routing cache into account.  (Basically,
> since I was testing interactively in a shell, I was too slow to trigger
> this issue.)
>
> So the core logic is correct, but it breaks as soon as there is a cache
> entry.  The way the route cache works, this is a bit annoying to fix
> correctly.
>
> If someone wants to work on SADR on Linux right now, I have a patch that
> partially fixes the cache lookup, but it only works as long as the
> source specifications don't overlap.  [which should be the case in
> homenet most of the time, but note it breaks when there is a route with
> ::/0 source.]
>
> (For the interested, fib6_lookup/_1() and ip6_pol_route() need to be
> restructured.  Also, the "BACKTRACK" macro is completely f*ken useless.
> Not sure if this ever worked.)

git clone git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git

There have been a half dozen commits in linux's net-next kernel tree
around the route cache in the last few weeks, notably one simplified
ip rule for dealing with default routes, another broke out the genid
stuff to make route flushing ipv4 not affect ipv6 and vice versa. Can
I encourage those looking at this to look at that and see what can be
leveraged/improved/fixed/de-borked?

commit 7764a45a8f1fe74d4f7d301eaca2e558e7e2831a
Author: Stefan Tomanek <stefan.tomanek@wertarbyte.de>
Date:   Thu Aug 1 02:17:15 2013 +0200

    fib_rules: add .suppress operation

    This change adds a new operation to the fib_rules_ops struct; it allows the
    suppression of routing decisions if certain criteria are not met by its
    results.

    The first implemented constraint is a minimum prefix length added to the
    structures of routing rules. If a rule is added with a minimum prefix length
    >0, only routes meeting this threshold will be considered. Any other (more
    general) routing table entries will be ignored.

    When configuring a system with multiple network uplinks and default routes,
    is often convinient to reference the main routing table multiple times - but
    omitting the default route. Using this patch and a modified "ip" utility, th
    can be achieved by using the following command sequence:

      $ ip route add table secuplink default via 10.42.23.1

      $ ip rule add pref 100            table main prefixlength 1
      $ ip rule add pref 150 fwmark 0xA table secuplink

    With this setup, packets marked 0xA will be processed by the additional rout
    table "secuplink", but only if no suitable route in the main routing table c
    be found. By using a minimal prefixlength of 1, the default route (/0) of th
    table "main" is hidden to packets processed by rule 100; packets traveling t
    destinations with more specific routing entries are processed as usual.

>
>
> -David
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html