- Test - lists.nanog.org

Barak contact information
by German Martinez 22 Aug '06

22 Aug '06

Hello, Please someone from Barak's routing team contact me off-list Thanks German

2 1

Ikano?
by Drew Weaver 22 Aug '06

22 Aug '06

Anyone else notice ikano.com is completely down? Or is it just me? -Drew

4 3

Wikipedia/Cogent
by Richard A Steenbergen 22 Aug '06

22 Aug '06

So, lets kick this Friday off right... I don't suppose anybody has noticed that Wikipedia is being blackholed by Cogent, and that it seems to be intentional? :) -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

8 12

hp.com contact, please?
by Suresh Ramasubramanian 22 Aug '06

22 Aug '06

Can someone from HP please email me offlist? thanks srs -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

1 0

RE: Amazon?
by Joseph Jackson 22 Aug '06

22 Aug '06

That whois stuff is meaningless. When are people going to get it that it really isn't a "hack". > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Jon R. Kibler > Sent: Monday, August 21, 2006 1:36 PM > To: Elijah Savage > Cc: Brandon Galbraith; nanog(a)nanog.org; Steven M. Bellovin > Subject: Re: Amazon? > > I am currently in the DC area. It appears that Amazon came up > about 20 minutes ago. > > SANS ISC has a little info on the problem. Quoting from > http://isc.sans.org/diary.php?n&storyid=1625 : > > UPDATE: > > > > Diligent Reader Corwin Grey points out: > > > > "Amazon may be having more than a 'little' trouble. :/ > Check out their whois: > > > > > > Server Name: AMAZON.COM.IS.N0T.AS.1337.AS.WWW.GULLI.COM > > IP Address: 80.190.192.24 > > Registrar: KEY-SYSTEMS GMBH > > Whois Server: whois.rrpproxy.net > > Referral URL: http://www.key-systems.net > > > > <snip>" > > > > Now, amazon.com looks OK from a whois lookup at > www.internic.net (record points to Network Solutions) and > from a Network Solutions whois lookup. But, it looks like > we've got some whois database hijinks out there for some of > the whois servers and the www.amazon.com info. > > > > Reader Sean points out that these gulli folks do this kind > of thing a lot to sites like Amazon.com, Microsoft, and > others, and these whois hijinks are likely independent of the > back-end problems that Amazon.com appears to be having. I agree. > > > > I just now checked, and they seem to be back up... so, > intermittent problem fixed? For now... It's not the end of > the world. > > > > --Ed Skoudis > > Intelguardians > > > > Elijah Savage wrote: > > Thats strange I am not having any issues at all and I have > tested it > > from 3 different peering points. > > > > ----- Original Message ----- > > From: Brandon Galbraith <brandon.galbraith(a)gmail.com> > > To: Steven M. Bellovin <smb(a)cs.columbia.edu> > > Cc: Jon R. Kibler <Jon.Kibler(a)aset.com>, nanog(a)nanog.org > > Sent: Monday, August 21, 2006 3:42:21 PM GMT-0500 > > Subject: Re: Amazon? > > > > Intermittent application/load balancer issues perhaps? > > > > -brandon > > > > On 8/21/06, *Steven M. Bellovin* <smb(a)cs.columbia.edu > > <mailto:smb@cs.columbia.edu>> wrote: > > > > > > On Mon, 21 Aug 2006 15:21:40 -0400, "Jon R. Kibler" < > > Jon.Kibler(a)aset.com <mailto:Jon.Kibler@aset.com>> > > wrote: > > > > > Hi, > > > > > > Anyone know what is up with Amazon? They appear to be down. > > > > > > Doesn't appear to be a network issue... tried from > two different > > ISP's networks. > > > > > That's odd. When I try from one path, I get the same > error you get; > > when > > I try another, it works. A tcptraceroute shows that > both are ending > > up at > > the same IP address at Amazon, too. > > > > --Steven M. Bellovin, > > http://www.cs.columbia.edu/~smb > > <http://www.cs.columbia.edu/%7Esmb> > > > > > > > > > > -- > > Brandon Galbraith > > Email: brandon.galbraith(a)gmail.com > > <mailto:brandon.galbraith@gmail.com> > > AIM: brandong00 > > Voice: 630.400.6992 > > "A true pirate starts drinking before the sun hits the > yard-arm. Yarrrr. > > --thelost" > > > > > > > > ================================================== > > Filtered by: TRUSTEM.COM's Email Filtering Service > > http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. > > > > -- > Jon R. Kibler > Chief Technical Officer > Advanced Systems Engineering Technology, Inc. > Charleston, SC USA > (843) 849-8214 > > > > > > ================================================== > Filtered by: TRUSTEM.COM's Email Filtering Service > http://www.trustem.com/ > No Spam. No Viruses. Just Good Clean Email. > >

4 3

Amazon?
by Jon R. Kibler 21 Aug '06

21 Aug '06

Hi, Anyone know what is up with Amazon? They appear to be down. Doesn't appear to be a network issue... tried from two different ISP's networks. This is what you get at http://www.amazon.com/: > We're sorry! > An error occurred when we tried to process your request. Rest assured, we're already working on the problem and expect to resolve it shortly. > > If you were trying to make a purchase, please check Your Account to confirm that the order was placed. > > We apologize for the inconvenience. > > on the Amazon.com home page Anyone know that is going on? Jon Kibler -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA (843) 849-8214 ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.

