[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quagga-dev
Subject:    [quagga-dev 583] Multiple kernel tables and BGPD,
From:       Howard Wilkinson <howard () cohtech ! com>
Date:       2003-12-25 10:36:06
[Download RAW message or body]

Hi guys, I am new to this list so not entirely sure of the protocol, but 
I have an interesting problem, which reading the users list and looking 
at the development list suggests that this is the right place to ask 
questions and seek advice.

I have a small system distributed over the planet. This system runs 
FreeS/WAN Virtual Private Networks between each of the sites. We have a 
mesh of sites with client and satellite locations appended around a 
central core. Our routing environment uses redundant routes maintained 
by BGP sessions between all of the sites. The BGP sessions run over GRE 
tunnels between the systems running IPSEC tunnels. Each client site or 
satellite office has 3 independent tunnels to each of our core sites. 
These tunnels have priority on their routing so that all traffic will 
flow down one of the tunnels and if this fails the next will be chosen. 
We do this as the tunnels are on firewalled machines (using Shorewall as 
the firewall technology) and asymmetric connections would be blocked by 
the firewalls. Clients sites are not allowed to initiate connections 
into our core or to other satellite sites except for SSH, Traceroute and 
Ping traffic.

Our satellite and core sites have effectively open access, although we 
do place some limits on traffic to and from the firewalls themselves and 
limit traffic between servers inside the core.

This scheme works very well and scales as we add more client and 
satellite sites. However, we have a small problem with Road Warriors. We 
can set up a Road Warrior connection into a core site and dynamically 
route traffic to the Road Warrior by using Network Address Translation 
at the connection point. That is when a Road Warrior connects the target 
firewall at the core site adds an address to its interior interface. 
This is then routable by all of the interior nodes at the core and any 
of the clients and satellite sites, but we have a crucial problem as the 
NAT stops the Kerberos protocols from working properly and Windows 2000 
authentication fail over the mesh from the road warriors.

So what I want to do is to remove the need for the NAT. To do this I 
need to set up routing for the road warrior in the dynamic protocols. Of 
course this routing can only be via rule based routes as the IPSEC 
routing on the firewall requires that the road warrior address be 
routable via the Internet and via the tunnel. so FreeS/WAN installs the 
rule.

from 192.168.0.0/19 to 144.138.102.50 lookup 42

for example. SO I now want to put the route into table 42 to route 
traffic to 144.138.102.50 via the IPSEC tunnel. Which works on the local 
core, but I now need to propagate this via BGP around the core, the 
satellites and client sites. So I now want to be able to get the 
contents of a kernel table injected into the BGP protocol.

Using quagga I cannot see how to do this. In effect I want the facility 
to add a non-install route into the local BGP tables and tell everybody 
else that this firewall will take over routing for the road warrior.  I 
would really like to propagate the rules as well, but I can live without 
this as our road warriors will always connect to client and satellites 
via the core if they have an open tunnel (DNS does this for us).

So any suggestions as to how this could be achieved with quagga and what 
changes might be needed to get the table contents injected into BGP (I 
would like to be able to define a route-map that injects it for 
particular sessions as I can see a future need to provide selective road 
warrior access) would be appreciated. With help I am quite willing to 
look at adding code to the quagga daemons and user interface to 
accomplish this.

Regards, Howard.



_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev
[prev in list] [next in list] [prev in thread] [next in thread]