[CUWiN-Dev] Manipulating routing table

[Bryan Cribbs]

* Jeongkeun Lee <jklee at mmlab.snu.ac.kr> :
> 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.

If I understand properly, yes.

> So, I want to how to add a new route entry for the above traffic splitting
> with multiple gateways: how to prevent zebra (or hsls) from deleting the new
> entry.

I do not know.

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

Our approach is that each node independantly can deduce it's own best 
route based on "nearby" metadata.  A centralized routing system is
pretty much the antithesis of our intent.

> 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.
> 
> I'm using the 0.7.0 CuWiNware source and 0.7.0 netbsd source. 
> 
> Always thanking you for helpful comments,
> Regards,
> 
> -- Jeongkeun
> 
> 
> _______________________________________________
> CU-Wireless-Dev mailing list
> CU-Wireless-Dev at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev