Hi,

On Thursday 27 December 2007 13:20, Simon Wunderlich wrote:

the URL is broken, i guess the right URL is http://layer-acht.org/batman/

well yes, and no :-) It's batmand now (as the package name). Thanks for noticing!

regards, Holger

Hi,

I've added support to send BATMAN routes to zebra daemon and redistribute them to other Quagga protocols. The interface is through zebra UNIX socket. A new option -q followed by the UNIX socket path is added (see batmand --help) to enable route export. I've also implemented a metric for BATMAN routes based on TTL value which is essential when using BATMAN as IGP to BGP Confederations.

thanks for submitting your work. I published it on our website so that others can find it: https://www.open-mesh.net/batman/patches

By the way: Using the TTL as basis for a hop metric is ambiguous and may lead to errors. By doing so you assume that every host uses the same start TTL and every hop decreases it in the same way. The B.A.T.M.A.N. protocol does not demand or enforce this behaviour. On the other hand the hop count does not reflect the quality of a path. May be it would be a better approach to calculate the link quality into the metric so that hop based protocols can do a better decission.

Regards, Marek

Στις Monday 31 December 2007 02:01:49 ο/η Acinonyx έγραψε:

Hello ppl,

I've added support to send BATMAN routes to zebra daemon and redistribute them to other Quagga protocols. The interface is through zebra UNIX socket. A new option -q followed by the UNIX socket path is added (see batmand --help) to enable route export. I've also implemented a metric for BATMAN routes based on TTL value which is essential when using BATMAN as IGP to BGP Confederations.

Hello again,

I've fixed a bug in zebra client route update which tried to delete routes with the new metric instead of the previously installed.

I've also tried to calculate a metric based on link quality. Unfortunately, I wasn't able to find a way to compare latency between two different originators. Originators could only be compared based on packet loss which isn't what we want because it would lead to having the same metric (1) for all nodes if there isn't some packet loss present. So, we are staying for the moment with the TTL approach with some adjustment to make it safer with different TTL settings.

I also want to point out an issue with batmand host routes and Quagga. Although Quagga succesfully installs host routes, it doesn't treat them as valid gateways if the associated interface isn't flaged as P-t-P. I don't know if this is a bug or a feature but it renders all batmand second level routes inactive. I added a workaround in zebra client which disables host route installation. This means that you can use quagga zebra client only if you have standard broadcast subnets.

The attached patch is against latest stable BATMAN release (revsion 502).

Regards, Vasilis

Στις Sunday 20 January 2008 09:52:41 ο/η Axel Neumann έγραψε:

Hello Axel,

Assuming information about the latency is available. I guess you would like to use it as a secondary input when calculating the metric. Do you know (or have any feeling) how problematic it can become if the indicated latency for a given route is changing very frequently (definitely much more often than the best next hop and related TTL).

I would like to use it as primary input for metric calculation. The reason I wrote quagga zebra client is to be able to use B.A.T.M.A.N. as IGP in a BGP Confederation. BGP minimum route advertisement interval is by default 30 seconds and updating route metric more frequently than that isn't necessery. I haven't given this step much thought since I realised that there is no way to compare latency between different originators but I think I could calculate the average latency from an originator and update metrics every x seconds interval (30 secs in my case).

I am not familiar with quagga. Why is it problematic to have several routes with the same metric. Or asked another way: There could also be several routes (to the same destination) with the same TTL. Why does this problem not exist in this case?

In a BGP Confederation, best path selection is based on IGP metric since all the other criteria are always equal. If IGP metrics are also equal, then path selection falls to the rule: 'Prefer the route that comes from the BGP router with the lowest router ID'. This creates a major problem when all metrics are equal because it always favors the selection of paths that come from one specific BGP router.

what is your definition of a standard broadcast subnet ? is it "POINTOPOINT,MULTICAST,NOARP,..." and /32 ?

A subnet on an interface flaged as BROADCAST with a prefix length < /32

Best Regards, Vasilis