Telemetry News Now

Telemetry news now.

Welcome to another episode of Telemetry News Now. We are in the midst of summertime, and, we still have a lot of headlines coming out. Typically, things kinda slow down, but we have some news about outages and acquisitions and some security concerns coming out of Washington. So let's get started.

From the Cloudflare block and really all over tech news recently, if you've been paying attention, on July fourteenth twenty twenty five. So about a week ago now from when we're recording today, Cloudflare's one dot one dot one dot one public DNS resolver, everybody's beloved DNS resolver, wanna add. That's my commentary. Experienced a global outage lasting a little over an hour, sixty two minutes to be precise, and it was due to an internal configuration error.

Now I think, Justin, you would agree, Cloudflare has always been pretty good about being transparent with their issues. We don't want them to have any issues, of course, but we gotta give them credit where credit is due. They are usually transparent and quick to respond. So the way they explain it in the blog, and I did follow-up on some other blog posts from other vendors and analysts, the issue began when there was a configuration change that was intended for an unrelated service and it mistakenly included the prefix one dot one dot one dot one and some others, I think.

And that was during like a a routine update. And what happened was the error stayed dormant. You know, they they added the configuration, but it wasn't engaged or enacted in any way.

From June six until it was triggered on July fourteenth when that new those prefixes went into effect. And when I say went into effect, the configuration went into effect that caused the one dot one dot one and associated prefixes to be withdrawn.

And so production data centers around the world lost that, basically cutting off, you know, DNS, name resolution for users that are relying on on those IP addresses for their DNS. So, you know, while DNS or DNS over HTTPS and then and some other UDP based queries, they did remain functional because there are alternate IPs. A lot of people around the world, maybe yourself included, lost DNS resolution. And what's interesting and I saw Doug Madore comment on this on on Twitter.

What's interesting is that there was a BGP hijack by Tata Communications for that prefix one dot one zero one dot zero slash twenty four, so the the twenty four subnet. That was observed at the same time. So there were a lot of folks that kinda jumped to that conclusion, but it does turn out that that was unrelated to the outage. So, yeah, I mean, another check mark for network automation and change management, I guess.

Right? I mean, Cloudflare themselves, they attributed the root cause to legacy systems that use hard coded data and hard coded lists and all that kind of stuff. And so they don't have that kind of progressive mindset, I guess. Maybe they're lacking in that area.

And their remediation plans really just included deprecating those legacy systems and then putting in more programmatic rollouts. And it's like, okay. That's great. So I'm glad they're doing it, but it still does give me a little bit of concern that, like, there are still single points of failure in services, like, that the whole world relies on. You know what I mean?

Yeah. I mean, I think the interesting thing was that, apparently, they're turning on a new service they call DLS, data localization suite. And so they had a new data center that they were prepping to bring online and that's what this configuration change that was, I guess, rolled out in on June sixth. Sounds like it was actually rolled out in an automated way, but the data center wasn't live.

And so they brought the data center live on July fourteenth. It was supposed to be internal only, but somehow, I guess, leaked that prefix, like you said, out to the Internet, routed traffic for the DNS resolver to this new data center, which is not where those resolvers are. So it's not getting to the right end address. Mhmm.

So, you know, a couple things I found interesting in this article. One was that they did have internal systems that alerted them right away to the fact that there was an outage. So they are monitoring, obviously, the health of that DNS resolver service.

So they knew right away they had an issue Yeah.

And were able to roll it back fairly quickly. I mean, you know, a little over an hour outage isn't too bad these days on the Internet compared to some of the ones we've seen that have taken, you know, twenty four hours or whatever to repair. So I think, like you said, they're usually transparent, share a lot of information as than they did in this case.

Like the other thing it it raises as a reminder that, like, you can't rely just on their one dot one dot one dot one resolver. To your point, I use it at home for all of my stuff, but I also use Google's eight dot eight dot eight dot eight. That way, I'm relying on two different technology providers. So if one has an issue, hopefully, other one's still online. So I didn't actually see any impact from it. I presume all of my devices were just not able to reach that one and failed over to to Google's resolvers in that case.

But so Yeah.

You know, just a reminder for all of us that you need redundant systems.

