[Xorp-users] PIM of FreeBSD implementation (was: Multicast without PIM on internal interface while PIM on external)

[Dan Lukes]

edrt napsal/wrote, On 06/16/05 07:08:
>>One thing you were probably seeing is that in the MFEA section you
>>enabled the interface toward the source, but you disabled it in the
>>PIM section: the MFEA received the NOCACHE upcall and accepted it,
>>but then PIM (correctly) threw it away.

> This scenario could cause performance degrade of PIM router. 
> Say, a source is multicasting large volumn data, PIM process
> router will constantly receive NOCACHE notification from kernel
> even if it isn't enabled on that interface.

> One method to alleviate the problem is to have MFEA MRT_ADD_VIF
> to kernel only those PIM enabled interfaces. But, this still doesn't
> prevent the not-directly-connected-network-source-address multicast
> host from bugging MFEA. Anybody have good method to solve the problem?

	Let's speak about non-local sources only.

	At the first, the kernel limit the NOCACHE rate, so it's not generated 
with every packet coming from the source.

	At the second, on consistently maintained network it should not be 
permanent state. It should be rare condition caused by misconfiguration 
of a part of network.

Scenario 1:
	Packet come from outside in. It should not come in into being. Nobody 
inside should subscribe G arriving throught us without our 
participation. This stream shouldn't be joined by us so upstream router 
should send this packet to us. Well, bad boy can send PI-Register to 
foreign RP. We should use firewall or law or whatever to force our users 
to configure it's computers properly.

Scenario 2:
	Packet come from inside out.
   2a: users are alowed to send packet to this group but apropriate 
RP(s) is/are temporary unavaiable - it's temporary network condition 
which must be resolved by an administrator
   2b: users are not allowed to send packets to this particular group - 
use firewall or law or ...
   2c: users are allowed to send this kind of packets, but those packet 
should be site-wide only so foreing RP didn't apply for those groups - 
create local RP which accept registration for apropriate group range.

  ---
	Well, there is problem with this implementation of multicast routing - 
current implementation is not optimal when you want PIM on one interface 
while other multicast routing protocol on second interface.

E.g. - Scenario 3 - packet come from interface running other multicast 
routing protocol than PIM

	This scenario reveal lack of current kernel design (on FreeBSD at 
least). The kernel to userland interface (I mean NOCACHE/WHOLEPKT 
signal) is not generic. It's PIM specific. But it's not XORP bug.

	If you want the optimal implementation you must select between 
following types:
1. complete kernel-level implementation of a routing protocol
2. complete user-level implementation (which grab necesarry packets by 
BPF, for example)
3. mixed implementation with protocol dependent kernel-to-user land 
interface ; it mean we can implement those multicast protocol wich are 
supported by kernel modifications only
4. mixed implementation with protocol independent kernel-to-user land 
interface (it scenario is used for unicast routing)

	Types [1] and [2] sounds bad for me.

	Curent implemenation is type [3], with mrouting protocol limited to PIM 
which must be running on all multicast interfaces.

	The [4] seems to be better, but there isn't required generic interface. 
I don't know if we can use the standart routing socket (with necesarry 
modification) as used for unicast protocols. I have insufficient 
experience with multicast so I'm unable to recommend something.

> Another similar scenario cause performance degrade of PIM router
> is about WHOLEPKT. When a source is multicasting large volumn data
> and PIM router has no idea about a particular RP(G), PIM process

It should not come in into being unless temporary network infrastructure 
or RP breakdown or policy violation caused by user within my network.

Well it didn't mean we can't protect against it.

> Add below code might alleviate the problem on FBSD with advance mcast api.
...
> (Pls let me know if you find the above code piece has defect)

	It must wait to somebody more familiar with FreeBSD's PIM 
implementation. I can't evaluate it.

						Dan