- Test - lists.nanog.org

Re: any known users of NetRange 172.16.0.0 - 172.31.255.255
by Tony Rall 27 Sep '02

27 Sep '02

On Thursday, 2002-09-26 at 20:42 AST, hostmaster <hostmaster(a)nso.org> wrote: > I have this very odd email address found with one of our employees.... > <hidden_user(a)172.17.0.1> > > Here's my questions: > > - Given that 1918 deals with allocation issues for "private Internets", is > there a recording entity of this special address space beyond the formal > IANA, which details the distribution of data from any "private Internet" > once it enters the public Internet vice versa ? > > - Whom to anyone's knowledge is known to be using (for special projects) or > perhaps misusing this 172.17.0.1 ? This mail is likely from a spammer or (even more likely) from a misconfigured sender behind a NAT gateway. There are lots of folks using addresses in this range on the private nets; some of it, unfortunately leaks to the Internet (all to no good). Tony Rall

2 1

RE: AP IX locations
by James Spenceley 26 Sep '02

26 Sep '02

|Given the enormous scope of the question, the US west coast almost |sounds like an effective common denominator *regardless* of the |state of interconnection within the region, or the history of |US-centric traffic demand and under-sea cable routes. PAIX alone can supply 10-15k of AP routes, coupled with AP routes from ABOV and others, that would be most it. No matter where you are located in AP, its going to be a long and difficult build to get a similar level of routes from within the region. Now if you coming from Europe it would make even less sense. -- James

1 0

MPLS as a protection mechanism
by Marian Stasney 26 Sep '02

26 Sep '02

I read the thread on NANOG about MPLS in Metro Networks and the replies danced around this issue but didn't address it directly. I'd like to know if anyone is/is considering using MPLS as a Layer 1 or Layer 2 protection mechanism, whether alone or in combination with other protection mechanisms. By "protection", I am referring to resiliency similar to SONET wrapping. Would it allow the sale of different levels of protection for individual data streams? If so or if not, please contact me off-list and I'll post the compiled replies (if any). Marian Stasney Managing Partner Telecom Inquiry Solutions mstasney(a)telecominquiry.com Ofc: 512-295-4410 Cell: 512-845-1546

1 0

RE: False-alarm generator
by Todd, John 26 Sep '02

26 Sep '02

As it turns out, the NCS has an RFI out on the street looking for input of just this sort. See it at <https://www.ditco.disa.mil/dcop/Public/ASP/requirement.asp?req_no=NCS_RFI>. We would love to hear from you all! JW

1 0

UUnet routing "problem"
by Sorin CONSTANTINESCU 26 Sep '02

26 Sep '02

