January 2019 - Test - lists.nanog.org

Quick Script to check the uptime of ASR920's
by Erik Sundberg 20 Feb '19

20 Feb '19

All, I just created a quick script to check the uptime of a ASR920 via SNMP if you have a fairly long list of devices. It's a simple bash script and snmpwalk version 2c. Figured I would share it with you. Happy Friday Grab the code from GitHub: https://github.com/esundberg/CiscoRouterUptime It's a quick and dirty script and my first repo on github. Let me know if there any issues with it. Output Format in CSV DeviceName, IP, Uptime in Days, OK/Warning I set my warning to 800 Days, you can change this in the code ASR920list.txt ------------- ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey ASR920-2.SEA1, 192.168.28.2, SuperSecretSNMPKey ~~~~snip you get the idea~~~~ Output [user@Linux]$ ./CiscoRouterUptime.sh ASR920list.txt ASR920-1.SEA1, 192.168.28.1, 827, WARNING ASR920-2.SEA1, 192.168.28.2, 827, WARNING ASR920-2.ATL1, 192.168.23.2, 828, WARNING ASR920-1.ATL1, 192.168.23.1, 813, WARNING ASR920-1.CHI1, 192.168.21.3, 828, WARNING ASR920-1.NYC1, 192.168.25.1, 787, OK ASR920-2.CHI1, 192.168.21.4, 720, OK ASR920-3.CHI1, 192.168.21.5, 720, OK ASR920-1.DAL1, 192.168.26.3, 488, OK ASR920-4.CHI1, 192.168.21.6, 142, OK ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

5 7

Network Speed Testing and Monitoring Platform
by Colton Conor 19 Feb '19

19 Feb '19

As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net, or worse sending a tech out with a laptop to do the same thing. What opensource and commercial options are out there?

26 39

adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?
by nusenu 14 Feb '19

14 Feb '19

Dear NIST RPKI Monitor Team, thanks for creating and maintaining the RPKI Monitor https://rpki-monitor.antd.nist.gov/#rpki_adopters I've seen your graphs in multiple routing security presentations :) What do you think about adding graphs that show the amount of actually unreachable prefixes and IP space? (prefix where no alternative valid/unknown announcement exists) I think such graphs would help us focus on those prefixes that we should have to tackle first. This page contains examples of INVALID prefixes that would still be reachable in a route origin validating environment (see the RPKI validator screenshots): https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c kind regards, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

5 8

CGNAT
by Ahmed Munaf 07 Feb '19

07 Feb '19

Hi, Any recommendation regarding CGNAT appliance who try it and which brand is the best from his perspective! The throughput which I want to pass through the CGNAT is about 40Gbits and number of subscribers are about 40,000 subscribers. Regards, Ahmed

10 13

BGP Experiment
by Italo Cunha 06 Feb '19

06 Feb '19

NANOG, We would like to inform you of an experiment to evaluate alternatives for speeding up adoption of BGP route origin validation (research paper with details [A]). Our plan is to announce prefix 184.164.224.0/24 with a valid standards-compliant unassigned BGP attribute from routers operated by the PEERING testbed [B, C]. The attribute will have flags 0xe0 (optional transitive [rfc4271, S4.3]), type 0xff (reserved for development), and size 0x20 (256bits). Our collaborators recently ran an equivalent experiment with no complaints or known issues [A], and so we do not anticipate any arising. Back in 2010, an experiment using unassigned attributes by RIPE and Duke University caused disruption in Internet routing due to a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other similar bugs have been patched [e.g., CVE-2013-6051], and new BGP attributes have been assigned (BGPsec-path) and adopted (large communities). We have successfully tested propagation of the announcements on Cisco IOS-based routers running versions 12.2(33)SRA and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and 1.6.3. We plan to announce 184.164.224.0/24 from 8 PEERING locations for a predefined period of 15 minutes starting 14:30 GMT, from Monday to Thursday, between the 7th and 22nd of January, 2019 (full schedule and locations [E]). We will stop the experiment immediately in case any issues arise. Although we do not expect the experiment to cause disruption, we welcome feedback on its safety and especially on how to make it safer. We can be reached at disco-experiment(a)googlegroups.com. Amir Herzberg, University of Connecticut Ethan Katz-Bassett, Columbia University Haya Shulman, Fraunhofer SIT Ítalo Cunha, Universidade Federal de Minas Gerais Michael Schapira, Hebrew University of Jerusalem Tomas Hlavacek, Fraunhofer SIT Yossi Gilad, MIT [A] https://conferences.sigcomm.org/hotnets/2018/program.html [B] http://peering.usc.edu [C] https://goo.gl/AFR1Cn [D] https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experim… [E] https://goo.gl/nJhmx1

