Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지 내용
 

레이어 2 Data Center Interconnect를 위한 VXLAN 연결 구성

이 문서에서는 게이트웨이 디바이스에서 VXLAN 연계를 사용하여 DCI(Data Center Interconnect)를 구현하기 위한 구성 및 검증 단계에 대해 설명합니다. VXLAN 연결 기능을 사용하면 특정 VXLAN 가상 네트워크 식별자(VNI)를 함께 연결하여 DC 간에 레이어 2 스트레치를 세부적으로 제공할 수 있습니다.

주니퍼 네트웍스의 스위칭 및 라우팅 장치는 다양한 DCI 옵션을 지원합니다. 예를 들어, OTT(Over the Top) DCI를 사용하여 POD 간의 오버레이를 확장할 수 있습니다. 자세한 내용은 OTT DCI 를 참조하십시오. OTT 방법의 한 가지 단점은 레이어 2 또는 레이어 3에서 POD 간에 모든 VLAN을 확장한다는 것입니다. 또한 OTT DCI는 엔드투엔드 VXLAN VNI의 중요성을 필요로 합니다. 이는 VNI에 대한 VLAN 간 중복 할당이 없는 두 개의 DC/POD를 병합하는 경우 문제가 될 수 있습니다.

POD 간에 확장되는 VLAN을 보다 세밀하게 제어해야 하는 경우도 있습니다. Junos VXLAN 연결 기능을 사용하면 VNI 수준에서 DCI를 수행하여 VLAN별로 레이어 2 연결을 확장할 수 있습니다. 또는 동일한 VNI가 각 POD의 서로 다른 VLAN에 할당된 인스턴스를 수용하기 위해 VNI를 변환해야 할 수 있습니다. 예를 들어, VLAN 1에 POD 10001이 할당되고 POD 2에서 동일한 VLAN이 VNI 20002에 할당되는 경우를 가정해 보겠습니다. 이 경우 POD 중 하나를 재구성하여 VLAN을 VNI에 대한 전역(중첩) 매핑을 달성해야 합니다. 또는 번역 스티칭을 사용하여 로컬 POD VNI 값을 WAN을 통해 사용되는 VNI에 매핑할 수 있습니다.

주니퍼 네트웍스는 3단계 및 5단계 IP 패브릭 모두에 대해 VXLAN 스티칭을 지원합니다. 또한 CRB(Centrally-Routed Bridging) 오버레이, ERB(Edge-Routed Bridging) 오버레이 및 브리지 오버레이 아키텍처에 VXLAN 스티칭이 지원됩니다. 이 사용 사례에서는 EVPN-VXLAN POD 패브릭이 이미 표 1에 나와 있는 지원되는 아키텍처 중 하나 또는 그 조합을 사용하여 리프와 스파인으로 구성되어 있다고 가정합니다.

두 POD 간에 VXLAN 연결 연결을 활성화하려면 WAN 라우터 계층을 추가하여 언더레이를 확장해야 합니다. 언더레이 확장은 POD 간의 오버레이를 확장합니다. 그런 다음 POD 간에 원하는 VLAN(현재 VXLAN VNI로 표시)을 확장하도록 게이트웨이 디바이스에 VXLAN 연결을 구성합니다.

메모:

이 문서에서는 "WAN 라우터"라는 용어를 사용합니다. 그렇다고 해서 POD 간에 실제 WAN 네트워크가 있다는 의미는 아닙니다. WAN 라우터는 이 예에서와 같이 두 POD에 모두 로컬일 수 있습니다. 또한 POD가 지리적으로 멀리 떨어져 있을 때 확장된 WAN 네트워크를 통해 VXLAN 연결을 사용할 수도 있습니다.

그림 1 은 이 레퍼런스 설계에서 검증한 POD/DC 패브릭 유형을 보여주는 개략적인 다이어그램을 제공합니다.

그림 1: VXLAN 연계 레퍼런스 아키텍처 VXLAN Stitching Reference Architectures

그림 1에서 각 WAN 라우터는 두 POD의 각 게이트웨이 디바이스에 연결됩니다. 이러한 연결 및 관련 BGP 피어 세션은 두 POD 사이의 언더레이를 확장하는 역할을 합니다. 특히, 디바이스는 POD 간에 게이트웨이 디바이스의 루프백 주소를 보급합니다. 이 루프백 도달 가능성은 EBGP 기반 피어링 세션을 설정하여 두 Pod의 게이트웨이 디바이스 간에 오버레이를 확장합니다.

POD 1은 게이트웨이 기능이 스파인 디바이스로 축소된 3단계 CRB 아키텍처를 나타냅니다. 따라서 POD 1에서는 스파인 및 게이트웨이라는 용어가 각각 적용됩니다. 일반적으로 스파인 디바이스를 설명할 때 게이트웨이라는 용어를 사용합니다. 여기서는 게이트웨이 기능에 초점을 맞추기 때문입니다.

이에 반해 POD 2는 린 스파인과 개별 게이트웨이 디바이스를 사용하는 5단계 ERB 아키텍처입니다. POD 2의 게이트웨이 디바이스는 슈퍼 스파인 또는 경계 리프 디바이스라고도 합니다. 이 예에서는 VXLAN 연결 기능을 수행하므로 게이트웨이 디바이스라고 합니다.

표 1 에는 이 참조 설계의 일부로 검증한 POD 아키텍처가 요약되어 있습니다.

표 1: VXLAN 연계를 위해 지원되는 POD 아키텍처

포드 1

포드 2

에지 라우팅 브리징

