- NANOG - lists.nanog.org

pmmon spam
by Daniel Simms 08 Nov '96

08 Nov '96

We got spammed today, but I'm not totally convinced of how it happened. Thus, this a sanity check for me. So, this is my theory. It seems like the spamee list was an alias on one of the Spammer's machines. The the From: field of the spam was that *same* alias. Then there was a wave autoresponses directly to that address. Then, the n(n-1) autobot free-for-alls ensued, since there were several dozen infobots on the spamee list. Is this plausable? Send comments my way. - --- begin original message ---

2 1

Re: BGP Configuration Problem
by Rob Liebschutz 08 Nov '96

08 Nov '96

> > We are having a BGP configuration problem which looks trivial but is not > > working the way we expect. I'm going to throw myself on the mercy of > > the court and ask for help. > > > > There are three routers A, B and C. These are in ASa, ASb and ASc, > > respectively. B imports 10.1.64/19 from A and 10.1/16 from C. What > > we were expecting was for B's route to the /19 to be via A, just because > > this is the more specific route. However, the only route (both in the > > BGP and routing tables on B) is for the entire /16 via C. > > Even if it isn't the best route, you should see the table of choices > (in a Crisco) if you do 'sho ip bgp x.y.z.0'. You'll only see the most > specific choices that match with that - you could also do a 'sho ip bgp' and > watch (presumably 10/8 should be near the top) for 10.1.64.0's range to show up > and see what choices are presented. How about: show ip bgp 10.1.0.0 255.255.0.0 longer-prefixes

1 0

Re: Cisco for dummies?
by Mike Vallee 08 Nov '96

08 Nov '96

If Tim and Associates could give the ISP community, and the rest of the IP world a Nutshell Book on IOS/IP, the rest of the protocols could go to the devil for all I care. The fact is, _only_ the IP feature set would have enough of a market to make such a book worth doing. Maybe IPX, maybe. For TCP/IP, I would make sure a copy went to each of my customers while they wait for PcaBell to hook up the local loop. Should give them plenty of time to get up to speed. Mike At 08:48 PM 11/8/96 -0600, Paul J. Zawada wrote: > >Actually, to cover everything the various flavors of IOS does, you would >probably need different nutshell books targeted at different audiences, >perhaps one for each flavor of IOS. (Enterprise, IBM, Desktop, ISP...) I >don't think too many people on this list would care about the SNA $%#^ that >Cisco-Blue does. > >--zawada > >At 05:33 PM 11/8/96 -0500, Deepak Jain wrote: >> >>Actually the Nutshell books are great. "Cisco IOS in a Nutshell" I can go >>for that. Aren't they the ones that also do *the* Sendmail book? >> > > >Paul J. Zawada, RCDD | Senior Network Engineer >zawada(a)ncsa.uiuc.edu | National Center for Supercomputing Applications >+1 217 244 4728 | http://www.ncsa.uiuc.edu/People/zawada > >

1 0

BGP Configuration Problem
by Michael H. Lambert 08 Nov '96

08 Nov '96

We are having a BGP configuration problem which looks trivial but is not working the way we expect. I'm going to throw myself on the mercy of the court and ask for help. There are three routers A, B and C. These are in ASa, ASb and ASc, respectively. B imports 10.1.64/19 from A and 10.1/16 from C. What we were expecting was for B's route to the /19 to be via A, just because this is the more specific route. However, the only route (both in the BGP and routing tables on B) is for the entire /16 via C. I have a hunch that what is happening is that B is saying "gee, I can get to the entire /16 by going through C, so why bother with A". If I'm not mistaken, this can be fixed by introducing local_pref for both peers. Could someone please comment on this? Thanks, Michael +----------------------------------------------------------------------------+ | Michael H. Lambert, Network Engineer Phone: +1 412 268-4960 | | Pittsburgh Supercomputing Center FAX: +1 412 268-8200 | | 4400 Fifth Avenue, Pittsburgh, PA 15213 lambert(a)psc.edu | +----------------------------------------------------------------------------+

5 4

Announcing PMMON 2.0 (Terminal Server Monitor Software)
by pmmon＠solgate.com 07 Nov '96

07 Nov '96

