Azure 허브 및 스포크 네트워크 토폴로지와 SDWAN 통합

Azure ExpressRoute
Azure VPN Gateway
Azure Virtual Network

이 문서는 온-프레미스 시설을 서로 Azure와 연결하도록 SD-WAN(소프트웨어 정의 광역 네트워크)을 설계하려는 네트워크 설계자를 위한 것입니다. Azure 고객이 Microsoft 백본 위에 효율적이고 글로벌 SD-WAN 오버레이를 구축하여 플랫폼에 대한 기존 투자를 사용할 수 있는 아키텍처를 설명합니다.

적용 가능한 시나리오

이 문서의 권장 사항은 공급업체에 구애받지 않으며 다음 두 가지 기본 필수 조건을 충족하는 비 Microsoft SD-WAN 기술에 적용할 수 있습니다.

  • TCP(Transmission Control Protocol) 또는 UDP(사용자 데이터그램 프로토콜)를 기본 전송으로 사용하는 터널링 프로토콜(예: NAT 순회를 사용하는 터널 모드 IPSec ESP)에 의존합니다.
  • 외부 엔터티와의 경로 교환에 대한 BGP(Border Gateway Protocol) v4 지원. 타사 SD-WAN 디바이스에서 서로 라우팅 정보를 교환하는 데 사용하는 라우팅 프로토콜에 대한 가정은 없습니다.

이러한 권장 사항을 준수하는 고객은 선택한 SD-WAN 기술을 사용하여 다음 목표를 달성할 수 있습니다.

  • Azure Virtual Network와 SD-WAN 디바이스 간의 경로 교환을 자동화하여 기존 Azure 허브 및 스포크 네트워크에 SD-WAN 제품을 통합합니다.
  • 로컬 인터넷 중단이 있는 분기의 연결(Azure 및 온-프레미스 데이터 센터 모두)을 최적화합니다. Microsoft 백본의 도달 범위는 용량, 복원력 및 "콜드 포테이토" 라우팅 정책과 결합되어 글로벌 SD-WAN의 고성능 언더레이로 사용될 수 있음을 시사합니다.
  • 모든 Azure 간 트래픽(지역 간 및 지역 간)에 Microsoft 백본을 사용합니다.
  • 기존 MPLS(다중 프로토콜 레이블 전환) 네트워크를 고성능 언더레이로 사용합니다. 비즈니스에 미치는 영향을 최소화하는 단계적 접근 방식에서 기존 MPLS 네트워크를 대체하는 데 사용할 수도 있습니다.

다음 섹션에서는 판독기에서 SD-WAN 패러다임의 기본 사항과 Microsoft 백본의 아키텍처를 잘 알고 있다고 가정합니다. Microsoft 백본은 Azure 지역을 서로 및 공용 인터넷과 상호 연결합니다.

아키텍처

글로벌 현재 상태 및 다중 지역 Azure 공간이 있는 조직은 일반적으로 연결 서비스의 조합을 사용하여 회사 네트워크를 구현하고 Microsoft 백본에 연결합니다.

  • MPLS IPVPN(Internet-Protocol-Virtual-Private-Networks)과 같은 전용 연결 서비스는 데이터 센터 또는 본사와 같은 가장 큰 사이트에서 사용할 수 있습니다.
  • 대규모 사이트에는 지원되는 연결 모델 중 하나를 사용하여 ExpressRoute 회로를 통해 Microsoft 백본에 대한 전용 연결이 포함될 수 있습니다. 더 구체적으로, 사이트는 전용 지점 및 지점간 회로를 사용하여 가장 가까운 ExpressRoute 피어링 위치에 연결할 수 있습니다. 또는 MPLS 캐리어에서 제공하는 ExpressRoute 회로에 액세스하기 위해 MPLS IPVPN을 적용할 수 있습니다.
  • 인터넷 연결만 있는 지사는 IPSec VPN을 사용하여 가장 가까운 온-프레미스 데이터 센터에 연결하고 해당 데이터 센터의 ExpressRoute 연결을 사용하여 Azure 리소스에 액세스할 수 있습니다. 또는 IPSec VPN을 사용하여 Azure 허브 및 스포크 네트워크에 직접 연결할 수 있습니다.

SD-WAN 프로젝트는 대체하려는 기존 네트워크 서비스 측면에서 서로 다른 범위를 가질 수 있습니다. 일부 조직에서는 대규모 시설에 대한 전용 링크 또는 MPLS를 고수하고 SD-WAN을 배포하여 소규모 사이트의 레거시 인터넷 기반 IPSec VPN을 대체할 수 있습니다. 다른 조직에서는 SD-WAN을 MPLS 연결 사이트로 확장하고 기존 MPLS 네트워크를 고성능 언더레이로 사용할 수 있습니다. 마지막으로 일부 조직에서는 MPLS IPVPN을 해제하려고 할 수 있습니다. 또는 SD-WAN 패러다임을 수용하기 위한 모든 전용 연결 서비스입니다. 이러한 방식으로 전체 회사 네트워크를 공용 또는 공유 언더레이(공용 인터넷 및 Microsoft 백본)를 기반으로 논리적 오버레이로 빌드할 수 있습니다.

이 문서에 설명된 아키텍처는 이전에 나열된 모든 범위를 지원하며 다음 원칙을 기반으로 합니다.

  • SD-WAN 디바이스는 각 Azure 지역의 허브 및 스포크 네트워크에서 NVA(네트워크 가상 어플라이언스)로 배포되고 온-프레미스 사이트에서 터널을 종료하는 SD-WAN 허브로 구성됩니다.
  • Azure의 SD-WAN 디바이스는 서로 터널을 설정하도록 구성되므로 Azure 지역 간에 트래픽을 효율적으로 전송하고 Microsoft 백본 위에 지리적으로 먼 온-프레미스 사이트 간에 트래픽을 릴레이할 수 있는 완전히 메시된 허브 간 오버레이를 만듭니다.
  • SD-WAN 디바이스는 SD-WAN 솔루션에서 다루는 모든 온-프레미스 사이트에 배포되고 가장 가까운 Azure 지역의 SD-WAN NVA에 대한 터널을 설정하도록 구성됩니다. 다른 사이트에서는 공용 인터넷, ExpressRoute 연결 등과 같은 터널의 언더레이로 다양한 전송 서비스를 사용할 수 있습니다.
  • Azure 또는 다른 온-프레미스 사이트에서 사이트 간 트래픽은 가장 가까운 Azure 지역의 SD-WAN NVA로 라우팅됩니다. 그런 다음 허브-허브 오버레이를 통해 라우팅됩니다.

SD-WAN 제품은 독점 프로토콜 및 기능을 사용하여 동적으로 설정되면 두 사이트 간의 직접 터널을 감지하여 Azure의 SD-WAN NVA를 통해 트래픽을 릴레이하는 것보다 더 나은 성능을 제공할 수 있습니다.

다음 그림에서는 Microsoft 백본, 공용 인터넷 및 전용 ER 연결을 언더레이로 사용하는 글로벌 SD-WAN의 고급 아키텍처를 보여 줍니다.

상위 수준 SD-WAN 아키텍처를 보여 주는 다이어그램그림 1: Microsoft 백본, 공용 인터넷 및 전용 ER 연결을 언더레이로 사용하는 글로벌 SD-WAN의 고급 아키텍처입니다. 검은색 파선은 사이트와 지리적으로 가까운 Azure 지역에 배포된 SD-WAN NVA를 통해 두 온-프레미스 사이트 간의 트래픽을 라우팅하는 방법을 보여 줍니다. Microsoft 백본은 도달 범위, 용량 및 "콜드 포테이토" 라우팅 정책으로 인해 특히 장거리 연결의 경우 공용 인터넷보다 훨씬 더 나은/예측 가능한 성능으로 이어질 수 있습니다.

Azure 허브 및 스포크 네트워크의 SD-WAN 제품

이 섹션에서는 기존 허브 및 스포크 Azure 네트워크에서 타사 SD-WAN CPE 디바이스를 NVA로 배포하기 위한 권장 사항을 제공합니다.

허브 가상 네트워크의 SD-WAN NVA

허브 및 스포크는 고객 관리형 가상 네트워크를 사용하여 Azure 지역에서 확장 가능한 네트워크를 구축하기 위해 Microsoft에서 권장하는 토폴로지입니다. 허브 가상 네트워크는 사이트 2 사이트 VPN 또는 ExpressRoute를 통해 방화벽, 부하 분산 및 온-프레미스 사이트에 대한 연결과 같은 네트워크 기능을 제공하는 비 Microsoft NVA 및 네이티브 서비스와 같은 공유 구성 요소를 호스트합니다. 허브 가상 네트워크는 SD-WAN NVA의 자연스러운 위치이며, 궁극적으로 원격 네트워크에 대한 액세스를 제공하는 비 Microsoft 게이트웨이입니다.

SD-WAN NVA는 다음과 같이 허브 가상 네트워크에 배포해야 합니다.

  • 단일 NIC(네트워크 인터페이스 컨트롤러)는 모든 SD-WAN 트래픽에 사용됩니다. 관리 NIC와 같은 다른 NIC는 보안 및 규정 준수 요구 사항을 충족하거나 Azure 배포에 대한 공급업체 지침을 준수하기 위해 추가할 수 있습니다.
  • SD-WAN 트래픽에 사용되는 NIC는 전용 서브넷에 연결되어야 합니다. 서브넷의 크기는 이 문서의 뒷부분에서 설명한 HA(고가용성) 및 크기 조정 또는 처리량 요구 사항을 충족하기 위해 배포된 SD-WAN NVA의 수에 따라 정의되어야 합니다.
  • NSG(네트워크 보안 그룹)는 직접 또는 서브넷 수준에서 SD-WAN 트래픽 NIC에 연결되어야 합니다. 이 연결을 사용하면 SD-WAN 솔루션에서 사용하는 TCP/UDP 포트를 통해 원격 온-프레미스 사이트에서 연결할 수 있습니다.
  • SD-WAN 트래픽에 사용되는 NIC에서 IP 전달을 사용하도록 설정해야 합니다.

허브 가상 네트워크의 Azure Route Server

Azure Route Server는 SD-WAN NVA와 Azure SDN(소프트웨어 정의 네트워킹) 스택 간의 경로 교환을 자동화합니다. Route Server는 BGP를 동적 라우팅 프로토콜로 지원합니다. Route Server와 SD-WAN NVA 간에 BGP 인접성을 설정하여 다음을 실행합니다.

  • SD-WAN에 연결된 모든 온-프레미스 사이트의 경로는 가상 네트워크의 경로 테이블에 삽입되고 모든 Azure VM에서 학습됩니다.
  • 가상 네트워크의 주소 공간에 포함된 모든 IP 접두사에 대한 경로는 모든 SD WAN 연결 사이트로 전파됩니다.

경로 서버는 다음과 같이 구성해야 합니다.

  • Azure Portal을 사용하여 경로 서버 만들기 및 구성에 따라 허브 가상 네트워크의 전용 서브넷에 배포해야 합니다.
  • 모든 스포크 가상 네트워크에 대해 자동화된 경로 교환을 사용하도록 설정하려면 스포크 가상 네트워크가 허브 가상 네트워크의 게이트웨이 및 경로 서버를 사용할 수 있도록 가상 네트워크 피어링을 구성해야 합니다. Azure Route Server FAQ에서 사용할 수 있는 세부 정보입니다.
  • 경로 서버와 SD-WAN NVA가 서로 다른 서브넷에 연결되어 있으므로 Route Server와 SD-WAN NVA 간의 BGP 세션은 eBGP 멀티호프 지원을 사용하여 구성해야 합니다. SD-WAN NVA에서 지원하는 최대 2~홉 수를 설정할 수 있습니다. 경로 서버에 대한 BGP 인접 구성에 대한 자세한 내용은 Azure Portal을 사용하여 경로 서버 만들기 및 구성에서 확인할 수 있습니다.
  • 경로 서버에서 노출하는 BGP 엔드포인트에 대해 SD-WAN NVA에서 두 개의 /32 정적 경로를 구성해야 합니다. 이 구성을 통해 NVA의 경로 테이블에는 멀티홉(직접 연결되지 않은) BGP 피어에 대한 경로가 항상 포함됩니다.

경로 서버가 데이터 경로에 없습니다. 컨트롤 플레인 엔터티입니다. SD-WAN NVA와 가상 네트워크 SDN 스택 간에 경로를 전파하지만, 다음 그림과 같이 SD-WAN NVA와 가상 네트워크의 가상 머신 간에 전달되는 실제 트래픽은 Azure SDN 스택에서 수행됩니다. 이 라우팅 동작을 얻기 위해 Route Server는 SD-WAN NVA에서 학습한 모든 경로를 NVA의 자체 주소로 설정한 다음 홉과 함께 삽입합니다.

경로 서버는 현재 IPv6을 지원하지 않습니다. 이 아키텍처는 IPv4 전용입니다.

Route Server의 작동 방식을 보여 주는 다이어그램그림 2. Route Server는 SD-WAN CPE와 가상 네트워크 SDN 스택 간의 경로 전파를 지원하지만, SD-WAN CPE와 가상 네트워크의 가상 머신 간에 트래픽을 전달하지는 않습니다.

Route Server를 사용하여 SD-WAN NVA에 대한 고가용성

경로 서버에는 기본 제공 HA가 있습니다. 두 개의 컴퓨팅 노드가 Route Server의 단일 인스턴스를 백업합니다. 서로 다른 가용성 영역, 가용성 영역 지원이 있는 지역 또는 동일한 가용성 집합에 배포됩니다. 두 개의 BGP 엔드포인트를 노출합니다. SD-WAN NVA의 HA는 여러 가용성 영역, 지원되는 지역 또는 동일한 가용성 집합에 여러 인스턴스를 배포하여 달성됩니다. 각 SD-WAN NVA는 Route Server에서 노출하는 두 엔드포인트를 사용하여 두 개의 BGP 세션을 설정합니다.

이 문서에 설명된 아키텍처는 Azure Load Balancer를 사용하지 않습니다. 즉,

  • 공용 부하 분산 장치는 SD-WAN 터널 엔드포인트를 노출하지 않습니다. 각 SD-WAN NVA는 자체 터널 엔드포인트를 노출합니다. 원격 피어는 Azure의 각 SD-WAN NVA에 대해 하나씩 여러 터널을 설정합니다.

  • 내부 부하 분산 장치는 Azure VM에서 시작된 트래픽을 SD-WAN NVA에 분산하지 않습니다. 경로 서버 및 Azure SDN 스택은 ECMP(동일 비용 다중 경로) 라우팅을 지원합니다. 여러 NVA가 경로 서버와 인접한 BGP를 설정하고 동일한 수준의 기본 설정을 사용하여 동일한 대상(있는 경우, SD-WAN에 연결된 원격 네트워크 및 사이트)에 대한 경로를 알리는 경우 경로 서버:

    • 가상 네트워크의 경로 테이블에 해당 대상에 대한 여러 경로를 삽입합니다.
    • 다른 NVA를 다음 홉으로 사용하도록 각 경로를 설정합니다.

그런 다음 SDN 스택은 사용 가능한 모든 다음 홉에서 해당 대상으로 트래픽을 분산합니다.

결과 HA 아키텍처는 다음 그림에 나와 있습니다.

Route Server 고가용성을 보여 주는 다이어그램그림 3. Route Server는 ECMP(동일 비용 다중 경로) 라우팅을 지원합니다. 가용성 및/또는 확장성을 위해 여러 SD-WAN NVA를 사용하는 경우 Azure Load Balancer가 필요하지 않습니다.

N-활성 및 활성 대기 고가용성

여러 SD-WAN NVA를 사용하고 경로 서버와 피어링하는 경우 BGP는 장애 조치(failover)를 구동합니다. SD-WAN NVA가 오프라인 상태가 되면 경로 서버에 대한 경로 보급을 중지합니다. 실패한 디바이스에서 학습된 경로는 가상 네트워크의 경로 테이블에서 철회됩니다. 따라서 SD-WAN NVA가 디바이스 자체 또는 언더레이에서 오류로 인해 원격 SD-WAN 사이트에 더 이상 연결을 제공하지 않는 경우 더 이상 가상 네트워크의 경로 테이블의 원격 사이트에 대한 가능한 다음 홉으로 표시되지 않습니다. 모든 트래픽이 정상 디바이스를 다시 기본 이동합니다. SD-WAN NVA와 Route Server 간의 경로 전파에 대한 자세한 내용은 BGP 피어에서 Route Server로 보급된 경로를 참조하세요.

경로 서버 BGP 기반 장애 조치(failover)를 보여 주는 다이어그램.그림 4. BGP 기반 장애 조치(failover). SD-WAN NVA #0이 오프라인 상태가 되면 Route Server가 있는 해당 BGP 세션이 닫힙니다. SD-WAN NVA #0은 Azure에서 온-프레미스 사이트로 가는 트래픽에 대해 가능한 다음 홉으로 가상 네트워크의 경로 테이블에서 제거됩니다.

BGP 기반 장애 조치(failover) 및 ECMP 라우팅은 N 디바이스가 동시에 트래픽을 처리하는 N-활성 HA 아키텍처를 자연스럽게 사용하도록 설정합니다. 그러나 BGP를 사용하여 활성 및 수동 HA 아키텍처를 구현할 수도 있습니다. 수동 디바이스를 구성하여 경로 서버에 활성 피어보다 낮은 수준의 기본 설정으로 경로를 알릴 수 있습니다. 경로 서버는 활성 디바이스에서 수신하는 경우 수동 디바이스에서 수신한 경로를 카드 더 높은 수준의 기본 설정으로 동일한 대상에 대한 경로를 해제합니다. 또한 가상 네트워크의 경로 테이블에서 후자의 경로만 배관합니다.

활성 디바이스가 일부 경로에 실패하거나 철회되면 경로 서버:

  • 수동 디바이스에서 발표한 해당 경로를 선택합니다.
  • 가상 네트워크의 경로 테이블에 경로를 연결합니다.

SD-WAN NVA가 경로 서버에 알리는 경로에 대한 기본 설정을 표현하는 데 사용할 수 있는 유일한 BGP 특성은 AS Path입니다.

N-Active HA 아키텍처는 최적의 리소스 사용(독립 실행형 SD-WAN NVA 없음) 및 수평 확장성을 사용하도록 설정하기 때문에 권장됩니다. 처리량을 늘리기 위해 여러 NVA를 경로 서버에서 지원하는 최대 BGP 피어 수까지 병렬로 실행할 수 있습니다. 자세한 내용은 BGP 피어를 참조 하세요. 그러나 N-활성 HA 모델을 사용하려면 SD-WAN NVA가 상태 비저장 계층 3 라우터 역할을 해야 합니다. 사이트에 대한 여러 터널이 있는 경우 TCP 연결을 비대칭으로 라우팅할 수 있습니다. 즉, 동일한 TCP 연결의 ORIGINALREPLY 흐름은 서로 다른 터널 및 다른 NVA를 통해 라우팅될 수 있습니다. 다음 그림에서는 비대칭으로 라우팅된 TCP 연결의 예를 보여 줍니다. 이러한 라우팅 비대칭은 가상 네트워크 또는 온-프레미스 사이트에서 시작된 TCP 연결에 대해 가능합니다.

