June 2020 - Test - lists.nanog.org

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

RPKI race
by Baldur Norddahl 17 Jun '20

17 Jun '20

Hello I noticed that we regressed and started failing the test at https://isbgpsafeyet.com/. Investigating I found that we apparently had some routes in the validation state "unknown" that should have been either invalid or valid. Including the test prefix which was received via NL-IX (and Cogent on IPv6). We do however have plenty of prefixes that are validated and received from the same sources. This is a Juniper MX204 router running 20.1R1.11. I tried a few things including "clear bgp neighbor xxx soft-inbound" (supposed to rerun the import policy where RPKI marking and check happens) which did not fix it. Doing a "clear bgp neighbor xxx", which disconnects the peer and reconnects after a slight delay, did however fix the issue. But I have to do that for every peer we received the prefix from and potentially we could have trouble with every peer we have :-( This router was software upgraded and rebooted two days ago. I suspect a race condition. What if the router started BGP sessions before it was able to communicate with the RPKI validation server or before the RPKI database was synchronized? I find it a bit disappointing that we this easily ended up with a bad validation state and apparently there is little I can do about it, except for walking through all our peers and BGP reset them. Which frankly is an unacceptable disruption of traffic flow. Regards, Baldur

3 3