- Test - lists.nanog.org

re: POWER: San Mateo/San Francisco power outage report
by CONWAY＠pjm.com 09 Dec '98

09 Dec '98

This didn't make it to the list the first time. Doh! > -----Original Message----- > From: jzeeff(a)verio.net [SMTP:jzeeff@verio.net] > Sent: Wednesday, December 09, 1998 9:04 AM > To: SEAN(a)SDG.DRA.COM > Cc: nanog(a)merit.edu > Subject: Re: POWER: San Mateo/San Francisco power outage report > > > > breakers on the substation. It also caused a cascade effect, tripping > > the Hunters Point and Potrero power plants. > > > grid primary power sources. Aside from the human error, the system worked > > "as designed to protect the rest of the grid." > > I suggest that causing a cascade effect and increasing the area of an > outage isn't a good way to design a system. > > > If you're interested in finding our more about how the power grid is operated, > my company has a lot of operational info documented on the web. It's scope > is the operation of the interconnected grid in the mid-Atlantic region of the > US (PA-NJ-DE-MD-DC-VA). The concepts and procedures documented there are > probably very similar to the ones used on the west coast (YMMV, I'm a > networking tech not a power systems engineer). > > All of our Operations Manuals are available at: http://pubs.pjm.com > > Of specific interest might be: Emergency Operations > http://pubs.pjm.com:80/dynaweb/PJMpubs/m13/@Generic__BookView and > Transmission Operations > http://pubs.pjm.com:80/dynaweb/PJMpubs/m03/@Generic__BookView > > > Chuck Conway > Network Management > PJM Interconnection, LLC > conway(a)pjm.com

1 0

Ascend Router Question Re: IP Classless
by Andrea Di Lecce 09 Dec '98

09 Dec '98

All, Apologies for the seemingly rudimentary question. A select number of customers on Rogers cannot access a certain site, and I have reason to believe that it is due to the lack of an IP Classless statement in a downstream router. The Ascend router that the problem is originating from is owned by another network and is not under my influence. My question is, do the Ascend routers support IP Classless ? If so, what is the command to enable it on the p75 and p50 devices ? Please respond in private :) Thanks, Andrea. ************************************************** Andrea Di Lecce (416) 935-6485 Rogers@Home Network Operations 1 Mount Pleasant Road, Toronto, M4Y 2Y5 **************************************************

1 0

Re: Lawsuit threat against RBL users
by Andrew Staples 09 Dec '98

09 Dec '98

Dean wrote: >But claiming that you can "do anything you please with your equipment" is >complete BS. There isn't anything more I can say. I really hope you mean that. Of course, cant' != won't Andrew

3 2

Prioritization...
by Rich Sena 08 Dec '98

08 Dec '98

Got a question - been trying to track some loss I've seen in our traffic - and one of the things that came to mind was packet priority and a lower priority being set for UDP at some exchanges - especially congested ones. Anyone here doing such - snd if so does anyone have anysort of data re: how much of that traffic is being dropped... -- I am nothing if not net-Q! - ras(a)poppa.clubrich.tiac.net

2 2

Re: More Sidgemore on per-bit pricing (fwd)
by Paul Vixie 08 Dec '98

08 Dec '98

> > One could use something like MPLS to determine the Ingress and Egress > > points of the network if it had a robust enough MIB. > > Goodbye scalability. > > Please tell me what happens when a link carrying a million MPLS-ed > flows does flap. I can't. But scalability isn't important in the modern era. MPLS and to some extent QOS are all intranet standards, and if they are ever applied to the true universal Internet in an end to end way we'll see a pretty much vertical rise in the complexity of things like BGP and record-route and traceroute. No matter how bad an idea it seems like, the fact remains that to push public data networking to the next level of functionality, vendors and pundits and especially venture capitalists are deliberately waffling on the definition and extent of the word "public." Stateful internets are bad. Stateful intranets aren't so bad. The last voice-over-IP story I heard was just a way to increase cost efficiency in the last mile -- it wasn't an end-to-end thing. The one before that was just to increase cost efficiency in a long distance carrier -- it wasn't an end-to-end thing. Vendors of both equipment and services are thinking of new technology in terms of what it can do for large VPN-consumers or for networks which mostly just move data for their own direct customers. And of course, most of the so-called first tier expects there to just be one network in the endgame, with all others as customers of it. The people who, six years ago, yelled about NAT, and ten years ago, yelled about firewalls, all because "internet" means "network of networks" and anything which couldn't scale to universal end-to-enditude shouldn't be used (and certainly not standardized!) probably had the unspoken worry that we were headed for a "network of VPNs" or a "network of NAT clouds" or a "network of its own customers". I had to think my way through all of this in order to understand the last batch of Internet industry investment analysis briefs I slogged through. Nobody, anywhere, expects to see a million MPLS'd flows going over a single link before 2004, and by that time, the problems will be very different from today's. -- Paul Vixie <paul(a)vix.com>

