October 2016 - Test - lists.nanog.org

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

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

Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension
by Ken Chase 01 Nov '16

01 Nov '16

re more general 'network utilities' and scripts: http://sizone.org/m/hacks/cidrmath.pl adds and removes subnets from networks giving list of remaining/aggregated (sub)nets. I couldnt find an online calculator that does this, most are just for 'translation' from subnet masks<>cidr or cisco inverse masks, etc. Wrote it years ago cuz I had an itch. The included perl module populates a hash entry per ip and I didnt want to write my own, so uses lots of ram+cpu on big ops (/8 - /9 for eg). But great for earthly operations like /23 - /27 + /28. Yes I should start my own git repo, but i've been lazy. No warranties provided. If anyone has a faster/better one, that'd be handy. /kc -- Ken Chase - ken(a)sizone.org Toronto & Guelph Canada

2 1

Help interpret a strange traceroute?
by Randy 01 Nov '16

01 Nov '16

Happy monday all! Any idea how a traceroute (into my network) could end up this fubar'd? Discovered this wierd routing while investigating horrendously slow speeds (albeit no packet loss) to a particular ISP abroad. It's like - coming into us - the packets are taking every available path, simultaniously. Tracing back to him looks perfectly normal. Thank you in advance for any comments on or off list. Him to us: traceroute to mirror.ash.fastserv.com (208.85.240.29), 64 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 1.552 ms 1.522 ms 1.261 ms 2 br1.l.hiweb.ir (46.224.0.12) 17.750 ms 18.932 ms 18.811 ms 3 172.16.5.65 (172.16.5.65) 18.505 ms 20.044 ms 18.414 ms 4 int.gr1.s.hiweb.ir (46.224.0.125) 19.096 ms 18.447 ms 18.752 ms 5 int.gr1.l.hiweb.ir (46.224.0.117) 18.454 ms 18.768 ms 103.441 ms 6 10.21.252.166 (10.21.252.166) 66.308 ms 18.728 ms 18.867 ms 7 * * * 8 185.100.209.139 (185.100.209.139) 162.126 ms ae5.istanbul1.ist.seabone.net (93.186.132.212) 210.124 ms 126.208 ms 9 et7-1-0.franco71.fra.seabone.net (195.22.214.131) 102.694 ms if-ae-9-3.tcore1.pvu-paris.as6453.net (195.219.87.14) 189.955 ms 185.100.209.197 (185.100.209.197) 218.539 ms 10 te0-3-0-4.rcr21.b023101-0.lon01.atlas.cogentco.com (149.14.144.89) 201.223 ms 215.996 ms 185.100.209.1 (185.100.209.1) 164.381 ms 11 if-ae-2-2.tcore2.av2-amsterdam.as6453.net (195.219.194.6) 199.161 ms be2950.ccr22.lon01.atlas.cogentco.com (130.117.2.109) 216.648 ms if-ae-3-6.tcore1.l78-london.as6453.net (80.231.130.85) 271.750 ms 12 if-ae-4-2.thar1.njy-newark.as6453.net (80.231.130.34) 183.984 ms * be2814.ccr42.ams03.atlas.cogentco.com (130.117.0.141) 109.045 ms 13 if-ae-1-3.thar2.njy-newark.as6453.net (216.6.57.2) 207.371 ms be2870.ccr41.lon13.atlas.cogentco.com (154.54.58.173) 186.804 ms be12488.ccr42.lon13.atlas.cogentco.com (130.117.51.41) 190.236 ms 14 if-ae-14-14.tcore2.nto-new-york.as6453.net (66.198.111.126) 203.156 ms if-ae-9-2.tcore1.n75-new-york.as6453.net (63.243.128.122) 273.177 ms be2807.ccr42.dca01.atlas.cogentco.com (154.54.40.110) 235.632 ms 15 66.110.96.134 (66.110.96.134) 182.695 ms be2806.ccr41.dca01.atlas.cogentco.com (154.54.40.106) 278.593 ms 240.075 ms 16 66.110.96.142 (66.110.96.142) 245.454 ms be3084.ccr41.iad02.atlas.cogentco.com (154.54.30.66) 191.973 ms be3083.ccr41.iad02.atlas.cogentco.com (154.54.30.54) 240.740 ms 17 te0-0-0-0.nr13.b023801-0.iad01.atlas.cogentco.com (154.24.36.18) 257.027 ms be3083.ccr41.iad02.atlas.cogentco.com (154.54.30.54) 236.617 ms hu-1-3-0-2-cr02.newyork.ny.ibone.comcast.net (68.86.83.97) 221.186 ms 18 be-10102-cr02.ashburn.va.ibone.comcast.net (68.86.85.161) 194.766 ms 250.493 ms be-10203-cr01.newark.nj.ibone.comcast.net (68.86.85.185) 191.052 ms 19 be-10102-cr02.ashburn.va.ibone.comcast.net (68.86.85.161) 197.694 ms te0-0-2-0.nr11.b023801-0.iad01.atlas.cogentco.com (154.24.36.2) 266.914 ms 235.444 ms 20 te0-0-2-3.nr11.b023801-0.iad01.atlas.cogentco.com (154.24.36.6) 255.756 ms 38.88.249.210 (38.88.249.210) 216.677 ms te0-0-2-0.nr11.b023801-0.iad01.atlas.cogentco.com (154.24.36.2) 211.364 ms 21 208.85.240.29 (208.85.240.29) 274.692 ms 212.896 ms ash01-mls-dc-core-a.latisys.net (67.217.175.37) 208.976 ms And back to him: traceroute to 46.224.145.65 (46.224.145.65), 30 hops max, 60 byte packets 1 104.153.64.146 (104.153.64.146) 22.067 ms 22.049 ms * 2 xe-3-1-1.er1.iad10.us.above.net (208.185.24.1) 0.398 ms 0.392 ms 0.420 ms 3 zayo-tata.iad10.us.zip.zayo.com (64.125.13.170) 0.708 ms 0.580 ms 0.623 ms 4 if-ae-11-2.thar2.NJY-Newark.as6453.net (216.6.87.138) 92.900 ms if-ae-11-3.thar2.NJY-Newark.as6453.net (216.6.87.242) 92.802 ms if-ae-11-4.thar2.NJY-Newark.as6453.net (216.6.87.169) 97.177 ms 5 if-ae-1-3.thar1.NJY-Newark.as6453.net (216.6.57.1) 92.940 ms 93.008 ms 89.431 ms 6 if-ae-8-2.tcore1.LDN-London.as6453.net (66.198.70.174) 97.315 ms 96.049 ms 95.855 ms 7 if-ae-17-2.tcore1.L78-London.as6453.net (80.231.130.129) 98.074 ms if-ae-3-6.tcore1.PYE-Paris.as6453.net (80.231.130.86) 92.733 ms 92.898 ms 8 if-ae-2-2.tcore1.PVU-Paris.as6453.net (80.231.154.17) 93.636 ms if-ae-3-6.tcore1.PYE-Paris.as6453.net (80.231.130.86) 97.917 ms 98.363 ms 9 if-ae-2-2.tcore1.PVU-Paris.as6453.net (80.231.154.17) 100.909 ms if-ae-9-3.tcore2.FNM-Frankfurt.as6453.net (195.219.87.13) 92.055 ms 93.173 ms 10 195.219.87.46 (195.219.87.46) 208.894 ms 209.042 ms if-ae-9-2.tcore2.FNM-Frankfurt.as6453.net (195.219.87.9) 94.718 ms 11 * 195.219.87.46 (195.219.87.46) 209.640 ms int.gr1.s.hiweb.ir (46.224.0.118) 202.201 ms 12 int.cr1.s.hiweb.ir (46.224.0.126) 205.150 ms * * 13 * * * 14 int.gr1.s.hiweb.ir (46.224.0.118) 201.803 ms 201.799 ms int.cr1.s.hiweb.ir (46.224.0.126) 201.819 ms 15 int.cr1.s.hiweb.ir (46.224.0.126) 204.952 ms 198.969 ms * 16 46.224.145.65 (46.224.145.65) 210.507 ms 211.144 ms 206.998 ms

