Re: Routing SMP benefit

Andre Oppermann wrote:
Haven't looked at the multicast code so I can't comment. The other
stuff is just talk so far. No work in progress, at least from my side.

Insofaras rmlocks and cache line size vs rtentry size applies to multicast:

I know there are implementations out there which use the unicast BSD routing code to do multicast. This is preferable as the MROUTING implementation in the main tree has a 32 vif limitation. Moving this into the main radix trie code allows us to overcome these limitations.

Recall that a multipath FIB holds multiple next-hops for each route. Multicast routes need the same, but they also need to send traffic to all of the next-hops. This is basically what the MROUTING code does, but it does so completely separately from the unicast forwarding code. The reasons for this are mostly historical -- folks wanted to develop it separately from unicast IPv4.

For IETF MANET, ie tactical mobile IP networks, we need to be able to address multicast next-hops by their unicast address -- most of the time we can't reliably use link layer multicast or even IGMP to reach all subscribers, or use PIM shared trees, so flooding is necessary -- as well as being able to disable the existing RPF checks on inbound traffic from MANET interfaces. In situations like this, 32 next-hop

I'm aware this is only marginally related to the DFZ/tier-1 router scenario, but, it's something I want FreeBSD to support as it allows IP networks to be deployed in novel situations i.e. where no existing infrastructure exists, and centralized/hierarchical network infrastructure isn't suitable (think International Rescue).

So it's something to think about for folks doing multipath work -- the same performance constraints which affect struct rtentry *now* for SMP and multipath work will potentially affect multicast forwarding in future.

regards
BMS
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • RE: nlb mode
    ... In my experience I have used both unicast and multicast. ... It all depends on what your NLB hosts will be doing and if they need to ... there is no inter-host communication possible between the hosts ...
    (microsoft.public.windows.server.clustering)
  • Re: nlb mode
    ... I would need inter-host communication for the same reason as you: ... Now I could do Unicast & add a 2nd nic to each server, ... > In my experience I have used both unicast and multicast. ... Since all hosts in the cluster have the same IP Address and the same MAC ...
    (microsoft.public.windows.server.clustering)
  • Re: Message sender and receiver for unicast+multicast+Broadcast
    ... > unicast, multicast, Broadcast and get the ACK for every message sent. ...
    (comp.unix.programmer)
  • Re: nlb mode
    ... Ok based on this information I would use multicast without a doubt. ... flooding unicast will actually cause in your network setup. ... static arp entries if required by your router. ... >> multicast address to the cluster instead of changing it and this makes ...
    (microsoft.public.windows.server.clustering)
  • Re: resend: multiple routing table roadmap (format fix)
    ... However it makes sense to merge the multicast and unicast forwarding code as currently MROUTING is limited to a fan-out of 32 next-hops only. ... As regards getting ARP out of forwarding tables, this should have happened a long time ago... ...
    (freebsd-arch)