- NANOG - lists.nanog.org

Career @ Micron21 - Working in Australia / Melbourne - Data Centre Experienced Network Engineer
by James Braunegg 10 Jan '20

10 Jan '20

Dear NANOG Happy 2020 I hope it's extremely successful for everyone within the NANOG community. Now anyone who didn't enjoy 2019 and is looking for a new start I am on the hunt for a Data Centre Experienced Network Engineer based in Melbourne Australia. (Master of BGP, eVPN, VXLAN, IS-IS, routing, switching, DDoS Mitigation etc) You can read all about the position here - https://www.seek.com.au/job/40631063?type=standout#searchRequestToken=11fab… If you are interested in joining me @ Micron21 then please reach out to me ASAP, so you can start 2020 Fresh with an awesome new career!! Happy to sponsor the candidate with the required visa to gain access to work full time in Australia. Looking forward to hearing from you Kindest Regards James Braunegg [cid:image001.png@01D280A4.01865B60] 1300 769 972<tel:1300%20769%20972> / 0488 997 207<tel:1300%20769%20972> james(a)micron21.com<mailto:james@micron21.com> www.micron21.com/<http://www.micron21.com/> [cid:image002.png@01D280A4.01865B60]<http://www.micron21.com/> [cid:image003.png@01D280A4.01865B60]<https://www.facebook.com/micron21/> [cid:image004.png@01D280A4.01865B60]<https://twitter.com/micron21> Follow us on Twitter<https://twitter.com/micron21> for important service and system updates. This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.

1 0

Cost Recovery Surcharge & Va Personal Property Tax Recovery for IP Transit
by Siyuan Miao 10 Jan '20

10 Jan '20

NANOG, We've recently signed contract of colocation + IP transit with a local provider in Northern Virginia. Co-location services is okay but we found something unusual on our IP transit invoices. - Va Personal Property Tax Recovery (1.8%) - Cost Recovery Surcharge (3%)? We've talked with our providers but they told us: > we use a tax engine that provides the taxes/rates to our services. If you would like further language on them, please let me know and I will have some one send that over. Has anyone else ran into this? If this is a legit "surcharge"? Also, IP transit isn't a property, why is there a "Property Tax" for IP transit? Regards, Siyuan Miao

12 14

RE: "Using Cloud Resources to Dramatically Improve Internet Routing"
by Aistis Zenkevičius 09 Jan '20

09 Jan '20

So, a bit like this then: https://noia.network/technology -Aistis -----Original Message----- From: NANOG <nanog-bounces(a)nanog.org> On Behalf Of Phil Pishioneri Sent: 2019 m. spalio 4 d., penktadienis 22:52 To: NANOG list <nanog(a)nanog.org> Subject: "Using Cloud Resources to Dramatically Improve Internet Routing" [Came up in some digest summary I receive] Using Cloud Resources to Dramatically Improve Internet Routing UMass Amherst researchers to use cloud-based ‘logically centralized control’ https://www.umass.edu/newsoffice/article/using-cloud-resources-dramatically… -Phil

7 8

help with diagnosing traffic blackhole to / from select akamai ranges?
by William McLendon 09 Jan '20

09 Jan '20

Good afternoon, we have a downstream customer originating a more specific /24 prefix, and when they do so, traffic sourced from that /24 prefix to at least a subset of akamai ranges (at minimum the 184.27.24.0/22 block at this time) are getting blackholed somewhere along the path either to or from, but i’m not sure how best to go about troubleshooting or getting assistance with diagnosing where the problem may be. from a device in the offending IP block I cannot ping or curl to www.akamai.com <http://www.akamai.com/> that resolves to 184.27.25.72, however from an IP outside the /24 specific prefix but still in their supernet range I am able to ping and get an HTTP 301 redirect response. Some other akamai prefixes like 23.73.0.0/20 seem to work without issue from what I can tell thus far. If the /24 prefix is removed, all works as expected via their covering announcement (which does return via their primary provider, as we are generally a backup path for their larger block). Any guidance the community can share as to how to go about trying to resolve I would greatly appreciate — this is the first time i’ve had to trace down a [seemingly random] reachability issue like this. Connectivity to other services seem ok from what I can gather so far, even to some other akamai ranges. from looking glass perspective it looks like the route is being accepted properly by our upstreams and other large providers like NTT, etc. I did send an email to noc(a)akamai.com <mailto:noc@akamai.com> but not sure that is the appropriate way to reach out for assistance or not, since we nor our downstream customer are direct customers or peers of theirs. Thanks, Will McLendon wimclend(a)gmail.com <mailto:wimclend@gmail.com>

4 4

Re: Cost Recovery Surcharge & Va Personal Property Tax Recovery for IP Transit
by Rob Seastrom 09 Jan '20

09 Jan '20

>> On Jan 6, 2020, at 10:30, William Herrin <bill(a)herrin.us> wrote: > >> - Va Personal Property Tax Recovery (1.8%) > If it's not written in to your contract, it's a breach of contract. Either way it's a deceitfully imposed surcharge, not a state tax. Virginia does not tax the sale of services like transit and colo. More, the only personal property tax I've heard of in Virginia is on motor vehicles. Hi Bill, It’s called “business tangible personal property tax”, and it’s technically levied by the counties, not by the state (although authorized by the legislature, as all local government activities must be in a Dillon’s Rule state). Loudoun’s page on this (chosen at random because I live here... and can see The Cloud’s Cloud from my house) is at https://www.loudoun.gov/1556/Business-Tangible-Personal-Property-Tax -r

