We are not seeing any video or audio from the NANOG meeting session. Is there some sort of problem with the transmission? Scott -- smace@neosoft.com - KC5NUA - Scott Mace - Network Engineer - Neosoft Inc. Any opinions expressed are mine.
There we some problems early on (between 9:00am and 9:30am EST) due to some high packet loss on an upstream router (around 55%). After a reboot, the problem went away. You should be getting video and audio without a problem now. There are currently about 30 active VIC members and about 40 VAT users. We also have the WB going with schedule info. Actually, I am seeing your entry on VAT list as having been active at some time today. --curtis According to Scott Mace:
We are not seeing any video or audio from the NANOG meeting session. Is there some sort of problem with the transmission?
Scott -- smace@neosoft.com - KC5NUA - Scott Mace - Network Engineer - Neosoft Inc. Any opinions expressed are mine.
-- Curtis Generous generous@uucom.com Phone: (703) 461-1350 UUcom Inc., Suite 250, 4875 Eisenhower Avenue, Alexandria, VA 22304-0797
Other than a 5 minute outage due to a Cisco bug and a 65-second outage while routing settled down after a topology change, I've been receiving the NANOG transmission consistently since 1300 EST when I tuned in. Bill
We are not seeing any video or audio from the NANOG meeting session. Is there some sort of problem with the transmission?
I don't know if this is a widespread problem or not, but we seem to have lost all DVMRP routes. Dreck - this happened at the exact moment that they returned from lunch, right after I had finally gotten something in place to record the remainder of the session. mb
The upstream tunnel sent a prune about 30 minutes ago. Things should have timed out by now. --curtis According to Mark Boolootian:
We are not seeing any video or audio from the NANOG meeting session. Is there some sort of problem with the transmission?
I don't know if this is a widespread problem or not, but we seem to have lost all DVMRP routes. Dreck - this happened at the exact moment that they returned from lunch, right after I had finally gotten something in place to record the remainder of the session.
mb
In message <199605301746.KAA22926@krazy.UCSC.EDU> you write:
I don't know if this is a widespread problem or not, but we seem to have lost all DVMRP routes.
I don't think it's widespread; U-SURE-R-NOSEY.UCSC.EDU's tunnel to mbone.berkeley.edu is up but is not advertising proper routes for nets internal to ucsc.edu, and U-SURE-R-NOSEY has a buggy multicast traceroute implementation so I can't help debug this. This symptom points to U-SURE-R-NOSEY's unicast routing table not agreeing with the tunnel endpoint and is fixed in a later IOS release. (Oh, and while you're complaining to your vendor, comm-g.UCSC.EDU's multicast traceroute implementation is buggy as well, a bug that I have seen more and more and haven't been able to get a good explanation for.) Bill % mtrace -g 128.114.1.252 128.164.192.15 krazy.ucsc.edu 224.2.234.159 Mtrace from 128.164.192.15 to 128.114.129.44 via group 224.2.234.159 Querying full reverse path... 0 krazy.UCSC.EDU (128.114.129.44) -1 comm-g.UCSC.EDU (128.114.1.252) PIM thresh^ 16 -2 U-SURE-R-NOSEY.UCSC.EDU (128.114.1.250) DVMRP thresh^ 16 -3 mbone.berkeley.edu (198.128.16.22) DVMRP thresh^ 0 Wrong interface [default] Round trip time 98 ms % mtrace -g 128.114.1.252 crevenia.parc.xerox.com krazy.ucsc.edu Mtrace from 13.2.116.11 to 128.114.129.44 via group 224.2.0.1 Querying full reverse path... 0 krazy.UCSC.EDU (128.114.129.44) -1 comm-g.UCSC.EDU (128.114.1.252) PIM thresh^ 16 Prune sent upstream [default] Round trip time 84 ms
I don't know if this is a widespread problem or not, but we seem to have lost all DVMRP routes.
I don't think it's widespread;
It wasn't. The router feeding us has a built-in throttle to stop multicast routing if the number of DVMRP routes gets too large. The threshold was set at 3500 and was crossed, subsequently all our routes disappeared. The threshold's been pushed up a bit.
U-SURE-R-NOSEY.UCSC.EDU's tunnel to mbone.berkeley.edu is up but is not advertising proper routes for nets internal to ucsc.edu, and U-SURE-R-NOSEY has a buggy multicast traceroute implementation so I can't help debug this. This symptom points to U-SURE-R-NOSEY's unicast routing table not agreeing with the tunnel endpoint and is fixed in a later IOS release.
(Oh, and while you're complaining to your vendor, comm-g.UCSC.EDU's multicast traceroute implementation is buggy as well, a bug that I have seen more and more and haven't been able to get a good explanation for.)
nosey is running 11.0.5 and comm-g is running 11.0.7. I'll drop a line to cisco. Thanks for the response. regards, mb f with sneakers, T-shirt and baseballcap
worn backwards :)
bye,Kai
Sean wasn't wearing the baseball cap backwards last time I saw him at NANOG, but otherwise, you just described his attire. Owen --- End of forwarded message from owen@DeLong.SJ.CA.US (Owen DeLong)
In message <199605301545.KAA15633@crash.ops.neosoft.com> you write:
We are not seeing any video or audio from the NANOG meeting session. Is there some sort of problem with the transmission?
According to mtrace, MBONE.SESQUI.NET is dropping all the packets that NANOG is sending. This is presumably some bug in Cisco's DVMRP implementation. Bill Source Response Dest Packet Statistics For Only For Traffic 128.164.192.15 204.162.228.2 All Multicast Traffic From 128.164.192.15 v __/ rtt 209 ms Lost/Sent = Pct Rate To 224.2.234.159 128.164.192.15 ? v ^ ttl 32 14/666 = 2% 66 pps 14/665 = 2% 66 pps 128.167.252.196 cpk-mc1.sura.net v ^ ttl 33 200/1577 = 13% 157 pps -1/651 = 0% 65 pps 137.39.43.34 MBONE1.UU.NET v ^ ttl 66 -7/1313 = 0% 131 pps -4/652 = 0% 65 pps 192.41.177.247 mae-bone.psi.net v ^ ttl 67 148/1584 = 9% 158 pps 656/656 =100% 65 pps 128.241.254.1 MBONE.SESQUI.NET v ^ ttl 67 3/5 = --% 0 pps 0/0 = --% 0 pps 204.70.114.29 204.70.114.45 dec3800-1-fddi-1.Dallas.mci.net v ^ ttl 69 0/142 = 0% 14 pps 0/0 = --% 0 pps 206.109.1.253 core1-e0.hou.neo.net Output pruned v ^ ttl 69 0/4 = --% 0 pps 0/0 = --% 0 pps 206.109.4.50 crash.ops.NeoSoft.COM Prune sent upstream v \__ ttl 69 0 0 pps 0 0 pps 206.109.4.50 204.162.228.2 Receiver Query Source
participants (4)
-
Bill Fenner -
booloo＠cats.ucsc.edu -
Curtis Generous -
Scott Mace