[Cerowrt-devel] Fwd: [Babel-users] ANNOUNCE: Babel-S update

[Cerowrt-devel] Fwd: [Babel-users] ANNOUNCE: Babel-S update

[Dave Taht]

I have longed for the source specific functionality for several
reasons. I am sore tempted to replace quagga with this version of
babeld because:

0) homenet compatible patches for quagga ospf haven't been merged yet
1) I would like to test ipv6 native, 6rd, and several forms of tunnel
at the same time. babels will let me do this
2) the mptcp congestion control problem is fascinating

Is there anyone using quagga's other routing protocols currently and
can't live without being able to add in ripd, bgp, or ospf?



---------- Forwarded message ----------
From: Matthieu Boutier <boutier@pps.univ-paris-diderot.fr>
Date: Sat, Dec 14, 2013 at 2:31 AM
Subject: [Babel-users] ANNOUNCE: Babel-S update
To: babel-users@lists.alioth.debian.org


Dear all,

There is many changes in the source-sensitive version of babeld
since the last announce. Recall that the code is available at:

    git clone -b source-specific
git://git.wifi.pps.univ-paris-diderot.fr/babels.git
    http://git.wifi.pps.univ-paris-diderot.fr/?p=babels.git
    https://github.com/boutier/babeld

CHANGES:

- configuration:

    - filter: you can filter source-specific routes using "src-ip", "src-eq",
        "src-le", "src-ge".  It works as "ip", "eq", etc.

    - importing specific routes: now, this is done via filters.  Instead of
        using "allow", just use "src-specific <prefix>".  This can be done
        either in the "redistribute" or "in" filters.

        For example, in order to redistribute all v4 routes as specific to
        192.268.1.0/24, use

            redistribute src-specific 192.168.1.0/24

        Be worry when using it in the "in" filter... You will found details and
        more examples in the manpages.

- implementation:

    - IPV6-SUBTREES: Since Linux 3.10.12, source-sensitive routing tables can be
        used as we expected.  If you compile the code with '-D IPV6_SUBTREES',
        it will use the native netlink API instead of using multiple routing
        tables with rules over it.  Of course, the IPv4 part of the code is let
        unchanged.

        The best solution would be to check it dynamically.  If someone knows
        how to do that...

    - requests: Source-specific request messages are implemented.

- other:

    Many bugs have been fixed, especially for the interoperability and TLV
    compression mechanism.

Best regards,
Matthieu


_______________________________________________
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users


-- 
Dave Täht

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

Re: [Cerowrt-devel] [Babel-users] ANNOUNCE: Babel-S update

[Dave Taht]

I am going to take the silence on this issue as affirmation that I can
swap out things for babel-s whenever I get around to it. I've been
dying to try out mptcp for AGES, and source specific routing will make
it easy.



Recently there was a bunch of discussion here about mobility between
cerowrt access points. There are many compelling reasons for doing
this in the Real World, and I guess we should get around to
documenting how to do it. However, what it requires is bridging
together wired and wireless or, as one person mentioned, tunnelling
back stuff over GRE. As for the latter, there is some work that just
landed in the openwrt mainline that allows for larger than 1514 MTUs
on at least some atheros chipsets, I have not verified if the wndr3800
is one of them. I am other wise kind of allergic with mucking with the
MTU as would be required for GRE but can be pursuaded otherwise.

As for the former, that's how the world does it, bridging together two
very different sorts of wireless, with very different and much faster
forms of ethernet, and I personally, hate it, and hate what a busy
ethernet network can do to a wifi one, and hate how it's depricating
multicast and so on and so forth. I have seen people seriously
proposing bridging 6lowpan to normal networks, proposing data center
bridging on wifi, and it really bugs me, the mediums are so
dissimilar. If bridged together, dhcp also has to get turned off on
the other clients, and if routed most end users end up with multiple
layers of nat.

So (along with homenet) we have pursued fixing routing in ospf and
babel, getting things like dhcpd-pd to work to distribute subnets
properly around a home, fixing multicast service discovery with things
like http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-02 -
etc. It's slow work but making routing rather than bridging less
magical seems a worthy goal??

