May 2010 - Test - lists.nanog.org

Extended outage at Vitelity / XO?
by Graham Freeman 21 May '10

21 May '10

Hi, folks, All 30 of the DIDs I have at one of VOIP providers, Vitelity.net, have been offline for more than 8 hours as of this writing. Vitelity quickly acknowledged the problem, and are characterizing this as a "global DID outage" at XO Communications, affecting "over 100,000 of [Vitelity's] DIDs alone and many others throughout [XO's] network." Now, I know major outages do happen, and service with Vitelity has been generally good, but 8 hours and counting is pretty awful. I'm worried that this may in fact be the result of a contract dispute of some kind between Vitelity and XO, and, if so, that this may be an even bigger problem for me than it already is. Can anyone else confirm Vitelity's report of widespread outages with XO? thanks, Graham

2 1

IPv4 Multicast
by Rens 21 May '10

21 May '10

Hi all, I would like to setup a multicast server sending out some streams and having 10-50 receivers at one location across an existing IP backbone. Here is the setup: Receivers <=> Cisco 3560G <=> Cisco 7206VXR <=> IP BACKBONE (OSPF & BGP) <=> Cisco 7206VXR <=> Cisco 4503 <=> streaming server Does anyone have any configuration examples for this or tutorials, everything on the net seems way to complex for my needs. Regards, Rens

4 5

[OT]Bounce Back
by James Bensley 20 May '10

20 May '10

Got the below message back from Hotmail when emailing a friend I email every week. I have never experienced this particular error before, is this just an indication of high traffic between Google Mail and Hotmail? ---------- Forwarded message ---------- From: Mail Delivery Subsystem <mailer-daemon(a)googlemail.com> Date: 18 May 2010 23:06 Subject: Delivery Status Notification (Delay) To: me This is an automatically generated Delivery Status Notification THIS IS A WARNING MESSAGE ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. Delivery to the following recipient has been delayed: xxxxxxx(a)hotmail.co.uk Message will be retried for 2 more day(s) Technical details of temporary failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 421 421 RP-001 The mail server IP connecting to Windows Live Hotmail server has exceeded the rate limit allowed. Reason for rate limitation is related to IP/domain reputation problems. If you are not an email/network admin please contact your E-mail/Internet Service Provider for help. Email/network admins, please visit http://postmaster.live.com for email delivery information and support (state 13). ----- Original message ----- Received: by 10.231.184.75 with SMTP id cj11mt3081679ibb.51.1274129866890; Mon, 17 May 2010 13:57:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.15.198 with HTTP; Mon, 17 May 2010 13:57:13 -0700 (PDT) From: me Date: Mon, 17 May 2010 21:57:13 +0100 Message-ID: <AANLkTilWHGkHdWtwgdaCFiAFA773Ma_tfefAFXfAeaBV(a)mail.gmail.com> Subject: xxxxxxxx Content-Type: text/plain; charset=ISO-8859-1 -- Regards, James. http://www.jamesbensley.co.cc/

4 3

[NANOG-announce] Book Now - Hotel Rate for NANOG 49 Expires Soon!
by Carol Wadsworth 20 May '10

20 May '10

If you are attending NANOG 49, June 13-16, in San Francisco and need overnight lodging, the group room rate at The Westin St. Francis expires this coming Monday, May 24, so please make your reservation soon. NANOG 49 is being hosted by Netflix. For all meeting related details, please see: http://www.nanog.org/meetings/nanog49/index.php See you there! _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

BGP Transit AS
by Rafael Ganascim 20 May '10

20 May '10

Hi all, I have a doubt about the bellow scenario, where the ISP1 use eBGP sessions to its peers and is a BGP Transit AS. NSP 1 ------------------ ISP 1 Router2 ----------- NSP 2 | | | | | | | annunce /21 | | | Customer1 --------------- ISP 1 Router1 announce /20 The "Customer1" is client on both ISPs (ISP1 and NSP1) and have an /20 IP prefix. To NSP1, it announce two /21 prefixes. To ISP1, it announce a /20 prefix. If traffic comes from NSP 2 (connected only to ISP 1) to Customer1, the ISP 1 Routers try to send data over NSP 1, ignoring the Custormer1->ISP1 link. To solve this question, an solution that I found is filter Customer1 prefixes in BGP session between NSP1 and ISP1 Router2. But this don't appear scalable... Is this solution right ? What is the better solution for this scenario? How large ISPs solve this kind of problem? Thanks, Rafael

