[Xorp-users] OLSR test results on Linux.

Bruce Simpson bms at incunabulum.net
Thu Jul 9 14:49:58 PDT 2009


Ben Greear wrote:
>
> Where is the loop detection lacking?  Is this any different from running
> OSPF and pimsm beside it?

OSPF doesn't know anything about multicast; you still need to run PIM 
within an OSPF domain at each hop. PIM will protect against forwarding 
loops, either by tunneled unicasting to the RP, or forming a shared tree 
based on its discovered topology. PIM will generally use the unicast 
routes learned by OSPF by pulling them into the MRIB.

OLSR doesn't know anything about multicast. Whilst you could configure 
PIM peerings to nodes inside the OLSR cloud, this is largely pointless, 
if the topology is highly dynamic. PIM's in-built detection mechanisms 
like Asserts are just not designed with cloud in mind -- they work, for 
the most part, within shared broadcast domains like Ethernet, but 
they're not relevant to something like ATM which is NBMA.

So there is no protection against multicast storms / packet 
amplification if there is a forwarding loop, unless you use something 
like the SMF draft.

Forwarding loops can, and do, form within clouds, and this is one reason 
why various tunables, like weights, willingness-to-forward etc., exist 
in OLSR.

I guess what you could do, as a workaround, is to hack mbonetools or 
something to forcibly install a tunnel-to-the-rp style entry to the 
multicast forwarding cache on the OLSR nodes. This effectively means 
that any multicast traffic originating within the cloud is always 
tunneled to the RP as a unicast packet.

>
> Our use case is multiple OLSR (xorp) routers in a mobile mesh network.
> Anything transmitting or receiving multicast will be directly attached
> to a router in the normal case.

You should be OK, providing you don't intend to forward multicast 
traffic within the OLSR cloud itself -- i.e. it only originates from 
outside the cloud, and does not cross more than 1 hop to the OLSR 
node(s). If the hop count at the OLSR domain gateway router ends up 
being greater than 1, and OLSR nodes are configured to forward 
multicast, you risk a packet storm.

>
> We did the same thing with OSPF & multicast routing and it seems to
> basically work that way at least.  From looking at the routes that OLSR
> generates (for a simple network, at least), it seems pretty similar to
> what OSPF does.
>

OLSR is conceptually similar, in some respects, to OSPF, but the 
similarities stop as soon as you get to Topology Control. HNA is a bit 
of a hack to put it bluntly.

>
> Got any pointers to what you are talking about here?

http://tools.ietf.org/html/draft-ietf-manet-smf-08

cheers
BMS



More information about the Xorp-users mailing list