(Secondly cero specifically puts each technology type on a different
ip address range, which from an experimental perspective makes it
really easy to identify what radio or interface a packet capture or
trace came from. So aside from the ideology I'm wedded to the ip
addressing scheme for the testing)

And that said, there remains a need for mobility that isn't being
addressed in cero in a way that works for enough people.

In my case since day 1 cero has supported babeld and ahcpd, the
combination of which allows for mobility between access points AND
wireless. You can go from ethernet to wireless, to another access
point with wireless, to ethernet, and never lose your session. Even
better, your device can act as a relay for other devices on your
network. I realize that NetworkManager has made things increasingly
difficult to use this mode over the last 7 years, but it is often as
simple as killing NetworkManger and

apt-get install babeld ahcpd
ifconfig wlan0 down
iwconfig wlan0 channel 11 mode ad-hoc essid babel
ifconfig wlan0 up
ahcpd -D wlan0 eth0 # usb0 if you are networked that way too
babeld -z3 -D wlan0 eth0

Am I the ONLY person in the universe that still likes to move between
wireless *and* wired nets, and that prefers his sessions stay up
through these sort of outages? Certainly since the advent of mosh I
care a lot less about keeping everything going...



On Sun, Dec 15, 2013 at 11:07 PM, Dave Taht <dave.taht@gmail.com> wrote:
> I have longed for the source specific functionality for several
> reasons. I am sore tempted to replace quagga with this version of
> babeld because:
>
> 0) homenet compatible patches for quagga ospf haven't been merged yet
> 1) I would like to test ipv6 native, 6rd, and several forms of tunnel
> at the same time. babels will let me do this
> 2) the mptcp congestion control problem is fascinating
>
> Is there anyone using quagga's other routing protocols currently and
> can't live without being able to add in ripd, bgp, or ospf?
>
>
>
> ---------- Forwarded message ----------
> From: Matthieu Boutier <boutier@pps.univ-paris-diderot.fr>
> Date: Sat, Dec 14, 2013 at 2:31 AM
> Subject: [Babel-users] ANNOUNCE: Babel-S update
> To: babel-users@lists.alioth.debian.org
>
>
> Dear all,
>
> There is many changes in the source-sensitive version of babeld
> since the last announce. Recall that the code is available at:
>
>     git clone -b source-specific
> git://git.wifi.pps.univ-paris-diderot.fr/babels.git
>     http://git.wifi.pps.univ-paris-diderot.fr/?p=babels.git
>     https://github.com/boutier/babeld
>
> CHANGES:
>
> - configuration:
>
>     - filter: you can filter source-specific routes using "src-ip", "src-eq",
>         "src-le", "src-ge".  It works as "ip", "eq", etc.
>
>     - importing specific routes: now, this is done via filters.  Instead of
>         using "allow", just use "src-specific <prefix>".  This can be done
>         either in the "redistribute" or "in" filters.
>
>         For example, in order to redistribute all v4 routes as specific to
>         192.268.1.0/24, use
>
>             redistribute src-specific 192.168.1.0/24
>
>         Be worry when using it in the "in" filter... You will found details and
>         more examples in the manpages.
>
> - implementation:
>
>     - IPV6-SUBTREES: Since Linux 3.10.12, source-sensitive routing tables can be
>         used as we expected.  If you compile the code with '-D IPV6_SUBTREES',
>         it will use the native netlink API instead of using multiple routing
>         tables with rules over it.  Of course, the IPv4 part of the code is let
>         unchanged.
>
>         The best solution would be to check it dynamically.  If someone knows
>         how to do that...
>
>     - requests: Source-specific request messages are implemented.
>
> - other:
>
>     Many bugs have been fixed, especially for the interoperability and TLV
>     compression mechanism.
>
> Best regards,
> Matthieu
>
>
> _______________________________________________
> Babel-users mailing list
> Babel-users@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html



-- 
Dave Täht

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