- Test - lists.nanog.org

Re: Which RFC?
by Bill Woodcock 02 Jan '97

02 Jan '97

> Anyone know *which* RFC says a packets should be routed using > the most specific route in a routing table, not (for instance) > the first route in the table that matches, or, for instance, > using a less specific route that has a better metric? It might be worth your while to look through the sections of RFC 791 and subsequent revisions which define the second byte of the IP header, which sets the delivery-priority and the class-of-service for the packet. The class-of-service (type-of-service?) field lets you specify whether you want the shortest, largest, cheapest, or most reliable route, those being mutually exclusive. In my experience, both fields are set to 0 on just about all packets, which doesn't specify any requested class-of-service. That presumably leaves the router free to choose any route it likes, at its discretion. > This is so basic I hardly know where to find it If the router, in its discretion, chooses to route the packet in the wrong direction, that should be easily demonstrated and reasonably incontrovertable, no? What's your vendor's argument in favor of shipping the packet to a nearby site which isn't associated with your destination? I'm kind of curious to hear it... Who's the vendor? Please humiliate them publicly. :-) -Bill ______________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)nowhere.loopback.edu user(a)host.domain.com

3 2

Which RFC?
by Alex.Bligh 02 Jan '97

02 Jan '97

Anyone know *which* RFC says a packets should be routed using the most specific route in a routing table, not (for instance) the first route in the table that matches, or, for instance, using a less specific route that has a better metric? This is so basic I hardly know where to find it, but I have a (for the time being anonymous) systems vendor who really prefers the way their kernel does it .... Oddly enough it doesn't work well with subnetting. Alex Bligh Xara Networks

3 2

Re: Film at 11:00
by Vadim Antonov 02 Jan '97

02 Jan '97

Tony Li wrote: >So the problem is that as we approach higher speed (post-7500) interfaces, >you're forced into more specialized hardware. At this point, not having an >SSE ASIC becomes somewhat silly. The rest of the board is ASICs, which in >volume end up cheaper than processors... There's not enough volume in high-end box market to get to the break-even point on the price-performance. Providing that there's a way to get a bunch of cheapo CPUs to do the job. And don't forget the DRAM vs SRAM issue. I did the arithmetic. --vadim

2 1

Film at 11:00
by Paul Ferguson 01 Jan '97

01 Jan '97

Looks like the 45k mark was reached: Table History Date Prefixes 231296 43352 241296 44089 251296 43735 261296 43391 271296 43093 281296 43912 291296 45352 301296 45532 Happy New Year on the Internet, - paul ref: http://www.employees.org:80/~tbates/cidr-report.html

5 4

45k
by alex＠relcom.EU.net 31 Dec '96

31 Dec '96

Sorry, I was mistaken about the subj. > > Hmm, it's not news for us. 45K can hold core routing only as > inter-back-bone router, not more. > > But why, why this crasy CISCO could not predict future when > they designed 45K routers? It was not difficult for them > develop this box to cary 64 or 128MB RAM. > > > > > Looks like the 45k mark was reached: > > > > Folks with 7000's and SSE's should start monitoring their memory > > utilization via "show sse summary". > > > > Tony > > > > --- > Aleksei Roudnev, Network Operations Center, Relcom, Moscow > (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) > (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) > > --- Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

1 0

RE: news at 11:00
by John-David Childs 31 Dec '96

31 Dec '96