에지 라우팅 브리징

중앙 라우팅 브리징

에지 라우팅 브리징

중앙 라우팅 브리징

중앙 라우팅 브리징

브리지 오버레이

브리지 오버레이

3단계 또는 5단계 패브릭

3단계 또는 5단계 패브릭

VXLAN 스티칭을 사용할 때 주의해야 할 다른 항목은 다음과 같습니다.

  • POD 1과 같이 스파인과 게이트웨이의 역할을 축소된 설계로 결합할 수 있습니다.

  • 스티칭된 VNI는 POD에 VNI 간 중복 VLAN 할당이 있는 경우 동일한 값(글로벌 스티칭)을 가지거나 두 POD 간에 변환될 수 있습니다. 후자의 기능은 VNI와 VLAN 할당이 겹치지 않는 POD(DC)를 병합할 때 유용합니다.

  • 당사는 기본 스위치 EVPN 인스턴스(EVI) 및 MAC-VRF 라우팅 인스턴스에서 VXLAN 연결을 지원합니다.

  • 유니캐스트 및 BUM 트래픽에 대해서만 레이어 2 스티칭을 지원합니다. BUM 트래픽의 경우 로컬 게이트웨이 ESI LAG에 대한 DF(지정 전달자)가 수신 복제를 수행하고 BUM 트래픽의 복사본을 각 원격 게이트웨이로 전달합니다. 원격 게이트웨이 디바이스에서 원격 ESI LAG에 대한 DF는 수신 복제를 수행하고 BUM 트래픽의 복사본을 로컬 POD의 모든 리프 노드로 보냅니다.

  • 구성 문을 사용하여 CRB 패브릭의 스파인 디바이스에서 proxy-macip-advertisement IRB 인터페이스를 구성하는 것이 좋습니다. 이 옵션은 CRB EVPN-VXLAN 패브릭에서 올바른 ARP 운영을 보장하며 CRB 참조 아키텍처의 일부입니다. 이 옵션에 대한 자세한 내용은 proxy-mac-ip-advertisement 를 참조하십시오.

EVPN–VXLAN 패브릭 참조 설계에 대해 다음 사항을 참고하십시오.

  • 이 예에서는 두 POD의 스파인 및 리프 디바이스 계층이 이미 존재하며 가동 중이라고 가정합니다. 따라서 이 주제에서는 게이트웨이-WAN 라우터 EBGP 언더레이 피어링, POD 간 EBGP 오버레이 피어링 및 VXLAN 연결에 필요한 구성을 제공합니다.

    두 POD에서 스파인 및 리프 디바이스를 구성하는 방법에 대한 자세한 내용은 다음을 참조하십시오.

  • 이 예는 WAN 라우터를 기존 2개의 POD EVPN-VXLAN 패브릭에 통합합니다. VXLAN 연계에 초점을 맞추기 위해 이 예시의 두 POD는 CRB 아키텍처를 기반으로 하는 동일한 3단계 Clos 패브릭을 사용합니다. 스파인은 레이어 3 VXLAN 게이트웨이로서의 역할 외에도 VXLAN 연결 기능도 수행합니다. 결과는 축소된 게이트웨이 아키텍처의 예입니다.

    그림 2 는 축소된 게이트웨이 CRB 기반 VXLAN 연결 예제 토폴로지를 보여줍니다.

    그림 2: VXLAN 연결 예제 토폴로지 VXLAN Stitching Example Topology

    이 예에서는 기존 CRB 스파인 구성에 게이트웨이 기능을 추가합니다. 위에서 언급했듯이 주니퍼는 게이트웨이 피어링 및 연결 기능을 수행하는 슈퍼 스파인 레이어를 통해 5단계 아키텍처도 지원합니다. 최대 확장성과 성능을 위해 개별 게이트웨이 장치를 사용하는 것이 좋습니다. 3단계 또는 5단계 ERB 아키텍처를 통해 린 스파인 또는 슈퍼 스파인 디바이스에 각각 게이트웨이 구성을 추가합니다.

  • POD 간에 오버레이 BGP 피어링을 구성할 때 IBGP 또는 EBGP를 사용할 수 있습니다. 일반적으로 데이터센터(POD)가 동일한 AS(Autonomous System) 번호를 사용하는 경우 IBGP를 사용하고 POD가 다른 AS 번호를 사용하는 경우 EBGP를 사용합니다. 이 예제에서는 각 POD에서 서로 다른 AS 번호를 사용하므로 EBGP 피어링을 사용하여 POD 간의 오버레이를 확장합니다.

  • WAN 라우터를 통합하여 두 POD 간에 언더레이와 오버레이를 확장한 후, POD 간에 주어진 VLAN을 확장하도록 번역 VXLAN 스티칭을 구성합니다. 번역 VXLAN 연결은 각 POD에서 로컬로 사용되는 VNI 값을 WAN 세그먼트 전반에서 사용되는 공통 VNI 값으로 변환합니다. 이 예에서는 각 POD에서 VLAN 1에 다른(겹치지 않는) VNI 값을 할당합니다. 이것이 우리가 이 경우에 병진 스티칭을 사용하는 이유입니다. 일반적으로 동일한 VNI 값이 두 POD에서 동일한 VLAN에 매핑될 때 글로벌 모드 연결을 사용합니다.

다음은 뭘까요

WAN을 통해 언더레이를 확장하도록 게이트웨이 디바이스 구성

