- NANOG - lists.nanog.org

Multiple incidents (NYC, Illinois, N.California)
by Sean Donelan 26 Jul '00

26 Jul '00

There is a fiber cut in central illinois. Uunet has equipment problems in New York City. And there seems to be something down between San Jose and San Francisco (parts of Yahoo dailynews.yahoo.com and some frame-relay service are down).

1 0

71% of the outages were within the carrier's control
by Sean Donelan 26 Jul '00

26 Jul '00

Several people asked me for a citation for my report that 71% of the outages were within the carrier's control. See ftp://ftp.atis.org/pub/nrsc/2mins2q2000.pdf item #74. You can also see the corresponding debate over what "control" meant.

2 1

replacement for Patton 2715 (G.703->V.35) ?
by Jim Mercer 26 Jul '00

26 Jul '00

i'm in north america, so i don't have much experience to draw on for E1 gear. i've got a circuit running using a Patton 2715 to convert the G.703 E1 into a full 2mbit V.35 which is connected to a cisco HD60 connector. i recommended this to a new client, but they are saying they can't get the Patton unit. can i get a short list of recommended E1 -> V.35 converters? -- [ Jim Mercer jim(a)reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]

1 0

Re: 71% of the outages were within the carrier's control
by Sean Donelan 26 Jul '00

26 Jul '00

On Wed, 26 July 2000, "Chris" wrote: > Is it just me or does the report you sight say. in his opinion, 71% of > outages where in the carrier's control. I think you kinda left that word > opinion out of your statement. In my opinion, the earth is round.

1 0

Re: Internet FUD Abound
by Danny McPherson 26 Jul '00

26 Jul '00

Agreed. For example, effecting availability of a few root nameservers alone would have an _interesting effect. No need to even attack the servers themselves, simply advertise more specifics of their address space (or the like). Just another subtle reminder that prefix-filtering (@ access and inter-provider -- at least well-known address space) could have a significant impact -- if/when this does occur. -danny > The Reuters article skips over some of the important qualifiers > in the Nature letter. Read the entire letter on the Nature > website. http://www.nature.com/ > > The conclusions are interesting, but I think missing a few pieces > of data. Every major public NAP has had service affecting incidents, > and so far we have not seen the partioning effect Albert et al write > about. I've also followed a fair number problems in the private > connections, also without major network partion beyond those networks. > Further, the source data from NLANR doesn't pick up every possible > connection between networks. You should view source data as a floor(), > not a ceil(), on the connectivity. And finally, coordinating a physical > attack on more than a few physical locations is hard, even with perfect > information. > > Of course, this is a false argument because it has never happened doesn't > mean it can never happen. But I think its important to understand why > such an attack is hard, as well as understanding why it is possible. > > On the other hand, there have been accidents (and perhaps some attacks) > on the logical layer which have severely disrupted the Internet. The > interesting thing about logical attacks is you don't need perfect information > about the network because the critical points of the network almost act as > natural gravity wells pulling the attack towards them (using a physical > analogy in cyberspace). > > >

1 0

RE: Netflow Type 7 (was RE: bw usage?)
by rdobbins＠netmore.net 26 Jul '00

26 Jul '00

