[Olsr-users] Route-Flapping | Out of Control [Deutsch]

[Markus Kittenberger]

afair just specify an unicast adress (the ip address of the neighbour) for
Ipv4Broadcast on both sides, and it should be unicast traffic

bust maybe its still a broadcast, using an adress that looks like an unicast
adress

(so better look at the ethernet header with tcpdump to be sure,.. (you
should see the mac of your neighbour, an no multicast ethernet adress))

Markus

p.s. did u enable packet aggregation (or multicast optimization) on your
osbridges, if so, turn it off!


On Thu, Feb 17, 2011 at 5:52 PM, Michael Rack <
(spam-protected)> wrote:

>  Dear Markus and list,
>
> is there a change to get OLSR working UNICAST and not MULTICAST in Layer 2?
>
> My Problem is not solved, my OSBRIDGE is routing MULTICAST differently then
> UNICAST. OSBridge does not ACK Multicast Packets, so that when the link
> becomes full, Multicast-Traffic (LAYER2) is not reach the destination.
>
> The Setup is P2P, so UNICAST makes sense.
>
> How to get OLSR to send HELLO-Messages and all others as UNICAST?
>
>
> Liebe Grüße aus Freilassing,
>
> Michael Rack
> RSM Freilassing
> --
> RSM Freilassing                 Tel.: +49 8654 607110
> Nocksteinstr. 13                Fax.: +49 8654 670438
> D-83395 Freilassing            www.rsm-freilassing.de
>
>
> On 23.12.2010 23:14, Markus Kittenberger wrote:
>
>
>
> On Thu, Dec 23, 2010 at 9:16 PM, Michael Rack <
> (spam-protected)> wrote:
>
>>
>> > OLSR packets are sent over multicast.  In IEEE 802.11, unicast and
>> > multicast packets use different link-layer protocols, and it's fairly
>> > usual to see much higher loss rates for multicast than for unicast
>> > packets.
>>  OLSR packets are set via broadcast, not multicast ;)
>> multicast is a routed subnet via IGMP in range 224.0.0.0 -
>> 239.255.255.255.
>>
> routet or not, or which iprange, makes no difference at layers < 3
>
>  regarding ethernet layer 2 any mac adress having the last bit of the
> first byte set to 1 is a multicast,..
> this includes broadcasts FF:FF:FF:FF:FF:FF or various types of
> multicasts,..
>
>>  Broadcasts should not be dropped anyway.
>>
> having higher loss rate, does not imply the packets are actively dropped,..
>
> i think what juliusz meant was that multicasts (including broadcasts) are
> not acked or retransmitted in most IEEE 802.11 modes (e.g. WDS links are an
> exception)
> thats why multicasts are usually easier lost than unicasts,..
>
>  but osbridges are definetely not "always" IEEE 802.11 conform,..
> (i think you mentioned that this link is done with osbridges,..)
>
>  (to compensate this expectable higher loss rates) broadcasts are usually
> sent with another (usually lower) bitrate:
> the multicastrate
>
>  which is afair "unconfigureable" on osbridges,..
> (but osbridge have a setting called "Multicast Optimization", which imho is
> better turned off *G,or at least try if changing it dos have effects on your
> problem,..)
>
>  but osbridges are definetely not "always" IEEE 802.11 conform,..
>
> e.g. when used in ptp-bridge mode, they do somewhat wdslike things (but not
> exactly wds)
> (but they will handle broadcasts like unicast in this mode afair,.. (i.e
> the ack anr retransmit))
>
>  btw. i had once an rb411(bridge mode)-osbridge(ptp-client) link having
> (sometimes) unbelieveable high olsr packet loss (about 90%, while the link
> itself was doing fine), imho not explainable by lack of retransmits alone.
>
>  i temporary fixed this by tunneling the traffic through this link (which
> transformed all broadcasts to unicasts)
> (and later i replaced the osbridge against a routerboard,..)
>
>  another approach would be to configure olsrd to use unicasts instead of
> broadcasts *G (i.e. ip4broadcast=neighbor_ip on both sides) (of course this
> only makes sense on a ptp link!!)
>
>  but when using 2 osbridges i never had such problems (but i don`t use
> them since years ago for many other reasons,..)
>
>  Markus
>
>>
>> --
>> Olsr-users mailing list
>> (spam-protected)
>> http://lists.olsr.org/mailman/listinfo/olsr-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20110217/3f2b1c6f/attachment.html>