2 1

Many Thanks!
by Thom Youngblood 08 Dec '98

08 Dec '98

Turns out to be IPinIP packets coming from 10.2.2.21. (Spoofed, of course.) The NOC of the network sending 20mb per second of these is hearing from us now. Thanks for all the help.

1 0

Re: More Sidgemore on per-bit pricing (fwd)
by Vadim Antonov 08 Dec '98

08 Dec '98

Eric Dean wrote: > > > Please tell me what happens when a link carrying a million MPLS-ed > > flows does flap. > > The same thing that happens in an SVC environment. Routing reconverges > and the pain is felt by all. Yep, and how much time does it take? (A: with simplistic oblivious VC routing which was shown to produce absymally bad utilization in general topologies it'll take O(N), optimal VC routing is NP-complete (i.e. at least O(exp(N)); there's a number of heuristics working in polinomial time). N here stands for number of end-points in the network. For comparison, rerouting in per-hop routing network takes O(log N). Yeah, MPLS may work in private networks; but assuming it'll be of any use in public Internet backbones is a serious delusion. The only way to make it work is to avoid dynamic rerouting by building a double-redundant full mesh-like network (by mapping PVCs in SONET, for example). That is exactly what telephone companies are doing for voice SVCs. Unfortunately it also wastes at least 70% of useable bandwidth. In other words, use SVCs of any kind - and if you want to build a large reliable network, you're up to sacrificing most of your network's capacity. _Not_ doing SVCs provides enough "spare" capacity to provide much better quality of service to all customers. (There's one mode of usage in MPLS, downstream demand tag allocation, which is equivalent to destination-only forwarding; all it is doing is eliminating IP address lookup. Which can easily be done in 1.5 memory reads on average; so the "savings" here are not worth the additional complexity (and related bugs) of a MPLS code. Another usage of MPLS in large networks is to create arcane routing policies (for example, to circumvent "routing fish"), but, frankly, i never had any problem of that kind which couldn't be fixed with a length of wire and a crimp tool.) MPLS shares one common property with ATM: it introduces a lot of complexity which can be gainfully used only in places where traffic is not very large. The complexity _always_ has a way of biting back, so the net result is networks which are less manageable, software which has more bugs, interesting failure modes and guaranteed employment for network consultants. Which is all what that MPLS hype is about. This one will come to pass, too. I guess many folks fogrot the Magic Rule Of Reliable Networking: Keep It Simple, Stupid. --vadim

1 0

Re: ARIN co-located nameserver problem
by prue＠ISI.EDU 08 Dec '98

08 Dec '98

>...Presumably in this case, you are responsible for that nameserver >and therefore the /32 should be SWIP'd to you. I do not see this as a valid assumption. It may well be that you don't want to be bothered with DNS maintenance or you don't trust your own network engineers to do DNS right and that you want to pay, say Paul Vixie, to do your DNS for you. His name and the quality of his DNS knowledge will add credulity to your network service. This works out so well, that Paul decides to sell this as a service to many small/medium size ISP's, running it on a single server. Now one /32 is the name server for multiple networks. So the registration system must be able to deal with that. This is not an unreasonable scenario. Walt Prue

2 1

Re: MAE-West et al.
by howland＠Priss.com 08 Dec '98

08 Dec '98

...or that the MAE has two seperate physical installations, one at NASA Ames, also with full power backup... --------------- > > Any word if the major power problems near San Fransisco are affecting > > MAE-West or any carriers in that area? > > The MAE West facilities are 20 miles or so south of the affected > areas (SF, San Mateo County) so no problems here. Not to mention that there are 4 emergency generators in the building. ---------------

1 0

Re: comments please
by Bill Manning 08 Dec '98

08 Dec '98

> > On Tue, 8 Dec 1998, Bill Manning wrote: > > > 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 are the prefixes called out > > in RFC 1918. They are only for use in private networks that wish to use > > the IP protocols. Network operations and End System administrators should > > ensure that these prefixes is not coded into systems or routed through any > > Internet infrastructure. Since they have the appearance of "normal" prefixes, > > special precautions should be taken to ensure that they are not propagated > > in the Internet. > > What about instances where an I/NSPs extends its use of these addresses to > the customer's boundary router? This becomes epseically important if the > customer happens to have been doing its homework and using RFC1918 > addresses only to find (after signing the contract) that they collide with > the provider's addresses. Who wins in that case? > > Mohamad Eljazzar > EET Data Communications Well, RFC 1918 says these prefixes should not be propogated over the Internet but can be used on/in Intranets. I occasionally find it tough to discriminate between the two ideas. -- --bill

2 1