I'm not confusing anything with anything, thanks - I want V7 directly from my MPLS-enabled Catalysts in my core. I'm very grateful for your advice, however. ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice -----Original Message----- From: Hendrik Visage [mailto:hvisage@is.co.za] Sent: Wednesday, July 26, 2000 1:00 PM To: Dana Hudes Cc: rdobbins(a)netmore.net; nanog(a)merit.edu Subject: Re: Netflow Type 7 (was RE: bw usage?) Importance: High Roland, you are confusing V8 (Aggregation) with V7 (Switches Cat5500+RSM or Cat ^500) in any case: http://www.caida.org for cflowd. Check the mailing list for other references etc. but do check the rrdtool for frontends for NetFlow data collected via Cflowd Greetz Hendrik On Wed, Jul 26, 2000 at 12:26:52PM -0400, Dana Hudes wrote: > > Usually you don't want type 7, you want type 5. Let cflowd et al have the full data. Type 7 the router has done aggregation for you. Good for reducing > overall data rate to the flow capture system but bad for seeing what's going on in your network. > > ----- Original Message ----- > From: <rdobbins(a)netmore.net> > To: <nanog(a)merit.edu> > Sent: Wednesday, July 26, 2000 12:11 PM > Subject: Netflow Type 7 (was RE: bw usage?) > > > > > > > > Does anyone know of a tool like Cflowd which will capture Netflow Type 7 > > stats? The only one I know of is the commercial product from Cisco; any > > advice would be greatly appreciated. > > > > ----------------------------------------------------------- > > Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice > > > > > > -----Original Message----- > > From: Alex [mailto:alex@nac.net] > > Sent: Wednesday, July 26, 2000 8:23 AM > > To: David M. Ramsey > > Cc: nanog(a)merit.edu > > Subject: Re: bw usage? > > > > > > > > > > > > > > On Wed, 26 Jul 2000, David M. Ramsey wrote: > > > > > For now I've cobbled together some crude software to regularly > > > read SNMP port byte in/out counters from our switches, stashing > > > the deltas in a DB for later reporting/analysis. > > > > We do about the same thing, but we store absolute byte counts, relative > > byte counts from the last measurement, and figure the kb/s; we also store > > AdminStatus and OperStatus for SLA purposes. > > > > > > > I'm concerned that the data is misleading, though, in that it will > > > include LAN broadcast traffic. Also, customers end up paying > > > for other bandwidth that they did not want or induce, like network > > > scans, etc. (tough luck?). > > > > Exactly, tough. If they use the bandwidth, then they should pay for the > > bandwidth. > > > > > > > We've considered implementing unique customer VLANS to separate > > > customer broadcast domains, but it seems like that'd be a pain, > > > would eat up IP addresses, and possibly tax our routers with all of > > > the ISL/VLAN stuff? > > > > We do that; it's unwise to have everyone on the same VLAN, as some others > > have demonstrated. > > > > >

1 0

Re: Sonet protection usage
by smd＠clock.org 26 Jul '00

26 Jul '00

Bill Simpson writes on the "expertise list": | APS is specified to switch a failing circuit over to a backup within 50 | milliseconds. No. APS/MSP is a simple protocl that uses the K1/K2 MSOH bytes *between* SDH section terminating devices to determine which of several parallel paths is active and should be used as the working TxInterface->RxInterface pair. In bidirectional line-switched restoration, either end may force a switch between working and protect; in unidirectional LSR, the receiver tracks the sender. In either mode, the switch can be as quick as the propagation delay of the section overhead with the new K1/K2 byte values. Alternatively, if there is a cut on the working path, there will be a time threshold at which the receiver will start listening to a non-working path. This is typically 50ms, but one has to add the one-way delay to that. If the sender knows there is an incipient failure on the working path, it can force a switch to a protect path using the K1/K2 protocol. Otherwise, we have a timeout, and how quickly the sender realizes that the working path is malfunctioning depends on whether the signalling is bidirectional or not, although that's often not very important. The Cisco implementation splits the working and protect interfaces across multiple boxes; there is an out-of-band (IP-based) router-to-router protocol that synchronizes the K1/K2 protocol state. The routers can force a switch at the next-hop multiplex section terminator (usually an ADM) if they desire, and a clean shutdown is supposed to force such a switch rather than deal with timeouts. Meanwhile, an SDH trail (an end-to-end circuit) can be composed of concatenated BLSR structures, where only a pair of adjacent multiplex terminators will be aware of a protection switch. It is not an end-to-end protocol as specified (although there is Cisco's "dumb-mode" which deals with broken implementations). There is no requirement that every section of a trail use BLSR or any kind of restoration whatsoever. In many cases, the only BLSR-protected portions are between a pair of Ciscos and an adjacent ADM, at either end of the trail. Other people have noted reasons why one might choose to do this. | It assumes that failure is in a multiplexor. It assumes | that most of the circuits will be statistically idle. It assumes that | the individual T3 (OC-1) paths are burstable, and can be recombined at | the path or section layer. It assumes that 50 milliseconds is short | relative to switching time. In short, it assumes voice. Data doesn't | look like that at all! Well data doesn't look like voice, it's true, but in all other respects this paragraph is wrong. All that APS/MSP does is make it easier to manage which of several supposedly-redundant signals an SDH section terminator hears is the working one. 50ms seems like a reasonable timeout value for section terminators to try to make sense of different signals heard from upstream. If it is sensible to use another value, there is no obvious reason why not to. | If the failure is actually due to the usual circumstances, a lot of | data "circuits" fail all at once. There is no chance that they will all | be backed up. What is protected in BLSR is the highest-order multiplex container. This is usually an STM-16 or OC48 (or STM-64 or OC192 )header. | APS (as sold) is a fraud on the uninformed. Those who live in glass houses should not confuse APS with restoration topology layout. Sean.

