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

[Dave Price]

Dear Mark,

	Thanks for reply.


M.Handley@cs.ucl.ac.uk said:
> One useful piece of information you could gather is the TTL of the
> dups.

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

whereas, if I get tcpdump to not capture the beacon traffic on 233.3.18.1 then..

LiveCD# tcpdump -vv -i rl3 not host 233.3.18.1
tcpdump: listening on rl3

15:36:53.186014 noc6.koren21.net.50117 > 224.2.172.238.51482: udp 162 (ttl 112, id 18864, len 190)
15:36:53.209351 champion-station.cisco.com.1047 > 224.2.172.238.51482: udp 967 (ttl 96, id 2162, len 995)
15:36:53.221570 mission-peak.cisco.com.1035 > 224.2.172.238.51482: udp 109 (ttl 92, id 49343, len 137)
15:36:53.268883 noc6.koren21.net.50118 > 224.2.172.238.51483: udp 240 (ttl 112, id 18865, len 268)
15:36:53.295489 boboy.cisco.com.1024 > 224.2.172.238.51482: udp 239 (ttl 92, id 48976, len 267)
15:36:53.296774 noc6.koren21.net.50117 > 224.2.172.238.51482: udp 144 (ttl 112, id 18866, len 172)
15:36:53.297967 IPTVserver.ldc.lu.se.1107 > 224.2.172.238.51483: udp 280 (ttl 103, id 61628, len 308)


which all seem to arrive just once.

Any more thoughts??


We are running two beacon listeners within the site, 193.60.11.36
which is "mine", 144.124.19.40 which is osfgi.aber.ac.uk  and then there is
another attached to the local riverstone which is beacon.aber.swman.net.uk 	194.83.179.254

I wonder if by some weird manner, each internal beacon is getting sent a copy
of the multicast beacon traffic, but it gets delivered to both of them?
No, surely not.  To test this weird thought, I've just started
another beacon client on 193.60.11.10, i'm still getting
two of each packet though not more....   Mind you, both 193.60.11.36 and
193.60.11.10 have the ssame router acting as the DR whereas 144.124.19.40 has
another.

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

Any more thoughst folks??

Dave