- NANOG - lists.nanog.org

isp/cdn caching
by Aaron Gould 02 Oct '17

02 Oct '17

Hi, I've been aware of a few caching providers for a few years now, but I'm learning of others as time goes on. which makes me curious if there are more springing up and gaining popularity. I'm speaking of ISP-type caching whereas the cache provider sends hardware servers and perhaps a switch to the local ISP to install locally in their network. Can someone please send a simple list of what they know is the current players in this ISP Caching space? I'll list the ones I know about and you please let me know of others. This seems to be an evolving/growing thing and I'm curious of where we are today for significant providers and possibly up-and-coming ones that I should know about. (amazon prime has my wondering also.) Google (GGC) Netflix (OCA) Akamai (AANP) Facebook (FNA) Apple (I heard this isn't isp-located like the others, but unsure) ? others ? ? others ? ? others ? -Aaron Gould

5 4

Long BGP AS paths
by William Herrin 02 Oct '17

02 Oct '17

To the chucklehead who started announcing a 2200+ byte AS path yesterday around 18:27 EDT, I beg of you: STOP. You've triggered a bug in Quagga that's present in all versions released in the last decade. Your announcement causes routers based on Quagga to send a malformed update to their neighbors, collapsing the entire BGP session. Every 30 seconds or so. For everyone else: please consider filtering BGP announcements with stupidly long AS paths. There's no need nor excuse for them to be present in the DFZ and you could have saved me a painful Saturday. Cisco: router bgp XXX bgp maxas-limit 50 Juniper: https://kb.juniper.net/InfoCenter/index?page=content&id=KB29321 Quagga: ip as-path access-list maxas-limit50 deny ^([{},0-9]+ ){50} ip as-path access-list maxas-limit50 permit .* Regards, Bill Herrin -- William Herrin ................ herrin(a)dirtside.com bill(a)herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>

9 11

Which one(s) of SWIP, RWhois, RDAP? (Fwd: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information)
by John Curran 02 Oct '17

02 Oct '17