7 6

Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24
by Selphie Keller 31 Oct '16

31 Oct '16

Hi, I noticed this thread and wanted to provide some information, subnet 103.11.67.0/24 is not an illicit squat this subnet is apart of 103.11.64.0/22 which was transferred from APNIC to ARIN back this last February and is listed publicly at https://www.arin.net/knowledge/statistics/transfers.html within the "Inter-RIR Transfers to the ARIN Region", also WebNX AS18450 does have the LOA's on file for the subnet. I do agree with the others in this thread about the lack of WHOIS as looking up 103.11.67.0/24 does indeed provide very little information to go on so I can see how this could be misunderstood as a squat of the subnet due to the lack of whois information which is an updating issue ARIN/APNIC's part, hopefully can get this resolved so that ARIN shows the chain: APNIC -> 103.11.64.0/22 -> then to WebNX 103.11.67.0/24, which would show the full chain and a proper abuse contact for this subnet. As for the spamming/spam email part of this thread, please send the said spam email/emails with headers in question to abuse(a)webnx.com, this way we can investigate and sort it out. We do take spamming seriously and will work quickly to get it resolved. -Selphie K

2 2

Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24
by Ronald F. Guilmette 31 Oct '16

31 Oct '16

I just got a spam from 103.11.67.105. The containing /24 appears to be unallocated APNIC space. RIPE tools seem to say that AS18450 has been routing this block since around May 23rd. I see this kind of stuff almost every day now, it seems. And you know, there are days when I really do start to wonder "Has the Internet gone mad?" I'm going to call these turkeys right now and just ask them, point blank, what the bleep they think they're doing, routing unallocated APNIC space. But if history is any guide, this is probably going to turn out to be another one of these "absentee landlord" kinds of ASes, where all they have is an answering machine. I have to either laugh or cry when I see people posting here about the non-functionality of abuse@ email addresses, and then see other people saying "Well, this is why all ASes also have phone numbers." I wish I had a dollar for every AS I had ever tried to contact where -neither- the abuse@ address -nor- the phone number got me to any actual human being. Regards, rfg