이 섹션에서는 축소 게이트웨이 디바이스(VXLAN 스티칭 게이트웨이 기능이 추가된 CRB 스파인)가 WAN 디바이스와 통신할 수 있도록 구성하는 방법에 대해 설명합니다. 각 POD에는 이미 3단계 CRB 아키텍처에 대한 참조 구현을 기반으로 하는 완전한 기능의 언더레이 및 CRB 오버레이가 있습니다. 자세한 내용은 Centrally-Routed Bridging Overlay Design and Implementation 을 참조하십시오.

WAN 라우터와 피어링하도록 스파인/게이트웨이 디바이스를 구성하여 두 POD 간에 언더레이를 확장합니다. 여기에는 각 게이트웨이에서 루프백 경로를 태깅하고 보급하도록 EBGP 피어링 및 정책을 구성하는 작업이 포함됩니다. 이러한 경로는 다음 섹션에서 패브릭 오버레이를 확장하는 POD 간 EBGP 피어링 세션을 설정합니다.

메모:

WAN 라우터 구성은 이 문서의 범위를 벗어납니다. 게이트웨이 디바이스에 대한 통합 이더넷 인터페이스 및 EBGP 피어링을 지원하기만 하면 됩니다. 이 예에서 WAN 라우터는 하나의 POD에서 다른 POD로 수신된 모든 경로를 다시 보급해야 합니다. Junos 디바이스의 경우, 이 예에서 EBGP 언더레이 피어링에 대한 기본 정책입니다.

그림 3 은 POD 네트워크의 DCI 부분에 대한 인터페이스, IP 주소 지정 및 AS 번호 지정에 관한 세부 정보를 제공합니다.

그림 3: WAN 전반의 언더레이 및 오버레이 확장에 대한 세부 정보 Details for Underlay and Overlay Extension Across the WAN

모든 게이트웨이 디바이스의 구성은 비슷합니다. 게이트웨이 1 디바이스를 구성하는 과정을 안내한 다음, 다른 3개 게이트웨이에 대한 전체 구성 델타를 제공합니다.

Gateway 1

  1. 게이트웨이 1 디바이스를 2개의 WAN 라우터에 연결하는 인터페이스를 구성합니다.

    여기서는 단일 멤버를 포함하는 어그리게이션 이더넷(AE) 인터페이스를 생성합니다. 이 접근 방식을 사용하면 멤버 링크를 쉽게 추가하여 WAN 처리량 또는 복원력을 높일 수 있습니다.

  2. 라는 underlay-bgp-wanBGP 피어 그룹을 생성하고 EBGP 그룹으로 구성합니다.
  3. EBGP 언더레이 AS 번호를 구성합니다.

    이 참조 설계에서는 언더레이 네트워크의 각 디바이스에 고유한 AS 번호를 할당합니다. 게이트웨이 및 WAN 디바이스의 AS 번호는 그림 3 을 참조하십시오.

    계층의 시스템 AS 번호 설정은 [edit routing-options autonomous-system] 로컬 패브릭의 MP-IBGP 오버레이 피어링과 POD 간의 오버레이를 확장하는 데 사용되는 EBGP 피어링에 사용되기 때문에 문을 사용하여 local-as BGP 피어 그룹 수준에서 언더레이 네트워크에서 EBGP에 대한 AS 번호를 구성합니다.

  4. WAN 디바이스 1 및 2와의 EBGP 피어링을 구성합니다.

    WAN 디바이스의 IP 주소 및 AS 번호를 지정하여 각 WAN 디바이스를 EBGP neighbor로 구성합니다. 스파인 디바이스의 IP 주소 및 AS 번호는 그림 3 을 참조하십시오.

  5. 특정 커뮤니티로 태그가 지정될 때 WAN에서 수신한 경로의 로컬 기본 설정 값에서 10을 뺀 가져오기 라우팅 정책 구성합니다. 이 정책은 동일한 게이트웨이 루프백 주소가 WAN 피어링을 통해 학습되는 경우에도 게이트웨이 디바이스가 항상 로컬 언더레이 경로를 선호하도록 합니다.

    여기서는 WAN 라우터 피어링에 대한 게이트웨이에 EBGP를 사용합니다. 기본적으로 EBGP는 수신된 모든 경로를 다른 모든 EBGP(및 IBGP) neighbor로 다시 보급합니다. 즉, 게이트웨이 1이 해당 루프백 경로를 WAN 라우터 1에 알리면 WAN 라우터는 해당 경로를 게이트웨이 2에 다시 보급 합니다. 그 결과 각 게이트웨이에는 로컬 POD의 다른 게이트웨이에 도달하기 위한 패브릭 내부 경로와 패브릭 간 경로가 모두 있습니다.

    게이트웨이가 항상 패브릭 내부 경로를 선호하도록 하려고 합니다. 이를 위해 WAN에서 수신한 경로의 로컬 기본 설정 값을 조정(AS 경로 길이에 관계없이 덜 선호되도록)합니다. 또한 이 정책은 로컬 패브릭으로 피어링하는 WAN을 통해 학습된 게이트웨이 루프백 경로의 재보급을 차단합니다. 그 결과 리프 디바이스에는 패브릭 내 게이트웨이 루프백 경로만 표시되지만 게이트웨이 디바이스는 항상 패브릭 내 게이트웨이 경로를 선호합니다.

    다음 단계에서 참조된 커뮤니티를 정의합니다.

    메모:

    이 예시는 두 POD의 기준선 참조 아키텍처에서 시작한다고 가정합니다. 기존 참조 기준의 일부는 패브릭 언더레이 및 오버레이 관련 BGP 피어링 및 정책입니다. 이 예는 스파인과 게이트웨이가 단일 디바이스로 축소되는 것을 기반으로 합니다. WAN 라우터를 통해 언더레이 및 오버레이 확장을 추가했으므로 게이트웨이(이 경우 스파인/게이트웨이 디바이스)에서 기존 언더레이 정책을 수정하여 다른 패브릭 디바이스에서 태그 wan_underlay_comm 가 지정된 경로의 재보급을 차단해야 합니다.

    여기에 이러한 수정의 예가 나와 있습니다. 새롭게 추가된 from_wan 용어는 일치하는 커뮤니티가 있는 경로를 패브릭 언더레이로 보급하지 않습니다.
  6. 내보내기 라우팅 정책을 구성하여 WAN 디바이스에 게이트웨이 루프백 인터페이스 주소를 광고합니다. 이 정책은 다른 모든 광고를 거부합니다. 이제 이러한 경로에 wan_underlay_comm 태그를 지정하는 데 사용되는 커뮤니티를 정의합니다.
  7. 서로 다른 AS에서 EBGP 피어 간 로드 밸런싱을 활성화하려면 옵션으로 multiple-as multipath를 구성합니다.

    기본적으로 EBGP는 각 접두사에 대해 하나의 최적 경로를 선택하고 해당 경로를 포워딩 테이블에 설치합니다. 또한 BGP multipath를 구성하여 주어진 목적지에 대한 모든 equal-cost 경로가 라우팅 테이블에 설치되도록 합니다.

  8. WAN EBGP 세션에 대해 BFD(Bidirectional Forwarding Detection)를 활성화합니다. BFD는 장애를 신속하게 감지하여 빠른 리컨버전스를 가능하게 합니다.