35 96

Calling LinkedIn, Amazon and Akamai @ DE-CIX NY
by Jason Lixfeld 05 Feb '19

05 Feb '19

Hi, In late October 2018, DE-CIX announced that they would be renumbering their IPv4 address block in New York between 01-28-19 and 01-30-19. This was followed by numerous reminders in months, weeks and even days leading up to the renumbering activity. The renumbering activity has come and gone, but LinkedIn, Amazon and Akamai are still using the old IPs. If three months has gone by and the numerous reminders that have been sent have resulted in these organizations still living on the old IP space, it seems to me that there may be some sort of a disconnect between who receives the notifications from IXPs and how they are filtered upstream. I’m hopeful that the eyeballs who read this list are some of those folks who should have received the notifications from DE-CIX, or can at least filter the info back downstream to whoever can perform the renumbering activity. Thanks.

18 28

ARIN NS down?
by Suresh Ramasubramanian 04 Feb '19

04 Feb '19

couldn't get address for 'ns1.arin.net': not found couldn't get address for 'ns2.arin.net': not found couldn't get address for 'u.arin.net': not found couldn't get address for 'ns3.arin.net': not found dig: couldn't get address for 'ns1.arin.net': no more srs@Sureshs-MacBook-Pro-2 19:56:18 <~> $ dig +trace +norec whois.arin.net ; <<>> DiG 9.10.6 <<>> +trace +norec whois.arin.net ;; global options: +cmd . 2230 IN NS m.root-servers.net. . 2230 IN NS b.root-servers.net. . 2230 IN NS c.root-servers.net. . 2230 IN NS d.root-servers.net. . 2230 IN NS e.root-servers.net. . 2230 IN NS f.root-servers.net. . 2230 IN NS g.root-servers.net. . 2230 IN NS h.root-servers.net. . 2230 IN NS i.root-servers.net. . 2230 IN NS j.root-servers.net. . 2230 IN NS a.root-servers.net. . 2230 IN NS k.root-servers.net. . 2230 IN NS l.root-servers.net. . 2230 IN RRSIG NS 8 0 518400 20190121050000 20190108040000 16749 . JqXTRb0qik0Iy1zDpwKRfKr1iZjTeiJRTk1GCfIWh9dFFvhN0c7Fiz6H lbNfhgQbPsacG0b/1I3rguS13H2guX7apppK2w88h+z8mzym2Bw1C1HR ZR3ocj/jHLJbMqHdQ+DFyRdw/AxCXBdhnbX46C8+unhQ03D/MzS0M0t4 vgadYi7BN4sa+iZIilwFV56n2dOfpzyO+evVbcnTLRZ6D4bjCHZLCtO8 EDziAPUbVAPZWiflb7/Y2dECe5gbOuGYYU/xv/Pal5+v9cjgMjcf8buG S+iTIL/lnus0JJSRDmkM6yzfYMBXC2ZqhOp+Ls+EfvmqFjIZzi394XCi pdKRZw== ;; Received 525 bytes from 10.0.0.1#53(10.0.0.1) in 40 ms net. 172800 IN NS g.gtld-servers.net. net. 172800 IN NS c.gtld-servers.net. net. 172800 IN NS j.gtld-servers.net. net. 172800 IN NS e.gtld-servers.net. net. 172800 IN NS h.gtld-servers.net. net. 172800 IN NS k.gtld-servers.net. net. 172800 IN NS m.gtld-servers.net. net. 172800 IN NS i.gtld-servers.net. net. 172800 IN NS f.gtld-servers.net. net. 172800 IN NS b.gtld-servers.net. net. 172800 IN NS a.gtld-servers.net. net. 172800 IN NS d.gtld-servers.net. net. 172800 IN NS l.gtld-servers.net. net. 86400 IN DS 35886 8 2 7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE net. 86400 IN RRSIG DS 8 1 86400 20190124130000 20190111120000 16749 . uahpltN27UkKaFJRaAU1on+IpC2lpgZo84XEM7Pk7dQysKfSnqUkaVLY PXQf9kvgW5eOx/+BttQB2OWFLckJs8vv5ScOpz7dDhs8zR2FPLm93HTD 4F/XEKDNOQbFGSA3g4pZq3fatY7kFEkV9sFTH90WqJt0sXe64LYFcwr2 FtrJaS/yhEV4XDbsN3RLkBP58bf526LPpvonwSZsMUTDZcnXtUnc57ZI dlTHg2snNhVWu4qJfHDsEQPwOZagRXJhjlRT8Ox/7HwXvplmRfmeuhZb Vj5kdiY+3j0RTxpLRCG/SZRDIRcvdFKh9umdwQvAzuTS0xzO8OyPw9q8 8QCCYg== ;; Received 1171 bytes from 192.112.36.4#53(g.root-servers.net) in 207 ms arin.net. 172800 IN NS ns1.arin.net. arin.net. 172800 IN NS ns2.arin.net. arin.net. 172800 IN NS u.arin.net. arin.net. 172800 IN NS ns3.arin.net. arin.net. 86400 IN DS 48281 5 2 6EB0CCF325A8101A768C93D10CE084303D3714D4E92FEE53D6E683D2 22291017 arin.net. 86400 IN DS 48281 5 1 FCBF93357C8FE3247CECB2CD277F45EB955EE4CE arin.net. 86400 IN RRSIG DS 8 2 86400 20190117062448 20190110051448 6140 net. stuWyfC0PDuk2hNF/Bnz0lnypk+bA/slTa2KYznjmoLXDtq7v1obJq41 ZfloQKXuC7MnzpCQj70GU9ZESZq1/XU+u6wDmCqmEUbJ3kyrILxkVrln bTEySJWPmurpwUVzDVfvqFpXEOhWxOjDu6drZMcC3wG9EdPqBuFC6wlf FIQ= couldn't get address for 'ns1.arin.net': not found couldn't get address for 'ns2.arin.net': not found couldn't get address for 'u.arin.net': not found couldn't get address for 'ns3.arin.net': not found dig: couldn't get address for 'ns1.arin.net': no more

