Dear B.A.T.M.A.N List,
i've installed BATMAN v0.3.2 in a ethernet network to dynamicly route my network-informations. Before switching to BATMAN, i've used OLSR.
With OLSR all things went fine. But since my network grows faster as intended, i like to switch to BATMAN.
NOW TO MY PROBLEM:
I like to announce a gateway that is behind an VPN-Tunnel. The VPN-Tunnel is established, before BATMAN is running.
When i try to start BATMAN on the Gateway with this options: batmand -g 30mbit/2mbit
the clients will create a gate0 interface. I do not need this gate0 interface. All routers have static public ip-addresses assigned. The once that i need is, that BATMAN inserts a DEFAULT-ROUTE to the next neighbour hop thats reach the gateway.
NETWORK-Setup:
1. i386 Router located on ISP runs batman as gateway-provider xxx.205.12.0/32 brd 255.255.255.255
<--- VPN-Tunnel over ISP-Network --->
xxx.205.12.4/32 brd 255.255.255.255 2. i386 Router located at home #1 xxx.205.12.17/30 brd xxx.205.12.19
<--- Wireless Bridge-Connection --->
xxx.205.12.18/30 brd xxx.205.12.19 3. i386 Router located at home #2 xxx.205.12.21/30 brd xxx.205.12.23
<--- Wireless Bridge-Connection --->
xxx.205.12.22/30 brd xxx.205.12.23 4. i386 Router located at home #3
How can i tell BATMAN (gateway) to announce 0.0.0.0/0 as HNA?
# batmand -c -a 0.0.0.0/0 Invalid announced network (netmask is invalid): 0.0.0.0/0
I dont like to setup a second VPN / P2P Tunnel, because thats not needed.
Thanks in advance, Michael
Hello Michael!
Batmand checks and deliberately blocks users from announcing 0.0.0.0/0 - this could cause the notorious black-hole problem we have experienced in the old days when using OLSR. Also we think it is important that we can explicitly tell a Batman node to use Internet gateway functionality or not.
Default routes in a mesh can be really annoying and break network functionality. If you only have one default gateway in your Batmand network and really know what you are doing you can actually override this check with a simple trick.
As a workaround you can announce two subnetworks 0.0.0.0/1 and 128.0.0.0/1 instead of 0.0.0.0/0.
batmand -a 0.0.0.0/1,128.0.0.0/1 <your interface>
Cheers, Elektra
Hi Elektra,
thanks for your trick. This trick works for me, but it is a bad solution :-) I switched back to OLSR, although i like the concept of BATMAN more then that of OLSR.
Announcing 0.0.0.0/0 can really be a problem, but why does BATMAN tunnel the internet-traffic through gate0?
It will be nice, if there will be a option in the next release, where users can decide to use routing or tunneling internet-traffic.
Cheers, Michael.
Am 06.09.2009 12:50, schrieb elektra:
Hello Michael!
Batmand checks and deliberately blocks users from announcing 0.0.0.0/0 - this could cause the notorious black-hole problem we have experienced in the old days when using OLSR. Also we think it is important that we can explicitly tell a Batman node to use Internet gateway functionality or not.
Default routes in a mesh can be really annoying and break network functionality. If you only have one default gateway in your Batmand network and really know what you are doing you can actually override this check with a simple trick.
As a workaround you can announce two subnetworks 0.0.0.0/1 and 128.0.0.0/1 instead of 0.0.0.0/0.
batmand -a 0.0.0.0/1,128.0.0.0/1<your interface>
Cheers, Elektra _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@lists.open-mesh.net https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Hi Michael!
Announcing 0.0.0.0/0 can really be a problem, but why does BATMAN tunnel the internet-traffic through gate0?
Because we want to have the means to select the gateway from the gateway client, rather than ending up somewhere random with our outgoing Internet traffic. With default route entries in every mesh node all a gateway client node can determine is its next link-local hop on the path towards one of the gateways. Hence every node on your path will make its own selection for the default gateway, so it is not possible to select the gateway from the mesh gateway client.
Cheers, Elektra
Hi,
When i try to start BATMAN on the Gateway with this options: batmand -g 30mbit/2mbit
the clients will create a gate0 interface. I do not need this gate0 interface. All routers have static public ip-addresses assigned. The once that i need is, that BATMAN inserts a DEFAULT-ROUTE to the next neighbour hop thats reach the gateway.
I don't understand why you have the feeling the gate0 interface is a problem. As Elektra explained choosing a default gateway by "inserting a default route" is meaningless (in a mesh). If each client should be able to choose its own gateway there is no way around the tunnel mechanism.
If you dislike the masquerading (which is activated per default) you can learn here[0] how to disable it. If you really want to have the plain default route I suggest to use the --policy-routing-script [1] option to modify the routing tables on the fly.
Regards, Marek
[0] http://www.open-mesh.net/wiki/InternetTuning [1] http://www.open-mesh.net/wiki/RoutingVodoo
Am 06.09.2009 17:11, schrieb Marek Lindner:
I don't understand why you have the feeling the gate0 interface is a problem. As Elektra explained choosing a default gateway by "inserting a default route" is meaningless (in a mesh). If each client should be able to choose its own gateway there is no way around the tunnel mechanism.
Sorry but i had not the right view of the tunneling-interface.
Now, the reason for the tunneling-interface is totaly clear. There is no other solution to route internet-traffic through a specified gatway. The only solution will be to lable a tcp/ip-packet how MPLS does, but that is to fancy.
One question: Will the P2P-Interface (gate0) shows up in a traceroute? The P2P-Interface have a private ip-address 169.x.x.x assigned to it. I use only public ip-addresses and do not want to show a private ip-address in a traceroute.
When using the tunneling interface, the MTU is set to a lower value then 1500 bytes (1431 bytes). B.A.T.M.A.N have in addition to the NAT-Helper set the TCPMSS Flag to something like 1371 bytes (1431 bytes - 20 Bytes of MAC-Address and - 40 Bytes of TCP/IP Header). I found nothing about TCPMSS on my firewall-rules (iptables) in the table "mangle".
Without TCPMSS, packages that transport more then 1371 bytes will be silently dropped in my case.
Now i will give B.A.T.M.A.N a second try and will use the little tricky solution to add two /1 subnets. Thanks to Elektra.
I suggest to use the --policy-routing-script [1] option to modify the routing tables on the fly.
Currently i have my own policy-routing-script, because B.A.T.M.A.N does not support HOST-Routes xxx.205.12.4/32. But why does B.A.T.M.A.N not fully support Host-Routes? A mash with only Host-Addresses is easier to administrate then complete networks. A second goal is, that the ad-hoc mobile user is free to change his position across the net.
I use only host-addresses to safe ip-addresses.
Michael.
On Monday 07 September 2009 01:13:49 Michael Rack wrote:
Now, the reason for the tunneling-interface is totaly clear. There is no other solution to route internet-traffic through a specified gatway. The only solution will be to lable a tcp/ip-packet how MPLS does, but that is to fancy.
Well, we have something similar called "batman-adv". It is a kernel module implementing the batman protocol on layer 2.5 (using mac addresses instead of IPs). May be you should look into that ?
One question: Will the P2P-Interface (gate0) shows up in a traceroute? The P2P-Interface have a private ip-address 169.x.x.x assigned to it. I use only public ip-addresses and do not want to show a private ip-address in a traceroute.
I have no test setup at hand but I think you always should see the gateway's virtual ip (0.0 at the end) if you try to traceroute a host that resides in the internet.
Keep in mind that the tunneling will make everything appear as a single hop no matter how many nodes are in between. A traceroute should look like this:
* node ip * gw virtual ip * internet ip1 * internet ip2 * ...
When using the tunneling interface, the MTU is set to a lower value then 1500 bytes (1431 bytes). B.A.T.M.A.N have in addition to the NAT-Helper set the TCPMSS Flag to something like 1371 bytes (1431 bytes - 20 Bytes of MAC-Address and - 40 Bytes of TCP/IP Header). I found nothing about TCPMSS on my firewall-rules (iptables) in the table "mangle".
Without TCPMSS, packages that transport more then 1371 bytes will be silently dropped in my case.
Not sure how you get to these numbers (1431 / 1371) as the batman tunnel is running over UDP which costs 29 Bytes [20 Bytes IP + 8 Bytes UDP + 1 Byte batman stuff] in total, reducing the maximum packet size to 1471.
You are right about the the TCPMSS configuration - batman could set this automatically as well. I suggest something like this:
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -o gate0 -j TCPMSS --clamp- mss-to-pmtu
Currently i have my own policy-routing-script, because B.A.T.M.A.N does not support HOST-Routes xxx.205.12.4/32. But why does B.A.T.M.A.N not fully support Host-Routes? A mash with only Host-Addresses is easier to administrate then complete networks. A second goal is, that the ad-hoc mobile user is free to change his position across the net.
Your own policy-routing-script ? Why do you think batman does not support host routes ? I had the feeling batman supports host routes in all possible ways. :-)
Cheers, Marek
Am 06.09.2009 19:47, schrieb Marek Lindner:
When using the tunneling interface, the MTU is set to a lower value then 1500 bytes (1431 bytes). B.A.T.M.A.N have in addition to the NAT-Helper set the TCPMSS Flag to something like 1371 bytes (1431 bytes - 20 Bytes of MAC-Address and - 40 Bytes of TCP/IP Header). I found nothing about TCPMSS on my firewall-rules (iptables) in the table "mangle".
Without TCPMSS, packages that transport more then 1371 bytes will be silently dropped in my case.
Not sure how you get to these numbers (1431 / 1371) as the batman tunnel is running over UDP which costs 29 Bytes [20 Bytes IP + 8 Bytes UDP + 1 Byte batman stuff] in total, reducing the maximum packet size to 1471.
You are right about the the TCPMSS configuration - batman could set this automatically as well. I suggest something like this:
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -o gate0 -j TCPMSS --clamp- mss-to-pmtu
I got these numbers by "/sbin/ip addr show dev gate0".
gate0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1431 qdisc pfifo_fast qlen 500 link/[65534] inet 169.254.0.0/32 scope global gate0
MTU is set to 1431 bytes.
Currently i have my own policy-routing-script, because B.A.T.M.A.N does not support HOST-Routes xxx.205.12.4/32. But why does B.A.T.M.A.N not fully support Host-Routes? A mash with only Host-Addresses is easier to administrate then complete networks. A second goal is, that the ad-hoc mobile user is free to change his position across the net.
Your own policy-routing-script ? Why do you think batman does not support host routes ? I had the feeling batman supports host routes in all possible ways. :-)
IP-Host #1: 123.205.12.0 / 32 IP-Host #2: 123.205.12.4 / 32
IP RULES ON "HOST #2": ~ $ /sbin/ip rule show 6600: to 123.205.12.4 lookup batman_hosts [66] 6601: from all lookup batman_networks [65] 6700: to 123.205.12.4 lookup batman_unreach [67]
Host #1 (123.205.12.0) is in the routingtable of batman_hosts [66].
But i can not ping 123.205.12.0, because the kernel will not enter the rule 6600.
When i configure my Host #2 to a /24 network, all went fine. Then the rule will setuped as follow:
6600: to 123.205.12.4/24 lookup batman_hosts [66]
In this case, i had to write my own routing-policy-script.
Cheers, Michael.
On Monday 07 September 2009 18:16:47 Michael Rack wrote:
I got these numbers by "/sbin/ip addr show dev gate0".
gate0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1431 qdisc pfifo_fast qlen 500 link/[65534] inet 169.254.0.0/32 scope global gate0
MTU is set to 1431 bytes.
And what is the MTU of the interface batman is running on ?
Did the iptables command I posted help you to fix your MSS problem ?
IP-Host #1: 123.205.12.0 / 32 IP-Host #2: 123.205.12.4 / 32
IP RULES ON "HOST #2": ~ $ /sbin/ip rule show 6600: to 123.205.12.4 lookup batman_hosts [66] 6601: from all lookup batman_networks [65] 6700: to 123.205.12.4 lookup batman_unreach [67]
Host #1 (123.205.12.0) is in the routingtable of batman_hosts [66].
But i can not ping 123.205.12.0, because the kernel will not enter the rule 6600.
When i configure my Host #2 to a /24 network, all went fine. Then the rule will setuped as follow:
6600: to 123.205.12.4/24 lookup batman_hosts [66]
Ok, I see your problem. Batman could easily detect whether the host is part of any existing network and if not modify the routing rules. I see 2 options: * adding more rules to jump in table 66 * adding the node to table 65 instead of 66
What did you do to make it work ?
Regards, Marek
Am 07.09.2009 15:02, schrieb Marek Lindner:
And what is the MTU of the interface batman is running on ?
Did the iptables command I posted help you to fix your MSS problem ?
The interface where batman is running on have MTU 1460 (Standard Ethernet - UDP VPN Overload) on HOST #1. The interface where batman is running on have MTU 1500 (Standard Ethernet) on HOST #2. Yes, the iptables-command does the trick for me. This iptalbes-filter was known before. I added the filter to the mangle-table as the problem occurs.
My Root-Server (HOST #1) is located at Nuernberg, DE and have access to the internet with a public ip-space /22 that allocated to me. HOST #2 is connected to an lowcost ISP-Provider with 30MBits / 2MBits. HOST #2 is connected by VPN with HOST #1 to route the public ip-addresses.
IP-Host #1: 123.205.12.0 / 32 IP-Host #2: 123.205.12.4 / 32
IP RULES ON "HOST #2": ~ $ /sbin/ip rule show 6600: to 123.205.12.4 lookup batman_hosts [66] 6601: from all lookup batman_networks [65] 6700: to 123.205.12.4 lookup batman_unreach [67]
Host #1 (123.205.12.0) is in the routingtable of batman_hosts [66].
But i can not ping 123.205.12.0, because the kernel will not enter the rule 6600.
When i configure my Host #2 to a /24 network, all went fine. Then the rule will setuped as follow:
6600: to 123.205.12.4/24 lookup batman_hosts [66]
Ok, I see your problem. Batman could easily detect whether the host is part of any existing network and if not modify the routing rules. I see 2 options:
- adding more rules to jump in table 66
- adding the node to table 65 instead of 66
Correct. I've added some rules with "to any", and this does the trick. In addition i use my own policy-routing-script, because the "throw" event makes the routing-table a little fuzzy. Now i have only two routing-tables "batman_hosts" and "batman_networks". In my policy-routing-script i do the seperation between both tables.
What did you do to make it work ?
My policy-routing-script is attached.
Michael.
On Monday 07 September 2009 21:40:48 Michael Rack wrote:
The interface where batman is running on have MTU 1460 (Standard Ethernet - UDP VPN Overload) on HOST #1. The interface where batman is running on have MTU 1500 (Standard Ethernet) on HOST #2.
Ok, that is what I expected. Batman will take the 29 Bytes it needs from the given MTU.
Yes, the iptables-command does the trick for me. This iptalbes-filter was known before. I added the filter to the mangle-table as the problem occurs.
Ok, I'll make a patch to let batman handle this automatically. Thanks for bringing this up.
Correct. I've added some rules with "to any", and this does the trick. In addition i use my own policy-routing-script, because the "throw" event makes the routing-table a little fuzzy. Now i have only two routing-tables "batman_hosts" and "batman_networks". In my policy-routing-script i do the seperation between both tables.
You will need the throw routes as soon as you use the tunneling.
My policy-routing-script is attached.
Nice - happy to see it in action. :-)
Regards, Marek
Dear B.A.T.M.A.N List,
i do not like to use the -g option, to select the preffered gateway. I need a complete route-information.
I'm not able to set the HNA-Route 0.0.0.0/0 because a error-message appears: Invalid announced network (netmask is invalid): 0.0.0.0/0 The current workarround is, to set HNA-Routes for 0.0.0.0/1,128.0.0.0/1.
Is there a chance, that anyone make a patch to add a new option to "batmand"-command, to allow /0 routes?
The -g option should be disabled, in case the /0-option is enabled.
Liebe Grüße aus Freilassing,
Michael Rack RSM Freilassing
Hello Michael -
i do not like to use the -g option, to select the preffered gateway. I need a complete route-information.
I'm not able to set the HNA-Route 0.0.0.0/0 because a error-message appears: Invalid announced network (netmask is invalid): 0.0.0.0/0 The current workarround is, to set HNA-Routes for 0.0.0.0/1,128.0.0.0/1.
Is there a chance, that anyone make a patch to add a new option to "batmand"-command, to allow /0 routes?
The -g option should be disabled, in case the /0-option is enabled.
*sigh*
This question has been raised and discussed before. Should become part of a FAQ list. Check the mailing list archive. In 99.9% of the cases it is stupid to announce /0. Since the project is open source you or anyone else can modify the code and maintain a patch, for those who think it is smart to have this "feature". I would consider it a bug.
Cheers, Elektra
b.a.t.m.a.n@lists.open-mesh.org
-
elektra -
Marek Lindner -
Michael Rack