WAN을 통해 오버레이를 확장하도록 게이트웨이 디바이스 구성

이 섹션에서는 EBGP를 사용하여 두 POD 간에 EVPN 오버레이를 확장하는 방법을 보여줍니다. 이 예에서 두 POD는 고유한 AS 번호를 가지므로 EBGP가 사용됩니다.

3단계 CRB 패브릭에서 일반적으로 그렇듯이, 주니퍼의 스파인 디바이스(게이트웨이)는 해당 POD의 리프 디바이스에 대한 오버레이에서 경로 리플렉터 역할을 합니다. 이 섹션에서는 POD 간에 오버레이를 확장하는 새로운 EBGP 피어링 그룹을 정의합니다. AS 번호 지정 및 스파인 디바이스 루프백 주소에 대한 자세한 내용은 그림 3 을 참조하십시오.

모든 게이트웨이 디바이스의 구성은 비슷합니다. 다시 한 번 게이트웨이 1 디바이스를 구성하는 과정을 안내하고 다른 3개 게이트웨이에 대한 전체 구성 델타를 제공합니다.

Gateway 1

  1. EBGP 그룹을 구성하여 EVPN 오버레이를 원격 게이트웨이 디바이스로 확장합니다.

    일반적으로 EVPN 오버레이에는 IBGP를 사용합니다. 여기서는 POD에 다른 AS 번호를 할당했기 때문에 EBGP를 사용합니다. 여기서 옵션을 활성화 multihop 해야 합니다. 기본적으로 EBGP는 직접 연결된 피어를 예상합니다. 이 예에서 피어는 WAN의 먼 쪽에 원격으로 연결됩니다. 또한 옵션을 구성해야 no-nexthop-change 합니다. 이 옵션은 경로를 재보급할 때 BGP 다음 홉을 로컬 값으로 업데이트하는 기본 EBGP 동작을 변경합니다. 이 옵션을 사용하면 게이트웨이 디바이스에 오버레이 경로에 대한 BGP 프로토콜 다음 홉을 변경하지 않고 그대로 두도록 지시할 수 있습니다. 이는 게이트웨이 IP 주소가 VXLAN VTEP 주소가 아닐 수 있기 때문에 중요합니다(예: EVPN 유형 2 경로에 대한 다음 홉이 해당 리프 디바이스를 식별해야 하는 ERB 패브릭에서). 다음 홉을 덮어쓰지 않으면 VXLAN 터널에 올바른 VTEP가 사용됩니다.

    게이트웨이 디바이스 루프백 주소 간에 EBGP 피어링을 구성합니다.

  2. 언더레이 피어링과 마찬가지로 오버레이 확장에서 신속한 장애 감지를 위해 BFD를 추가합니다. 여기서는 오버레이 피어링에 대해 더 긴 간격을 지정합니다. 언더레이 확장 피어링에서는 1초 간격을 사용했습니다. 여기서는 리컨버전스가 필요한 언더레이 장애 발생 시 오버레이 세션이 계속 유지되도록 4초 간격으로 구성합니다.
  3. 이 단계 후에 모든 게이트웨이 디바이스에서 변경 사항을 커밋해야 합니다.

언더레이 및 오버레이 확장을 위한 게이트웨이 디바이스 구성

이 섹션에서는 4개의 게이트웨이 디바이스 모두에 대한 구성 델타를 제공합니다. 이 델타를 초기 CRB 기준선에 추가하여 WAN을 통해 POD 언더레이 및 오버레이를 확장합니다.

메모:

마지막 두 문은 기존 패브릭 언더레이 정책을 수정하여 다른 리프 디바이스에서 커뮤니티로 wan_underlay_comm 태그 지정된 경로의 재보급을 차단합니다.

게이트웨이 1(POD 1)

게이트웨이 2(포드 1)

게이트웨이 3(POD 2)

게이트웨이 4(POD 2)

