- Test - lists.nanog.org

IBGP problem concerning more specific routes
by Pascal Petit - SYNET 03 Dec '97

03 Dec '97

Here is an amusing BGP problem : Wild Wolrd-----------R1--------------R2------Our Networks There is an IBGP sesion running between R1 and R2. R2 advertises route 194.214.0.0/16 to R1. In our block there is a class C used by one of our customer which is not directly connected to our network. This customer advertises its class C to the Wild World via its own ISP. R1 receives the 194.214.253.0/24 advertisement from the Wild World, it stores it in its routing table; however R2 never takes it into account : its routing table only mentions 194.214.0.0/16 , it doesn't mention the more specific routing entry 194.214.253.0/24. Our Networks cannot get to 194.214.253.0/24. Is it a feature of IBGP ?? Thanks for any help, Pascal ------------------------------------------------------------------------ Pascal Petit SYNET tel: 33 1 4696 0040 74, rue Roque de Fillol fax: 33 1 4696 0041 92800 Puteaux email: ppetit(a)synet.fr FRANCE http://www.synet.fr

2 1

Re: caching at windmills (i mean exchange points)
by Duane Wessels 03 Dec '97

03 Dec '97

Ton Verschuren writes: >I know. Still, for a cache to fill it has to fetch docs and thus act as >a parent. If the NLANR cache acts as a parent for all MW connected >ISP's than *all* misses from those ISP's get routed through the NLANR >cache and for the transatlantic traffic the lines of NLANR's ISP will >fill up. No? In order for the cache to fill, yes some MW customers will need to call the cache a parent. Some could call the cache a sibling. However, it isn't so black-and-white as that. Squid can be configured to measure RTTs to origin servers. Squid's ICP replies will include the RTT estimations, and the child cache can compare these values to its own measurements, or those made by other (parent) caches. Additionally, for the MW cache, we have modified Squid to return an ICP_MISS_NOFETCH reply for requests origin servers which appear to be unreachable (presumably due to incomplete routing info). Upon receiving this reply, the child cache will not forward the request to us. Thus, a child cache can use our MW cache as a parent only for origin servers which are reachable by us, and which our cache is "closer" to. If the child cache is closer, then it will forward the request directly. A potential problem is that the RTT measurement feature is not compiled in by default. It requires building Squid with a macro defined, and installing the ICMP sending/receiving program with root privs. A few more details can be found at http://squid.nlanr.net/Squid/FAQ/FAQ-7.html#ss7.6 Duane W. -- wessels(a)nlanr.net Think Globally, Cache Locally.

2 1

Re: Horrible Service Agreements
by Adrian Chadd 02 Dec '97

02 Dec '97