Yep. Absolutely. I use my local service provider's DNS, hard coded, and then I hard code my backup is Google eight dot eight eight dot eight. So I I wasn't affected either, but I do remember it. And, you know, it does also add to the fodder of DNS jokes, so I'll give Cloudflare credit for that because, you know, where where would we be with our DNS memes without these kinds of incidents?

DNS is the Internet for the average user. Right?

Yeah. Yeah. For sure. Right. Right. Okay. So, next up from Yahoo Finance earlier this week, SentinelOne.

That's an endpoint security vendor. Their stock jumped from around nine point eight percent to nineteen nineteen dollars and seventy eight cents share after reports that they are in advanced talks. So some of this is kinda rumors. They're in advanced talks to be acquired by Palo Alto Networks for eight to ten billion dollars.

And so the rumor actually surfaces only a few weeks after SentinelOne posted a quarter one fiscal year twenty twenty six net loss of two hundred and eight million dollars. So that's interesting.

Now neither company has actually commented publicly on this potential deal. But if you do recall, Palo Alto was in was in the process of acquiring Protect AI, and you and I talked about this, Justin. Mhmm. And it actually finalized this week, just the other day.

So it's another security vendor focused on securing AI applications and models, not endpoints per se. Right. But we could see, you know, Palo Alto's expansion here. And I I mean, I think that the acquisition is gonna obviously deepen Palo Alto's endpoint security stack.

Right? They are a security vendor, network security vendor, and some people were considering SentinelOne like a fast up and coming competitor in some respect. So obviously acquiring a competitor eliminates that. That's just something that I read.

But the rumored price here, right, of eight to ten billion dollars, that kinda reflects SentinelOne's, like, really heavy cash burn because that's the stage that they're in. And if it falls through, you know, they're reporting losses. You're gonna see the spotlight, I think, go back to how you know, it's gonna go back to their losses, their heavy cash burn, and that they're competing in a really crowded market. When you look at those, like, Gartner slides or or our slides, can't think for that matter, and you see, like, some network vendors, okay.

You see your smattering of network vendors. You see your smattering of of the visibility vendors and whatever. And then you look at the security slide and you see like endpoint protection and, you know, SASE companies and all those. And, oh my goodness, there are dozens upon dozens upon dozens of customers.

So definitely a very customers. I mean, vendors, excuse me. But definitely a very crowded market.

Yeah. I mean, I don't know if you've ever been to an RSA conference, Bill, but, like, there's a gluttony of vendors that are at something like an RSA, like a security focused conference as sponsors.

It's amazing how many security tools are out there. Right? And for quite a while, the industry has spent big money on anything even related to security. Right?

The security teams at a lot of companies had near unlimited budget. Some of it comes because they get insurance money if there's a breach, and so they get some additional money that's unbudgeted that way. So there's been a lot of spending on things that may or may not really be helping in the end game to make enterprises more secure. You know, think SentinelOne is is a is a great company and and provides a good product, but I think what a lot of the companies are now starting to realize is we need to figure out, like, how do we do some consolidation here.

Right? What does our actual architecture look like and what what's actually providing us value? And so I've been hearing from a number of industry experts that, like, the the spending in security is not really slowing down. It's just that companies are trying to figure out, like, we really gotta have a strategy of, like, what are we buying?

Why are we buying it? How does it all interconnect? And, you know, what's the end goal here as opposed to just a spending spree? And I think that's what's affected SentinelOne in their recent earnings where they've, you know, had a a loss.

They're still their revenues are still growing.

Same quarter last year, they were a hundred and eighty six million, so they're up to two hundred and twenty nine million Mhmm. Year on year, twenty three percent increase in their revenues, but they're still losing money. Right? And so that's why the stock, the, you know, the shareholders are excited if this rumor is true that Palo Alto would come in and buy them out for what represents about an eight to ten x revenue acquisition.

Right? Because, you know, if you're a company and you're if your revenues are growing, but you're losing money and your shareholders can get eight to ten years worth of revenue in one lump sum as an acquisition, that looks pretty attractive. So I can understand why that would be something that the shareholders would be excited about. You'd see that nine point eight percent increase in share price.

