- Test - lists.nanog.org

RE: Bandwidth Monitoring by IP
by Daniska Tomas 20 Jun '02

20 Jun '02

netflow? -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first. > -----Original Message----- > From: Mitchell, Dan [mailto:Dan.Mitchell@hosting.com] > Sent: 20. júna 2002 14:49 > To: 'nanog(a)merit.edu' > Subject: Bandwidth Monitoring by IP > > > > Hi all, > > Does anyone know of a low-cost solution for monitoring > bandwidth by IP? My > original thought was 1 switch port = 1 IP, but in the case of > virtual IP's > on a single port, that just wouldn't work. I'm seeing more > and more of a > demand for a basic BW report by IP, so our customers can bill > their customer > accordingly. > > Any recommendations? > > Thanks, > Dan > > Dan Mitchell > Internet Systems Engineer - Boston > AllegianceInternet / Hosting.com > 781.478.1857 Direct Line > dan.mitchell(a)hosting.com > >

1 0

Fw: SPEWS?
by Mike Lewinski 20 Jun '02

20 Jun '02

> What ticks me off is there is noone to talk to about it, you are expected > to grovel on some usenet group and hope that they are reading and will > remove you after sufficient heckling. You could also try groveling on #spews @ dalnet. Mike

2 1

39/8 ?
by Stephen J. Wilcox 20 Jun '02

20 Jun '02

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

3 3

Re: SPEWS?
by Hermann Wecke 20 Jun '02

20 Jun '02

On Wed, 19 Jun 2002, Alex Rubenstein wrote: > So, to the point; what is the consensus on SPEWs? I've never really > noticed them until this point. I'm still trying to understand two points: 1) WHO is SPEWS (who is beyond that, who runs that stuff)??? 2) WHO uses it??? (I mean: who really big - like Yahoo!, Hotmail etc is using their list) I know that several netblocks listed there are really spamheavens (like Telefonica Brazil), but they are now listing /24 even if only IP in that netblock is spamming... They may even be serious, but listing /24 and bigger ranges without showing the evidence for that listing is really crazy and insane...

1 0

if anyone would like to help...
by Earnest Guevera 20 Jun '02

20 Jun '02

If anyone is in a position to assist... 2600 IRC SERVER OFFLINE INDEFINITELY Posted 18 Jun 2002 07:13:36 UTC As a result of a massive Denial of Service attack of biblical proportions, we no longer have a home for irc.2600.net. It's rather ironic that hackers are constantly blamed for DoS attacks when they, like many Internet users, are often the victims. We have, for the moment anyway, lost a major forum of communications for the hacker community. It doesn't much matter if this was orchestrated by a bored individual or some sort of government conspiracy - the result is the same. Voices are silenced, communication becomes all the harder, any semblance of community is wiped away. There are those who will view the dismantling of our network as a good thing and it's those people whose interests were served by these attacks - attacks which required no computer skills and had nothing at all to do with hacking. The attacks came over the weekend, around the same time other such attacks were directed at sites like Fox News. They, however, got their connection back and launched a federal investigation. We would have preferred to simply find a technical solution but we weren't given that chance as our provider chose to simply disconnect us instead. Our system was kept afloat entirely through volunteer efforts and the fact of the matter is that we have more pressing things to worry about right now. Whether the IRC network ever comes back is now entirely up to the hacker community's ability to design a network that can work around the efforts of those trying to shut us down. If you want to help, please email irc(a)2600.com. We're sorry that the net continues to be shaped by malicious morons intent on shutting down all aspects of free speech. http://www.2600.com/news/display.shtml?id=1203 __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

11 10

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