June 2021 - NANOG - lists.nanog.org

AT&T Fiber Line / NOT MIS
by Dennis Burgess 10 Jun '21

10 Jun '21

I have a ATT fiber line for a customer that has a 300/300 circuit, but its not a MIS they are telling me we cannot route a /26 (they have allocated) to my device behind it. ☹ Any options? [LTI-Full_175px] Dennis Burgess Mikrotik : Trainer, Network Associate, Routing Engineer, Wireless Engineer, Traffic Control Engineer, Inter-Networking Engineer, Security Engineer, Enterprise Wireless Engineer Hurricane Electric: IPv6 Sage Level Cambium: ePMP Author of "Learn RouterOS- Second Edition” Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net<http://www.linktechs.net/> Create Wireless Coverage’s with www.towercoverage.com Need MikroTik Cloud Management: https://cloud.linktechs.net How did we do today? [Gold Star]<https://app.customerthermometer.com/?template=log_feedback&hash=5badbac1&em…>[Green Light]<https://app.customerthermometer.com/?template=log_feedback&hash=675abe04&em…>[Yellow Light]<https://app.customerthermometer.com/?template=log_feedback&hash=e42b48a5&em…>[Red Light]<https://app.customerthermometer.com/?template=log_feedback&hash=ecaadcd3&em…>

3 7

Technical resources for Open Access Fiber Networks?
by Mark Leonard 10 Jun '21

10 Jun '21

Hi NANOG, Not so long ago I learned about Open Access Fiber Networks. I'm quite curious about how these are actually implemented. I'm able to find boatloads of marketing material and management-targeted boilerplate, but I've not yet been able to find any technical resources. My first thoughts were: * Are these just massive VPLS networks? * Are they just giant L2 networks? I can't imagine that either of the above would scale particularly well. I'm looking for any books / papers / config guides / magic tomes / etc on the subject. Can anyone point me in the right direction? Thanks, Mark

3 2

NAT devices not translating privileged ports
by Fernando Gont 10 Jun '21

10 Jun '21

Folks, While discussing port randomization (in the context of https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt ), it has been raised to us that some NAT devices do not translate the source port if the source port is a privileged port (<1024). Any clues/examples of this type of NATs? Thanks! Regards, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

5 12

A survey on BGP MRAI timer values in practice
by shahrooz＠cs.umass.edu 10 Jun '21

10 Jun '21

Hi NANOG, This is Shahrooz, a fourth-year CS Ph.D. student at the University of Massachusetts Amherst working under the supervision of prof. Arun Venkataramani. We often read that the Internet (i.e. BGP) has a long convergence delay. But why is it so slow? And can we (researchers) do anything about it? Please help us out to find out by answering our short anonymous survey (<10 minutes). This survey aims at finding the best current practices on the Internet about MRAI/"delay out" timer values. We expect the findings to increase the understanding of the perceived BGP convergence on the Internet, which could then help researchers to design better solutions for BGP long convergence delay. Survey URL: https://forms.gle/VNRpU2MzRU8DX1o57 We expect the questionnaire to be filled out by network operators whose job relates to BGP operations. It has a total of 6 questions and should take less than 10 minutes to answer. A summary of the aggregate results will be published as a part of a scientific article later (hopefully :) this year. Thank you so much in advance, and we look forward to read your responses! We would be also extremely grateful if you could forward this email to any operator you might know who may not read NANOG. Best, Shahrooz

5 7

Can't Port from a Particular Rate Center
by Mike Hammett 10 Jun '21

10 Jun '21

I first asked on a list much more narrow in scope, but failing to get sufficient data points, I've expanded my scope. Assuming the number isn't held by someone exempt from porting, what would prevent someone from being able to port a number from a particular rate center in a LATA they have coverage in? We picked up a particular carrier for our out-of-area needs and the first thing we throw at them in a LATA we know they have coverage in, they can't do. They have a non-useful reason why. It doesn't appear to have moved to a state where they contacted the losing provider as the response was very fast, so my provider rejected the port, not theirs. When I started at this company (where we do our own porting), I made sure to port a bunch of numbers from all over our LATA to see what would happen. All successful. That seems to indicate that it doesn't matter which xLEC or tandem currently serves that number, it can move elsewhere. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

5 5

MPLS/MEF Switches and NIDs
by Colton Conor 09 Jun '21

09 Jun '21