WAN을 통한 언더레이 및 오버레이 확장 확인

이 섹션에서는 게이트웨이 디바이스가 WAN에 제대로 통합되었는지 확인하여 두 POD 간에 언더레이 및 오버레이 네트워크를 확장하는 방법을 보여줍니다.

  1. 어그리게이션 이더넷 인터페이스가 작동하는지 확인합니다. 적절한 BGP 세션 설정은 인터페이스가 트래픽을 전달할 수 있다는 좋은 신호입니다. 확실하지 않은 경우 AE 링크의 원격 끝을 ping합니다.

    출력은 어그리게이션 이더넷 인터페이스 ae4 가 게이트웨이 1에서 작동하는지 확인합니다. 또한 트래픽 카운터는 인터페이스가 패킷을 보내고 받는지 확인합니다.

  2. WAN 디바이스에 대한 언더레이 EBGP 세션이 설정되었는지 확인합니다.

    출력은 게이트웨이 1 디바이스의 두 EBGP 피어링 세션이 두 WAN 라우터에 모두 설정되었음을 보여줍니다.

  3. 오버레이 EBGP 세션이 WAN 전체의 게이트웨이 디바이스 간에 설정되는지 확인합니다.

    출력은 게이트웨이 1 디바이스의 오버레이 EBGP 세션 모두가 POD 2의 두 원격 게이트웨이에 설정되었음을 확인합니다.

    언더레이 및 오버레이 확장이 확인되면, 포드 간 레이어 2 DCI를 위한 VXLAN 연결을 구성할 준비가 된 것입니다.

기본 스위치 인스턴스에서 번역 VXLAN 연결 DCI 구성

이 섹션에서는 게이트웨이 디바이스에서 VXLAN 연결을 구성하여 기본 스위치 인스턴스를 사용하여 두 POD 사이에 레이어 2 확장을 제공합니다. 당사는 기본 스위치 인스턴스와 MAC-VRF 인스턴스에서 VXLAN 스티칭을 지원합니다. 기본 스위치 인스턴스로 시작하여 나중에 MAC-VRF 인스턴스 케이스에 대한 델타를 표시합니다.

VXLAN 연계는 전역 모드와 변환 모드를 모두 지원합니다. 글로벌 모드에서 VNI는 POD와 WAN 네트워크 모두에서 동일한 엔드투엔드를 유지합니다. POD 간에 VLAN 및 VNI 할당이 겹칠 때 전역 모드를 사용합니다. 번역 모드에서는 로컬 POD VNI 값을 WAN 전반에서 사용되는 VNI에 매핑합니다.

게이트웨이 디바이스에서만 VXLAN 연결을 구성합니다. 리프 디바이스는 변경할 필요가 없습니다. ERB 패브릭에서 게이트웨이 기능을 수행하는 슈퍼 스파인 레이어가 있는 경우 린 스파인 디바이스도 변경할 필요가 없습니다.

표 2 에는 POD, VLAN 및 VNI 할당이 요약되어 있습니다. 이 예에서 POD는 동일한 VLAN에 대해 다른 VNI를 사용합니다. 이것이 이 경우 병진 스티칭을 구성하는 이유입니다. 번역 연결을 사용하면 VNI가 각 POD에 고유할 수 있으며 WAN을 통해 공유 VNI 할당에 연결될 수 있습니다.

표 2: VLAN-VNI 매핑

포드 1

포드 2

WAN DCI

VLAN 1

VNI: 100001

VNI: 110001

VNI: 910001

VLAN 2

VNI: 100002

VNI: 110002

VNI: 910002

그림 4 는 이 예에서 VLAN 1에 대한 VXLAN 연결 계획을 개략적으로 보여줍니다.

그림 4: VLAN 1에 대한 번역 VXLAN 연결 요약 Translational VXLAN Stitching Summary for VLAN 1

그림 4 는 POD 1의 VLAN 1이 VNI 100001 사용하는 반면 POD 2의 동일한 VLAN은 11000에 매핑되는 것을 보여줍니다. WAN을 통한 전송을 위해 두 VLAN을 공통 VNI 910001에 연결합니다. WAN에서 수신되면 게이트웨이는 연결된 VNI를 POD 내에서 로컬로 사용되는 VNI로 다시 변환합니다.

다시 한 번 말씀드리지만, 게이트웨이 디바이스의 구성은 유사합니다. 게이트웨이 1 디바이스에 필요한 단계를 안내하고 다른 게이트웨이 노드에 대한 구성 델타를 제공합니다.

게이트웨이 1에서 번역 VXLAN 연결을 구성하려면 다음 단계를 수행합니다.