Are you seeing, like, large enterprises consolidate security tools? Like, is that actually something that you're seeing when you talk to folks? Mhmm. I know that there are a lot of different tools to handle very, very specific things in the security world. And then, you know, and that includes the network security world. But are you seeing folks like wanna just go with the one vendor? Because that does seem, especially for very like hardcore security people, a little bit, you know, antithetical to what, you know, putting all your eggs in one basket, one vendor's, you know, code base and that sort of thing.

Even though that's gonna be one vendor, I haven't had anybody say that. What I've heard people say is that they may have like fifty or a hundred security vendors that they're paying for out of their security budget.

The question is like Okay.

That's a lot.

Yeah. Could we get down to ten to fifteen? Right? Like, are all these actually providing value?

Right? And, like, how do we consolidate these and make sure that they all work together? Right? And are providing a unified architecture for the security team to be able to actually find and respond to security incidents quickly, which is of course the overarching business goal of all of this.

Yeah, of course. And Palo Alto seems to be going in that direction where they are expanding into, you know, beyond just, you know, edge edge perimeter firewall and and SASE and moving into AI security and and now looking at endpoint and others.

So moving on from network world, US house lawmakers have sent letters to the CEOs of Alphabet, Meta, Amazon, Microsoft, you may have heard of them, requesting detailed disclosures about every submarine cable system in which those companies have ownership or even operational roles.

So as you know, what could be quite a few cables, these could be high capacity cables as well and that potentially operate most of the cloud services that we rely on. Right? Especially if you're talking about globally. So by August four, it's coming up in just a couple weeks, the companies must they must list all cables, the contractors used for construction and maintenance since twenty eighteen, so going back to twenty eighteen, and also the physical and cybersecurity controls that are already in place. Then there's gonna be a follow-up briefing due by August eighth.

So this, I guess we call it an inquiry, it's led by committee chairs focused on homeland security, Europe, the Chinese Communist Party. And according to the article, it does reflect rising concerns that Chinese state linked vendors, you know who they are, may still touch cable routes serving US traffic. Mhmm. And we've seen some recent incidents like in the Baltic Sea, the Red Sea. There was an incident near Taiwan that I think we talked about.

And then there's there was a FCC proposal to block cables containing Chinese, you know, gear and infrastructure. So clearly, there is growing congressional attention to submarine cables in terms of security risks here. This has been, I think, growing for the past couple of years for sure.

Yeah. And like you said, those those incidences have taken place in the Baltic Sea and so forth. It's really hard to figure out whether they're accidental damage or intentional sabotage. Right?

And I think that's really what the government's trying to figure out here is, like, okay. Who owns what? What's our risk profile look like? Right?

And then who are the contractors that are doing the repairs? Because I think one of the companies that it was, I guess, rumored that one of the companies that is a US company that owns one of these undersea cables is using some Chinese technology and subcontractors to do some of the repairs and so forth. So, you know, whether the government actually requires them to change their approach or not is still TBD, but I think at this point, they're just trying to get some information to figure out, like, what is our risk profile here. Right?

If things continue to be unfriendly between the US and China or the US and Russia, which is the other company that they've mentioned in the article, you know, what is the potential impact? Could could the Chinese go and, you know, damage one of these cables intentionally and cut the US off from some of this, you know, some of these places? So I think it's just a matter at this point of gathering information and figuring out what the risk profile actually looks like and then presumably some amount of legislation is gonna follow.

Yep. And I I don't think this is a to use a strange phrase, new news. I mean, this is a philosophy that the government has adopted years ago and has applied in other areas of technology and telecommunications just like the even with five g and then with cloud. It's the idea of supply chain security, right, where, you know, you're looking at the entire chain of vendors, manufacturers, and all of that to identify security risks.

So this is not anything new. What is new is the attention being paid specifically to submarine telecom cables, which really has sort of become very top of mind for folks just in the past few years, I've noticed. And maybe that's just my naive perspective because it's become top of mind for me in the past few years, but I do see this growing body of articles and research and analysis and blog posts and just showing up in mainstream news and media as well. And I mean, this is gonna require from the hyperscalers that we talked about so far, it's gonna require a lot more transparency and a lot more transparency about their joint venture ownership and and and all this because these are global companies for sure.

And you know, Microsoft doesn't have like Microsoft ships that they send out when the cable breaks. They have contractors, you know, multinational contractors that do like break fix and and that and that kind of stuff. So you know, we are gonna see, I think, I think, I say we are, but I believe that we're gonna see any kind of government oversight is always going to adversely affect cost and timelines. You're gonna see, you know, new builds take a little bit longer.

