September 2009 - Test - lists.nanog.org

RE: cross connect reliability
by Carlos Alcantar 17 Sep '09

17 Sep '09

We seem to have the highest failure rate on cross connects from ds3's and t1's. -carlos -----Original Message----- From: Brandon Palmer [mailto:bpalmer@fxcm.com] Sent: Thursday, September 17, 2009 5:59 PM To: Michael J McCafferty; nanog Subject: Re: cross connect reliability We've never had a fiber CC fail. We HAVE had DS3 and T1s fail. Those were due to other customer circuits being installed near ours and bumping them. >>> Michael J McCafferty <mike(a)m5computersecurity.com> 9/17/2009 5:45 PM >>> All, Today I had yet another cross-connect fail at our colo provider. From memory, this is the 6th cross-connect to fail while in service, in 4yrs and recently there was a bad SFP on their end as well. This seemes like a high failure rate to me. When I asked about the high failure rate, they said that they run a lot of cables and there is a lot of jiggling and wiggling... lots of chances to get bent out of whack from activity near my patches and cables. Until a few years ago my time was spent mostly in single tenant data centers, and it may be true that we made fewer cabling changes and made less of a ruckus when cabling... but this still seems like a pretty high failure rate at the colo. I am curious; what do you expect the average reliability of your FastE or GigE copper cross-connects at a colo? Thanks, Mike -- ************************************************************ Michael J. McCafferty Principal, Security Engineer M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************

1 0

Re: cross connect reliability
by William Pitcock 17 Sep '09

17 Sep '09

We have never had a xconnect fail, ever. And we have several. This is over a 6 year period. William ------Original Message------ From: Michael J McCafferty To: nanog Subject: cross connect reliability Sent: Sep 17, 2009 4:45 PM All, Today I had yet another cross-connect fail at our colo provider. From memory, this is the 6th cross-connect to fail while in service, in 4yrs and recently there was a bad SFP on their end as well. This seemes like a high failure rate to me. When I asked about the high failure rate, they said that they run a lot of cables and there is a lot of jiggling and wiggling... lots of chances to get bent out of whack from activity near my patches and cables. Until a few years ago my time was spent mostly in single tenant data centers, and it may be true that we made fewer cabling changes and made less of a ruckus when cabling... but this still seems like a pretty high failure rate at the colo. I am curious; what do you expect the average reliability of your FastE or GigE copper cross-connects at a colo? Thanks, Mike -- ************************************************************ Michael J. McCafferty Principal, Security Engineer M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************ -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149

1 0

RE: cross connect reliability
by David Hubbard 17 Sep '09

17 Sep '09

From: Michael J McCafferty [mailto:mike@m5computersecurity.com] > > All, > Today I had yet another cross-connect fail at our colo > provider. From memory, this is the 6th cross-connect to > fail while in service, in 4yrs and recently there was a > bad SFP on their end as well. This seemes like a high > failure rate to me. When I asked about the high failure > rate, they said that they run a lot of cables and there > is a lot of jiggling and wiggling... lots of chances to > get bent out of whack from activity near my patches and > cables. > I am curious; what do you expect the average > reliability of your FastE > or GigE copper cross-connects at a colo? You're seeing these failures on copper?! I've worked in some places with absolute cabling nightmares on the copper side of things in wiring closets but those were all enterprise situations and we still rarely had failures of ports and even less on the wiring itself. I'd never expect there to be frequent copper issues in a colo where you would not have anywhere near the volume of moving cables around that goes on in an enterprise. On the fiber side, your experience still seems high although obviously much easier to damage fiber cables. Perhaps they have a big mess of a fiber plant and have to fish tape new runs through it and like to snag adjacent cables, etc. It can only get worse if that's the problem and they don't clean it up. David

1 0

RE: <Keepalives are temporarily in throttle due to closed TCP window>
by Michael Ruiz 17 Sep '09

17 Sep '09

And is that the one that traverses the 3550 with the 1500 byte MTU? Both connection traver through the 3550. I will disable the command on 7206 vxr. thanks -----Original Message----- From: "Richard A Steenbergen" <ras(a)e-gerbil.net> To: "Michael Ruiz" <mruiz(a)telwestservices.com> Cc: "Brian Dickson" <Brian.Dickson(a)concertia.com>; "nanog(a)nanog.org" <nanog(a)nanog.org> Sent: 9/16/09 8:58 PM Subject: Re: <Keepalives are temporarily in throttle due to closed TCP window> On Wed, Sep 16, 2009 at 06:47:10PM -0500, Michael Ruiz wrote: > >Either a) you have the mtu misconfigured on that 7206vxr > > That part is where I am at a loss. How is it the 6509 can establish a > IBGP session with a 7606 when it has to go through the 7206 VXR? The > DS-3s are connected to the 7206 VXR. To add more depth to the story. I > have 8 IBGP sessions that are connected to the 7206 VXR that have been > up and running for over a year. Some of the sessions traverse the DS-3s > and or a GigE long haul connections. There are a total 10 Core routers > that are mixture of Cisco 7606, 6509s, 7206 VXR w/ NPE400s or G1s. Only > this one IBGP session out of 9 routers is not being established. Since > I have a switch between the 7606 and 7206, I plan to put a packet > capture server and see what I can see. And is that the one that traverses the 3550 with the 1500 byte MTU? Re-read what we said. You should be able to test the MTU theory by disabling path-mtu-discovery, which will cause MSS to fail back to the minimum 576. -- 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)

2 3

PPPOE design
by Devangnp 17 Sep '09

17 Sep '09

