May 2014 - Test - lists.nanog.org

RE:Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
by Darin 06 May '14

06 May '14

And since those puppies are going to need a reload after adjustment make sure your not exposed to the component decay issue for cards manufactured between 2005-2010 or you could have a interesting night. We've hit that issue on three different 7600 chassis. Darin -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Drew Weaver Sent: Tuesday, May 06, 2014 10:39 AM To: 'nanog(a)nanog.org' Subject: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. Hi all, I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. We are at about 94/95% right now of 512K. For most of us, the 512K route mark is arbitrary but for a lot of folks who may still be running 6500/7600 or other routers which are by default configured to crash and burn after 512K routes; it may be a valuable public service. Even if you don't have this scenario in your network today; chances are you connect to someone who connects to someone who connects to someone (etc...) that does. In case anyone wants to check on a 6500, you can run: show platform hardware capacity pfc and then look under L3 Forwarding Resources. Just something to think about before it becomes a story the community talks about for the next decade. -Drew

2 1

linkedin.com abuse admins around?
by goemon＠anime.net 06 May '14

06 May '14

If there is anyone from linkedin.com abuse around please let me know. I've been trying for 2 months to get an abuse issue resolved. -Dan

4 3

Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]
by Chris Grundemann 06 May '14

06 May '14

Hi Mans, On Fri, May 2, 2014 at 2:35 PM, Måns Nilsson <mansaxel(a)besserwisser.org>wrote: > This is a field where v4 next-hops are essential to make things > work. <rant>In that context, allocating 100.64.0.0/10 to CGN was > especially un-clever... </rant> > Would you expound a bit on what you mean here? I don't quite follow but I am very interested to understand the issue. Thanks! ~Chris -- @ChrisGrundemann http://chrisgrundemann.com

8 14

AusNOG 2014 Call for Presentations
by Mark Prior 06 May '14

06 May '14

Call for presentations for AusNOG 2014 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Swissotel Sydney 4 & 5 September 2014 Topics =-=-=- Internet operations can be a broad topic and the programme committee will be short-listing presentations in the following focus areas: * Improving the redundancy/resiliency/sustainability of your network * Making leaps in service or network availability * Taking the network operations BCP to the next level * Using 'offline' communications tools to keep the network working * How technology is changing network architectures * Evolution in network architectures and scaling issues * Analysis of relevant major operational events of the year This year we will be reintroducing a "Peering Forum". In this part of the programme we hope to include: * Peering related talks * Peering personals from various networks * IX updates Additional topics that are of interest to the network operator community are also welcome at AusNOG 2014. Naturally, presentations of a marketing nature are not welcome at this technical event. Notes to presenters =-=-=-=-=-=-=-=-=-= Preference will be given to presentations that result in actual operational outcomes. Session speakers should be prepared to present for 30 minutes. Keynote speakers will be expected to present for 45 minutes to 1 hour. Short presentations of strong operational content are also acceptable. Once the final slides are submitted, changes will only be permitted where the presentation requires the most up to date information or data. By submitting a presentation for consideration in the AusNOG 2014 programme, and if selected the presenter will allow AusNOG to: * Take photographs of the presentation and presenter * Record and rebroadcast video and audio of the presentation and presenter * Redistribute the presentation slides, audio, video, and photographs electronically, on the AusNOG website, or otherwise but leaving all intellectual property in the hands of presenter or rightful property holder[1]. Deadlines =-=-=-=-= 09 June: Submission of presentation title, presentation description (300 words), and presenter biography (200-400 words) 04 July: Presenters notified of their acceptance status as an AusNOG 2014 presentation. 27 August: Submission of final presentation slides as Portable Document Format (pdf), PowerPoint, or Keynote. Provision of a recent digital photograph (<500k) of the presenter. All submissions must be sent to organisers at ausnog.net. A separate call for lightning talks will be made closer to the AusNOG 2014 event. As in previous years you must be registered to attend AusNOG 2014 in order to be considered for a lightning talk. [1]: AusNOG accepts that some speakers are unable to allow us to archive their presentation due to company or corporate policy, and if the situation arises AusNOG will delete all copies in its possession after the presentation. Mark. For the AusNOG Board

1 0

Paging HP DNS admin
by Mark Radabaugh 05 May '14

05 May '14

Dear HP: If your not going to support IPv6 can you at least not return SRVFAIL when asked for an AAAA record: root@spoons:/etc/mail # dig AAAA onramp01.hpeprint.com ; <<>> DiG 9.8.3-P4 <<>> AAAA onramp01.hpeprint.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61583 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;onramp01.hpeprint.com. IN AAAA And what genius thought that emailing documents to printers was a good idea in the first place? Nothing like taking graphics, turning it into 7 bit text, and sending it through a system never intended for the purpose. Supporting luser email is a big enough pain in the arse, now I have to deal with your idiotic printers as well? Gee thanks! Mark

6 8

