- NANOG - lists.nanog.org

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

Survey on the use of IP blacklists for threat mitigation
by Rachee Singh 17 Jun '20

17 Jun '20

Hi NANOG community, We are a group of researchers studying the use of IP blacklists as a mechanism to mitigate security threats -- particularly over the IPv6 Internet. We would like to understand if and how you use IP blacklists to secure your networks. Please consider taking our short survey: https://forms.gle/ZEsxyiBivJAfLF7e6 The survey will be anonymous unless you choose to identify yourself. Thanks, Rachee UMass Amherst

8 9

NANOG List Maintenance Announcement
by geeks＠nanog.org 16 Jun '20

16 Jun '20

Summary During the evening on Saturday June 20, 2020 between 0300 to 0600 UTC, the NANOG Tech Committee will preform an upgrade of the mailman software and migration of archives. During this time, all mailing lists will be unavailable, including the ability to make changes to your subscription options. We expect this migration to be completed in three hours time or backed out. Detailed notes NANOG is committed to the availability of its mailing lists as the best direct member community access medium. Ongoing issues with "backskatter" and other annoyances to posters on the list are mitigated in newer versions of mailman. NANOG will be upgrading to the newest stable mailman 2.1 and enabling VERP (Variable Envelope Return Path) [1]. This will make each message to each user unique, and enable tracing bounces or other backskatter annoying emails. VERP will mean a slightly increased load on the MTA (Postfix), however in testing this was found to be a non issue. Our other addition will be to the archives. Currently all archives are split into 2011+, 1994-2011 and even older archives from the NSFNet back to 1992. All these archives will be merged and added into mailman archives. This will provide almost 30 years of archives in a single place. Should anyone have postings before 1992 please let us know, we'd like to capture them as well. Archives to be merged Attendee Jobs Members NANOG NANOG-announce Newcomers Our testing shows this merge and rebuilding the archives to take from 50-70 minutes and will be the majority of the outage time. Additional information A MOP or Method of Procedure is in-place for this maintenance with clear go/no-go steps and a back-out plan should we find any insurmountable problems. An update will be posted to the NANOG mailing list once this is completed. Any messages sent to the list during the maintenance will be queued and retried once the mailman server comes back online. This may delay some messages for a few hours, but no messages will be lost. Any questions may be directed to geeks(a)nanog.org or on-list if of interest to the community. References 1. http://cr.yp.to/proto/verp.txt Status of this Notice This notice provides information for the community. Distribution of this notice is unlimited. Copyright Copyright (C) NANOG, Inc (2020). All Rights Reserved.

1 0

puertorico internet exchange
by Mehmet Akcin 16 Jun '20

16 Jun '20

Hey there as the first bits started flowing through PRIX, I wanted to give a few exciting updates. Current peer lists can be found https://www.peeringdb.com/ix/2353 One of the major social media companies who have a presence in PR has committed to join PRIX. We have also started a slack channel to have better communication with onsite (in PR) people and remote folks to collaborate. You can join the slack https://join.slack.com/t/puertoricoix/shared_invite/enQtODcyMTY4ODEzMTI0LTc… not much traffic yet but here is an attached traffic exchange graph. https://ibb.co/vBS6N30 thanks, everyone for your help Mehmet

1 4

Re: Survey on the use of IP blacklists for threat mitigation
by Rogers, Zachery 16 Jun '20

16 Jun '20

Yikes. I suppose the old guard will continue to block progressive change. We can do better, folks. -- Zach Rogers Lead Security Analyst Network Security Monitoring Oregon Research & Teaching Security Operations Center (ORTSOC) Phone: 541.737.7723 GPG Fingerprint: ECC5 03A6 7E91 17C6 50C6 8FAC D6A0 8001 2869 BD52 ________________________________________ From: NANOG on behalf of J. Hellenthal via NANOG Sent: Tuesday, June 16, 2020 12:08 PM To: Ryan Landry Cc: NANOG; Rachee Singh Subject: Re: Survey on the use of IP blacklists for threat mitigation Guess we all better start rewriting all of the documentation out there because some PC marketing snowflake wants to get extra brownie points and attention for classifying a color in RGB into a racial divide for which it never originated.blacklists are not always deny/block/disallow and conformed of things that allow you to take actions whatever your choosing upon their contents and your policies.What’s next ? redlisting ? Don’t offend the Russians ... blue ? Don’t want to offend the police ...Leave this crap off the list, it’s not helping anyone.SMH-- J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Jun 16, 2020, at 13:27, Ryan Landry <ryan.landry(a)gmail.com> wrote:In kind, I'd like to encourage the use of terms like permit/accept list or deny/block list.Respectfully,-RyanOn Tue, Jun 16, 2020 at 11:33 AM Rachee Singh <rachee.singh(a)gmail.com> wrote:Hi NANOG community,We are a group of researchers studying the use of IP blacklists as a mechanism to mitigate security threats -- particularly over the IPv6 Internet. We would like to understand if and how you use IP blacklists to secure your networks. Please consider taking our short survey: https://forms.gle/ZEsxyiBivJAfLF7e6The survey will be anonymous unless you choose to identify yourself.Thanks,RacheeUMass Amherst

1 0