- Test - lists.nanog.org

C&W IP Backbone Topology Map
by Sean Patrick Gorman 28 Jan '99

28 Jan '99

A few people have been interested where the new C&W post MCI acquisition map is located. You can find in Boardwatch Magazine's February 1999 issue. Unfortunately it won't be online on their web site for a few eeks at least. Not sure if I am breaking copyright laws, but I was going to scan it and send it out to some friends so if anyone wants added onto the mailing list just drop me a line. BTW I got some good info about the C&W side of things, but was wondering if anyone has heard about what how AT&T is integrating IBM's network. Thanks Sean Gorman University of Florida Dept. of Gepgraphy

1 0

Re: Busy Connect
by William Allen Simpson 28 Jan '99

28 Jan '99

> From: "Steven J. Sobol" <sjsobol(a)nacs.net> > Ameritech offers the same service, and I've only been charged for the times > I've actually used the feature. If I hang up, I don't get charged. I have to > believe BellSouth works the same way, although I could be wrong. > Ameritech doesn't offer it here in Michigan, so I don't know what problems there are. In Mississippi, it works like this: Busy tone is replaced by a voice message saying something like "Your party is currently busy. If you would like to call again, press 1 or hold the line." If you hold the line too long (30 seconds?), or you redial a number with a 1 in it (several of our hunt groups have a 1 in them), you get charged $.75... But nobody has gotten phone bills yet, so we don't know how bad the financials are. The support calls are all folks trying to kindly tell us that our phone lines have stopped working, because of the messages shown by the modem software, which expects a busy signal. And if you call BellSouth to complain, they tell you to signup for BellSouth.Net :-( WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

4 5

Re: Busy Connect
by Dean Anderson 28 Jan '99

28 Jan '99

I would complain to the FCC. Presumably, the customer is dialing the number with their modem, and the modem isn't responding the the message "do you want to busy connect for 75 cents". Yet they are getting the busy connect service and presumably are charged the 75 cents to "busy connect" without their approval. The service should not default to charging the customer when there is no response to the query, as would be the case with a modem connection. You should ask your customers to complain to the FCC and complain to Bell South to get their 75 cents per call refunded. Your customers should not need to disable the service entirely. --Dean At 11:46 AM 1/27/1999 -0500, William Allen Simpson wrote: >I don't know how many other small/dialup ISPs are seeing this problem. >BellSouth just turned it on in our area. Sent our support calls through >the ceiling during busy evening hours. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

Re: Byte Counters on Ciscos
by Dean Anderson 27 Jan '99

27 Jan '99

Cisco stores them as 32 bits, but SNMP also retrieves them as 32 bits. HP has a proprietary MIB & impl. for its Lanprobes & RMON s/w for HP workstations, which is 64 bits wide. These are the only devices I know of that store more than 32 bits, and have accurate counts of bytes over a long period of time. So on ciscos, you should clear counters before they can roll over. You should really have a raffle to guess the uptime on your router. ;-) --Dean At 10:46 AM 1/25/1999 -0500, alex(a)nac.net wrote: > > >I am working on some byte counting stuff, and have a odd question. > >I noticed on my of my routers: > > 2403558863 packets input, 2476827328 bytes > >thats: > > 2,403,558,863 packets input, > 2,476,827,328 bytes > > >which when divided out, comes to 1.03 bytes per packet, which without >saying is obviously in error. > >So, when does a Cisco counter 'flip' ? How many bits is it? > > >-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > Atheism is a non-prophet organization. I route, therefore I am. > Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member > Father of the Network and Head Bottle-Washer > Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 > Don't choose a spineless ISP; we have more backbone! http://www.nac.net >-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

smurf tracing
by cache22 27 Jan '99

27 Jan '99

greetings-- if one needed to trace spoofed packets on their network, how would one go about doing so? are there sniffers that identify an ethernet packet's source and destination mac address? are there any free unix ones? -matt sommer

1 0

Re: Who uses RADB/IRR?
by Daniel Senie 27 Jan '99

27 Jan '99