For MPLS and MEF switches, I know Juniper, Cisco, and Nokia are commonly talked about on this list. However, I was wondering if anyone has evaluated other brands? We are not interested in looking at chinese based vendors, so ZTE and Huawei are not an option. Anyone else worth looking into? We have used Juniper's ACX line primarily, but there is a big gap in their product line. The ACX2200 has only two 10G ports. The next jump up from there is the ACX710 with 24 10G ports. They have nothing in between that has 4-12 10G ports. Not to mention, Juniper is very proud price wise. We are looking for cost efficient 10G NIDs with at least 4 10G ports on them and aggregation boxes with at least 12 10G ports on them with 25g/100G uplinks. Ciena seems to have multiple options available with Segment Routing, MPLS, and streaming telemetry support. I am probably most interested in what Ciena has to offer. Has anyone deployed the 3000 or 5000 product line of Ciena? How does it compare to Juniper? The Ciena 3924 is sub $1000 for example, and has 4 10G ports on it. Adva has quite a few options as well, but I don't think their routing stack is as strong as Ciena's. Tejas was an unknown player to me, but they seem to have a couple of options that fit the bill. Price wise, I have heard the run circles around everyone. RAD has some options, but their pricing looks much higher than Ciena. Accedian looked interesting, but it seems they don't make aggregation switches, only NIDs. ECI Telecom / Ribbon seems to have some options, but I have not talked to them. What does Nokia and Cisco have in this space, and price wise is it going to compare to these less known vendors?

13 33

hulu IP issue
by Daniel Sterling 09 Jun '21

09 Jun '21

I changed my hulu passwd and got this email from hulu (see below). It notes what IP I used to change the passwd, but it's an internal IP! Probably not as intended :) email: You've Changed Your Password Hi Daniel, As requested, your password has been changed. From now on, you'll use this new password to log in to Hulu. The password was changed from the IP address 10.35.33.117.

1 0

Re: A survey on BGP MRAI timer values in practice
by Jakob Heitz (jheitz) 09 Jun '21

09 Jun '21

In Cisco, MRAI is "advertisement-interval". MRAI helps to reduce route update multiplication in highly redundant networks. OTOH, it can increase the time it takes to re-advertise a complete internet table in some router implementations. Update multiplication due to redundant network connections causes some receivers of the multiple updates to become slow peers. Here's an experiment: Do something to cause a BGP route refresh, like the equivalent of "clear bgp soft out". It will not change any routes. It just resends everything that was already sent. See how long it takes with MRAI=0. Then set MRAI to about half of that value and do the refresh again. If it takes substantially longer to complete the refresh, stick with MRAI=0. If there is no significant difference, use MRAI of 1 or 2 seconds. Regards, Jakob. -----Original Message----- Date: Wed, 9 Jun 2021 08:53:19 +0300 From: Saku Ytti <saku(a)ytti.fi> On Wed, 9 Jun 2021 at 01:18, Adam Thompson <athompson(a)merlin.mb.ca> wrote: If your work results in actionable recommendations such as "don't use BGP > out-delay timers to mitigate XYZ in circumstance LMNO, do ABC instead", > that's fantastic. Please keep us advised, and do post aggregated survey > results here once you close the survey. > What is actionable? What is the goal? The question as OP presented contains some assumptions a) better convergence is needed b) MRAI is important part of the solution space Neither are provable. We already know how to make DFZ convergence really fast (or at least orders of magnitude faster than it is), that information exists, but that isn't deployed because customers are not asking for it, so providers are not aware that there is room for improvements. Things don't optimise to be as good as they can be, things optimise to be as bad as the market allows them to be. And the market accepts the DFZ convergence. If you do decide to optimise for DFZ convergence, without commercial pressure, you will risk lower availability, because you'll be using configuration less tested by other customers and everyone knows how terrible quality every NOS is. Everyone finds novel bugs, in the same damn protocols we've ran +20 years. It's like running Windows and Linux and regularly finding out listing files in a directory breaks your service, year after year after year. For those who are interested in better convergence - change your interface down reporting to 0 (there may be delay before interface down is reported to system, so that optical protection works without causing outage) - use 'add-path' or at least 'best-external' in iBGP, so that you always have backup eBGP route immediately available once best is invalidated (normally you have lot of delay to find next best, once you lose your best eBGP) - tie your route validity to IGP, so you can invalidate your BGP the moment IGP disappears - ensure IGP converges fast (another topic) - set MRAI to 0 - use PIC edge - ensure your BGP NLRI can be as large as MTU allows - ensure your convergence isn't bottle necked by slow peer in group - ensure you are not dropping received TCP packets on punt path - ensure your fast external fallover works (eBGP down, on int down) this is quite easy to break - then ensure everyone else in the DFZ does the same thing But from a business POV, don't do any of this, you will have more bugs and lower availability and your customers will be less happy. > I *am *specifically interested in the answer to "Have you ever had to > adjust BGP out-delay with any of your peers, and why?" It would be great > if we could derive that answer from the survey results, but anecdotal > replies here would also be helpful. All you larger(-than-me) network > operators out there: when would I need to use out-delay? Why? What does > it accomplish? > > Good luck in reformulating your survey to get better engagement, > -Adam > > *Adam Thompson* > Consultant, Infrastructure Services > [image: 1593169877849] > 100 - 135 Innovation Drive > Winnipeg, MB, R3T 6A8 > (204) 977-6824 or 1-800-430-6404 (MB only) > athompson(a)merlin.mb.ca > www.merlin.mb.ca > > ------------------------------ > *From:* NANOG <nanog-bounces+athompson=merlin.mb.ca(a)nanog.org> on behalf > of Saku Ytti <saku(a)ytti.fi> > *Sent:* June 8, 2021 01:06 > *To:* shahrooz(a)cs.umass.edu <shahrooz(a)cs.umass.edu> > *Cc:* nanog list <nanog(a)nanog.org>; Arun Venkataramani <arun(a)cs.umass.edu> > *Subject:* Re: A survey on BGP MRAI timer values in practice > > On Mon, 7 Jun 2021 at 19:32, <shahrooz(a)cs.umass.edu> wrote: > > > We often read that the Internet (i.e. BGP) has a long convergence delay. > > But why is it so slow? And can we (researchers) do anything about it? > > Create business incentives to improve it. This is a non-technical > problem, we've long had technical tools to make it fast, there just > isn't incentive to make it fast. Customers are not asking operators > for better convergence speeds. > > > Please help us out to find out by answering our short anonymous survey > > (<10 minutes). > > Can you tell me what have you done so far? What are the default MRAI > values for each AFI/SAFI for IOS, IOS-XR, Junos, SROS, VRP and EOS? > Then people responding don't have to check what their NOS does, they > can refer to your table and tell the default value, since this is what > >99% will be using. > > Now your survey has built-in selection bias, people who answer it are > people who know what it is and who are concerned about it and have > changed it, this is not a representative group and you will start your > work with very bad data. > > > > -- > ++ytti > -- ++ytti