Observations of an Internet Middleman
by staticsafe 05 May '14

05 May '14

http://blog.level3.com/global-connectivity/observations-internet-middleman/ -- staticsafe https://asininetech.com

1 0

[NANOG-announce] NANOG Event Updates
by Betty Burke <betty＠nanog.org> 05 May '14

05 May '14

NANOGers: A few reminders regarding upcoming NANOG Events: - NANOG ON THE Road - LA <https://www.nanog.org/meetings/road3/home>is fast approaching, Tuesday, May 20, 2014. If you have not yet registered for this free one day event, consider doing so now<https://www.nanog.org/meetings/road3/home/registration>. The agenda <http://www.nanog.org/meetings/road3/home/agenda> is now posted, the day is sure to be of value to all. If you know of someone local and not on the NANOG list, please pass along this information. - NANOG Education Classes<https://www.nanog.org/meetings/education/bellevue_education_classes/home> in Bellevue, will be held on Sunday, June 1, 2014. Two classes will be offered, Routing Fundamentals<https://www.nanog.org/meetings/education/routing_fundamentals_bellevueclass>, and IPv6 Routing Fundamentals<https://www.nanog.org/meetings/education/ipv6routing_fundamentals_bellevuec…>. The classes will help prepare students for transition into current world operations of the Internet. If you know of someone who would benefit from the NANOG experience offered, please pass along this information. - Lastly, NANOG 61 <https://www.nanog.org/meetings/nanog61/home> in Bellevue is a few weeks away, June 2-4, 2014. The NANOG 61 Highlights<https://www.nanog.org/meetings/nanog61/agendahighlights> page provides an over-view of what attendees should expect while attending the meeting. The NANOG Program Committee has been hard at work building another outstanding program. The Pre-agenda and Topics<https://www.nanog.org/meetings/nanog61/preagenda> page is available and the full agenda will be posted soon. - The NANOG 61 meeting Registration<https://www.nanog.org/meetings/nanog61/registration> fee will increase on Monday, May 12, 2014, and the NANOG Hotel Block<https://www.nanog.org/meetings/nanog61/hotelinformation> will expire on Friday, May 16, 2014. If you have not yet registered, or made your room reservation, consider doing so this week! - NANOG 61 Fellowships <https://www.nanog.org/resources/fellowships> are available. If you or a colleague are interested in attending NANOG 61 and need some travel assistance, please do consider applying. - Consider having your company join the growing number of NANOG 61 Sponsors <https://www.nanog.org/meetings/nanog61/sponsors> in Bellevue. A few Sponsorship opportunities<https://www.nanog.org/sponsors/opportunities> remain. If you are not currently a NANOG member <https://www.nanog.org/membership>, do consider joining the 556 NANOGers who find value in being a part of the NANOG governance process, joining is easy<https://www.nanog.org/membership/join> . Should you have any questions about NANOG, please do not hesitate to contact nanog-support(a)nanog.org or feel free to contact me directly. Sincerely, Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 www.nanog.org _______________________________________________ NANOG-announce mailing list NANOG-announce(a)mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

CLEC and FTTP H.248/Megaco
by Jean-Francois Mezei 05 May '14

05 May '14

