[Xorp-users] malformed PIM REGISTER messages?

[Pavlin Radoslavov]

> >> 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.

Sorry, I take the above back.
This particular packet is the PIM Null Register, which should look
like what you see. After the DR (XORP) receives the PIM Register
Stop from the RP, it will periodically send such PIM Null
Registers.

You would see the normal PIM Registers only on startup before you
receive the PIM Register Stop from the RP (or only if the RP doesn't
respond to the PIM Null Register with PIM Register Stop).

> > 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.

This packet is normal (see my correction above).

> 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.

>From what you say above it seems that everything is in order and now
the multicast traffic is forwarded without any issues.

Sorry about the false alarm for the PIM Register packet.
I should have analyzed it based on what I see rather than based on
what I expected to see :)

Regards,
Pavlin