NANOGers! Apologies (as some of you have already seen this) but it has more relevance to network operations than most IP number policy matters, so out of avoidance of any doubt, I call this to your attention. ARIN has opened a community consultation on the question of which methods for reporting network sub-delegations should be supported by ARIN. If you have views on this matter, please read the attached and take the time to comment on the arin-consult mailing list (which is the mailing list which ARIN uses for discussion of community suggestions & consultations and is open to the public.) Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN <info(a)arin.net<mailto:info@arin.net>> Subject: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information Date: 2 October 2017 at 8:19:36 AM PDT To: <arin-consult(a)arin.net<mailto:arin-consult@arin.net>> ARIN was previously requested via the ARIN Consultation and Suggestion Process (ACSP) to open a consultation to generate discussion about the possibility of sun-setting RWhois support by the ARIN organization. ARIN's initial response to the ACSP indicated we would open a consultation following the completion of the Registration Data Access Protocol (RDAP) specification inside the IETF processes. This work has been completed and the RFC has been published. ARIN took the additional step of implementing RDAP inside its own directory services offering with referral support to the other Regional Internet Registries (RIRs). With this work complete, we are following through with the formalized request to open a consultation on this topic. https://www.arin.net/participate/acsp/suggestions/2013-22.html In accordance with ARIN's Number Resource Policy Manual (NRPM), Organizations are required to report certain types of customer network sub-delegation information (reassignments and reallocations) to ARIN. Currently there are two reporting methods available. Both are delineated in the NRPM and supported by ARIN's production services. There is also a third possible method of reporting sub-delegation information that could be made available, but is not yet offered. Method 1: SWIP (currently available): The reporting of sub-delegation information using ARIN's database. This can be done either by submitting a SWIP template, interfacing with ARIN's RESTful API, or by creating a sub-delegation inside ARIN Online using ARIN's SWIP-EZ functionality. https://www.arin.net/resources/request/reassignments.html Method 2: RWhois (currently available): The reporting of sub-delegation information on your own hosted and operated RWhois server with referral link information provided in ARIN Whois as part of your own organization's Whois records. In order for a user of ARIN's directory services to view sub-delegation information hosted by an RWhois server, they would have to submit a separate query to that RWhois server, and are not referred in an automated fashion. https://www.arin.net/resources/request/reassignments_rwhois.html Method 3: RDAP: The five RIRs currently use RDAP for referrals to each other's Whois data. Although the specification language of the RDAP could allow it to be used as a third method for the reporting of sub-delegation information to ARIN, it is not currently offered as an option. In order to make this option available, associated registry software would need to be created. This possible method would allow users of ARIN's directory services to view sub-delegation information available on customer hosted RDAP servers in an automated fashion. This RDAP method may also be viewed as redundant to RWhois. https://tools.ietf.org/html/rfc7482 https://www.arin.net/resources/rdap.html Options Going Forward ARIN expects to continue offering Method 1 (SWIP) into the foreseeable future. As previously described, we are acting on a formal suggestion to consult with the community about the future of RWhois support, and also have potential options with RDAP. * Question (general): Of the three sub-delegation reporting methods listed (SWIP, RWhois, RDAP), which should ARIN support in the future? * Question (SWIP/RESTful API specific): The existing RESTful API allows users to report (SWIP) one sub-delegation at a time to be added to ARIN Whois. Should ARIN add bulk-upload features to the RESTful API? * Question (RWhois specific): As noted, RWhois servers are not referred to in an automated fashion when users query ARIN Whois. Should ARIN automate referrals to RWhois servers from ARIN's Whois service? * Question (RDAP specific): If ARIN was to allow the reporting of network sub-delegation information using RDAP, associated enabling software would be required. Should ARIN enable this method by creating an RDAP software suite that would allow ARIN registrants to run RDAP service locally? The feedback you provide during this consultation will help inform decisions about software tools and support for the reporting of network sub-delegation information to ARIN in the future. Thank you for your participation in the ARIN Consultation and Suggestion Process. Discussion on arin-consult(a)arin.net<mailto:arin-consult@arin.net> will close on 27 October 2017. If you have any questions, please contact us at info(a)arin.net<mailto:info@arin.net>. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult(a)arin.net<mailto:ARIN-consult@arin.net>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info(a)arin.net<mailto:info@arin.net> if you experience any issues.

1 0

Re: AS PATH limits
by Ken Chase 02 Oct '17

02 Oct '17

I dont see that as the solution. Someone else will offend again. However, I also don't see trusting major backbones as our filters (for many other reasons). Our software should be handling what's effectively a buffer overflow or equivalent (beware long paths that are actually shellcode). Quagga among others seems to be subject to this bug, pre 0.99.23 or so (.99.24+ seems ok). So upgrading is a solution. There was also some chatter on the quagga mailing list on how it's more pleasant to stab your eyeballs out rather than constructing extremely long regexp's that might work as a filter. https://lists.quagga.net/pipermail/quagga-users/2017-September/thread.html /kc On Sat, Sep 30, 2017 at 05:30:03PM +0200, Niels Raijer said: >My message to NANOG about this from 12:31 UTC today is still in the moderation queue. I had opened a support case with Cogent before writing my message to NANOG and Cogent has let me know approximately 40 minutes ago that they have contacted their customer. > >Niels > > > >On 30 Sep 2017, at 17:09, sthaug(a)nethelp.no wrote: > >>> If you're on cogent, since 22:30 UTC yesterday or so this has been happening >>> (or happened). >> >> Still happening here. I count 562 prepends (563 * 262197) in the >> advertisement we receive from Cogent. I see no good reason why we >> should accept that many prepends. >> >> Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no > -- Ken Chase - math(a)sizone.org Guelph Canada

7 7

Re: Long BGP AS paths
by Scott Weeks 02 Oct '17

02 Oct '17

> Nowhere in the BGP RFCs it says it is okay for the > software to crash. :: we could send a community to signal that it's ok :: to crash Call it the ECB. (Evil Crash Bit). ;-) scott

1 0

Re: Long BGP AS paths
by William Herrin 01 Oct '17