I need a sanity check. An incumbent in Canada has revealed that its voice service on FTTP deployments is based on H.248 MEGACO (Media Gateway Controller). Are there any examples of CLEC access to such FTTP deployments ? (for instance, an area where the copper was removed, leaving only fibre to homes, do CLECs retain competitive access via fibre to homes, or is it going out of business or going with pure SIP/VoIP over the regular internet connection, instead of using the "quality" voice link in the GPON with garanteed bandwidth ? Can this protocol support the programming of one OLT/MG connecting to the Telco's MGC, while the OLT/MG next door connects to the CLEC's MGC ? Or does the protocol result in MG's "discovering" the nearest MGC and connecting to it (making it hard to have multiple MGCs from competing telcos). I have been lead to believe that most OLTs came with a SIP based ATA. It appears that H.248 is more telco friendly and scales better. Does this mean that H.248 is more widely deployed in FTTH ?

5 6

What Net Neutrality should and should not cover
by Rick Astley 05 May '14

05 May '14

Without the actual proposal being published for review its hard to know the specifics but it appears that it prohibits blocking and last mile tinkering of traffic (#1). What this means to me is ISP's can't block access to a specific website like alibaba and demand ransom from subscribers to access it again. I do not know if this provision would also include prohibiting intentionally throttling traffic on a home by home basis (#2) and holding services to the same kind of random is also prohibited but I think this too would be a far practice to prohibit. Bits are bits. >From the routers article ( http://www.reuters.com/article/2014/04/23/us-usa-fcc-internet-idUSBREA3M1H0…) and elsewhere it seems what the proposal does not outlaw is paid peering and perhaps use of QoS on networks. #3 On paid peering: I think this is where people start to disagree but I don't see what should be criminal about paid peering agreements. More specifically, I see serious problems once you outlaw paid peering and then look at the potential repercussions that would have. Clearly it would not be fair to for only the largest content providers to be legally mandated as settlement free peers because that would leave smaller competitors out in the cold. The only fair way to outlaw paid peering would be to do it across the board for all companies big and small. This would be everyone from major content providers to my uncle to sells hand runs a website to sell hand crafted chairs. This would have major sweeping repercussions for the Internet as we know it over night. I think it makes sense to allow companies to work it out as long as the prices charged aren't unreasonably high based on market prices for data. This means if 2 ISP's with similar networks want to be settlement free they can. If ISP's want to charge for transit they can, and if ISP's want to charge CDN's to deliver data they can. Typically the company with the disproportional amount of costs of carrying the traffic would charge the other company but really it should be up to the companies involved to decide. Based on the post by Tom Wheeler from the FCC ( http://www.fcc.gov/blog/setting-record-straight-fcc-s-open-internet-rules ) it sounds like if this pricing is "commercially unreasonable" (ie extortion) they will step in. Again I think this is fair. #4 On QoS (ie fast lane?): In some of the articles I skimmed there was a lot of talk about fast lane traffic but what this sounds like today would be known as QoS and classification marking that would really only become a factor under instances of congestion. The tech bloggers and journalists all seems to be unanimously opposed to this but I admit I am sort of scratching my head at the outrage over something that has been in prevalent use on many major networks for several years. I don't see this as the end of the Internet as we know it that now seems to essentially be popular opinion on the issue. Numerous businesses are using QoS to protect things like voice traffic and business critical or emergency traffic from being impacted in a failure scenario. In modern day hyper converged networks where pretty soon even mobile voice traffic could be VoIP over a data network prohibiting the use of all QoS seems irresponsible. The larger question is, is it fair for ISP's to charge people to be in a priority other than "best effort"? To answer a question with a question, if an ISP is using a priority other than "best effort" for some of its own traffic is it fair if a peer with a competing service is only best effort delivery? This is sort of akin to Comcast not counting its own video service against the ~250G/month cap of subscribers but counting off network traffic against it. In theory if some of an ISP's own services are able to use higher than best effort priority the same should be available to the business they are selling service to. If they go completely out of their way to intentionally congest the network to force people into needing a higher than best effort classification I would think it should fall into what the FCC calls "commercially unreasonable" and thus be considered a violation. So again, I think this is fair. I have numbered the items I mentioned from 1-4 being #1. Blocking #2. per household (last mile) rate limiting of a service (though rate limiting at all anywhere should probably be up for discussion so #2.5) #3. The legality of paid peering #4. The legality of QoS (unless fast lane is something else I don't understand). Feel free to augment the list.

18 22

Ruxcon 2014 Call For Papers
by cfp＠ruxcon.org.au 05 May '14

05 May '14

Ruxcon 2014 Call For Presentations Melbourne, Australia, October 11th-12th http://www.ruxcon.org.au The Ruxcon team is pleased to announce the Call For Presentations for Ruxcon 2014. This year the conference will take place over the weekend of the 11th and 12th of October at the CQ Function Centre, Melbourne, Australia. .[x]. About Ruxcon .[x]. Ruxcon brings together the individual talents of the best and brightest security folk in the region, through live presentations, activities, and demonstrations. The con is held over two days in a relaxed atmosphere, allowing delegates to enjoy themselves whilst networking within the community and expanding their knowledge. Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community. .[x]. Important Dates .[x]. May 1st - Call For Presentations Open September 30th - Call For Presentations Close October 6-7 - Ruxcon/Breakpoint Training October 8-9 - Breakpoint Conference October 11-12 - Ruxcon Conference .[x]. Topic Scope .[x]. o Topics of interest include, but are not limited to: o Mobile Device Security o Virtualization, Hypervisor, and Cloud Security o Malware Analysis o Reverse Engineering o Exploitation Techniques o Rootkit Development o Code Analysis o Forensics and Anti-Forensics o Embedded Device Security o Web Application Security o Network Traffic Analysis o Wireless Network Security o Cryptography and Cryptanalysis o Social Engineering o Law Enforcement Activities o Telecommunications Security (SS7, 3G/4G, GSM, VOIP, etc) .[x]. Submission Guidelines .[x]. In order for us to process your submission we require the following information: 1. Presentation title 2. Detailed summary of your presentation material 3. Name/Nickname 4. Mobile phone number 5. Brief personal biography 6. Description of any demonstrations involved in the presentation 7. Information on where the presentation material has or will be presented before Ruxcon * As a general guideline, Ruxcon presentations are between 45 and 60 minutes, including question time. If you have any enquiries about submissions, or would like to make a submission, please send an email to presentations(a)ruxcon.org.au .[x]. Contact .[x]. o Email: submissions(a)ruxcon.org.au o Twitter: @ruxcon

1 0