You're gonna see processes put in place for vendors to be vetted and more paperwork to be done and that kind of thing. I I wonder if you're even gonna see like pressure to have additional reroute policies put in place.

Don't The reroute is like the traffic.

Is that what you're thinking?

Yeah.

Yeah. Yeah. Yeah. Absolutely. Like, path diversification and and kind of plan that out more than than it is today. And then also with some oversight from the government. I mean, all that stuff I think is gonna be end up becoming part of their purview more and more as as people are just more aware of how utterly critical to global commerce and global connectivity and communication these undersea cables are.

Yeah. I mean, to your point, I mean, one of the statements in the article is these cables carry about ninety nine percent of international Internet traffic. I'm not sure how they're measuring that, but that number seemed really high to me. I mean, I know that they're very critical, obviously, to our international Internet traffic, but ninety nine percent seems like a pretty high number when there's still a number of places on the world that are not connected with an undersea cable and are having to rely on satellite and some other types of connectivity.

But, yeah, either way, whether they whether ninety nine percent is the right number or not, they're definitely critical to the Internet and I can understand why the government would wanna understand what the risk is, you know, from places like China and Russia that we don't have the most friendly relationship with and especially like one of the things that was mentioned in the article is that some of these undersea cables carry US Department of Defense traffic on it. Right? So there's government traffic on this, not just people browsing the web or viewing Zoom calls. Right?

There's some what the US government would consider to be pretty sensitive and pretty critical traffic flowing on some these undersea cables.

Of course. And the thing is that whether it's ninety nine percent or ninety five percent, it's still the vast vast majority of traffic. Yep. So it's still something. And also, the vast majority of traffic coming from like my house is not necessarily traversing a submarine cable.

Mhmm.

That really is a lot more. Mean, there's hundreds and hundreds of cables, so I'm sure for some things that I'm connecting to, I'm I'm gonna go you know, the bits are gonna go across the ocean. But generally speaking, they're gonna go to POPs and data centers that are in United States and North America, perhaps one continent over. But a lot of that's gonna be backbone traffic for data centers for, you know, Amazon's Europe regions and North America regions and and things like that.

And certainly certainly some end user traffic as well. So I think it's critical just in the operation and then ultimately the trickle down to us, but the operation of these, you know, big cloud providers too. So I don't I don't think we're gonna see like immediate service degradation and things like that, but I think there are gonna be increases to that long haul connectivity cost. And it's gonna get baked into future pricing.

That's how that works. Yep. And then, you know, just as the increase of national security scrutiny just increases and increases, you're gonna see these even at at that stage, hyperscaler reshuffle their cable build plans and road maps and things like that. So we're gonna we're gonna get affected.

But in any case, I do believe it's not anything new. It's just being applied to this technology probably for the first time.

So interesting stuff.

Alright. Next up is an article from Network World titled significant outage at Alaska Airlines, not a security incident, but a hardware breakdown. So folks may have seen that, over the weekend starting on Sunday evening around eight PM Pacific, Alaska Airlines had to do a full ground stop of all of their airplanes due to what was originally announced to be some sort of computer glitch, I think was the way it was phrased in the media. Turns out it was actually not a cyber attack, which is what a lot of folks were suspecting was potentially the case since that happened to Hawaiian Airlines back in June, which is a subsidiary of Alaska owned by Alaska Airlines, that is. In this case, it turns out it was actually a hardware failure in one of their data centers.

And the interesting thing about this, Phil, is that they don't really say what critical piece of hardware it was or what manufacturer it comes from, what vendor it comes from. They just say it was a third party vendor, but it was a multi redundant system. So supposedly, they had whatever equipment it was that failed was in setup in a redundant setup and both the primary and the backup redundant one failed, which leads me to believe it may be something related to, like, a software problem versus a hardware problem. Right?

Potentially something where, like, the primary and the backup are running the same code, hit the same bug, something along those lines. I'm speculating a little bit just based on what was said, but I guess the article kind of points out that even redundant systems can both fail. That doesn't I don't don't think they're trying to go so far as to say there's no point in redundancy if both can fail. I think, you know, it's just a reminder that you need to test your redundancy.

