[Xorp-users] PIM: questions

[Pavlin Radoslavov]

Husni,

> Two questions regarding PIM module:
> 1. I tried to use the "alternate-subnet" and MFEA complains 
>     proto_socket_read() failed: RX packet from AAA.BBB.91.25 to
> 239.255.255.250: no vif found
>     Looking at the proto_socket_read() code, the packet seems to get discarded.
>     Is this a bug?

Yes and no.

The purpose of alternative-subnet is to solve (in a hackish way)
a very narrow problem. If, say, you have the following
configuration:

Sender ..... Satellite receiver---R1---Your PIM-SM domain

The purpose of PIM-SM router R1 is to pick the data packets received
via the (uni-directional) satellite link, and to forward them toward
your PIM-SM domain. However, when the multicast data packets appear
on the link between the satellite receiver and R1, R1 will ignore
them because they don't appear to come from a directly-connected
source, and because most likely R1 doesn't have (S,G) Join state.

To solve that problem, the alternative-subnet configuration
statement can be used in R1 to instruct it that R1 should consider
the data packets for the defined subnet as coming from a
directly-connected source. Hence, the data packes from Sender will
be accepted by R1 for forwarding (e.g., the R1 will act as a DR for
all remote Senders and will send PIM Registers to the RP).

Note that the alternative-subnet setup applies only for the
multicast data packets (more specifically, how PIM-SM treats such
data packets). Those data packets should not be seen by
proto_socket_read(). Typically, only control packets (e.g., IGMP or
PIM) should be received by proto_socket_read(), so it is a bit of a
mistery for me what type of packet sent to multicast group address
of 239.255.255.250 has been received there.

Also, please note that currently the alternative-subnet
implementation has some deficiencies. E.g., the RPF interface toward a
remote sender must be same as the alternative-subnet interface.

In general, a much better solution is to implement the PMBR (PIM
Multicast Border Router) functionality, and then the PMBR will take
care of the data packets from the remote senders. Hence, once the
PMBR functionality is implemented, the alternative-subnet hack will
be removed.

In any case, I would strongly discourage you from using the
alternative-subnet configuration, unless you _REALLY_ need it.
Can you describe the problem you have been trying to solve?

> 2. Does PIMv6 really need to have a domain-wide address on each interface?
>     Isn't an interface with a domain-wide address enough for PIMv6
> router operation?
>     Suppose we have a PIMv6 router with two interfaces: fxp0 and fxp1, and the
>     link connected to fxp1 is designed to consist only  with routers. Therefore
>     basically there is no need to use a domain-wide address on this link.

Yes, I think you are correct. It is sufficient to have a single
domain-wide address per router instead of mandating that every
interface has such address. Though, if a router is not a Cand-RP or
Cand-BSR, and is not running MLD/IGMP, then it doesn't need any
domain-wide address.

For simplicity, the current implementation requires that all enabled
interfaces must have domain-wide address. This will be fixed in the
future.

Thanks,
Pavlin