February 2001 - Test - lists.nanog.org

Cingular Wireless drops below 99.999
by Alan Clegg 14 Feb '01

14 Feb '01

For the second day in a row, Cingular Wireless has no service in the 919, 910, and 704 areacodes. The customer support specialist that I talked to this morning tells me that there are 48 sites down, and offered no information as to a time-to-repair. Not being a statistics major, how long do you have to be up to fix 2 days back to 99.999%? If you are trying to get in touch with me today, just don't bother. ;-) AlanC -- Clap on (clap clap) | Clap off (clap clap) | abc(a)bsdi.com NO CARRIER

2 1

Re: happy bday IGS-R
by dave o'leary 14 Feb '01

14 Feb '01

I expect that you will get an error message if you type sho ip route, since in those days, the default was IP and sho route did exactly that. dave At 12:28 AM 2/14/01 -0500, Paul Lantinga wrote: >Tonight I fired up an *old* cisco router and found that the IOS image on >it was having it's 10th bday. > >samsite#sh ver >IGS-R Software, Version 8.2(3) >Copyright (c) 1986-1991 by cisco Systems, Inc. >Compiled Tue 12-Feb-91 12:10 by mlb > >System Bootstrap, Version 4.3(2) > >samsite uptime is 2 hours, 1 minute >System restarted by power-on >Running default software > >cisco IGS (68020) processor (revision 5) with 1024K bytes of memory. >Serial Number 00200825 >1 Ethernet/IEEE 802.3 interface. >1 Serial network interface. >16K bytes of non-volatile configuration memory. >Configuration register is 0x101 > >No command line help, no command line completion, no cidr notation, no >motorcar, not a single luxury... it's primitive as can be[1]. So, does >'mlb' still work for cisco? > >-Paul Lantinga >Q9 Networks >[1] 2 points if you got the cultural reference. 10 points if you ever >worked on an IOS version older than 8.2(3).

1 0

happy bday IGS-R
by Paul Lantinga 14 Feb '01

14 Feb '01

Tonight I fired up an *old* cisco router and found that the IOS image on it was having it's 10th bday. samsite#sh ver IGS-R Software, Version 8.2(3) Copyright (c) 1986-1991 by cisco Systems, Inc. Compiled Tue 12-Feb-91 12:10 by mlb System Bootstrap, Version 4.3(2) samsite uptime is 2 hours, 1 minute System restarted by power-on Running default software cisco IGS (68020) processor (revision 5) with 1024K bytes of memory. Serial Number 00200825 1 Ethernet/IEEE 802.3 interface. 1 Serial network interface. 16K bytes of non-volatile configuration memory. Configuration register is 0x101 No command line help, no command line completion, no cidr notation, no motorcar, not a single luxury... it's primitive as can be[1]. So, does 'mlb' still work for cisco? -Paul Lantinga Q9 Networks [1] 2 points if you got the cultural reference. 10 points if you ever worked on an IOS version older than 8.2(3).

1 0

Re: Using unallocated address space
by smd＠clock.org 13 Feb '01

13 Feb '01

Other-Sean writes: | Other than making it difficult for people to figure out WHOIS using that | ASN, "yanking" an ASN's registration has little practical effect. You | can use an un-allocated ASN almost as easily as using an un-allocated | address block. Well, the hidden point here was that the registries act on behalf of the communities of ISPs who form the registries' paying customer base / membership, and there is no particular reason why they could not alert their membership to "evil doers". What is done with such an alert is of course up to each individual member/network, however I imagine several of them would set up filtering, perhaps including the ones closest to the source of the "evil doing". Obvious candidates for reportable behaviour include the use of unregistered prefixes and ASNs. In the past in the odd case where an addressing registrar asked for assistance in dealing with such a thing she or he had discovered, I was happy to provide it. Sean.

5 8

minor update to caida reverse traceroute meta-server
by k claffy 13 Feb '01

13 Feb '01

posted this last month http://www.caida.org/analysis/routing/reversetrace/ and in response to those who brought up the obvious feature we should have included, you can now search by specific as (number, NIC name, state, city). (thanks, those who encouraged us...). nb that by 'nic name' i mean the 'AS name' for e.g., 701 is 'ALTERNET' (MCI, worldcom, etc don't work unless 701 changes its registered AS nicname) uses http://netgeo.caida.org for geography information (if you haven't checked that out you should) tnx to caida's wilfred dittmer, david moore, alex ma, brad huffaker, margaret murray feedback/suggestions still welcome (holler if you know of rvtr serversor looking glasses we should add) tnx k/elves

1 0

Re: BGP Question - how do work around pigheaded ISPs
by Smerdon, John D 13 Feb '01

13 Feb '01

FWIW, the Unisys 129.227 and 192.39 networks are supposed to be advertised as /16s. We recently converted to AGNS and have recently been informed that our /24 advertisements were not being filtered. We have been working with AGNS to correct this and it should be resolved soon. > Look at UNISYS's net 129.227/16 or any of the other examples in > traditional Class B space. -- John D Smerdon Unisys Corporation

1 0

