July 2002 - Test - lists.nanog.org

Notes on the Internet for Bell Heads
by Sean Donelan 26 Aug '02

26 Aug '02

Has anyone written the equivalent of the old Bell Systems Notes on the Network for the Internet? A couple of books come close, Hueston's ISP Survival Guide and Cisco's ISP Essentials. But there doesn't seem to be anything that helps Bell heads understand what switching, routing or signaling means on the Internet. There are a lot of words which are spelled alike, but mean very different things in the Bell world and the Internet world. I've been thinking of it like driving in England or the USA. We drive on different sides of the road. Its safe until you get someone who doesn't know the rules of the road driving on the other side of the Atlantic. So how do you explain the rules of the Internet road to someone used to driving on the telephone system?

18 23

Corporate PGP for network operators
by Sean Donelan 19 Aug '02

19 Aug '02

Ok, extremely dumb question. But I'm sure lots of other people have already solved this one. Network operators have been using various PGPs to exchange confidential information for many years. I have my own personal PGP key for my own use and a nice Unix box of my own. There are licensed versions, freeware versions, guerilla versions, and so forth. NAI is no longer selling a commercial version of PGP Desktop for Microsoft Windows/NT. Phil Zimmerman points people to the OpenPGP alliance http://openpgp.org/members/ What do commercial network operators, who are required to use Microsoft, use for business PGP mail besides NAI? I.E. if we need to exchange PGP mail, what package is least likely to crash Outlook and Windows.

3 3

DNS monitoring changes
by Rob Thomas 07 Aug '02

07 Aug '02

Hi, NANOGers. I have added two additional data collection points to my DNS root name server monitoring. I have also scaled the graphs (thanks, Howard!) and added a text only version. You will find it all here: http://www.cymru.com/DNS Comments and feedback are always welcome! Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

2 1

GBLX router upgrade breaks bgp sessions
by nanog 06 Aug '02

06 Aug '02

Subject says it all. GBLX upgraded some edge routers to a new JunOS release (possibly 5.3 rev 24)- and now our bgp sessions continually reset with: Jul 10 06:58:24 MST: %BGP-3-NOTIFICATION: sent to neighbor X.X.X.X 3/3 (update missing required attributes) 0 bytes Anyone clueful at GBLX listening? We've been down for about 4 hours, and the NOC (call center) people are less than helpful. bill

5 7

Identifying DoS sources quickly (was: Bogon list or Dshield.org type list)
by michael.dillon＠radianz.com 01 Aug '02

01 Aug '02

>As far as tracking DoS, I've read some good papers on the subject and it >always boils down to tracking MAC addresses and going interface by >interface to the source, demanding inter-ISP cooperation, and finally >legal assistance. This has been tried during a few severe instances with >poor results. That's the obvious solution to the problem if the problem is how to track down the source(s) of a DoS attack. However, in any DoS attack, there is always a victim and one or more devices sending attack traffic to the victim. The owners of the attacking devices are accessories to the crime although I'm sure they could plead ignorance and avoid any liability. But what if they could not plead ignorance? What if we could identify some of the attacking devices, and what if the victim sent a legal "cease and desist" letter to the owners of the attacking devices? Now, the victim is in a position to sue the owners of these attacking devices if they don't fix the problem by securing their machines. And once this happens and gets some press coverage, a whole bunch of other machine owners will wake up and realize that they could be stuck with big legal bills if they don't secure their machines. So, to restate the problem, how do we identify some of the sources of a DoS attack quickly, maybe even while the attack is still in progress? >Bots/Zombies are traded openly on IRC and there is no >accountability for personal security. ISPs won't shut someone down >because they've been "hacked", merely send them a warning Email or >call--a process that takes days in my experience. How many ISPs would identify the user of an IP address for the purposes of sending a "cease and desist" letter when contacted by a lawyer? Considering that failure to provide the identity would result in the ISP themselves getting sued by the DoS victim? As long as *SOME* ISPs would cooperate with a DoS victim, there is enough to get the legal ball rolling. The alternative is to painfully backtrack until you find an uncooperative ISP and then sure them. As I said before, if there was a central registry something like dshield.org that collected data on the destination IP addresses of DoS attacks along with estimated magnitude based on analysing the traffic from random source addresses blocked by ingress filters, then we have something an ISP can use to analyze their outgoing traffic. If you are an ISP and you have netflow data that contains destination addresses which also occur in the DoS victim registry then you should be willing to act on that data. Of course, it's up to you what you do with it. You may offer the DoS victim the identity of the source provided that they serve you with the right legal documents. Or you might go to the owner of the machine yourself with the evidence and warn them that they are aiding and abetting cyber terrorists and could suffer the legal consequences if they don't secure their machines. It's certainly not perfect but it's worth a try. --Michael Dillon

