Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

EVPN 멀티호밍 설정에서 Junos OS 업그레이드

이 네트워크 구성 예 정보

이 네트워크 구성 예제를 사용하여 EVPN 멀티호밍(ESI-LAG라고도 함)을 위해 구성된 한 쌍의 Junos OS 또는 Junos Evolved 디바이스에서 Junos OS를 연결된 서버(호스트)로 수동으로 업그레이드합니다.

이 예는 QFX 스위치를 사용하는 기존 ERB(Edge-Routed Bridging) EVPN 구성을 기반으로 합니다. 여기서 설명한 단계는 CRB(Centrally-Routed Bridging) 및 브리지 오버레이 EVPN 아키텍처에도 적용할 수 있습니다.

지원되는 플랫폼 및 EVPN ESI-LAG에 대한 Junos 또는 Junos Evolved 릴리스 지원에 대한 자세한 내용은 기능 탐색기를 참조하십시오.

예: EVPN 멀티호밍 사용 사례에서 Junos OS 업그레이드

요구 사항

이 절차를 사용하여 EVPN 멀티호밍 호스트 연결을 지원하도록 구성된 한 쌍의 QFX 시리즈 리프 스위치를 업그레이드합니다.

시작하기 전에:

  • 콘솔 액세스가 두 리프 디바이스 모두에서 사용 가능한지 확인합니다.

  • 호스트 MAC 주소가 두 리프 디바이스의 EVPN 데이터베이스에 있는지 확인합니다.

  • 두 리프 스위치의 LAG 인터페이스에서 60초(60000밀리초)의 hold-time up 타이머 값을 구성하는 것이 좋습니다. 이 옵션에 대한 자세한 내용은 hold-time 을 참조하십시오. 홀드 업 타이머를 구성하면 재부팅 이벤트 후 스위치가 BGP 경로 교환을 완료하기 전에 LAG 멤버 인터페이스에 향하는 호스트가 작동하지 않도록 할 수 있습니다.

  • 이 예는 멀티홈 호스트에서 VLAN의 IRB 인터페이스에 구성된 가상 게이트웨이 주소로의 ping을 생성합니다. ping 응답을 생성하려면 두 스위치의 IRB 인터페이스에 옵션을 추가해야 virtual-gateway-accept-data 합니다.

이 예에서 사용되는 하드웨어 및 소프트웨어 구성 요소는 다음과 같습니다.

  • 처음에 Junos OS 릴리스 19.1R3.9를 실행하는 2개의 QFX5100-48S-6Q 디바이스

  • Junos OS 릴리스 19.2R1.8

  • 두 ToR 스위치에 대한 링크가 있는 Ubuntu 또는 Centos 서버. 서버는 LACP 기반 링크 어그리게이션을 지원하기 위해 모드 4 본딩 인터페이스로 구성됩니다.

절차 개요

이 섹션에서는 업그레이드 절차에 대한 개요를 제공합니다. 일련의 단계는 멀티홈 호스트를 지원하는 리프 스위치 한 쌍을 업그레이드할 때 중단을 최소화하도록 설계되었습니다.

  1. 업그레이드 준비:

    • LAG 인터페이스가 두 스위치 모두에서 작동하고 EVPN 컨트롤 플레인이 통합되었는지 확인합니다.

    • 원하는 Junos OS 이미지를 두 스위치의 /var/tmp 디렉터리에 복사합니다.

  2. 멀티홈 호스트에서 동일한 VLAN의 오버레이 대상으로 ping을 시작합니다. 예를 들어, CRB의 경우 스파인 디바이스의 IRB 인터페이스 또는 ERB의 경우 리프 디바이스의 IRB 인터페이스가 있습니다. 이 단계는 나중에 업그레이드 절차와 관련된 패킷 손실 정도를 확인할 수 있도록 하기 위해 수행됩니다.

  3. 업그레이드할 스위치를 선택하고 서버 또는 호스트에 대한 다운링크 인터페이스를 비활성화합니다.

  4. 스위치를 새로운 Junos 버전으로 업그레이드하고 재부팅합니다. 스위치에서 새 버전을 실행하고 있는지 확인합니다.

  5. EVPN 컨트롤 플레인을 확인하여 업그레이드된 스위치가 다운링크 호스트의 MAC 주소를 다시 학습했는지 확인합니다.

  6. 업그레이드된 스위치의 다운링크 인터페이스를 활성화합니다.

  7. 다른 스위치에서 3단계부터 6단계까지 반복하여 업그레이드를 완료합니다.

  8. 호스트 생성 ping을 중지하고 업그레이드 절차 중 손실된 패킷 수를 확인합니다.

    참고:

    업그레이드 절차는 중단이 없습니다. 다운링크에서 전송 중인 패킷은 업그레이드 준비 과정에서 인터페이스가 비활성화될 때 손실될 수 있습니다. 인터페이스가 비활성화되면 트래픽은 다른 리프 스위치로 전환되고 계속 흐릅니다. 이 절차에서는 업그레이드 중인 각 스위치에서 LAG 멤버 인터페이스를 비활성화할 때 두 개의 작은 손실 창이 있습니다. 이러한 손실 기간은 50밀리초를 초과해서는 안 됩니다.