활성/활성 구성의 비대칭 라우팅을 보여 주는 다이어그램그림 5. 활성/활성 HA 아키텍처의 비대칭 라우팅입니다. SD-WAN NVA #0 및 SD-WAN NVA #1은 경로 서버에 대한 경로 길이가 동일한 대상 192.168.1.0/24(원격 SD-WAN 사이트)에 대해 동일한 경로를 발표합니다. 원래 흐름(SD-WAN 원격 사이트에서 Azure로, 빨간색 경로)은 SD-WAN NVA #1에 의해 Azure 쪽에서 종료된 터널을 통해 라우팅됩니다. 온-프레미스 SD-WAN CPE가 이 터널을 선택합니다. Azure SDN 스택은 가상 네트워크의 경로 테이블에 따라 REPLY 흐름(Azure에서 원격 SD-WAN 사이트, 녹색 경로)을 192.168.1.0/24에 대한 가능한 다음 홉 중 하나인 SD-WAN NVA #0으로 라우팅합니다. Azure SDN 스택에서 선택한 다음 홉이 원래 흐름을 받은 SD-WAN CPE와 항상 동일하다는 보장은 불가능합니다.

활성 및 수동 HA 아키텍처는 Azure의 SD-WAN NVA가 상태 저장 방화벽과 같은 라우팅 대칭이 필요한 다른 네트워크 기능을 수행하는 경우에만 고려해야 합니다. 확장성에 미치는 영향 때문에 이 방법은 권장하지 않습니다. SD-WAN NVA에서 더 많은 네트워크 함수를 실행하면 리소스 사용량이 증가합니다. 동시에 활성 및 수동 HA 아키텍처를 사용하면 언제든지 하나의 NVA 처리 트래픽을 가질 수 있습니다. 즉, 전체 SD-WAN 계층은 확장되지 않고 지원하는 최대 Azure VM 크기로만 확장할 수 있습니다. n-활성 HA에 대한 표준 Load Balancer 사용하는 별도의 NVA 클러스터에서 라우팅 대칭이 필요한 상태 저장 네트워크 함수를 실행합니다.

ExpressRoute 연결 고려 사항

이 문서에 설명된 아키텍처를 통해 고객은 SD-WAN 패러다임을 완전히 수용하고 공용 인터넷 및 Microsoft 백본을 기반으로 논리적 오버레이로 회사 네트워크를 구축할 수 있습니다. 또한 나중에 설명한 특정 시나리오를 해결하기 위해 전용 Expressroute 회로를 사용할 수도 있습니다.

시나리오 #1: ExpressRoute 및 SD-WAN 공존

SD-WAN 솔루션은 SD-WAN 디바이스가 사이트의 하위 집합에만 배포될 때 ExpressRoute 연결과 공존할 수 있습니다. 예를 들어 일부 조직에서는 인터넷 연결만 있는 사이트에서 기존 IPSec VPN을 대체하는 SD-WAN 솔루션을 배포할 수 있습니다. 그런 다음, 다음 그림과 같이 대규모 사이트 및 데이터 센터에 MPLS 서비스 및 ExpressRoute 회로를 사용합니다.

SD-WAN 및 ExpressRoute 공존을 보여 주는 다이어그램그림 6. SD-WAN CPE 디바이스가 사이트의 하위 집합에만 배포될 때 SD-WAN 솔루션은 ExpressRoute 연결과 공존할 수 있습니다.

이 공존 시나리오에서는 SD-WAN에 연결된 사이트와 ExpressRoute 회로에 연결된 사이트 간에 트래픽을 라우팅할 수 있도록 Azure에 배포된 SD-WAN NVA가 필요합니다. 여기에 설명된 대로 Azure에서 ExpressRoute 가상 네트워크 게이트웨이와 SD-WAN NVA 간에 경로를 전파하도록 AllowBranchToBranch 경로 서버를 구성할 수 있습니다. ExpressRoute 가상 네트워크 게이트웨이와 SD-WAN NVA 간의 경로 전파는 BGP를 통해 발생합니다. Route Server는 둘 다로 BGP 세션을 설정하고 서로 학습된 경로를 각 피어에 전파합니다. 플랫폼은 Route Server와 ExpressRoute 가상 네트워크 게이트웨이 간의 BGP 세션을 관리합니다. 사용자는 명시적으로 구성할 필요가 없지만 경로 서버를 배포할 때만 플래그를 사용하도록 설정합니다 AllowBranchToBranch .

