[Xorp-users] IPv4 PIM-SM and SSM (was Xorp debug messages)
Pavlin Radoslavov
pavlin@icir.org
Thu, 09 Mar 2006 15:17:43 -0800
> I solved my problem regarding the Hello messages. I set up a new
> machine, running Xorp-1.2-RC and a properly configured 2.6.10 kernel.
> Xorp and Click now successfully exchange PIM Hello messages.
Can you elaborate a little bit more on the original problem and the
solution. If I understand correctly, it was not possible to pass the
PIM control messages from Click to XORP (if they were running on the
same machine). However, if you run Click on a separate machine
directly connected to XORP then XORP could receive the PIM control
messages. Is this correct?
> I'd like to built a Source Path Tree now. My testbed look like this:
>
> IGMPv3 Receiver <-> Click router <-> Xorp router <-> Sender
>
> 1. The sender sends a (S,G) stream to the Xorp router
> As a result, "show pim mfc" and "show pim join" return the following lines:
>
> martin@ubuntu> show pim mfc
> Group Source RP
> 232.2.2.2 192.168.40.1 0.0.0.0
> Incoming interface : eth1
> Outgoing interfaces: ..O
> martin@ubuntu> show pim join
> Group Source RP Flags
> 232.2.2.2 192.168.40.1 RP_ADDR_UNKNOWN SG SPT DirectlyConnectedS
> Upstream interface (S): eth1
> Upstream interface (RP): UNKNOWN
> Upstream MRIB next hop (RP): UNKNOWN
> Upstream MRIB next hop (S): UNKNOWN
> Upstream RPF'(S,G): UNKNOWN
> Upstream state: Joined
> Register state: RegisterJoin RegisterCouldRegister
> Join timer: 4
> KAT(S,G) running: true
> Local receiver include WC: ...
> Local receiver include SG: ...
> Local receiver exclude SG: ...
> Joins RP: ...
> Joins WC: ...
> Joins SG: ..O
> Join state: ..O
> Prune state: ...
> Prune pending state: ...
> I am assert winner state: ...
> I am assert loser state: ...
> Assert winner WC: ...
> Assert winner SG: ...
> Assert lost WC: ...
> Assert lost SG: ...
> Assert lost SG_RPT: ...
> Assert tracking SG: O.O
> Could assert WC: ...
> Could assert SG: ..O
> I am DR: O.O
> Immediate olist RP: ...
> Immediate olist WC: ...
> Immediate olist SG: ..O
> Inherited olist SG: ..O
> Inherited olist SG_RPT: ...
> PIM include WC: ...
> PIM include SG: ...
> PIM exclude SG: ...
>
> Is that ok so far?
I guess you have 2+1 PIM-SM related interfaces on your machine:
eth0, eth1 and the special register_vif (generated internally by
XORP). I presume that eth0 is the interface between the Click router
and the XORP router and XORP should receive the PIM-SM (S,G) Join
message on this interface.
By looking into the "Joins SG" state above, the only Join state is
for the third interface (which always is the register_vif), and that
state is set internally without any PIM-SM (S,G) Join messages.
In other words, it seems that the XORP router hasn't received the
expected PIM-SM Join message from the Click router (or at least it
didn't like it for some reason).
> 2. The IGMPv3 receiver sends an "Include" report to the Click router and
> requests an (S,G) stream. The Click routers adds this information to its
> forwarding cache. A PIM join message is generated and sent to the Xorp
> router.
>
> 2.1 I used the PIM neighbors unicast address to sent the PIM join
> message to. This is mentioned in section 4.3.4 and 4.5.3 in
> draft-ietf-pim-sm-v2-new-11.txt.
The IP destination address of the PIM Join message must be
224.0.0.13. The "neighbor unicast adderss" mentioned in the above
sections refer to the "Upstream Neighbor Address (Encoded-Unicast
format)" _inside_ the PIM Join message.
> Xorp complains and asks for a multicast address.
> [ 2006/03/08 16:28:57 WARNING xorp_pimsm4 PIM ] RX PIM_JOIN_PRUNE from
> 192.168.30.6 to 192.168.30.2 on vif eth2: destination must be multicast
This complain is legitimate: the destination address must be 224.0.0.13
> 2.2 Sending the PIM join message to the group address (232.2.2.2 in this
> case) does not work either.
True, another multicast address won't work either.
> Xorp adds an entry to its MFC, the Join/Prune message is not reckognised.
> martin@ubuntu> show pim mfc
> Group Source RP
> 232.2.2.2 192.168.30.6 0.0.0.0
> Incoming interface : eth2
> Outgoing interfaces: ...
This MFC entry won't forward anything because the outgoing interface
set is empty.
> The PIM join message format is (tethereal output):
> -----
> Frame 4 (72 bytes on wire, 72 bytes captured)
> Arrival Time: Mar 8, 2006 16:39:59.819030000
> Time delta from previous packet: 0.009573000 seconds
> Time since reference or first frame: 0.121406000 seconds
> Frame Number: 4
> Packet Length: 72 bytes
> Capture Length: 72 bytes
> Protocols in frame: eth:ip:pim
> Ethernet II, Src: 00:30:48:52:fe:b3, Dst: 00:09:5b:e4:23:7a
> Destination: 00:09:5b:e4:23:7a (192.168.30.2)
> Source: 00:30:48:52:fe:b3 (192.168.30.6)
> Type: IP (0x0800)
> Internet Protocol, Src Addr: 192.168.30.6 (192.168.30.6), Dst Addr:
> 232.2.2.2 (232.2.2.2)
The IP destination address is wrong (see above).
> Version: 4
> Header length: 24 bytes
> Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6;
> ECN: 0x00)
> 1100 00.. = Differentiated Services Codepoint: Class Selector 6
> (0x30)
> .... ..0. = ECN-Capable Transport (ECT): 0
> .... ...0 = ECN-CE: 0
> Total Length: 58
> Identification: 0xf45f (62559)
> Flags: 0x00
> 0... = Reserved bit: Not set
> .0.. = Don't fragment: Not set
> ..0. = More fragments: Not set
> Fragment offset: 0
> Time to live: 1
> Protocol: PIM (0x67)
> Header checksum: 0x6686 (correct)
> Source: 192.168.30.6 (192.168.30.6)
> Destination: 232.2.2.2 (232.2.2.2)
> Options: (4 bytes)
> Router Alert: Every router examines packet
> Protocol Independent Multicast
> Version: 2
> Type: Join/Prune (3)
> Checksum: 0x1c60 (correct)
> PIM parameters
> Upstream-neighbor: 192.168.30.6
The "Upstream-neighbor" should not be the IP address of the
originator of the PIM packet. Instead, it should be the address of
the next-hop router toward the sender (maybe 192.168.30.2 in your
setup?).
> Groups: 1
> Holdtime: 65535 (infty)
> Group 0: 232.2.2.2/32
> Join: 1
> IP address: 192.168.40.1/32 (SW)
> Prune: 0
> -----
>
> 2.3 draft-ietf-pim-sm-v2-new-11.txt mentions 0.0.0.0 as a valid
> destination address, see section 4.5.3. This did not work on Xorp.
Section 4.5.3 says th following:
<QUOTE>
On unnumbered interfaces on point-to-point links, the router's address
should be the same as the source address it chose for the Hello message
it sent over that interface. However on point-to-point links we also
recommend that for backwards compatibility PIM Join/Prune messages with
a destination address of all zeros are also accepted.
</QUOTE>
In other words, the acceptance of zero destination address is
recommended (i.e., it is not mandatory) for backward compatibility
purpose, and only on point-to-point links.
Furthermore, the UNIX IP stack won't deliver to userland listeners
IP packets with zero destination addresses, unless we bypass the
IP stack and use bpf-like snooping to get the packets from the wire.
This would require significant changes to the MFEA implementations,
and such effort can be spent better on other more important tasks.
> 2.4 My last try was to send the Join message to 224.0.0.13, the PIM
> routers' address.
> As a result I get the following line:
> [ 2006/03/08 16:55:17 WARNING xorp_pimsm4 PIM ] RX PIM_JOIN_PRUNE from
> 192.168.30.6 to 224.0.0.13: invalid source/RP flags for (192.168.40.1,
> 232.2.2.2): 0x6
The IP destination address is correct, but some of the flags inside
the packet are incorrect, so this is the real reason the XORP router
doesn't mark an outgoing interface as joined.
The problematic flags are the "|S|W|R|" flags in the Encoded-Source
address format (see Section 4.9.1 in the spec).
In your case "(S,G) Join" the flags should be "1|0|0" (i.e., 0x4).
However, you have "1|1|0". I.e., you have set the S and the W flags,
but this is not a valid combination because the spec says that:
"If the WC bit is 1, the RPT bit MUST be 1".
Keep only the "S" bit value set to 1 and try again.
Pavlin