Gateway 1

  1. 두 POD 간의 경로 교환을 위한 기본 스위치 인스턴스 EVPN 매개 변수를 구성합니다. 이 구성에는 게이트웨이 간의 모든 활성 ESI LAG에 대한 지원이 포함됩니다. WAN을 통해 ESI LAG를 설정하면 모든 WAN 링크가 패킷 루프의 위험 없이 트래픽을 전달하는 데 적극적으로 사용됩니다. 지정된 POD 내의 모든 게이트웨이에 대해 동일한 ESI 값을 사용해야 하며 각 POD는 고유한 ESI 값을 사용해야 합니다. 따라서 이 예에서는 각 POD의 각 게이트웨이 쌍에 대해 하나씩 두 개의 고유한 ESI를 구성합니다.

    경로 대상은 경로 가져오기를 제어합니다. 하나의 POD에서 보급하는 모든 경로를 다른 POD에서 가져오도록 모든 게이트웨이 디바이스에서 동일한 경로 대상을 구성합니다. 각 게이트웨이 디바이스의 루프백 주소를 반영하도록 경로 식별자를 설정합니다.

  2. VLAN 1 및 2에 대한 VXLAN 연결을 구성합니다. 계층에서 WAN을 통해 연결되는 VNI를 [edit protocols evpn interconnect interconnected-vni-list] 지정합니다. 두 POD의 게이트웨이 디바이스는 연결된 각 VNI에 대해 WAN 전체에서 동일한 VNI를 사용해야 합니다.
  3. 로컬 VLAN/VNI를 변환 VNI에 연결하여 VLAN 1에 대한 변환 VXLAN 연결을 구성합니다. 번역 VNI 값은 이전 단계의 계층에서 protocols evpn interconnect interconnected-vni-list 구성한 VNI와 일치합니다. 따라서 다음 명령을 사용하여 로컬 VNI를 WAN VNI에 매핑합니다.

    글로벌 VXLAN 연결의 경우, 단순히 번역 문을 생략하고 계층에서 구성하는 것과 동일한 VNI 값을 사용하도록 사용자 VLAN을 [edit protocols evpn interconnect interconnected-vni-list] 구성합니다.

    각 Pod의 리프 및 스파인 디바이스는 이미 CRB 참조 아키텍처에 대해 구성되어 있습니다. 기존 구성의 일부로 VLAN은 스파인 및 리프 디바이스 모두에서 정의됩니다. 모든 디바이스의 VLAN 정의에는 VLAN ID와 VXLAN VNI 매핑이 포함됩니다. 그러나 스파인의 VLAN 구성은 레이어 3 IRB 인터페이스를 포함한다는 점에서 리프와 다르며, 이 역시 CRB의 예입니다. VLAN 1에 대한 기존 구성은 참조를 위해 게이트웨이 1(스파인 1) 디바이스에 표시됩니다.

    이제 게이트웨이 1 디바이스에서 VLAN 1에 대한 구성을 수정하여 번역 VXLAN 연결을 불러일으킵니다. 지정한 VNI는 이전 단계의 계층에서 edit protocols evpn interconnect interconnected-vni-list 구성한 VNI 값 중 하나와 일치합니다. 그 결과 디바이스는 VNI 100001(VLAN 1의 POD 1에서 로컬로 사용됨)를 WAN을 통해 전송할 때 VNI 910001로 변환합니다. 원격 POD에서 유사한 구성은 WAN VNI에서 원격 POD의 동일한 VLAN과 연결된 로컬 VNI로 다시 매핑됩니다. 구성 모드에서 다음 명령을 입력합니다.

  4. VLAN 2를 위한 번역 VXLAN 스티칭을 구성합니다.

    VLAN 2의 구성을 수정하여 VNI 100002(VLAN 2의 POD 1에서 로컬로 사용됨)에서 WAN을 통해 VNI 910002으로 번역 VXLAN 연결을 호출합니다.

  5. VLAN 1에 대한 변경 사항을 확인합니다. 간결성을 위해 VLAN 2는 생략합니다. 다음 명령은 구성 모드에서 VLAN 1의 변경 사항을 표시합니다.
  6. 완료되면 모든 게이트웨이 장치에서 변경 내용을 커밋해야 합니다.

기본 스위치 인스턴스의 번역 VXLAN 연계를 위한 게이트웨이 디바이스 구성

이 섹션에서는 4개의 게이트웨이 디바이스 모두에 대한 구성 델타를 제공합니다. WAN을 통해 DCI에 대해 수정한 CRB 기준선에 이 델타를 추가합니다. 언더레이와 오버레이를 확장한 후에는 다음 구성이 로컬 POD의 VNI와 WAN의 VNI 간에 번역 VXLAN 연결을 수행합니다.

게이트웨이 1(POD 1)

게이트웨이 2(포드 1)

게이트웨이 3(POD 2)

게이트웨이 4(POD 2)

기본 스위치 인스턴스에서 번역 VXLAN 연결 확인

  1. 게이트웨이 디바이스 간의 ESI LAG가 작동 중이고 액티브-액티브 모드인지 확인합니다.

    출력은 ESI 00:00:ff:ff:00:11:00:00:00:00:01이 작동 중임을 보여줍니다. 또한 출력에는 액티브-액티브 포워딩(Mode 열은 표시 all-active됨)과 Designated forwarder 및 Backup forwarder 디바이스 주소가 모두 표시됩니다.

  2. 원격 VXLAN VTEP를 확인하여 원격 게이트웨이 디바이스가 WAN VTEP로 나열되는지 확인합니다.

    출력에는 두 원격 게이트웨이가 모두 (으)로 Wan-VTEP올바르게 표시됩니다.

  3. VXLAN VNI 100001에 대한 게이트웨이 1 디바이스의 EVPN 데이터베이스를 확인합니다. 이 예에서는 POD 1의 CRB 리프 및 스파인에서 VLAN 1에 할당한 VNI입니다.

    출력은 VLAN 1과 연결된 VNI 값 100001가 보급되고 로컬 POD에서 사용됨을 확인합니다.

  4. VXLAN VNI 910001에 대한 게이트웨이 1 디바이스의 EVPN 데이터베이스를 확인합니다. 이는 WAN을 통한 번역 VXLAN 연결을 위한 VLAN 1과 연결된 VNI입니다.

    출력은 VLAN 1과 연결된 VNI 값 910001가 원격 포드에 보급됨을 확인합니다. 이는 VNI 910001가 WAN을 통해 사용됨을 확인합니다. 로컬 VNI가 WAN에서 사용되는 VNI와 다르다는 점을 감안할 때, 이는 기본 스위치 인스턴스 사용 사례에 대한 번역 VXLAN 연결을 확인합니다.