Solgate, Inc. 1822 E. First St. Wichita, KS 67214 Tel: (316) 262-3131 Fax: (316) 264-4445 WWW: http://www.solgate.com/~thrasher/jwz/pmmon-2.0/ Email: pmmon(a)solgate.com Wichita, Kansas, November 1996: SolGate, Inc. announces the release of our PMMON 2.0 Terminal Server utility software. This Terminal Server utility software was designed to - --- (truncted) end of original message --- -- Daniel Simms "A common mistake that people make when trying to design dsimms(a)alink.net something completely foolproof [is] to underestimate the (408) 720-6161 ingenuity of complete fools" -Ford Prefect

1 0

PCH routing service (was: CIX routing service)
by William Allen Simpson 06 Nov '96

06 Nov '96

> From: Bill Woodcock <woody(a)zocalo.net> > What you just outlined is exactly what PCH has been doing at MAE-West > for a bit over two years. It works great; extremely low investment, > unmeasurably low flappage, and good fast routes. I'd give unqualified > encouragement to other folks to do exactly the same thing at other > peering points. > I encourage this idea. It wouldn't be useful at the ATM-NAPs, would it? What about transit to other metro exchanges? I thought that PCH was also handling that? Could you give the group details on your model? Will it scale? And then there was the issue of "new ISP education" that we talked about at AA Nanog. PCH does that, too, out of pure self interest (those unmeasurably low flapping rates). A great combination! WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: CIX routing service (was Re: AGIS/DIGEX)
by Bill Woodcock 06 Nov '96

06 Nov '96

Avi Freedman <freedman(a)netaxs.com> writes: > Something like an MLPA, but without even the needed formality. > Basically, a 2501 or 2 or 3 at exchange points acting as route > reflectors might be handy for smaller ISPs who wanted to say > "I'll peer with anyone here to get better connectivity to them". > Since noone with > a few k routes is going to participate, 2501s > will have more than enough memory, and a 2501 can handle 20-30 > such peers without dying when reloaded. And all sessions would > be screened... Good idea! :-) What you just outlined is exactly what PCH has been doing at MAE-West for a bit over two years. It works great; extremely low investment, unmeasurably low flappage, and good fast routes. I'd give unqualified encouragement to other folks to do exactly the same thing at other peering points. -Bill

1 0

Undeliverable Message
by MAILER-DAEMON＠Teleglobe.CA 05 Nov '96

05 Nov '96

To: Cornelies Healy@NET@WAS TGB400@HQSB02@Servers [C=US/A=INTERNET/DDA=ID/pferguso(a)cisco.com] Ismat Pasha@NET@WAS Cc: TGB400@HQSB02@Servers [C=US/A=INTERNET/DDA=ID/nanog(a)merit.edu] Subject: Re: Canadian ISP Code of Conduct Message not delivered to recipients below. VNM3043: Cornelies Healy@NET@WAS

1 0

Small update on CIDR Report
by Tony Bates 05 Nov '96

05 Nov '96

You can now check this on a daily basis via HTML at the following URL http://www.employees.org:80/~tbates/cidr-report.html This is just a very basic translation of the CIDR report I send out once a week but now updated on a daily basis. I will continue to send out the weekly mail updates. I'll be adding more to the Web interface as time permits. For those interested in todays report it highlights a very large leak of almost 1200 routes by AS719 which they wish to take a look at. I'll let others draw their own conclusions from the rest of the data. Regards, --Tony

1 0

Re: 5 NAPs Any savings?
by Rob Liebschutz 04 Nov '96

04 Nov '96

> > Here is the question that occurred to me. > > If we set a requirement to be at 5 NAPs, and we don't peer with anyone > who isn't at 5 NAPs, and we only peer with like 4 networks that qualify, > aren't we essentially talking about using GigaSwitch or ATM switches as > private interconnects? [barring the defaulting issue on FDDI] > > If whole point is to exclude networks due to a number of technical > reasons why go to 5 or 20 NAPs when private connects would serve the same > purpose? Or is it some kind of bragging thing where a network can say "We > went to the time and expense of engineering connections to 5 NAPs and now > no one qualifies for peering with us." Wouldn't the obvious question be, > "Why did you bother then?" For several organizations it isn't the money > that is really a question with multiple NAPs, but the marginal value of > the next NAP after you are already at 3 or 4 whatever is considered > acceptable/comfortable. [Economic theory, sorry] > > Anyone agree? > > -Deepak. > At least one of the organizations that you probably have in mind sells transit over the NAPs. Rob

1 0