토폴로지

그림 1 은 이 EVPN 멀티호밍 업그레이드 예시의 토폴로지를 보여줍니다. 두 스위치 모두 연결된 호스트와 연결된 VLAN에 대해 구성된 IRB 인터페이스를 가지고 있습니다. 이러한 IRB는 192.168.0.1의 공유 가상 게이트웨이 주소로 구성됩니다. 호스트는 bond0 인터페이스에서 주소 192.1689.1.100이 할당됩니다. 이 다이어그램은 또한 호스트에 있는 bond0 인터페이스의 MAC 주소와 두 리프 스위치의 LAG 인터페이스에 구성된 ESI(Ethernet Segment Identifier)에 대해 자세히 설명합니다.

그림 1: 토폴로지 Topology

EVPN 멀티호밍 업그레이드 구성

업그레이드 준비

단계별 절차
  1. EVPN 멀티호밍이 작동하는지 확인합니다. 서버에 로그인하고 본딩 인터페이스가 작동 중인지 확인합니다. 그 동안 bond0 인터페이스의 MAC 주소를 기록해 둡니다. 이 예에서는 호스트가 Ubuntu를 실행 중이므로 ifconfig 명령이 사용됩니다. Centos 배포판을ip link show bond0 사용하는 경우 명령을 사용합니다. 이 예에서 호스트의 bond0 인터페이스에 대한 MAC 주소는 00:1B:21:79:5A:EC입니다.

  2. 명령을 사용하여 LAG 인터페이스가 두 리프 디바이스 모두에서 작동하는지 확인합니다 show interfaces ae1 . 이 예에서 LAG 인터페이스는 ae1 두 리프 디바이스 모두에 있습니다. 어그리게이션된 인터페이스 번호는 두 리프 디바이스 간에 달라질 수 있는 로컬 인덱스입니다. 인터페이스 이름이 아니라 일치하는 ESI 및 system-id 매개 변수의 구성으로 두 리프 간의 LAG 인터페이스를 논리적으로 바인딩합니다. LAG 인터페이스가 두 리프 디바이스 모두에서 작동 중인지 확인해야 합니다.

    출력은 LAG 인터페이스가 작동하고 ESI가 양쪽 리프에서 00:01:01:01:01:01:01:01: 01:01로 구성되어 있음을 확인합니다.

  3. 이전 단계에서 기록한 ESI 값을 사용하여 호스트 MAC 주소가 두 멤버 스위치의 EVPN 데이터베이스에 존재하는지 확인합니다.

  4. 두 리프 디바이스에 어그리게이션된 인터페이스 구성을 표시합니다. hold-time up 옵션은 이 예의 권장 사항에 따라 6초 동안 구성됩니다.

  5. 두 스위치의 LAG 멤버 인터페이스 이름을 기록해 둡니다. 업그레이드 중인 스위치에서 이 인터페이스를 종료해야 합니다. LAG 멤버 인터페이스 이름은 스위치 쌍 간에 달라지는 것이 일반적입니다. 이 예에서 LAG 멤버 인터페이스는 두 리프 디바이스 모두에서 xe-0/0/46입니다.

  6. 그림 2와 같이 원하는 Junos OS 이미지를 두 리프 디바이스로 전송합니다. 스위치의 /var/tmp 디렉토리에 이미지를 배치해야 합니다. 일반적으로 FTP 또는 SCP는 리프 디바이스에 이미지를 복사하는 데 사용됩니다. CLI를 사용하여 파일을 복사하는 방법에 대한 자세한 내용은 파일 복사를 참조하십시오.

    참고:

    업그레이드를 위한 충분한 공간이 있는지 확인하기 위해 새 이미지를 전송하기 전에 명령을 실행하는 request system storage cleanup 것이 좋습니다.

    그림 2: 새로운 Junos 이미지 Transfer the New Junos Image 전송
  7. EVPN 멀티호밍 리프 모두에서 시작 Junos OS 버전을 확인합니다. 이 예에서 시작 Junos OS 버전은 19.1R3.9입니다. 간결성을 위해 리프 2의 출력만 표시됩니다.

  8. 지금까지 수행된 단계는 LAG 인터페이스가 작동하고 EVPN 컨트롤 플레인이 수렴되었음을 나타냅니다. 업그레이드를 시작하기 전에 호스트에서 VLAN의 IRB 인터페이스에 할당된 가상 게이트웨이 IP 주소로 ping을 시작합니다. 이 트래픽은 하나의 멤버 링크 또는 다른 멤버 링크로 해시됩니다. 두 스위치가 동일한 가상 게이트웨이 IP로 구성되므로 호스트가 트래픽을 보내는 스위치는 중요하지 않습니다.

    두 스위치 중 하나가 ping에 응답할 수 있다는 점에 유의해야 합니다. 즉, 한 스위치가 재부팅될 때 다른 스위치는 사용 가능한 상태로 유지되며 ping에 응답할 수 있습니다.

    참고:

    ping이 성공하려면 IRB 인터페이스가 두 스위치 모두에서 옵션으로 구성되어 virtual-gateway-accept-data 있는지 확인해야 합니다.

