Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2017-07-13,master
commit 1f3cf62adfe0c8af1863d071f4e775e585accdd9 Author: Marek Lindner mareklindner@neomailbox.ch Date: Sun May 31 18:26:59 2009 +0000
doc: batmand/RoutingVodoo
1f3cf62adfe0c8af1863d071f4e775e585accdd9 batmand/RoutingVodoo.textile | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/batmand/RoutingVodoo.textile b/batmand/RoutingVodoo.textile index 1acec135..dee0ccbe 100644 --- a/batmand/RoutingVodoo.textile +++ b/batmand/RoutingVodoo.textile @@ -1,11 +1,13 @@ -== Getting behind the routing vodoo == + +h2. Getting behind the routing vodoo +
With version 0.3 batman became "policy routing" support and thus can use special routing functions provided by the Linux kernel.
This document explains its purpose and tries to point out why batman is doing it. Please keep in mind: Normally, you wont have to to anything about it ! Batman will take care of all the routing work but it might prove helpful to understand what batman does and why. ;-)
-'''Routing tables''' +*Routing tables*
Linux provides much more routing tables than just the one you can see with the "route" command. Batman makes use of the feature to spread its routing entries over 4 routing tables. To find out which routing tables are used issue "batmand -i" and watch out for the "rt_table" information:
@@ -32,7 +34,7 @@ The "route" command provides access to routing table 254. To see or manipulate t ip route ls table 66
-'''Routing rules''' +*Routing rules*
Additionally to more routing tables, Linux offers to set routing rules which opens the possibility to control the packet flow. A rule can be based on certain criteria as source IP / destination IP / incoming interface / etc and will always target a routing table. When a new packet comes in, the kernel will follow the rules from the smallest available rule number until a rule is matched. Then the kernel jumps to the routing table which is pointed to by the rule and tries to find a routing entry there. If nothing is found the routing table will be left and the kernel proceeds with the next rule. Issue "batmand -i" to get the rule numbers used by batman:
@@ -67,15 +69,15 @@ The next rule means: All packets should go through our "network" (HNA) table. The last rule is similar to the first rule but the kernel will jump to our "unreachable" table.
-'''What is the purpose of all this ?''' +*What is the purpose of all this ?*
- * Batman can clearly seperate hosts from announced networks. With a simple lookup you can see whether a node is announced or runs batman. - * It allows you and batman to easily delete all batman related table entries because the batman tables are well known and distinct. - * All batman activity is hidden in the background and does not mess with your manual configuration. You can still manipulate the default table without disturbing batman. - * It makes batman more interoperable with other routing protocols. This is very useful for testing scenarios where you want to test two (or more) routing protocols at the same time. - * With the unreachable rule we can make batman "faster". Whenever you want to access a node within your network which does not exist, your packets will end in the default route. You never will get an answer until your programm reaches a timeout. The unreachable rule changes this: If the packets destination is in your mesh network and no route exists, the kernel will immediately drop the packet and inform the programm which sent it. - * The policy routing "protects" your default route from other nodes. Batman will setup rules around the "tunnel" routing table which make sure that only non-batman interfaces and local traffic can end in the tunnel default route. You can choose your gateway as you like while this decission does not affect others in the network. - * The policy routing can be used for many more things, e.g. protecting against announced networks which have the same IP range as your internal network. Without policy routing it happens that you can't reach your internal network anymore because someone else announces the same IP range and your router sends the traffic there. However, this can't be done automatically by batman as the network configurations are too different. Firmware maintainers can tightly integrate batman into their distribution and add this feature. +* Batman can clearly seperate hosts from announced networks. With a simple lookup you can see whether a node is announced or runs batman. +* It allows you and batman to easily delete all batman related table entries because the batman tables are well known and distinct. +* All batman activity is hidden in the background and does not mess with your manual configuration. You can still manipulate the default table without disturbing batman. +* It makes batman more interoperable with other routing protocols. This is very useful for testing scenarios where you want to test two (or more) routing protocols at the same time. +* With the unreachable rule we can make batman "faster". Whenever you want to access a node within your network which does not exist, your packets will end in the default route. You never will get an answer until your programm reaches a timeout. The unreachable rule changes this: If the packets destination is in your mesh network and no route exists, the kernel will immediately drop the packet and inform the programm which sent it. +* The policy routing "protects" your default route from other nodes. Batman will setup rules around the "tunnel" routing table which make sure that only non-batman interfaces and local traffic can end in the tunnel default route. You can choose your gateway as you like while this decission does not affect others in the network. +* The policy routing can be used for many more things, e.g. protecting against announced networks which have the same IP range as your internal network. Without policy routing it happens that you can't reach your internal network anymore because someone else announces the same IP range and your router sends the traffic there. However, this can't be done automatically by batman as the network configurations are too different. Firmware maintainers can tightly integrate batman into their distribution and add this feature.
-If you want to influence batmans routing policy use the --policy-routing-script option to provide a custom executable. If this option is used batman will send it routing decissions to stdin of that executable instead of manipulation the routing table directly. Now, this executable can alter the rules and routing table entries by manipulating the routing by itself. You can see [http://downloads.open-mesh.org/batman/useful-scripts-and-tools/policy_routin... policy_routing_script.sh] to get a routing script sample. You wont need this option / script unless you want to do something fancy. \ No newline at end of file +If you want to influence batmans routing policy use the --policy-routing-script option to provide a custom executable. If this option is used batman will send it routing decissions to stdin of that executable instead of manipulation the routing table directly. Now, this executable can alter the rules and routing table entries by manipulating the routing by itself. You can see "policy_routing_script.sh":http://downloads.open-mesh.org/batman/useful-scripts-and-tools/policy_routin... to get a routing script sample. You wont need this option / script unless you want to do something fancy. \ No newline at end of file