Looks like MCI<->BBNPlanet have some routing issues to work out! :) Appended below are two just-posted BBNPlanet trouble-tickets regarding the "leakage of more-specific routes" between BBN and MCI. -- John-David Childs www.marsweb.com/www.ism.net System Administrator Internet Services Montana (406)721-6277 & Network Engineer M@RSWeb - Montana's PREMIER Web Site "I used up all my sick days...so I'm calling in dead" ---------- Forwarded message ---------- Date: Tue, 31 Dec 1996 02:38:21 GMT From: Internet Operations Center <ops(a)bbnplanet.com> To: att-tech-customer-contacts(a)bbnplanet.com Subject: #69035/5 (planet)mci peering:On Sunday, 12/28/96 during the... Ticket Number: 69035 Ticket Opened: 11/26/96 16:21 GMT Ticket Type: planned/network Ticket Source: noc Ticket Scope: planet What: mci peering Ticket Owner: neteng/liam Report Time: 12/31/96 02:15 GMT Author: kjc Problem Started: 12/28/96 08:00 GMT Original Problem Description: On Sunday, 12/28/96 during the 03:00 (EST) to 07:00 (EST) maintenance window, BBN Network Engineers will transition BBN Planet/MCI peering from regional AS's (AS200,AS86,AS279, AS560) to Planet's backbone AS (AS1). *** Note #5 As fall-out from this work, BBN was leaking more specific routes to MCI, primarily in the eastern region but certainly with issues at all four peering points. This was cleared this evening and the issue has been corrected as of 00:45 GMT. Network Engineering is continuing to deal with further fall-out from an issue with MCI - they are having access-list issues due to their configuration generator being broken. This is causing them to refuse to accept certain aggregate routes. Tracking this in tkt#74338. For a complete history of this ticket, do "finger ticket-69035(a)tickets.bbnplanet.com". ================================================================= Date: Tue, 31 Dec 1996 02:44:44 GMT From: Internet Operations Center <ops(a)bbnplanet.com> To: att-tech-customer-contacts(a)bbnplanet.com Subject: #74338/1 (planet)mci peering:After correcting routing leaka... Ticket Number: 74338 Ticket Opened: 12/31/96 02:32 GMT Ticket Type: unplanned/network Ticket Source: noc Ticket Scope: planet What: mci peering Ticket Owner: neteng Report Time: 12/31/96 02:39 GMT Author: kjc Problem Started: 12/31/96 00:45 GMT Original Problem Description: After correcting routing leakage between BBN Planet and our peering points with MCI, the fact that MCI is having issues refusing some of our aggregates became more of an immediate problem. MCI is currently working this issue - it is apparently fallout from a broken configuration generator. *** Note #1 BBN Planet Network Engineering is working closely with MCI to re-establish corrected routing. This is an issue with MCI's access-lists. For a complete history of this ticket, do "finger ticket-74338(a)tickets.bbnplanet.com". =================================================================

1 0

news at 11:00
by Philip J. Nesser II 30 Dec '96

30 Dec '96

After reading Paul's message I went and checked out Tony's page. Does anyone have any idea why the number of announced routes has jumped nearly 14 percent in the last 30 days? Going from just under 40k to 45.5k? ---> Phil

2 1

Re: Policies affecting the Internet as a whole - Hitting wh
by Dave Paulsen 29 Dec '96

29 Dec '96