Route Server가 AllowBranchToBranch=TRUE로 구성된 경우의 경로 전파를 보여 주는 다이어그램그림 7. ExpressRoute 가상 네트워크 게이트웨이와 SD-WAN NVA 간의 경로 전파는 BGP를 통해 발생합니다. Route Server는 "AllowBranchToBranch=TRUE"로 구성된 경우 둘 다로 BGP 세션을 설정하고 양방향으로 경로를 전파합니다. 경로 서버는 경로 리플렉터 역할을 합니다. 즉, 데이터 경로의 일부가 아닙니다.

이 SD-WAN 및 ExpressRoute 공존 시나리오를 사용하면 MPLS 네트워크에서 SD-WAN으로 마이그레이션할 수 있습니다. 레거시 MPLS 사이트와 새로 마이그레이션된 SD-WAN 사이트 간에 경로를 제공하여 온-프레미스 데이터 센터를 통해 트래픽을 라우팅할 필요가 없습니다. 이 패턴은 마이그레이션 중뿐만 아니라 회사 합병 및 인수로 인해 발생하는 시나리오에서도 사용할 수 있으며 서로 다른 네트워크의 원활한 상호 연결을 제공합니다.

시나리오 #2: SD-WAN 언더레이로서의 Expressroute

온-프레미스 사이트에 ExpressRoute 연결이 있는 경우 ExpressRoute 회로 또는 회로를 기반으로 Azure에서 실행되는 SD-WAN 허브 NVA에 대한 터널을 설정하도록 SD-WAN 디바이스를 구성할 수 있습니다. ExpressRoute 연결은 지점 간 회로 또는 MPLS 네트워크를 통해 수행할 수 있습니다. ExpressRoute 프라이빗 피어링과 Microsoft 피어링을 모두 사용할 수 있습니다.

비공개 피어링

ExpressRoute 프라이빗 피어링을 언더레이로 사용하는 경우 모든 온-프레미스 SD-WAN 사이트는 Azure의 SD-WAN 허브 NVA에 대한 터널을 설정합니다. 이 시나리오에서는 SD-WAN NVA와 ExpressRoute 가상 네트워크 게이트웨이 간의 경로 전파가 필요하지 않습니다(즉, 경로 서버는 "AllowBranchToBranch" 플래그를 false로 설정하여 구성해야 함).

이 방법을 사용하려면 ExpressRoute 연결을 종료하는 고객 또는 공급자 쪽 라우터에 적절한 BGP 구성이 필요합니다. 실제로 MSE(Microsoft Enterprise Edge 라우터)는 회로에 연결된 가상 네트워크에 대한 모든 경로를 발표합니다(직접 또는 가상 네트워크 피어링을 통해). 그러나 SD-WAN 터널을 통해 가상 네트워크로 향하는 트래픽을 전달하기 위해 온-프레미스 사이트는 ER 회로가 아닌 SD-WAN 디바이스에서 해당 경로를 학습해야 합니다.

따라서 ExpressRoute 연결을 종료하는 고객 쪽 또는 공급자 쪽 라우터는 Azure에서 받은 경로를 필터링해야 합니다. 언더레이에 구성된 유일한 경로는 온-프레미스 SD-WAN 디바이스가 Azure의 SD-WAN 허브 NVA에 연결할 수 있도록 하는 경로여야 합니다. ExpressRoute 프라이빗 피어링을 SD-WAN 언더레이로 사용하려는 고객은 그에 따라 라우팅 디바이스를 구성할 수 있는지 확인해야 합니다. 이렇게 하는 것은 ExpressRoute에 대한 에지 디바이스를 직접 제어할 수 없는 고객에게 특히 관련이 있습니다. 예를 들어 ExpressRoute 회로가 IPVPN 서비스 위에 있는 MPLS 통신 사업자에 의해 제공되는 경우입니다.

expressRoute 프라이빗 피어링을 SD-WAN 언더레이로 보여 주는 다이어그램그림 8. SD-WAN 언더레이로서의 ExpressRoute 프라이빗 피어링. 이 시나리오에서 고객 및 공급자 쪽 라우터는 ER 프라이빗 피어링 BGP 세션 및 SD-WAN CPE에서 ExpressRoute 연결을 종료하는 가상 네트워크에 대한 경로를 받습니다. SD-WAN CPE만 Azure 경로를 사이트의 LAN으로 전파해야 합니다.

Microsoft 피어링

