October 2016 - Test - lists.nanog.org

IPv6 Residential Deployment Survey
by John Curran 24 Jan '19

24 Jan '19

NANOGers - If you are providing residential Internet service with IPv6 (or are a customer of same), please take a moment to complete Jordi’s survey - this will help provide insight into the actual technical practices being used in residential IPv6 deployment. More details in attached email - Thanks! /John Begin forwarded message: From: John Curran <jcurran(a)arin.net<mailto:jcurran@arin.net>> Subject: [arin-ppml] IPv6 Residential Deployment Survey Date: May 22, 2016 at 6:24:17 AM GMT+2 To: ARIN PPML <ppml(a)arin.net<mailto:ppml@arin.net>> Folks - Jordi Palet Martínez is conducting a brief survey regarding IPv6 deployment in residential Internet service. Having insight into the various practices that are in use may help to inform IPv6 number resource policy development, and thus I ask that you take a moment to complete the survey if you are providing such services (whether production or trial basis.) Jordi notes - "The results will be published and updated every month or so - No personal data will be published. (If you know your network, it takes less than 2 minutes to complete it) The survey can be responded even if is not yet a commercial service, and customers can also respond, not just the ISP. However, to avoid duplicate data, make sure to include the country and ISP name.” The IPv6 Residential Deployment Survey may be found here - <http://survey.consulintel.es/index.php/175122> Thanks! /John John Curran President and CEO ARIN

9 16

Quanta LB4M
by Mike Hammett 20 Apr '18

20 Apr '18

Has anyone gotten a "non-factory" firmware to go onto these guys? There are a couple threads on Google that are inconclusive. There are rumors that it's the same as a Dell something or an HP something else, but no one has outright said, "I loaded a Dell XXXX firmware onto it and solved all of the random ass bugs." If I didn't already have a couple of stacked Extreme x400s, I'd consider these at home, but they're somewhat buggy. Quanta told me to contact whomever I bought it from... but I don't think the random guy on eBay is going to have much of anything useful to say. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

4 7

Why the internal network delays, Gmail?
by Nate Metheny 21 Jun '17

21 Jun '17

Help (and hi)! I work in higher education and we've been experiencing problems with Google delaying or queuing email for delivery to our domain. Here's some truncated email headers: ** Example 1: X-Received: by 10.237.55.65 with SMTP id i59mr10986018qtb.62.1472137448952; Thu, 25 Aug 2016 08:04:08 -0700 (PDT) Received: by mail-qt0-f175.google.com with SMTP id u25so27419242qtb.1 for <@***>; Thu, 25 Aug 2016 12:05:46 -0700 (PDT) ** Example 2: X-Received: by 10.36.1.75 with SMTP id 72mr5275579itk.40.1472130531887; Thu, 25 Aug 2016 06:08:51 -0700 (PDT) Received: by mail-it0-f48.google.com with SMTP id x131so289116132ite.0 for <@***>; Thu, 25 Aug 2016 11:50:42 -0700 (PDT) In both of these examples, these emails haven't even left Google's internal network yet; I'm getting blamed for these delays, however there is no delay in receiving these emails after they leave Google's network. Are other people having this same problem? I've tested delivery to my network from many outside sources and all SMTP requests go through without delay; this issue seems be exclusive to Google-hosted and Gmail accounts and domains. -- Nate <natemetheny(a)gmail.com>nate(a)dopedesign.com

14 21

Multi-port RFC2544/EtherSAM loopback appliance
by Jason Lixfeld 25 May '17

25 May '17

