how to recover from vBNS outage this afternoon
tony at ncsa.uiuc.edu
Mon Aug 23 14:14:06 CDT 1999
In general, when we are actively working a problem, I would prefer that you
leave the native stuff up. If the traffic disapears, it makes it hard to
fix the problem at all.
In terms of time and impact, dialogue on the moo is probably the best way to
figure out which way to go. if the audience impact is huge and it seems we
should go that way and fix the routing problems later, speak up. more than
likely, I will defer to your opinion about that kind of prioritization
unless significant progress is being made and a fix seems forthcomming.
The main issue is that each multicast failure is a little unique and each
site has its own issues, all of which combine to make it hard to pin down an
answer to your question.
Tom Coffin <tcoffin at ncsa.uiuc.edu> writes:
> To handle this from a presentation perspective, I moved from
> the multicast to the bridge. I would have liked to have done this
> quicker. Is there a way we can determine for future events
> when I can make the jump? Had we had a larger audience the impact
> would have been greater as far as being down is concerned.
> At 01:44 PM 8/23/99 -0500, Bill Nickless wrote:
> >ACCESS-DC and ANL have recovered from the vBNS multicast outage.
> >To do so we
> > - Verified that the M-BGP route for the other sites was coming from
> > AS 145 (vBNS)
> > - clear ip mroute 126.96.36.199
> > - clear ip msdp peer <vBNS msdp peer>
> >Once these were done the traffic started flowing again.
> >Please use http://www-unix.mcs.anl.gov/~olson/rtpmon-beacon/ for
> >verification of traffic flow.
> >Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252
> >PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7
> nickless at mcs.anl.gov
> Tom Coffin .......................... tcoffin at ncsa.uiuc.edu
More information about the ag-tech