Need some help about static routing tables on two hosts.

[Ondrej Zajicek]

On Wed, Jul 25, 2012 at 11:46:10PM +0300, Eliezer Croitoru wrote:
> i' kind of new in some of this stuff so i need basically directions.
>
> i am working on a lab for a real implementation.
> the way things works now is like that:
>
> 10 proxies behind 2 LB that works based o linux route policies.
> the policies are "from ip/mask use routing table 10" will take all  
> traffic from these sources through proxy 10 route that is store in linux  
> routing table 10 that contains "default via proxy_ip".
>
> there is a "master" server that gets live extended status of each proxy.
> it can be up\down load = 80% etc...
> and if a change of a route on the LB should be changed it is being  
> committed using a script over ssh almost manually.
..
> so i want the master to monitor the proxy servers and in a case of  
> change in the network status of a proxy for any reason to let say down i  
> would change the routes in specific table and then send bird "configure  
> soft" to update the settings.
>
> so if there is a nice method of combining all bird capabilities and some  
> routing protocol for the process i will be very happy to hear about it.

Hello

That is interesting setup. If you want just to synchronize tables
between master and LB, you could do that for one table on master and
one table on LB by using e.g. BGP (see comment below), but it is
problematic to synchronize several such tables. I guess that you could
have several parallel BGP sessions, one for each table, but you would
probably have to use different pair of IP addresses for each BGP
session. Note that if 'master' crashes, BGP sessions would go down and
default routes in LBs would disappear.

> i have tried to use bgp in a local as between the  master and the LB but  
> it seems that on the LB when he gets the static route it states the 
> route:
> 0.0.0.0 .... unreachable.

This is probably caused by 'gateway recursive' mode on BGP (default for IBGP).
See 'gateway direct' option and then question 'IBGP does not work ...' in FAQ:

https://git.nic.cz/redmine/projects/bird/wiki/FAQ



Another, completely different way how to implement this would be that
'master' would just announce which proxies are 'usable' (through one BGP
session) and LBs would fill all tables from this information. That could
be done using static recursive routes. For example for proxy 10.100.1.10
we will use auxiliary pseudo-IP 10.100.2.10 and if 10.100.1.10 is
usable, master will propagate pseudo-route:

10.100.2.10/32 via 10.100.1.10

to LB. On LB, there will be static recusive route:

route default recursive 10.100.2.10

If master propagated that pseudo-route, this recursive route will appear as:

route default via 10.100.1.10

otherwise it will appear as

route default unreachable

You could have such recursive route for each proxy so you will get a
table with a set of default routes that are either corrrect or
unreachable. Unfortunately being unreachable does not lower route
priority, so you would have to use another table connected with pipe and
in pipe filter you do something like 'if dest = RTD_UNREACHABLE then
prio = 1'. this will move all unreachable routes to the bottom, so the
reachable route with highest configured priority will be used. This have
to be replicated for each table on LB (probably with different priority
for each static routes so that different one will be used as best one),
only the table with pseudo-routes received from master will be shared.

It is pretty complex and i don't know if it does what you really need,
but it should work.

-- 
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/20120726/dabaaca7/attachment-0001.asc>