8 10

MAE ATM
by nanog＠missnglnk.com 01 Aug '02

01 Aug '02

Out of curiousity, when were MAE East/West ATM established? -- Omachonu Ogali missnglnk(a)informationwave.net http://www.informationwave.net

11 11

Re: redundancy [was: something about arrogance]
by Pedro R Marques 31 Jul '02

31 Jul '02

Pedro Roque Marques wrote: >------- Start of forwarded message ------- >From: pre(a)PRE.ORG (Patrick Evans) >To: Jim Shankland <nanog(a)shankland.org> >Cc: nanog(a)merit.edu >Newsgroups: jnx.ext.nanog >Subject: Re: redundancy [was: something about arrogance] >Message-ID: <Pine.LNX.4.44.0207310130150.3798-100000(a)pimlico.PRE.ORG> >Date: 31 Jul 02 00:32:49 GMT >References: <200207310019.RAA05167(a)ndk.shankland.org> >Organization: Juniper Networks, San Francisco, California > > >On Tue, 30 Jul 2002, Jim Shankland wrote: > > > >>Patrick Evans <pre(a)PRE.ORG> writes: >> >> >> >>>My first project, if network availability were a key issue, within any >>>organisation would be to a) obtain [an AS number] and b) make use of >>>it. >>> >>> >>Heh. How many bits in an AS number, again? >> >> >> >*grin* > >That's a problem with the underlying protocol. I get paid to run >operational networks, not bleat endlessly about "how much work would >it *really* take to implement 24bit AS numbers?" :) > > The plan is 32 bits... (see draft-ietf-idr-as4bytes-05.txt for details). Essentially i think it just takes interest/demand from ISPs since the mechanism can be implemented and deployed without in a non disrruptive way. >Crying about protocol deficiencies is a distant second to keeping a >business up and running these days. > > imho, protocol efficiencies are not so much the problem. If it is clear the scale routing must operate on the right hardware/software can be engineered... that assuming that people are willing to upgrade their existing boxes and that it isn't a requirement that it must run on 5 year old small entreprise boxes. The later seems to be the biggest problem although. Effectivly the growth of routing table size is bound by the maximum memory size and CPU capacity present in the most common boxes used in the network and not by protocol efficiency. It is not so much of a question if one can build a database engine and respective distribution protocol than can scale upto n million paths but of the limits of the current day moral equivalent of the AGS+. Thus all the people that have these deployed in their networks tend to be concerned about the need to upgrade them as the size of the routing table increase. As one of the posters was king enought to point out these sometimes end up being more issues of economics/buisiness than of engineering. regards, Pedro.

1 0

Re: redundancy [was: something about arrogance]
by Patrick Evans 31 Jul '02

31 Jul '02

On Tue, 30 Jul 2002, David Schwartz wrote: > One more just for kicks. Client had a 100Mbps circuit from their sole > provider (100Mbps to colocated router, DS3 from this router to their > premises). The circuit had been in place for several years and the contract > had long since expired. One day, they got a call Er, what does due diligence mean to you? (We're waaaay into no-shit-sherlock territory here) (For the record, I'd consider any operation without an AS number a startup, and my first project, if network availability were a key issue, within any organisation would be to a) obtain one and b) make use of it. YMMV, but some V are more equal then others. Particularly in the current economic climate.) -- Patrick Evans, allegedly Email: pre(a)pre.org CV: www.pre.org/pre/cv Wheels: Kawasaki ZXR400L9

2 2

redundancy [was: something about arrogance]
by Pedro R Marques 30 Jul '02

30 Jul '02