2 1

RE: Wanted: Clueful Individual @ TeleGlobe.net
by Hal Murray 26 Jul '00

26 Jul '00

> Out of curiousity, how does the telco world handle this? When some one > signs up for MCI longdistance, I assume that on some calls they will cross > off the MCI network (and potentially though several others) that will be > piled mile high in static. The customers will complain about their I have one case to report. If it's typical, then the telco world tracks all the grumbling/finger-pointing I've seen here. I was trying to call 800-xxx-xxxx. It didn't work. I forget the details, but it was roughly: PacBell (my local carrier) said it wasn't their problem. AT&T (my long distance carrier) said it wasn't their problem, but they told me which carrier owned that number. Of course, they couldn't fix it - their end worked OK. Some operator tried it and said "works for me". I'm pretty sure some local switch had a bad entry in the routing table for that number. I talked to one semi-clued person, perhaps because I called during lunch. They couldn't get it fixed right away, but at least sounded like they would look into it. Fortunately, I wasn't in a hurry. It was working in a day or two when I tried again. Sound familiar? I considered calling the PUC to see how things like that should get handled but didn't get around to it.

8 8

Re: Sonet protection usage
by Sean Donelan 26 Jul '00

26 Jul '00

On Wed, 26 July 2000, Steve Meuse wrote: > At 07:10 AM 07/26/2000 -0400, William Allen Simpson wrote: > >My opinion (based on a fair number of years of experience) is that any > >ISP foolish enough to have bought APS should also ask proof that no > >other circuit is provisioned for the same APS. Once you've done that, > >a class action might be in order.... > > This isn't an issue, when you own the transmission gear (like many NSPs do). This *is* an issue even when you own the transmission gear. Diversity doesn't happen by magic. You must do the hard work and then audit the work. Unfortunately the carrier outage reports are full of circuit provisioning errors on the carriers *internal* circuits which later resulted in a loss of service due to a lack of recovery path. Owning your transmission doesn't mean its configured correctly nor does it make you infallible. Large NSPs have the problem of being large, and they don't always know what all the different parts of the same company is doing. It may seem like redudent work to audit what your own transmission people did. But if the transmission group can't provide paying customers with the diversity they ordered, what makes you think they provide any better service to an internal, usually funny-money, circuit. Whether you are ordering circuits from a different carrier or from your internal transmission group, if you haven't done an audit, you really don't know what you have.

1 0

Netflow Type 7 (was RE: bw usage?)
by rdobbins＠netmore.net 26 Jul '00

26 Jul '00

Does anyone know of a tool like Cflowd which will capture Netflow Type 7 stats? The only one I know of is the commercial product from Cisco; any advice would be greatly appreciated. ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice -----Original Message----- From: Alex [mailto:alex@nac.net] Sent: Wednesday, July 26, 2000 8:23 AM To: David M. Ramsey Cc: nanog(a)merit.edu Subject: Re: bw usage? On Wed, 26 Jul 2000, David M. Ramsey wrote: > For now I've cobbled together some crude software to regularly > read SNMP port byte in/out counters from our switches, stashing > the deltas in a DB for later reporting/analysis. We do about the same thing, but we store absolute byte counts, relative byte counts from the last measurement, and figure the kb/s; we also store AdminStatus and OperStatus for SLA purposes. > I'm concerned that the data is misleading, though, in that it will > include LAN broadcast traffic. Also, customers end up paying > for other bandwidth that they did not want or induce, like network > scans, etc. (tough luck?). Exactly, tough. If they use the bandwidth, then they should pay for the bandwidth. > We've considered implementing unique customer VLANS to separate > customer broadcast domains, but it seems like that'd be a pain, > would eat up IP addresses, and possibly tax our routers with all of > the ISL/VLAN stuff? We do that; it's unwise to have everyone on the same VLAN, as some others have demonstrated.

2 1