June 2020 - NANOG - lists.nanog.org

Client-side information gathering tool
by Matt Harris 17 Jun '20

17 Jun '20

Hey folks, I was hoping maybe someone could point me in a useful direction here. I'm looking into software tools (ideally, they'd support Windows, Mac, and Linux, though Windows is perhaps the only critical one) that can be sent over to random users with varying (mostly very little) knowledge of how the internet works to gather a bunch of data that they can then provide to us to help identify connectivity issues between the client and a chosen endpoint. IPv4 and IPv6 support are requirements. I've got a lot of clients with VPN connections of varying sorts running on internet connections of often very low quality, and sometimes even in places where reasonable quality doesn't seem to even exist. Right now, when these users complain, this often means my support folks get to walk them through downloading winmtr and running that as well as other command line tools to gather a bunch of other information about their computer, its connection to their LAN, their LAN configuration as best as we can tell, and their connection to the greater internet. This is somewhat cumbersome of a process though. If we could send them something they could click on and then copy/paste out of or otherwise direct the data to us, that would save a fair bit of time and also be a lot less patience-grating on the part of our clients. Any links to potentially useful tools (commercial or free are both fine) would be appreciated. The main goal is getting lots of relevant information to us without having to walk an end-user through lots of steps to do so. The more relevant data, the better. Thanks, Matt Matt Harris|Infrastructure Lead Engineer 816-256-5446|Direct Looking for something? Helpdesk Portal|Email Support|Billing Portal We build and deliver end-to-end IT solutions.

2 1

Yahoo Email NOC
by Fawcett, Nick 17 Jun '20

17 Jun '20

Could someone from Yahoo email NOC contact me offline. We have been getting complains from our users trying to send to yahoo.com addresses. Email is getting deliverd, but randomly going into the Yahoo users spam folder. Thanks. ~Nick -- Checked by SOPHOS http://www.sophos.com

2 1

Mystery CDN
by Clinton Work 17 Jun '20

17 Jun '20

I'm struggling to determine which CDN owns the servers in CenturyLink prefix 8.240.0.0/12. During the Call of Duty Season 4 update on June 11th from 06:00 UTC until 08:30 UTC, we had 240 Gbps of traffic steaming into our network from CenturyLink prefix 8.240.0.0/12. We originally thought it was Akamai, but they swear up and down that the servers don't belong to them. Here are some of the HTTP/HTTPS servers in 8.240.0.0/12: 8.253.151.248 8.251.135.126 8.240.167.126 8.240.228.126 8.240.168.126 8.240.126.254 8.240.191.254 -- Clinton Work Airdrie, AB

5 4

IPv4 routes spiking from 10PM EST until 8AM EST
by Drew Weaver 17 Jun '20

17 Jun '20

Has anyone noticed over the last week or so that the IPv4 routes appear to be spiking up temporarily every night from about 10PM EST until about 8AM EST? Is that just someone trying to test flipping over other network's TCAMs? Just wondering.

1 0

Re: RPKI race
by Baldur Norddahl 17 Jun '20

17 Jun '20

On Wed, Jun 17, 2020 at 10:07 AM Niels den Otter <niels.denotter(a)surfnet.nl> wrote: > Hello Baldur, > > If you want to validate routes in a VRF you need to configure; > > set routing-options validation notification-rib <rib> > > Have you done so? > > > That was missing from the config. After adding it and running the command "request validation policy" I got the prefixes validated. Thanks for the help. Baldur

3 2

Cogent sales reps who actually respond
by noc＠as37662.com noc＠as37662.com 17 Jun '20

17 Jun '20

Hi fellow network operators, Do any orgs here have experience with a good Cogent rep? The rep we got via Cogent's website is unresponsive to even basic questions. It feels like we are dealing with a bot and copy-pasted replies. Thanks Ruldu

66 146

BGP FLowspec to Yang/Yaml ACL
by Douglas Fischer 17 Jun '20

17 Jun '20

We were looking for some way to implement BGP Flowspec Filtering(just the permit/deny basic) using L3 switches in an automated way. Searching a bit we found https://github.com/ios-xr/bgpfs2acl Is almost what we are looking for! But is focused on Cisco devices. We even considered fork it to our specific vendor. But before reinventing the wheel, I decide to ask to colleagues if anybody knows some tool that converts BGP Flowspec ACLs into YAML or even to YANG. If that exists, with Ansible/Netconf/RestConf(or some similar tool), it would be easy to delegate to Switchs doing the basic filtering that only More expensive Routers can do by now. P.S.: This Idea does not include(on the first moment) more complex features of Flowspec like Redirect ou Rate-Limt. Any suggestions or ideas? -- Douglas Fernando Fischer Engº de Controle e Automação