Brad writes: > I'm probably demonstrating my ignorance here (and my stupidity in > stepping into a long-standing highly charged argument), but I'm > completely missing something. For reasons of redundancy & > reliability, even if you were to buy bandwidth in only one location, > wouldn't you want to buy it from at least two different providers? > If you buy bandwidth from two different providers at two > different locations, this would seem to me to be a good way to > provide backup in case on provider or one location goes > Tango-Uniform, and you could always backhaul the bandwidth for the > site/provider that is down. Several other posters have mentioned reasons why redundancy between 2 different connections to separate providers are not, in most situations, the preferable aproach but i would like to add another point/question... When considering redudancy/reliability/etc it is important to think about what kind of failures do you want to protect against vs cost of doing so. It is my impression, from reading this list and tidbits of gossip, that the most common causes of failure are: - link failure - equipment failure (routers mostly), both software and hardware - configuration errors All of those are much more frequent than the failure of an entire ISP (a transit provider). It is expected, i believe, of a competent ISP to provide redudancy both within a POP and intra-POP links/equipment and its connections to upstreams/peers. As such, probably the first level of redundancy that a origin AS (non-transit) would look at would be with the intent to protect from failures of its external connectivity link and termination equipment (routers on both ends). To do so, one can look at: - 2 external links to distinct providers - 2 external links to the same provider While i can't speak to the economics part of the equation (although i would expect it to be cheaper to buy an additional link than connect to a different provider) from a point of view of restoration, protecting a path with an alternate path from the same provider is certainly an aproach that gives you much better convengence times. This comes from the fact that in terms of network topology, the distance between 2 links to the same upstream is much shorter than 2 links to different upstreams. While, if you protect a path with an alternate path to the same ISP you can expect convergence to occur within the IGP convergence times of your provider, with 2 different providers you need global BGP convergence to occur. This gets to be longer dependent on how topologically distant your 2 upstreams are... for instance attempting to protect a path to an ISP with very wide connectivity with a protection path from one with very limited connectivity would be a particularly bad case as you would have to wait for the path announced by the larger ISP to be withdrawn n times from all its peering points and the protection path to make its way through in replacement. It is counter-intuitive to me what i perceive to be the standard practice of attempting to multi-home to 2 distinct providers by origin-only ASes... from several points of view: convergence times, load on the global routing system, complexity of management, etc, dual connectivity to different routers of the same provider (using distinct physical paths) would seem to me to make more sense. Unless the main concern is that the upstream ISP fails entirely... which given the fact that it tends to have frontpage honors on the NYTimes this days does not apear to be an all to common occurence (i mean operationally, not financially - clarification added to dispel potential humorous remarks). So, my question to the list is, why is multi-homing to 2 different providers such a desirable thing ? What is the motivation and why is it prefered over multiple connections to the same upstream ? Is the main motivation not so much reliability but having a shorter as-path to more destinations ? This would apear to me to be a clear advantage since that doesn't necessarily reflect in better qualitify of interconnection. My apologies in advance if these seem to be stupid questions... thanks, Pedro.

6 7

RE: OC-768 availability?
by Rowland, Alan D 30 Jul '02

30 Jul '02

Compton, CA, US and Sealand would be the giveaways. Best regards, _________________________ Alan Rowland Who lives just south of Compton -----Original Message----- From: Scott Weeks [mailto:surfer@mauislanwanman.com] Sent: Monday, July 29, 2002 4:31 PM To: Williams, Ken Cc: 'dalph(a)hushmail.com'; nanog(a)nanog.org Subject: RE: OC-768 availability? No, he's not for real. It's a satire in the likes of Bandy Rush and such. Children need to have their fun... scott On Mon, 29 Jul 2002, Williams, Ken wrote: : : hah 2621 rockin oc-192 are you for real? : : -----Original Message----- : From: dalph(a)hushmail.com [mailto:dalph@hushmail.com] : Sent: Monday, July 29, 2002 4:10 PM : To: nanog(a)nanog.org : Subject: OC-768 availability? : : : : : Hello, : : I am currently running a network of cisco 2621s with the OC-192 NM for my : upstream connections. The internal network links are a mixture of K56Flex : modems and GRE tunnels. : : I am looking to upgrade to OC-768 real soon now and am wondering what the : prospects are for OC-768 availability on the 2621 platform. I've found the : 2621 to be rock-solid, except when I ping it, so I'd like to keep my network : on that platform if possible. : : In addition, if anyone knows the availability of OC-768 circuits between the : following cities I'd appreciate any fiber maps and an approximate price : range: : Ottawa, ON, CA : Midland, ON, CA : Goderich, ON, CA : Toronto, ON, CA : Compton, CA, US : Sealand : : At each site I plan to announce a /24 from a /20 I was allocated so if : everyone could please update their prefix filters now that would be great. : : Thank you. : : -- Dalph Roncaster : : Communicate in total privacy. : Get your free encrypted email at https://www.hushmail.com/?l=2 : : Looking for a good deal on a domain name? : http://www.hush.com/partners/offers.cgi?id=domainpeople :

4 3