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

[Michael Rack]

Hi Markus,

thank you. I don't believe it, but it is true ;) OLSR now goes 
unicast... a dream ;)
Ipv4Broadcast is a misconducted name for unicasting, but it does the job ;)
Verify with tcpdump -ni vlan1 port 698 and ether host 00:12:3f:a0:f7:b6 
was successful.

I did not use packet aggregation. I have no option "multicast 
optimization", the handbook shows such a configuration option, but it is 
not available. The units have to be replaced by Ubiquity Hardware.

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 17.02.2011 20:16, Markus Kittenberger wrote:
> 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) 
> <mailto:(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 Freilassingwww.rsm-freilassing.de  <http://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)
>>     <mailto:(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) <mailto:(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/92ea05c5/attachment.html>