3 3

favourite YANG data-store?
by adamv0025＠netconsultings.com 17 Jun '20

17 Jun '20

Hi folks, Was just wondering what are you folks using as production YANG data store and what do you like about the particular one you're using? Or maybe folks using OANP what is your YANG DS of choice? Plan on using it as in memory DS primarily for service, network YANG modules, (in addition to the usual use case of device modules), - so quite a lot of data as you can imagine storing data for higher abstraction layers Service & Network. Been looking at ODL and Confd thus far. adam

2 1

Fwd: [routing-wg] From Zero to RPKI Hero: Live Demo
by Melchior Aelmans 17 Jun '20

17 Jun '20

For those who still need to deploy RPKI OV we are running a 'live show' on Friday. Feel free to join. Cheers, Melchior ---------- Forwarded message --------- From: Nathalie Trenaman <nathalie(a)ripe.net> Date: Wed, Jun 17, 2020 at 12:39 PM Subject: [routing-wg] From Zero to RPKI Hero: Live Demo To: ripedenis--- via routing-wg <routing-wg(a)ripe.net> Hi all, The community has teamed up to bring something very exiting to network operators around the world! This Friday, from 17:00 CEST, we are doing a live demo “From Zero to RPKI Hero” where we will show how to create ROAs, set up Routinator, RIPE NCC Validator, configure Juniper, Arista, Nokia and Cisco routers to perform RPKI Origin Validation. This has never been done before! And it will be live! People can join over Zoom: https://arista.zoom.us/s/93051476697 < https://arista.zoom.us/s/93051476697> or join the Facebook live stream: https://www.facebook.com/events/183972346373123/186010836169274/ Later on, this will be uploaded to YouTube. Please note: This is not an event organised by any of the vendors, nor is it a commercial event. Just a bunch of techies (Ties de Kock, Florian Hibler, Greg Hankins, Jeff Tantsura, Orhan Ergun, Melchior Aelmans, Alex Band and Nathalie Trenaman) coming together to show “how it’s done” Best regards, Nathalie Trenaman

1 0

RE: [c-nsp] LDPv6 Census Check
by adamv0025＠netconsultings.com 17 Jun '20

17 Jun '20

> David Sinn > Sent: Friday, June 12, 2020 4:42 PM > > > On Jun 12, 2020, at 8:26 AM, Saku Ytti <saku(a)ytti.fi> wrote: > > > > On Fri, 12 Jun 2020 at 18:16, David Sinn <dsinn(a)dsinn.com> wrote: > > > The label stack question is about the comparisons between the two > extremes of SR that you can be in. You either label your packet just for it's > ultimate destination or you apply the stack of the points you want to pass > through. > > In the former case you are, at the forwarding plane, equal to what you see > with traditional MPLS today, with every node along the path needing to > know how to reach the end-point. Yes, you have lowered label space from > traditional MPLS, but that can be done with site-cast labels already. And, > while the nodes don't have to actually swap labels, when you look at > commodity implementations (across the last three generations since you > want to do this with what is deployed, not wholesale replace the network) a > null swap still ends up eating a unique egress next-hop entry. So from a > hardware perspective, you haven't improved anything. Your ECMP group > count is high. > Yes this is where each node needs to have a label uniquely identifying every LSP passing through it. Saku, With IP header you don't need this, Consider this: PE1 to PE2 via 3 P-core nodes With ECMP in IP, then PE1 just needs single FEC the DST-IP of PE2, which will be load-shared across all 3 paths. Using MPLS If you need to uniquely identify each path you need 3 FECs (3 LSPs one via each P core node), now imagine you have 100K possible paths across the fabric -that's a lot of FECs on PE1 or any node in the fabric where each has to have a unique label for every possible unique path via the core that the particular node is part of. > In the extreme latter case, you have to, on ingress, place the full stack of > every "site" you want to pass through. That has the benefits of "sites" only > need labels for their directly connected sites, so you have optimized the > implications on commodity hardware. However, you now have a label stack > that can be quite tall. At least if you want to walk the long-way around the > world, say due to failure. On top, that depth of label stack means devices in > the middle can't look at the original payload to make ECMP decisions. So you > can turn to entropy labels, but that sort of makes matters worse. > David, You can use hierarchy of tunnels to help with the deep label-stack imposition problem. adam

3 10