[CUWiN-Dev] Manipulating routing table

[Jeongkeun Lee]

Thank you, David. 

We were able to use the mesh network as a transit network connecting two
different subnets by setting two gateways according to your guide. 

Regarding the centralized routing, we use a kind of trick and I'd like to
share it for interested ones.

We write a path configuration file describing path trees rooted on each
gateway. Each tree can contain multiple address ranges for the tree's root
node (gateway) to advertise.
A coordinator on the server outside the mesh parses the input configuration
file and generates and sends route control messages to mesh nodes. Each mesh
node runs a new routing demon which accepts the route control messages from
the coordinator and communicates with hslsd to prevent it from overwriting
routing entries. After telling hslsd not to overwrite, the new routing demon
performs 'route delete ..;route add ...' for each routing entry assigned by
the coordinator. 
In order to simplify the communication between hslsd and the new demon, we
only changed the src/zrib/rib_zebra.c file. There is a function,
rib_zebra_route called by hsls to add routing entries into the zebra routing
table, which in turn appears in the kernel routing table.

So, now I'm able to mandate mesh nodes to use specific routing paths for
specific destinations and it works together with hslsd. 

I believe there must be a more elegance way to do this, but it was a short
and easy way to go. :)

Best,
-- jk

> 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.
> 

> 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
> _______________________________________________
> CU-Wireless-Dev mailing list
> CU-Wireless-Dev at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev