BGP Stuck Routes Operational Experience Survey
Dear NANOG community members, We are researchers from Georgia Tech investigating the phenomenon of BGP stuck routes (also known as "zombie routes")—prefixes that persist in routing tables despite being withdrawn by their origin AS. While recent research using BGP beacons (including our work presented at IMC 2025 [1]) confirms that zombie routes occur regularly and can persist for long periods, there is a gap in understanding the operational reality of this issue. We observe the data, but we need to hear from operators to understand the real-world impact and their mitigation responses. We invite you to participate in a brief, anonymous survey to help us assess the extent and impact of this phenomenon in operational settings and to identify common practices for mitigating it. Survey Link: https://forms.office.com/r/9BuWqN0n0J Privacy & Data Usage: This survey is anonymous. We are not collecting any PII (Personally Identifiable Information) data. Thank you for your time and for your contributions to this Internet measurement study. [1] I. Xygkou, A. Chariton, X. Dimitropoulos, and A. Dainotti. "A First Look into Long-lived BGP Zombies". IMC '25. https://doi.org/10.1145/3730567.3764469 Best regards, Iliana Xygkou PhD student Georgia Institute of Technology
Thanks for sharing the survey. In addition to responding, I thought I'd share a blog we wrote late last year detailing our operational experience with stuck routing: https://blog.cloudflare.com/going-bgp-zombie-hunting/ -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Mon, Apr 6, 2026 at 5:02 PM Iliana Xygkou via NANOG < nanog@lists.nanog.org> wrote:
Dear NANOG community members,
We are researchers from Georgia Tech investigating the phenomenon of BGP stuck routes (also known as "zombie routes")—prefixes that persist in routing tables despite being withdrawn by their origin AS. While recent research using BGP beacons (including our work presented at IMC 2025 [1]) confirms that zombie routes occur regularly and can persist for long periods, there is a gap in understanding the operational reality of this issue. We observe the data, but we need to hear from operators to understand the real-world impact and their mitigation responses.
We invite you to participate in a brief, anonymous survey to help us assess the extent and impact of this phenomenon in operational settings and to identify common practices for mitigating it. Survey Link: https://forms.office.com/r/9BuWqN0n0J Privacy & Data Usage: This survey is anonymous. We are not collecting any PII (Personally Identifiable Information) data.
Thank you for your time and for your contributions to this Internet measurement study.
[1] I. Xygkou, A. Chariton, X. Dimitropoulos, and A. Dainotti. "A First Look into Long-lived BGP Zombies". IMC '25. https://doi.org/10.1145/3730567.3764469
Best regards, Iliana Xygkou PhD student Georgia Institute of Technology _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AEBZ3D77...
On Mon, Apr 06, 2026 at 09:05:23PM -0000, Iliana Xygkou via NANOG wrote:
[1] I. Xygkou, A. Chariton, X. Dimitropoulos, and A. Dainotti. "A First Look into Long-lived BGP Zombies". IMC '25. https://doi.org/10.1145/3730567.3764469
Hi, The text refering to reference 9, and reference 9 itself seems wrongly titled: those Large BGP Communities Beacons were my personal project. I was originating routes with large communities from my home router. :-) In that time period, members of my household noticed they couldn't reach certain websites, and that observatoin led to the discovery there was squatting of BGP codepoints: http://largebgpcommunities.net/2016/new-path-attribute-value/ Eventually much more codepoint assignment issues were uncovered, and the registries were updated accordingly: https://datatracker.ietf.org/doc/html/rfc8093 Kind regards, Job
On 07/04/2026 20:06, Bryton Herdes via NANOG wrote: Hi, When a zombie route appears in some stub or esoteric ASN, the damage is minimal. But when a zombie route appears in someone as large as AS3356, that causes chaos. Here is a traceroute for 128.139.7.0/24 - 30 minutes after a withdrawal was issued: 1 vl-51-gw.uoregon.edu (128.223.51.1) [AS 3582] 116 msec 48 msec 48 msec 2 10.252.19.140 48 msec 48 msec 48 msec 3 10.252.10.177 48 msec 48 msec 10.252.9.177 48 msec 4 10.252.10.178 48 msec 48 msec 48 msec 5 128.223.182.77 [AS 3582] 48 msec 48 msec 48 msec 6 10.252.10.250 116 msec 10.252.10.246 48 msec 48 msec 7 eugn-oh-pe-02.net.linkoregon.org (207.98.127.249) [AS 3701] 48 msec 48 msec 48 msec 8 eugn-oh-noc-gw.net.linkoregon.org (207.98.126.13) [AS 3701] [MPLS: Labels 900249/100001 Exp 0] 48 msec 1-1-c23-1.ear2.Sacramento1.Level3.net (4.53.203.181) [AS 3356] 48 msec eugn-oh-noc-gw.net.linkoregon.org (207.98.126.13) [AS 3701] [MPLS: Labels 900249/100001 Exp 0] 48 msec 9 eugn-oh-pe-01.net.linkoregon.org (207.98.126.76) [AS 3701] [MPLS: Labels 900249/100001 Exp 0] 49 msec * 48 msec 10 209.244.187.2 [AS 3356] 146 msec eugn-oh-pe-02.net.linkoregon.org (207.98.127.249) [AS 3701] 48 msec 48 msec 11 ae86.edge2.NewYork6.Level3.net (209.244.187.1) [AS 3356] 116 msec 1-1-c23-1.ear2.Sacramento1.Level3.net (4.53.203.181) [AS 3356] 48 msec * 12 209.244.187.2 [AS 3356] 116 msec 146 msec * 13 209.244.187.2 [AS 3356] 96 msec 96 msec 97 msec 14 209.244.187.2 [AS 3356] 96 msec * 98 msec 15 209.244.187.2 [AS 3356] 104 msec 106 msec * 16 * 98 msec * 17 209.244.187.2 [AS 3356] 96 msec 99 msec 99 msec 18 ae86.edge2.NewYork6.Level3.net (209.244.187.1) [AS 3356] 96 msec * 97 msec 19 ae86.edge2.NewYork6.Level3.net (209.244.187.1) [AS 3356] 97 msec 209.244.187.2 [AS 3356] 97 msec 165 msec 20 * 213 msec ae86.edge2.NewYork6.Level3.net (209.244.187.1) [AS 3356] 98 msec 21 * 209.244.187.2 [AS 3356] 116 msec 100 msec 22 * * 97 msec 23 * 97 msec 96 msec 24 * 74 msec 74 msec 25 209.244.187.2 [AS 3356] 74 msec ae86.edge2.NewYork6.Level3.net (209.244.187.1) [AS 3356] 81 msec 209.244.187.2 [AS 3356] 75 msec 26 * * 75 msec 27 ae86.edge2.NewYork6.Level3.net (209.244.187.1) [AS 3356] 134 msec 209.244.187.2 [AS 3356] 74 msec ae86.edge2.NewYork6.Level3.net (209.244.187.1) [AS 3356] 82 msec 28 * 209.244.187.2 [AS 3356] 97 msec * 29 * 98 msec * 30 * * * AS3356 appears here: https://www.thousandeyes.com/bgp-stuck-route-observatory/?asn=3356 How can I, a non-customer of AS3356, get them to fix their network so as to stop spawning zombie routes? Thanks, Hank
Thanks for sharing the survey.
In addition to responding, I thought I'd share a blog we wrote late last year detailing our operational experience with stuck routing: https://blog.cloudflare.com/going-bgp-zombie-hunting/
-- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare
On Mon, Apr 6, 2026 at 5:02 PM Iliana Xygkou via NANOG < nanog@lists.nanog.org> wrote:
Dear NANOG community members,
We are researchers from Georgia Tech investigating the phenomenon of BGP stuck routes (also known as "zombie routes")—prefixes that persist in routing tables despite being withdrawn by their origin AS. While recent research using BGP beacons (including our work presented at IMC 2025 [1]) confirms that zombie routes occur regularly and can persist for long periods, there is a gap in understanding the operational reality of this issue. We observe the data, but we need to hear from operators to understand the real-world impact and their mitigation responses.
We invite you to participate in a brief, anonymous survey to help us assess the extent and impact of this phenomenon in operational settings and to identify common practices for mitigating it. Survey Link: https://forms.office.com/r/9BuWqN0n0J Privacy & Data Usage: This survey is anonymous. We are not collecting any PII (Personally Identifiable Information) data.
Thank you for your time and for your contributions to this Internet measurement study.
[1] I. Xygkou, A. Chariton, X. Dimitropoulos, and A. Dainotti. "A First Look into Long-lived BGP Zombies". IMC '25. https://doi.org/10.1145/3730567.3764469
Best regards, Iliana Xygkou PhD student Georgia Institute of Technology _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/AEBZ3D77...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6PBWXGLP...
participants (4)
-
Bryton Herdes -
Hank Nussbacher -
ixygkou3＠gatech.edu -
Job Snijders