This is The Internet Report, where we analyze outages and trends across the Internet through the lens of ThousandEyes Internet and Cloud Intelligence. I’ll be here every other week, sharing the latest outage numbers and highlighting a few interesting outages. This week, we’re taking a break from our usual programming for a special conversation with Lefteris Manassakis about all things BGP, including “BGP zombies,” an interesting case of suspicious prefix announcements, and BGP monitoring best practices. As always, you can read more below or tune in to the podcast for firsthand commentary.
BGP & Why It Matters for Secure, Smooth Digital Experiences
Billions of people rely on the Internet every day—often without paying any mind to the invisible threads that keep it all connected. At the crux of this complex web lies Border Gateway Protocol (BGP), the standard that quietly routes our digital lives. But what happens when this standard protocol goes awry?
In this episode of The Internet Report, we’re joined by Lefteris Manassakis. As a pioneering network engineer, researcher, and co-founder of Code BGP (now part of Cisco ThousandEyes), Lefteris brings deep expertise in BGP monitoring and security. We’ll discuss:
- What BGP really is: Find out why BGP is “the glue that holds the Internet together,” and why trust and vulnerabilities are baked into this protocol—and what that means for security.
- The story behind a mysterious BGP incident: Hear what an event in 2023 involving root DNS prefixes revealed about BGP monitoring challenges.
- Why catching “BGP zombies” is critical: Learn how researchers are working to spot and contain stuck BGP routes, as well as best practices for network operators as they work to detect anomalies and protect critical infrastructure.
To learn more, listen now and follow along with the full transcript below. For additional BGP insights, also explore this blog post.
A Conversation on BGP Zombies, Monitoring Best Practices, & More
BARRY COLLINS: Hi, everyone! Welcome back to The Internet Report, where we uncover what's working and what's breaking on the Internet—and why. I'm Barry Collins, and I'll be hosting today with the amazing Mike Hicks, Principal Solutions Analyst at Cisco ThousandEyes.
This week, we're taking a break from our usual programming for a special conversation with Lefteris Manassakis, exploring all things BGP, including “BGP zombies,” an interesting case of suspicious prefix announcements, and BGP monitoring best practices. A seasoned researcher and network engineer, Lefteris co-founded Code BGP, which is now part of Cisco ThousandEyes.
He currently serves as a Software Engineering Technical Leader at ThousandEyes, focusing on BGP monitoring. As always, we've included chapters in the episode description below so you can skip ahead to the sections that are most interesting to you. And if you haven't already, we'd love for you to take a moment to give us a follow over on Spotify, Apple Podcasts, or wherever you like to listen.
So, let's start with the basics. What is BGP, and what is it used for?
LEFTERIS MANASSAKIS: One of my favorite expressions about BGP is that BGP is the glue that holds the Internet together. And it sounds quite graphical, but it's also true because it's the protocol that determines the path that the packets need to follow in order to reach a destination. So, for example, if right now we're talking over the Internet, I am in Greece, you are in the U.K., if I remember, and Mike is in Australia. This communication takes place over autonomous systems, which are networks that essentially have their own capability to configure policy. So each company, each organization has one or multiple autonomous systems, and they can use BGP in order to configure policy and how traffic flows across the network and across the Internet. BGP is the protocol that determines which AS [autonomous system] traffic passes through in order to reach the destination. And it's one of the core protocols of the Internet.
BARRY COLLINS: And it's quite an old protocol, built on trust?
LEFTERIS MANASSAKIS: Correct. So, Geoff Huston says something that I really like, that when BGP was first invented in 1989 and when it first started being used by research institutes and by universities, we didn't expect it would escape the lab. This is his expression, and I really like to use it.
Back then, due to the fact that the network comprised only the universities, government institutes, and research institutes, all these networks trusted each other. So there was no inherent need for building trust in the protocol. Therefore, BGP has had many iterations since 1989. The one that we use now is BGP version four from RFC 4271 of 2006. But still, there is no authentication and authorization on BGP. Anybody can announce anything they would like, essentially the prefixes they want, even if they don't own these prefixes, even if they are not assigned these prefixes. And this can cause a lot of problems.
BARRY COLLINS: So, Mike, what do you think some of those problems are?
MIKE HICKS: So, because we've built on this inherent level of trust there, we could be masquerading as someone else to start with, or we're advertising we know the best way to get to this particular path. There's something that Lefteris said to me previously, which I think goes fundamentally in this, is that we often refer to BGP as a routing protocol, but it isn't a routing protocol itself. It is actually a client-server architectural protocol. So it's actually saying how we get between these two areas.
So, if I actually say I know how to get to the U.K. from here, I could effectively route all traffic through me, and therefore then I've got, effectively, access to that traffic. Because we're working on this level of trust, we have this implication that, okay, this is a legitimate way. You've told me this is the best way to get there, so that's how I'm going to get there. Obviously, we have this problem of not just performance degradation, but also having our traffic effectively flow through somewhere we particularly don't want it to go.
BARRY COLLINS: If it's that easy to hijack routes or send traffic the wrong way, what does that mean for Internet users?
LEFTERIS MANASSAKIS: First of all, it's not that easy anymore. There have been, since 2006 and especially in recent years, since the advent of RPKI and other security mechanisms like BGPsec—which has not been implemented yet—and ASPA, which is a new protocol that protects BGP as well. All these advancements, in combination with BGP filters that networks apply in order to not allow anybody to announce anything. For example, if I am a provider, an ISP, I know that you own these specific prefixes and this is your AS.
So I create a filter in our BGP session, and I allow you to announce only these prefixes. If you want to announce something else, you need to ask me to configure my filter accordingly. There have been efforts to secure BGP. It's not the Wild West out there.
But still, due to the inherent issues that we discussed earlier, BGP hijacks occur, and the outcome of a hijack is, as Mike said, that you can eavesdrop on traffic. This is the more malicious scenario where the hijacker routes the traffic through his network towards the destination. Therefore, he's able to infiltrate the traffic and either steal bitcoins—which is a very common use case—or do any kind of malicious activity by eavesdropping.
And the other bad outcomes are outages. So hijacks can cause complete outages of networks. And in other cases, degradation of traffic. Like, if your path goes through a network that has not enough capacity to support your demand, your customers will suffer from traffic degradation.
MIKE HICKS: We see that a couple of times, essentially, where—and that's not necessarily a hijack, I guess, more a route leak, which amounts to the same thing—instead our traffic goes through different, crosses different boundaries. And this situation where—typically due to a configuration mistake—we've seen this route advertised through an ISP that doesn't have the capacity to carry this traffic, and all of a sudden, we have 50% of the Internet being traversed through a very small regional ISP, which is then going to result in drops and the traffic not actually getting to its destination.
BARRY COLLINS: So let's talk about a specific incident that occurred on May 19, 2023. Can you explain what happened there exactly, Lefteris?
LEFTERIS MANASSAKIS: First of all, I need to say that I am one of the founders of Code BGP. It was acquired by Cisco in August of 2023 and since then, I have worked for Cisco ThousandEyes. Code BGP was a BGP monitoring company, and we had our own software platform that was monitoring BGP globally. And I was monitoring the root DNS prefixes.
Now, I need to explain what root DNS prefixes are, what root DNS system is, and why I was monitoring it. The root DNS servers are the authoritative name servers for the DNS root zone. Essentially, they are one of the most critical infrastructure on the Internet since the DNS system, which is a domain name system, essentially the phone book of the Internet, relies on them. And we have thirteen such DNS operators.
Each one of the operators has hundreds of servers all over the world announcing their DNS prefixes. So, essentially, this service is anycasted. For each prefix, it's being announced all over the world by hundreds of locations, the same prefix by the same AS.
And this is how DNS works.
So, why did I want to monitor these prefixes? There are multiple reasons. One reason is that, as I said, it's critical Internet infrastructure, therefore worth protecting.
A second reason, which is more subtle, is that due to the anycast nature of DNS advertisement via BGP, any hijack—any exact prefix hijack on these prefixes—would be hardly noticed on the data plane due to the fact that it's been announced everywhere. I expected a hijack to have a local impact, but it would not even be picked up by BGP monitoring infrastructures.
So, I wanted to see what I would find when I started monitoring DNS.
And since January of 2023, when I started doing that, I have detected many such incidents, hijacks of all the root DNS prefixes. Actually, I'm writing a blog post about this that will have been released by the time our listeners listen to this podcast.
One of these incidents is May 19, 2023—an incident where one AS started to announce multiple root DNS prefixes at the same time.
It was AS2096861. And it was announcing three IPv6 prefixes that did not belong to them. They were root DNS server prefixes, of course: A-Root, C-Root, and G-Root prefixes.
BARRY COLLINS: And what was the impact?
LEFTERIS MANASSAKIS: That's a great question. As I said, due to the anycast nature of the DNS announcements, I was not able, back then at Code BGP, to detect the exact impact on the data plane because the Code BGP platform was a control plane platform—it had no data plane capability. I could only assume and infer that the impact of the data plane would be negligible due to the anycast nature of DNS that we mentioned earlier. But I had no means to assess the impact of the data plane. And that's one of the very cool things about working for ThousandEyes nowadays. The fact that now we have the ability, whenever an anomaly takes place, to also measure the impact of the data plane using ThousandEyes.
MIKE HICKS: This is really important, Barry, because we have this issue where we're looking at these BGP hijacks and these attacks. We can see a lot of movement or a lot of traffic taking place. But if they're short-lived and then something's happened there when you actually monitor, you may actually miss this bit in between if you look at where the announcements come out. But now because we can associate the data plane with that control plane, that routing plane—we can actually now see specifically the impact itself.
Because that's obviously what you're going to see. And this isn't just the echoes or the effects of it. When we talk about the impacts, we often talk about how we're seeing a high loss rate or we're seeing something like that. But it's not specifically talking about the impact itself.
We can see, in this case, where that traffic is passing through, which ISPs or which paths it's actually taken through. So, you can see, right, “this is the potential impact we're going to have as a result of this.”
LEFTERIS MANASSAKIS: We need to mention two pieces of information for our listeners to have a full view of what we're talking about. The first thing is that we have different types of hijacks. In this case, we are talking about an exact prefix hijack, meaning that the hijacker is announcing the exact same prefix as the one that belongs to the root DNS servers. Whenever you have an exact prefix hijack, the entire Internet is not affected. Only the local area of the hijacker is affected. Various hops near to the hijacker have a shortest path compared to the rest of the Internet.
We have more, even worse attacks than exact prefix hijacks, like sub-prefix hijacks. The hijacker announces a sub-prefix of the actual prefix. In the case of a sub-prefix hijack, due to the fact that the golden rule of routing as we say is that the most specific prefix always wins, when the hijacker announces a sub-prefix of a prefix, it steals the entire Internet traffic towards them.
Therefore, they can cause outages or they can infiltrate the entire traffic and send it back to the legitimate owner.
Therefore, in the case of an exact prefix hijack like the one we're talking about on May 19, 2023, we are not certain what is the exact impact on the data plane because of the nature of the hijack—the fact that it is the exact prefix. There is a second thing that is worth mentioning here, and it largely goes unnoticed by a lot of people: What we say in the research is that the data plane does not always equal the control plane. What does this mean? We might see announcements on BGP determining that the prefix has been announced by this AS, but the traffic—the actual route that the traffic takes—is not always what BGP says. And the reason is that we have static routes, we have default routes, we have Layer 2 tunnels, we have—you name it. We have a lot of various things on the Internet. It's the Wild West out there. Therefore, BGP might not always tell you what the actual route of the traffic will be. You need to take active measurements in order to determine the actual path on the data plane.
BARRY COLLINS: And what made this incident particularly puzzling from a detection standpoint?
LEFTERIS MANASSAKIS: From a detection standpoint, there were multiple things. One is the fact that they were very short-lived announcements. They lasted two minutes, and afterwards they were withdrawn.
Another factor was that there were three root DNS prefixes being announced at the same second, like, at the exact same timestamp.
One of the innovations we introduced at Code BGP was the ability to detect events within three seconds of origination. At the time, it had never been done before, and that's why we were able to detect events with exact-second granularity.
So one unusual thing about this announcement was that it involved three DNS prefixes, and also the fact that they were all announced and withdrawn within the same time frame.
BARRY COLLINS: Were there any other clues that something was amiss?
LEFTERIS MANASSAKIS: At Code BGP, we had developed—and we now have integrated this technology into ThousandEyes—our own monitoring infrastructure. So we were using the RIS Live WebSocket to collect BGP data from RIPE NCC, which is the routing registry for Europe, the Middle East, and Asia.
What was interesting about this announcement that we picked up was that it was being seen by only one RIS peer and it was not being seen by any other peer of RIS Live, which has more than 1,500 peers, out of which almost 700 are v6. Only one of them was picking up this announcement. And there was no Code BGP monitor able to pick up this announcement. So when I noticed that, because it was not an announcement that had a very long AS path for example, so that it would be artificially hidden and unable to be picked up by BGP monitors; it was a normal announcement, with a normal AS path length. It should have been picked up, but it was not.
And that led me, together with discussions I had with other network operators, to the understanding that this was a RIS peer malfunction, essentially. It was not an actual hijack that was taking place.
It was that one RIS peer was, in reality, redistributing these prefixes to the global Internet. It was being picked up by RIS, by the one peer, but then RPKI was stopping these announcements, or BGP filters were stopping these announcements. Therefore, they did not propagate to the rest of the Internet to cause harm. It was just a misconfiguration, the redistribution of false prefixes to BGP, that caused this alert.
BARRY COLLINS: So the defenses that are built into the system to protect against BGP hijacks worked here?
LEFTERIS MANASSAKIS: Yes, correct.
BARRY COLLINS: So what does this incident tell us about the challenges of BGP monitoring?
LEFTERIS MANASSAKIS: Essentially, there are major challenges in terms of being certain that the data that you collect have data integrity and data quality.
There are two major public routing infrastructures that have been in service for the last twenty-plus years. There is RIPE RIS, which we mentioned earlier, and there is also RouteViews, another big network with thousands of peers based in Oregon in the U.S.
Both these infrastructures have been providing a window into the evolution of the Internet over the last three decades for all researchers, and we are all—both researchers and network operators—very appreciative of their work.
And they still do this type of work. They provide this data for free to everyone. But due to the fact—I mean, this is my personal opinion, and I have discussed this with other people as well—up until recently, both these infrastructures have had what we call an open peering policy.
Anybody was able to peer with them and provide data, even if the network was not a professional network, even if it was a hobby with an individual. And when you have such cases where monitors provide the wrong data, there is a chance that this hobby network, the person who owns it, does various tests in order to learn BGP. So you might see data that are not exactly what you are expecting. I'm trying to be as polite as possible because I really care about these networks and I value their contribution, but this is the reality.
BARRY COLLINS: So this incident raises questions about BGP data reliability. Another important factor to consider is BGP zombies. Can you explain what they are and how they relate to monitoring challenges?
LEFTERIS MANASSAKIS: BGP zombies, or stuck routes, or ghost routes, are routes that are persistent in the routing table, despite the fact that they are withdrawn. In the beginning, nobody knew that this would ever happen. Like, we were considering BGP protocol to work 24/7, and there would not be such anomalies. It was in the early 2000s when ghost routes were first detected. The challenge of detecting ghost routes or zombie routes is that we do not know the ground truth on BGP. We do not know who's announcing what, when.
So if you see, let's say for example, at Code BGP, we had in our ThousandEyes hundreds of monitors all over the world. If a specific prefix is visible only by a subset of these monitors like ten, for example, or five of them, this is an indication that this might be a stuck route.
But you cannot be sure because this could also be a routing policy of the network operator. Network operators have the ability to restrict the visibility of a prefix and allow it to be visible in a certain geographic area, for example, for traffic engineering reasons.
We cannot know if this is the case or if it's a zombie. And the way we detect zombies, there has been some research in the late 2010s—two research papers actually—that used the RIPE RIS BGP beacon. These are prefixes that are being announced and withdrawn at specific intervals. They are announced every two hours, then withdrawn for two hours, and then announced again, and so on and so forth.
So we know at each given timestamp whether this prefix is either announced or withdrawn.
Having this ground truth knowledge, if we see at a given timestamp an announced prefix being visible on the Internet, although due to the beacon nature of this announcement, it should have been withdrawn, we know that this prefix is a zombie.
BARRY COLLINS: So what problems do BGP zombies cause?
LEFTERIS MANASSAKIS: They can cause suboptimal routing, which is a best-case scenario, or even outages if you have a routing loop, which is phenomenon that has existed or taken place in the past and taken out large networks. The hard thing about zombies is that they are very, very difficult to detect because you don't have the ground rule, as we discussed. Therefore, you are not sure. Is this an actual announcement or is it a zombie?
BARRY COLLINS: How do zombies relate to the May 19, 2023, incident that we discussed previously?
LEFTERIS MANASSAKIS: The May 19 incident was not a zombie, in reality.
I have had an interest in zombies—actually, I have had an interest in all things related to BGP—but in February of 2023, I did a presentation at NANOG 87 in Atlanta, where I used the previous research that was using beacons, BGP beacons by RIPE, and I did the same exact experiment myself using the Code BGP monitors.
I did a presentation at NANOG called “BGP Zombies,” and I extended this research by announcing prefixes that belong to Code BGP, announcing or withdrawing them at given timestamps—the same logic, but prefixes that belong to Code BGP that were not beacons, to see if there was any difference in the zombie phenomenon between the beacons and the Code BGP prefixes.
And the reason I wanted to compare the two is that in the research papers, they were saying that the “noisy prefixes,” meaning the prefixes that are being announced with wrong calls at least like the beacons, tend to have more zombies.
What would happen if you made announcements of prefixes that previously were not present in the global routing table? Would you have less zombies? Would you be able to detect monitors, RIPE RIS monitors for example, or Code BGP monitors that constantly have zombies compared to monitors that do not?
These are the types of questions that I wanted to answer. And, yes, I also verified that the prefixes that are not noisy, like the ones that belong to Code BGP, have fewer zombies compared to the noisy ones, but they still have a large portion of the Internet seeing zombie prefixes as well. So the zombie phenomenon is largely underestimated—that's what I presented back then. And there's more research that needs to be done.
BARRY COLLINS: What causes a BGP zombie in the first place?
LEFTERIS MANASSAKIS: The root cause is essentially that the BGP update is lost, for whatever reason, and because it’s been lost, it is not withdrawn. A withdrawal is essentially lost, a BGP withdrawal.
Therefore, the prefix is not withdrawn from the routing table of the router, and it appears as a zombie.
The reason can be many things. Typically, there are software bugs on routers. This is the most common phenomenon. Also, routing policies that are inconsistent can cause such phenomena. Even a restart on the routing interface can cause such events.
There are a plethora of reasons why this might happen, but the bottom line in any case is that a BGP update is lost.
BARRY COLLINS: Mike, you cover a lot of outages. How many do you see that are BGP related? How big a problem is this?
MIKE HICKS: I mean, you get the point, basically—does it actually come down to this? The first thing you have to really understand is, you know, is this a real outage? What's actually occurring here? So we're actually looking specifically at the outages, then we're going to correlate the signals across there. So the first thing we're actually looking for is what is the impact, then we're sort of coming down to see what is the cause, because we're looking for that commonality there.
It's a very long answer to say, it does vary, and the first thing we've got to identify is, is this something sort of malicious going on? We can identify this through aspects, such as these routing changes taking place, and then, as Lefteris was saying, looking at the length of the path. So have we got autonomous systems placed in there? What has changed? How has it changed? Is there something that’s been injected into that path that's slightly different, that's therefore impacted our area? Are we going to a black hole? And if we go into a black hole, we then see that implicated, we see a whole bunch of loss situations.
We also have these situations from a BGP perspective, and sort of an internal BGP, when we're looking at the information from within an autonomous system itself. So, as we saw within the Microsoft outage back in January 2023, where we saw these sort of routing updates—this change within there—and they failed to advertise or withdraw the routes there. So we saw, actually, this complete failure of getting into that environment itself.
So it really comes down to trying to identify specifically what's caused it. Because we're looking at BGP as a fundamental, foundational aspect—that routing protocol that allows us to get from A to B or gives us directions for how we're actually going to get across the network—it often impacts these scenarios. But I can't specifically give you a “one every week,” or whatever it is. They are there and it's quite often impacting it because it is a foundational aspect.
So it's really about understanding, “Is it the cause or are we getting it from somewhere else?”
LEFTERIS MANASSAKIS: One more thing that is worth mentioning about the hijacks in particular, and route leaks and BGP anomalies, is that BGP works with the best path selection algorithm, as we say. So each network, each router knows only what their neighbors tell them. They do not have a full view of the network like OSPF, for example. It's not possible in such a huge network like the Internet.
(Parenthesis, because it's quite interesting: Despite the fact that the Internet, from the early days when we had 20,000 prefixes present in the global routing table, now has 1.1 million prefixes in the global routing table and is constantly expanding, and billions of users use it from a few thousand back then, the number of average AS hops that exist on the Internet is the same, 4.5 AS path length, which is astonishing. It speaks to the ability of BGP to scale at such numbers without having any issues.)
MIKE HICKS: Yeah, it's a very good point. Everything we're looking at is my immediate neighbor. I just know how to get to the next hop, so therefore then I know how to get to the next hop. We're trusting those peer relationships, which sort of goes back across everything we've said in terms of trust and understanding filtering, the RPKI, and things like that.
BARRY COLLINS: What's the difference between a malfunction and a deliberate attempt to hijack a BGP route?
LEFTERIS MANASSAKIS: With a malfunction, the issue is that it will cause a false alert for the operator that uses a BGP monitoring system because it will not be a real event. It will be a malfunction in the monitoring system. Therefore, a false positive.
(I will open a parenthesis here to explain something about our approach as researchers at Code BGP: Back at Code BGP, we used to say that we leverage the knowledge of the network operator when it comes to creating alerts because each network operator for their own network, knows which are their prefixes, their AS’s, their neighbors’, and their policies’. They know that. The rest of the Internet does not know it, but they do. So by allowing them to create alerts based on this knowledge—whenever you see, for example, you can say, this AS belongs to me and I'm announcing these prefixes. I know this. If the monitoring system picks up an announcement of your own prefixes by another AS, then you are being alerted and you know that this is not a false positive. You are 100% certain this is not a false positive. And this is like a simple idea, essentially, but powerful, that we were using back at Code BGP, even before as researchers on the paper that I mentioned from 2018. And also now at ThousandEyes, we allow users to encode alerts based on their knowledge. Therefore, when they get alerted, this is not a false positive. I close the parenthesis.)
So in the case of malfunctions, you just get alerted. A hijack can have serious impacts, as we mentioned, like outages. So they're very different events, essentially.
BARRY COLLINS: And what are the lessons here for network operators in regard to BGP zombies and reliability?
LEFTERIS MANASSAKIS: First of all, people need to be aware that zombies exist—because from discussions that I've had with operators in various conferences, a lot of them do not know that zombies exist to begin with. People need to be aware that such phenomena exist so that they can think about how this might be the case when they see such low-visibility prefixes. They need to have a second thought about whether this is actually a policy or if it's a zombie route.
Therefore, they will be able to troubleshoot events whenever they have issues with better accuracy and speed, essentially.
MIKE HICKS: I think another point there is the combining of sources, as well—multiple data points. We often talk about, when we talk about the outages, looking at everything in context. As Lefteris was saying, if I'm looking at it from a monitor that doesn't have access or visibility across the whole of the global routing table, I'm not going to see it. So if I have not necessarily more, but just the pertinent data of specifically where I need to get that, and then combine it with the different signals available, all of a sudden I can actually start to reduce those false positives, corroborate what I'm seeing in conjunction with the alerts, and understand what's going on.
BARRY COLLINS: Finally, the ThousandEyes team also did some recent research on methods for detecting BGP zombies. Can you tell us a bit more about that and where people can learn more if they're interested?
LEFTERIS MANASSAKIS: An intern named Iliana Xygkou came to ThousandEyes. She's a PhD student at Georgia Tech who joined the BGP team last summer and did her research work together with Antonios Chariton, a researcher in the BGP team, and Fontas Dimitropoulos, who's a professor at the University of Crete and the co-founder of Code BGP, along with Vasileios Kotronis and myself.
These three, they worked on a new approach for detecting zombies. They wrote three blog posts about this topic that are available on the engineering blog of ThousandEyes, for everybody who might be interested. The novel approach they presented—and it's a great idea actually—is that in order to detect zombies with accuracy, they created what we call clock beacons—essentially, prefixes. But within the prefix, the timestamp of the announcement is encoded, including the date and the time. And these announcements are announced and withdrawn every fifteen minutes.
And by knowing exactly when they are announced and withdrawn, if you see them persisting in the routing table, you know that this is a zombie. Therefore, you can infer zombies, but you can also infer who's causing them from the AS path along the way—which AS is the most likely suspect. If you see a lot of zombies coming from this AS—a zombie breakout, as we call it—this indicates that it has a router that is malfunctioning for whatever reason: software issue, network issue, or whatever it might be, that is causing zombies to break out.
BARRY COLLINS: Special thanks to Lefteris Manassakis for joining us this week. Please give us a follow and leave us a review on your favorite podcast platform. We really appreciate it. And not only does this help ensure you're in the know when a new episode is published, it also helps us to shape the show for you. You can follow us on LinkedIn or X @thousandeyes or send questions or feedback to internetreport@thousandeyes.com. Until next time, goodbye!