[Xorp-users] malformed PIM REGISTER messages?

Eckmann, Steve CTR MDA/IC steve.eckmann.ctr at mda.mil
Wed Aug 9 13:10:52 PDT 2006


>> Fedora Core 4 with 2.6.11-1.1369_FC4 kernel.
>> We got the same result without tunneling: we connected the
>> Linux/XORP router directly to the Cisco router and still see the
>> Cisco router responding with REGISTER_STOP to Linux REGISTER
>> messages (that Ethereal considers malformed). I don't know how to
>> tell whether tcpdump considers a packet malformed; it didn't
>> complain about the REGISTER message in the attached file. Maybe
>> somebody here is willing and able to do a sanity check on it; I
>> depend on Ethereal for that...
>
> I decoded the packet using tcpdump, and here is what it looks like:
>
> pavlin at xorp13[14] tcpdump -r pim-register.tcpdump -vvv -s 0 -x
> 10:10:18.931667 IP (tos 0x0, ttl  64, id 9, offset 0, flags [DF], proto: PIM (103), length: 52, options ( RA (148) len 4 )) 10.6.60.6 > 10.6.30.3: PIMv2, length: 28
>       Register N IP (tos 0x0, id 0, offset 0, flags [none], proto: PIM (103), length: 20) 10.6.60.10 > 239.16.2.2:
>       0x0000:  4600 0034 0009 4000 4067 3741 0a06 3c06
>       0x0010:  0a06 1e03 9404 0000 2100 9eff 4000 0000
>       0x0020:  4500 0014 0000 0000 0067 8361 0a06 3c0a
>       0x0030:  ef10 0202
>
> The interesting thing is that the inner (encapsulated) payload is a
> little bit odd:
>  * It is a PIM packet, while usually it should be UDP.
>  * Its packet's length is just 20 bytes (i.e., it contains only IP
>     header).
>  * That PIM packet was sent to multicast group 239.16.2.2, so
>    it has nothing to do with the PIM protocol.
>  * Its TTL is 0 so even if everything else didn't trigger the
>    REGISTER_STOP by Cisco, it will be dropped anyway by the other
>    side when decapsulated.
>
> Were you trying to test the multicast forwarding using PIM packets?
> FYI, the sender of that packet was 10.6.60.10.
>
> I would recommend to try with UDP packets and see whether the
> behavior will be different. Just don't forget to set the TTL of
> those UDP packets to be large enough, because the default multicast
> TTL is 1 :)

10.6.60.10 is the host that is sending UDP multicast packets to group
239.16.2.2, so that part seems right. When I look at those packets
on the host side of the XORP router I see TTL = 32. It is really weird
that the PIM REGISTER packet I captured on the other side of the XORP
router, which I thought should have one of the UDP packets encapsulated,
apparently encapsulates another PIM packet.

We might have fixed our problem by explicitly configuring the Cisco
router to know that it is the RP. Isn't a PIM-SM router supposed to
infer that it is an RP when it gets a JOIN or REGISTER message for
a group? Anyway, I turned on debugging on the Cisco router and saw that
it was refusing to be the RP when it got REGISTER messages. That
behavior has stopped and the multicast traffic is flowing where it
is supposed to.

Thanks much for your troubleshooting suggestions, Pavlin. I think
the problem turned out to be on the Cisco side, though I'm not sure
that we identified the real problem, and I still don't understand
the PIM traffic we see between the routers.

Regards,
Steve



More information about the Xorp-users mailing list