Subject: IETF retransmission problems

From: "Lucia Gradinariu" <[email-masked]>
Date: Fri, 13 Dec 1996 09:42:27 +0100 (MET)

hi,

for 10 minutes all pakets from video2.mtg.ietf.org have been dropped at
dec3800-2-fddi-0.SanFrancisco.mci.net. (see one of the mstats):

cisco>mstat 205.180.223.4 224.0.1.15
Type escape sequence to abort.
Mtrace from 205.180.223.4 to 193.48.222.1 via group 224.0.1.15
From source (video2.mtg.ietf.org) to destination (cisco-aramis.univ-lyon1.fr)
Waiting to accumulate statistics......
Results after 10 seconds:

  Source        Response Dest   Packet Statistics For    Only For Traffic
205.180.223.4   193.48.222.1    All Multicast Traffic     From 205.180.223.4
     |       __/  rtt 488  ms   Lost/Sent = Pct  Rate     To 224.0.1.15
     v      /     hop 488  ms   ---------------------     --------------------
205.180.223.1   rtr.mtg.ietf.org  
     |     ^      ttl   32   
     v     |      hop -188 ms    0/807 = 0%      80 pps    0/186 = 0%  18 pps
4.0.20.19       sanjose1-mbone1.bbnplanet.net 
     |     ^      ttl   33   
     v     |      hop -5   ms    -1/1230 = 0%      123 pps    0/186 = 0%  18 pps
131.119.0.197   paloalto-mbone1.bbnplanet.net  
     |     ^      ttl   34   
     v     |      hop -204 s    424/1414 = 30%      141 pps    1/186 = 1%  18 pps
204.70.158.61   dec3800-2-fddi-0.SanFrancisco.mci.net 
     |     ^      ttl   64   
     v     |      hop -3   s    1428/1428 = 100%      0 pps    185/185 = 100%  0 pps
137.39.246.98   MBONE2.UU.NET 
     |     ^      ttl   65   
     v     |      hop 191  s    440/443 = 99%      44 pps    0/0 = --%  0 pps
137.39.43.34    MBONE1.UU.NET 
     |     ^      ttl   66   
     v     |      hop -26  s    0/144 = 0%      14 pps    0/0 = --%  0 pps
192.41.177.247  mae-bone.psi.net 
     |     ^      ttl   67   
     v     |      hop -187 s    0/222 = 0%      22 pps    0/0 = --%  0 pps
192.70.92.133   fmroute1-1.exp.edf.fr 
     |     ^      ttl   68   
     v     |      hop -38  s    28/917 = 3%      91 pps    0/0 = --%  0 pps
192.44.54.126   r-jusren.reseau.jussieu.fr 
     |     ^      ttl   69   
     v     |      hop -255 s    0/99 = 0%      9 pps    0/0 = --%  0 pps
193.48.222.1    cisco-aramis.univ-lyon1.fr 
     |      \__   ttl   70   
     v         \  hop 0    ms        0         0 pps           0    0 pps
193.48.222.1    193.48.222.1    
  Receiver      Query Source

after sometime since we were "disconnected" here in Europe, one mstat said 
that  dec3800-2-fddi-0.SanFrancisco.mci.net had pruned our branch (see mstat:)

Mtrace from 205.180.223.4 to 193.48.222.1 via group 224.0.1.15
From source (video2.mtg.ietf.org) to destination (cisco-aramis.univ-lyon1.fr)
Waiting to accumulate statistics....* ..
Results after 10 seconds:

  Source        Response Dest   Packet Statistics For    Only For Traffic
205.180.223.4   193.48.222.1    All Multicast Traffic     From 205.180.223.4
     |       __/  rtt 484  ms   Lost/Sent = Pct  Rate     To 224.0.1.15
     v      /     hop 484  ms   ---------------------     --------------------
205.180.223.1   rtr.mtg.ietf.org  
     |     ^      ttl   32   
     v     |      hop -141 ms    0/795 = 0%      79 pps    0/167 = 0%  16 pps
4.0.20.19       sanjose1-mbone1.bbnplanet.net 
     |     ^      ttl   33   
     v     |      hop -5   ms    0/1161 = 0%      116 pps    0/167 = 0%  16 pps
131.119.0.197   paloalto-mbone1.bbnplanet.net  
     |     ^      ttl   34   
     v     |      hop 189  s    366/1293 = 28%      129 pps    0/167 = 0%  16 pps
204.70.158.61   dec3800-2-fddi-0.SanFrancisco.mci.net Output pruned
     |     ^      ttl   64   
     v     |      hop 127  s    0/437 = 0%      0 pps    167/167 = 100%  0 pps
137.39.246.98   MBONE2.UU.NET 
     |     ^      ttl   65   
     v     |      hop 191  s    502/823 = 61%      82 pps    0/0 = --%  0 pps
137.39.43.34    MBONE1.UU.NET 
     |     ^      ttl   66   
     v     |      hop -26  s    70/486 = 14%      48 pps    0/0 = --%  0 pps
192.41.177.247  mae-bone.psi.net 
     |     ^      ttl   67   
     v     |      hop -187 s    0/486 = 0%      48 pps    0/0 = --%  0 pps
192.70.92.133   fmroute1-1.exp.edf.fr 
     |     ^      ttl   68   
     v     |      hop -38  s    37/1066 = 3%      106 pps    0/0 = --%  0 pps
192.44.54.126   r-jusren.reseau.jussieu.fr 
     |     ^      ttl   69   
     v     |      hop -255 s    -4/211 = --%      21 pps    0/0 = --%  0 pps
193.48.222.1    cisco-aramis.univ-lyon1.fr 
     |      \__   ttl   70   
     v         \  hop 0    ms        0         0 pps           0    0 pps