4 3

SAS-70 Type II Colocation
by James Smallacombe 20 May '10

20 May '10

Looking for recommendations for SAS-70 type II certified colo providers in or around the Philly area. If you represent such a provider, please contact me OFF LIST. Thank you! PS: I checked the AUP for this list and I *think* this type of post is ok, but if it's not, I welcome correction. James Smallacombe PlantageNet, Inc. CEO and Janitor up(a)3.am http://3.am =========================================================================

1 0

Root Zone DNSSEC Deployment Technical Status Update
by Joe Abley 20 May '10

20 May '10

Root Zone DNSSEC Deployment Technical Status Update 2010-05-05 This is the sixth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. ** The final transition to a signed root zone took place today ** on J-Root, between 1700--1900 UTC. ** ** All root servers are now serving a signed root zone. ** ** All root servers will now generate larger responses to DNS ** queries that request DNSSEC information. ** ** If you experience technical problems or need to contact ** technical project staff, please send e-mail to rootsign(a)icann.org ** or call the ICANN DNS NOC at +1 310 301 5817, e-mail preferred ** if possible. ** ** See below for more details. RESOURCES Details of the project, including documentation published to date, can be found at <http://www.root-dnssec.org/>. We'd like to hear from you. If you have feedback for us, please send it to rootsign(a)icann.org. DEPLOYMENT STATUS The incremental deployment of DNSSEC in the Root Zone is being carried out first by serving a Deliberately Unvalidatable Root Zone (DURZ), and subsequently by a conventionally signed root zone. Discussion of the approach can be found in the document "DNSSEC Deployment for the Root Zone", as well as in the technical presentations delivered at RIPE, NANOG, IETF and ICANN meetings. All of the thirteen root servers have now made the transition to the to the DURZ. No harmful effects have been identified. The final root server to make the transition, J-Root, started serving the DURZ in a maintenance window between 1700--1900 UTC on 2010-05-05. Initial observations relating to this transition will be presented and discussed at the DNS Working Group meeting at RIPE 60 in Prague on 2010-05-06. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ 2010-05-05: J starts to serve DURZ To come: 2010-07-01: Distribution of validatable, production, signed root zone; publication of root zone trust anchor (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.)

6 10

Bell South RTBH
by Tony Bunce 20 May '10

20 May '10

Does anyone know if Bell South/AT&T (AS6386) has a RTBH BGP community? We just experienced a DoS attack and by the time we got through to support it had stopped. The tech told us they don't offer remote triggered blackholes but I'm not sure they exactly knew what we were asking for. It looks like our other upstream (Qwest) provides RTBH via BGP community "209:0" Thanks in advance! -Tony

1 0

Re: BGP and convergence time
by Scott Weeks 20 May '10

20 May '10

--- danny(a)tcb.net wrote: From: Danny McPherson <danny(a)tcb.net> On May 12, 2010, at 9:40 AM, Jay Nakamura wrote: > I just tested this and, yes, with Cisco to Cisco, changing the setting > won't reset the connection but you have to reset the connection to > have the value take effect. I need to look up what happens when two > sides are set to different values and which one takes precedent. : The holdtime isn't technically negotiated, both sides convey their : value in the open message and the lower of the two is used by both : BGP speakers. This isn't a negotiation? : IIRC, neither J or C reset the session with the timer change, but the : new holdtimer expiry value doesn't take effect until then. We use Alcatel 7750s. Damn thing just resets the session; no warning, no nothing. :-( : One other thing to note is that by default, keepalive intervals in : those implementations are {holdtime/3}. Normally, if you're setting : holdtime to something really lower (e.g., 10 seconds) you might want : to increase the frequency of keepalives such that the probability of : getting one through in times of instability rise. In particular, : congestion incurred outside of BGP, as update messages themselves : will serve as implicit keepalives, and with the amount of churn in BGP, : empty updates (keepalives) are rare for most speakers with a global BGP : view. I have been looking for info on the negative impact on a router by increasing the keepalive frequency to a high rate. I'm sure it's minimal for a few BGP peers, but I could imagine with a lot of peers it's a non-zero impact. scott

2 1

GSM modem test point with data and SMS support
by Frank Bulk 19 May '10

19 May '10

We have some interest in testing the real-world connectivity of several cellular towers using a GSM modem that has both a IP address on the WWAN and has SMS support. Is anyone aware of a self-contained box that supports both technologies? EDGE support is preferred, but GPRS would be acceptable. Frank

5 5