- Test - lists.nanog.org

Colombia
by Mehmet Akcin 06 Feb '19

06 Feb '19

Hi there I am looking to meet with folks who has done work in the past shipping network gear, or sourcing locally network gear/servers to/from colombia (Bogota). If you have any experience with hosting / colocation in Colombia please contact me offlist - thank you Mehmet -- Mehmet +1-424-298-1903

1 0

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

DNS admin request Microsoft / Comcast
by Neil J. McRae 05 Feb '19

05 Feb '19

Folks, If there is a Microsoft lead DNS person here and a comcast lead DNS person here can you contact me off-list please. Cheers, Neil McRae.

2 1

Any detail on 3356 outage this morning?
by David Hubbard 05 Feb '19

05 Feb '19

Curious if anyone has detail on the cause of the CenturyLink/L3 outage this morning? Their master ticket response is not exactly confidence inspiring; hey, routers nationwide decided to reboot, but don’t worry, service was restored with no manual intervention…. *** CASCADED EXTERNAL NOTES 05-Feb-2019 14:06:31 GMT From CASE: 15846504 - Event Event Conclusion Summary Outage Start: February 05, 2019 11:00 GMT Outage Stop: February 05, 2019 12:37 GMT Root Cause: Multiple devices rebooted impacting IP services in multiple markets. Fix Action: Services restored with no CenturyLink intervention. Reason for Outage (RFO) Summary: On February 05, 2018 at 11:00 GMT, CenturyLink identified a service impact in all markets network wide. The IP NOC reported multiple devices rebooted impacting IP services in multiple markets. Services restored on their with no CenturyLink intervention. The IP NOC engaged the equipment vendor, Tier III Technical Support, and Operations Engineering to conduct a post analysis review of the incident. This service impact has concluded; if additional issues are experienced, please contact the CenturyLink Repair Center.

2 1

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

oneamerica.com Contact
by Dan White 04 Feb '19

04 Feb '19

If there is a representative from OneAmerica here, please contact me off-list. -- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite(a)mybtc.com http://www.btcbroadband.com

1 0

IP Geo-Location
by Ben Logan 04 Feb '19

04 Feb '19

Hi, What's the proper way to specify the location of prefixes within a larger prefix? For example, we purchased a /17 and it is registered in ARIN as being located in our home town. However, smaller prefixes within that /17 are located in different areas of VA and NC, and people are complaining about location services showing them in the wrong area. Not sure how to "properly" fix it. Thanks, Ben -- <https://img.beta.newoldstamp.com/r/13887/p> Ben Logan Senior Network Engineer | Working Lead Wilkes Communications | RiverStreet Networks Address: 1400 River St Wilkesboro, NC 28697 Email: benlogan(a)myriverstreet.net Phone: 336-973-9075 Mobile: 336-452-8072 wilkes.net <https://www.wilkes.net> myriverstreet.net <https://www.myriverstreet.net> <https://img.beta.newoldstamp.com/r/13833/facebook> <https://img.beta.newoldstamp.com/r/13833/twitter> <https://img.beta.newoldstamp.com/r/13887/youtube> <https://img.beta.newoldstamp.com/r/13833/linkedin> <https://img.beta.newoldstamp.com/r/13833/instagram> This email transmission contains information which may be confidential and/or privileged. The information is intended to be for the use of the individual or entity named on this transmission. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this email information is prohibited. If you have received this email in error, please notify the sender to arrange for retrieval of the original documents. Thank you.

3 2

Frontier Communications Cisco DSL
by Mike Hammett 04 Feb '19

04 Feb '19

If any of you have a Cisco 2811 connected via DSL to Frontier, could you hit me up offlist? Likewise, if anyone from Frontier can help me, that'd be great. Most of the Cisco DSL documentation I'm running to is forever old and doesn't necessarily work on newer IOS releases or different configs at Frontier. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

1 0

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

Re: [EXTERNAL] Re: RTBH no_export
by John Kristoff 04 Feb '19

04 Feb '19

On Mon, 4 Feb 2019 09:01:20 +0000 i3D.net - Martijn Schmidt <martijnschmidt(a)i3d.net> wrote: > Cogent does let you use RTBH, but on a separate BGP session to a > blackhole server. So it's a bit more hassle to set it up policy-wise, > because it deviates from the standard. Same story for "former > GlobalCrossing", now CenturyLink's AS3549, which is still used for LATAM > and Asia. There are other providers that do this besides those you listed. I'm not sure one way or the other is truly "the standard" approach, but there may be an advantage and potentially good reason to have a separate session. If a no-multihop peering link/session is down, you might still be able to establish a RTBH peering session via another path. That may be what you need to get that direct neighbor back up. :-) John

1 0