MAC-VRF 라우팅 인스턴스에서의 VXLAN 연결

주니퍼는 MAC-VRF 라우팅 인스턴스에서 글로벌 및 번역 VXLAN 연계를 모두 지원합니다. 이전 기본 스위치 인스턴스에 대한 변환 연결을 시연했기 때문에 MAC-VRF 사례에 대해 글로벌 모드 VXLAN 연결을 표시합니다.

MAC-VRF 라우팅 인스턴스의 적용 범위는 이 문서의 범위를 벗어납니다. 다시 한 번 말씀드리지만, 참조 기준에 따라 구성된 MAC-VRF 인스턴스가 있는 CRB 패브릭이 작동 중이라고 가정합니다. MAC-VRF 구성에 대한 자세한 내용은 EVPN-VXLAN, DC IP 패브릭, MAC VRF, L2 서비스의 MAC-VRF 라우팅 인스턴스 유형 개요 및 샘플 사용 사례를 참조하십시오.

VXLAN 스티칭 기능에 초점을 맞추기 위해, 기존 MAC-VRF에 VXLAN 스티칭을 추가하는 델타를 호출합니다. 기본 스위치 인스턴스와 마찬가지로 연결 구성을 게이트웨이 디바이스에만 적용합니다. 그러나 MAC-VRF의 경우 계층이 아닌 MAC-VRF 인스턴스에서 VLAN-VNI 매핑을 [edit vlans] 구성합니다. MAC-VRF 케이스의 또 다른 차이점은 계층이 아닌 [edit protocols evpn interconnect interconnected-vni-list] 라우팅 인스턴스에서 문을 구성 interconnected-vni-list 한다는 것입니다.

이 예의 목표는 VLAN 1201 및 1202에 대한 글로벌 VXLAN 연결을 수행하는 것이며, 이는 각각 VXLAN VNI 401201 및 401201에 매핑됩니다. 두 POD에서 동일한 VLAN-VNI 매핑을 구성합니다. VLAN-VNI 할당은 두 POD에서 겹치기 때문에 글로벌 모드 연결을 사용할 수 있습니다.

연결(stitching)을 수행할 MAC-VRF 인스턴스의 게이트웨이 디바이스에 다음 명령을 추가합니다. 구성은 로컬 게이트웨이 간에 사용되는 ESI LAG를 정의하고 상호 연결된 VNI 목록을 지정합니다.

모든 게이트웨이 디바이스에 유사한 구성이 필요합니다. 이전과 마찬가지로 게이트웨이 1 디바이스에 대한 구성 세부 정보를 살펴본 다음 다른 게이트웨이에 대한 전체 구성 델타를 제공합니다.

아래 예에서는 WAN 세그먼트를 통한 VXLAN 연결을 위한 VNI 401201 및 401202를 구성합니다.

메모:

MAC-VRF 컨텍스트에서 VXLAN 연결을 구성할 때, Junos OS 실행하는 스위치의 QFX5000 라인의 모든 리프 노드에 옵션을 포함 set forwarding-options evpn-vxlan shared-tunnels 해야 합니다. 이 명령문을 추가한 후 스위치를 재부팅해야 합니다. MAC-VRF 라우팅 인스턴스에서 VXLAN 스티칭과 함께 Junos OS를 실행하는 QFX10000 라인 스위치의 게이트웨이 노드에서는 문을 사용하지 shared tunnels 않는 것이 좋습니다.

공유 터널은 진화한 Junos OS(MAC-VRF 구성으로만 EVPN-VXLAN을 지원)를 실행하는 디바이스에서 기본적으로 활성화됩니다.

앞서 언급했듯이 완전한 MAC-VRF 라우팅 인스턴스 구성은 우리의 범위를 벗어납니다. 아래 구성 블록은 MAC-VRF 참조 설계를 기반으로 하는 기존 MAC-VRF 인스턴스를 사용합니다. 이것이 글로벌 모드 VXLAN 연결의 예(MAC-VRF 인스턴스용)인 이유를 더 잘 설명하기 위해 이 구성 캡처를 보여줍니다. 샘플은 축소된 게이트웨이 예제 토폴로지의 게이트웨이이기도 한 CRB 스파인 1 디바이스에서 가져온 것입니다. 간결성을 위해 VLAN 1201에 대한 구성만 표시합니다.

위에서 VLAN 1201에 대한 MAC-VRF 정의는 계층에 나열된 동일한 VNI(401201)를 [edit routing-instances MACVRF-mac-vrf-ep-t2-stchd-1 protocols evpn interconnect interconnected-vni-list] 지정합니다. 이로 인해 해당 VNI에 대한 종단 간(전역) 중요성이 발생합니다.

기본 스위치 인스턴스와 마찬가지로 MAC-VRF 컨텍스트에서 변환 VXLAN 연결을 호출하는 것은 간단합니다.

예를 들어, VLAN 801에 대한 로컬 VNI 300801에서 920001의 WAN VNI로 변환하려면 관련 MAC-VRF 인스턴스에서 VLAN 정의를 수정하여 문을 포함 translation-vni 920001 하기만 하면 됩니다.

MAC-VRF VLAN 구성에 translation-vni 920001 명령문을 추가하면 게이트웨이 디바이스가 WAN을 통해 전송할 때 로컬 VNI 300801에서 VNI 920001로 변환하도록 지시할 수 있습니다.

