- NANOG - lists.nanog.org

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

AGIS/DIGEX
by Bob Collie 03 Nov '96

03 Nov '96

>From recent discussions on this list, I thought that the reason that DIGEX could not reach AGIS sites (and vice-versa) was because of AGIS's new peering policy, and not because of a circuit disconnection. (from http://agisgate.agis.net/outage.htm) Problems Reaching DIGEX -- UPDATED 10:40 EST October 29, 1996 Digex has disconnected their ANS circuit. We previously saw Digex routes only through ANS (our direct connection with Digex has been gone for a few months now). Since Digex is at too few NAPs to peer with AGIS, and they are not at the CIX, we see no routes from them. -- Bob Collie, Network/Systems Engineer, Telalink Corporation mailto:rmc@telalink.net

14 27

False SYN attacks?
by Hank Nussbacher 03 Nov '96

03 Nov '96

I am curious if other sites have had similar false SYN attacks (this one was reported by BBN and SI.NET to us). Here is the report from the offending site: ------------------------------------------------- As a result of a potential SYN attack that was reported to us and that may have originated from NCC, NCC has held an inquiry with a team lead by myself and including the NC VP for technology, and the NCC Ssytem Administrator and security officer. The Inquiry has found the following facts: NCC Internet connection for all NCC employess relys on a Microsoft Proxy Server code named CataPult (Beta Release) Which runs on an NT machine. It was only installed at NCC several days ago. The product has what it defines as a smart cache which decides itself to go fetch via HTTP updates of information on the Internet according to URL addresses it finds in its cache (which are more likely to be visited once again). This in theory provides improved performance for users browsing the Internet. The default update frequency value in this Beta release was set by Microsoft to be way too low ( a matter of seconds).Once a certain site in the cache is too busy and the Proxy Server fails to make the connection (like in this case when www.wellsfargo.com failed with cause 10060 connection timeout), the Proxy tries again. It is easy to distinguish on the log between a connection request made by a uset via a connection attempt made by CataPult Proxy Server. We are attaching two files which are the log that shows all activity on Oct 24th (file a.a) and all specific connection attampts to wells fargo(file b.b). We did chnage the timoout for this retry attempt to be much higher than the 1 minute value that was configured by default by Microsoft. -------------------------------------------------------------- Have other sites been using Catapault and seeing this problem? Hank

1 0

Re: AGIS v BBN
by Peter Kline 02 Nov '96

02 Nov '96

AGIS upgraded its router at the Sprint NAP to an RSP (from SP/SSP), and at the same time had to upgrade the FDDI interface. It hasn't really worked right since. It turns out through experimentation, any return traffic coming through Pennsauken dies on that router. So we've essentially taken the Sprint NAP router off the net while we figure out what's wrong. [That, by the way, is why it's so important to see as many networks in as many places as possible.] We've spent the time since try to determine if we have: - a FDDI problem - an RSP problem - an undesirable SMDS/IOS interaction (we use SMDS to get into Pennsauken from our net) - some other undesireable hardware/IOS interaction - routing or other configuration on the Pennsauken router - routing or other configuration on any other router I'll let you know what we find out. We've pretty much eliminated routing or FDDI, and are looking at SMDS/IOS or some other config issue. Peter BTW: when Kent's traceroute failed, that particular address was also unreachable from other nets. At 01:16 PM 11/1/96 -0500, Pritish Shah wrote: >this is not due to AGIS vs BBN. This is plain and simple BBN that is not >ok. As the response from one of the bbnplanet employee, the DNS is setup >but there is not machine at that location. > >Pritish > >On Fri, 1 Nov 1996, Kent W. England wrote: > >> Folks; >> >> It appears that routes to BBN via AGIS aren't working but others are. Is >> this true? Perhaps we should start an AGIS Peering Woes List? >> >> 1) Digex >> 2) BBN Planet >> 3) ?? >> >> --Kent >> >> > > >

2 1