Hi, Any design consideration on PPPoE agg & routing? Any good example of covering multiple customers or subnets ? Thanks, Devang Patel

2 1

[NANOG-announce] 2009 Elections Update
by Joe Provo 17 Sep '09

17 Sep '09

Hi NANOGers, Thanks to everyone who has thrown their hat into the ring for the NANOG Steering Committee! If you were nominated and had not yet sent in your bio or confirmation, please take a moment today to do so by sending mail to <nominations(a)nanog.org>. For the list, see http://www.nanog.org/governance/elections/2009elections/2009sc_candidates.p… As Dave posted previously, the PC nominations are currently open. If you think you or someone you know could help continue to improve the conference, send your nominations to <nominations(a)nanog.org>. After the election, the new Steering Committee will appoint people to fill the vacant slots. The current slate of nominees are posted here http://www.nanog.org/governance/elections/2009elections/2009pc_candidates.p… For more information, please check out the 2009 elections page: http://www.nanog.org/governance/elections/2009elections/ IMPORTANT DATES Mon 2009-09-28 MLC nominations open Mon 2009-09-28 Charter draft amendments posted to NANOG website Tue 2009-10-06 Ballot confirmed and finalized at NANOG SC meeting Sun 2009-10-18 Voting for the 2009/2010 NANOG SC opens Mon 2009-10-19 PC nominations close, candidate information posted Wed 2009-10-21 Voting for the 2009/2010 NANOG SC closes Thu 2009-10-22 SC appoints new PC Thu 2009-10-29 MLC nominations close, candidate information posted Tue 2009-11-03 SC appoints new MLC Cheers! Joe Provo for the NANOG Steering Committee -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

BGP question
by Rens 17 Sep '09

17 Sep '09

Hi all, I'm having difficulties to understand why I am not advertising a certain customer range to my upstream. I can see this range in my BGP table 3 times. show ip bgp customer_range Number of BGP Routes matching display condition : 3 Status codes: s suppressed, d damped, h history, * valid, > best, i internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i customer_range Local IX 110 0 XXXX YYYY i * customer_range upstream provider 100 0 AAAA BBBB XXXX YYYY i * customer_range my customer 0 120 0 YYYY YYYY i Last update to IP routing table: 0h23m34s, 1 path(s) installed: Route is not advertised to any peers customer_range = each time the same /24 But it seems to choose the set the one as local IX as best. When I disable local IX it sets the one with my upstream provider as best. Shouldn't it set the customer_range I receive from my customer as best since it's highest local pref and advertise it to my upstream provider peer? Regards, Rens

2 2

<Keepalives are temporarily in throttle due to closed TCP window>
by Michael Ruiz 16 Sep '09

16 Sep '09

I am having difficulty maintaining my BGP session from my 6509 with Sup-7203bxls to a 7206 VXR NPE-400. The session bounces every 3 minutes. I do have other IBGP sessions that are established with no problems, however, this is the only IBGP peer that is bouncing regularly. cr1.AUSTTXEE#show ip bgp neighbors 67.214.64.100 <SNIP> BGP state = Established, up for 00:02:54 Last read 00:00:53, last write 00:02:54, hold time is 180, keepalive interval is 60 seconds Keepalives are temporarily in throttle due to closed TCP window Neighbor capabilities: Route refresh: advertised and received(new) Address family IPv4 Unicast: advertised and received Message statistics: What does exactly the message mean and how do I stabilize this? Any help will be appreciated. Michael Ruiz Network Engineer Office 210-448-0040 Cell 512-744-3826 mruiz(a)telwestservices.com <mailto::mruiz@telwestservices.com> "I don't measure a man's success by how high he climbs but how high he bounces when he hits bottom." - General George S. Patton Jr. How am I doing? Please email my Director of Engineering Jared Martin with any feedback at: jmartin(a)telwestservices.com

6 15

ADMIN: List FAQ/Monthly Post.
by NANOG Mail List Committee 15 Sep '09

15 Sep '09

This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also contains pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins(a)nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://spam-l.com/mailman/listinfo * Contacting People * http://puck.nether.net/netops/ * http://www.peeringdb.com * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins(a)nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php

1 0

Repeated Blacklisting / IP reputation
by Tom Pipes 15 Sep '09

15 Sep '09

Greetings, We obtained a direct assigned IP block 69.197.64.0/18 from ARIN in 2008. This block has been cursed (for lack of a better word) since we obtained it. It seems like every customer we have added has had repeated issues with being blacklisted by DUL and the cable carriers. (AOL, AT&T, Charter, etc). I understand there is a process to getting removed, but it seems as if these IPs had been used and abused by the previous owner. We have done our best to ensure these blocks conform to RFC standards, including the proper use of reverse DNS pointers. I can resolve the issue very easily by moving these customers over to our other direct assigned 66.254.192.0/19 block. In the last year I have done this numerous times and have had no further issues with them. My question: Is there some way to clear the reputation of these blocks up, or start over to prevent the amount of time we are spending with each customer troubleshooting unnecessary RBL and reputation blacklisting? I have used every opportunity to use the automated removal links from the SMTP rejections, and worked with the RBL operators directly. Most of what I get are cynical responses and promises that it will be fixed. If there is any question, we perform inbound and outbound scanning of all e-mail, even though we know that this appears to be something more relating to the block itself. Does anyone have any suggestions as to how we can clear this issue up? Comments on or off list welcome. Thanks, --- Tom Pipes T6 Broadband/ Essex Telcom Inc tom.pipes(a)t6mail.com

44 80