[CUWiN-Dev] Manipulating routing table

[David Young]

On Mon, Dec 18, 2006 at 07:09:12PM +0900, Jeongkeun Lee wrote:
> Hi,
> 
> I'm finding the way how to set routing paths between mesh nodes and the
> gateway as I want.
> Initially I tried the 'route add' and 'route delete' commands, but zebra
> daemon seems to override my modifications on the routing table very
> frequently. So, I could not add or delete any routing entry.
> 
> My goal consists of two steps.
> 1. At first, I'd like to use multiple gateways and split the traffic based
> on address ranges. The picture below tries to capture the topology:
> 
> Server--->GW1--->Mesh--->GW2--->Client
> 
> Both the server and client are outside the mesh. Another way to think of
> this is that mesh is acting as transit for connecting the server and the
> client.
> 
> In this topology, assume the server has a.b.x.x address and client has
> c.d.x.x address. If gw1 advertises the a.b.x.x address range and gw2
> advertises c.d.x.x address range, hsls should do the right thing. But I
> found that the current behavior of hsls' gateway advertisement is
> propagating the 'default route' over the mesh. The gateway does not
> advertise its attached ip range but advertise the fact that it is connected
> to the internet. And hsls on each mesh node chooses the best gateway based
> on the ETX metric. Please correct me if I'm wrong.

You can augment or replace the default route with other prefixes.
I will illustrate with some example hslsd command-lines.
Here we advertise a default route on interface sip0:

	hslsd -f inet -t stub -i sip0 -p 0.0.0.0/0

Here we replace the default route with your route, a.b.x.x

	hslsd -f inet -t stub -i sip0 -p a.b.0.0/16

Finally, we advertise both a default route and c.d.x.x,

	hslsd -f inet -t stub -i sip0 -p 0.0.0.0/0 -p a.b.0.0/16

Any combination is possible.

Our hslsd configuration resides in /etc/rc.conf.d/hslsd, however, it
is created by a script at boot.  The script is /etc/rc.d/route_conf.
Add new routes to /etc/rc.d/route_conf so they are not overwritten.

> 2. Ultimately, I'd like to implement a centralized routing system. The
> coordinator outside the mesh determines and assigns the best routes for each
> mesh node. In order to find a way to write a new routing daemon which
> accepts the coordinator's message and controls zebra, I spent some time to
> look at the related source codes such as hsls, zebra, rib, zrib and etc, but
> the entire routing system is, of course, complicated. Please give me some
> tips to begin with. I think the hsls' neighbor discovery mechanism (via
> hello exchanges) is still needed ever after I replace hsls by the new
> routing daemon.

That's quite a project!  Previously, I have thought about how this can
be done.  You need to split hslsd into two pieces.  One part provides
the "decision" function (it runs Shortest Paths First).  You centralize
that.  The second part provides the "signaling" function, that is, the
transmission/reception of Hellos and/or ETX probe messages.  You have
already described this split.  You need some kind of IPC between the
two parts.  A TCP socket will probably be sufficient.  hslsd already
talks to zebra over a TCP socket, so running the decision function and
zebra on different hosts should not be a problem.

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933