Group, I'm looking for options and opinions on a cost effective, multi-port (6'ish port SFP/SFP+) RFC2544/EtherSAM rack appliance that can act as the remote/loopback for our field installers' portable RFC2544/EtherSAM enabled Exfo test sets. I came across XenaNetworks XenaCompact which looks like it would fit the bill, but I'm sure there are others (save Ixia, Exfo and Fluke, which I'm pretty much excluding by default because I imagine they are likely completely out to lunch on price relative to the extremely simplified feature set we require). Thanks in advance.

5 4

[NANOG-announce] 2016 NANOG Election Results
by Dave Temkin 21 Dec '16

21 Dec '16

Greetings NANOG Colleagues, The 2016 NANOG Board and Bylaw election process is now complete. The results were shared during NANOG 68, are posted on the NANOG website, and summarized here. In 2016, there were two regular open positions on the Board of Directors. The appointments are: - Will Charnock - 3 years - Patrick Gilmore - 3 years The officers elected and committee liaisons are: - Chair - Dave Temkin - Vice Chair - Ryan Donnelly - Treasurer - Will Charnock - Secretary - Betty Burke - Communications Committee Liaison - Jezzibell Gilmore - Program Committee Liaison - Patrick Gilmore The proposed amendments to the NANOG Bylaws were accepted. The updated Bylaws document will be posted to the NANOG website. Best Regards, -Dave Temkin Chair, NANOG Board of Directors _______________________________________________ NANOG-announce mailing list NANOG-announce(a)mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 1

Re: Death of the Internet, Film at 11
by Ronald F. Guilmette 02 Dec '16

02 Dec '16

Laszlo Hanyecz wrote: >What does BCP38 have to do with this? Your're right. That's not specifically related to *this* attack. Nobody needs to spoof anything when you've got a zillion fire hoses just lying around where any 13 year old can command them from the TRS 80 in his mom's basement. (I've seen different estimates today. One said there's about a half million of these things, but I think I saw where Dyn itself put the number of unique IPs in the attack at something like ten million.) I just threw out BCP 38 as an example of something *very* minimal that the collective Internet, if it had any brains, would have made de rigueur for everyone ten+ years ago. BCP 38 is something that I personally view as a "no brainer", that is already widely accepted as being necessary, and yet is a critical security step that some (many?) are still resisting. So, it's like "Well, if the Internet-at-large can't even do *this* simple and relatively non-controversial thing, then we haven't got a prayer in hell of ever seeing a world-wide determined push to find and neutralize all of these bloody damn stupid CCTV things. And when the day comes when somebody figures out how to remotely pop a default config Windoze XP box... boy oh boy, will *that* be a fun day... NOT! Because we're not ready. Nobody's ready. Except maybe DoD, and I'm not even taking bets on that one." I didn't intend to focus on BCP 38. Everybody knows that's only one thing, designed to deal with just one part of the overall problem. The overall problem, in my view, is the whole mindset which says "Oh, we just connect the wires. Everything else is somebody else's problem." Ok, so this mailing list is a list of network operators. Swell. Every network operator who can do so, please raise your hand if you have *recently* scanned you own network and if you can -honestly- attest that you have taken all necessary steps to insure that none of the numerous specific types of CCVT thingies that Krebs and others identified weeks or months ago as being fundamentally insecure can emit a single packet out onto the public Internet. And, cue the crickets... Recent events, like the Krebs DDoS and the even bigger OVH DDoS, and today's events make it perfectly clear to even the most blithering of blithering idiots that network operators, en mass, have to start scanning their own networks for insecurities. And you'd all better get on that, not next fiscal year or even next quarter, but right effing now, because the next major event is right around the corner. And remember, *you* may not be scanning your networks for easily pop'able boxes, but as we should all be crystal clear on by now, that *does not* mean that nobody else is doing so. Regards, rfg P.S. The old saying is that idle hands are the devil's playground. In the context of the various post-invasion insurgancies, etc., in Iraq, is is often mentioned that it was a somewhat less than a brilliant move for the U.S. to have disbanded the Iraq army, thereby leaving large numbers of trained young men on the streets with no jobs and nothing to do. To all of the network operators who think that (or argue that) it will be too expensive to hire professionals to come in an do the work to scan your networks for known vulnerabilities, I have a simple suggestion. Go down to your local high school, find the schmuck who teaches the kids about computers, and ask him for the name of his most clever student. Then hire that student and put him to work, scanning your network. As in Iraq, it will be *much* better to have capable young men inside the tent, pissing out, rather than the other way around.

55 165

nested prefixes in Internet
by Martin T 21 Nov '16

21 Nov '16

Hi, let's assume that there is an ISP "A" operating in Europe region who has /19 IPv4 allocation from RIPE. From this /19 they have leased /24 to ISP "B" who is multi-homed. This means that ISP "B" would like to announce this /24 prefix to ISP "A" and also to ISP "C". AFAIK this gives two possibilities: 1) Deaggregate /19 in ISP "A" network and create "inetnum" and "route" objects for all those networks to RIPE database. This means that ISP "A" announces around dozen IPv4 prefixes to Internet except this /24 and ISP "B" announces this specific /24 to Internet. 2) ISP "A" continues to announce this /19 to Internet and at the same time ISP "B" starts to announce /24 to Internet. As this /24 is more-specific than /19, then traffic to hosts in this /24 will end up in ISP "B" network. Which approach is better? To me the second one seems to be better because it keeps the IPv4 routing-table smaller and requires ISP "A" to make no deaggregation related configuration changes. Only bit weird behavior I can see with the second option is that if ISP "B" stops for some reason announcing this /24 network to Internet, then traffic to hosts in this /24 gets to ISP "A" network and is blackholed there. thanks, Martin

15 30

Voip faxing
by Samual Carman 03 Nov '16

03 Nov '16

Hello if this is not allowed please ignore and inform me that it not allowed however I could think of no better place for this I would like to know why there has not been more wide support of the V.38 or v.17 v.34 or the old style g.711 protocols for faxing over voip Based on my understanding it is an difficult in an IP based environment for faxing to work reliably however based on my understanding V.38 was suppose to fix that however the research I have conducted in regards to the support of these protocols is that there not widely implimted and besides G.711 which was designed for voice that proviso is somewhat implored on a wider scale However I understand faxing is archaic but in some fields it is necessary Thanks Sam Please excuse spelling and grammar as this was typed on my phone Get Outlook for iOS

3 3

Large BGP Communities beacon in the wild
by Job Snijders 02 Nov '16

02 Nov '16

Dear all, Large BGP Communities are a novel way to signal information between networks. An example of a Large BGP Communities is: 2914:4056024901:80. Large BGP Communities are composed of three 4-octet integers, separated by something like a colon. This is easy to remember and accommodates advanced routing policies in relation to 4-Byte ASNs. It is the tool that has been missing since 4-octet ASNs were introduced. IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY) in the "BGP Path Attributes" registry under the "Border Gateway Protocol (BGP) Parameters" group. The draft can be read here: https://tools.ietf.org/html/draft-ietf-idr-large-community Additional information about Large BGP Communities can be found here: http://largebgpcommunities.net/ Starting today (2016.10.11), the following two BGP beacons are available to the general public, with AS_PATH 2914_15562$ Both these prefixes have a Large BGP Community attached: 2001:67c:208c::/48 192.147.168.0/24 Large BGP Community - 15562:1:1 The NLNOG RING BGP Looking Glass is running the latest version of BIRD which understands the Large BGP Community Path Attribute. IPv4 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.147.168.0/24 IPv6 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:67c:208c::/48 In theory, since this is an optional transitive BGP Path Attribute, all the Looking Glass' peers should boomerang the Large Community back to the LG. However we currently observe that 50 out of 75 peers propagate the Large BGP Community to the LG. Relevant Router commands to see if you receive the attribute, or whether one of intermediate networks has stripped the attribute from the route: IOS: show ip bgp path-attribute unknown shows all prefixes with unknown path attributes. IOS #2 - like on route views: route-views>sh ip bgp 192.147.168.0 BGP routing table entry for 192.147.168.0/24, version 98399100 Paths: (39 available, best #30, table default) Not advertised to any peer Refresh Epoch 1 701 2914 15562 137.39.3.55 from 137.39.3.55 (137.39.3.55) Origin IGP, localpref 100, valid, external unknown transitive attribute: flag 0xE0 type 0x1E length 0xC value 0000 3CCA 0000 0001 0000 0001 rx pathid: 0, tx pathid: 0 IOS-XR: (you must look at specific prefixes) RP/0/RSP0/CPU0:Router#show bgp ipv6 unicast 2001:67c:208c::/48 unknown-attributes BGP routing table entry for 2001:67c:208c::/48 Community: 2914:370 2914:1206 2914:2203 2914:3200 Unknown attributes have size 15 Raw value: e0 1e 0c 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ JunOS: user@JunOS-re6> show route 2001:67c:208c::/48 detail 2001:67c:208c::/48 (1 entry, 1 announced) AS path: 15562 I Unrecognized Attributes: 15 bytes Attr flags e0 code 1e: 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A note about router Configurations: Ensure you are not fitlering the path attributes, eg: JunOS: [edit protocols bgp] user@junos# delete drop-path-attributes 30 XR: configure router bgp YourASN attribute-filter group ReallyBadIdea ! avoid creating bogons no attribute 30 ! ! Contact persons: myself or Jared Mauch or NTT NOC. BGP Session identifier 83.231.213.230 / 2001:728:0:5000::a92 AS 15562. Kind regards, Job

