[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