Re: [B.A.T.M.A.N.] Batman-adv hna balancing

Re: [B.A.T.M.A.N.] Batman-adv hna balancing

[Marek Lindner]

On Friday 15 April 2011 13:03:26 Gioacchino Mazzurco wrote:
> I think batman shouldn't handle mac duplication as conflict but simply
> act as the two nodes see the same clients, like olsrd do when multiple
> nodes announces the same hna

The HNA IP addresses have the same functionality as (HNA) mac addresses for 
batman-adv, therefore we talking about the same thing.

Regards,
Marek

Re: [B.A.T.M.A.N.] Batman-adv hna balancing

[Marek Lindner]

Hi,

> Here you can see our topology, there is two nodes at moment they are
> connected to the same switch and should see same hnas but they are
> announced mostly by one of the two
> http://eigenlab.org/batman-adv_status.php
> 
> If i turn off the cc:c8 node the hna pass to the other nodes but when
> i turn it on all hna pass on it
> 
> Why this? Is not better to balance hna announcing?

the 2 batman-adv nodes probably detected they are connected to the same switch 
and activated the bridge loop avoidance [1]. With 'batctl sn' you can retrieve 
the bridge loop neighbor list.

Regards,
Marek


[1] http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance

Re: [B.A.T.M.A.N.] Batman-adv hna balancing

[Gioacchino Mazzurco]

ok understood

many thanks!

2011/4/16 Marek Lindner <lindner_marek@yahoo.de>:
>
> Hi,
>
>> Here you can see our topology, there is two nodes at moment they are
>> connected to the same switch and should see same hnas but they are
>> announced mostly by one of the two
>> http://eigenlab.org/batman-adv_status.php
>>
>> If i turn off the cc:c8 node the hna pass to the other nodes but when
>> i turn it on all hna pass on it
>>
>> Why this? Is not better to balance hna announcing?
>
> the 2 batman-adv nodes probably detected they are connected to the same switch
> and activated the bridge loop avoidance [1]. With 'batctl sn' you can retrieve
> the bridge loop neighbor list.
>
> Regards,
> Marek
>
>
> [1] http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance
>

[B.A.T.M.A.N.] Batman-adv hna balancing

[Gioacchino Mazzurco]

Hi!

I am installing batman-adv on nodes on our mesh networks in Pisa, but
i have a question

Here you can see our topology, there is two nodes at moment they are
connected to the same switch and should see same hnas but they are
announced mostly by one of the two
http://eigenlab.org/batman-adv_status.php

If i turn off the cc:c8 node the hna pass to the other nodes but when
i turn it on all hna pass on it

Why this? Is not better to balance hna announcing?

Very thanks!

Re: [B.A.T.M.A.N.] Batman-adv hna balancing

[Antonio Quartulli]

Hi Gioacchino,

On ven, apr 15, 2011 at 10:07:13 +0200, Gioacchino Mazzurco wrote:
> Hi!
> 
> I am installing batman-adv on nodes on our mesh networks in Pisa, but
> i have a question
> 
> Here you can see our topology, there is two nodes at moment they are
> connected to the same switch and should see same hnas but they are
> announced mostly by one of the two
> http://eigenlab.org/batman-adv_status.php
> 
> If i turn off the cc:c8 node the hna pass to the other nodes but when
> i turn it on all hna pass on it
> 
> Why this? Is not better to balance hna announcing?
> 
> Very thanks!


What you are observing is part of a more general problem that we are
already taking into account: What to do if two nodes detect to be
connected to the same client (same MAC address). It is not a simple
problem and we are trying to figure out which could be a good solution.
(Ideas are welcome :D)

With the actual implementation, if I am not wrong, the last received OGM
that carries the client MAC address wins. Because there is not a real
mac conflicting handling procedure.

Moreover, in your case, you have a switch in between, so I can imagine
that the traffic is redirected to one or to the other node on the switch
basis depending on the packet destination. So, even with a mac conflict handling
procedure, I think that this situation would be a bit tricky to be
managed.

I hope I've been clear in what wanted to say. :)

bye

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

Re: [B.A.T.M.A.N.] Batman-adv hna balancing

[Gioacchino Mazzurco]

>So, even with a mac conflict handling
>procedure, I think that this situation would be a bit tricky to be
>managed.

I think batman shouldn't handle mac duplication as conflict but simply
act as the two nodes see the same clients, like olsrd do when multiple
nodes announces the same hna

2011/4/15 Antonio Quartulli <ordex@autistici.org>:
> Hi Gioacchino,
>
> On ven, apr 15, 2011 at 10:07:13 +0200, Gioacchino Mazzurco wrote:
>> Hi!
>>
>> I am installing batman-adv on nodes on our mesh networks in Pisa, but
>> i have a question
>>
>> Here you can see our topology, there is two nodes at moment they are
>> connected to the same switch and should see same hnas but they are
>> announced mostly by one of the two
>> http://eigenlab.org/batman-adv_status.php
>>
>> If i turn off the cc:c8 node the hna pass to the other nodes but when
>> i turn it on all hna pass on it
>>
>> Why this? Is not better to balance hna announcing?
>>
>> Very thanks!
>
>
> What you are observing is part of a more general problem that we are
> already taking into account: What to do if two nodes detect to be
> connected to the same client (same MAC address). It is not a simple
> problem and we are trying to figure out which could be a good solution.
> (Ideas are welcome :D)
>
> With the actual implementation, if I am not wrong, the last received OGM
> that carries the client MAC address wins. Because there is not a real
> mac conflicting handling procedure.
>
> Moreover, in your case, you have a switch in between, so I can imagine
> that the traffic is redirected to one or to the other node on the switch
> basis depending on the packet destination. So, even with a mac conflict handling
> procedure, I think that this situation would be a bit tricky to be
> managed.
>
> I hope I've been clear in what wanted to say. :)
>
> bye
>
> --
> Antonio Quartulli
>
> ..each of us alone is worth nothing..
> Ernesto "Che" Guevara
>