June 2020 - Test - lists.nanog.org

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

RE: Router Suggestions
by Jared Brown 16 Jun '20

16 Jun '20

My no-effort quote from last month lists just the box at $13,000. Once you are all in the total is that 1.5 multiple Baldur mentioned compared to OP. However, if you google "mx204 price" the first hit wants very much to sell you one for <$11,000. Caveat emptor and YMMV. Jared > Yes I too looked into that. And it was not near that price.. Please send me and email off list. I would like to know where I might find that. > >> On Mon, Jun 15, 2020 at 2:58 PM Forrest Christian (List Account) <lists(a)packetflux.com> wrote: >> >> We just got a MX204 quote and it was close to 2.5x the price you're quoting, with apparently the minimum license needed for full tables, and Next Day replacement. >> So if it's really $11K, please shoot me an email off list. Or if someone has a better place to get a decent quote for a MX204, or can clarify where this quote >> might have went wrong, that would be useful too. >> >> We're also looking at going the virtual router route where we put 2-3 servers in a HA cluster loaded up with 10Gb interfaces and running some sort of routing software. >> In case you didn't catch on, I'm >> fairly early in running this idea through the paces, although it seems like this is a pretty common thing nowadays. >> >>> On Mon, Jun 15, 2020 at 6:02 AM Colton Conor <colton.conor(a)gmail.com> wrote: >>> >>> For around $11,000 right now, you can get a brand new Juniper MX204 router. Alternatively, you can get a used MX240 / MX480 with quad power supplies, redundant quad core RE's, and 2 16X10G MIC cards >>>for around $12,000. >>> >>> My question, is there anything else worth looking at in this price range / port configuration? Open to both new and used options. Looking to take full BGP routes. >>> >> >> >> >> -- >> - Forrest

3 3

Re: ROV Deployment (was LDPv6 Census Check)
by John Kristoff 16 Jun '20

16 Jun '20

On Sun, 14 Jun 2020 18:09:24 +0000 Randy Bush <randy(a)psg.com> wrote: > thanks to a few vendor engineers who implemented as skunkworks, > to jay, you, and other large ops who have deployed, and to job > who has taken over waving the pom poms, i am rather optimistic. I concur. I asked our four major networks we (depaul.edu) had connectivity from if they supported ROV in early 2019. Cogent, HE.net, Internet2, and SeverCentral all said they do not and none had plans to deploy. Now two of those are doing some ROV. We've since replaced Zayo for Cogent and I asked them about it in late 2019. I know at least one of the remaining three is seriously looking at supporting it soon. Lots of reasons for the momentum, but two very noticeable reasons from my view were when AT&T announced their deployment and when Google got people worried about dropping routes. John

4 3

Re: Partial vs Full tables
by Jared Brown 16 Jun '20

16 Jun '20

From: Mike Hammett <nanog () ics-il net> Date: Fri, 5 Jun 2020 08:17:26 -0500 (CDT) > I've been wondering a similar thing for how to take advantage of the 150k - 250k hardware routes the CRS317 now has in > v7 beta. That many routes should cover the peering tables for most operators, maybe even transit's customers. Perhaps the thing you are looking for is SIR - the SDN Internet Router https://github.com/dbarrosop/sir TLDR; use pmacct to grab top N ASN speakers and install them into the FIB. Rinse and repeat. Alternatively filter out anything not from ARIN. Conveniently fits into 250k: Prefixes being announced by ARIN Region ASes: 238331 http://gregsowell.com/?p=5505 Should you want something that isn't quite so bleeding edge beta, perhaps pick up a used Arista 7050QX? It's about the same as a CRS317 and holds 144k routes. Jared

1 0

TIMELY – ARIN 45 Virtual Meeting Starts Later Today!
by John Curran 16 Jun '20

16 Jun '20

NANOGers – Our ARIN 45 Virtual Meeting will be held today and tomorrow, and is starting in approximately 5 hours… There’s plenty of time to register for this free event, and participate in the development of the policies by which we manage the ARIN registry. Details available below. Best wishes (and stay safe!) /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: From: ARIN <info(a)arin.net<mailto:info@arin.net>> Subject: [arin-announce] ARIN 45 Will Be Here Soon – Get Ready! Date: 15 June 2020 at 12:34:01 PM EDT To: <arin-announce(a)arin.net<mailto:arin-announce@arin.net>> This week is the ARIN 45 Virtual Meeting, where we will be in the thick of important community discussions on the following policies: - Recommended Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements - Recommended Draft Policy ARIN-2019-10: Inter-RIR M&A - Recommended Draft Policy ARIN-2019-12: M&A Legal Jurisdiction Exclusion - Recommended Draft Policy ARIN-2019-20: Harmonization of Maximum Allocation Requirements under Sections 4.1.8 (ARIN Waitlist) and 4.2.2 (Initial Allocation to ISPs) - Recommended Draft Policy ARIN-2019-21: Reserved Pool Replenishment - Draft Policy ARIN-2020-1: Clarify Holding Period for Resources Received via 4.1.8 Waitlist - Draft Policy ARIN-2020-2: Grandfathering of Organizations Removed from Waitlist by Implementation of ARIN-2019-16 - Draft Policy ARIN-2020-3: IPv6 Nano-Allocations All draft policy text is available at: https://www.arin.net/participate/policy/drafts/ The ARIN 45 agenda will also feature several other informative sessions, including updates on ARIN’s IRR and RPKI. Leading up to the meeting, we want to make sure you are ready to participate. To help you prepare, ARIN has published all of the meeting materials online for you to review or download beforehand. Just visit: https://www.arin.net/ARIN45_materials If this is your first time attending an ARIN meeting, you’ll find the welcome handout particularly helpful if you want to familiarize yourself with some of the ins and outs of ARIN. Need a refresher on ARIN’s Policy Development Process (PDP) before joining us to talk policy? You may want to check out the on-demand version of our PDP webinar, which covers the entire process, start to finish: https://www.arin.net/reference/training/webinars/#the-policy-development-pr… View the full agenda and register today for this meeting while there’s still time: https://www.arin.net/ARIN45 Please contact us at meetings(a)arin.net if you have any questions. We look forward to your participation! Regards, American Registry for Internet Numbers (ARIN)

1 0