ExpressRoute Microsoft 피어링을 SD-WAN 터널의 언더레이로 사용할 수도 있습니다. 이 시나리오에서 Azure의 SD-WAN 허브 NVA는 공용 터널 엔드포인트만 노출합니다. 이 엔드포인트는 인터넷에 연결된 사이트의 SD-WAN CPI(있는 경우)와 Expressroute 연결 사이트의 SD-WAN CPI에서 모두 사용됩니다. ExpressRoute Microsoft 피어링에는 프라이빗 피어링보다 더 복잡한 필수 구성 요소가 있지만 다음 두 가지 장점 때문에 이 옵션을 언더레이로 사용하는 것이 좋습니다.

  • 허브 가상 네트워크에 Expressroute 가상 네트워크 게이트웨이가 필요하지 않습니다. ExpressRoute FastPath를 사용하지 않을 때 복잡성을 제거하고 비용을 절감하며 SD-WAN 솔루션이 게이트웨이 자체의 대역폭 제한을 초과하여 확장할 수 있습니다.

  • 오버레이 경로와 언더레이 경로 간의 클린 구분을 제공합니다. MSE는 Microsoft 네트워크의 공용 접두사만 고객 또는 공급자 에지에 발표합니다. 이러한 경로를 별도의 VRF에서 관리하고 사이트 LAN의 DMZ 세그먼트로만 전파할 수 있습니다. SD-WAN 디바이스는 가상 네트워크에 대한 경로를 포함하여 오버레이에서 고객의 회사 네트워크에 대한 경로를 전파합니다. 이 방법을 고려하는 고객은 그에 따라 라우팅 디바이스를 구성하거나 MPLS 이동 통신 사업자에게 적절한 서비스를 요청할 수 있는지 확인해야 합니다.

MPLS 고려 사항

기존 MPLS 회사 네트워크에서 SD-WAN 패러다임을 기반으로 하는 최신 네트워크 아키텍처로 마이그레이션하려면 상당한 노력과 상당한 시간이 필요합니다. 이 문서에 설명된 아키텍처를 통해 단계적 SD-WAN 마이그레이션을 수행할 수 있습니다. 두 가지 일반적인 마이그레이션 시나리오는 나중에 설명합니다.

단계적 MPLS 서비스 해제

공용 인터넷 및 Microsoft 백본을 기반으로 SD-WAN을 빌드하고 MPLS IPVPN 또는 기타 전용 연결 서비스를 완전히 해제하려는 고객은 마이그레이션 중 이전 섹션에서 설명한 ExpressRoute 및 SD-WAN 공존 시나리오를 사용할 수 있습니다. 이를 통해 SD-WAN 연결 사이트는 여전히 레거시 MPLS에 연결된 사이트에 연결할 수 있습니다. 사이트가 SD-WAN으로 마이그레이션되고 CPE 디바이스가 배포되는 즉시 해당 MPLS 링크를 서비스 해제할 수 있습니다. 사이트는 가장 가까운 Azure 지역에 대한 SD-WAN 터널을 통해 전체 회사 네트워크에 액세스할 수 있습니다.

MPLS 서비스 해제 아키텍처를 보여 주는 다이어그램그림 9. "ExpressRoute 및 SD-WAN 공존" 시나리오를 사용하면 단계적 MPLS 서비스 해제가 가능합니다.

모든 사이트가 마이그레이션되면 MPLS IPVPN을 Microsoft 백본에 연결하는 ExpressRoute 회로와 함께 서비스 해제할 수 있습니다. ExpressRoute 가상 네트워크 게이트웨이는 더 이상 필요하지 않으며 프로비전을 해제할 수 있습니다. 각 지역의 SD-WAN 허브 NVA는 해당 지역의 허브 및 스포크 네트워크에 대한 유일한 진입점이 됩니다.

MPLS 통합

원하는 성능과 안정성을 제공하기 위해 공용 및 공유 네트워크를 신뢰하지 않는 조직은 기존 MPLS 네트워크를 엔터프라이즈급 언더레이로 사용하기로 결정할 수 있습니다. 두 가지 옵션은 다음과 같습니다.

  • 데이터 센터 또는 대규모 지사와 같은 사이트의 하위 집합입니다.
  • 일반적으로 대기 시간이 중요하거나 중요 업무용 트래픽인 연결의 하위 집합입니다.

앞에서 설명한 SD-WAN 언더레이로서의 Expressroute 시나리오는 SD-WAN 및 MPLS 통합을 가능하게 합니다. 이전에 설명한 이유로 프라이빗 피어링보다 ExpressRoute Microsoft 피어링을 선호해야 합니다. 또한 Microsoft 피어링을 사용하면 MPLS 네트워크와 공용 인터넷이 기능적으로 동등한 언더레이가 됩니다. Azure의 SD-WAN 허브 NVA에서 노출하는 모든 SD-WAN 터널 엔드포인트에 대한 액세스를 제공합니다. 인터넷 및 MPLS 연결이 모두 있는 사이트에 배포된 SD-WAN CPE는 두 언더레이 모두에서 Azure의 SD-WAN 허브에 여러 터널을 설정할 수 있습니다. 그런 다음 SD-WAN 컨트롤 플레인에서 관리하는 애플리케이션 수준 정책에 따라 서로 다른 터널을 통해 서로 다른 연결을 라우팅할 수 있습니다.

MPLS 통합 아키텍처를 보여 주는 다이어그램그림 10. "SD-WAN 언더레이로서의 ExpressRoute" 시나리오를 통해 SD-WAN 및 MPLS를 통합할 수 있습니다.