Pierre Thibaudeau wrote: > > On Tue, 26 Jan 1999, Daniel Senie wrote: > > > Date: Tue, 26 Jan 1999 09:18:27 -0500 > > From: Daniel Senie <dts(a)senie.com> > > To: nanog(a)merit.edu > > Cc: briand(a)spare.de.teleglobe.net > > Subject: Re: Who uses RADB/IRR? > > > > -------------------------------------------------------------------------------- > > > > briand(a)spare.de.teleglobe.net wrote: > > > > > > > DA> I started looking at the RADB, but haven't got ourselves setup yet. Does > > > > DA> anyone actually deny routes which aren't listed in the RADB? I guess what > > > > DA> I'm really asking is how important is it to be in the RADB? Does it get > > > > DA> more important sometime soon? > > > > > > Yes, for peers and customers. Pretty important, at least for international > > > connectivity (which is what we provide). Yes. (See below.) > > > > You present several good points for requiring peers to register. Not all > > networks require their peers or customers to be in the RADB, as not all > > networks use the RADB or other databases. > > > > Interesting problems arise when route filtering is applied by at least > > some RADB users. > > > > ANS.NET, for example, does not (at least in some cases) accept data from > > the RADB when a prefix is moved from one AS to another. A move in AS > > might occur when a portable prefix is shifted to a new ISP, or when a > > portable prefix aquires its own AS and goes multi-homed. When this type > > of change happens and ANS doesn't pick it up, the prefix which was moved > > loses access to sites attached to ANS. > > > > So, why is this a problem? The prefixes in question are not ANS > > customers, nor are they peers of ANS customers. How does one find out > > there's a lack of routing ability to ANS? Well, cnn.com doesn't work, > > and a few other sites. This is a BAD way to find out. > > > > What's needed is a clean way to examine the policy databases of RADB > > (and other database) users to verify whether a network is being properly > > routed. If your policy says to only accept a particular prefix as coming > > from a particular AS, then the owner of the prefix needs to be able to > > query your database to find out that you have that policy in place. > > > > Presently there is no list of routing policy database users, and no way > > to query the databases of those providers (at least that I've seen any > > Daniel, > > "Those providers" (to my knowledge, ALL those who build such filters) rely > on publicly available data to build their access-lists. Although it's not > possible to examine each carrier's filters, there is a simple way to > examine the database that is at the source of these filters. i.e.: > > alpha 58: whois -h radb.ra.net 204.69.207.0/24 > route: 204.69.207.0/24 > descr: Daniel Senie Consulting > descr: 324 Still River Road > descr: Bolton > descr: MA 01740, USA > descr: @Work Internet > origin: AS6172 > notify: routing(a)home.net > notify: noc(a)home.net > mnt-by: MAINT-AS6172 > changed: fath(a)corp.home.net 981104 > source: RADB > > With this, you can be sure that those carriers who filter will permit the > 204.69.207.0/24 if it is originated in AS6172; be it an immediate peer of > HomeNet or a distant one like ANS. Yes, this info is all well understood. It just DOES NOT happen that way. I had first hand experience of it not happening, and have talked with others who similarly have had experience with it not happening. I wanted to examine ANS's tables and policies directly because they did NOT pick up the RADB changes automatically. For whatever reason, a manual change was required at ANS. That case is history and the problem was solved after several days of phone calls. The bigger issue is ensuring such problems do not occur in other cases. > > > public info on). So, making any changes to the routing of a prefix is > > treacherous. I advise clients with portable address space that when > > they're switching providers or multi-homing, there may be loss of > > connectivity to some locations for a week or more (while database > > changes propagate) and some sites may be cut off entirely until the > > other site's ISP is contacted. > > It is the responsibility of the admin of the Autonomous System that will > eventually advertise a given network to register an appropriate route > object for it. > > Because some may forget or otherwise neglect this task, here is my advice: > before moving from one provider to another, make sure that your new > provider have done his homework. If you see a route-object with a > "origin:" field containing your provider's ASN, you're in business. No > need to fear: the RADB/IRR works fine with multiple route objects with > different "origin:" (technically, the key for these records in the > RADB/IRR system is the concatenation of the "route:" and "origin:" > fields). So if your new provider registers a route object ahead of time > (and this is what they should do), you will not loose connectivity through > your current provider. After the switchover, it is your former provider's > responsibility to delete the obsolete route object. The cases I more commonly work on involve sites with portable address space going to multi-homing. Here, my client is actually the owner of the ASN. We're running BGP with full tables to multiple upstreams, where a single upstream and no BGP existed before. The RADB data goes in quite a while ahead, since we're in control of the AS. Based on previous experience and that of other folks, I still have very little confidence that the routes will be picked up properly by all database users. The only way we can be sure the routes are there, is to schedule downtime, cut all links but one, and see what's reachable. This is a terrible way to do such testing. I'd like to see something better and less disruptive. Since there appears no other way, I have such a test scheduled for tomorrow night with one of my clients. This client does multi-homing for redundancy and load balancing. The redundancy part is useless if there are any database interpretation problems. Perhaps now you'll understand why I really want to see a list somewhere (eg. on the RADB pages) that list all providers using the databases, and a place on each provider's network where the tables can be examined for a set of prefixes. Yes, it SHOULD all just work. No, it doesn't ALWAYS just work. When things don't work, there needs to be a way to find out where things are broken and why. Finding out by having someone notice a week later that some site they need to access is unreachable is NOT acceptable. Dan -- ----------------------------------------------------------------- Daniel Senie dts(a)senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com

