November 2016 - Test - lists.nanog.org

400 N Tampa sells for almost $80M
by Jay R. Ashworth 04 Nov '16

04 Nov '16

The tower is the home of WOW (formerly E-Solutions), which has 2 floors of colo, and about 8 or 9 carriers, making it one of two major carrier hotels in downtown Tampa. As usual, no clue what the new owner's approach will be, though "refurbing and leasing aggressively" is mentioned. If you're in the building, assume they'll cut your fiber at least once. :-) http://www.bizjournals.com/tampabay/news/2016/11/04/downtown-tampas-origina… Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

1 0

Re: Google contact needed to help resolve captcha issue
by Fredrik Holmqvist / I2B 04 Nov '16

04 Nov '16

Hi. It's as useful as banging your head to the wall. All you get is the same information as you get from the captcha page. No help at all. No way to get the issue resolved. On 2016-11-04 08:37, Alexander Maassen wrote: > Tried noc(a)google.com? > > Kind regards, > > Alexander Maassen > > - Technical Maintenance Engineer Parkstad Support BV > - Maintainer DroneBL > - Peplink Certified Engineer > > -------- Oorspronkelijk bericht -------- > Van: Fredrik Holmqvist / I2B <fredrik(a)i2b.se> > Datum: 03-11-16 15:25 (GMT+01:00) > Aan: nanog(a)nanog.org > Onderwerp: Google contact needed to help resolve captcha issue > > Hi. > > We have a customer who have their /32 IPv6 block captcha blocked, and > also their /19 IPv4 have been blocked with captchas. > The big issue is that it doesn't help to solve the captchas, there is > a > new one directly after and solving it gives a new one and so it goes > on > till you move to Bing do do searches. > Even parts of their netblocks that arn't in use are blocked, and have > been for 3 weeks now. > We have tried to contact google, but no one gets back. There is no > useful information on how to solve the issue either. > > Would be great to have a tool like SPAMhaus or other RBLs, where you > as > a ISP can see the offending IPs and take care of the problem (if > there > is one). > > -- > Fredrik Holmqvist > I2B (Internet 2 Business) > +46-70-740 5033 -- Fredrik Holmqvist I2B (Internet 2 Business) 070-740 5033

1 0

Two upcoming "ARIN on the Road" events - Nashville and Oklahoma City
by John Curran 04 Nov '16

04 Nov '16

NANOGers - Just a reminder that there are two "ARIN on the Road” events coming up – in each we will cover a range of registry related topics including DNSSEC, RPKI, ARIN tools and services, and more. We will be in Nashville on 10 November 2016, and Oklahoma City on 8 December 2016. These events are open to all and registration is free. For more information (including venue, agenda, and registration), go to the ARIN Meetings page: https://www.arin.net/participate/meetings/index.html Thanks! /John John Curran President and CEO ARIN

1 0

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

[NANOG-announce] NANOG Registration Fee Changes
by Dave Temkin 03 Nov '16

03 Nov '16

Greetings, NANOGers- In February 2016, the Board began to review and discuss how best to achieve our stated financial and organizational objectives while ensuring NANOG meetings and associated agendas remain peer reviewed and free of any external financial dependence or influence. NANOG Strategic Goals are: - Maintain Educational 501(c)(3) Non-Profit status - Maintain Membership Policies and Procedures - Maintain tri-annual, peer-reviewed NANOG Conferences - Maintain community email list(s) and archive - Maintain public presentation archives - Adherence to NANOG Financial Controls and Reserve Policy - Ensure funding to provide educational outreach - Continue - Discounted student registration fee - Continue - College Immersion Program - Revised scholarship program (Combine Postel and Fellowship, convert to tuition based) - Revise and reintroduce education courses - Continue to drive increases in member value It is understood that NANOG conferences are, by far, the largest asset of this organization. It is the delivery mechanism for several of the NANOG strategic goals. At the same time, it is also the largest area of concern when planning how best to achieve those goals. The registration fee was last increased in February 2008, while expenses related to producing NANOG meetings have continued to rise with both inflation and breadth of programs and benefits offered. The current meeting registration fee does not cover the cost of producing a NANOG meeting without external funding associated with the NANOG sponsorship program. Thus, in order to maintain our peer reviewed program and funding independence, the following registration fees schedule will apply beginning with NANOG 69: Existing NANOG 69 & Forward - Early: $450 $550 - Standard: $525 $650 - Late: $600 $750 - On-site: $675 $950 The member discount of $25 for all registration fees will continue to apply. The Board is confident that these fees set us on the correct path to adhere to our reserve policy and ensure that the organization is protected in the event that we were faced with unforeseen circumstances. The Board met again after the initial announcement of these registration fee increases at NANOG 68 to review the valuable feedback provided. We decided that it was in the best interests of the organization to move forward with these fee increases immediately and to programatically consider our fees on an annual basis. For the NANOG Board of Directors, Dave Temkin Chair _______________________________________________ NANOG-announce mailing list NANOG-announce(a)mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Google contact needed to help resolve captcha issue
by Fredrik Holmqvist / I2B 03 Nov '16

03 Nov '16

Hi. We have a customer who have their /32 IPv6 block captcha blocked, and also their /19 IPv4 have been blocked with captchas. The big issue is that it doesn't help to solve the captchas, there is a new one directly after and solving it gives a new one and so it goes on till you move to Bing do do searches. Even parts of their netblocks that arn't in use are blocked, and have been for 3 weeks now. We have tried to contact google, but no one gets back. There is no useful information on how to solve the issue either. Would be great to have a tool like SPAMhaus or other RBLs, where you as a ISP can see the offending IPs and take care of the problem (if there is one). -- Fredrik Holmqvist I2B (Internet 2 Business) +46-70-740 5033

1 0

Syn flood to TCP port 21 from priveleged port (80)
by Oleg A. Arkhangelsky 02 Nov '16

02 Nov '16

7 13

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

DNS Services for a registrar
by Ryan Finnesey 02 Nov '16

02 Nov '16

We need to provide DNS services for domains we offer as a registrar. We were discussing internally the different options for the deployment. Does anyone see a down side to using IaaS on AWS and Azure? We were also kicking around the idea of a PaaS offering and using Azure DNS or AWS Route 53. Cheers Ryan

19 29