6 6

Re: BGP unsupported capability code
by Mike White 21 Aug '06

21 Aug '06

I recently implemented BGP graceful restart capability in a custom BGP app and encountered the same notification. By looking at the capabilities being advertised by the router, and advertising various subsets of those capabilities, I narrowed it down to the MPLS capability. It turned out the router deemed MPLS capability as a prerequisite for graceful restart. Adding the MPLS IPv4 unicast capability to the OPEN message along with the graceful restart capability fixed things for me. Hope this helps. - Mike

1 0

Open Source NMS Software
by Gary T. Giesen 21 Aug '06

21 Aug '06

I'm looking at depolying an open source-based NMS solution, and I'm looking at a couple products, mostly OpenNMS (http://www.opennms.org) and Zenoss (http://www.zenoss.org) I like the looks of Zenoss, but I've never really heard of it and I'm wondering if anyone has any experiences with it that they can share before I go and spend hours on an install/configuration. Is there something wrong with it, and that's why I've never heard of anyone using it? Am I just out of the loop? Even better would be someone who's used both products and could give me a quick comparison. I'd also welcome suggestions of another product (as long as it's not bb, nagios, or hobbit) that I should be looking at. Thanks, Gary Giesen

4 3

Cox leaking 128.0.0.0/1
by Richard A Steenbergen 18 Aug '06

18 Aug '06

Seeing as this has been going on for over 2h30m, no one can seem to get ahold of any live bodies who can fix it, and the emails about it to the noc contacts have gone unanswered, I'm reduced to trying the old public embarassment approach... Would Cox please stop announcing 128.0.0.0/1. Thanks. route-views.oregon-ix.net>sh ip bgp 128.0.0.1 BGP routing table entry for 128.0.0.0/1, version 471808 Paths: (14 available, best #14, table Default-IP-Routing-Table) Not advertised to any peer 852 22773 154.11.11.113 from 154.11.11.113 (154.11.11.113) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 852 22773 154.11.98.225 from 154.11.98.225 (154.11.98.225) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 3277 6820 3267 3343 174 174 174 22773 194.85.4.55 from 194.85.4.55 (194.85.4.55) Origin IGP, localpref 100, valid, external Community: 3277:6820 3277:65361 3277:65364 2493 3602 812 22773 206.186.255.223 from 206.186.255.223 (206.186.255.223) Origin IGP, localpref 100, valid, external Community: 812:2 3602:65011 3602:65535 7500 2516 22773 202.249.2.86 from 202.249.2.86 (203.178.133.115) Origin IGP, localpref 100, valid, external 6539 22773 216.18.63.137 from 216.18.63.137 (216.18.63.137) Origin IGP, localpref 100, valid, external 11608 3491 22773 207.246.129.13 from 207.246.129.13 (207.246.129.15) Origin IGP, localpref 100, valid, external Community: 3491:2000 3491:2007 3491:22773 11608:1004 11608:5504 22773:130 22773:60101 22773:64002 22773:64100 22773:64101 7660 2516 22773 203.181.248.233 from 203.181.248.233 (203.181.248.13) Origin IGP, localpref 100, valid, external 1221 4637 22773 203.62.252.26 from 203.62.252.26 (203.62.252.26) Origin IGP, localpref 100, valid, external 3333 1103 1273 22773 193.0.0.56 from 193.0.0.56 (193.0.0.56) Origin IGP, localpref 100, valid, external 8001 22773 209.123.12.51 from 209.123.12.51 (209.123.12.51) Origin IGP, localpref 100, valid, external Community: 8001:3000 8001:3023 8001:6008 22773:130 22773:60101 22773:64002 22773:64100 22773:64101 12956 22773 213.140.32.146 from 213.140.32.146 (213.140.32.146) Origin IGP, localpref 100, valid, external Community: 12956:18500 12956:28200 12956:28201 22773:130 22773:60101 22773:64002 22773:64100 22773:64101 5650 22773 74.40.7.35 from 74.40.7.35 (207.173.112.63) Origin IGP, metric 0, localpref 100, valid, external 5650 22773 74.40.7.36 from 74.40.7.36 (74.40.0.11) Origin IGP, metric 0, localpref 100, valid, external, best Oh and if you are on this list (and therefore accepting that prefix), you may need better filters. :) -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

1 0

BGP unsupported capability code
by Joe Maimon 18 Aug '06

18 Aug '06

If A tries to peer with B, and B sends a BGP capability 64 to A, if A does not support that capability what would proper and/or reasonable behavior for A be? (a "published" source for it, if you could possibly do so.) a) send unsupported capability code 64 lengh 6 ## 2006-08-17 19:17:05 : [bgp/stack]: send NOTIFICATION msg code (Open-Error) subcode(Open Message Error: Unsupported Capability) to peer w9.x4.y7.z9 via socket 415 b) ignore it c) admin defined rfc3392.txt only appears to address the case where if A tries to peer with B, and B sends a BGP capability 64 to A, if A does not support that capability, B MAY terminate the connection with the above notification. (section 3 paragraph 5) Thanks, Joe

3 3