Re: [B.A.T.M.A.N.] Route selection over VPN links
Hi! On Mon, Jul 16, 2012 at 3:02 AM, Marek Lindner lindner_ma...@yahoo.de wrote: Hi, As we are nearing to our transition to Batman, we are playing some scenarios with it and our current setups and layouts. Currently we have many nodes connected to more and more VPN servers we have. And we would like to use Batman on top of that. What happens is that we would like to use the Batman also for routing over those VPN links. So that we can connect our nodes to all VPN servers at the same time and Batman then chooses over which tunnel the data should be routed. And of course this is a bit different situation then wireless routing. For example, different VPN servers might have different free capacities at the moment available, or at least different overall capacity provided (somebody can donate 100 Mbit/s on the server, somebody else 50 Mbit/s), and then there are also different latencies. Is there some way for Batman to prefer routes based on this information? So latency over one link and capacity? I know that capacity is problematic to measure for wireless links, but here we could configure them manually. Latency could be measured. And maybe it would even be enough to measure latency, assuming that congested link would have higher latency. So the logic could be: * if packet loss is different, choose the one with lower packet loss * if packet loss is the same, choose the one with lower latency Such logic could probably be even user also on wireless links, no? Anyway, is this doable? If I understand correctly, Batman does not support some plugin system where we could inject this in? Would be this some addition which could go into the core implementation? I think I asked a bit of this questions before, but now we have a bit more concrete picture what would be nice to have for our setup to play really nicely. the later versions of batman support a routing protocol plugin structure (check bat_iv_ogm.c to get an idea). Using bandwidth information for the routing decision is a nice idea but how does your concept look like ? How should the routing logic look like ? I thought I explained it enough. So for now, I would just go with only measuring latency (I don't know what would be the best way to measure this, though). If I have the latency (and this could be only one hop), I would do: * if packet loss is different, choose the one with lower packet loss * if packet loss is the same, choose the one with lower latency in the next hop What do you think? Mitar
Re: [B.A.T.M.A.N.] [PATCHv5 3/3] batman-adv: change interface_rx to get orig node
On Thursday, July 05, 2012 23:38:30 Antonio Quartulli wrote: In order to understand where a broadcast packet is coming from and use this information to detect not yet announced clients, this patch modifies the interface_rx() function by passing a new argument: the orig node corresponding to the node that originated the received packet (if known). This new argument if not NULL for broadcast packets only (other packets does not have source field). Signed-off-by: Antonio Quartulli or...@autistici.org --- Changes since v4: - noop routing.c| 10 ++ soft-interface.c |6 +- soft-interface.h |5 +++-- 3 files changed, 14 insertions(+), 7 deletions(-) Applied in revision 9cbc67d. Thanks, Marek
Re: [B.A.T.M.A.N.] [PATCHv3] batman-adv: Add wrapper to look up neighbor and send skb
On Monday, July 09, 2012 00:00:29 Martin Hundebøll wrote:
+bool batadv_send_skb_to_orig(struct batadv_orig_node *orig_node,
+struct sk_buff *skb,
+struct batadv_hard_iface *recv_if)
+{
+ struct batadv_priv *bat_priv = orig_node-bat_priv;
+ struct batadv_neigh_node *neigh_node;
+
+ /* batadv_find_router() increases neigh_nodes refcount if found. */
+ neigh_node = batadv_find_router(bat_priv, orig_node, recv_if);
+ if (!neigh_node)
+ return false;
+
+ /* route it */
+ batadv_send_skb_packet(skb, neigh_node-if_incoming,
neigh_node-addr); +
+ batadv_neigh_node_free_ref(neigh_node);
+
+ return true;
+}
Can we make the skb variable the first argument ? Something like this:
bool batadv_send_skb_to_orig(struct sk_buff *skb,
struct batadv_orig_node *orig_node,
struct batadv_hard_iface *recv_if)
Regards,
Marek
Re: [B.A.T.M.A.N.] Route selection over VPN links
On Tuesday, July 17, 2012 08:36:30 Mitar wrote: the later versions of batman support a routing protocol plugin structure (check bat_iv_ogm.c to get an idea). Using bandwidth information for the routing decision is a nice idea but how does your concept look like ? How should the routing logic look like ? I thought I explained it enough. So for now, I would just go with only measuring latency (I don't know what would be the best way to measure this, though). If I have the latency (and this could be only one hop), I would do: * if packet loss is different, choose the one with lower packet loss * if packet loss is the same, choose the one with lower latency in the next hop I was more curious about the bandwidth routing than the latency stuff. The current routing algorithm already takes latency into account. An alternate path always need to be better than the current path. If both paths are equal the faster packets win the race. Regards, Marek
Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
Hi Guido, In both configurations described, there's one router running batman and the other connected via ethernet which is not. The function of the latter is just to forward batman packets between ethernet and wifi. That way the batman routers see alternative paths to their neighbours through their ethernet interfaces. For this to work, however, it's necessary to do something in the router which doesn't run batman, because a normal ad hoc interface using 2 MAC addresses doesn't work in a bridged configuration. That's why Simon suggested the 4-addr mode in ad hoc, but unfortunately, we found that with ath9k it's not possible to use that mode. So we began with the configuration 1) where we didn't use ad hoc, but instead we tried with ap and sta using wds (a mode with 4-address for access points and stations). As mentioned previously, the problem with this configuration was that as we were using both ap and sta bridged in the same non-batman forwarding router (to achieve alternative paths between all nodes), the batman broadcast packets were being forwarded directly. That's where we tried with ebtables + ad hoc (config 2). This way using ebtables and the cloned MACs we don't need 4-addr mode, and the batman routers see the alternative paths through their ethernet interfaces. But for this to work, the batman routers need to use ebtables also, not just the forwarding routers, because we change the dst MACs in both the forwarding and the batman routers. And for using ebtables in a router running batman, we had to add eth0 to a bridge, and then add the bridge to bat0, that's what i was saying with that sentence. Look at this thread: https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2010-May/002716.html By the way, we're using batman-adv 2012.0.0 Anyway, all this was just to achieve link alternation using two routers with 1 radio each. With 2 radios it would be much better i guess. Please tell me if something is still unclear. Best regards Gabriel El 14/07/2012 06:35 p.m., Guido Iribarren escribió: Ah, i missed this sentence In the normal configuration with batman managing eth0 it doesn't work. why? How was the setup? Which batman version? I came across something like this (reported in a previous thread) but so far i haven't had spare time to reproduce it again to debug it. On 7/14/12, Guido Iribarren guidoiribar...@buenosaireslibre.org wrote: You can try taking eth0 out of the bridge and adding it to bat0 that way you wouldn't need to mess with ebtables? As there would be no bridged interfaces, batman would be the only one forwarding packets between eth0 and wlan0. With hop penalty. On 7/13/12, gto...@inti.gob.ar gto...@inti.gob.ar wrote: Hi. We've been trying two different configurations to use link alternation with two routers conected via ethernet. In both cases in each pair of routers one runs batman and the other only forwards traffic between ethernet and wifi, as Simon suggested: 1) First in the forwarding routers we configured an AP and a station, both using wds. The idea was to form a chain of pairs of routers, where each forwarding router were connected to the previous and the next forwarder using those sta and AP interfaces, as can be seen in conf_1.png. Unfortunately we found that with this configuration the broadcast batman packets were forwarded through all the chain without any batman processing. For example, Batman 1 sends an Originator which goes out through its ad hoc interface, and also through ethernet, then Forward 1 sends it through its sta to Forward 2. In Forward 2 the sta, ap and ethernet interfaces are bridged, so the Originator goes to Batman 2 via ethernet (that's ok) but also goes directly to Forward 3 without the hop penalty applied. As a result Batman 3 sees the ethernet interface of Batman 1 as a direct neighbour with a good quality. In a longer chain the result would be the same. 2) A solution to the first configuration could be use some ebtables rules, but using ebtables we directly tried with normal ad hoc interfaces. So we used the configuration seen in conf_2.png. We cloned the MACs of the Batman ethernet interfaces to the ad hoc interfaces. That way the packets destined by Batman to the ethernet interfaces of their neighbours enter through the wireless interfaces because they have the same MAC. Once inside the Forwarding routers we use this rule: ebtables -t broute -A BROUTING -i wlan0 -d MAC1 -j dnat --to-dst MACX --dnat-target ACCEPT So changing the dst MAC the packets are forwarded through ethernet. In the BATMAN routers we used this rule to change again the dst MAC: ebtables -t broute -A BROUTING -i eth0 -d MACX -j dnat --to-dst MAC1 --dnat-target ACCEPT For using ebtables with Batman we had to attach eth0 to a bridge, and add that bridge to batman. In the normal configuration with batman managing eth0 it doesn't work. For the reverse path, packets entering to Forwarding routers from Batman routers it wasn't
Re: [B.A.T.M.A.N.] Route selection over VPN links
Hi! On Tue, Jul 17, 2012 at 3:57 AM, Marek Lindner lindner_ma...@yahoo.de wrote: I was more curious about the bandwidth routing than the latency stuff. The current routing algorithm already takes latency into account. An alternate path always need to be better than the current path. If both paths are equal the faster packets win the race. Hm. This happens only first time, it does not really change the route latter on, if chosen path latency increases and becomes worse than the second path, but packet loss stays the same (zero). Or it does? For bandwidth, I would say that we first need multipath routing. And then route on all possible paths some percentage of packets, based on given capacity ratio. So if you have three paths A, B, and C with same packet loss and capacity Ca, Cb, and Cc, you route over A with Ca/(Ca + Cb + Cc) ratio. The other way would be to route based on free capacity, but this means you would also have to know how much capacity is already taken for the given path. This is probably hard. But for given interface maybe not so much. So for wall links we probably cannot know capacity. (This is especially true for WiFi.) But for some links we can know (VPN links, especially where people can set caplimit how much of their link they want to donate to the network). So probably this information (link cap and free capability) should be transmitted to all neighbors. And for those links where you have this additional information, I would route like: - if packet loss on a path is different for some epsilon, route based on that - if latency on a path is different for some epsilon, route based on that - otherwise route based on the largest free capacity for some epsilon available for the next hop (or preferably even path) This would do correct thing for the case of VPN links, where most of links will have almost zero packet loss, latency will be or small (for local VPN servers) or big (for foreign VPN servers), and then based on free capacity we would route on that. So there should be some hysteresis and some epsilon equality so that we do not flap the links all the time. One more thing, we have currently one gateway server and multiple VPN servers connecting to it. So most of the time traffic flows from or to this gateway server from VPN servers. So if we transmit around information about capacity on links, this would be a case where nodes connected to multiple VPN servers could decide not just on next hop capacity link, but also on the link to gateway. And so not just congest the VPN server, because the link to it is free, but that also link from it to gateway server should be free. The above logic tells me, that routing plugins could be stacked. So that you could have a stack of routing decisions where each of plugins in the stack, in order, over which paths the packet should be routed. It simply returns a list of those with some ratio/vote on each path. Or simply remove some out of the list if it determines it is really bad. For example, for above logic, for paths A, B and C: - packet loss would return [A:0.33, B:0.33, C:0.33] because there is no significant packet loss - latency would return the same - free capacity would return [A:(Ca/(Ca + Cb + Cc)), ...] And at the end, for now, Batman could choose the best one route. Later on with multipath routing, it could use this information to choose for example n best. Just some ideas ... Mitar
Re: [B.A.T.M.A.N.] Route selection over VPN links
On Tue, Jul 17, 2012 at 11:06:27AM -0700, Mitar wrote: Hi! On Tue, Jul 17, 2012 at 3:57 AM, Marek Lindner lindner_ma...@yahoo.de wrote: I was more curious about the bandwidth routing than the latency stuff. The current routing algorithm already takes latency into account. An alternate path always need to be better than the current path. If both paths are equal the faster packets win the race. Hm. This happens only first time, it does not really change the route latter on, if chosen path latency increases and becomes worse than the second path, but packet loss stays the same (zero). Or it does? For bandwidth, I would say that we first need multipath routing. And then route on all possible paths some percentage of packets, based on given capacity ratio. So if you have three paths A, B, and C with same packet loss and capacity Ca, Cb, and Cc, you route over A with Ca/(Ca + Cb + Cc) ratio. You have to be careful with packet reordering. If i remember correctly, Linus did some measurements when link bonding was introduced in BATMAN. TCP can cope with packet reordering, but it has negative effects on goodput. ... This would do correct thing for the case of VPN links, where most of links will have almost zero packet loss, latency will be or small (for local VPN servers) or big (for foreign VPN servers), and then based on free capacity we would route on that. Are these assumptions really true? In my home setup, my ADSL modem is where my telephone socket is. My VPN server is somewhere else and there is a wifi and a powerline link in between. If my neighbors swamp the wifi channel with their torrent download, my VPN will suffer. (Well not really, i known this wifi stuff better than my neighbors) Andrew
Re: [B.A.T.M.A.N.] Route selection over VPN links
Hi! On Tue, Jul 17, 2012 at 11:22 AM, Andrew Lunn and...@lunn.ch wrote: You have to be careful with packet reordering. Hm. True. Yes, maybe multipath routing is just in theory a good idea. ;-) I also don't really believe in it. Or even believe it is necessary. But some balancing could be useful to have. For example, based on origin. So all packets from same origin goes on the same link, and the other on the other. Is this possible to achieve? Are these assumptions really true? In my home setup, my ADSL modem is where my telephone socket is. My VPN server is somewhere else and there is a wifi and a powerline link in between. If my neighbors swamp the wifi channel with their torrent download, my VPN will suffer. (Well not really, i known this wifi stuff better than my neighbors) I think we talk about different topologies here. We have a gateway server on collocation, with VPN servers spread around the country. We connect all nodes to those VPN servers, and VPN servers to gateway server. We do not use ADSL uplinks for anything else than just to connect to those VPN servers. I am not talking about user's VPN servers, but network's. The ones which allow nodes to be in the same network even if there is no (yet) existing WiFi link between them. Mitar
