New release 1.3.0!

[Andrew Lemin]

Hi Ondrej,

Thank you for your time considering this, it is greatly appreciated.
I understand how this works, very clever. This is indeed quite an inventive hack :)

I will have a play and see if we can get it to work.

Our edge firewalls actually advertise around 80 RIP routes at the moment (we have an awful lot of VPNs here in the head office) and so this would be a lot to program but not unfeasible.

The limitation is that approximately once a month we have to add more VPNs as we take on more remote locations and so I would need to continually update the BIRD configuration every time we add more VPNs to gain multipath access for the newly added tunnels etc.


I will definitely let you know how we get on. Please, please do consider rewriting RIP with emcp. We would be in your debt and after all, whilst RIP is archaic (I wish we could use a newer protocol) it is still the most widely used routing protocol in SMB network devices. Obviously high end devices from Cisco, Juniper etc support OSPF but Netgear, Draytek, Firebox etc etc only support RIP.


I would love to install some Cisco VPN concentrators however we like many other SMB companies simply do not have the in-house skills to manage these properly, and so we are forced to use basic kit which I can train others (non-networking staff) to program/manage in my absence.

Thanks again for your time and kind help.

 Andy.


-----Original Message-----
From: Ondrej Zajicek [mailto:santiago at crfreenet.org]
Sent: 31 March 2011 15:42
To: Andrew Lemin
Cc: Tony Vroon; Ondrej Filip; bird-users at network.cz
Subject: Re: New release 1.3.0!

On Thu, Mar 31, 2011 at 11:09:54AM +0100, Andrew Lemin wrote:
>    Great work to all involved J
>
>    We have looked through the notes in the git repository etc however we are
>    still confused as to whether multi-path support can be 'made to work' with
>    RIP or not?

No, sorry. Current RIP was not ready for simple integrating multipath like in OSPF. I will probaly rewrite it in a near future.

I thought about your case and i found a crazy hack, that should bring multipath routes to your particular case (two RIP neighbors with a fixed number of routes, just import from RIP):

table tn;
table te;
table t1;
table t2;

protocol static st_null
{
        table tn;
        export all;
        preference 80; # lower than RIP

        route 10.131.0.0/16 reject;
        ... (other routes)
}

protocol static st_ecmp
{
        table te;
        export all;

        route 10.131.0.0/16 multipath via 192.168.214.1 via 192.168.215.1;
        ... (other routes)
}

protocol rip EDGE1RIP
{
        table t1;
        ... (like in your config)
}

protocol rip EDGE2RIP
{
        table t2;
        ... (like in your config)
}


protocol pipe pn1
{
        table tn;
        peer table t1;

        export all;
        import none;
}

protocol pipe pr1
{
        table t1;
        peer table master;

        export where proto = "EDGE1RIP";
        import none;
}

protocol pipe pg1
{
        table t1;
        peer table te;
        mode opaque; # this is important
        preference 300; # higher than static

        export where proto = "st_null";
        import none;
}

protocol pipe pn2
{
        table tn;
        peer table t2;

        export all;
        import none;
}

protocol pipe pr2
{
        table t2;
        peer table master;

        export where proto = "EDGE2RIP";
        import none;
}


protocol pipe pg2
{
        table t2;
        peer table te;
        mode opaque; # this is important
        preference 300; # higher than static

        export where proto = "st_null";
        import none;
}

protocol pipe pe
{
        table te;
        peer table master;
        mode opaque; # this is important
        preference 150; # higher than RIP

        export where proto = "st_ecmp";
        import none;
}

The idea is simple:

routes from RIP1 came to t1 together with reject route from st_null (through pn1). if route from RIP1 exists, it will be preferred, because it has higher priority than route from st_null. Pipe pg1 would push preferred route (opaque pipe push just a preferred route) from t1 to te, but only if it is from st_null (filter). If the preferred route is RIP1, nothing is pushed. such route in table te would block ecmp route to be propagated to master (beacuse it has higher priority, 300). So if there are routes from both RIPs, nothing is propagated to table te and ecmp route will win. RIP routes are already pushed to master through pr1, pr2.

So to use this, for each prefix from RIP you have to configuure one
(reject) static route in st_null and one ECMP route in st_ecmp.

You should see something like:

10.131.0.0/16      multipath [pe 16:35] * (150)
        via 78.128.195.198 on eth0 weight 1
        via 78.128.195.199 on eth0 weight 1
                   via 78.128.195.198 on eth0 [EDGE1RIP 16:35] (120)
                   via 78.128.195.199 on eth0 [EDGE2RIP 16:35] (120)

(if both routes from RIP are present - so these are three routes, two from RIP and one multipath from pe)

--
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

Monitor Computer Systems Limited
Company Registration Number: NI 17805
Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED