December 2018 - Test - lists.nanog.org

Spectrum technical contact
by Josh Luthman 23 Jan '20

23 Jan '20

We have had a DOS attack for over 12 hours. I simply want them to null route or black hole an address. The traffic is filling one of our circus with them. The farthest I got was them telling me they can't do route changes because we're not public safety. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373

9 19

Cellular backup connections
by Dovid Bender 24 Jun '19

24 Jun '19

Hi All, I finally got around to setting up a cellular backup device in our new POP. I am currently testing with T-Mobile where the cell signal strength is at 80%. The connection is 4G. When SSH'ing in remotely the connection seems rather slow. Ping times seem to be all over the place (for instance now I am seeing: rtt min/avg/max/mdev = 174.142/336.792/555.574/99.599 ms) . Is that just cellular or is that more related to the provider and the location where I am? I could in theory test with VZ and ATT as well. With Verizon they charge $500.00 just to get a public IP and I want to avoid that if possible. Thanks and sorry in advance if this is off topic.

15 19

Disney+ CDN
by Aaron Graves 28 Apr '19

28 Apr '19

Anyone know what Disney is planning on doing for streaming content distribution once they leave Netflix? Would be nice if they'd provide an on-prem cache server. AG

14 18

JunOS Fusion Provider Edge
by Mehmet Akcin 12 Apr '19

12 Apr '19

Hey there Any ISP using Juniper Fusion Provider Edge? https://www.juniper.net/documentation/en_US/junos/information-products/path… I am trying to chat with an engineer besides Juniper engineers to understand how buggy (or not) this is to go on production for a medium size ISP. Any feedback good/bad appreciated. -- Mehmet +1-424-298-1903

10 10

Arista Layer3
by Romeo Czumbil 09 Mar '19

09 Mar '19

So I've been using Arista as layer2 for quite some time, and I'm pretty happy with them. Kicking the idea around to turn on some Layer3 features but I've been hearing some negative feedback. The people that I did hear negative feedback don't use Arista themselves. (they just heard....) So do we have any Arista L3 people out here that can share some negatives or positives? Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP Maybe 20k routes (no full internet routes) 7050 Series 7280 Series -Romeo

20 33

WIndows Updates Fail Via IPv6
by Mark Tinka 07 Mar '19

07 Mar '19

Hi all. Anyone ever figured out why Windows updates fail when the computer has an IPv6 connection? Google has tickets and tickets of this to and outside of Microsoft since 2013, with no real solution or answer as to what the problem actually is. In essence, many of the solutions out there point toward making sure the updates do not occur over IPv6, which, in effect, is the same as disabling it. I have a family PC at home running Windows 10 Pro, and noticed updates would fail in recent months. It took me a moment to realize that this started happening only after I enabled IPv6 in the TCP/IP stack. Disabling it immediately solves the issue. Quite odd that this is happening in 2018... Mark.

20 49

Re: How to choose a transit provider?
by nanog-isp＠mail.com 05 Mar '19

05 Mar '19

Mike Hammett wrote: > Usually, DIA (as transit delivered to a customer) is more expensive than transport + transit + small colo > (1U\2U stuff) + IX... at least as observed by many of my brethren. Is this really true in the general case? Adding colo and IX to transport and transit involves at least one additional cross connect and an IX port fee. This is likely to push the total above the pure DIA price. However, regardless of how the numbers pencil out, this isn't really a fair comparison. For small ISPs, the yardstick against which adding an IX to the mix is usually measured against is the marginal cost of IP transit. Given that the cost of transport is fixed, is it more economical to buy more IP transit or to join an IX? Transit being so cheap means that joining an IX isn't always so enticing from a financial perspective, although there are other non-monetary benefits. I certainly subscribe to the notion that transport + transit is usually less expensive than DIA, but this does depend on the market and location. Jared

4 4

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