Re: Using unallocated address space
by Sean Donelan 13 Feb '01

13 Feb '01

On Tue, 13 February 2001, Roy wrote: > It would seem to me that ARIN and its counterparts should get together and > provide a "blackhole" BGP feed (the NBL?) where all packets destined for > unallocated, restricted, or private space go bye-bye. This isn't very effective because a longer, more specific prefix wins. It would immediately inflate the route table to its maximum size if the registries announced every possible delegation. It is similar to the problem with people hijacking addresses. Unless you tie it to filters which ignore prefix announcements longer than the "authorized" allocation size. Which brings us back to the start of this thread. If AS1239 and others contributed and used something like the IRR to filter announcements, the problem is simplier.

2 1

Re: BGP Question - how do work around pigheaded ISPs
by Sean Donelan 13 Feb '01

13 Feb '01

On Sun, 11 February 2001, "Craig A. Huegen" wrote: > The original poster didn't entirely make it clear whether the other > remaining /18's would be used by other sections of the parent company, > but that's not the point. If the space had been allocated from > 206+ or 62/63/64, his announcements would have been accepted. > Just because their parent company has been around for a while means that > some ISP's penalize them. One could guess from his e-mail address that > the parent company is one of the larger global enterprises in the world. Big doesn't mean right. Old doesn't mean wise. The net is full of "big" doing really dumb things, which the rest of us are stuck working around. Net 24 is a "big" example, or Net 12 in Class A space. Look at UNISYS's net 129.227/16 or any of the other examples in traditional Class B space. > Be careful with that answer if you haven't worked in or run a network > for a global enterprise that has multiple Internet access locations. > Global enterprises pay ISP's to deliver Internet traffic LOCALLY; they > don't run Internet backbones, and they have no intention to. Therefore, > they want to assign different addressing to different areas in order to > have the ISP's bring traffic to the region with that addressing. This > differs from the ISP model where traffic arrives at the closest possible > entrypoint into the network, then follows a backbone to its destination. In general, if you look at most global enterprises who don't run Internet backbones, you'll also find they rarely have divergent routing policies. The AS Path is identical for all the locations because global enterprises have global purchase agreements. If you want to divide your /16 up within UUNET, fine. Just pay UUNET to aggregate your block before passing the announcement outside UUNET's network. Why do people forget you can aggregate blocks at points other than the edge of the network. If UNISYS had IBM aggregate 129.227/16, there is no reason why all those /24's need to appear in the global route table outside of IBM's network. UNISYS can pay IBM to get local trafic locally, but there is no reason why the rest of the global Internet needs to see those more specific paths. As you might have figured out, announcing more specifics is a nifty way to get around ISP peering handoffs, which is why some ISPs don't like listening to more specific announcements for the same organization. If I can dump the traffic onto Sony's california network block, why do I want to listen to a more specific announcement from Sony's european offices and carry the traffic on my backbone to europe. > But is there a good reason that a block size of /19 shouldn't be accepted > in this space? Is it not reasonable for an older global enterprise to > want more Internet access locations for their enterprise, and therefore > divide their address space up a bit more? Except that is not what happens, and not really even good reason for dividing up their space. Access location has nothing to do with it. You divide up the space to announce different inter-provider path attributes, e.g. different AS Path, different MED, etc. If you use the same upstreams for all your locations, there is no reason why the rest of the global routing table needs to see your seperate access locations. Whether it is a /32 or a /16, if the global path is identical, then there is no reason for a more specific announcement. We don't need to know you have a 3000 access locations in your network. Yes, in the past there were networks who wanted to announce a seperate network for each dialup POP. Yes, there seems to be a constant influx of new people everyday who believe you must announce a seperate route for each access location in the global route table. > Some ISP's believe that when the registries allocated address space in the > B space prior to CIDR times, that they intended for those companies only > to announce that space as /16's. Okay, I can accept that, given the > landscape at the time. However, the flaw that these ISP's are making in > policy is the belief that all the organizations who received this space in > the past won't use VLSM, and can't be responsible with addressing. Unfortunately, history has shown this is true. As you point out, most ISPs will listen to longer announcements *IF* you can give a good story. The reality is there are few good stories in comparison to the number of flawed attempts. >From what I read of the current big attempt, I haven't heard a good story yet. There are several alternatives, which given my limited knowledge, all seem to work for this situation.

9 9

Access to .com, .net, and .org zone files?
by Deepak Jain 12 Feb '01

12 Feb '01

Now that all of the TLD registries are all in full swing, if one wants to get FTP access to the zone files for .com (et al) who is one supposed to make the request to? (the README in ftp://rs.internic.net/domain says send a request to hostmaster(a)internic.net -- hostmaster(a)internic.net is bouncing) Thanks in advance, Deepak Jain AiNET

5 4

smtp virus traffic
by Dan Hollis 12 Feb '01

12 Feb '01

Ok folks, Virus email traffic has roughly doubled since january, with the 'snow white' virus and its mutations as #1 in virus volume. If it keeps up, virus emails will soon outnumber spam and normal email. -Dan

1 0