- Test - lists.nanog.org

Start-up offers free management tool
by virendra rode // 27 Jul '06

27 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://www.networkworld.com/news/2006/072106-free-management.html?twht=0724… regards, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEySu/pbZvCIJx1bcRAr75AKCbJgg64VgodbRkET1xLC3DThP5HQCglgdj 8/pG+5HCd3rRCtahWYNW8d0= =k7fE -----END PGP SIGNATURE-----

1 0

RE: Ultradns using anycast?
by Jeffrey Sharpe 27 Jul '06

27 Jul '06

Working on it. ------------------------------------------------ Jeffrey Sharpe CyberLynk Network Support 414.858.9335 or 800.942.8022 jsharpe(a)cyberlynk.net ------------------------------------------------ -----Original Message----- From: Sean Leach [mailto:sleach@wiggum.com] Sent: Thursday, July 27, 2006 1:49 PM To: Jeffrey Sharpe Cc: nanog(a)merit.edu Subject: Re: Ultradns using anycast? > On 27-Jul-2006, at 13:11, Jeroen Massar wrote: > >>> Or how to get someone at UltraDNS or PIR to take ownership of a >>> issue and resolve it? Did they take issue and/or resolve it?

1 0

Ultradns using anycast?
by Jeffrey Sharpe 27 Jul '06

27 Jul '06

Does anyone know if Ultradns uses anycast? Or how to get someone at UltraDNS or PIR to take ownership of a issue and resolve it? ------------------------------------------------ Jeffrey Sharpe CyberLynk Network Support 414.858.9335 or 800.942.8022 jsharpe(a)cyberlynk.net ------------------------------------------------

5 5

RE: APC Matrix 5000 question(s)
by Brian Wilson 27 Jul '06

27 Jul '06

>> Hi, >> i am very sure that the batterys are dead. APC recommends to change the >> batterys every 3 to 5 years. I'd change them every 3 years to be sure. >> Its very unlikely that your 6 year old packs are still fully functional. >> I had the same symptoms at a customers APC (3000VA) and the battery >> packs were dead. Try to locate the packs on ebay, can save quite a bunch >> of money (but beware of low quality packs). >> >> > http://stores.ebay.com/Gruber-Power-Services > > I've used them multiple times and been very happy. > > Malcolm I have used them as well and been fairly happy. Beware that they will spam you to death (and responding to their mailings with removal requests continue to go unanswered). Brian

1 0

update bogon routes
by Miguel Mata 27 Jul '06

27 Jul '06

Hi guys and gals, please update your bogon lists to avoid 190.0.0.0/8 that has been asigned to LACNIC as you can see from: http://www.iana.org/assignments/ipv4-address-space http://whois.arin.net/whois/?queryinput=190.5.0.0 We have had some problems of being beaten back. Our space, being annocunced by AS 16592, is 190.5.128.0/19 Thanks for your time. -- Miguel Mata Gerente de Operaciones Intercom El Salvador mmata(a)intercom.com.sv voz: ++(503) 2278-5068 fax: ++(503) 2265-7024 "Intercom, sus Telecomunicaciones en buenas manos"

3 3

Hot weather and power outages continue
by Sean Donelan 26 Jul '06

26 Jul '06

Due to the hot weather in many parts of the US, there have been various power outages. Some large outages have been caused by severe storms, but mostly the heat has just overloaded power distribution equipment. The good news so far is the Net has shown very few disruptions due to the heat and some multi-day power outages. The major ISP access providers have been indicating about average numbers of outages in their networks, i.e. even during "normal" times, there are usually a few tens of thousands of lines down nationwide. While its expected for individual customers to go down during power outages, usually because the customer does not have local backup power, it is less common for major web sites and co-location centers to experience downtime during power outages. MySpace.com reported it was down tonight due to power problems, with a temporary page up now. MySpace.com is hosted at a few Internet co-location data centers (Equinix and CWIE).

12 14

Global Crossing Contact / BGP and SONET interaction question
by Forrest W Christian 26 Jul '06

26 Jul '06