Hi, This morning we've discovered that one of our IP's was routed somewhere towards an ALTER.NET customer. All the "experiments" i'm going to show you are done from route-server.exodus.net. a show ip bgp 193.231.236.41 show that the originator of the IP Block from where 193.231.236.41 belongs is AS8708 (RDSNET ROMANIA). BGP routing table entry for 193.231.224.0/20, version 4439795 Paths: (8 available, best #1) Not advertised to any peer 3561 701 702 8708, (aggregated by 8708 193.231.191.33) 209.1.40.63 from 209.1.40.63 (209.1.40.63) Origin IGP, localpref 1000, valid, internal, atomic-aggregate, best 3561 701 702 8708, (aggregated by 8708 193.231.191.33) 209.1.40.129 from 209.1.40.129 (209.1.40.129) Origin IGP, localpref 1000, valid, internal, atomic-aggregate 3561 701 702 8708, (aggregated by 8708 193.231.191.33) 209.1.220.242 from 209.1.220.242 (209.1.220.242) Origin IGP, localpref 1000, valid, internal, atomic-aggregate 3561 701 702 8708, (aggregated by 8708 193.231.191.33) 209.1.220.134 from 209.1.220.134 (209.1.220.134) Origin IGP, localpref 1000, valid, internal, atomic-aggregate 3561 701 702 8708, (aggregated by 8708 193.231.191.33) 209.1.40.141 from 209.1.40.141 (209.1.40.141) Origin IGP, localpref 1000, valid, internal, atomic-aggregate 3561 701 702 8708, (aggregated by 8708 193.231.191.33) 209.1.220.7 from 209.1.220.7 (209.1.220.7) Origin IGP, localpref 1000, valid, internal, atomic-aggregate 3561 701 702 8708, (aggregated by 8708 193.231.191.33) 209.1.220.7 from 209.1.220.84 (209.1.220.7) But, somewhere on the way, route-server.exodus.net>tr 193.231.236.41 Type escape sequence to abort. Tracing the route to FuckingLiveShow.home.ro (193.231.236.41) 1 dcr01-p0-1.sntc08.exodus.net (209.1.169.182) 0 msec 0 msec 0 msec 2 ibr01-g0-0.sntc08.exodus.net (66.35.194.197) 0 msec 0 msec 0 msec 3 dcr2-so-3-0-0.SantaClara.cw.net (208.172.156.197) [AS 3561] 0 msec 0 msec 4 msec 4 agr3-so-2-0-0.SantaClara.cw.net (208.172.156.138) [AS 3561] 4 msec agr4-so-6-0-0.SantaClara.cw.net (208.172.156.158) [AS 3561] 0 msec agr3-so-2-0-0.SantaClara.cw.net (208.172.156.138) [AS 3561] 4 msec 5 acr1-loopback.SanFrancisco.cw.net (206.24.210.61) [AS 3561] 4 msec 4 msec 4 msec 6 bpr2.SanJoseEquinix.cw.net (206.24.210.27) [AS 3561] 4 msec 4 msec 8 msec 7 cable-and-wireless-peering.SanJoseEquinix.cw.net (208.173.55.2) [AS 3561] 4 msec cable-and-wireless-peering.SanJoseEquinix.cw.net (208.173.55.46) [AS 3561] 224 msec cable-and-wireless-peering.SanJoseEquinix.cw.net (208.173.55.2) [AS 3561] 4 msec 8 POS2-0.XR2.SJC7.ALTER.NET (152.63.56.166) [AS 701] 8 msec 4 msec 4 msec 9 POS5-0.XR2.SJC1.ALTER.NET (152.63.52.141) [AS 701] 8 msec 4 msec 4 msec 10 0.so-0-0-0.XL2.SJC1.ALTER.NET (152.63.55.126) [AS 701] 8 msec 4 msec 4 msec 11 0.so-3-0-0.TL2.SAC1.ALTER.NET (152.63.54.10) [AS 701] 8 msec 8 msec 8 msec 12 0.so-4-0-0.TL2.DCA6.ALTER.NET (152.63.10.61) [AS 701] 84 msec 84 msec 84 msec 13 0.so-6-0-0.XL2.DCA6.ALTER.NET (152.63.38.74) [AS 701] 88 msec 88 msec 88 msec 14 0.so-7-0-0.XR2.DCA6.ALTER.NET (152.63.38.90) [AS 701] 88 msec 88 msec 88 msec 15 284.at-2-0-0.CL2.IAD5.ALTER.NET (152.63.35.58) [AS 701] 88 msec 88 msec 92 msec 16 501.ATM5-0.GW5.IAD5.ALTER.NET (152.63.43.141) [AS 701] 92 msec 92 msec 88 msec 17 xa-gw2.customer.alter.net (157.130.13.70) [AS 701] 120 msec 92 msec 92 msec 18 s1.home.ro (193.231.236.41) [AS 8708] 92 msec 92 msec 92 msec route-server.exodus.net> Has anyone ever experienced this kind of problems? We've written to UUNET Europe, and they've answered to us that it's a problem at UUNET USA. It's been almost 8 hours since they replied to us, but the problem persists. PS: If there are any technicians from UUNET on this list, please give us a hand. Thank you, --- Sorin Constantinescu Tel: +402 13 010 850 Network Administrator Fax: +402 13 010 892 RDS Bucharest Email: adonay(a)rdsnet.ro Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such a case, you should destroy this message and kindly notify the sender by reply e-mail.

5 4

DDoS/Backbone Security presentations
by Nicolas FISCHBACH 26 Sep '02

26 Sep '02