3 2

Geo locate change for IP ?
by JASON BOTHE 08 Jan '20

08 Jan '20

Hi guys Something odd has happened and I’m not sure how to sort. One of our public prefixes, 205.174.3.0/24 issued from ARIN has suddenly had its geo changed and now everyone accessing the internet from it is showing up as a UK IP, London specifically. We announce this and every other prefix we have out all of our peers globally and are pretty mystified on how this happened and how to resolve. Any help is appreciated. Thanks Jason

3 3

ICANN extracts $20m signing fee for $1bn dot-com price increases and guess who's going to pay for it?
by Dan Hollis 08 Jan '20

08 Jan '20

https://www.theregister.co.uk/2020/01/07/icann_verisign_fees/ 98% of the comments were opposed. How many / which companies would have to get onboard in order to get enough support for an icann alternative? Is such a thing even feasible? -Dan

6 5

Spoofer Report for NANOG for Dec 2019
by CAIDA Spoofer Project 08 Jan '20

08 Jan '20

In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Dec 2019: ASN Name Fixed-By 32 STANFORD 2019-12-11 19624 SERVERROOM 2019-12-28 62957 HOSPITALITY-NETWORK 2019-12-30 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Dec 2019: ASN Name First-Spoofed Last-Spoofed 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2019-12-27 6128 CABLE-NET-1 2016-09-03 2019-12-29 20412 CLARITY-TELECOM 2016-09-30 2019-12-31 20001 TWC-20001-PACWEST 2016-10-08 2019-12-06 6181 FUSE-NET 2016-10-10 2019-12-31 174 COGENT-174 2016-10-21 2019-12-31 32440 LONI 2016-11-03 2019-12-27 12083 WOW-INTERNET 2016-11-09 2019-12-31 9009 M247 2017-01-10 2019-12-30 701 UUNET 2017-06-14 2019-12-24 63296 AMARILLO-WIRELESS 2017-09-01 2019-12-31 546 PARSONS-PGS-1 2017-11-20 2019-12-30 12222 AKAMAI 2018-02-14 2019-12-31 11827 WSU 2018-05-07 2019-12-13 393564 SPOKANE 2018-06-05 2019-12-31 225 VIRGINIA 2018-06-18 2019-12-17 33452 RW 2018-09-19 2019-12-02 20448 VPNTRANET-LLC 2018-09-20 2019-12-30 63275 RADIOWIRE 2019-02-07 2019-12-09 19531 NODESDIRECT 2019-03-14 2019-12-17 8047 GCI 2019-04-11 2019-12-31 10745 ARIN-ASH-CHA 2019-04-29 2019-12-12 46573 GLOBAL-FRAG-NETWORKS 2019-05-16 2019-12-14 29933 OFF-CAMPUS-TELECOMMUNICATIONS 2019-07-15 2019-12-30 54600 PEGTECHINC 2019-08-28 2019-12-18 46300 HSC-WAP 2019-10-30 2019-12-26 2886 EC-813-2886 2019-11-05 2019-12-31 63018 USDEDICATED 2019-12-03 2019-12-06 21859 ZNET 2019-12-26 2019-12-26 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block… Please send any feedback or suggestions to spoofer-info(a)caida.org

1 0

BGP Path Attribute Filtering, YES or NO?
by adamv0025＠netconsultings.com 08 Jan '20

08 Jan '20

Would like to gather current views of a wider community on BGP Path Attribute Filtering (discarding selected attributes in particular, not treat as withdraw) as an addition to the long list of standard conditioning tools like max as-path length limit, limiting number of communities all the way to running iBGP infrastructure to carry Internet prefixes separate to the one carrying customers' L3/L2VPN prefixes. And I appreciate the topic is somewhat contentious and there's no simple yes or no answer either. My view is that in a stub AS there should be no harm in discarding unused BGP path attributes, On transit AS-es I'd expect two opposing views: One might be: "I have a business to run and don't care about some university experiments, so unless any of my customers specifically asks for some attribute I'll drop all reserved, unassigned and deprecated ones and might even drop some not widely used ones just to be on the well-trodden bug free path" Other might be: "These experimental work is of great value to the community and there's a process now to announce and manage these experiments, what about net neutrality, and besides modern BGP implementations should handle well formatted attributes and if it's not the case its good that these flaws are being exposed and fixed." Please let me know your thoughts. adam

4 11

FCC proposes $10 Million fine for spoofed robocalls
by Sean Donelan 08 Jan '20

08 Jan '20

On Monday, U.S. FCC Chairman Pai and Canadian CRTC Chairperson Scott made the first official cross-border SHAKEN/STIR call. https://www.fcc.gov/document/pai-scott-make-first-official-cross-border-sha… Today, the U.S. FCC announced a proposed nearly $10 million fine for spoofed robocalls. https://www.fcc.gov/document/fcc-proposes-nearly-10-million-fine-spoofed-ro… A U.S. telemarketing firm spoofed the caller-id of a competitor to make approximately 47,610 political robocalls shortly before a California State Assembly primary election. I think this case is somewhat unusual for robocall spoofing, because the alleged perpetrator, victims, and 'crime scene' occured within the same jurisdiction. While the FCC likes to announce large enforcement actions in splashy press releases, its actually bad about collecting fines. The FCC must rely on the Justice Department to initiate separate prosecution to enforce payment from non-license holders because the FCC can't do that itself. So don't expect anyone to actually pay soon (or ever).

27 54