Hi all.
I have made a new version of the patch posted by acinonyx (rv502), for interfacing batmand with the zebra routing daemon. There are 2 versions available: One for the latest svn (rv1060) and one for the stable 0.3 release. Take a look at:
http://www.cslab.ece.ntua.gr/~chazapis/batman/
Please consider this code experimental. Some initial tests are promising, but there may be bugs... :)
For now, the plug-in just supports sending routes to zebra, not the opposite (redistributing routes from other protocols). That was also the case with the older - rv502 - version.
What the patch does is: - Adds a flag "-z" to the batmand executable which may be used to enable zebra communication and accepts as an argument the path to the corresponding zebra unix-domain socket. - If zebra is enabled: - No rules are added to the kernel. - All UNICAST routes are sent to zebra.
All routes are also sent to the kernel (in linux/route.c), but the extra routing tables are not used by linux, because of the lack of rules. These routing tables remain, just to help with route management, so batmand can successfully remove all added routes on shutdown.
Antony
Hi,
I have made a new version of the patch posted by acinonyx (rv502), for interfacing batmand with the zebra routing daemon. There are 2 versions available: One for the latest svn (rv1060) and one for the stable 0.3 release. Take a look at:
it looks good - thanks for your work. I would like to put your changes on open-mesh.net. Either linking to your webspace or copying your work on our server. What do you prefer ?
What the patch does is:
- Adds a flag "-z" to the batmand executable which may be used to enable zebra communication and accepts as an argument the path to the corresponding zebra unix-domain socket.
- If zebra is enabled:
- No rules are added to the kernel.
- All UNICAST routes are sent to zebra.
Did you consider using the "--policy-routing-script" for this communication with zebra ? You could write an external program that gets the information from batman and relays them to zebra. Therefore, you would not need to patch every batman installation and would not have to change your patches every time when batman changes. By using this facility you can decide what routes are sent to zebra, what routes are added to the routing table and you don't need to worry about batman. This communication interface could also be used by other routing protocols without the need of reinventing the wheel over and over again.
Greetings, Marek
On May 7, 2008, at 3:41 PM, Marek Lindner wrote:
Hi,
I have made a new version of the patch posted by acinonyx (rv502), for interfacing batmand with the zebra routing daemon. There are 2 versions available: One for the latest svn (rv1060) and one for the stable 0.3 release. Take a look at:
it looks good - thanks for your work. I would like to put your changes on open-mesh.net. Either linking to your webspace or copying your work on our server. What do you prefer ?
I would prefer that you copy it over. I think it is better to keep things in one place. :)
What the patch does is:
- Adds a flag "-z" to the batmand executable which may be used to enable zebra communication and accepts as an argument the path to the corresponding zebra unix-domain socket.
- If zebra is enabled:
- No rules are added to the kernel.
- All UNICAST routes are sent to zebra.
Did you consider using the "--policy-routing-script" for this communication with zebra ? You could write an external program that gets the information from batman and relays them to zebra. Therefore, you would not need to patch every batman installation and would not have to change your patches every time when batman changes. By using this facility you can decide what routes are sent to zebra, what routes are added to the routing table and you don't need to worry about batman. This communication interface could also be used by other routing protocols without the need of reinventing the wheel over and over again.
I had a lengthy conversation about that with Acinonyx. The first patch I did was to enable us to pass arguments to the policy routing script. However, I preferred a direct patch, because I couldn't find an easy way with the current batmand and (more importantly) the zebra interface to retrieve routes on exit. I had to implement some kind of route management/tracking in the script and delete these routes on shutdown. With the direct patch, route management is done in the kernel. Sure, a full-featured policy-routing-script would be a more appropriate solution and I hope to find some time to do it in the future.
An even greater challenge would be to implement a bidirectional policy- routing-script, that could also be used to implement route redistribution from other protocols. Which would of course require a full API to talk with batmand... Need even more time for that... :)
Cheers,
Antony
Greetings, Marek _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
I would prefer that you copy it over. I think it is better to keep things in one place. :)
Ok, I copied it and put a note on the website. See: https://www.open-mesh.net/batman/patches
I renamed the patches from "experimental" to "needs-testing" otherwise people might get confused with our experimental branch.
I had a lengthy conversation about that with Acinonyx. The first patch I did was to enable us to pass arguments to the policy routing script. However, I preferred a direct patch, because I couldn't find an easy way with the current batmand and (more importantly) the zebra interface to retrieve routes on exit. I had to implement some kind of route management/tracking in the script and delete these routes on shutdown. With the direct patch, route management is done in the kernel. Sure, a full-featured policy-routing-script would be a more appropriate solution and I hope to find some time to do it in the future.
But batman should keep track of all routes and send the delete commands to your program. On exit batman should notify your program about all the routes to be deleted. If not you found a bug. ;-)
An even greater challenge would be to implement a bidirectional policy- routing-script, that could also be used to implement route redistribution from other protocols. Which would of course require a full API to talk with batmand... Need even more time for that... :)
You mean batman should distribute zebra routes on the fly ? That is possible - even _today_. :-) You can add and delete HNA routes via the unix socket. HNA is a way to flood the batman network with routes which do not belong to batman.
Greetings, Marek
On May 7, 2008, at 4:29 PM, Marek Lindner wrote:
I would prefer that you copy it over. I think it is better to keep things in one place. :)
Ok, I copied it and put a note on the website. See: https://www.open-mesh.net/batman/patches
I renamed the patches from "experimental" to "needs-testing" otherwise people might get confused with our experimental branch.
I had a lengthy conversation about that with Acinonyx. The first patch I did was to enable us to pass arguments to the policy routing script. However, I preferred a direct patch, because I couldn't find an easy way with the current batmand and (more importantly) the zebra interface to retrieve routes on exit. I had to implement some kind of route management/tracking in the script and delete these routes on shutdown. With the direct patch, route management is done in the kernel. Sure, a full-featured policy-routing-script would be a more appropriate solution and I hope to find some time to do it in the future.
But batman should keep track of all routes and send the delete commands to your program. On exit batman should notify your program about all the routes to be deleted. If not you found a bug. ;-)
This is not a bug, but an implementation restriction. Batmand uses flush_routes_rules (in linux/route.c) to get back all all routes that have been added to the kernel during execution and from there it calls add_dell_route to remove them. When using the policy-routing-script, nothing is removed, as nothing has been added to the kernel. It is supposed to be the responsibility of the policy-routing-script to know what has to be deleted. If there was a way to simply tell zebra: "Delete all routes from batman", that wouldn't be a problem. But I don't know how to do this with the zebra API and I didn't wan't to keep track of all routes in the script, as this is already implemented in batmand.
An even greater challenge would be to implement a bidirectional policy- routing-script, that could also be used to implement route redistribution from other protocols. Which would of course require a full API to talk with batmand... Need even more time for that... :)
You mean batman should distribute zebra routes on the fly ? That is possible - even _today_. :-) You can add and delete HNA routes via the unix socket. HNA is a way to flood the batman network with routes which do not belong to batman.
I hadn't though about that. I'll give it a try.
You could also consider merging http://www.cslab.ece.ntua.gr/~chazapis/batman/batman-r1040-policy-routing-sc... into the main branch. It allow for passing args to the policy-routing- script, which is really useful.
Antony
Greetings, Marek _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Hello
Antony Chazapis wrote:
For now, the plug-in just supports sending routes to zebra, not the opposite (redistributing routes from other protocols). That was also the case with the older - rv502 - version.
Marek Lindner wrote:
You mean batman should distribute zebra routes on the fly ? That is possible - even _today_. :-) You can add and delete HNA routes via the unix socket. HNA is a way to flood the batman network with routes which do not belong to batman.
I am mainly interested in redistributing zebra routes to batman as i do with olsr_quagga plugin. This way, i can think about switching from olsr to batman 0.3. Perhaps, you will enable it in your code again.
Thx
Daniel
Hi,
I am mainly interested in redistributing zebra routes to batman as i do with olsr_quagga plugin. This way, i can think about switching from olsr to batman 0.3. Perhaps, you will enable it in your code again.
it was never "enabled" - it was part of a patch. I'm not that familiar with zebra/quagga. Can you explain what you need and why the dynamic HNA adding/deleting is not enough ? That feature did not exist in revision 502.
Greetings, Marek
Hey Marek
Marek Lindner wrote:
I am mainly interested in redistributing zebra routes to batman as i do with olsr_quagga plugin. This way, i can think about switching from olsr to batman 0.3. Perhaps, you will enable it in your code again.
it was never "enabled" - it was part of a patch. I'm not that familiar with zebra/quagga. Can you explain what you need and why the dynamic HNA adding/deleting is not enough ? That feature did not exist in revision 502.
Enabling zebra to tell batmand to add/remove routes needs a patch in zebra. It would be really nice to have a batmand plugin whatever that talks to zebra for getting dynamic HNA routes. So i dont have to modify my zebra, but can enable a plugin in batmand (as it is in OLSR).
I need this for BGP routing. Imagine to route two batmand clouds together via BGP. If the third cloud joins, i dont want to reconfigure the other batmand-daemons. They just grep the routes from the running zebra.
Another big option would be to let zebra speak batman / olsr protocol and be able to configure batman / olsr through zebra interface / configuraion. But that would be "top of everything" and imo not necessary.
Greetz
Daniel
Hi,
Enabling zebra to tell batmand to add/remove routes needs a patch in zebra. It would be really nice to have a batmand plugin whatever that talks to zebra for getting dynamic HNA routes. So i dont have to modify my zebra, but can enable a plugin in batmand (as it is in OLSR).
Your concept of "batman plugin" confuses me a bit. Is that a plugin in batman or a plugin in zebra ? And what are the functions it provides which can't be provided now and why ?
Greetings, Marek
Hello Marek
Marek Lindner wrote:
Enabling zebra to tell batmand to add/remove routes needs a patch in zebra. It would be really nice to have a batmand plugin whatever that talks to zebra for getting dynamic HNA routes. So i dont have to modify my zebra, but can enable a plugin in batmand (as it is in OLSR).
Your concept of "batman plugin" confuses me a bit. Is that a plugin in batman or a plugin in zebra ? And what are the functions it provides which can't be provided now and why ?
Its a batman plugin like an olsr plugin. zebra doesnt provide any plugins imo.
You provide a external switch to insert HNA by script. Unfortunately, zebra cant call external script as i have to patch zebra then - or i dont know how.
with the olsr-quagga-plugin i can redistribute zebra routes to olsr internally. thats something i like to see with batman-zebra-plugin.
Greetz
Daniel
Its a batman plugin like an olsr plugin. zebra doesnt provide any plugins imo.
You provide a external switch to insert HNA by script. Unfortunately, zebra cant call external script as i have to patch zebra then - or i dont know how.
with the olsr-quagga-plugin i can redistribute zebra routes to olsr internally. thats something i like to see with batman-zebra-plugin.
Batman does not provide any plugin interface as well. Simply because it is a routing daemon and should only do that. On the other hand we don't like this rewriting of plugins over and over again. As already explained in the other part of this thread batman offers an external interface for adding/deleting routing information which could be used for that. A little external application can talk to zebra, add/delete routes and/or HNA and could be _reused_ by other routing applications.
Greetings, Marek
I got some news.
I went the other way round and started out on an external program that will act as an interface between batman and quagga. You can find it here:
http://www.cslab.ece.ntua.gr/~chazapis/batman/batquagga-0.1.c
It is more of a sketch-of-proof right now and _should not be used for deployment purposes_. The program is completely based on the libraries provided by quagga, in contrast to the current patch and the olsrd plug-in, that re-implement the API.
Assuming you have quagga installed, you can compile it with:
gcc -o batquagga batquagga.c -lzebra
Some systems may also require "-lcap" linked in.
What batquagga does is read from standard input the ROUTE commands issued by batmand (--policy-routing-script) and issue the corresponding route add/del messages to zebra. Note that I read 11 variables form stdin, which includes the "metric". So to use batquagga, you must have a batman sources patched with the "...quagga.patch".
Moreover, batquagga can send redistribute requests to zebra, to get routes by other protocols. For now, it just prints out the routes, but as you said it should be easy to invoke batmand from within the program to add/del HNAs.
Now to the problem:
When exiting, I tell zebra to give me back the routes marked as "batman" through a redistribute request. The purpose is to clear all batman- originated routes from the system. But zebra responds to a redistribute request only with the "selected" routes. So some entries are not echoed back.
After various hacks, I conclude that in order to properly implement batquagga I will either have to implement route-flushing in zebra, or I will somehow have to change batmand so that it will clear all HNAs on shutdown. The first case is easier and I will be trying to do that for now, but I guess the second is "better".
Which leads me to a question to developers:
Do you keep or plan to keep network HNA information in batmand? I mean, is there any way that flush_routes_rules (in linux/route.c) could be implemented in batmand, without the need of the external routing table management?
As a routing daemon, batman, should keep track of the network state in its own structures, which in turn would ease porting to other platforms as well. As implemented, flush_routes_rules could be used for linux-specific clean-up on startup. Another function, completely os-agnostic, could be implemented to remove all batman-generated routes on shutdown. This is at least how all quagga protocols are implemented.
Are there any plans on that?
Antony
(The batquagga name is credit of Acinonyx.)
On May 8, 2008, at 1:12 PM, Marek Lindner wrote:
Its a batman plugin like an olsr plugin. zebra doesnt provide any plugins imo.
You provide a external switch to insert HNA by script. Unfortunately, zebra cant call external script as i have to patch zebra then - or i dont know how.
with the olsr-quagga-plugin i can redistribute zebra routes to olsr internally. thats something i like to see with batman-zebra-plugin.
Batman does not provide any plugin interface as well. Simply because it is a routing daemon and should only do that. On the other hand we don't like this rewriting of plugins over and over again. As already explained in the other part of this thread batman offers an external interface for adding/deleting routing information which could be used for that. A little external application can talk to zebra, add/ delete routes and/or HNA and could be _reused_ by other routing applications.
Greetings, Marek
B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Hi,
I went the other way round and started out on an external program that will act as an interface between batman and quagga. You can find it here:
http://www.cslab.ece.ntua.gr/~chazapis/batman/batquagga-0.1.c
cooool !
Do you keep or plan to keep network HNA information in batmand? I mean, is there any way that flush_routes_rules (in linux/route.c) could be implemented in batmand, without the need of the external routing table management?
Batman keeps track of the HNA and all other routes which were placed by batman and deletes them individually. The mentionned function flush_routes_rules() is only called during the startup to clean the tables and in case of a segmentation fault because the internal data structures can't be trusted anymore. The normal case is that batman deletes its own routes one by one.
I did some testing with a script which just prints the commands and I noticed that the script can't execute those commands because it dies too quickly via SIGINT or SIGTERM. Therefore the latest revision (1065) ignores these signals. Apart from that we have a little sync problem. Batman kills its child after sending all the commands via the pipe. At that moment the child may still be busy with processing these commands. We have to find an elegant way to communicate that the child finished its last job. The latest revision waits another 3 seconds which is far from being perfect ...
Greetings, Marek
PS: Your addtional script arguments patch is an interesting idea. We are checking on that because it might have some side effects.
On May 13, 2008, at 11:34 AM, Marek Lindner wrote:
Hi,
I went the other way round and started out on an external program that will act as an interface between batman and quagga. You can find it here:
http://www.cslab.ece.ntua.gr/~chazapis/batman/batquagga-0.1.c
cooool !
Do you keep or plan to keep network HNA information in batmand? I mean, is there any way that flush_routes_rules (in linux/route.c) could be implemented in batmand, without the need of the external routing table management?
Batman keeps track of the HNA and all other routes which were placed by batman and deletes them individually. The mentionned function flush_routes_rules() is only called during the startup to clean the tables and in case of a segmentation fault because the internal data structures can't be trusted anymore. The normal case is that batman deletes its own routes one by one.
That's great. My apologies I couldn't find that before.
I did some testing with a script which just prints the commands and I noticed that the script can't execute those commands because it dies too quickly via SIGINT or SIGTERM. Therefore the latest revision (1065) ignores these signals. Apart from that we have a little sync problem. Batman kills its child after sending all the commands via the pipe. At that moment the child may still be busy with processing these commands. We have to find an elegant way to communicate that the child finished its last job. The latest revision waits another 3 seconds which is far from being perfect ...
I will take a look at that and see if I can do anything.
Thanks!
Antony
Greetings, Marek
PS: Your addtional script arguments patch is an interesting idea. We are checking on that because it might have some side effects. _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
On May 13, 2008, at 12:14 PM, Antony Chazapis wrote:
On May 13, 2008, at 11:34 AM, Marek Lindner wrote:
I did some testing with a script which just prints the commands and I noticed that the script can't execute those commands because it dies too quickly via SIGINT or SIGTERM. Therefore the latest revision (1065) ignores these signals. Apart from that we have a little sync problem. Batman kills its child after sending all the commands via the pipe. At that moment the child may still be busy with processing these commands. We have to find an elegant way to communicate that the child finished its last job. The latest revision waits another 3 seconds which is far from being perfect ...
I've checked out the latest revision and have seen the problem you mention. I think that waiting and then killing the process is not needed. If you just close the pipe, the other end should notice that there is an EOF at stdin and die. I created a new batquagga version (0.2) that does exactly that and even when removing the "sleep" and "kill" commands from restore_defaults(), it works fine.
Moreover, batquagga-0.2 has no signal handlers for SIGKILL and SIGINT. They are not needed anymore. Also, the "retain routes" option was removed (no sense at this point, and no way to properly distinguish between delete routes that happen at shutdown vs. delete routes that would normally occur).
PS: Your addtional script arguments patch is an interesting idea. We are checking on that because it might have some side effects.
The arguments patch or some other form of passing arguments is essential for using the policy-routing-script to redistribute routes from other protocols...
Antony
I created a new batquagga version (0.2) that does exactly that and even when removing the "sleep" and "kill" commands from restore_defaults(), it works fine.
Unfortunately, it does not cover all the cases. I attached the test shell script I used. Without the sleep & kill it does not die ...
The arguments patch or some other form of passing arguments is essential for using the policy-routing-script to redistribute routes from other protocols...
As I said: Your idea is excellent - we just looked for an easy way to find a suitable solution for all sort of cases. The latest revision (1066) contains a method to forward the given arguments. You can use it like this:
batmand --policy-routing-script "test.sh one two three" eth0:bat
or even
batmand --policy-routing-script "test.sh "one two three"" eth0:bat
Greetings, Marek
On May 14, 2008, at 9:52 PM, Marek Lindner wrote:
I created a new batquagga version (0.2) that does exactly that and even when removing the "sleep" and "kill" commands from restore_defaults (), it works fine.
Unfortunately, it does not cover all the cases. I attached the test shell script I used. Without the sleep & kill it does not die ...
This is because you use a "while true" loop.
Try instead:
while read bla do echo "bla: $bla" done
The arguments patch or some other form of passing arguments is essential for using the policy-routing-script to redistribute routes from other protocols...
As I said: Your idea is excellent - we just looked for an easy way to find a suitable solution for all sort of cases. The latest revision (1066) contains a method to forward the given arguments. You can use it like this:
batmand --policy-routing-script "test.sh one two three" eth0:bat
or even
batmand --policy-routing-script "test.sh "one two three"" eth0:bat
Even simpler... Much better.
Greetings, Marek <test.sh> _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Hi,
This is because you use a "while true" loop.
I'm well aware of that. For you that might be enough but in general the solution is not really perfect. I will get flooded with questions why batman uses 100% cpu power. ;-) What about sending a special "EXIT" command to give the child the possibility to clean up. If the child is not dead after 10 seconds batman kills it.
Even simpler... Much better.
Yeah - I like it simple. Thanks for the idea and thanks Simon for input.
Greetings, Marek
On Wednesday, 14. May 2008 21:51:16 Antony Chazapis wrote:
I think that waiting and then killing the process is not needed. If you just close the pipe, the other end should notice that there is an EOF at stdin and die.
Ok, I applied your idea to the trunk and changed the demo script accordingly. See revision 1080. Sending EXIT or something like that is even uglier ...
Greetings, Marek
b.a.t.m.a.n@lists.open-mesh.org
-
Antony Chazapis -
Daniel Paufler -
Marek Lindner