[Xorp-users] (Most) Multicast packets arriving twice

Pavlin Radoslavov pavlin@icir.org
Wed, 28 Jul 2004 18:06:11 -0700


> > Knowing what the TTL of a packet is and the TTL of its duplicate is
> > will provide quite a bit of information about the possible causes
> > because it will let you know what the difference is in the length of
> > the paths the two packets took.
> 
> They both appear the same I think.
> 
> LiveCD# tcpdump -vv -i rl3
> tcpdump: listening on rl3
> 15:32:57.670046 cerb-ag2.bris.ac.uk.2767 > 233.3.18.1.56786: udp 79 (ttl 117, id 52287, len 107)
> 15:32:57.670083 cerb-ag2.bris.ac.uk.2767 > 233.3.18.1.56786: udp 79 (ttl 117, id 52287, len 107)
> 15:32:57.670115 river.oucs.ox.ac.uk.32884 > 233.3.18.1.56786: udp 82 (ttl 116, id 43885, len 110)
> 15:32:57.670132 river.oucs.ox.ac.uk.32884 > 233.3.18.1.56786: udp 82 (ttl 116, id 43885, len 110)
> 15:32:57.671589 osfgi.aber.ac.uk.32833 > 233.3.18.1.56786: udp 63 (DF) (ttl 126, id 0, len 91)
> 15:32:57.672336 194.83.100.74.1094 > 233.3.18.1.56786: udp 64 (ttl 116, id 56144, len 92)
> 15:32:57.672935 194.83.100.74.1094 > 233.3.18.1.56786: udp 64 (ttl 116, id 56144, len 92)
> 
> The one shown only once, is another beacon client running on-site here.
> 
> mynet <-> xorpbox <-> sitecisco <-> otherroutersonsite <-> localriverstone <==twinlinks==> distantriverstone and so on...
> 
> The osfgi beacon hangs off another link on "sitecisco" above
> 
> I guess this tells us that all pairs of packets are arriving by the same
> route as ttl for each pair matches.  That I guess makes it unlikely ( I guess impossible)
> that one is on SPT and one on RPT.

Dave,

Given that you get duplicates for only the multicast beacon group,
and given that you don't get duplicates for the beacon client that
is within your domain, then if I have to guess I would say that the
duplication problem is somewhere upstream.

To verify that, the simplest thing to do (if you have access of
course), is to run tcpdump for only the multicast beacon destination
address on the link between your domain and your provider (i.e.,
between the localriverstone and distantriverstone). In your case,
because you use twinkinks, you may want to run tcpdump on both
links AND on the link between otherroutersonsite and
localriverstone.
In other words, try to run tcpdump as further upstream as possible.

Other things you can try, though I doubt will make much difference
is:
 (a) Stop all beacon clients in your site, and start only a single
 beacon client.
 (b) Instead of starting a beacon client, just use /usr/sbin/mtest
 to join the same multicast group and check whether you still get
 the duplicates (e.g., to rule-out that something funny is going on
 at the application level).

> I also noticed something else odd.  Some of the beacon clients
> send all their UDP packets showing an IP id field of zero in all packets.
> I guess that is o.k. or is it??

Is this consistent for some subset of the beacon clients?
I guess that the multicast beacons are using the standart socket
interface to send the UDP packets, so the IP id field should be set
by the host OS. In other words, it looks like some host OSes are not
behaving properly.

Regards,
Pavlin