New release 1.3.0!

[Ondrej Zajicek]

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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20110331/f6adff8d/attachment-0001.asc>