1 0

BCP38 on public-facing Ubuntu servers
by Stephen Satchell 09 Jun '21

09 Jun '21

Not every uplink service implements BCP38. When putting up servers connected more-or-less directly to the Internet through these uplinks, it would be nice if the servers themselves were able to implement ingress and egress filtering according to BCP38. (Sorry about the typo in the subject lines of my previous message -- not everyone can get a BGP feed.) (Or, when using Ubuntu server edition to implement edge routers.) My earlier query was asking if anyone has encoded the blackhole routes in YAML for inserting in netplan(5). My prior message contains the routes to be blackholed. That takes care of egress routing. (I think I can write a Python program to take my list and convert it to the YAML that netplan(5) wants to see. That way, the routes are inserted when the public interface is up, and removed when the public interface is down.) Ingress routing appears to be one-line addition. IPTABLES can be told to weed out packets with unroutable source addresses. My experiments will add something like this line to the firewall: # iptables -A INPUT -m addrtype -i enp1s0 --src-type BLACKHOLE -j DROP THIS HAS NOT BEEN VERIFIED. I'm building a web server that will integrate this idea, and try it out.

7 9

Spoofer Report for NANOG for May 2021
by CAIDA Spoofer Project 08 Jun '21

08 Jun '21

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 May 2021: ASN Name Fixed-By 5078 ONENET-AS-1 2021-05-19 55016 IMPER-AS-1 2021-05-25 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during May 2021: ASN Name First-Spoofed Last-Spoofed 3356 LEVEL3 2016-03-06 2021-05-05 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2021-05-25 20412 CLARITY-TELECOM 2016-09-30 2021-05-31 6181 FUSE-NET 2016-10-10 2021-05-29 11427 TWC-11427-TEXAS 2016-10-21 2021-05-28 174 COGENT-174 2016-10-21 2021-05-11 30036 MEDIACOM-ENTERPRISE-BUSINESS 2016-11-16 2021-05-25 22898 ATLINK 2016-12-16 2021-05-28 63296 AWBROADBAND 2017-09-01 2021-05-27 546 PARSONS-PGS-1 2017-11-20 2021-05-20 393564 SPOKANE 2018-06-05 2021-05-18 33452 RW 2018-09-19 2021-05-26 20448 VPNTRANET-LLC 2018-09-20 2021-05-28 5078 ONENET-AS-1 2020-04-06 2021-05-24 6391 URBAN-15 2020-05-29 2021-05-20 208188 PUGET-SOUND-NETWORKS 2020-12-04 2021-05-30 62684 XLBROADBAND 2021-05-19 2021-05-19 13876 FIBER-64 2021-05-20 2021-05-27 26397 OPTIPUTER 2021-05-24 2021-05-24 3754 NYSERNET3 2021-05-24 2021-05-24 3756 NYSERNET3 2021-05-24 2021-05-26 20150 ANYNODE 2021-05-29 2021-05-29 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