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 본딩 인터페이스로 구성됩니다.
절차 개요
이 섹션에서는 업그레이드 절차에 대한 개요를 제공합니다. 일련의 단계는 멀티홈 호스트를 지원하는 리프 스위치 한 쌍을 업그레이드할 때 중단을 최소화하도록 설계되었습니다.
업그레이드 준비:
LAG 인터페이스가 두 스위치 모두에서 작동하고 EVPN 컨트롤 플레인이 통합되었는지 확인합니다.
원하는 Junos OS 이미지를 두 스위치의 /var/tmp 디렉터리에 복사합니다.
멀티홈 호스트에서 동일한 VLAN의 오버레이 대상으로 ping을 시작합니다. 예를 들어, CRB의 경우 스파인 디바이스의 IRB 인터페이스 또는 ERB의 경우 리프 디바이스의 IRB 인터페이스가 있습니다. 이 단계는 나중에 업그레이드 절차와 관련된 패킷 손실 정도를 확인할 수 있도록 하기 위해 수행됩니다.
업그레이드할 스위치를 선택하고 서버 또는 호스트에 대한 다운링크 인터페이스를 비활성화합니다.
스위치를 새로운 Junos 버전으로 업그레이드하고 재부팅합니다. 스위치에서 새 버전을 실행하고 있는지 확인합니다.
EVPN 컨트롤 플레인을 확인하여 업그레이드된 스위치가 다운링크 호스트의 MAC 주소를 다시 학습했는지 확인합니다.
업그레이드된 스위치의 다운링크 인터페이스를 활성화합니다.
다른 스위치에서 3단계부터 6단계까지 반복하여 업그레이드를 완료합니다.
호스트 생성 ping을 중지하고 업그레이드 절차 중 손실된 패킷 수를 확인합니다.
참고:업그레이드 절차는 중단이 없습니다. 다운링크에서 전송 중인 패킷은 업그레이드 준비 과정에서 인터페이스가 비활성화될 때 손실될 수 있습니다. 인터페이스가 비활성화되면 트래픽은 다른 리프 스위치로 전환되고 계속 흐릅니다. 이 절차에서는 업그레이드 중인 각 스위치에서 LAG 멤버 인터페이스를 비활성화할 때 두 개의 작은 손실 창이 있습니다. 이러한 손실 기간은 50밀리초를 초과해서는 안 됩니다.
토폴로지
그림 1 은 이 EVPN 멀티호밍 업그레이드 예시의 토폴로지를 보여줍니다. 두 스위치 모두 연결된 호스트와 연결된 VLAN에 대해 구성된 IRB 인터페이스를 가지고 있습니다. 이러한 IRB는 192.168.0.1의 공유 가상 게이트웨이 주소로 구성됩니다. 호스트는 bond0 인터페이스에서 주소 192.1689.1.100이 할당됩니다. 이 다이어그램은 또한 호스트에 있는 bond0 인터페이스의 MAC 주소와 두 리프 스위치의 LAG 인터페이스에 구성된 ESI(Ethernet Segment Identifier)에 대해 자세히 설명합니다.
EVPN 멀티호밍 업그레이드 구성
업그레이드 준비
단계별 절차
EVPN 멀티호밍이 작동하는지 확인합니다. 서버에 로그인하고 본딩 인터페이스가 작동 중인지 확인합니다. 그 동안 bond0 인터페이스의 MAC 주소를 기록해 둡니다. 이 예에서는 호스트가 Ubuntu를 실행 중이므로
ifconfig
명령이 사용됩니다. Centos 배포판을ip link show bond0
사용하는 경우 명령을 사용합니다. 이 예에서 호스트의 bond0 인터페이스에 대한 MAC 주소는 00:1B:21:79:5A:EC입니다.root@server-host# ifconfig bond0 bond0 Link encap:Ethernet HWaddr 00:1B:21:79:5A:EC inet addr:192.168.100.100 Bcast:192.168.100.255 Mask:255.255.255.0 inet6 addr: fe80::21b:21ff:fe79:5aec/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:99980 errors:0 dropped:0 overruns:0 frame:0 TX packets:2997762 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:12393700 (11.8 MiB) TX bytes:371717722 (354.4 MiB)
명령을 사용하여 LAG 인터페이스가 두 리프 디바이스 모두에서 작동하는지 확인합니다
show interfaces ae1
. 이 예에서 LAG 인터페이스는 ae1 두 리프 디바이스 모두에 있습니다. 어그리게이션된 인터페이스 번호는 두 리프 디바이스 간에 달라질 수 있는 로컬 인덱스입니다. 인터페이스 이름이 아니라 일치하는 ESI 및system-id
매개 변수의 구성으로 두 리프 간의 LAG 인터페이스를 논리적으로 바인딩합니다. LAG 인터페이스가 두 리프 디바이스 모두에서 작동 중인지 확인해야 합니다.출력은 LAG 인터페이스가 작동하고 ESI가 양쪽 리프에서 00:01:01:01:01:01:01:01: 01:01로 구성되어 있음을 확인합니다.
root@leaf3> show interfaces ae1 Physical interface: ae1, Enabled, Physical link is Up Interface index: 640, SNMP ifIndex: 529 Link-level type: Ethernet, MTU: 1514, Speed: 10Gbps, BPDU Error: None, Ethernet-Switching Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled, Minimum links needed: 1, Minimum bandwidth needed: 1bps Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Current address: 10:0e:7e:b5:7e:f0, Hardware address: 10:0e:7e:b5:7e:f0 Ethernet segment value: 00:01:01:01:01:01:01:01:01:01, Mode: all-active Last flapped : 2020-05-06 21:44:35 UTC (1d 09:25 ago) Input rate : 960 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface ae1.0 (Index 550) (SNMP ifIndex 530) Flags: Up SNMP-Traps 0x24024000 Encapsulation: Ethernet-Bridge Statistics Packets pps Bytes bps Bundle: Input : 0 0 0 0 Output: 0 0 0 0 Adaptive Statistics: Adaptive Adjusts: 0 Adaptive Scans : 0 Adaptive Updates: 0 Protocol eth-switch, MTU: 1514 Flags: Is-Primary
root@leaf2> show interfaces ae1 Physical interface: ae1, Enabled, Physical link is Up Interface index: 640, SNMP ifIndex: 541 Link-level type: Ethernet, MTU: 1514, Speed: 10Gbps, BPDU Error: None, Ethernet-Switching Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled, Minimum links needed: 1, Minimum bandwidth needed: 1bps Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Current address: f4:b5:2f:44:af:30, Hardware address: f4:b5:2f:44:af:30 Ethernet segment value: 00:01:01:01:01:01:01:01:01:01, Mode: all-active Last flapped : 2020-05-08 05:58:07 UTC (01:22:18 ago) Input rate : 968 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface ae1.0 (Index 554) (SNMP ifIndex 542) Flags: Up SNMP-Traps 0x24024000 Encapsulation: Ethernet-Bridge Statistics Packets pps Bytes bps Bundle: Input : 0 0 0 0 Output: 0 0 0 0 Adaptive Statistics: Adaptive Adjusts: 0 Adaptive Scans : 0 Adaptive Updates: 0 Protocol eth-switch, MTU: 1514 Flags: Is-Primary
이전 단계에서 기록한 ESI 값을 사용하여 호스트 MAC 주소가 두 멤버 스위치의 EVPN 데이터베이스에 존재하는지 확인합니다.
root@leaf3> show evpn database | match esi 00:01:01:01:01:01:01:01:01:01 Instance: default-switch VLAN DomainId MAC address Active source Timestamp IP address 10100 00:1b:21:79:5a:ec 00:01:01:01:01:01:01:01:01:01 May 08 08:23:11 192.168.100.100
root@leaf3> show evpn database | match esi 00:01:01:01:01:01:01:01:01:01 Instance: default-switch VLAN DomainId MAC address Active source Timestamp IP address 10100 00:1b:21:79:5a:ec 00:01:01:01:01:01:01:01:01:01 May 07 22:06:11 192.168.100.100
두 리프 디바이스에 어그리게이션된 인터페이스 구성을 표시합니다.
hold-time up
옵션은 이 예의 권장 사항에 따라 6초 동안 구성됩니다.root@leaf3> show configuration interfaces ae1 esi { 00:01:01:01:01:01:01:01:01:01; all-active; } aggregated-ether-options { lacp { active; system-id 00:00:01:01:01:01; hold-time up 6000; } } unit 0 { family ethernet-switching { interface-mode access; vlan { members v100; } } }
root@leaf2> show configuration interfaces ae1 esi { 00:01:01:01:01:01:01:01:01:01; all-active; } aggregated-ether-options { lacp { active; system-id 00:00:01:01:01:01; hold-time up 6000; } } unit 0 { family ethernet-switching { interface-mode access; vlan { members v100; } } }
두 스위치의 LAG 멤버 인터페이스 이름을 기록해 둡니다. 업그레이드 중인 스위치에서 이 인터페이스를 종료해야 합니다. LAG 멤버 인터페이스 이름은 스위치 쌍 간에 달라지는 것이 일반적입니다. 이 예에서 LAG 멤버 인터페이스는 두 리프 디바이스 모두에서 xe-0/0/46입니다.
root@leaf3> show lacp interfaces Aggregated interface: ae1 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-0/0/46 Actor No No Yes Yes Yes Yes Fast Active xe-0/0/46 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-0/0/46 Current Slow periodic Collecting distributing . . .
root@leaf2# run show lacp interfaces Aggregated interface: ae1 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-0/0/46 Actor No No Yes Yes Yes Yes Fast Active xe-0/0/46 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-0/0/46 Current Slow periodic Collecting distributing . . .
그림 2와 같이 원하는 Junos OS 이미지를 두 리프 디바이스로 전송합니다. 스위치의 /var/tmp 디렉토리에 이미지를 배치해야 합니다. 일반적으로 FTP 또는 SCP는 리프 디바이스에 이미지를 복사하는 데 사용됩니다. CLI를 사용하여 파일을 복사하는 방법에 대한 자세한 내용은 파일 복사를 참조하십시오.
참고:업그레이드를 위한 충분한 공간이 있는지 확인하기 위해 새 이미지를 전송하기 전에 명령을 실행하는
request system storage cleanup
것이 좋습니다.그림 2: 새로운 Junos 이미지 전송EVPN 멀티호밍 리프 모두에서 시작 Junos OS 버전을 확인합니다. 이 예에서 시작 Junos OS 버전은 19.1R3.9입니다. 간결성을 위해 리프 2의 출력만 표시됩니다.
root@leaf2> show version localre: -------------------------------------------------------------------------- Hostname: leaf2 Model: qfx5100-48s-6q Junos: 19.1R3.9 JUNOS OS Kernel 64-bit [20200219.fb120e7_builder_stable_11] JUNOS OS libs [20200219.fb120e7_builder_stable_11] JUNOS OS runtime [20200219.fb120e7_builder_stable_11] JUNOS OS time zone information [20200219.fb120e7_builder_stable_11] JUNOS OS libs compat32 [20200219.fb120e7_builder_stable_11] JUNOS OS 32-bit compatibility [20200219.fb120e7_builder_stable_11] JUNOS py extensions [20200326.053318_builder_junos_191_r3] . . .
지금까지 수행된 단계는 LAG 인터페이스가 작동하고 EVPN 컨트롤 플레인이 수렴되었음을 나타냅니다. 업그레이드를 시작하기 전에 호스트에서 VLAN의 IRB 인터페이스에 할당된 가상 게이트웨이 IP 주소로 ping을 시작합니다. 이 트래픽은 하나의 멤버 링크 또는 다른 멤버 링크로 해시됩니다. 두 스위치가 동일한 가상 게이트웨이 IP로 구성되므로 호스트가 트래픽을 보내는 스위치는 중요하지 않습니다.
두 스위치 중 하나가 ping에 응답할 수 있다는 점에 유의해야 합니다. 즉, 한 스위치가 재부팅될 때 다른 스위치는 사용 가능한 상태로 유지되며 ping에 응답할 수 있습니다.
참고:ping이 성공하려면 IRB 인터페이스가 두 스위치 모두에서 옵션으로 구성되어
virtual-gateway-accept-data
있는지 확인해야 합니다.[root@serverhost ~]# ping 192.168.100.1 PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=3.80 ms 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=1.93 ms 64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=8.81 ms 64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=2.91 ms 64 bytes from 192.168.100.1: icmp_seq=5 ttl=64 time=1.34 ms 64 bytes from 192.168.100.1: icmp_seq=6 ttl=64 time=15.0 ms ...
손실된 총 패킷 수를 확인할 수 있도록 업그레이드 절차 전반에 걸쳐 호스트-IRB 인터페이스 ping이 계속 실행되는지 확인합니다.
리프 3 업그레이드
단계별 절차
그림 3의 빨간색 "X"와 같이 LAG 멤버 xe-0/0/46을 향하는 서버를 종료하여 Leaf 3에서 업그레이드 프로세스를 시작합니다.
참고:이 단계에서 리프 3의 xe-0/0/46 인터페이스에서 전송 중인 소수의 패킷이 손실될 수 있습니다. 이때 Ping 트래픽은 업그레이드가 완료될 때까지 리프 2 디바이스를 통해 흐르고 리프 3에서 다운링크 인터페이스를 다시 활성화합니다.
그림 3: 리프 3 에서 다운링크 인터페이스 비활성화[edit interface xe-0/0/46] root@leaf3# set disable
[edit interface xe-0/0/46] root@leaf3# commit and-quit
콘솔 연결을 사용하여 명령을 사용하여 리프 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 업그레이드 시작스위치 재부팅 후 업그레이드가 성공했는지 확인합니다.
root@leaf3> show version localre: -------------------------------------------------------------------------- Hostname: leaf3 Model: qfx5100-48s-6q Junos: 19.2R1.8 JUNOS OS Kernel 64-bit [20190517.f0321c3_builder_stable_11] JUNOS OS libs [20190517.f0321c3_builder_stable_11] JUNOS OS runtime [20190517.f0321c3_builder_stable_11] JUNOS OS time zone information [20190517.f0321c3_builder_stable_11] JUNOS OS libs compat32 [20190517.f0321c3_builder_stable_11] JUNOS OS 32-bit compatibility [20190517.f0321c3_builder_stable_11] JUNOS py extensions [20190621.152752_builder_junos_192_r1] JUNOS py base [20190621.152752_builder_junos_192_r1] JUNOS OS vmguest [20190517.f0321c3_builder_stable_11] JUNOS OS crypto [20190517.f0321c3_builder_stable_11] . . .
이때 모든 언더레이 및 오버레이 BGP 세션을 다시 설정해야 합니다. 리프 3에서 지연 멤버 인터페이스를 활성화하기 전에 모든 BGP 피어가 백업되고 EVPN 컨트롤 플레인이 다시 수렴되었는지 확인합니다.
root@leaf3> show evpn database esi 00:01:01:01:01:01:01:01:01:01 Instance: default-switch VLAN DomainId MAC address Active source Timestamp IP address 10100 00:1b:21:79:5a:ec 00:01:01:01:01:01:01:01:01:01 May 08 08:40:33 192.168.100.100
그림 5의 녹색 확인 표시로 표시된 것처럼 리프 3에서 다운링크 인터페이스를 활성화합니다.
그림 5: 리프 3 에서 다운링크 인터페이스 활성화[edit interface xe-0/0/46] root@leaf3# delete disable
[edit interface xe-0/0/46] root@leaf3# commit and-quit
리프2 업그레이드
단계별 절차
그림 6의 빨간색 X로 표시된 것처럼 다운링크 인터페이스를 비활성화하여 리프 2에서 업그레이드 절차를 시작합니다. ping이 리프 2를 통해 흐를 가능성이 높기 때문에 이 단계는 절차에서 두 번째 손실 창을 표시합니다. 리프 2를 업그레이드할 때 핑은 리프 3 디바이스를 통해 계속 흘러야 합니다.
그림 6: leaf2 에서 다운링크 인터페이스 비활성화[edit interface xe-0/0/46] root@leaf2# set disable
[edit interface xe-0/0/46] root@leaf2# commit and-quit
이미지 로드를 시작하고 명령을 사용하여 리프 2에서 재부팅합니다
request system software add /var/tmp/jinstall-host-qfx-5e-x86-64-19.2R1.8-secure-signed.tgz
. 리프 2의 업그레이드 및 재부팅은 그림 7의 톱니바퀴 아이콘과 같습니다.그림 7: 리프 2 에서 업그레이드 시작리프 2 재부팅 후 Junos OS 버전을 확인하여 업그레이드가 성공했는지 확인합니다.
root@leaf2> show version localre: -------------------------------------------------------------------------- Hostname: leaf2 Model: qfx5100-48s-6q Junos: 19.2R1.8 JUNOS OS Kernel 64-bit [20190517.f0321c3_builder_stable_11] JUNOS OS libs [20190517.f0321c3_builder_stable_11] JUNOS OS runtime [20190517.f0321c3_builder_stable_11] JUNOS OS time zone information [20190517.f0321c3_builder_stable_11] JUNOS OS libs compat32 [20190517.f0321c3_builder_stable_11] JUNOS OS 32-bit compatibility [20190517.f0321c3_builder_stable_11] JUNOS py extensions [20190621.152752_builder_junos_192_r1] JUNOS py base [20190621.152752_builder_junos_192_r1] JUNOS OS vmguest [20190517.f0321c3_builder_stable_11] JUNOS OS crypto [20190517.f0321c3_builder_stable_11] . . .
EVPN 컨트롤 플레인이 리프 2에서 재수렴되었는지 확인합니다. 모든 BGP 세션이 다시 설정되고 호스트의 MAC 주소가 EVPN 데이터베이스에 채워지는 데 몇 분 정도 걸릴 수 있습니다.
root@leaf2> show evpn database esi 00:01:01:01:01:01:01:01:01:01 Instance: default-switch VLAN DomainId MAC address Active source Timestamp IP address 10100 00:1b:21:79:5a:ec 00:01:01:01:01:01:01:01:01:01 May 08 08:53:30
그림 8의 녹색 확인 표시로 표시된 것처럼 리프 2에서 LAG 멤버 인터페이스를 활성화합니다.
그림 8: 리프 2 에서 다운링크 인터페이스 활성화[edit interface xe-0/0/46] root@leaf2# delete disable
[edit interface xe-0/0/46] root@leaf2# commit and-quit
이제 두 스위치가 모두 업그레이드되었으며 모든 LAG 멤버 인터페이스가 다시 작동합니다. 업그레이드 프로세스 중 트래픽 중단을 측정하려면 ping을 중지하고 ping 통계를 기록해 두십시오. 이 예에서는 멀티홈 호스트를 지원하는 리프 디바이스 쌍을 업그레이드하는 동안 총 2개의 패킷이 손실됩니다.
대부분의 경우 진행 중인 ping이 중단되면 단일 패킷의 손실이 표시됩니다. 실제로 손실된 패킷이 1개이든 2개이든 관계없이 업그레이드는 사실상 무중단으로 간주됩니다. 이는 이 예에 설명된 절차의 기대치에 따른 것입니다.
[root@serverhost ~]# ping 192.168.100.1 ... 64 bytes from 192.168.100.1: icmp_seq=1621 ttl=64 time=0.465 ms 64 bytes from 192.168.100.1: icmp_seq=1622 ttl=64 time=7.52 ms 64 bytes from 192.168.100.1: icmp_seq=1623 ttl=64 time=0.920 ms 64 bytes from 192.168.100.1: icmp_seq=1624 ttl=64 time=8.48 ms 64 bytes from 192.168.100.1: icmp_seq=1625 ttl=64 time=9.89 ms 64 bytes from 192.168.100.1: icmp_seq=1626 ttl=64 time=8.95 ms 64 bytes from 192.168.100.1: icmp_seq=1627 ttl=64 time=1.85 ms ^C --- 192.168.100.1 ping statistics --- 1627 packets transmitted, 1625 received, 0% packet loss, time 1628654ms rtt min/avg/max/mdev = 0.260/8.371/87.282/11.096 ms
결론
EVPN 멀티호밍은 고성능 및 고가용성을 모두 지원해야 하는 데이터센터 아키텍처에서 중요한 기능입니다. 이 예에서는 중단을 최소화하면서 멀티홈 호스트 연결을 지원하는 한 쌍의 리프 스위치를 업그레이드하는 데 필요한 구성과 단계를 설명했습니다.