참고:

손실된 총 패킷 수를 확인할 수 있도록 업그레이드 절차 전반에 걸쳐 호스트-IRB 인터페이스 ping이 계속 실행되는지 확인합니다.

리프 3 업그레이드

단계별 절차
  1. 그림 3의 빨간색 "X"와 같이 LAG 멤버 xe-0/0/46을 향하는 서버를 종료하여 Leaf 3에서 업그레이드 프로세스를 시작합니다.

    참고:

    이 단계에서 리프 3의 xe-0/0/46 인터페이스에서 전송 중인 소수의 패킷이 손실될 수 있습니다. 이때 Ping 트래픽은 업그레이드가 완료될 때까지 리프 2 디바이스를 통해 흐르고 리프 3에서 다운링크 인터페이스를 다시 활성화합니다.

    그림 3: 리프 3 Disable the Downlink Interface on Leaf 3 에서 다운링크 인터페이스 비활성화
  2. 콘솔 연결을 사용하여 명령을 사용하여 리프 3 request system software add /var/tmp/jinstall-host-qfx-5e-x86-64-19.2R1.8-secure-signed.tgz reboot 에서 업그레이드를 시작합니다. 이미지 로딩 및 후속 재부팅 프로세스는 그림 4의 톱니바퀴 아이콘으로 표시됩니다. 업그레이드 프로세스를 완료하는 데 몇 분 정도 걸립니다. 리프 3을 업그레이드하는 동안 완전히 작동하므로 이 시간 동안 ping이 리프 2를 통해 전달되어야 합니다.

    그림 4: 리프 3 Start the Upgrade of Leaf 3 업그레이드 시작

    스위치 재부팅 후 업그레이드가 성공했는지 확인합니다.

  3. 이때 모든 언더레이 및 오버레이 BGP 세션을 다시 설정해야 합니다. 리프 3에서 지연 멤버 인터페이스를 활성화하기 전에 모든 BGP 피어가 백업되고 EVPN 컨트롤 플레인이 다시 수렴되었는지 확인합니다.

  4. 그림 5의 녹색 확인 표시로 표시된 것처럼 리프 3에서 다운링크 인터페이스를 활성화합니다.

리프2 업그레이드

단계별 절차
  1. 그림 6의 빨간색 X로 표시된 것처럼 다운링크 인터페이스를 비활성화하여 리프 2에서 업그레이드 절차를 시작합니다. ping이 리프 2를 통해 흐를 가능성이 높기 때문에 이 단계는 절차에서 두 번째 손실 창을 표시합니다. 리프 2를 업그레이드할 때 핑은 리프 3 디바이스를 통해 계속 흘러야 합니다.

    그림 6: leaf2 Disable the Downlink Interface on leaf2 에서 다운링크 인터페이스 비활성화
  2. 이미지 로드를 시작하고 명령을 사용하여 리프 2에서 재부팅합니다 request system software add /var/tmp/jinstall-host-qfx-5e-x86-64-19.2R1.8-secure-signed.tgz . 리프 2의 업그레이드 및 재부팅은 그림 7의 톱니바퀴 아이콘과 같습니다.

    그림 7: 리프 2 Start the Upgrade at Leaf 2 에서 업그레이드 시작

    리프 2 재부팅 후 Junos OS 버전을 확인하여 업그레이드가 성공했는지 확인합니다.

  3. EVPN 컨트롤 플레인이 리프 2에서 재수렴되었는지 확인합니다. 모든 BGP 세션이 다시 설정되고 호스트의 MAC 주소가 EVPN 데이터베이스에 채워지는 데 몇 분 정도 걸릴 수 있습니다.

  4. 그림 8의 녹색 확인 표시로 표시된 것처럼 리프 2에서 LAG 멤버 인터페이스를 활성화합니다.

    그림 8: 리프 2 Enable the Downlink Interface on leaf 2 에서 다운링크 인터페이스 활성화
  5. 이제 두 스위치가 모두 업그레이드되었으며 모든 LAG 멤버 인터페이스가 다시 작동합니다. 업그레이드 프로세스 중 트래픽 중단을 측정하려면 ping을 중지하고 ping 통계를 기록해 두십시오. 이 예에서는 멀티홈 호스트를 지원하는 리프 디바이스 쌍을 업그레이드하는 동안 총 2개의 패킷이 손실됩니다.

    대부분의 경우 진행 중인 ping이 중단되면 단일 패킷의 손실이 표시됩니다. 실제로 손실된 패킷이 1개이든 2개이든 관계없이 업그레이드는 사실상 무중단으로 간주됩니다. 이는 이 예에 설명된 절차의 기대치에 따른 것입니다.

결론

EVPN 멀티호밍은 고성능 및 고가용성을 모두 지원해야 하는 데이터센터 아키텍처에서 중요한 기능입니다. 이 예에서는 중단을 최소화하면서 멀티홈 호스트 연결을 지원하는 한 쌍의 리프 스위치를 업그레이드하는 데 필요한 구성과 단계를 설명했습니다.