Right? And the article talks about Yeah.

Oh, absolutely.

Talks about companies like Netflix who have been pretty vocal about their Chaos Monkey that they do, which will randomly kill the primary system to make sure that it doesn't cause an outage.

And then they mentioned the somewhat now famous Elon Musk walking in and unplugging things randomly in the data centers at Twitter based on some frustration he had at how long some migrations were taking. And the upside of that is that the website didn't go down, so it did prove that their redundancy does work. So anyway, the point being, I think, the takeaway is that it's really important to test your redundancy to make sure that it is actually providing the redundancy that your design says that it should.

But ultimately, if you start unplugging things and everything is up, great. But if you unplug everything, then nothing is connected. So it's gonna go down. So I think yeah. There there was very little detail. So I I can't make much commentary on the details of this outage other than to say that, you know, it does illustrate the operational risk of failure, hardware and software failure, even in the cases that you have decent redundancy because it does boil down to something somewhere is going to be a single point.

And like you said, they can be hidden single points of failure in the sense that you have primary and secondary or primary active and backup, whatever you wanna call them, but they're using the same code, And then the problem is in the code. So just like you said, Justin, so there's those hidden firmware version, you know, whatever it happens to be. So there's those, I guess, hidden single points of failure that aren't really apparent because you think you have two pieces of hardware running.

Well, you don't think you do. You do have two pieces of hardware running. Oh, yeah. You know, how do you how do you plan around that? How do you get that granular? It was interesting that they did you see how in the article, they very explicitly used the term third party?

Yes.

And I'm like, of course, it's a third party.

Alaska Airlines is not like building servers, you know. Of course, it's third party.

Don't think they're doing white box?

No. I do not. Well, no. Get actually. Maybe maybe there's some, you know, ambitious group of engineers back there in their IT department for sure. But the way I took that was distance distance yourself, kinda like pass the buck just a little bit. Now that could be my cynical passive aggressive nature coming out and reading too much into something, but I did totally see that.

I do have to say, I mean, it wasn't like they named names. Wasn't like they tried to blame it on a specific vendor. Right? They did say it was a third party vendor, but they're not coming out and saying, oh, it was, you know, whatever.

This vendor and, you know, shame on them. Right? So I I did appreciate that part that they were saying that, know, a third party vendor didn't name them. Doesn't probably matter in this case because nobody's innocent when it comes to these type of issues.

Right? It's just a reminder of when we design our network, things we need to think about and be really careful with.

Yeah. Yeah. And and, you know, one other thing I was thinking just now as you were talking was this idea that, like, maybe we need to get better at, like, distinguishing between a security incident and then a hardware failure. I mean, immediately, they were like, security breach.

And we're like, well, and, you know, it came out that it wasn't. But I don't know. I don't know if that speaks to better cybersecurity scrutiny practices or more transparent root cause communication with the public, especially for for an airline where people's lives are at stake. I'm I'm not sure.

But I don't know.

You know, some people say that it wasn't Coldplay's fault that the CEO of Oh, growing there.

Astronomer, you know, got caught. And some people say that it, you know, like him said it was their fault. Gently implied that it was their fault.

Well, he more than gently implied fault or is it the implementer's fault?

That's that's another question.

Yeah. For sure. Alright. Moving on. The next article is from Network World titled, technology is coming so fast, data centers are obsolete by the time they launch.

And this one Phil is interesting to me. I mean, at the beginning of the article, the implication is that the technology is moving so quickly and the data centers that are being built today are going to be obsolete before they're brought online. Because again, remember, you don't just start building a data center tomorrow and a month later, it's online operational and ready to go. Right?

It's a multi year process by from the time you break ground until, you know, everything goes live. Probably three years is is fast and a lot of them take as long as five years. So the point is technology is changing and evolving so quickly right now with the generations of GPUs and some of the technology around power and how much power and cooling you can put into a given rack that they're arguing that, you know, you should just you you shouldn't be building data centers right now. You should wait and see how some of this technology evolves, which I found to be a really interesting thought exercise because, you know, there's a lot of demand right now as we've talked many times on the podcast for data center space.

And I get that you're probably going to be behind if you start building now by the time it comes live. But, I mean, that's just the reality we live with in technology. So there's always a new generation coming.

