Cisco bug

[Rick Stevens]

John,

I think you need to understand that we are using these debugging periods
precisely 
for this type of debugging.. and we need to do a lot more.. to insure that the 
"events" look, and sound as good as possible.. for this to happen we need your
help to encourage the right things to happen.  The test cruises are tests
and rehearsals,
just like rehearsing for a play.. and just like play we need to practice
making all the technology
work , networking, video, audio, people, etc. many times between now and
August.. 
There will be many "failures" etc. just like make forgotten lines in a
rehearsal, etc.
we dont need a big to do about each one, what we need is the right people
learning
and trying again..  Your people are doing a great job coming up the
learning curve..
the best way you can help is give them the support they  need $$ or
otherwise and
as a PACS person encourage Frank to see that the ACCESS CENTER in DC come
up to 
the same level of participation as Kentucky.. you guys are leading the PACS
pack
at the moment and I'm very happy to see that..

Best

--Rick

At 11:26 AM 6/23/99 , Robert Olson wrote:
>At 08:14 AM 6/23/99 -0400, John Connolly wrote:
>>One of my local networking experts asked me about the multicast bug
>>in the Cisco router at Argonne that ruined the demonstrations last
>>week. 
>
>Well, it didn't ruin any demonstrations -- it led to some hitches in the
>debugging for the cruise until we put a workaround in place.
>
>> I said I didn't know anything except that Rick Stevens thinks
>>it's software and Mark Hereld thinks it's hardware.  Is there a
>>place you can point us to, to find out more about what the actual
>>problem is?  And is anyone thinking about a work-around in case
>>"beating on Cisco" doesn't fix the problem?
>
>The problem is related to the Cisco Catalyst ethernet switching
>infrastructure we have in place here. My impression is that the basis of
>the problem is that the switch(es) get in a state where multicast traffic
>will be flooded to all ports; and that the emptying of the cgmp (Cisco's
>multicast routing/switching tech, cf
>http://www.cisco.com/warp/public/cc/cisco/mkt/gen/tech/cgmp_wp.htm) table
>is related to this and somehow relates to the drying up of multicast
>traffic during these episodes. 
>
>The manifestation of this that we saw last week was periodic freezing of
>video and cutout of audio.
>
>We worked around this 	by using the Fermi multisession bridge for the
>ANL-local sessions instead of the local multicast. Note that the Fermi
>bridge is what we're using currently to connect the remote sessions until
>wide-area multicast is debugged.
>
>As far as beating on Cisco is concerned, one of our network folks is
>working closely with a Cisco engineer and the two are deep into debugging
>this. This is a problem that has cropped up elsewhere and I hear that they
>may have an answer soon.
>
>--bob