본 콘텐츠는 사용자의 편의를 고려해 자동 기계 번역 서비스를 사용하였습니다. 영어 원문과 다른 오류, 누락 또는 해석상의 미묘한 차이가 포함될 수 있습니다. 필요하시다면 영어 원문을 참조하시기를 바랍니다.
저희 Cloudflare에서는 저희만의 좀비 사냥으로 할로윈을 축하해 왔습니다. 제거하려는 좀비는 인터넷에서 트래픽을 라우팅하는 방법을 담당하는 코어 프레임워크를 방해하는 좀비입니다. 경계게이트웨이 프로토콜(BGP).
BGP 좀비는 인터넷의 Default-Free Zone(DFZ)에서 멈춘 경로에 대한 어리석은 이름입니다.
좀비의 근본적인 근본 원인은 라우터의 버그가 있는 소프트웨어 또는 일반적인 경로 처리 속도와 같이 여러 가지일 수 있습니다. 이 시기는 BGP 접두사가 인터넷에서 사라지게 하려는 의도이지만, 이런 식으로 접두사가 언데드의 일원이 되어 일정 시간 떠돌아다니게 되는 시기입니다.
이러한 좀비가 오래 남아있을수록 운영에 더 큰 영향을 미치고 네트워크 운영자에게는 진정한 골칫거리가 됩니다. 좀비는 패킷을 경로 루프 내부에 가두거나 지나치게 멋진 경로를 선택하도록하여 패킷을 잘못 이끌 수 있습니다. 오늘은 BGP 좀비가 형성되는 과정과 이들이 인터넷 트래픽에 큰 피해를 줄 가능성을 낮추는 방법을 다루며 할로윈 데이를 기념하고자 합니다.
BGP 좀비로 이어지는 경우가 많은 속도를 이해하려면 먼저 경로 사냥에 대해 이야기할 필요가 있습니다. 경로 헌팅은 BGP를 실행하는 라우터가 LPM(Longest Prefix Matching)과 경로 길이, 로컬 기본 설정 등의 BGP 라우팅 속성에 의해 결정되는 접두사에 대한 최상의 경로를 철저하게 검색할 때 발생합니다. 이는 경로가 정확히 어떻게 막히는지, 얼마나 오래 멈추는지, 인터넷에 표시되는 정도를 관찰하는 데 중요한 역할을 합니다.
예를 들어, 경로 사냥은 보다 구체적인 BGP 접두사가 글로벌 라우팅 테이블에서 철회되고 네트워크가 덜 구체적인 BGP 알림으로 폴백해야 할 때 발생합니다. 이 예에서는 구체적인 BGP 알림에 2001:db8::/48을 사용하고 덜 구체적인 접두사에 2001:db8::/32를 사용합니다. 원래 자율 시스템 (AS)이 /48을 철회하면 BGP 라우터는 해당 경로를 누락된 경로로 인식하고 2001:db8::/32 경로를 통해 2001:db8::1과 같은 IP로 트래픽을 라우팅하기 시작해야 합니다. 접두사 2001:db8::/48은 사라졌지만,
몇 가지 다이어그램을 통해 실제로는 어떤 모습일지 살펴보겠습니다.
다이어그램 1: 활성 2001:db8::/48 라우트
이러한 초기 상태에서 2001:db8::/48은 트래픽 전달에 적극적으로 사용되며, 모두 AS64511로 가는 도중에 AS13335를 통해 흐릅니다. 이 경우 AS64511은 Cloudflare의 BYOIP 고객이 됩니다. AS64511은 또한 다른 인터넷 서비스 공급자(ISP)인 AS64510에 백업 경로를 알리지만, 2001:db8::1로의 전달을 위한 AS64510의 라우팅 테이블에서도 이 경로는 활성화되지 않습니다. 2001:db8::/48이 더 긴 접두사 일치이기 때문입니다 2001:db8::/32와 비교하면요.
AS64510이 Cloudflare에 의해 2001:db8::/48을 철회하라는 신호를 보내면(AS13335) 상황이 더욱 흥미로워집니다.
고객이 2001:db8::/48 알림을 철회하라고 Cloudflare에 신호를 보내면(BGP 제어 또는 API 호출을 통해) 모든 BGP 라우터는 이 업데이트에 따라 경로 사냥을 포함하여 수렴 해야 합니다. AS13335는 직접 연결된 BGP 이웃에게 2001:db8::/48에 대한 BGP 철회 메시지를 보냅니다. 철수 소식은 AS13335에서 다른 네트워크로 빠르게 전파될 수 있지만, 일부 이웃에는 다른 네트워크보다 더 빨리 전파될 수 있습니다. 이는 모두가 인출을 수신하고 처리할 때까지 네트워크가 AS13335가 인출을 인출한 후에도 2001:db8::/48 접두사에 도달하기 위해 서로를 통해 라우팅할 수 있음을 의미합니다.
Diagram 2: 2001:db8::/48 route 철회된 by AS13335
AS64501이 구형 하드웨어의 사용, 하드웨어 과부하, 소프트웨어 버그, 특정 구성 설정, 불운 등의 요인으로 인해 나머지보다 약간 느리지만, /48 인출을 아직 처리하지 않았다고 상상해 보세요. 경로가 짧은 기간 동안 정체되어 있기 때문에, 그 자체로 BGP 좀비가 될 수 있습니다. 2001:db8::1에 대한 ping은 실제로 AS64511에 도달할 수 없습니다. AS13335는 /48이 철회되어야 한다는 것을 알고 있지만, 전체 테이블을 가진 일부 라우터는 아직 그 결과로 수렴하지 않기 때문입니다.
경로 사냥에 소요되는 시간은 MRAI(Minimum Route Advertisement Interval)에 의해 증폭됩니다. MRAI는 BGP 라우터에서 전송되는 BGP 알림 메시지 사이의 최소 시간을 지정합니다. 즉, 각 BGP 알림 업데이트 사이에 의도적인 지연 시간(초)을 도입합니다. RFC4271 에서는 eBGP 업데이트에 MRAI 값을 30초로 설정할 것을 권장하며, 이렇게 하면 BGP의 수다함이나 잠재적인 업데이트 변동을 줄일 수 있지만, 경로 사냥을 더 오래하게 만듭니다.
다음 경로 사냥 주기에서는 이전에 AS13335에서 여전히 존재하지 않는 /48 경로를 가리키고 있던 AS64501조차도 /32 알림이 2001:db8::1을 향해 남아 있다는 것을 알게 됩니다. 완료되면 트래픽 흐름은 다음과 같이 됩니다.
다이어그램 3: DFZ에서 2001:db8::/32 및 2001:db8::/48로의 라우팅 폴백이 사라졌습니다
이는 BGP 경로 사냥이 끝났고 인터넷에서 2001:db8::/32가 2001:db8::1로 갈 수 있는 최선의 경로라는 것을 깨달았다는 것을 의미하며, 실제로 2001:db8::/48은 사라졌습니다. 이 예에서는 의도적으로 경로 사냥이 2 사이클만 지속되도록 만들었지만, 실제로는 훨씬 더 많을 수 있습니다. 특히 AS13335가 전 세계 수천 개의 피어링 네트워크 및 Tier-1과 얼마나 연결되어 있는지에 따라 달라질 수 있습니다.
이제 BGP 경로 사냥과 그 작동 방식에 대해 살펴보았으므로, 이제 여러분도 BGP 좀비 발생이 어떻게 시작되고 라우팅 테이블이 오랜 시간 동안 정체될 수 있는지 알 수 있을 것입니다. 이전에 알려진 보다 구체적인 접두사에 대한 과도한 BGP 경로 사냥은 좀비가 따를 수 있는 초기 지표가 될 수 있습니다.
최근 우리의 관심을 끈 것은 좀비에 대해 Magic Transit에 Bring-Your-Own-IP(BYOIP) 온디맨드 광고를 활용하는 고객이 있었기 때문입니다. BYOIP는 접두사가 지속적으로 발표되는 "always-on" 모드와 고객이 원할 때만 접두사가 발표되는 "on-demand"의 두 가지 모드로 구성할 수 있습니다. 일부 온디맨드 고객의 경우 발표 및 철회 주기가 더 잦아 BGP 좀비가 증가할 수 있습니다.
이를 염두에 두고 경로 사냥이 어떻게 작동하는지 알았으니, 인터넷에 우리 좀비를 스폰시켜 봅시다. 이를 위해 IPv4 및 IPv6의 여유 블록을 다음과 같이 발표합니다.
경로가 발표되고 안정화되면, Cloudflare를 통해 광고된 보다 구체적인 경로를 전 세계적으로 철회할 것입니다. 몇 번의 클릭만으로 망자를 성공적으로 소생시켰습니다.
변종 A: Ghoulish Gateways
좀비가 일반적으로 발생하는 한 장소는 업스트림 인터넷 서비스 공급자 사이입니다. 특정 인터넷 서비스 공급자 네트워크 내의 라우터 중 하나가 업데이트 속도가 조금 느리면 경로가 정체될 수 있습니다.
예를 들어 업스트림 파트너 두 곳 사이에서 관찰된 다음 루프를 살펴보겠습니다.
7. be2431.ccr31.sjc04.atlas.cogentco.com
8. tisparkle.sjc04.atlas.cogentco.com
9. 213.144.177.184
10. 213.144.177.184
11. 89.221.32.227
12. (waiting for reply)
13. be2749.rcr71.goa01.atlas.cogentco.com
14. be3219.ccr31.mrs02.atlas.cogentco.com
15. be2066.agr21.mrs02.atlas.cogentco.com
16. telecomitalia.mrs02.atlas.cogentco.com
17. 213.144.177.186
18. 89.221.32.227
또는 동일한 금단 테스트에서 관찰된 이러한 루프가 서로 다른 두 공급자 사이에서 발생했습니다.
15. if-bundle-12-2.qcore2.pvu-paris.as6453.net
16. if-bundle-56-2.qcore1.fr0-frankfurt.as6453.net
17. if-bundle-15-2.qhar1.fr0-frankfurt.as6453.net
18. 195.219.223.11
19. 213.144.177.186
20. 195.22.196.137
21. 213.144.177.186
22. 195.22.196.137
변형 B: 언데드 LAN(근거리 통신망)
동시에 특정 네트워크 내에서만 좀비가 발생할 수 있습니다. Cloudflare 네트워크에서 경로를 철회하면 네트워크의 각 장치가 개별적으로 경로 철회 절차를 시작해야 합니다. 일반적으로는 원활한 프로세스이지만, 여전히 문제가 발생할 수 있습니다.
예를 들어, Cloudflare 네트워크 내의 한 라우터가 아직 출금을 완전히 처리하지 못한 상황을 가정해 보겠습니다. 연결 파트너는 실제로 트래픽을 처리할 수 있는 라우터 뒤에 호스트가 남아 있지 않은 동안(아직 철수를 수신하지 않았으므로) 해당 라우터 쪽으로 트래픽을 계속 라우팅합니다. 그 결과 내부 전용 루프 경로가 생성됩니다.
10. 192.0.2.112
11. 192.0.2.113
12. 192.0.2.112
13. 192.0.2.113
14. 192.0.2.112
15. 192.0.2.113
16. 192.0.2.112
17. 192.0.2.113
18. 192.0.2.112
19. 192.0.2.113
가상으로 묘사된 대부분의 보물 창고와 달리 잘 보이는 우리의 좀비는 대부분의 주요 네트워크에서 수명이 제한되어 있습니다. 만듭니다. 안타깝게도 이 시간은 어떤 경우에는 장수명 좀비가 10분 이상 연결 문제를 일으키기도 합니다. 이 시간은 대부분의 네트워크 운영자가 정상적인 상황에서 BGP 융합에 소요될 것으로 예상하는 것보다 더 깁니다.
하지만 앞서 이야기한 과도한 경로 사냥인가요? 아니면 BGP 좀비인가요? 실제로, 이는 BGP 융합이 접두사 철회를 처리하는 데 걸리는 시간 에 대한 기대와 허용 오차에 따라 달라집니다. 어쨌든, 보다 특정한 접두사를 철회한 지 30분이 지나도 경로 뷰 공개 수집기에서 좀비 경로를 쉽게 볼 수 있습니다.
~ % monocle search --start-ts 2025-10-28T12:40:13Z --end-ts 2025-10-28T13:00:13Z --prefix 198.18.0.0/24
A|1761656125.550447|206.82.105.116|54309|198.18.0.0/24|54309 13335 395747|IGP|206.82.104.31|0|0|54309:111|false|||route-views.ny
계층 1 네트워크 계층에서 최악의 경우 BGP 수렴에 걸리는 시간은 6분에서 11분(또는 그 이상이 합리적인 시간)이라고 주장할 수도 있지만, 그 시간 자체도 길어진 것처럼 보입니다. 이를 제쳐두더라도, 우리의 데이터에 따르면 매우 실제적인 BGP 좀비는 글로벌 라우팅 테이블에 존재하며 트래픽에 부정적인 영향을 미칩니다. 흥미롭게도 경로 사냥 지연은 IPv4에서 더 악화되었으며, 주요(계층 1) 네트워크에서 관찰된 가장 긴 IPv6 영향은 4분을 조금 넘었습니다. 혹자는 이것이 부분적으로는 IPv6 글로벌 테이블보다 인터넷 글로벌 라우팅 테이블에 있는 IPv4 접두사의 수가 훨씬 많고 BGP가 이를 개별적으로 처리하기 때문이라고 추측할 수 있습니다.
출처: RIPEstat의 BGPlay
지연의 일부는 AS13335가 상호 연결된 방식에서 비롯된 것으로 보입니다. 인터넷의 많은 부분과 집중적으로 피어링하면 경로가 특정 위치에서 멈출 가능성이 높아집니다. 이를 감안할 때, 좀비가 반대로 방향으로 움직였다면 수명이 더 짧았을 것입니다. 철수는 피어링이 덜한 네트워크에서 이루어지기 때문에 융합에 걸리는 시간이 단축될 수 있습니다.
실제로 예상대로 여전히 경로가 정체되어 있으며, Tier 1 네트워크 계층에서 약 20초 동안만 생존합니다.
19. be12488.ccr42.ams03.atlas.cogentco.com
20. 38.88.214.142
21. be2020.ccr41.ams03.atlas.cogentco.com
22. 38.88.214.142
23. (waiting for reply)
24. 38.88.214.142
25. (waiting for reply)
26. 38.88.214.142
안타깝게도 그 20초는 여전히 영향력이 있지만, 더 개선되면 우리가 원하는 수준이 아닙니다. 정확한 시간은 연결된 기본 인터넷 서비스 공급자 네트워크에 따라 다르며 몇 분 분량의 라우팅 중단으로 완화될 수 있습니다.
두 경우 모두 초기 발표 시간 때문에 손실이 발생하지 않았으며 두 경로 모두 초기 수명 내내 유효했기 때문에 좀비가 생성되지 않았습니다. 좀비는 보다 구체적인 접두사가 완전히 철회된 경우에만 만들어졌습니다. 새로 발표된 경로는 철회된 보다 구체적인 경로와 같은 방식으로 경로 사냥의 대상이 되지 않습니다. 사람들이 말하듯이, 좋은 (새로운) 소식은 빠르게 전달됩니다.
저희 연구 결과는 보다 구체적인 접두사를 철회하면 좀비가 더 오랜 시간 동안 만연할 수 있다고 믿게 되었습니다. 따라서 저희는 당사의 온디맨드 BGP 기능에 의존하는 고객에게 BGP 좀비 라우팅의 영향을 덜 미치는 몇 가지 개선 사항을 모색하고 있습니다.
Cloudflare에 도달하는 트래픽에 대해, 내부적으로 BGP 트래픽 포워딩 개선 사항을 도입할 예정입니다. 여러 면에서, BGP를 실행하는 서버에서 잘 알려진 내보내기 금지 커뮤니티의 BGP 기능과 매우 유사합니다. 즉, 라우팅이 중단되어 외부 당사자로부터 트래픽을 수신하는 경우에도 터널 연결 또는 Cloudflare 네트워크 상호 연결(CNI)을 통해 상대방 고객에게 트래픽을 전달할 수 있는 기회는 여전히 있습니다. 기본적으로 트래픽을 보다 원활하게 배출하기 위한 이러한 개선 작업의 긍정적인 영향을 추후 보고드릴 예정입니다.
Cloudflare의 에지에 도달하지 않고 대신 네트워크 공급자 사이의 루프의 경우에는 다른 접근 방식을 사용해야 합니다. 특정한 접두사 라우팅 폴백이 BGP 좀비 발생에 더 취약하다는 것을 알고 있기 때문에, Cloudflare는 고객이 사용하지 않는 온디맨드 접두사에 대해 Cloudflare 에지에서 트래픽을 배출하기를 원할 경우, 대신 다단계 드레이닝 프로세스를 사용하도록 권장하고 있습니다. 경로 루프 또는 블랙홀 이벤트를 도입하는 것입니다. Cloudflare에서 BYOIP 접두사에 대한 트래픽을 제거할 때의 소모 프로세스는 다음과 같습니다.
이 고객은 이미 Cloudflare를 통해 example 접두사를 발표하고 있습니다. 198.18.0.0/24
고객은 네트워크에서 트래픽을 대체하려는 인터넷 서비스 공급자에게 접두사 198.18.0.0/24(즉, Cloudflare를 통해 알리는 접두사와 동일한 길이)를 기본적으로 알리기 시작합니다.
몇 분 후 고객은 198.18.0.0/24 접두사를 위해 Cloudflare에서 BGP 인출을 알립니다.
결과는 깔끔하게 차단됩니다. 같은 길이의 접두사(198.18.0.0/24)가 글로벌 라우팅 테이블에 남아 있기 때문에 영향력 있는 좀비를 피할 수 있습니다. 라우터에서 누락된 보다 구체적인 접두사 일치 항목을 적극적으로 찾아야 하는 대신, 고객 네트워크까지의 기본적으로 시작된 경로에서 라우팅 테이블에 지속되는 동일 길이의 알림으로 폴백할 수 있으므로 과도한 경로 사냥을 피할 수 있습니다.
출처: RIPEstat의 BGPlay
BGP 좀비 측정 방법을 계속 개선할 예정이므로 향후 더 많은 인사이트를 기대하셔도 좋습니다. 또한 좀비 측정과 관련하여 커뮤니티 구성원이 흥미롭고 유용한 데이터를 제공한 연구 결과가 있습니다. BGP 좀비 생성과 관련된 소프트웨어 버그와 싸우는 측면에서 라우팅 벤더는 BGP SendHoldTimer인 RFC9687을 구현해야 합니다. 일반적인 아이디어는 상대방 라우터가 예기치 않게 BGP 메시지 처리를 중단하면 로컬 라우터가 SendHoldTimer를 통해 이를 감지하여 좀비가 장시간 정체될 가능성을 낮추는 것입니다.
또한, 보다 구체적인 접두사 알림 및 과도한 경로 사냥에 대해 이 게시물에서 관찰한 사실을 염두에 둘 필요가 있습니다. 네트워크 운영자가 장애 조치 또는 트래픽 엔지니어링을 위해 보다 구체적인 BGP 접두사 알림에 의존하는 경우 완전한 BGP 통합이 이루어지기 전에 오랜 시간 동안 경로가 정체될 수 있다는 점에 유의해야 합니다.
BGP 좀비와 같은 문제에 관심이 있다면 Cloudflare에 와서 일하거나 인턴십에 지원하는 것을 고려해 보세요. Cloudflare는 함께 더 나은 인터넷 구축을 지원할 수 있습니다!