Brian J. Murrell wrote: > > Part of the problem is the inflexibility of various players. Everything > that deals with routing assumes a single "main" routing table when in a > more complex world that's not the case and there is no ability to step > in and change that. That's why shorewall's "hack"s to deal with it is > used by the people who use it. >
My what you miss when your sleeping... If your talking init scripts here, right? The issues I found with dealing with iproute2, is that the packages that deal with obtaining/creating an ip address only assume the main routing table should be used. While what we really want here, I think, is one table per ip, maybe one per net route with secondary ips using src. Much like what a table looks like with what shorewall generates without an entry in the copy column for a provider, just the ip specific routing. Then the other issue becomes /etc/iproute2 data, what should the table names be? Tom's manipulation of rt_tables could be used to set the table's name based on the interface name, and the related route rule code use to create the routing rule. Thus, to look up a route it would be: ip route ls table ppp0, ip route ls table tun0, ip route ls table eth0 etc... I'm I on track here or way off base? To change the networking scripts would be a major under taking here, and maintaining patches until upstream came on board would be a headache, I gave up with the little bit I came up with for multi-dhcp provider support for fedora. Maybe, I'm up for it now, if there is others who are interested, otherwise I'm not going to bother trying to change the world. Jerry ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
