[Xorp-users] Re: Newbie Xorp & m'cast problem

[Pavlin Radoslavov]

> 	Well, I catch one source. It's very interesting.
> 
> 	All messages come from 0.0.0.0, same MAC 0011.936d.61b2. All are IGMP 
> leave, TTL=1, TOS=0xC0. All have the same destination - 
> ALL-ROUTERS.MCAST.NET

<DEL>

> 	The MAC prefix is allocated to Cisco Systems.
> 
> 	But we have no Cisco routers. Only 38 Cisco switches.
> 
> 	Cisco documentation says:
>   ------
>   When a switch with IGMP snooping enabled receives an IP group-specific 
> IGMPv2 leave message, it sends a group-specific query out the interface 
> where the leave message was received to determine if there are any other 
> hosts attached to that interface that are interested in the MAC 
> multicast group. If the switch does not receive an IGMP join message 
> within the query-response-interval and none of the other 31 IP groups 
> corresponding to the MAC group are interested in the multicast traffic 
> for that MAC group and no multicast routers have been learned on the 
> interface, then the interface is removed from the port list of the 
> (mac-group, vlan) entry in the L2 forwarding table.
>   ------
> 
> 	Othere part of documentation says the IGMP leave packet is forwarded 
> only when there are no other subscribers to group in question on the 
> same switch.
> 
> 	My theory:
> Imagine there is only port on a switch subscribed to a group. The link 
> on the port is going down with no IGMP LEAVE sent by station connected 
> to it. The switch know that last subscriber of a group disapeared. So, 
> it sends IGMP LEAVE by self. As it have no IP it uses 0.0.0.0 which mean 
> "unknown source".
> 
> 	It allows the switch to unsunbscribe the unnecesarry multicast traffic 
> as soon as possible to maintain optimal bandwidth management. I can't 
> say it seems to be bug.

Interesting theory, and you may be right about how those packets
have been generated.
I don't want to argue about the legitimacy of such packets, but
insde the IGMPv3 spec (RFC-3376) which we plan to implement in the
future I found the following text in the Security Considerations
section:

"State-Change Report messages with a source address of 0.0.0.0 SHOULD
be accepted on any interface."

Hence, this is a good enough reason for me to modify the MFEA to
accept link-local multicast packets with source address of 0.0.0.0
and let the protocol module itself deal with it.
Though, the MFEA would accept the packets only if the kernel told it
where the packet came from.

If time allows, we will have this implemented for the next release.
In addition, there probably will be an IGMP configuration statement
to enable IGMP Leave messages with source address of 0.0.0.0 (as you
suggest).


> P.S. Within other message I asked about interface connected to pure IGMP 
> subnet without PIM allowed on it.  I would ask you, Pavlin, for very 
> short response. It no problem if current XORP didn't support this kind 
> of configuration, but I'm not sure I didn't miss something important 
> within documentation. Thank you very much.

The short answer is that currently XORP doesn't support it.
We would like to implement it, but it may take a while until we
design and implement it properly as part of a more general multicast
routing policy mechanism.
As a temporary soultion we could add a PIM-SM configuration switch
per interface that disables the sending and receiving of all PIM
packets, but this switch may go away once we have the multicast
routing policy in place.

Pavlin