8 8

MPLS in the campus Network?
by steven brock 02 Nov '16

02 Nov '16

Dear NANOG members, We operate a campus network reaching more than 100 buildings on 5 campuses. We also operate a regional backbone and the interconnexion to our NREN. The current architecture is made of a L2 backbone and a few routers. Most of the buildings are connected with a 1 Gb/s link using our own optical fiber (only a few building are connected at 10 Gb/s). In a smaller number of buildings (a few dozens), we also operate the internal network, made of ethernet switches (in a multi-vendor environment). In each building, we provide at least an edge switch, marking the boundary between us and the customer, where we deliver the different services on ethernet ports. The services we currently offer: - L2 interconnections (400 vlans are present in 2 buildings or more; only a few VLANs are present in more than 30 buildings) - IPv4 et IPv6 routing (hundreds of subnets) and Internet access, - specific interconnections (ex: terminating a VPN to the customer, say a national private infrastructure delivered by the NREN through MPLS L2/L3VPN and stitched to the customer network using a specific VLAN) - routing isolation using routing instances (~ VRF Lite) : only 5 instances, but we could have more, - routing and filtering using open source firewalls running on servers in our DCs (less than 15 platforms, as most customer operate their own firewall), - user authentication, - shared VPN platform allowing direct access for an identified user into the customer network (based on radius attribute) - this platform uses VLANs to interconnect to the rest of the network, - wireless LAN, also allowing direct access for an identified user into the customer network ; the platform is a centralized controller, and it uses VLAN to interconnect to the rest of the network. (those last two services could use just a VLAN or a dedicated subnet delivered on a port of the edge switch which is then connected to the customer firewall) We are not satisfied with the current backbone design ; we had our share of problems in the past: - high CPU load on the core switches due to multiple instances of spanning tree slowly converging when a topology change happens (somehow fixed with a few instances of MSTP) - spanning tree interoperability problems and spurious port blocking (fixed by BPDU filtering) - loops at the edge and broadcast/multicast storms (fixed with traffic limits and port blocking based on threshhold) - some small switches at the edge are overloaded with large numbers of MAC addresses (fixed with reducing broadcast domain size and subnetting) This architecture doesn't feel very solid. Even if the service provisionning seems easy from an operational point of view (create a VLAN and it is immediately available at any point of the L2 backbone), we feel the configuration is not always consistent. We have to rely on scripts pushing configuration elements and human discipline (and lots of duct-tape, especially for QoS and VRFs). We are re-designing our network architecture. We have enough fiber to imagine many ways to link the core network devices. We find MPLS has its merit as a platform, to bring all the network services we currently provide (L2, L3 VPN, VPLS, and soon EVPN) However, we also want to upgrade the infrastructure to allow future growth of the traffic. Some labs, especially in physics, could need more than 10 Gb/s in the coming years. Our cycles of evolution are long (we keep a backbone technology for 8 years). MPLS is definitely not cheap considering the price of a 10G or 100G router interface. Compared to MPLS, a L2 solution with 100 Gb/s interfaces between core switches and a 10G connection for each buildings looks so much cheaper. But we worry about future trouble using Trill, SPB, or other technologies, not only the "open" ones, but specifically the proprietary ones based on central controller and lots of magic (some colleagues feel the debug nightmare are garanteed). If you had to make such a choice recently, did you choose an MPLS design even at lower speed ? How would you convince your management that MPLS is the best solution for your campus network ? How would you justify the cost or speed difference ? Thanks for your insights!

7 14