July 2000 - Test - lists.nanog.org

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

RE: bw usage?
by Jeremy Brandt 26 Jul '00

26 Jul '00

If you are using Cisco 6500 switches you an use Private VLANS. They do exactly what you want without wasting IP addresses. Jeremy Brandt Infrastructure Architect Scient -----Original Message----- From: David M. Ramsey [mailto:dmr@webserve.net] Sent: Wednesday, July 26, 2000 9:54 AM To: nanog(a)merit.edu Subject: bw usage? Folks, I'm interested in learning which tools other people are using to measure bandwidth usage for co-located client machines on Ethernet switches. 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. 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?). 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? Thanks in advance for any help/hints/pointers/advice you can offer. Regards, --dmr David Ramsey Charlotte, NC

2 1

Re: Sonet protection usage
by Danny McPherson 26 Jul '00

26 Jul '00

> Your experience leasing lines from RBOCs other than BellSouth and > Ameritech must be vastly better? Again, when ADMs and routers are in the same facility the local loop diversity issues are a non-issue. As Sean points out though, intra-facility connections fail, be it a result of human intervention or divine intervention. Also, maintenance affects this as well. > Now, in my experience, when routers _do_ fail, usually soon after > upgrading the software, APS won't help at all. The card is down, too. > IP has to route around the problem. > > Maybe this is some new use of the term "router"? Funny. You're clearly missing the point of the application. Consider the following: +-----+ | A3 | | | +-----+ / \ +-----+ +-----+ | A1 | | A2 | | | | | +-----+ +-----+ \w p/ +---------------+ | ADM-A | | | +---------------+ | | +---------------+ | ADM-B | | | +---------------+ /w p\ +-----+ +-----+ | B1 | | B2 | | | | | +-----+ +-----+ \ / +-----+ | B3 | | | +-----+ You're a provider with two locations (A & B), you own the ADMs (not the transmission facilities) and have only a single connection between the sites, say an OC12c that you lease from an RBOC. Now, you don't have another $100k (monthly) to give to the RBOC for a redundant, presumably diverse secondary OC12 connection, though you would like to be able to load new software on a router or perform maintenance such as hardware upgrades without losing connectivity between the sites. Considering you average ~300 Mbs on the OC12 buying a lower speed connection for redundancy isn't a viable option. So, you buy some ADMs (a capital expense which is likely less than one month of the recurring OC12 fees) and do inter-router APS at the site. Since APS isn't required on both sides (or in the network), you could even do one side at a time. The OC12 connection from the telco may or may not be protected. Under normal conditions the ADMs would transmit frames ingress from the network to both tributary ports (routers) and the inactive routers (A2 & B2, both inactive protect circuits at this point) are responsible for discarding the frames. The ADM would only transmit the ingress signal from the active tributary port to the network. The ADM and routers communicate via the K1 & K2 SONET bytes. Now, you want to do maintenance on B1 so you simply trigger a force switch to the protect circuit from the protect router interface. This in essence forces the ADM to use B2 as the active circuit. B1 is notified via the ADM (K1/K2) and becomes inactive, while B2 frames will be transmitted to the network. This is an overly simplistic model, though I hope the application has been better demonstrated. And again, it becomes even more interesting when the OC12 is trans-oceanic, or its an OC48 and the only viable completely diverse option requires 3 times the circuit route miles (which you pay for) and a few million dollars to provision a diverse fiber path into the facility, etc.. I assure you that it has it's uses and is employed by both network service providers (which in _this definition I refer to as owning the transmission facilities), as well as ISPs. There are lots of higher layer issues such as interaction with the IGP that impact convergence times considerably (e.g. the fact that when B2 becomes active above a new adjacency must be formed with A1, the remote router, or SPF run timers throttling rerun when the new adjacency is reported because of a recent run triggered by the report of the failure itself), but it's still far, far better than doing nothing at all. > Virtually every router I've installed, even "ancient" NetBlazers > and Ascends sitting out at the customer sites, has been stable > for years without interruption. OTOH, links fail often, in ice > storms, in rain, on windy days, even for no known reason at all! As for this, let me let you in on a little secret: There's always a reason the links fail. (Just kidding! ;-). HTH, -danny

1 0

Re: Sonet protection usage
by Danny McPherson 26 Jul '00

26 Jul '00

> Think about it -- are they really provisioning two circuits, leaving > one available as a backup? Of course not! I think you missed on of my points, which was APS on the trib side of the ADM, only a small mention of APS on the network side. If you can't figure out whether you've two circuits sitting there you've got bigger problems... > This may be a useful feature for voice circuits, where most of the > capacity sits idle most of the time. It's worse than useless for data. Again, I think you're missing the application wrt it residing on the trib side of the ADM -- to protect against router failures -- continuing to use the same network portion (i.e. the expensive portion) of the connection. > APS was designed to protect against the failure of the electronics > for a single fiber in a cable. Often, a dozen other circuits are > "protected" by a single APS. It's a ripoff. Perhaps in your experience, though I can argue quite the contrary, especially when your company owns the the transmission facilities. Though again, I was referring primarily to local protection against router failure on the trib side of the ADM. > Of course, the usual failure mode is backhoe fade, not electronics. > In which case, that APS circuit was cut along with the rest. Of course, backhoes don't normally work inside PoPs, which is the application of APS I was referring to. Routers do fail though (often more than links), and APS has been demonstrated to work relatively well for protecting against such failures. > For transoceanic links, diverse APS is even more unlikely, and unless > you are paying serious money, you won't be a priority over the other > hundred customers that are sharing that APS circuit. Not on the trib side, when protecting against router failures. > Diverse links _are_ the only _real_ protection. You might even get > what you pay for.... And in the short term, you at least get twice > the bandwidth Again, APS w/two local links to an ADM sufficiently protect against a local router failure. -danny

3 2

Sonet protection usage
by Steve Feldman 26 Jul '00

26 Jul '00

A quick poll: Are many ISPs taking advantage of SONET APS protection to provide port or router redundancy on short (metro-area) circuits? Or is it more typical to get two circuits and load-share? Or just not bother? Thanks, Steve

2 1