193.48.222.1    193.48.222.1    
  Receiver      Query Source

What's the explanation of this "prune" ? 

At this moment exactly it happens again but on r-jusren.reseau.jussieu.fr:

mstat 205.180.223.4 224.0.1.15
Type escape sequence to abort.
Mtrace from 205.180.223.4 to 193.48.222.1 via group 224.0.1.15
From source (video2.mtg.ietf.org) to destination (cisco-aramis.univ-lyon1.fr)
Waiting to accumulate statistics......
Results after 10 seconds:

  Source        Response Dest   Packet Statistics For    Only For Traffic
205.180.223.4   193.48.222.1    All Multicast Traffic     From 205.180.223.4
     |       __/  rtt 535  ms   Lost/Sent = Pct  Rate     To 224.0.1.15
     v      /     hop 531  ms   ---------------------     --------------------
205.180.223.1   rtr.mtg.ietf.org  
     |     ^      ttl   32   
     v     |      hop -182 ms    2/746 = 0%      74 pps    1/122 = 1%  12 pps
4.0.20.19       sanjose1-mbone1.bbnplanet.net 
     |     ^      ttl   33   
     v     |      hop -5   ms    0/1123 = 0%      112 pps    0/121 = 0%  12 pps
131.119.0.197   paloalto-mbone1.bbnplanet.net  
     |     ^      ttl   34   
     v     |      hop 201  s    379/1247 = 30%      124 pps    0/121 = 0%  12 pps
204.70.158.61   dec3800-2-fddi-0.SanFrancisco.mci.net 
     |     ^      ttl   64   
     v     |      hop 114  s    0/1306 = 0%      0 pps    0/121 = 0%  0 pps
137.39.246.98   MBONE2.UU.NET 
     |     ^      ttl   65   
     v     |      hop 191  s    539/1706 = 32%      170 pps    2/121 = 2%  12 pps
137.39.43.34    MBONE1.UU.NET 
     |     ^      ttl   66   
     v     |      hop -26  s    0/1255 = 0%      125 pps    0/119 = 0%  11 pps
192.41.177.247  mae-bone.psi.net 
     |     ^      ttl   67   
     v     |      hop -187 s    75/1333 = 6%      133 pps    6/119 = 5%  11 pps
192.70.92.133   fmroute1-1.exp.edf.fr 
     |     ^      ttl   68   
     v     |      hop -38  s    67/1914 = 4%      191 pps    2/113 = 2%  11 pps
192.44.54.126   r-jusren.reseau.jussieu.fr Output pruned
     |     ^      ttl   69   
     v     |      hop -255 s    0/172 = 0%      17 pps    111/111 = 100%  11 pps
193.48.222.1    cisco-aramis.univ-lyon1.fr 
     |      \__   ttl   70   
     v         \  hop 3    ms        0         0 pps           0    0 pps
193.48.222.1    193.48.222.1    
  Receiver      Query Source

it lasted for 2-3 minutes

thanks for any opinion,

--------------------------------------------------------------------------------
Lucia GRADINARIU, Eng.
CISM-Univ. Cl. Bernard Lyon1			voice:(33).72.43.13.69
Bat. 101 Bd. du 11 Novembre 1918		fax:(33).72.44.84.10
69622 Villeurbanne FRANCE			email:[email-masked]
		http://www.univ-lyon1.fr/CISM/lucia
---------------------------------------------------------------------------------

---

From: Bill Fenner <[email-masked]>
Date: Fri, 13 Dec 1996 08:09:06 PST

>137.39.246.98   MBONE2.UU.NET 

The problem with mtrace is that you can't tell which hop lost the
packets.  It could have been either MCI or UUNET.  There have been
various IOS bugs where it would install incorrect state and not
notice that packets were actually flowing; perhaps that's what
happened here.

The fact that mbone2.uu.net reported that 0 packets came in on the
tunnel (e.g. the 100% loss in the left hand column) implies that
there's something funny going on there.  This may just be a statistics
reporting bug, however.

>137.39.246.98   MBONE2.UU.NET 

In DVMRP, prunes always occur at the request of the downstream
neighbor, so mbone2.uu.net is the guy that sent the prune.  There's
another IOS bug which appears to send prunes and then forget them,
which I'm not sure if we ever tracked down well enough for Cisco to
find it or not.

>193.48.222.1    cisco-aramis.univ-lyon1.fr 

Same explanation; cisco-aramis sent r-jusren a prune and then forgot
that it did so.

>it lasted for 2-3 minutes

Which, I believe, is the default lifetime of the prune messages that
IOS sends.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Fri, 13 Dec 1996 08:24:04 PST

Apologies for a second message, I just thought of another potential

>137.39.246.98   MBONE2.UU.NET 

Given that mbone2.uu.net is reporting 100% loss on the tunnel, it's also
possible that this was a unicast routing flap that caused the tunnel to
go one-way for some amount of time.

  Bill

---

From: "Lucia Gradinariu" <[email-masked]>
Date: Sat, 14 Dec 1996 00:16:25 +0100 (MET)

thanks Bill for explanation

> Same explanation; cisco-aramis sent r-jusren a prune and then forgot

to precise the environment: between cisco-aramis and r-jusren we have a GRE/IP tunnel

as for these Output prune messages they appear some minutes after a 100% loss is reported
at a node (even though the prune message is sent by the next-down node), i cann't really see
the relationship but there must be one (yesterday i saw the same problem , in the same order,
on the top of the french mbone so either mstat isn't reliable or there is an  IOS bug). 

a +,

lucia

---

From: "Lucia Gradinariu" <[email-masked]>
Date: Sat, 14 Dec 1996 00:16:25 +0100 (MET)

a +,

lucia