Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지의 내용
 

레이어 2 데이터센터 상호 연결을 위한 VXLAN 연결 구성

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

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

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

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

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

참고:

이 문서에서는 "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 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에 중복되는 VLAN-VNI 할당이 있는 경우 동일한 값(글로벌 연결)을 갖거나 두 POD 간에 변환될 수 있습니다. 후자의 기능은 겹치는 VNI가 없는 POD(DC)를 VLAN 할당에 병합할 때 유용합니다.

  • 주니퍼는 기본 스위치 EVPN 인스턴스(EVI) 및 MAC-VRF 라우팅 인스턴스에서 가상 확장형 LAN(VXLAN) 결합을 지원합니다.

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

  • 게이트웨이 디바이스는 Junos 소프트웨어 릴리스 20.4R3 이상을 실행하는 QFX10000 라인의 스위치여야 합니다.

  • 구성 문을 사용하여 proxy-macip-advertisement CRB 패브릭의 스파인 디바이스에서 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 스티칭을 구성합니다. Translational VXLAN 스티칭은 각 POD에서 로컬로 사용되는 VNI 값을 WAN 세그먼트 전체에서 사용되는 공통 VNI 값으로 변환합니다. 이 예에서는 VLAN 1에 각 POD에 다른(겹치지 않는) VNI 값을 할당합니다. 이것이 우리가 이 경우에 번역 스티칭을 사용하는 이유입니다. 일반적으로 동일한 VNI 값이 두 PODS의 동일한 VLAN에 매핑될 때 글로벌 모드 결합을 사용합니다.

무엇 향후 계획

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

이 섹션에서는 WAN 디바이스와 통신할 수 있도록 축소된 게이트웨이 디바이스(VXLAN 스티칭 게이트웨이 기능이 추가된 CRB 스파인)를 구성하는 방법을 보여줍니다. 각 POD에는 3단계 CRB 아키텍처에 대한 참조 구현을 기반으로 하는 완전한 기능의 언더레이 및 CRB 오버레이가 이미 있습니다. 자세한 내용은 중앙 라우팅 브리징 오버레이 설계 및 구현을 참조하십시오.

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 디바이스를 두 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) 인접 라우터에 다시 보급합니다. 즉, 게이트웨이 1이 루프백 경로를 WAN 라우터 1에 보급하면 WAN 라우터는 해당 경로를 게이트웨이 2에 다시 보급 합니다. 그 결과 각 게이트웨이에는 로컬 POD의 다른 게이트웨이에 도달하기 위한 패브릭 내 경로와 패브릭 간 경로가 모두 있습니다.

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

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

    참고:

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

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

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

  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. EVPN 오버레이를 원격 게이트웨이 디바이스로 확장하도록 EBGP 그룹을 구성합니다.

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

    언더레이 및 오버레이 확장이 확인되면 POD 간 레이어 2 DCI에 대한 VXLAN 연결 구성으로 이동할 준비가 된 것입니다.

기본 스위치 인스턴스에서 DCI 연결 변환 VXLAN 구성

이 섹션에서는 기본 스위치 인스턴스를 사용하여 두 POD 사이에 레이어 2 스트레치를 제공하도록 게이트웨이 디바이스에서 VXLAN 스티칭을 구성합니다. 주니퍼는 기본 스위치 인스턴스와 MAC-VRF 인스턴스에서 VXLAN 스티칭을 지원합니다. 기본 스위치 인스턴스로 시작하여 나중에 MAC-VRF 인스턴스 사례에 대한 델타를 보여줍니다.

VXLAN 스티칭은 글로벌 모드와 번역 모드를 모두 지원합니다. 전역 모드에서 VNI는 종단 간, 즉 POD와 WAN 네트워크 모두에서 동일하게 유지됩니다. VLAN 및 VNI 할당이 POD 간에 겹치는 경우 전역 모드를 사용합니다. 변환 모드에서는 로컬 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 Translational VXLAN Stitching Summary for VLAN 1 에 대한 번역 VXLAN 연결 요약

그림 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] 구성합니다.

    각 포드의 리프 및 스파인 디바이스는 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 값 중 하나와 일치합니다. 그 결과 디바이스는 WAN을 통해 전송할 때 VNI 100001(VLAN 1의 POD 1에서 로컬로 사용됨)를 VNI 910001로 변환합니다. 원격 POD에서 유사한 구성이 WAN VNI에서 원격 POD의 동일한 VLAN과 연결된 로컬 VNI로 다시 매핑됩니다. 구성 모드에서 다음 명령을 입력합니다.

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

    VLAN 2에 대한 구성을 수정하여 WAN을 통해 VNI 100002(VLAN 2의 POD 1에서 로컬로 사용됨)에서 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:01이 작동 중임을 보여줍니다. 출력에는 액티브-액티브 포워딩(Mode 열 표시all-active)과 및 Backup forwarder Designated 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이 원격 POD에 보급되었음을 확인합니다. 이를 통해 WAN을 통해 VNI 910001 사용됨을 확인할 수 있습니다. 로컬 VNI가 WAN에서 사용되는 VNI와 다르다는 점을 감안할 때, 이는 기본 스위치 인스턴스 사용 사례에 대한 번역 VXLAN 결합을 확인시켜줍니다.

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

주니퍼는 MAC-VRF 라우팅 인스턴스에서 글로벌 및 번역 VXLAN 스티칭을 모두 지원합니다. 이전 기본 스위치 인스턴스에 대한 번역 스티칭을 시연했기 때문에 MAC-VRF의 경우 글로벌 모드 VXLAN 스티칭을 보여줍니다.

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

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에 매핑됩니다. 두 PODS에서 동일한 VLAN-VNI 매핑을 구성합니다. VLAN-VNI 할당이 두 POD에서 겹치기 때문에 전역 모드 결합을 사용할 수 있습니다.

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

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

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

참고:

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

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

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

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

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

    출력은 ESI 00:00:ff:ff:00:11: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)

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

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

호스트 경로 지원 확인

목적

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

작업

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

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