1 0

Good work, MCI!
by James Rishaw 26 Jan '99

26 Jan '99

It's now been 7 days one hour since I opened the "critical" priority ticket with MCI security with no callback :-) Three calls to the noc with ticket "18" got nothing but laughs.. "We dont have tickets that low" .. :-p Growing pains? :-( -- jamie rishaw (efnet:gavroche) American Information Systems, Inc. jamie at ais dot net infrastructure engineering

2 1

Re: InterNic Responds
by Dean Anderson 26 Jan '99

26 Jan '99

Interesting. They claim to get 30000 registrations a day, 20000 bogus. That isn't very many. Interesting that they claim the speculators are "spammers spamming their system with bogus and incomplete registrations". Seems like speculation and denial of service are separate things. I smell something from NSI. But, since some people disputed what I and 'half a million' others think about the difficulty and performance limitations of a registration system, I'll "put up" instead. I'll supply the development system that will run on Linux with Oracle 8 (I'll spend the $295 for Oracle/Linux) The devel system will be a dual P233 with Redhat 5.2. (Already have this) This will allow the software to be moved to a Sun with Oracle Enterprise, which has the features required to handle very large tables, replication, etc. It will be able to be a "highly available, commercial quality system". If you are interested in writing code to generate zone files, modify whois/rwhois server to use oracle/odbc, make web pages, send me mail. (I'll write the email parser) I don't think this will take very long, even part time. I expect that the devel system should be able to handle the 30000 registrations per day. --Dean At 05:20 AM 1/26/1999 -0800, Henry Linneweh wrote: >Speculators Inundate InterNIC >http://www.wired.com/news/news/technology/story/17522.html > >Henry R. Linneweh > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

FW: Concert Network Maintance - 8.5 Upgrade Domain 4 (UK)
by Regan, Sharon 26 Jan '99

26 Jan '99

-----Original Message----- From: BrownLJ(a)stentor.ca [mailto:BrownLJ@stentor.ca] Sent: Tuesday, January 26, 1999 1:36 PM To: Regan, Sharon Cc: GreenKB(a)stentor.ca; GodardD(a)stentor.ca; WongR(a)stentor.ca; SavardCR(a)stentor.ca; MenardPA(a)stentor.ca; McfetridgeM(a)stentor.ca; FournierLC(a)stentor.ca; SchroederJP(a)stentor.ca; ShurtliffMJ(a)stentor.ca; LockeMW(a)stentor.ca; WarrenGA(a)stentor.ca; PackmanJ(a)stentor.ca; ReilleyJA(a)stentor.ca; RochfordM(a)stentor.ca; GirardLP(a)stentor.ca; BirdBR(a)stentor.ca; WarrenL(a)stentor.ca Subject: Concert Network Maintance - 8.5 Upgrade Domain 4 (UK) Ms. Regan; On February 12th, 1999, Concert will be upgrading Subnet 4 (UK) to System Software 8.5. This upgrade is to begin at 23:00 GMT (18:00 Eastern) with a maintenance window duration of 10 hours. The initial impact to the Frame Relay network will be minimal; the expected downtime will be less than 45 seconds for most nodes and up to 2 minutes of data interruption for some. There is also a possibility of reroutes, although the chance is small and would be like any other reroute that would occur upon a trunk failure. There is an expectation that approximately 10% of the PVC's will experience failures for which a script will be executed, on each node, to correct the problem. All issues that have been observed with the Subnet 5 (Germany) upgrade have been addressed in this script and it is expected to take approximately 2 hours to complete. The lower the number of PVC's on a node, the quicker the reroute time. The reroutes will be noticeably faster as System Software 8.5 supports trunk based loading. Please note however, by resetting connections throughout the Subnet, each PVC will be impacted twice. This is unfortunate but unavoidable in order to accomplish the upgrade. Regards, Linda J. Brown CCSC - Concert Canada Service Center Concert Change Management 613-781-9382

1 0

Re: Who uses RADB/IRR?
by briand＠spare.de.teleglobe.net 26 Jan '99

26 Jan '99

> DA> I started looking at the RADB, but haven't got ourselves setup yet. Does > DA> anyone actually deny routes which aren't listed in the RADB? I guess what > DA> I'm really asking is how important is it to be in the RADB? Does it get > DA> more important sometime soon? Yes, for peers and customers. Pretty important, at least for international connectivity (which is what we provide). Yes. (See below.) > "Important" is hard to define. People tend to register in the RRs and make > use of the RSes because: > > [1] It's the right thing to do to publish public policy. It's like > signalling before changing lanes. > > [2] It makes life easier on yourself and the community that participates in > configuring off the RRs. [3] One word says it all: scaling. The use of the RADB to register routes and routing policy, permits the automated generation of all types of ACLs, independent of the size of the ACL. Manual methods do *not* scale, and while authentication of the contents of the RADB are questionable, this is addressable and only requires more people to update their maintainer objects (to use more-secure methods). Here is the crux of the argument why anyone would *require* their peers to register: - if you filter your customers by hand, your filters are suspect - if you filter your customers by RADB, not so much - if you don't use the RADB for customer filters, I'm not comfortable trusting your routes blindly, and want to filter you - if you don't filter at all, I *insist* that I filter you - I don't want to build a filter for you, which is orders of magnitude bigger that your filters for your customers, by hand - thus, I want you to use the RADB - but, if you use the RADB, you can automate your customer filters! So, if you use the RADB to build your customers' filters, I *could* consider trusting you, but at that point it is trivial for me to build a filter for you. If you don't, I can't trust you, and can't easily filter, so I won't peer with you. (!!) Teleglobe (ie, us) use the RADB for building ACLs for *all* customers and peers. (Well, obviously not for statically-routed customers, but those are registered from our AS.) If someone doesn't register or maintain their as-macro, for example, we maintain our own IRR, irr.teleglobe.net, and make a private "snap-shot" of this peer's set of AS's, and build a proxy as-macro, which is immediately out-of-date, but is updated periodically, and is a heck of a lot better than running unfiltered. This is the only thing we do that even vaguely resembles manual support for non-registrants. We require that route objects themselves be registered, regardless, in order to accept routing updates. We have no interest in attempting to keep the whole internet proxy-registered on a per-route-object basis! While we currently maintain at least one transit relationship, this will still permit connectivity to be established via such transit providers; once we switch to pure-peering for connectivity, this registration *will* be very important if you want to access any of our customers. We currently represent approximately 15% of the reachable Internet, and our growth rate is greater than that of the general industry, ie. expect this percentage to increase. We don't want to force our policy on anyone else, but we insist on not being forced by others into changing our policy. Our policy is to filter. Our filters use the RADB. Anyone who wants to peer with us, either at NAPs or via private link, must register. If they don't keep the RADB up-to-date, they will at some point announce routes that we filter out. This is their problem, not ours. If anyone wants to register but is concerned about public visibility, an option is to run a private IRR, and permit your BGP peers to query this IRR. However, if you provide transit to anyone, they would need to be registered on either your IRR or a public IRR, and if you get transit from someone, their peers will need access to your info as well. These all point in the direction of public IRR's as the right way to go. > DA> I would also tend to think [based on limited BGP knowledge] that it would > DA> only be a problem if your direct upstream used the RADB or if your upstream > DA> is RADB filtered by their peers. Is this true? Or if *their* upstream is filtered by peers, etc, etc, up to the "tier 1" providers. Of the big tier 1's, I believe Sprint is the only non-registrant of significance (ie numbers of routes in double-digit percent of global table.) If this ever changes, then global reachability could require registration, period. > You forgot the word "exclusive". Many providers in addition to configuring > off the RR also manually configure in (by hand) those who do not have > registered policy in the RRs. I consider this suboptimal administrative > practice but you do what you have to. Refusing to manually update non-registered networks, is a significant lever to "encourage" the other guy to register. If enough people join this effort, *everybody* wins. Be advised, however, that filtering *big* networks takes lots of space in your router configs, and even with "service compress-config", you can hit the wall pretty easily, and eventually need to save configs onto flash or a local TFTP server (and don't forget to change boot buffersize!). However, this is no reason not to filter, it is simply a change in procedure needed while Cisco ships pitifully small NVRAM on their core router products. ;-) > And for those who only do > aspath-based filtering... keep knocking on wood. |8^) For those who do not grasp the subtlety of this last statement: More than once, in recent memory, has a clueless small ISP done the unthinkable of redistributing BGP into an IGP, and back into BGP, thus appearing to announce the entire Internet from their own AS. Allowing these routes without filtering, resulted in major blackholing/meltdown of big pieces of the Internet, notably those ISPs providing transit to the small ISP and its ISP without filtering. Those who do not learn from history are doomed to repeat it. Those who do not learn from history are doomed to repeat it. Those who do not learn from history are doomed to repeat it. In case anyone is concerned about operational impact of filtering: The filtering we discuss here is filtering routing updates, not filtering of packets. Routing updates generally represent a negligible load, and filtering is inexpensive in this regard. The only times where routing updates are a big load, is the *precise* time when you really want to be filtering out the updates, eg the redistribution situation above. Brian Dickson Teleglobe

3 2