경로 서버 라우팅 기본 설정

이전 두 섹션에서 다루는 두 MPLS 시나리오에서 일부 분기 사이트는 MPLS IPVPN 및 SD-WAN에 모두 연결할 수 있습니다. 결과적으로 허브 가상 네트워크에 배포된 Route Server 인스턴스는 ExpressRoute 게이트웨이 및 SD-WAN NVA에서 동일한 경로를 학습할 수 있습니다. 경로 서버 라우팅 기본 설정을 사용하면 가상 네트워크의 경로 테이블에 기본 설정 및 배관해야 하는 경로를 제어할 수 있습니다. 라우팅 기본 설정은 AS 경로 앞에 추가할 수 없는 경우에 유용합니다. 예를 들어 ExpressRoute 연결을 종료하는 PE에서 사용자 지정 BGP 구성을 지원하지 않는 MPLS IPVPN 서비스가 있습니다.

경로 서버 제한 및 디자인 고려 사항

경로 서버는 이 문서에 설명된 아키텍처의 초석입니다. 가상 네트워크에 배포된 SD-WAN NVA와 기본 Azure SDN 스택 간에 경로를 전파합니다. 고가용성 및 수평적 확장성을 위해 여러 SD-WAN NVA를 실행하는 BGP 기반 접근 방식을 제공합니다. 이 아키텍처 를 기반으로 대규모 SD-WAN을 디자인하는 경우 Route Server 의 확장성 제한을 고려해야 합니다.

다음 섹션에서는 확장성 최대값 및 각 제한을 처리하는 방법에 대한 지침을 제공합니다.

BGP 피어에서 Route Server로 보급된 경로

경로 서버는 플래그가 설정될 때 ExpressRoute Virtual Network 게이트웨이에 보급할 수 있는 경로 수에 AllowBranchToBranch 대한 명시적 제한을 정의하지 않습니다. 그러나 ExpressRoute 게이트웨이는 경로 서버에서 학습한 경로를 연결된 ExpressRoute 회로로 추가로 전파합니다.

Azure 구독 및 서비스 제한, 할당량 및 제약 조건에 문서화된 프라이빗 피어링을 통해 ExpressRoute 게이트웨이가 ExpressRoute 회로에 보급할 수 있는 경로 수에는 제한이 있습니다. 이 문서의 지침에 따라 SD-WAN 솔루션을 디자인하는 경우 SD-WAN 경로로 인해 이 제한에 도달하지 않도록 하는 것이 중요합니다. 적중되면 ExpressRoute 게이트웨이와 ExpressRoute 회로 간의 BGP 세션이 삭제되고 ExpressRoute를 통해 연결된 가상 네트워크와 원격 네트워크 간의 연결이 끊어집니다.

ExpressRoute 게이트웨이가 회로에 보급하는 총 경로 수는 Route Server에서 학습된 경로 수와 Azure 허브 및 스포크 네트워크의 주소 공간을 구성하는 접두사 수의 합계입니다. 삭제된 BGP 세션으로 인한 중단을 방지하려면 다음 완화를 구현하는 것이 좋습니다.

  • 기능을 사용할 수 있는 경우 네이티브 SD-WAN 디바이스의 기능을 사용하여 Route Server에 발표되는 경로 수를 제한합니다.
  • Azure Monitor 경고를 사용하여 ExpressRoute 게이트웨이에서 발표한 경로 수의 급증을 사전에 감지합니다. 모니터링할 메트릭의 이름은 ExpressRoute 모니터링설명된 대로 피어에 보급된 경로 수입니다.

BGP 피어

경로 서버는 최대 수의 BGP 피어를 사용하여 BGP 세션을 설정할 수 있습니다. 이 제한은 경로 서버와 인접한 BGP를 설정할 수 있는 SD-WAN NVA의 최대 수와 모든 SD-WAN 터널에서 지원될 수 있는 최대 집계 처리량을 결정합니다. 큰 SD-WAN만 이 제한에 도달할 것으로 예상됩니다. 이를 극복하기 위한 해결 방법은 여러 허브 및 스포크 네트워크를 만드는 것 외에, 각각 자체 게이트웨이 및 경로 서버를 사용하는 해결 방법이 없습니다.

참여하는 VM

Virtual Network 게이트웨이 및 경로 서버는 자체 가상 네트워크 및 직접 피어링된 가상 네트워크의 모든 VM에 대해 원격 피어에서 학습하는 경로를 구성합니다. VM에 대한 라우팅 업데이트로 인한 과도한 리소스 사용으로부터 Route Server를 보호하기 위해 Azure는 단일 허브 및 스포크 네트워크에 존재할 수 있는 VM 수에 대한 제한을 정의합니다. 동일한 지역에 자체 게이트웨이 및 경로 서버를 사용하는 여러 허브 및 스포크 네트워크를 만드는 것 외에는 이 제한을 극복할 수 있는 해결 방법이 없습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계