I think that's a I don't know. Just found an interesting take, Phil. I'm interested to hear what your take is.

It's weird. It's a weird perspective to have, I think, in technology. It's always the case that things go out of date. Now maybe there maybe it's an accelerated pace. Sure. Fine.

And and so there's more of this sense of urgency to get the thing built and and into production so you feel like, am I am I gonna lose money on this hundred billion dollar deal? Sure. I understand that.

But the underlying spirit of, like, technology goes out of date, so you need to be focused on building in a modular nothing's ever future proof, but in a modular design that allows you to upgrade certain components more easily so that way you can, you know, make this investment worthwhile for decades to come. And so whether that is setting yourself up that you can swap out GPUs more easily, you can you can upgrade cooling more easily, you have a mechanism to upgrade power easily, so that kind of forethought. You might think to yourself, oh my goodness, we're gonna have so much so much electricity and power coming into this this data center that we're never gonna need anymore.

And then lo and behold, in three years later, you're like, okay, we need like twice as much power. But you've set yourself up to be able easily accommodate that. And when I say easily, I I say that in air quotes. It's never easy, but you can.

You don't have to build a new data center per se. So I think that's that's really at the root here is that you just have to design with that in mind. And so I think it's a strange thing to say like, don't we're gonna put a pause on building data centers. Actually, If I Justin, if you and I had a company called like Data Center Builders Inc, I don't know.

There's probably a company called that. And we were building data centers. I would totally promote covertly the crap out of this article. So that way all our competitors stopped building data centers and we were like, we're too.

Yeah. Because nobody's gonna stop building data centers. It's a strange take in my opinion. And again, I said it in a previous commentary, maybe it's naive naive perspective of technology, but I I do think that's odd.

I think it just requires that you just give it that much more effort and forethought into being modular and proactive in future thinking in your design.

Well, the other thing I think the article sort of ignores is that these companies that are building data centers like this are not just building one data center and then being done. Right? They're continuing they've got multiple projects in the works, and they've got, like, a road map of additional data centers they're building. So let's just say for the sake of discussion, they're building a data center today, and when it comes online, they're one generation behind in modern, you know, amount of kilowatts per rack you can do and the number of Jeep you know, what generation of NVIDIA GPUs you can support.

They're gonna build another one. Right? That you know, whether it's down the road or somewhere else across the country or in another country, like, they've got more planned. And then next one can be the next generation.

The next one could be the next generation beyond that. And then at some point, they may come back and retrofit some of the older ones. Like, there's there's a whole business model that's bigger than just a single data center, which is sort of what the article tends to imply is that if you're building a data center today, maybe you should wait.

Yeah. And it sort of presupposes that any data centers that's thirty three point seven minutes out of date is therefore useless and not viable, and that's completely false. Mhmm. Yeah.

There's still a huge market for just running even very legacy data centers on, like, just ten gig links everywhere. I mean, so there's still a lot of value there. Obviously, the investment for AI data centers is significantly more, so maybe the value isn't isn't really there. But I think, you know, you get what I'm trying to say is that even if you're a generation out and a generation might be six months, it's still highly valuable functionality, high highly valuable asset, even just the the real estate part, the the structure that you build.

Yeah. Our next article comes from CRM titled new Arista COO, Todd Nightingale. I'm excited to get back to networking. So those not familiar with Todd, Todd was an executive at Meraki when Meraki was acquired by Cisco. He then spent some time in leadership of running basically the Meraki BU inside of Cisco.

He's been over at Fastly for the last few years and just joined Arista as president and COO back in July. And so the CRN article is actually an interview with Todd just asking him why he's excited about the future of Arista and some questions around where he sees Arista's business model going. So I have a little bit of a personal story with Todd. I interviewed at Meraki right as they were being acquired by Cisco, and my final interview was a whiteboard session with Todd, walking through everything that takes place when you fire up your laptop, go to a website in your browser, everything from getting your dynamic IP address, the DNS resolution, the three way TCP handshake, like, walking through the whole thing.

And, you know, I think I did okay at it, but it was amazing how well Todd understands the technology that underlies it. So, you know Mhmm. Yeah. Todd's not just an executive who understands the business aspects, but he's a he's a really great technology practitioner as well.