01 Oct '17

On Sun, Oct 1, 2017 at 1:06 PM, Kelly Dowd <kdowd(a)transelement.net> wrote: > On Sun, Oct 1, 2017 at 12:29 AM, William Herrin <bill(a)herrin.us> wrote: > >> To the chucklehead who started announcing a 2200+ byte AS path yesterday >> around 18:27 EDT, I beg of you: STOP. You've triggered a bug in Quagga >> > > Is this better or worse than the "chucklehead" who is running buggy > routing kit and complaining about what is a perfectly valid configuration? > Hi Kelly, Show me a reasonable use case for an AS path that's much longer than the Internet is wide and I'll withdraw my complaint. Your software has bugs too. You just didn't get bitten. This time. Regards, Bill Herrin -- William Herrin ................ herrin(a)dirtside.com bill(a)herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>

1 0

ISC DLV Registry now running a signed empty zone
by Dan Mahoney (Gushi) 01 Oct '17

01 Oct '17

All, Just to let people know via this list: As of DNS-OARC 27 (where the change was done live) ISC's DLV Registry has now been replaced with a signed empty zone (SOA/NS/A/TXT/DNSKEY/RRSIG), which will be auto-re-signed with the same keys for the forseeable future. The IP address for the old DLV web-ui now redirects to ISC's main page, but if anyone needs a copy of the last-known zone contents for historical purposes, please reach out. Thanks to the community for your support. -Dan Mahoney ISC Operations Group -- Notes: This was sent from my personal domain because that's what I keep subscribed to NANOG, but I'm speaking in this post as an ISC Employee. I will be at NANOG San Jose, I have blue hair and am hard to miss. (Also sent to a couple dns-related lists, apologies for duplicates).

1 0

Peering at public exchange authentication
by craig washington 30 Sep '17

30 Sep '17

Hello all, Wondering your views or common practices for using authentication via BGP at public exchange locations. Just for example, lets say you peer with 5 people in the TELX in Atlanta, do you require them to all use authentication for the BGP session? Ive seem some use it and some not use it, is it just a preference?

6 5

CPE that support 1G with BGP multihomed
by marcel.duregards＠yahoo.fr 30 Sep '17

30 Sep '17

Dear Nanoger, Anyone have an advice on CPE which can support the following features, please: 1) 1 Gigabits/s ipv4 or ipv6 forwarding IMIX or Internet traffic, full duplex (not sure if cisco or miercom are conducting bidirectionals traffic flows at the same time). 2) with ACLs and with uRPF with prefix filtering with bgp ext-communities (rfc 8092 would be a ++, but not mandatory) 3) with BGP full route, 1 eBGP session + 1 iBGP (--> multihomed, single attached solution, so there is 2 CPE connected to 2 bgp transit)) 4) vrf light and SNMP + telnet/ssh with ACLs Currently on Cisco side, we see the following candidates: - ASR 1001-x - ASR 1002 - ISR 4431, 4451 - ISR G2 2921 + 2951 + 3925(E) (EoL soon, so we are currently in the process of evaluating other solution). But we would like also to include other manufacturer : juniper, mikrotik , etc.... Thank for your help, - Marcel

4 3

AT&T-twtelecom LA issue
by Andrew Stern 29 Sep '17

29 Sep '17

Hello. We are experiencing traffic issues between AT&T and twtelecom between SF and LA (5-7% dropped and out-of-order packets, increased latency RTT). Issue occurs only during business hours pacific time. We are on the AT&T enterprise side of the equation. My personal guess is oversubscribed peering, but what do I know? If anyone from att or twtelecom sees this, help! Andrew Stern, CBNE | Broadcast Engineer Cumulus Media San Francisco KFOG | KNBR | KSAN | KTCT | KGO | KSFO office: 415-995-5740 andrew.stern(a)cumulus.com<mailto:andrew.stern@cumulus.com> 750 Battery St. | 2nd Floor | San Francisco | CA 94111 ________________________________ Cumulus Media Disclaimer This message contains confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

1 0