12 27

AS6461 (Zayo) LAS->ORD Packet Loss
by Brandon Yarnell 31 Oct '16

31 Oct '16

Seeing some packet loss between LAS and ORD on the Zayo backbone. Long wait times / no answer on the ncc line, no auto-response/ticket creation after sending email. Anybody know whats up? Alerts cleared after taking the peers out of route. -- =========================== Brandon Yarnell Senior Network Engineer | Technical Operations O: (720) 515-3376

2 1

FYI: Net Neutrality in Canada
by Jean-Francois Mezei 30 Oct '16

30 Oct '16

This is a heads up, the CRTC (Canada's FCC) is holding a week long hearing on net neutrality in Canada ("differential pricing" is the used). Canada has had its "ITMP" (Internet Traffic Management Practices) policy since 2009 which deals with unfair throttling, and now, we are arguing on zero rating and sponsored content stuff). It will be broadcasted at http://www.cpac.ca (at bottom of home page there should be a selection for the CRTC hearing). Note: you can choose between english, french of floor (untranslated). Days generally start at 09:00. Can end at any time. Either @CRTCeng or @CRTChearings will be tweeting links to presentations as each presentation begins. hashtag: #CRTC #Diffpricing Facebook did not wish to appear but was "invited". Last time the CRTC did that, it was with Netflix and Google and sparks flew ("you don't regulate us, we don't have to answer"). (It appears on Tuesday right after me, so they should be roughly ~ 10:30 or 11:00.) The agenda: http://www.crtc.gc.ca/Telecom/eng/HEARINGS/2016/ag31_10.htm The original Notice of Consultation: > http://crtc.gc.ca/eng/archive/2016/2016-192.htm?_ga=1.136052530.24154879.14… And the record of the consultation: > https://services.crtc.gc.ca/pub/instances-proceedings/Default-defaut.aspx?E… Note: this started with a different proceeding in September 2015 2 parts 1 filings against Vidéotron who started zero rated music on its wireless service for music services that Vidéotron approved/selected. > https://services.crtc.gc.ca/pub/instances-proceedings/Default-Defaut.aspx?l…

2 3