June 2020 - Test - lists.nanog.org

Re: [c-nsp] LDPv6 Census Check
by Mark Tinka 10 Jun '20

10 Jun '20

On 10/Jun/20 21:20, Gert Doering wrote: > Oh. Indeed, sorry for being unclear here. > > SR/MPLS sounds like a good idea (reducing label state). > > SR/IPv6 does not sound convincing. +1. 2010 - 2019 has been a decade of "pushing stuff". 2020 is the year of deciding what snake oil no longer deserves energy, the Coronavirus notwithstanding. Mark.

1 0

Re: [c-nsp] LDPv6 Census Check
by Mark Tinka 10 Jun '20

10 Jun '20

On 10/Jun/20 21:17, Gert Doering wrote: > > We do have IOS XEs today (ASR920), and based on that, we're not going > to buy new IOS XE devices any time soon. > > The amount of... strangeness... that this BU considers acceptable > is... not. It's been a week of trying to get them to see reason. Tough for their "unified" case with the IOS XR team are delivering the goods. Mark.

1 0

infrapedia June 2020
by Mehmet Akcin 10 Jun '20

10 Jun '20

hey there, today we have interviewed Vint Cerf and asked him some questions about the internet, development after covid19, if you are interested in watching this interview, check it out - https://www.youtube.com/watch?v=hL3nV5x4fHc&feature=youtu.be if you have suggestions on who you would like to see interviewed also let me know, I am working on a couple of interesting people focusing on internet stability and reliability. (offlist please) we have also thought it would be a good idea to give international telecoms, ixps, datacenters, subsea cable companies an award as they work very hard, if you are interested in voting you can do that https://www.infrapedia.com/app as always source code for infrapedia is available https://github.com/infrapedia and please feel free to join and contribute to the project. last but not least... Join our slack here! https://join.slack.com/t/infrapedia/shared_invite/zt-em3btj80-jj0iGlG7jkAjP… Mehmet

1 0

Re: [c-nsp] LDPv6 Census Check
by Mark Tinka 10 Jun '20

10 Jun '20

On 10/Jun/20 20:10, Gert Doering wrote: > To be honest, I do not think we're going to buy any IOS XE gear in the > foreseeable future. But if we did, LDPv6 would be nice to have - to get > rid of IPv4 in the backbone network. We have LDPv6 working beautifully between IOS XR (6.4.2) and Junos (17.4). But we can't make the core BGPv6-free because downstream ASR1000's and ASR920's don't have it. So if you don't have IOS XE today, but have the others, then you're good to go :-). Nobody is going to demand LDPv6, because it's not about LDPv6... it's about IPv6, and wanting IPv4 parity. But, guess that doesn't much a business case write. > > We do not intend to run SRv6 any time soon. As I thought :-). Mark.

1 0

ACX5448
by JASON BOTHE 09 Jun '20

09 Jun '20

Hi all Just curious if anyone on is using the ACX5448 and what their thoughts are on it. Thanks J~

4 5

Re: Partial vs Full tables
by William Herrin 09 Jun '20

09 Jun '20

On Mon, Jun 8, 2020 at 10:52 AM <ljwobker(a)gmail.com> wrote: > Every "fast" FIB implementation I'm aware of takes a set of prefixes, stores them in some sort of data structure, which can perform a longest-prefix lookup on the destination address and eventually get to an actual physical interface for forwarding that packet. Exactly how those prefixes are stored and exactly how load-balancing is performed is *very* platform specific, and has tons of variability. I've worked on at least a dozen different hardware based forwarding planes, and not a single pair of them used the same set of data structures and design tradeoffs. Howdy, AFAIK, there are two basic approaches: TCAM and Trie. You can get off in to the weeds fast dealing with how you manage that TCAM or Trie and the Trie-based implementations have all manner of caching strategies to speed them up but the basics go back to TCAM and Trie. TCAM (ternary content addressable memory) is a sort of tri-state SRAM with a special read function. It's organized in rows and each bit in a row is set to 0, 1 or Don't-Care. You organize the routes in that memory in order from most to least specific with the netmask expressed as don't-care bits. You feed the address you want to match in to the TCAM. It's evaluated against every row in parallel during that clock cycle. The TCAM spits out the first matching row. A Trie is a tree data structure organized by bits in the address. Ordinary memory and CPU. Log-nish traversal down to the most specific route. What you expect from a tree. Or have I missed one? Regards, Bill Herrin -- William Herrin bill(a)herrin.us https://bill.herrin.us/

4 3

Re: Partial vs Full tables
by Jakob Heitz (jheitz) 08 Jun '20

08 Jun '20

