- NANOG - lists.nanog.org

Re: KPNQWEST cease operation?
by Michael.Dillon＠radianz.com 20 Jun '02

20 Jun '02

>Anyone who isn't in the process of moving away from KQ/Ebone is >in deep trouble and should act now to ensure you get on the >list of an alternative nearer the top than the bottom. I've >heard reports from various parts of Europe about issues >and in todays FT it looks like the network will be shutdown >by the NOC employees unless the company is bought outright! What I wonder is what they mean by "shutdown". If this means that the equipment is unplugged, then how many of these alternate providers will suddenly discover that they have a dependency on an Ebone SDH/SONET ADM or an Ebone DWDM box? If management at these alternate providers is just hunting through their databases looking for KPN/Qwest dependencies they probably won't see the complete picture. KQ only completed the Ebone acquisition back in March and about a year earlier, Ebone was doing business under the name GTS or Global Telesystems. Most people who bought wavelengths or leased lines from Ebone would have done it under those names and most of those companies were carriers or network operators. This could get interesting. Personally, I hope that the NOC employees in Brussels succeed in getting potential buyers to realize the value of a functioning cross-border fiber network that covers all of Europe. Michael Dillon ex-Ebone

5 4

ATTBI refuses to do reverse DNS?
by Lou Katz 19 Jun '02

19 Jun '02

A client of mine just discovered that he could no longer do ftp transfers to my machine. His IP address had changed to one in 12.240.20 and there is no reverse DNS for that block. His previous assignment was in a totally different block which did have reverse DNS. Calls to ATTBI got the answer that they are not obligated to provide reverse DNS and have no plans to do so. My servers refuse connections when there is no reverse lookup. Is this common? -- I suppose I could set up a bogus reverse for him, but, feh... -=[L]=-

12 21

RE: ATTBI refuses to do reverse DNS?
by Rowland, Alan D 19 Jun '02

19 Jun '02

<rant> Please define cheap. Oh yeah! I can opt for a 56K (frame relay) circuit for only $250 setup and $350/month plus another $125/month if my local loop is under 10 miles plus ~$500 for the hardware. That's $1225 the first month and $475/month after that. Yeah, Joe Consumer (me) is going to be willing to cough that up for 56K. Typical 768K DSL speeds pumps the cost to $500 setup and $850/month plus the $125 minimum for a local loop. We're into house payment territory now. :) </rant> Just my 2¢. The delete key is your friend. -Al Rowland -----Original Message----- From: Stephen Griffin [mailto:stephen.griffin@rcn.com] Sent: Wednesday, June 19, 2002 9:52 AM To: nanog(a)merit.edu Subject: Re: ATTBI refuses to do reverse DNS? In the referenced message, Daniel Senie said: <snip>... > >You neglect to include the option of the customer changing to an ISP > >that provides in-addr. > > Please explain how a customer changes to another broadband vendor, or > another CDPD vendor. Despite your company's presence in a limited number of > markets, there are MANY people out there with only one choice (if they're > lucky) for broadband. I'd be more likely to lose a customer than get them > to change ISPs. I would guess it would start with them looking at the businesses which provide service in their area. If all they want is the lowest cost provider, I would ponder the following: Cheap, Fast, Good, pick any two. There certainly are alternatives to Cheap, Fast, !Good providers. They may just be Cheap, !Fast, Good, or !Cheap, Fast, Good.

2 1

RE: ATTBI refuses to do reverse DNS?
by Tim Wolfe 19 Jun '02

19 Jun '02

> -----Original Message----- > From: woods(a)weird.com [mailto:woods@weird.com] <SNIP> > Was there not once upon a time there was a proposal to > require cable-cos > to provide what would effectively be layer-2 service to any > IP provider? Yes there was until the FCC kindly stepped in and told the cable companies that they didn't need to bother with any of that open access stuff (followed by their brilliant ruling that removed the necessity of ILECs to allow unbundled access to people like Covad, etc) Thanks FCC for ensuring that all of us yokels don't have to go through the pain of deciding which ISP to get our broadband from, since we'll only have one choice per broadband type soon..... --Tim =============================================== Timothy M. Wolfe CCSE/NSA/CCNA Sr. Security Engineer tim(a)ignw.com InfoGroup Northwest 541.485.0957 x108 ===============================================

1 0