Two somewhat intertwined questions. I'll ask the second part first. I buy transit from Global Crossing and another carrier on HDLC encapsulated DS3's. Recently my BGP session has started flapping on the GX circuit... It looks something like this: Jul 21 21:17:43.731 UTC: %BGP-3-NOTIFICATION: received from neighbor 67.17.168.73 6/6 (cease) 0 bytes Jul 21 21:17:43.731 UTC: %BGP-5-ADJCHANGE: neighbor 67.17.168.73 Down BGP Notification received Jul 21 21:18:25.439 UTC: %BGP-5-ADJCHANGE: neighbor 67.17.168.73 Up Jul 21 21:29:52.315 UTC: %BGP-3-NOTIFICATION: received from neighbor 67.17.168.73 6/6 (cease) 0 bytes Jul 21 21:29:52.315 UTC: %BGP-5-ADJCHANGE: neighbor 67.17.168.73 Down BGP Notification received Jul 21 21:30:38.511 UTC: %BGP-5-ADJCHANGE: neighbor 67.17.168.73 Up Jul 21 21:31:34.411 UTC: %BGP-3-NOTIFICATION: received from neighbor 67.17.168.73 6/6 (cease) 0 bytes Jul 21 21:31:34.411 UTC: %BGP-5-ADJCHANGE: neighbor 67.17.168.73 Down BGP Notification received Jul 21 21:32:20.535 UTC: %BGP-5-ADJCHANGE: neighbor 67.17.168.73 Up Jul 21 21:32:52.547 UTC: %BGP-5-ADJCHANGE: neighbor 67.17.168.73 Down Peer closed the session Jul 21 21:33:32.703 UTC: %BGP-5-ADJCHANGE: neighbor 67.17.168.73 Up There are no other log entries during the periods when this occur. Unfortunately this causes enough prefix flaps that any prefixes which are preferred through GX are damped for like a half hour by certain providers as my BGP routes get added/withdrawn through the GX link. GX claims (although I'm not sure they really know) that these are caused by SONET ring switches. I can believe this, since I haven't seen any real circuit flaps, and my understanding is that a SONET switch should generally be fast enough that you normally won't see the transition other than perhaps an error counter or two cranking up. However, it seems strange that I'm getting a 6/6 (cease) notification which I read as "configuration change" from their router. GX also seems to be at a loss to explain why my BGP is flapping - other than to point at the SONET switches. I guess I'm trying to find out if someone on the list recognizes what this might be so I can perhaps help GX find and fix this. I'm also kinda curious as to whether or not typically a SONET ring switch event would actually propagate into a router in such a way that BGP would try to shut down the BGP sessions. I'm just having a hard time visualizing how a supposedly below-layer-two switch would cause bgp to reset in this manner. Not being a SONET expert even by any long stretch of the imagination leaves me with some holes here, but I thought the whole goal of SONET when used to provide DS3 circuits was to hide the ring switches as much as possible from the DS3 circuits - realizing that framing may be hard to preserve on a ring switch which would cause momentary loss of sync or similar - which usually shows up as an error instead of a interface flap. And finally, does anyone have a contact within GX with a clue? So far I'm not sure I've talked to anyone who knows anything but how to spell BGP. I'd really like to talk to someone about the real cause of these flaps and try to resolve them so they don't reoccur. -forrest

5 5

Eurid suspends more than 74,000 .eu domain names
by Henry Linneweh 26 Jul '06

26 Jul '06

I think this operationally impact some people http://www.computerworld.com/action/article.do?command=viewArticleBasic&art… -Henry

5 5

more on Net Neutrality
by virendra rode // 25 Jul '06

25 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://www.npr.org/templates/story/story.php?storyId=5538363 enjoy :-) regards, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFExk/jpbZvCIJx1bcRAuC9AJ4nmNhEVtv7ONVCn+PPjhxUFXf8ZQCcDtjF Pm8gl8bnMgaG/8iyncwlKMs= =rAxX -----END PGP SIGNATURE-----

1 0

Re: SBC Lost of connectivty to Canada?
by Richard A Steenbergen 25 Jul '06

25 Jul '06

On Mon, Jul 24, 2006 at 09:43:19PM -0400, Valdis.Kletnieks(a)vt.edu wrote: > On Mon, 24 Jul 2006 13:18:42 EDT, Richard A Steenbergen said: > > Actually they just leaked some routes this morning, and blew out max > > prefixes to most peers. Pretty typical as far as accidental leaks go, > > those folks with sensible filtering and running routers which trip on max > > prefixes accepted not prefixes received probably weren't even affected. > > Another day on the internet. > > If I didn't know better, I'd say you were implying that your best bet for > a survivable design is to plan as if your peers listened to Randy Bush on > network design? Not sure what you're referencing there. If Randy said something to the effect of "all peers will screw up and leak something to you eventually, no matter how large or generally well run, so plan accordingly", I would agree with it though. I was suggesting that if even if you don't have the ability to fully prefix or as-path filter every peer (which, face it, most of us with large numbers of interesting peers don't have), you can still filter the really obvious stuff and prevent a large amount of the impact from common fat finger events. I can't tell you the number of problems that are prevented by applying a simple set of as-path filters matching large networks you know you should never hear from your peers (or most of your peers). Something simple like: deny _209_ deny _701_ deny _1239_ deny _1299_ deny _1668_ deny _3320_ deny _3356_ deny _3549_ deny _3561_ deny _5511_ deny _6453_ deny _7018_ Catches a huge amount of "stupid stuff", especially when the event isn't a full blown leak which trips max prefixes, but is an isolated set of prefixes leaked by someone not directly connected to you. On a Cisco, the leaked 7018 routes from 7132 this morning would have been gone splash harmlessly with such a filter, and sessions wouldn't even trip max prefixes and bounce. Unfortunately Juniper has a bit of a backwards take on the use of prefix limits. They believe that the reason to have a prefix limit is to protect a router against memory exhaustion (for example, someone sending you a few million routes that you are rejecting filling up your adj rib in), rather than as a policy tool (shutting down a wildly broken session that is sending you stuff it shouldn't). Juniper applies the max prefixs to routes received from a session rather than routes accepted, so even if the routes are filtered the prefix limit will still trip and shut down the session. This is particularly bad if for example you have a customer session which is fully prefix list filtered, and the customer accidentally leaks you a table. In reality, both types of limits are probabaly a "good idea". I've talked to a lot of people from a lot of companies who say they have requested Juniper add a seperate accepted-prefixes limit (or more likely, convert the existing limits to accepted-prefixes, and add a new received-prefixes knob), but so far it hasn't been implemented. If you are a Juniper customer who is reading this and you think having prefix limits which only count accepted prefixes is a good idea, please use this as an opportunity to submit an enhancement request so we can get this behavior improved. Feel free to throw in a request for "outbound prefix limits" as a last ditch safety net too. :) -- 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