These are the first steps to optimization. Hysteresis is another. They work in ideal cases. However, when coding, we need to consider all cases. How do you set the timer? The timer has to anticipate the future. It's like an automatic transmission. It can't anticipate the future. However, the worst that can happen if the automatic transmission anticipates incorrectly is that it hunts. Regards, Jakob. -----Original Message----- Date: Mon, 8 Jun 2020 10:14:17 +0200 From: Baldur Norddahl <baldur.norddahl(a)gmail.com> On 08.06.2020 07.56, Jakob Heitz (jheitz) via NANOG wrote: > FIB compression comes with some risks. > When routes churn, there are certain cases when you have to decompress the FIB. > Then, the FIB must have the space, or else OOPS. > If a set of compressed routes has to change to decompress some and compress a > different set to improve overall compression, there is a lot of FIB > programming going on. This can cause very long convergence times. > The easy solution is to introduce some delay before programming the FIB. Or even process RIB updates as a separate thread, such that the FIB update thread does not try to program every step the RIB might go through. Instead the FIB update thread would take a snapshot of where we are now and where do we want to be and only program the diff. Given the concept is a smaller FIB size, this might actually end up being less FIB programming. Regards, Baldur

1 0

Spoofer Report for NANOG for May 2020
by CAIDA Spoofer Project 08 Jun '20

08 Jun '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 May 2020: ASN Name Fixed-By 14860 AS-SMARTCOM 2020-05-17 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during May 2020: ASN Name First-Spoofed Last-Spoofed 54825 PACKET 2016-04-15 2020-05-01 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2020-05-28 6128 CABLE-NET-1 2016-09-03 2020-05-27 7459 GRANDECOM-AS1 2016-09-26 2020-05-24 20412 CLARITY-TELECOM 2016-09-30 2020-05-25 6181 FUSE-NET 2016-10-10 2020-05-29 11427 TWC-11427-TEXAS 2016-10-21 2020-05-24 174 COGENT-174 2016-10-21 2020-05-29 32440 LONI 2016-11-03 2020-05-31 12083 WOW-INTERNET 2016-11-09 2020-05-30 39939 RISE-CO-AS39939 2016-11-11 2020-05-30 30036 MEDIACOM-ENTERPRISE-BUSINESS 2016-11-16 2020-05-28 9009 M247 2017-01-10 2020-05-27 63296 AWBROADBAND 2017-09-01 2020-05-27 36236 NETACTUATE 2018-01-13 2020-05-24 40244 TURNKEY-INTERNET 2018-01-14 2020-05-24 12222 AKAMAI 2018-02-14 2020-05-07 20448 VPNTRANET-LLC 2018-09-20 2020-05-20 8047 GCI 2019-04-11 2020-05-28 6428 CDM 2019-06-04 2020-05-16 46300 HSC-WAP 2019-10-30 2020-05-28 21859 ZNET 2019-12-26 2020-05-27 239 UTORONTO 2020-01-28 2020-05-30 13614 ALLWEST 2020-03-16 2020-05-21 26335 MTSU 2020-03-20 2020-05-07 7859 PAIR-NETWORKS 2020-04-03 2020-05-29 5078 ONENET-AS-1 2020-04-06 2020-05-30 13781 ENERGYNET 2020-04-15 2020-05-12 208217 YUNJIANET 2020-04-27 2020-05-25 64236 UNREAL-SERVERS 2020-05-06 2020-05-06 393713 ALL-POINTS-BROADBAND-5 2020-05-08 2020-05-08 53356 WESTCONNECT 2020-05-19 2020-05-19 29844 SENAWAVE 2020-05-22 2020-05-26 18450 WEBNX 2020-05-24 2020-05-24 11650 PLDI 2020-05-25 2020-05-25 6391 URBAN-15 2020-05-29 2020-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

IP whitelisting in twitter (the joy of full tunnel VPN)
by Yannis Mitsos 08 Jun '20

08 Jun '20

Hi, We recently flipped from a split to a full tunnel configuration in our firewalls that live inside a big cloud provider. Seems that twitter is rate limiting us because it measures an immense number of API hits from a couple of IPs. Not sure if they have any process to whitelist such VPN endpoints. At least, I couldn't find anything in the web. Does anyone else have similar experience? Is there any colleague from twitter who is willing to reply (publicly or privately). Regards, Yannis

2 3

Re: Partial vs Full tables
by Jakob Heitz (jheitz) 08 Jun '20

08 Jun '20

FIB compression comes with some risks. When routes churn, there are certain cases when you have to decompress the FIB. Then, the FIB must have the space, or else OOPS. If a set of compressed routes has to change to decompress some and compress a different set to improve overall compression, there is a lot of FIB programming going on. This can cause very long convergence times. Because a FIB memory cell can not forward and be programmed at the same time, forwarding takes preference and programming speed suffers. FIB programming is the slowest part of convergence, the bottleneck. If routes also have a backup path loaded, then the backup nexthops also need to be the same in order to compress. During convergence, not all routes change at the same time and there could be some very uncompressible transient route sets during convergence. Some possible sequences of compress/decompress during convergence could cause a lot of churn in FIB programming. This presents lots of opportunities for optimization and thus bugs. Regards, Jakob.

2 1