Hi, If it's of any interest, the slides from my SwiNOG-5 presentation on DDoS (attacks, detection, protection, etc) are available: http://www.securite.org/presentations/ddos/ Some "older" slides from BH US'02 on "IP Backbone Security" are also available (PPT'97 and PDF): http://www.securite.org/presentations/secip/ Nico. -- Nicolas FISCHBACH (nico(a)securite.org) <http://www.securite.org/nico/> IP Engineering Manager - COLT Telecom AG Securite.Org Team <http://www.securite.org/>

1 0

Sprint (1239) blackhole ? Or bogus /32 route ?
by Mike Tancsa 26 Sep '02

26 Sep '02

Hi, I am trying to figure out if either sprint (as1239) has blackholed a single IP address in my network or something strange is up. If anyone has transit connectivity to AS1239, can you tell me if Sprint is sending 199.212.134.9/32 as a prefix ?? e.g. from as1239's website looking glass http://oxide.sprintlink.net/cgi-bin/glass.pl (only a traceroute interface) sl-bb20-ana>trace 199.212.134.9 Type escape sequence to abort. Tracing the route to smtp2.sentex.ca (199.212.134.9) 1 * * * Yet, on that same subnet all else is fine sl-bb20-ana>trace 199.212.134.1 Type escape sequence to abort. Tracing the route to ns.sentex.ca (199.212.134.1) 1 sl-bb22-ana-14-0.sprintlink.net (144.232.1.177) 4 msec sl-bb23-fw-10-2.sprintlink.net (144.232.18.241) 24 msec sl-bb22-ana-14-0.sprintlink.net (144.232.1.177) 0 msec 2 sl-bb25-chi-6-0.sprintlink.net (144.232.9.25) 56 msec sl-bb22-fw-10-1.sprintlink.net (144.232.9.250) 24 msec sl-bb25-chi-6-0.sprintlink.net (144.232.9.25) 52 msec 3 sl-bb22-chi-11-0.sprintlink.net (144.232.18.121) 48 msec sl-bb25-chi-15-0.sprintlink.net (144.232.26.82) 52 msec sl-bb22-chi-11-0.sprintlink.net (144.232.18.121) 44 msec 4 sl-gw33-chi-10-0.sprintlink.net (144.232.26.42) 52 msec sl-gw33-chi-9-0.sprintlink.net (144.232.26.22) 60 msec sl-gw33-chi-10-0.sprintlink.net (144.232.26.42) 48 msec 5 sl-splk-telus-1-0.sprintlink.net (144.223.35.30) 48 msec 52 msec 48 msec 6 chcnil23gr01.bb.telus.com (154.11.11.90) [AS 852] 48 msec chcnil23gr01.bb.telus.com (154.11.11.94) [AS 852] 48 msec chcnil23gr01.bb.telus.com (154.11.11.90) [AS 852] 48 msec 7 toroonxnbr00.bb.telus.com (154.11.11.5) [AS 852] 56 msec 64 msec 56 msec 8 toroonzddr00.bb.telus.com (154.11.6.67) [AS 852] 64 msec 56 msec 64 msec 9 peer.toroonzddr00.bb.telus.com (209.115.141.5) [AS 852] 60 msec 64 msec 64 msec 10 iolite.sentex.ca (209.112.4.3) [AS 15290] 64 msec 60 msec 64 msec 11 ns.sentex.ca (199.212.134.1) [AS 11647] 64 msec 64 msec 60 msec sl-bb20-ana> I am guessing a blackhole, but I dont see where they told me or what list that IP address is on... www.openrbl.org shows clean and all the box does is outbound smtp... Anyone else see strange things like this ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

2 5

False-alarm generator
by Sean Donelan 26 Sep '02

26 Sep '02

How does the government know when the public telephone network is down? They call AT&T. How does the government know when the Internet is down? They pay contractors lots of money to put colored maps on the wall. http://www.fcw.com/fcw/articles/2002/0923/web-ncs-09-26-02.asp In other words, much the same thing several thousand ISP NOCs do all the time with their own systems. Some ISPs also provider their customers with outage notification through e-mail, web sites and fax. The big difference is having someone with the expertise and background to analyze the data, to tell the difference between "normal" Internet problems and "real" Internet problems. Things turn "red" on the Internet all the time, it was designed that way. Unfortunately, this seems to be the government version of Netmedic or Zonealarm. Too many false-alarms and lack of useful information for network operators. Why do ISPs want to provide free consulting advice to debug why a government map turned red today? If it is like Zonealarm or Netmedic, most of the "alarms" are due to problems with the customer's application. If the government is interested in Internet outages, why not just subscribe to ISP outage lists and hear the story direct from the source. Or buy a 56K to T1 connection to many different ISPs in various parts of the country. ISPs don't like debugging non-customer problems, but they will at least glance at customer reported problems. Personal opinion only.

2 1

Security/operations roles/interactions
by Pete Kruckenberg 26 Sep '02

26 Sep '02

I have the opportunity to redefine some roles of our Network Security group and Operations group. More specifically, Operations want to be more involved in day-to-day security activities like incident management and security monitoring. The goal is to make both groups more effective and valuable to our customers (and each other). I realize that solution will be specific to our organization and how we do business. But I hope to have a head-start and hopefully avoid some mistakes. It would be helpful to hear from the list how these groups seem to work best together and what division of labor has worked best to "leverage" their particular strengths. Private responses welcomed, and I'd be happy to report back to the list if there is interest in the results. Pete.

1 0

Good Aricle on Restoration of 140 West Street
by Frank Coluccio 25 Sep '02

25 Sep '02

http://lw.pennnet.com/Articles/Article_Display.cfm? Section=Articles&Subsection=Display&ARTICLE_ID=152426

1 0