10 15

RTBH no_export
by Roel Parijs 04 Feb '19

04 Feb '19

Hello NANOG, To minimize the impact of DDoS, I have setup RTBH. For our own customers, we can set the RTBH community ourselves towards our transit suppliers and this works well. For our BGP customers the problem is more complex. Our BGP customers can send us the RTBH community, and we will drop the traffic at our borders. Since we're only running a small network, we don't have the capacity to deal with large attacks. If we would be able to forward (and maybe alter it) this RTBH community towards our upstream providers, the impact on our network would be limited. However, the RFC states that an announcement tagged with the blackhole community should get the no_advertise or no_export community. What is your opinion on this ? Thanks in advance Roel

12 13

DNS Flag Day, Friday, Feb 1st, 2019
by Brian Kantor 02 Feb '19

02 Feb '19

Quoting from the web site at https://dnsflagday.net/ What is happening? The current DNS is unnecessarily slow and suffers from inability to deploy new features. To remediate these problems, vendors of DNS software and also big public DNS providers are going to remove certain workarounds on February 1st, 2019. This change affects only sites which operate software which is not following published standards. Are you affected? On that web page, there is a Domain Owner's test. You can enter a domain name and click 'test' and shortly receive a report of what was found regarding your domain's DNS servers. I somehow managed to miss the announcement of this upcoming event, even though I read this mailing list fairly closely. Perhaps it was announced somewhere else instead. I think it needs to be mentioned here if it hasn't already been. - Brian