>From: Bradley Dunn <bradley(a)dunn.org> >Recently one of their customers decided the incoming directory on our FTP >server would be a good place to start a warez site. We mailed help(a)uu.net >and noc(a)uu.net. Our mail included the src IP address and the times that >the uploading of the warez occurred. They were fairly quick to respond >with UUNet's policy on these matters. Basically they will only take >action when told to do so by a law-enforcement agency. Well, common practice is to have your incoming directory writable but not readable, but, barring that lapse, once you discovered what was going on it was _your_ responsibility to inform the proper authorities with the information you had. Quite a few ISPs have an AUP that states a members account will be yanked upon reasonable proof of illegal or net.unfriendly activities. It is, however, a sticky situation trying to make ISPs net.cops. After weighing the pros and cons, I have to give more weight to the "common carrier" argument. It is _your_ responsibility to protect yourself. Most of us here are more than willing to help you do that, and your time is better spent getting your system setup properly than trying to get another ISP to police their users. If people didn't make it so damn easy to abuse their systems, there'd be a lot less abuse. >I think if you are getting attacked from a specific IP or block of IPs, >you have every right to filter those packets. I question the prudence of >a 'blacklist', though. I think you have a right to filter any packets you want, for any ol' reason whatsoever, into _your_ LAN. Just don't presume that any downstream systems may also want to use whatever filtering "algorithm" you come up with. Along the same lines, a blacklist from people or groups I trust (Bush, Vixie, NANOG in general) saves me time. >From: Wayne Bouchard <web(a)typo.org> >where it might be housed so... It would be nice if some group (Hey, >wait a minute.. we're something of a group..) could come up with an >"Acceptable Use Policy" that people could subscribe to or use as a >base for building their own policy. Keeping a list of people who have This is starting to sound familiar...oh yeah, about ten years ago...FidoNet Policy formulation...I'm in favor of anything that's no longer than and embodies the same spirit as the following: 1.) Thou shalt not be excessively annoying. 2.) Thou shalt not be too easily annoyed. I s'pose we can drop "Thou shalt honor ZoneMailHour" :-) >From: Paul A Vixie <paul(a)vix.com> >we do when our network is congested is: delay it. What we do when we see >a large amount of junk in a mail queue that appears to be the result of >some automated process gone wild is (listen carefully) expunge it with no >notice to anybody. :-) >>On Fri, 27 Dec 1996, jenni baier wrote: >> So how about a creating a "white"list? and a reply >From: "Robert A. Pickering Jr." <pickerin(a)fuse.net> >This is a much better approach. Reward those who operate responsibly and >in a sense of cooperation. I'd certainly be willing to help on a draft >of such a charter. Yeah, it sounds nice, positive, all feely-good and all that, but think for a nanosecond or so. What you'll end up with is a list of about 95-98% of all ISPs, and while the folks at _Boardwatch_ and other compilers of 'net lists will greatly appreciate your efforts, it's not gonna do those searching for a reputable ISP a whole lotta good. >From: Barry Shein <bzs(a)world.std.com> [in regard to dealing with spammers, crackers, and other net.miscreants] >Too often when an issue like this is discussed we are all mesmerized >by an image of getting a real bad guy. No, if he's just a plain old jerk, that's ok too :-) ...but... >I'd say around half of the complaints I see range from "there's >nothing wrong with that behavior, what's your point?", to "there's To true, to true. >One gets the feeling that at our current level >of sophistication in internet governance no matter what the infraction >we'd either ignore it or crush the person's car, mostly depending on >which action was more convenient at the moment. and your point is?... >From: randy(a)psg.com (Randy Bush) >Indeed. We don't neen no steenkin' legal system, we can just hang 'em >right here. Works for me. >Maybe this whole thread could be moved to inet-excess or somewhere? Actually, I'd like to take it somewhere, and to anyone who's traversed this far into this spew--is there a half-way intelligent discourse going on somewhere that goes into the more social/political aspects of network operation? I realize any such forum is gonna be about 50% flame fest, but as long as there are a few competent tech people to balance out the wild- eyed idealists, liberals, and the other generally clueless, it shouldn't be too bad. _dave_(seemingly obligatory and definitely bandwidth wasting .sig)

1 0

Re: Policies affecting the Internet as a whole
by John Curran 28 Dec '96

28 Dec '96

Hello all, My only request is that folks keeping lists of "cooperative" and "uncooperative" ISP's keep in mind that it is not a world of all black and white. In particular, there are many steps that a provider can take to cooperate with an ongoing security or spamming incident which are clearly valuable and legal (e.g. confirming contact information, escalating visibility of the situation at the customer/origin site, providing guidance on how to filter/remedy the situation locally at the destination, or opting to terminate service [all of the above actions are, of course, subject to the agreement between the ISP and site]). There are a set of actions which have been requested in the past which violate contract, consumer protection, or federal law in various contexts (e.g. termination w/o notice in the absence of a threat to life/property/service, certain privacy violations regarding email or wiretapping, etc.) Frankly, an ISP which engages in such activities without diligence is a hazard to us all. It will be interesting to see when the first ISP goes out of business for terminating someone's service without adaquate process (as the first customer terminated without notice as a result of forged email is going to win big in the court). If folks can tolerate the delay associated with ISP/customer resolution of complaints, then we may have an adaquate system. For those who want policing of the net and instant justice, I'd recommend investment in Internet-literate law enforcement and judicial staff, for this is the only place where "orders" should ever come. /John

1 0

Re: Policies affecting the Internet as a whole - Hitting where it hurts
by Vadim Antonov 28 Dec '96

28 Dec '96

Jenni Baier <lioness(a)universe.digex.net> wrote: > How about creating some organization for which the pre-requisite of > membership would be adherence to a charter which outlined some standards > and policies for dealing with other ISPs when giving complaints and > standards for dealing with complaints received? The membership list could > be published and serve as a list of providers worth using, rather than > publishing a "bad" list (which, it has already been shown, is > problematic). Several years ago i proposed that CIX membership should require adherence to some rules in regard to "good conduct". I don't know if the proposal was formally considered, though few top CIX people have seen it. In my opinion that this would make membership in CIX something which could figure pominently in ads, and definitely worth membership fees. --vadim

1 0