MAC-VRF를 사용한 글로벌 VXLAN 연결을 위한 게이트웨이 디바이스 구성

이 섹션에서는 MAC-VRF 컨텍스트에서 글로벌 모드 VXLAN 연결을 지원하기 위해 4개의 게이트웨이 디바이스 모두에 대한 구성 델타를 제공합니다. 이 델타를 추가하면 WAN을 통해 DCI에 대해 수정한 CRB 기준선에 추가됩니다. 언더레이와 오버레이를 확장한 후, 아래 구성은 VNI 401201 및 401202에 대한 글로벌 VXLAN 연결을 수행합니다. 이는 전역 모드 예제이므로 문을 포함 translation-vni 하지 않습니다. VLAN 및 인터커넥트 VNI 값은 동일합니다.

게이트웨이 1(POD 1)

게이트웨이 2(포드 1)

게이트웨이 3(POD 2)

게이트웨이 4(POD 2)

메모:

MAC-VRF 컨텍스트에서 VXLAN 연결을 구성할 때 QFX5000 스위치 라인의 모든 리프 노드에 옵션을 포함 set forwarding-options evpn-vxlan shared-tunnels 해야 합니다. 이 명령문을 추가한 후 스위치를 재부팅해야 합니다. MAC-VRF 라우팅 인스턴스에서 VXLAN 스티칭을 사용하는 Junos OS를 실행하는 QFX10000 라인 스위치의 게이트웨이 노드에서 공유 터널 문을 구성하는 것은 권장되지 않습니다.

공유 터널은 진화한 Junos OS(MAC-VRF 구성으로만 EVPN-VXLAN을 지원)를 실행하는 디바이스에서 기본적으로 활성화됩니다.

MAC-VRF 인스턴스에서 글로벌 VXLAN 연결 확인

  1. 게이트웨이 디바이스 간에 사용되는 ESI LAG가 작동 중이고 MAC-VRF 케이스에 대한 액티브-액티브 모드인지 확인합니다.

    출력은 ESI 00:00:ff:ff:00:11:00:00:00:00:01이 작동 중임을 보여줍니다. 액티브-액티브 포워딩은 모드와 지정된 포워더 및 백업 포워더의 존재 여부로 확인 all-active 됩니다.

  2. 원격 VXLAN VTEP를 확인하여 원격 게이트웨이 디바이스가 WAN VTEP로 나열되는지 확인합니다.

    출력에는 두 원격 게이트웨이가 모두 (으)로 Wan-VTEP올바르게 표시됩니다.

  3. WAN 광고용 VXLAN VNI 401201 위한 게이트웨이 1 디바이스의 EVPN 데이터베이스를 확인합니다. 이 예에서는 두 POD에서 VLAN 1201에 할당된 VNI입니다. CRB 예이므로 스파인 및 리프 디바이스에서 VLAN 1201을 정의했습니다. 그러나 스파인 디바이스만 VLAN 구성에 레이어 3 IRB 인터페이스를 포함합니다.

    출력은 VLAN 1201 및 irb.1201 인터페이스와 연결된 VNI 값 401201가 원격 POD에 보급됨을 확인합니다. 이는 VNI 401201가 VLAN 1201을 위해 WAN을 통해 사용됨을 확인합니다.

  4. 로컬 POD에 대한 보급을 위해 VXLAN VNI 401201 위한 게이트웨이 1 디바이스의 EVPN 데이터베이스를 확인합니다. 이는 두 POD에서 VLAN 1201과 연결된 VNI입니다. 이는 이전 명령에서 원격 게이트웨이에 광고를 표시하는 데 사용한 것과 동일한 VNI입니다.

    출력은 VNI 401201가 로컬 POD에 보급되었음을 보여줍니다. 이를 통해 VNI 401201가 로컬에서 사용됨을 확인할 수 있습니다. 동일한 VNI가 로컬 및 WAN 전반에서 사용된다는 점을 감안할 때, 이는 MAC-VRF 케이스에서 글로벌 VXLAN 스티칭을 확인시켜 줍니다.

VXLAN 연계를 통한 가상 머신 트래픽 최적화(VMTO)

일부 환경에서는 /32 또는 /128 호스트 경로를 설치하여 특정 VM에 대한 트래픽을 최적화할 수 있습니다. VXLAN 스티칭을 사용하는 경우 모든 게이트웨이 노드에서 다음을 구성하여 호스트 경로를 설치할 수 있도록 합니다.

첫 번째 명령은 기본 스위치 인스턴스에 호스트 경로 지원을 추가합니다. 두 번째는 특정 MAC-VRF 인스턴스에 대한 호스트 경로 지원을 추가합니다. 인스턴스 유형을 혼합하여 사용하는 경우 둘 다 구성해야 합니다.

호스트 경로 지원 확인

목적

MAC-VRF를 사용할 때 기본 스위치 인스턴스를 사용할 때 /32 호스트 경로를 레이어 3 VRF 테이블로 가져오거나 MAC-VRF 테이블로 가져왔는지 확인합니다.

행동

관련 라우팅 인스턴스의 경로 테이블을 표시하고 /32(또는 /128) 비트 접두사가 있는 경로를 찾습니다. 기본 스위치 인스턴스인 VXLAN 스티칭에 사용되는 레이어 3 VRF 테이블을 표시하는 것으로 시작하겠습니다.

다음으로 MAC-VRF 인스턴스 라우팅 테이블을 표시합니다.