17 47

Google you have a problem.
by Mark Andrews 01 Feb '19

01 Feb '19

[beetle:~/git/bind9] marka% fetch -v https://www.google.com/jsapi looking up www.google.com connecting to www.google.com:443 SSL connection established using ECDHE-RSA-AES128-GCM-SHA256 Certificate subject: /C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com Certificate issuer: /C=US/O=Google Trust Services/CN=Google Internet Authority G3 requesting https://www.google.com/jsapi fetch: https://www.google.com/jsapi: Bad Gateway [beetle:~/git/bind9] marka% curl -v https://www.google.com/jsapi * Trying 2607:f8b0:4007:80e::2004... * TCP_NODELAY set * Trying 172.217.14.100... * TCP_NODELAY set * Connected to www.google.com (2607:f8b0:4007:80e::2004) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /opt/local/share/curl/curl-ca-bundle.crt CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com * start date: Jan 15 13:15:00 2019 GMT * expire date: Apr 9 13:15:00 2019 GMT * subjectAltName: host "www.google.com" matched cert's "www.google.com" * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 * SSL certificate verify ok. > GET /jsapi HTTP/1.1 > Host: www.google.com > User-Agent: curl/7.63.0 > Accept: */* > < HTTP/1.1 502 Bad Gateway < Content-Length: 0 < Date: Thu, 31 Jan 2019 22:20:34 GMT < Content-Type: text/html; charset=UTF-8 < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" < * Connection #0 to host www.google.com left intact [beetle:~/git/bind9] marka% curl -4 -v https://www.google.com/jsapi * Trying 172.217.14.100... * TCP_NODELAY set * Connected to www.google.com (172.217.14.100) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /opt/local/share/curl/curl-ca-bundle.crt CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com * start date: Jan 15 13:15:00 2019 GMT * expire date: Apr 9 13:15:00 2019 GMT * subjectAltName: host "www.google.com" matched cert's "www.google.com" * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 * SSL certificate verify ok. > GET /jsapi HTTP/1.1 > Host: www.google.com > User-Agent: curl/7.63.0 > Accept: */* > < HTTP/1.1 502 Bad Gateway < Content-Length: 0 < Date: Thu, 31 Jan 2019 22:24:43 GMT < Content-Type: text/html; charset=UTF-8 < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" < * Connection #0 to host www.google.com left intact [beetle:~/git/bind9] marka% traceroute 172.217.14.100 traceroute to 172.217.14.100 (172.217.14.100), 64 hops max, 52 byte packets 1 172.30.42.65 (172.30.42.65) 1.340 ms 3.278 ms 1.673 ms 2 * * * 3 * * * 4 59.154.18.232 (59.154.18.232) 13.710 ms hu0-5-0-0.22btpr01.optus.net.au (59.154.18.234) 24.311 ms 13.662 ms 5 72.14.219.128 (72.14.219.128) 12.445 ms 43.781 ms 10.760 ms 6 108.170.247.74 (108.170.247.74) 12.743 ms 12.797 ms 108.170.247.59 (108.170.247.59) 14.167 ms 7 216.239.50.172 (216.239.50.172) 159.864 ms 162.324 ms 157.546 ms 8 108.170.230.130 (108.170.230.130) 147.234 ms 151.094 ms 152.088 ms 9 108.170.247.129 (108.170.247.129) 152.073 ms 149.194 ms 149.055 ms 10 108.170.230.137 (108.170.230.137) 149.697 ms 150.042 ms 74.125.252.75 (74.125.252.75) 149.363 ms 11 lax31s01-in-f4.1e100.net (172.217.14.100) 158.438 ms 147.982 ms 149.593 ms [beetle:~/git/bind9] marka% -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

2 5