대규모 허브 앤 스포크 VPN 규모 산정: BGP를 고르기 전에 세어라
프리픽스는 쉬운 숫자다. 세션, 업데이트 폭주, 허브 장애 후 복구가 수천 개 지사에서 설계가 버티는지를 결정한다.
지사가 삼천 개라는 말은 라우팅 문제처럼 들리지만 실제로는 장부 문제처럼 움직인다. 프리픽스 합계는 십 분이면 계산되고, 아픈 숫자는 좀처럼 그것이 아니다. 아픈 것은 세션당 작업, 공유 구성 요소가 죽을 때의 업데이트 폭주, 그리고 포워딩이 새 토폴로지와 다시 맞을 때까지 걸리는 시간이다.
그러니 산수를 올바른 순서로 밟아라. 관계를 세고, 프리픽스와 대안 경로를 세고, 다음으로 나쁜 한 시간에 무슨 일이 벌어지는지 세고, 그다음에야 프로토콜과 플랫폼을 비교하라. 순서를 뒤집으면 이 작업은 경로 한계를 둘러싼 논쟁이 되고, 탁자 위의 정보로는 아무도 끝낼 수 없다.
예산은 넷, 하나가 아니다
각 예산은 서로 다른 질문에 답하고, 각각은 다른 플랫폼에서 병목이 될 수 있다. 따로 적으면 하나의 큰 프리픽스 숫자가 설계 전체를 대신하지 못한다.
| Budget | What you are really counting |
|---|---|
| Sessions | Peers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count |
| Prefixes | Alternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see |
| Churn | Updates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event |
| Recovery | Time to detect, reselect, reinstall and restore the application, measured end to end rather than per box |
마지막 두 개는 설계 검토에서 빠지기 쉽다. 정상 상태에서 메모리에 넉넉히 들어가는 네트워크도 사백 개 지사가 이 분 안에 다시 접속하면 나쁘게 동작할 수 있다. 작업이 제어 평면이 소화하는 속도보다 빨리 도착하기 때문이다. 폭주의 크기를 숫자로 적고, 서비스가 얼마나 오래 저하되어도 되는지도 함께 적어라. 그러면 막연한 걱정이 실제로 돌려 볼 수 있는 시험이 된다.
네 가지 모두에 플랫폼 질문이 숨어 있다. 암호화, 포워딩, 라우팅이 같은 CPU를 공유하는지, 아니면 별도 경로를 쓰는지다. 경로 용량이 같은 두 장비도 폭주 아래에서는 아주 다르게 동작할 수 있고, 데이터시트는 어느 쪽을 사는지 좀처럼 말해 주지 않는다.
자기 숫자로 산수를 하라
가상의 설계를 하나 잡아라. 지사 3,000개, 집계 전 지사마다 프리픽스 세 개, 이중화를 위해 지사마다 허브 두 개. 허브 쌍은 요약 전에 약 9,000개의 지사 프리픽스를 담아야 하고, 모든 지사가 두 허브 모두와 피어링하면 설계는 6,000개의 지사-허브 세션을 뜻한다.
이제 프리픽스가 아닌 부분을 더하라. 각 세션은 아무것도 변하지 않아도 상태와 주기적 메시지를 실어 나른다. 빠른 전환을 기대하면 각 허브는 프리픽스마다 경로를 하나 이상 둘 수 있어 대안 수가 선택 수를 넘을 수 있다. 그리고 각 스포크의 시야는 별도의 정책 결정이다. 모든 지사에 다른 모든 지사의 경로를 주면 허브 쪽 계산으로는 드러나지 않는 방식으로 작업이 배가된다.
이는 설계 대화를 위한 계획 숫자이지 어떤 제품의 측정값이 아니다. 이 작업의 쓸모 있는 산출물은 곡선의 모양이지, 특정 라우터가 어디서 항복하는지에 대한 주장이 아니다.
BGP가 주는 것과 IGP가 주는 것
BGP는 라우터가 받은 것, 고른 것, 광고하는 것을 분리하고, 각각은 정책으로 제어된다. 지사 네트워크에 꼭 필요한 것이 그것이다. 스포크는 보통 기본 경로와 중앙 서비스, 그리고 아주 조금만 보아야 한다. 최종 테이블만 세면 대안 경로와 광고가 가려지는데, 이중화를 더할 때 늘어나는 것이 바로 그 부분이다.
IGP가 자동으로 틀린 것은 아니다. 토폴로지, 영역 구조, 인접 모델이 서비스에 맞으면 링크 상태 프로토콜은 빠르게 수렴하고 정책 골격도 덜 필요하다. 함정은 BGP와 같은 이웃별 내보내기 제어를 표현할 수 있다고 가정하는 것이다. OSPF 영역은 플러딩 경계이지, 지사 하나에 걸 수 있는 필터가 아니다.
어느 쪽이든 가시성 모델을 먼저 정하라. 기본 경로, 중앙 서비스용 요약, 전체 지사 세부 정보는 서로 다른 세 가지 제품이고, 더 구체적인 장애를 감추는 요약은 장애 중에 발견할 것이 아니라 적어 두어야 할 설계 결정이다.
정상 상태가 아니라 폭주를 시험하라
실제로 예상하는 장애, 곧 허브 다운, 지역 WAN 사건, 사이트 절반을 한꺼번에 오프라인으로 만드는 유지보수 창을 중심으로 비교를 세워라. 지사의 관점에서 애플리케이션까지 포함해 복구 시간을 재되, 몇 초에 수렴하는 제어 평면도 세션 재설정에 몇 분이 걸리면 의미가 작다.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPF플랫폼이 쉬는 상태가 아니라 폭주 정점에서 무엇을 하는지 기록하고, 보안 기능을 켠 채로 반복하라. 조용한 테이블만 보여 주는 개념 증명은 메모리 시험이고, 메모리는 한 번도 흥미로운 숫자가 아니었다.