On Tue, 2 Dec 1997, Vadim Antonov wrote: > Adrian Chadd <adrian(a)ourworld.net> wrote: > > > Erm, say you put your address on a webpage. > > Or post it to USENET. Better yet, write your home telephone, > address and social security number so every bozo can visit you > or steal your credit. [snip] I hope you realise I meant email address here. :-) This isn't relevant to NANOG I agree, so I'll be brief. Then I'll shut up :) Why should I waste my time having to implement anti-spam measures when it isn't fully effective anyway? Not everyone does it, so its not completely worth it. People have a habit of finding holes and back doors in protocols, programs, and I'm pretty sure any system brought in to effectively kill spam would either be so restrictive it becomes a pain in the butt to use, or its just 'broken' and people find a way to spam through it. Makes it all worthless. Although there ARE loophools in legalese, these are generally harder to find, and the penalties involved would deter most people from spamming. So IMHO, its really a question of which one BEST solves the problem QUICKEST. if you can get everyone to fix their mailer agents to do the anti-spam thing, or rush in a new mail protocol, hell.. feel free. I certainly don't have the time on my hands to keep rooting around upgrading mail agents to support new protocols, or anti spam stuff, etc, etc... Adrian (who really shouldn't be posting to email lists as much as he has been lately.. :-)

1 0

Re: Horrible Service Agreements
by Brian Horakh 02 Dec '97

02 Dec '97

First off I think this topic should be moved to another list.. it isn't appropriate for NANOG... but since i'm writing this message i'll put in my two cents. >Cryptography can be used to produce non-transferrable keys >allowing some party to send message to a particular recipient. >Messages can include "right to respond" keys. That is a cute idea, you can only email somebody who has emailed you first, unless of course (for example) you both like to go ostrich hunting then you can email any fellow ostrich hunters. Of course if it doesn't actually solve the problem, just makes it really inconvenient to get a list of all the other ostrich hunters out there so I can sell ostrich hunting supplies. All I have to do is find a message board about ostrich hunting and send 'em all some good ole' spam. Perhaps the legal approach of holding an ISP responsible is a more appropriate (and much more easily accepted method). Let me ask you... Which one is a easier measure, creating legal teeth which ISP's can use against spamming or getting every vendor who produces a SMTP mail product to upgrade to some new Secure-SMTP protocol? Keep in mind it would take the IETF at least 2 or 3 years before they could even agree on a standard (and that's if Microsoft Exchange div. didn't have their goons on the committee). So by the year 2001 we have a Secure-SMTP mail product that is an IETF standard, now the conversion process... lets be optimistic 1-2 years.. The year is now 2003 ... What sane company would stop receiving non-secure SMTP mail from potential customers? Do you honestly think that all the ISP's in the country are going to stop delivering non-authenticated mail? I can just picture tech support "i'm sorry Granny, you can't receive email from little Johnny who's gone off to colleg! e anymore because he's not considered trustworthy." .. The Internet doesn't move quick enough to get changes like that implemented within the system, its grown to large, to fast, and is much to rigid. If you don't believe me just look at UUCP (which I think can officially be declared dead? How many sendmail.cf's still allow user!domain(a)smtp.relay.com) If the government takes the time to give ISP's tools to stop the people/companies it will stop 99.9% of the people out there, you will still get the occasional person who will not remove you from a list, or snag addresses from mechanisms such as Usenet and the www. However that .1% won't even be enough to get mentioned on a list such as NANOG. Laws that have harsh punishments, and require financial restitution, combined with the ability to trace back to a specific USER and/or company will almost 99.9% spam free net. It is the ISP's responsibility to respond quickly to user feedback (even from foreign systems), and to properly configure their mailers to be used to relay non-returnable messages. Companies like hotmail, and rocketmail must take measures to make sure their customers are not performing these types of actions (possibly making it more difficult to get accounts, and getting restraining orders on regular offenders). I'm sure as the problem continues to escalate at the phenomenal rate it has lately this problem will solve itself as the companies who COULD stop the problematic users, will begin to find their staff time being consumed, and reputations being sullied. Just my two cents, -Brian Horakh Network Systems Engineer City of Escondido, CA. !

1 0

Re: The Year of the Backhoe Continues...
by Randy Bush 02 Dec '97

02 Dec '97

do people really think that the relative fiber cut rate is any higher than in the past? there's a bit more fiber, hence the term 'relative'. but i suspect that the predominant factor is that new victims have a better means of broadcasting their displeasure. randy

4 3

Router problems between 'psp.sk.canet.ca' and 'regional1.sk.canet.ca'
by James Philpott 01 Dec '97

01 Dec '97

See attached trace route for clarity. This is taken from my IP address of 204.29.28.142 while trying to reach 207.195.95.27. As of hop 11 all goes well and then a game of packet Ping-Pong ensues between psp.sk.canet.ca [192.68.63.1] and regional1.sk.canet.ca [192.68.63.101]. Any assistance would be appreciated. This message was already forwarded to 'canet-eng(a)canet.ca'. Regards, James Philpott <><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><> James Philpott jamesp(a)metainfo.com MetaInfo (206)674-3746 http://www.metainfo.com/support/onlineresources.htm <><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><> Sending 48 data bytes to ? [207.195.95.27] 1:Received echo from ? [204.29.28.253] in 0 msec. 2:Received echo from ? [204.29.28.254] in 10 msec. 3:Received echo from milo-s7.wa.com [198.202.20.5] in 10 msec. 4:Received echo from dilbert-fe4-0.wa.com [192.135.191.254] in 170 msec. 5:Received echo from dogbert.nwnexus.com [206.63.0.254] in 20 msec. No data received from intermediate hop. 7:Received echo from core2-fddi-1.Seattle.mci.net [204.70.203.65] in 40 msec. No data received from intermediate hop. 9:Received echo from canet.Seattle.mci.net [166.48.217.254] in 50 msec. 10:Received echo from psp2.bc.canet.ca [205.207.238.133] in 20 msec. 11:Received echo from psp.sk.canet.ca [205.207.238.26] in 50 msec. 12:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 13:Received echo from psp.sk.canet.ca [192.68.63.1] in 61 msec. 14:Received echo from regional1.sk.canet.ca [192.68.63.101] in 60 msec. 15:Received echo from psp.sk.canet.ca [192.68.63.1] in 60 msec. 16:Received echo from regional1.sk.canet.ca [192.68.63.101] in 60 msec. 17:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 18:Received echo from regional1.sk.canet.ca [192.68.63.101] in 80 msec. 19:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 20:Received echo from regional1.sk.canet.ca [192.68.63.101] in 81 msec. 21:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 22:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 23:Received echo from psp.sk.canet.ca [192.68.63.1] in 80 msec. 24:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 25:Received echo from psp.sk.canet.ca [192.68.63.1] in 90 msec. 26:Received echo from regional1.sk.canet.ca [192.68.63.101] in 80 msec. 27:Received echo from psp.sk.canet.ca [192.68.63.1] in 81 msec. 28:Received echo from regional1.sk.canet.ca [192.68.63.101] in 90 msec. 29:Received echo from psp.sk.canet.ca [192.68.63.1] in 80 msec. 30:Received echo from regional1.sk.canet.ca [192.68.63.101] in 90 msec. 31:Received echo from psp.sk.canet.ca [192.68.63.1] in 130 msec. TraceRoute Statistics for 207.195.95.27 31 packets transmitted, 28 packets received, 9% packet loss round-trip (ms) min/avg/max = 0/65/170

1 0

Router problems between 'psp.sk.canet.ca' and 'regional1.sk.canet.ca'
by James Philpott 01 Dec '97

01 Dec '97

See attached trace route for clarity. This is taken from my IP address of 204.29.28.142 while trying to reach 207.195.95.27. As of hop 11 all goes well and then a game of packet Ping-Pong ensues between psp.sk.canet.ca [192.68.63.1] and regional1.sk.canet.ca [192.68.63.101]. Any assistance would be appreciated. Regards, James Philpott <><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><> James Philpott jamesp(a)metainfo.com MetaInfo (206)674-3746 http://www.metainfo.com/support/onlineresources.htm <><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><> Sending 48 data bytes to ? [207.195.95.27] 1:Received echo from ? [204.29.28.253] in 0 msec. 2:Received echo from ? [204.29.28.254] in 10 msec. 3:Received echo from milo-s7.wa.com [198.202.20.5] in 10 msec. 4:Received echo from dilbert-fe4-0.wa.com [192.135.191.254] in 170 msec. 5:Received echo from dogbert.nwnexus.com [206.63.0.254] in 20 msec. No data received from intermediate hop. 7:Received echo from core2-fddi-1.Seattle.mci.net [204.70.203.65] in 40 msec. No data received from intermediate hop. 9:Received echo from canet.Seattle.mci.net [166.48.217.254] in 50 msec. 10:Received echo from psp2.bc.canet.ca [205.207.238.133] in 20 msec. 11:Received echo from psp.sk.canet.ca [205.207.238.26] in 50 msec. 12:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 13:Received echo from psp.sk.canet.ca [192.68.63.1] in 61 msec. 14:Received echo from regional1.sk.canet.ca [192.68.63.101] in 60 msec. 15:Received echo from psp.sk.canet.ca [192.68.63.1] in 60 msec. 16:Received echo from regional1.sk.canet.ca [192.68.63.101] in 60 msec. 17:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 18:Received echo from regional1.sk.canet.ca [192.68.63.101] in 80 msec. 19:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 20:Received echo from regional1.sk.canet.ca [192.68.63.101] in 81 msec. 21:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 22:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 23:Received echo from psp.sk.canet.ca [192.68.63.1] in 80 msec. 24:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 25:Received echo from psp.sk.canet.ca [192.68.63.1] in 90 msec. 26:Received echo from regional1.sk.canet.ca [192.68.63.101] in 80 msec. 27:Received echo from psp.sk.canet.ca [192.68.63.1] in 81 msec. 28:Received echo from regional1.sk.canet.ca [192.68.63.101] in 90 msec. 29:Received echo from psp.sk.canet.ca [192.68.63.1] in 80 msec. 30:Received echo from regional1.sk.canet.ca [192.68.63.101] in 90 msec. 31:Received echo from psp.sk.canet.ca [192.68.63.1] in 130 msec. TraceRoute Statistics for 207.195.95.27 31 packets transmitted, 28 packets received, 9% packet loss round-trip (ms) min/avg/max = 0/65/170

1 0

Re: Horrible Service Agreements
by Brian Horakh 01 Dec '97

01 Dec '97

>Cryptography can be used to produce non-transferrable keys >allowing some party to send message to a particular recipient. >Messages can include "right to respond" keys. That is a cute idea, you can only email somebody who has emailed you first, unless of course you both like to go ostrich hunting then you can email any fellow ostrich hunters. Of course if i'm a good ole spamming sportin goods store, this is a really convenient way to get a list of all the other ostrich hunters out there so I can sell ostrich hunting supplies. All I have to do is find a message board about ostrich hunting and send 'em all some good ole' spam. Perhaps the legal approach of holding an ISP responsible is a more appropriate (and much more easily accepted method). Let me ask you... Which one is a easier measure, creating legal teeth which ISP's can use against spamming or getting every vendor who produces a SMTP mail product to upgrade to some new Secure-SMTP protocol? Keep in mind it would take the IETF 2 or 3 years before they could even agree on a standard (and that's if Microsoft Exchange div. didn't have their goons on the committee). So by the year 2001 we have a Secure-SMTP mail product that is an IETF standard, now the conversion process... lets be optimistic 1-2 years.. The year is now 2003 ... What sane company would stop receiving non-secure SMTP mail from potential customers? Do you honestly think that all the ISP's in the country are going to stop delivering non-authenticated mail? I can just picture tech support "i'm sorry Granny, you can't receive email from little Johnny who's gone off to college anymore! ! ! because he's not considered trustworthy." .. The Internet doesn't move quick enough to get changes like that implemented within the system, its grown to large, to fast, and is much to rigid. If you don't believe me just look at UUCP (which I think can officially be declared dead? How many sendmail.cf's still allow user!domain(a)smtp.relay.com) If the government takes the time to give ISP's tools to stop the people/companies it will stop 99.9% of the people out there, you will still get the occasional person who will not remove you from a list, or snag addresses from mechanisms such as Usenet and the www. However that .1% won't even be enough to get mentioned on a list such as NANOG. Laws that have harsh punishments, and require financial restitution, combined with the ability to trace back to a specific USER and/or company will almost 99.9% spam free net. It is the ISP's responsibility to respond quickly to user feedback (even from foreign systems), and to properly configure their mailers to be used to relay non-returnable messages. Companies like hotmail, and rocketmail must take measures to make sure their customers are not performing these types of actions (possibly making it more difficult to get accounts, and getting restraining orders on regular offenders). I'm sure as the problem continues to escalate at the phenomenal rate it has lately this problem will solve itself as the companies who COULD stop the problematic users, will begin to find their staff time being consumed, and reputations being sullied. Just my two cents, -Brian Horakh Network Systems Engineer City of Escondido, CA. ! ! !

1 0

NANOG-POST switchover
by Susan R. Harris 01 Dec '97

01 Dec '97

Greetings - just wanted to let you know that we've cut over to the new NANOG posting process. In order to post to NANOG(a)merit.edu, you must also be subscribed to NANOG-POST(a)merit.edu. To subscribe, send e-mail to majordomo(a)merit.edu with 'subscribe nanog-post' (without the quotes) as the text of the message. You will receive a confirmation request; once you respond, you'll be able to post to the NANOG mailing list. --Susan Harris

1 0

Re: User-level ISP performance measurement
by Scott Huddle 01 Dec '97

01 Dec '97

John, Check out Inverse Network Technology. http://www.inversenet.com -scott > From owner-nanog(a)merit.edu Mon Dec 1 15:15 EST 1997 > Date: Mon, 1 Dec 1997 14:50:29 -0500 (EST) > From: John R Levine <johnl(a)iecc.com> > To: nanog(a)merit.edu > Subject: User-level ISP performance measurement > MIME-Version: 1.0 > Sender: owner-nanog(a)merit.edu > Content-Type> : > TEXT/PLAIN> ; > charset=US-ASCII> > Content-Length: 1422 > > I hope I'm not reopening a huge can of worms here, but ... > > Some of my relatives have started a small ISP in western Vermont. (They > already run the local telco.) They're wondering how to compare the > performance that their users see to the ISPs in the adjacent town. I told > them that there isn't anything published that'll be of much use, since the > stuff I've seen tries to measure backbone performance and for the most part > does so ineptly. > > For user level stuff, it seems to me that you could pick a representative set > of actions (visit large and small web sites, download e-mail, scan > newsgroups), dial in via PPP every hour for a week being sure to flush out > caches and otherwise start from a consistent user state, do the actions, time > them all, and make some simple stats. This would be miserable to do > manually, but pretty straightforward to do automatically. Is there anything > available, either as a product or service, that does this sort of analysis? > > One of the other hats I wear is as a director of a software testing tools > company, and we could certainly whip up this kind of stuff in no time using > our existing products if there were a demand for it. > > Regards, > John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet for Dummies", > Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner > Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47 > >

1 0