Followup: (What's wrong with provisioning tools?)
by David Daley 19 Jun '02

19 Jun '02

Below is a brief summary of the 'tools' and 'requirements' (plus a couple of unanswered questions) identified in response to my original post. Interestingly, no one mentioned next-gen OSS or anything that vaguely refered to the TMF (http://www.tmforum.org/) and the work that they've done over the years breaking down operational problems with network management systems. I suspect that no one is willing to stand up and be counted in defense of the tmf approach - at least how it tracks fulfillment systems - (and unfortunately the countless billions of funds that have gone into launch and support these companies). It's worthy to note that RFC3139 also identifies the requirements for IP configuration management. Would it be correct then to assume that the divergence between the operator and the vendor communities identified in the ietf draft (linked below) is a pointer to the failing of the approach taken by the ng/oss folks? If this is true, then what possibly is the solution to the excessive cost of management for todays networks? Cheers, David --- http://www.ietf.org/internet-drafts/draft-ops-operator-req-mgmt-02.txt -Bill --- In fact a very good tool is from DSET called IPSource that can do both provisioning and configuration management. I suggest you check it out.. --sukesh --- rtrmon or rancid can do great config archiving and provide difference output. --- > rtrmon or rancid can do great config archiving and provide difference > output. I didn't find anything that really suited my needs at the time (late 2000/early 2001), so I ended up writing my own archiver. From time to time I've thought about adding it to the COSI-NMS project on Sourceforge, but never gotten around to it. I've also other similar tools outside of Sourceforce, such as Pancho (http://pancho.lunarmedia.net/) --- i like the idea of "talking" with the box while let's say driving a car... --- The first is why aren't operators using even simple config management tools (Is every single one lacking somehow, or is it operational intertia?) The more interesting one, IMHO, concerns operational complexity. It seems that complexity is really what makes it hard to operate an IP network -- even with highly skilled engineers -- and is also the barrier to writing useful network provisioning and configuration software. What abstractions would make it easier to understand the network and hence figure out the right configuration changes to make, so software wouldn't generate config changes that are broken? --- - David Daley +1.905.922.6560 (global) daley(a)montagueriver.com www.montagueriver.com Montague River Networks Inc. -----Original Message----- From: David Daley [mailto:daley@montagueriver.com] Sent: Wednesday, June 12, 2002 1:38 PM To: 'nanog(a)trapdoor.merit.edu' Subject: What's wrong with provisioning tools? A couple of times during NANOG25, from the floor and from the podium, it was identified that the tools available for managing networks were garbage. I was surprised to hear that even real basics, such as change control and configuration management, weren't widely adopted. There definitely seemed to be an acceptance (and perhaps this is only true at some carriers) that many problems facing providers today are as a result of a dearth of decent tools to configure 'best common practices' into the routers - and as a result of this, the 'problems' with the networks were not with the h/w and/or the protocols they support, but with the people, and their lack of experience and/or ability to properly configure the boxes. A couple of comments that I heard over the last few days: 1) User interfaces are horrible and counter intuitive - I want 'xyz' out of my GUI 2) Systems blindly apply bad configurations to routers - they should be able to do 'some' verification before crashing my network - and can't roll back after they wreck things 3) Change control either doesn't exist, isn't usable, or isn't granular enough 4) There isn't anything to track non sanctioned changes to the network (i.e.: hacker induced re-configurations) I would very much like to hear about "specific" needs for (provisioning) tools that would satisfy your needs - needs that are either being poorly met to today, or not at all. In the hopes of preventing a vendor-bash extravaganza, I would suggest as a point of reference, that the NMS recommendations presented by Avi Freedman during the conference ("Industry/Government Infrastructure Vulnerability Assessment: Background and Recommendations". Of the recommendations pertinent to network management, many refer to future-features. As an additional attempt to constraint the discussion, I would recommend that the needs identified be realistic (i.e.: supportable on current equipment, the cost of the solution would be less than the cost of the problem, etc). Cheers, David - David Daley +1.905.922.6560 (global) daley(a)montagueriver.com www.montagueriver.com Montague River Networks Inc.

1 0

Re: ATTBI refuses to do reverse DNS?
by Lou Katz 19 Jun '02

19 Jun '02

Thanks for all the hints. I did not mean to trigger a flame war. ----- Forwarded message from "Robert A. Hayden" <rhayden(a)geek.net> ----- Date: Tue, 18 Jun 2002 16:13:07 -0500 (CDT) From: "Robert A. Hayden" <rhayden(a)geek.net> Subject: Re: ATTBI refuses to do reverse DNS? To: Lou Katz <lou(a)metron.com> Cc: <nanog(a)merit.edu> GAH! Sorry, bad typo. On Tue, 18 Jun 2002, Robert A. Hayden wrote: > > Most providers provide some kind for forward/reverse mapping, including > ATTBI. Often, however, they do provide customized reverse mapping (ie, ^^ do not > myhost.mydomain.com) That may be where the disconnect. > > I believe that ATTBI has a script that auto-generates forward/reverse > mappings on a regular basis. You client may be just in a waiting period > before the problem corrects itselft. I <naively?> hope that your suggestion turns out to be the case. In any event, I can do stuff which absolutely does not scale. My client needs ftp access to his website, and I do not allow anonymous ftp. I just set up a local DNS to give (consistent) local forward and reverse mapping for his IP-de-jour, and he was then able to get in. If his DHCP lease changes, I will just make another entry for him. Requiring working reverse DNS in this case (the Paranoid setting in ftpaccess) keeps down the noise level from the automatic door knob twisters. I (obviously?) do not block SMTP or HTTP access for no reverse lookup. YMMV ----- End forwarded message ----- -- -=[L]=-

1 0

ICANN requirement for "information refreshing"?
by Howard C. Berkowitz 19 Jun '02

19 Jun '02

I just received an email from Verisign customer service requesting I "refresh my information:" on an active domain that doesn't expire until 2004. My concern is that the request specifically stated ICANN required them to do this. On searching the ICANN-Verisign contract at the ICANN site, I could find no requirement for refreshing. I'm concerned this may be a covert marketing activity, since the web page for "refreshing" very easily could have led me into buying services from Verisign. This seems to be of operational interest to service providers hosting domains, if Verisign/Netsol can confuse people into shifting their service to them. Am I completely off base here? Is there some ICANN requirement I've missed?

13 16

RE: remember the "diameter of the internet"?
by Martin, Christian 19 Jun '02

19 Jun '02

>> When ANY router becomes as reliable as a dumb TDM device, then maybe >> we can begin collapsing the POP topology. However, the very >nature of >> the Internet almost prevents this reliability from being achieved >> (having a shared control and data plane seems to be the primary >> culprit). > >Uhm. Actually, control & data planes are rather separate >inside modern routers. What is flaky is router software. >That's what you get when your router vendor sells you 1001 way >of screwing up your routing :) Router hardware can be pretty flaky as well... ;) I was more referring to the nature of IP. With the exception of IS-IS, all IP control plane protocols are subject to abuse/attack by the same data plane that they are intending to control. > >> There are routers out there today that can single-handedly replace >> entire POPs at a fraction of the rack, power, and operational cost. >> Hasn't happened, tho. > >I know two boxes like that - one is broken-as-designed, with copper >distributed fabric; another (courtesy of VCs who managed to >lose nearly >entire engineering team mid-way but hired a bunch of marketers >long before >there was anything to ship) is still in beta. Ouch. >> I don't like wasting ports for redundant n^2 or log(n^2) >interconnect >> either, but router and reliability mix like oil and water... > >Actually, not. A router is a hell of a lot simpler than a >Class-5 switch, >particularly if you don't do ATM, FR, X.25, MPLS, QoS, >multicast, IPv6, >blah, blah, blah. There are opponents to this assertion. I haven't seen enough of what's in the sausage to make a firm statement either way. What I do know is that the class-5 switch is designed to save lives. A router is designed to fill vendor wallets. That, coupled with experience in the field suggests, coupled with dogma and the high-level of sensitivty to being burned repeatedly, suggests that the trend for chassis redundancy requiring massive amounts of wasted space, unnecessary hierarchy, and added complexity to continue. Ces't la Vie! >Demonstrably (proof by existence), those switches can be made >reasonably reliable. So can be routers. It's the fabled >computer tech culture of "be crappy, ship fast, pile features >sky high, test after you ship" aka OFRV's Micro$oft envy, >which is the root evil. Yep! -chris > >--vadim >

1 0

Re: 39/8 ?
by Andre Chapuis 19 Jun '02

19 Jun '02

Steve, I do not have 39/8 in my routing-table... (AS3303) André At 17:10 19.06.2002 +0100, Stephen J. Wilcox wrote: >Argh replying to my own post! :) > >Sorry, I can find AS4554 I typo'd my whois request. > >Query still applies tho .. why is there a /8 being routed from seemingly >IANA reserved space? > >Steve > >On Wed, 19 Jun 2002, Stephen J. Wilcox wrote: > >> I'm receiving routes for 39.0.0.0/8 which is odd as IANA states this is a >> reserved block, as does arin but theres a route in radb .. >> >> I cant find AS4554 either and the rDNS doesnt exist in in-addr.arpa >> >> Whats this all about then? >> >> Steve >> >> >> *>i39.0.0.0 62.24.192.1 7765 100 0 6461 4554 ? >> >> >> [whois.radb.net] >> route: 39.0.0.0/8 >> descr: Exchange Point Networks >> PO 12317 >> Marina del Rey, CA. 90295 >> US >> origin: AS4554 >> mnt-by: MNT-EPNET >> changed: bmanning(a)karoshi.com 20020401 >> source: ARIN >> >> [whois.arin.net] >> IANA (RESERVED-39A) >> Internet Assigned Numbers Authority >> 4676 Admiralty Way, Suite 330 >> Marina del Rey, CA 90292-6695 >> US >> >> Netname: RESERVED-39A >> Netblock: 39.0.0.0 - 39.255.255.255 >> >> Coordinator: >> Internet Corporation for Assigned Names and Numbers >> (IANA-ARIN) res-ip(a)iana.org >> (310) 823-9358 >> >> Domain System inverse mapping provided by: >> >> FLAG.EP.NET 198.32.4.13 >> DOT.EP.NET 198.32.2.10 >> >> --------------------- Andre Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 chapuis(a)ip-plus.net CCIE #6023 ---------------------

3 2

RE: 39/8 ?
by Kris Foster 19 Jun '02

19 Jun '02

I'm not seeing 39/8 in my tables due to proper filtering.. however: route-views.oregon-ix.net>sh ip bgp 39.0.0.0 BGP routing table entry for 39.0.0.0/8, version 5664884 Paths: (5 available, best #5) Advertised to non peer-group peers: 64.166.72.140 16150 8434 8918 6461 6461 4554 217.75.96.60 from 217.75.96.60 (217.75.96.60) Origin incomplete, localpref 100, valid, external 7500 2516 4554 202.249.2.86 from 202.249.2.86 (210.173.176.242) Origin incomplete, localpref 100, valid, external 3333 12859 6461 4554 193.0.0.56 from 193.0.0.56 (193.0.0.56) Origin incomplete, localpref 100, valid, external 1668 6461 4554 66.185.128.48 from 66.185.128.48 (66.185.128.48) Origin incomplete, localpref 100, valid, external 6461 4554 207.126.96.1 from 207.126.96.1 (207.126.96.1) Origin incomplete, metric 353, localpref 100, valid, external, best Community: 6461:5997 route-views.oregon-ix.net> > -----Original Message----- > From: John Palmer [mailto:nanog@adns.net] > Sent: Wednesday, June 19, 2002 12:42 PM > To: nanog(a)nanog.org > Subject: Re: 39/8 ? > > > > Perhaps there is a BOGON filter between you and AS4554. > > ----- Original Message ----- > From: "Andre Chapuis" <chapuis(a)ip-plus.net> > To: "Stephen J. Wilcox" <steve(a)opaltelecom.co.uk>; <nanog(a)merit.edu> > Sent: Wednesday, June 19, 2002 11:14 AM > Subject: Re: 39/8 ? > > > > Steve, > I do not have 39/8 in my routing-table... > (AS3303) > André > > At 17:10 19.06.2002 +0100, Stephen J. Wilcox wrote: > > >Argh replying to my own post! :) > > > >Sorry, I can find AS4554 I typo'd my whois request. > > > >Query still applies tho .. why is there a /8 being routed > from seemingly > >IANA reserved space? > > > >Steve > > > >On Wed, 19 Jun 2002, Stephen J. Wilcox wrote: > > > >> I'm receiving routes for 39.0.0.0/8 which is odd as IANA > states this is a > >> reserved block, as does arin but theres a route in radb .. > >> > >> I cant find AS4554 either and the rDNS doesnt exist in in-addr.arpa > >> > >> Whats this all about then? > >> > >> Steve > >> > >> > >> *>i39.0.0.0 62.24.192.1 7765 100 > 0 6461 4554 ? > >> > >> > >> [whois.radb.net] > >> route: 39.0.0.0/8 > >> descr: Exchange Point Networks > >> PO 12317 > >> Marina del Rey, CA. 90295 > >> US > >> origin: AS4554 > >> mnt-by: MNT-EPNET > >> changed: bmanning(a)karoshi.com 20020401 > >> source: ARIN > >> > >> [whois.arin.net] > >> IANA (RESERVED-39A) > >> Internet Assigned Numbers Authority > >> 4676 Admiralty Way, Suite 330 > >> Marina del Rey, CA 90292-6695 > >> US > >> > >> Netname: RESERVED-39A > >> Netblock: 39.0.0.0 - 39.255.255.255 > >> > >> Coordinator: > >> Internet Corporation for Assigned Names and Numbers > >> (IANA-ARIN) res-ip(a)iana.org > >> (310) 823-9358 > >> > >> Domain System inverse mapping provided by: > >> > >> FLAG.EP.NET 198.32.4.13 > >> DOT.EP.NET 198.32.2.10 > >> > >> > > --------------------- > Andre Chapuis > IP+ Engineering > Swisscom Ltd > Genfergasse 14 > 3050 Bern > +41 31 893 89 61 > chapuis(a)ip-plus.net > CCIE #6023 > --------------------- > > > >

1 0