Yeah. And and then having come from Fastly, right, he was CEO there for some years, and that's a that's a cloud company, edge cloud, whatever you wanna call it.

CDN. Yep.

Yeah. Yeah. So I don't know if that's strategic. I'm sure it is. Everything at this level is strategic.

Really does speak to Arista's move toward I mean, we've been talking about them in the context of data center networking, expanding into the enterprise, now bringing folks that are experts in leading cloud organizations as well. So Yep. Certainly, this does also speak to Arista's continued growth in the networking market and continually trying to go to the next level, very strategically. Strategically, sometimes with technology, sometimes through m and a.

We've we've talked about acquisitions and stuff as well. So I I don't have any personal stories of of this person, but certainly, it does speak to Arista's recent history and where I think they're going right now.

Yeah. The article talks about that during the interview where they talk about the fact that they just recently acquired VeloCloud away from Broadcom VMware. Right? And like you said, Todd's background running Fastly for a few years should play really well with the VeloCloud acquisition, which is SDN, not a CDN, but it's definitely more in, like, the WAN and delivery of of traffic across the WAN.

And so I think his expertise there will be really interesting. The one thing I I found interesting that seems to be missing a little bit in the article is, obviously, he has a background in wireless. Right? Meraki was a wireless provider.

Arista doesn't really have a strong wireless play. So it'll be interesting to see if we see more m and a activity in that. They did ask him about the HPE Juniper acquisition, and he did mention that, you know, it'll be interesting to see what plays out with Aruba and Juniper Mist and how those products shake out and so forth. So that might present an opportunity for Arista there.

Right? Either to acquire a wireless company or maybe HP looks to divest one of those assets and Arista could buy it up at a reasonable price. I don't know. It'd be interesting to to see where that might fit into Arista's strategy going forward.

Well, there's gonna have to be something because in spite of the fact that we were just talking about Fastly and and his experience in cloud, I mean, one of the things that he said was that he's gonna be focusing on enterprise enterprise customers.

Right?

And that wireless is obviously a big part of that.

That's table stakes in any kind of enterprise strategy today. So based on his experience as a traditional network engineer, campus land, we talked about VeloCloud just recently, That's gonna be top of mind for these meetings going forward for for channel engagements and things like that. So yeah. Yeah. I mean, we we we are seeing this shift for sure of Arista into into the enterprise, and this could be a big part of that as well.

Okay. Now moving on to upcoming events, and we're just looking about a month out. So we're looking at toward the end of August. So starting with just a week from now, the Japan Network Operators Group in Matsu City in Japan is on July thirtieth.

I don't know if anyone from Kentik is attending, but we do tend to go to a lot of those NOGs. After that, we have the Indiana Networking User Group, a NOG, part of the USNUA in Indianapolis on July thirty first. Justin, I believe you are doing something with that. Right?

Yeah. I'm just helping the organizers get a little bit more visibility. I've attended that one. I I actually spoke at it one time too. A, you know, like like all these regional NUGs are. It's a good audience and good group of people. So if you're in the Indianapolis area on July thirty first, I definitely encourage you to go check it out.

Great. The remaining list of events are all NUGs, so we'll just run right through them. The next is the Michigan Networking User Group in Detroit on August thirteenth, and then the California Networking User Group in San Francisco. And this is the inaugural group in California.

And so In the Bay Area, right Phil?

In the Bay Area right in San Francisco on August twenty first. I will be speaking at this one, and I will be talking about some practical use cases and implementations of artificial intelligence in specifically network operations. I might go a little bit more broad into IT operations, but specifically network operations. And then last on this list, we have the New York network and user groups, specifically the Buffalo chapter, also on August twenty one. I say specifically Buffalo because New York happens to have several. We have the New York NUG here in the capital region where I live in Saratoga Springs. We have one in Buffalo that goes back and forth between Buffalo and Rochester, and there is one in New York City.

And I wouldn't be surprised to see another one at some point, maybe in central New York. Who knows? So that's the events up until August. Stay tuned for September and October though because, Justin, I don't know about you, but my calendar is booked with travel and hotels for all of those two months, really all the way up till after Thanksgiving into early December. So it is gonna be a busy fall, but we'll talk about that soon. So for now, thanks so much for listening. Those are the headlines for today.