July 2019 - Test - lists.nanog.org

Re: CloudFlare issues?
by Francois Lecavalier 04 Jul '19

04 Jul '19

Hi Mark, Following that Verizon debacle I got onboard with ROV, after a couple research I stopped my choice on the ....drum roll.... CloudFlare GoRTR (https://github.com/cloudflare/gortr) If you trust them enough they provide an updated JSON every 15 minutes of the global RIR aggregate. I'll see down the road if we'll fetch them ourselves but at least it got us up and running in less than an hour. It was also easy for us to deploy as the routers and the servers are on the same PoP directly connected, so we don't need the whole encryption recipe they provide for mass distribution. But I also have a question for all the ROA folks out there. So far we are not taking any action other than lowering the local-pref - we want to make sure this is stable before we start denying prefixes. So the question, is it safe as of this date to : 1.Accept valid, 2. Accept unknown, 3. Reject invalid? Have any large network who implemented it dealt with unreachable destinations? I'm wondering as I haven't found any blog mentioning anything in this regard and ClouFlare docs only shows example for valid and invalid, but nothing for unknown. My assumption is that 1.Accept valid, 2. Accept unknown, 3. Reject invalid shouldn't break anything. Thanks, -Francois This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier ?lectronique est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous recevez ce courrier ?lectronique par erreur, veuillez m'en aviser imm?diatement, par retour de courrier ?lectronique ou par un autre moyen.

5 12

Real-world MPLS P/LSR experience on BCM T3 (X5/X7) vs T2+
by Jason Lixfeld 04 Jul '19

04 Jul '19

Hey all, In the role of an MPLS P/LSR, I’m curious if there have been any gotchas (or fixes) revealed with BCM T3 vs. T2+. I remember reading somewhere some years ago that there were oddities on the T2+ that I’d like to believe have been addressed on T3, but does anyone have any real-world experience with T3 in an MPLS core? (IS-IS, LDP, rLFA, 2-3 labels wide, likely SR/Seamless/BGP-LU/whatever down the road) I’m sure J, C, A, etc. all have their own challenges wrapping their code around the APIs, so would be curious to hear anything anyone has to share along those lines as well. Thanks in advance.

1 0

Any contact at VERIZON who manages @VTEXT.COM?
by Curtis Generous 04 Jul '19

04 Jul '19

We started seeing emails to @VTEXT.COM being periodically rejected earlier in the week, and now most/all our getting soft-bounced. Anyone here on the list have contact info at VERIZON who can assist in troubleshooting this? All normal channels to get hold of their support have failed Thanks --curtis

1 0

Microsoft SNDS contact
by Brian Rak 03 Jul '19

03 Jul '19

We've been trying to get SNDS access for our IP space, and we keep running into issues where the SNDS site is unable to determine what emails it should use to authorize access. SNDS support has so far been very unhelpful, they keep trying to tell us to submit the space as individual /24's, which is less then helpful when we have multiple /18s we're trying to set up. Does anyone have a contact at Microsoft that can help?

3 7

Re: few big monolithic PEs vs many small PEs
by James Bensley 03 Jul '19

03 Jul '19

On Wed, 19 Jun 2019 at 21:23, <adamv0025(a)netconsultings.com> wrote: > > Hi folks, > > Recently I ran into a peculiar situation where we had to cap couple of PE > even though merely a half of the rather big chassis was populated with > cards, reason being that the central RE/RP was not able to cope with the > combined number of routes/vrfs/bgp sessions/etc.. > > So this made me think about the best strategy in building out SP-Edge > nowadays (yes I'm aware of the centralize/decentralize pendulum swinging > every couple of years). > The conclusion I came to was that *currently the best approach would be to > use several medium to small(fixed) PEs to replace a big monolithic chasses > based system. > So what I was thinking is, > Yes it will cost a bit more (router is more expensive than a LC) > Will end up with more prefixes in IGP, more BGP sessions etc.. -don't care. > But the benefits are less eggs in one basket, simplified and hence faster > testing in case of specialized PEs and obviously better RP CPU/MEM to port > ratio. > Am I missing anything please? > > *currently, > Yes some old chassis systems or even multi-chassis systems used to support > additional RPs and offloading some of the processes (e.g. BGP onto those) > -problem is these are custom hacks and still a single OS which needs > rebooting LC/ASICs when being upgraded -so the problem of too many eggs in > one basket still exists (yes cisco NCS6k and recent ASR9k lightspeed LCs are > an exception) > And yes there is the "node-slicing" approach from Juniper where one can > offload CP onto multiple x86 servers and assign LCs to each server (virtual > node) - which would solve my chassis full problem -but honestly how many of > you are running such setup? Exactly. And that's why I'd be hesitant to > deploy this solution in production just yet. I don't know of any other > vendor solution like this one, but who knows maybe in 5 years this is going > to be the new standard. Anyways I need a solution/strategy for the next 3-5 > years. > > > Would like to hear what are your thoughts on this conundrum. > > adam > > netconsultings.com > ::carrier-class solutions for the telecommunications industry:: Hi Adam, Over the years I have been bitten multiple times by having fewer big routers with either far too many services/customers connected to them or too much traffic going through them. These days I always go for more smaller/more routers than fewer/larger routers. One experience I have made is that when there is an outage on a large PE, even when it still has spare capacity, is that the business impact can be too much to handle (the support desk is overwhelmed, customers become irate if you can't quickly tell them what all the impacted services are, when service will be restored, the NMS has so many alarms it’s not clear what the problem is or where it's coming from etc.). I’ve seen networks place change freeze on devices, with the exception of changes that migrate customers or services off of the PE, because any outage would create too great an impact to the business, or risk the customers terminating their contract. I’ve also seen changes freeze be placed upon large PEs because the complexity was too great, trying to work out the impact of a change on one of the original PEs from when the network was first built, which is somehow linked to virtually every service on the network in some obscure and unforeseeable way. This doesn’t mean there isn’t a place for large routers. For example, in a typical network, by the time we get to the P nodes layer in the core we tend to have high levels of redundancy, i.e. any PE is dual-homed to two or more P nodes and will have 100% redundant capacity. Down at the access layer customers may be connected to a single access layer device or the access layer device might have a single backhaul link. So technically we have lots of customers, services and traffic passing through larger P node devices, but these devices have a low rate of changes / low touch, perform a low number of functions, they are operationally simple, and are highly redundant. Adversely at the service edge, which I guess is your main concern here, I’m all about more smaller devices with single service dedicated devices. I’ve tried to write some of my experiences here (https://null.53bits.co.uk/index.php?page=few-larger-routers-vs.-many-smalle…) The tl;dr version though is that there’s rarely a technical restriction to having fewer large routers and it’s an operational/business impact problem. I'd like to hear from anyone who has had great success with fewer larger PEs. Cheers, James.

2 3

Intermittent "bad gateway"
by Stephen Satchell 02 Jul '19

02 Jul '19

Are we having another BGP problem this morning?

13 12

Re: Ideas to products (Shark Tank(-ish) @ Austin)
by Mehmet Akcin 01 Jul '19

01 Jul '19

Great point ;-) thanks Tom On Sat, Jun 29, 2019 at 09:29 Tom Daly <tjd(a)fastly.com> wrote: > Mehmet, > > Good idea, the opportunity for innovation and supporting ideas of others > in our operator groups is important, but NANOG is probably the wrong venue. > > Have you considered NANOG's 501c3 not-for-profit status in your analysis > of bringing this idea to the community? As a presenter, how would one > protect his/her intellectual property being shown to the proposed "sharks" > and/or the audience? (would an audience be permitted in the room?) > > I can't speak for the NANOG Board nor the Program Committee, but as an > interested party in NANOG's 501(c)3 not-for-profit status, I am pretty > certain this activity would jeopardize our recognized exemption with the > IRS. I think this is an important detail you explore before proceeding. > > HTH, > Tom > > On Sat, Jun 29, 2019 at 11:11 AM Mehmet Akcin <mehmet(a)akcin.net> wrote: > >> Hey there, >> >> I am trying to put together an event at NANOG Austin (will submit pc when >> CFP is open). So many of us had very interesting ideas over the years. Some >> of these ideas became products or companies making life easy for engineers >> and operators. Could there be other ideas waiting to be supported? Perhaps. >> I am sure you all watched shark tank! In simplest words i am trying to >> organize an event very similar to Shark Tank!( we will call it some other >> name tho) >> >> There will be some known investors on the stage and you will 5 mins for >> your pitch and 10 mins to answer questions, and hopefully make a deal. >> >> I will help those who want to pitch their idea with their p&l , >> presentation and other things as they needed. >> >> Please contact me if you have any questions offlist and want to pitch >> your idea. We need a single paragraph to get you started. >> >> Mehmet >> -- >> Mehmet >> +1-424-298-1903 >> > > > -- > Tom Daly - SVP, Infrastructure > tjd(a)fastly.com > -- Mehmet +1-424-298-1903

3 2

Ideas to products (Shark Tank(-ish) @ Austin)
by Mehmet Akcin 01 Jul '19

01 Jul '19

Hey there, I am trying to put together an event at NANOG Austin (will submit pc when CFP is open). So many of us had very interesting ideas over the years. Some of these ideas became products or companies making life easy for engineers and operators. Could there be other ideas waiting to be supported? Perhaps. I am sure you all watched shark tank! In simplest words i am trying to organize an event very similar to Shark Tank!( we will call it some other name tho) There will be some known investors on the stage and you will 5 mins for your pitch and 10 mins to answer questions, and hopefully make a deal. I will help those who want to pitch their idea with their p&l , presentation and other things as they needed. Please contact me if you have any questions offlist and want to pitch your idea. We need a single paragraph to get you started. Mehmet -- Mehmet +1-424-298-1903

2 1