이 페이지 내용
구성 연습
이 연습에서는 주니퍼 Apstra JVD로 3단계 패브릭을 구성하는 데 필요한 단계를 요약합니다. 자세한 단계별 구성 정보는 주니퍼 Apstra 사용자 가이드를 참조하십시오. 이 연습의 추가 지침은 메모 형식으로 제공됩니다.
이 연습에서는 주니퍼 데이터센터 검증 테스트 랩에서 검증하는 동안 사용되는 기본 설계의 구성을 자세히 설명합니다. 기본 설계는 스파인 역할의 QFX5220-32CD 스위치, 경계 리프 역할의 QFX5130-32CD 스위치, 서버 리프 역할의 QFX5120-48Y 스위치로 구성됩니다. JVD의 목표는 지원되는 디바이스 및 포지셔닝 표 1에 설명된 대로 이러한 스위치 플랫폼을 해당 역할에 대한 검증된 스위치 플랫폼으로 대체할 수 있도록 옵션을 제공하는 것입니다. 이 연습을 관리 가능한 길이로 유지하기 위해 이 문서의 목적에는 기준 디자인 플랫폼만 사용됩니다.
Apstra: Apstra 서버 및 Apstra ZTP 서버 구성
이 문서에서는 Apstra 설치에 대해 다루지 않습니다. 설치에 대한 자세한 내용은 주니퍼 Apstra 사용자 가이드를 참조하십시오.
첫 번째 단계는 Apstra 서버를 구성하는 것입니다. Apstra 서버 VM에 처음 연결하면 구성 마법사가 시작됩니다. 이제 Apstra 서버, Apstra UI 및 네트워크 구성에 대한 암호를 구성할 수 있습니다.
Apstra: Junos OS 디바이스 관리
주니퍼 디바이스를 Apstra에 추가하는 방법에는 수동으로 또는 ZTP를 사용하여 대량으로 추가하는 두 가지 방법이 있습니다.
장치를 수동으로 추가하려면(권장):
Apstra UI에서 디바이스 > 에이전트 > 오프박스 에이전트 생성으로 이동합니다.
이를 위해서는 디바이스에서 구성할 루트 암호 및 관리 IP의 최소 구성이 필요합니다.
ZTP를 통해 디바이스를 추가하려면:
Apstra ZTP 서버에서 디바이스를 추가하려면 주니퍼 디바이스의 ZTP에 대한 자세한 내용은 주니퍼 Apstra 사용자 가이드를 참조하십시오.
이 설정에서는 디바이스를 Apstra에 추가하기 전에 루트 암호와 관리 IP가 모든 스위치에 이미 구성되어 있었습니다. Apstra에 스위치를 추가하려면 먼저 Apstra 웹 UI에 로그인하고, 위와 같이 디바이스 추가 방법을 선택하고, 해당 디바이스에 대해 사전 구성된 적절한 사용자 이름과 암호를 제공합니다.
Apstra는 주니퍼 디바이스에서 깨끗한 구성이라고 하는 구성을 가져옵니다. Junos 구성 'groups' 스탠자는 기본 구성을 가져올 때 무시되며, Apstra는 상속 모델에 나열된 그룹 구성을 검증하지 않습니다(Use Configuration Groups to Rapid Configure Devices 참조). 그러나 루프백, 인터페이스(관리 인터페이스 제외), routing-instances(management-instance 제외)는 설정하지 않는 것이 가장 좋습니다. Apstra는 디바이스가 성공적으로 승인되면 프로토콜 LLDP 및 RSTP를 설정합니다.
Apstra 웹 UI: 에이전트 프로필 생성
이 JVD 실습의 목적을 위해 루트 사용자와 암호는 모든 디바이스에서 동일합니다. 따라서 에이전트 프로필이 아래와 같이 생성됩니다. 이렇게 하면 암호도 가려져 안전하게 유지됩니다.
- 디바이스(Devices) > 에이전트 프로필(Agent Profiles)로 이동합니다.
- 상담원 프로필 만들기를 클릭합니다.
에서 에이전트 프로필 생성
Apstra 웹 UI: 디바이스 대량 검색을 위해 IP 주소 또는 IP 주소 범위를 입력합니다
디바이스를 Apstra에 대량으로 추가하려면 IP 주소 범위를 제공할 수 있습니다.
- Devices > Agents(디바이스) Agents(에이전트)로 이동합니다.
- Offbox 에이전트 만들기를 클릭합니다.
만들기
Apstra 웹 UI: 기본 구성 추가 및 Junos OS 업그레이드
Devices > Managed Devices에서 디바이스에서 수집하거나 Apstra에서 푸시하여 원시 구성을 추가합니다. 기본 구성의 일부로 적용되는 구성은 사용자, 관리 스위치에 대한 고정 경로 등을 추가하여 디바이스에 도달하는 데 필요한 기본 구성 또는 최소 구성이어야 합니다. 이렇게 하면 Apstra에 기본 구성의 백업이 생성되고 문제 발생 시 디바이스를 원래 구성으로 되돌릴 수 있습니다.
추가
위의 그림 3 과 같이 Apstra를 사용하여 기본 구성을 업데이트하면 Revert to Pristine을 실행해야 합니다. 중요: 업그레이드가 중단될 수 있으므로 모든 디바이스 업그레이드를 수행하려면 유지 관리 기간이 필요합니다. 업그레이드를 위한 모범 사례 권장 사항:Apstra는 현재 기본 업그레이드 검사만 수행하므로 Junos OS 소프트웨어 설치 및 업그레이드 가이드와 Junos OS 버전 릴리스 노트에 설명된 대로 Junos OS CLI를 사용하여 디바이스를 업그레이드하십시오. 그러나 이 JVD는 Apstra를 업그레이드에 사용할 경우 업그레이드 단계를 요약합니다. 장치가 청사진에 추가된 경우 장치를 "배포 취소"로 설정하고 청사진에서 일련 번호 할당을 취소하고 변경 사항을 커밋하면 원래 구성으로 되돌아갑니다. 그런 다음 업그레이드를 진행합니다. 업그레이드가 완료되면 디바이스를 블루프린트에 다시 추가합니다.
Apstra를 사용하면 디바이스를 업그레이드할 수 있습니다. 그러나 Apstra는 기본 검사를 수행하고 업그레이드 명령을 실행합니다. Apstra에서 디바이스를 업그레이드하려면 다음 그림을 참조하십시오.
에서 디바이스 업그레이드
Apstra에 Junos OS 이미지를 등록하려면 모든 OS 이미지가 저장되어 있는 리포지토리에 대한 링크를 제공하거나 아래와 같이 OS 이미지를 업로드하십시오. Apstra UI에서 Devices > OS Images 로 이동하고 Register OS Images를 클릭합니다.
업로드
제공
Apstra 패브릭 프로비저닝
검색된 장치를 확인하고 장치를 승인합니다.
디바이스 > 매니지드 디바이스
오프박스 에이전트가 추가되고 디바이스 정보가 수집되면 확인란 인터페이스를 클릭하여 모든 디바이스를 선택한 다음 승인을 클릭합니다. 이에 따라 스위치는 Apstra 서버의 관리 하에 위치하게 됩니다.
마지막으로, Apstra가 LLDP 및 RSTP에 대한 구성을 추가할 때 원래 구성이 다시 한 번 수집되도록 보장합니다.
에서 관리할 디바이스 승인
스위치가 승인되면 "승인되었습니까?" 테이블 헤더 아래의 상태 아이콘이 빨간색 X에서 녹색 확인 표시로 바뀝니다. 모든 스위치에 대해 이 변경 사항을 확인합니다. 변경 사항이 없으면 절차를 반복하여 스위치를 다시 확인합니다.
에서 관리하는 디바이스
Apstra에서 디바이스를 관리한 후에는 Apstra를 사용하여 모든 디바이스 구성 변경을 수행해야 합니다. Apstra가 변경 사항을 되돌릴 수 있으므로 Apstra 외부 디바이스에서 구성 변경을 수행하지 마십시오.
Apstra 웹 UI: 논리적 디바이스 식별 및 생성, 디바이스 프로파일을 이용한 인터페이스 맵
다음 단계에서는 주니퍼 Apstra 기본 아키텍처 및 디바이스로 3단계 패브릭을 정의합니다. Blueprint를 프로비저닝하기 전에 토폴로지의 복제본이 생성됩니다. 다음 단계에서는 ERB 데이터센터 참조 아키텍처 및 장치를 정의합니다.
- 여기에는 스파인, 리프 및 경계 리프 스위치에 대한 논리적 디바이스를 선택하는 작업이 포함됩니다. 논리적 디바이스는 물리적 디바이스의 추상화로서 포트의 양, 속도 및 역할과 같은 일반적인 디바이스 폼 팩터를 지정합니다. 공급업체별 정보는 포함되지 않으므로 공급업체 및 하드웨어 디바이스 모델을 선택하기 전에 네트워크 정의를 구축할 수 있습니다. Apstra 소프트웨어 설치에는 논리적 디바이스의 변형을 생성하는 데 사용할 수 있는 여러 사전 정의된 논리적 디바이스가 포함됩니다.
- 그런 다음 논리 디바이스는 인터페이스 맵을 사용하여 디바이스 프로파일에 매핑됩니다. 인터페이스 맵에 매핑된 포트는 디바이스 프로파일 및 물리적 디바이스 연결과 일치합니다. 다시 말하지만, Apstra 소프트웨어 설치에는 많은 사전 정의된 인터페이스 맵과 디바이스 프로필이 포함됩니다.
- 마지막으로, 랙과 템플릿은 구성된 논리적 디바이스 및 디바이스 프로파일을 사용하여 정의되며, 이는 청사진을 생성하는 데 사용됩니다.
주니퍼 Apstra 사용자 가이드는 Apstra 청사진 및 디바이스로 작업할 때 이해해야 하는 디바이스 라이프사이클에 대해 설명합니다.
3단계 설계 프로비저닝 단계에서는 Apstra 데이터센터 참조 설계를 사용합니다.
Design > Logical Devices(논리적 디바이스 설계)로 이동한 다음 포트 수와 포트 속도에 따라 나열된 디바이스를 검토합니다. 추가해야 하는 장치와 가장 유사한 장치를 선택한 다음 논리적 장치를 복제합니다.
시스템 추가 또는 기본 논리 장치는 변경할 수 없습니다.
다음 표에는 이 문서에서 주니퍼 Apstra JVD를 사용한 3단계 패브릭 랩을 위해 생성된 디바이스 역할, 논리적 디바이스 유형, 포트 및 연결이 나와 있습니다. Port Groups(포트 그룹) 열은 이 실습에 필요한 최소 연결을 나타냅니다. 이는 이러한 스위치가 제공할 수 있는 실제 포트 그룹과 다릅니다.
| 디바이스 역할 | 포트 그룹 연결1 | 포트 그룹2 | 연결 대상 |
|---|---|---|---|
| 척주 | 슈퍼스파인/스파인/리프/액세스/일반 | 5 x 100Gbps(각 스파인) | 경계 리프 스위치 2개 서버 리프 스위치 3개 |
| 서버 리프(단일) | 슈퍼스파인/스파인/리프/액세스/일반 | 2 x 100Gbps 5 x 10Gbps |
2 척추 2 서버(일반) |
| 서버 리프 스위치(ESI 리프 스위치 2개) | 슈퍼스파인/스파인/리프/액세스/일반 | 4 x 100Gbps(두 리프 스위치 모두) 5 X 10Gbps |
2 척추 4 서버(일반) |
| 경계 리프 스위치 | 슈퍼스파인/스파인/리프/액세스/일반 | 6 X 10Gbps 4 x 100Gbps(두 리프 스위치 모두) |
6 서버 2 척추 |
1 포트 그룹 연결의 경우 연결된 역할 및 디바이스에 따라 달라질 수 있습니다.
2 포트 그룹의 경우 포트 수는 연결 및 속도에 따라 달라질 수 있습니다.
디바이스 프로필
이 문서에서 다루는 모든 디바이스의 디바이스 프로필( 디바이스 > 디바이스 프로필 아래에 있는 Apstra에 정의됨)은 Apstra: 디바이스 관리에서 다룬 대로 디바이스를 Apstra에 추가하는 동안 Apstra와 정확히 일치Junos OS. 지원되는 디바이스를 검증하는 동안 디바이스의 라인 카드 설정에 맞게 디바이스 프로필을 맞춤 제작해야 하는 경우가 있습니다(예: QFX5700). 디바이스 프로필에 대한 자세한 내용은 디바이스 프로필에 대한 Apstra 사용자 가이드를 참조하십시오.
에 연결된 QFX5700 디바이스 프로필
에 연결된 디바이스 프로필 QFX5700
스파인 논리적 디바이스 및 해당 인터페이스 맵
스파인 논리적 디바이스는 QFX5220-32CD(Junos OS)를 기반으로 합니다. 이 솔루션의 목적을 위해 리프 스위치 연결에 7개의 100G 링크가 사용됩니다. 그림 11 에 나와 있듯이 100Gbps의 포트 12개면 5개의 스파인-리프 연결에 충분합니다.
스파인 논리적 디바이스 포트는 아래와 같이 인터페이스 맵을 사용하여 디바이스 프로필에 매핑됩니다. 인터페이스 맵에 매핑된 포트는 디바이스 프로파일 및 물리적 디바이스 연결과 일치합니다.
서버 리프 스위치 논리적 디바이스 및 인터페이스 맵
이 JVD에는 3개의 QFX5120-48Y 서버 리프 스위치가 있습니다. 그 중 두 개는 ESI 지원 스위치이고 그 중 하나는 비 ESI LAG 스위치입니다. 3개의 서버 리프 스위치는 모두 100GB 인터페이스를 사용하여 각 스파인에 연결되며 10GB 인터페이스는 일반 서버에 연결됩니다.
단일(중복되지 않은) 리프 스위치의 경우 ESI가 사용되지 않고 LACP(활성)만 구성됩니다.
ESI(이중화) 리프 스위치의 경우 ESI Lag는 멀티호밍에 사용됩니다. ESI LAG는 Design > Rack Types의 Rack 아래에 구성됩니다.
서버 리프 논리 장치는 아래와 같이 장치 프로파일에 매핑됩니다.
용 서버 리프 스위치 인터페이스 맵
이 경우 단일 리프 및 ESI 서버 리프 쌍은 모두 동일한 장치 프로필을 가지고 있지만 스위치의 물리적 포트가 서버와 스파인을 향해 연결되는 방식의 차이로 인해 두 개의 다른 논리 장치가 설계되었습니다.
경계 리프 스위치 논리적 디바이스 및 인터페이스 맵
경계 리프 논리적 디바이스는 이 설계에 사용된 QFX5130-32CD 스위치를 표현한 것입니다. 물리적 케이블 연결은 인터페이스 맵에 할당된 포트를 결정합니다.
나머지 논리적 디바이스는 아래에 설명되어 있습니다. 인터페이스 맵은 선택 사항이며 생략할 수 있습니다.
일반 서버 논리적 디바이스
일반 서버는 리프 스위치(경계 및 단일)에 연결된 서버로부터의 네트워크 인터페이스 연결을 정의합니다.
사용되는 서버의 논리적 디바이스는 Apstra 내에 이미 사전 정의되어 있습니다. 유사한 일반 시스템이 DCI에 사용될 수 있습니다. 그러나 DCI는 별도의 JVD 확장 문서에서 다룹니다.
외부 라우터
외부 라우터는 경계 리프 스위치에 연결됩니다.
Apstra는 MX 시리즈 디바이스와 같은 외부 라우터를 관리하지 않습니다. 따라서, MX 시리즈 라우터는 관련 포트 및 속도 구성을 가진 외부 일반 서버로 분류됩니다.
일반 외부 시스템은 Blueprint가 생성된 후 Blueprint에 추가됩니다. 인터페이스 맵은 일반 서버 또는 외부 라우터에 필요하지 않습니다. 외부 라우터의 연결 및 기능은 이 문서의 범위를 벗어납니다.
Apstra 웹 UI: 랙, 템플릿 및 청사진 - 랙 생성
논리적 디바이스와 인터페이스 맵을 정의한 후 다음 단계는 랙을 생성하여 논리적 디바이스를 랙 형태로 배치하는 것입니다. 이 솔루션의 기본 설계는 스파인 2개, 서버 리프 스위치 5개, 경계 리프 스위치 2개입니다. 스파인 스위치에 이를 지원하는 충분한 포트가 있는 한 어떤 랙 설계든 여러 번 생성하여 사용할 수 있습니다.
Apstra에서 Design > Rack Types(랙 유형) 아래에 랙을 생성합니다. 이 솔루션에는 4개의 랙이 있습니다. 경계 리프 스위치용 랙 1개 및 서버 리프 스위치용 랙 3개. 랙 생성에 대한 자세한 내용은 주니퍼 Apstra 사용자 가이드를 참조하십시오.
이 설계의 경우 L3 Clos 랙 구조는 다음과 같습니다.
서버 리프 스위치(단일 리프)
가 없는 단일 리프 랙
서버 리프 스위치(리프 스위치 2개)
경계 리프 스위치
Blueprint가 생성되고 작동한 후 랙을 변경해야 하는 경우 KB 문서 https://supportportal.juniper.net/s/article/Juniper-Apstra-How-to-change-Leaf-Access-Switch-of-existing-rack-after-Day2-operations?language=en_US 를 따르십시오. 검증 과정에서 경계 리프 랙이 수정되어 표 5에 나열된 모든 디바이스를 검증했습니다.
템플릿 만들기
템플릿은 네트워크의 구조와 인텐트를 정의합니다. 랙을 생성한 후에는 스파인 링크를 각 랙에 연결해야 합니다. 이 설계에서 랙 기반 템플릿을 사용하여 랙을 랙 상단(ToR) 스위치(또는 ToR 스위치 쌍)로 연결합니다.
스파인 논리적 디바이스 섹션에 설명된 대로 각 서버 리프 및 경계 리프에 할당된 100G 링크가 있습니다. 스파인 논리적 디바이스가 템플릿에 할당됩니다. 이 디자인에는 슈퍼 스파인이 없기 때문에 템플릿에서 제외됩니다. 템플릿에 대한 자세한 내용은 주니퍼 Apstra 사용자 가이드를 참조하십시오.
템플릿은 블루프린트를 생성하기 위한 기반으로 사용되며, 이에 대해서는 다음 섹션에서 설명합니다. 템플릿은 Blueprint 수명 동안 한 번만 사용됩니다. 따라서 템플릿을 변경해도 블루프린트는 수정되지 않습니다.
있는 DC 랙 기반 템플릿
청사진
각 청사진은 데이터센터를 나타냅니다. 템플릿은 템플릿 설계 > 섹션에서 생성되며 Blueprint에 대한 글로벌 카탈로그에서 사용할 수 있습니다. 템플릿이 정의되면 이를 사용하여 데이터센터의 청사진을 생성할 수 있습니다.
Blueprint를 생성하려면 Blueprint > Create Blueprint를 클릭합니다. 블루프린트 생성에 대한 자세한 내용은 주니퍼 Apstra 사용자 가이드를 참조하세요.
을 사용하여 블루프린트 생성
청사진(Blueprint) > 준비됨(Staged)으로 이동합니다. 표시된 토폴로지를 확장하여 모든 연결을 볼 수 있습니다. 여기에서 Staged에서 블루프린트를 프로비저닝할 수 있습니다.
않음
위에 표시된 대로 Blueprint가 생성되지만 프로비저닝되지는 않습니다. 토폴로지에 불일치가 있는지 검사할 수 있으며, 불일치가 있는 경우 템플릿 또는 랙을 수정한 후 블루프린트를 다시 생성할 수 있습니다. 또는 Staged > Racks 로 이동하여 이 문서에 언급된 단계에 따라 랙을 편집합니다.
Apstra 웹 UI: 네트워크 프로비저닝 및 정의
청사진이 생성되면 청사진을 스테이징할 준비가 되었음을 의미합니다. 생성된 청사진 아래의 탭을 검토합니다.
프로비저닝을 시작하려면 Staged 탭을 > Physical(물리적 )을 클릭한 다음 오른쪽 패널에서 Build(빌드)를 클릭합니다. 자세한 정보는 주니퍼 Apstra 사용자 가이드를 참조하십시오.
중인 리소스 할당
자원 배정
첫 번째 단계는 이 리소스 섹션에서 만든 IP를 할당하는 것입니다. 이 디자인의 경우 사용되는 리소스 값은 다음과 같습니다.
- Staged > Physical > Build > Resources를 클릭하고 아래와 같이 업데이트합니다.
- DC1 ASN—스파인 및 리프 스위치: 64512 - 64999
- 루프백 IP—스파인 및 리프 스위치: 192.168.255.0/24
- 링크 IP—스파인 <> 리프 스위치: MUST-FABRIC-Interface-IPs DC1-10.0.1.0/24
리소스
스위치에 인터페이스 맵 할당
청사진에서 Staged > Physical > Build > Device Profiles)로 이동합니다.
그런 다음 이 문서의 Apstra 웹 UI: 논리 디바이스 식별 및 생성, 디바이스 프로파일을 사용한 인터페이스 맵 섹션에서 생성된 인터페이스 맵에 디바이스를 할당합니다.
인터페이스 맵
일반 시스템 또는 서버에 인터페이스 맵을 할당하는 것은 선택 사항입니다. 이러한 매개변수의 상태는 RED로 표시되며 선택 사항으로도 표시됩니다.
시스템 ID 및 올바른 관리 IP를 할당합니다
청사진에서 Staged > Physical > Build > Devices 로 이동하고 Assigned System IDs(할당된 시스템 ID)를 클릭합니다. 시스템 ID는 디바이스 일련 번호입니다.
아래의 시스템 ID 할당
각 노드 또는 디바이스에 대한 디바이스 호스트 이름과 표시 이름(Apstra에서)이 다르며, 이는 Apstra에서 관리되지 않으므로 시스템 ID가 일반 서버 및 외부 라우터에 할당될 Apstra.No 이를 사용하여 변경할 수 있습니다.
시스템 ID(디바이스의 일련 번호)를 할당하기 전에 디바이스 > 매니지드 디바이스 아래의 Apstra에 모든 디바이스가 추가되었는지 확인합니다.
케이블 연결 검토
Apstra는 물리적 케이블과 동일하지 않을 수 있는 디바이스의 케이블 연결 포트를 자동으로 할당합니다. 그러나 Apstra에서 할당한 케이블링은 재정의하고 변경하여 실제 케이블 연결을 나타낼 수 있습니다. 이 작업은 청사진에 액세스하여 Staged > 물리적 > 링크로 이동한 다음 Edit Cabling Map 버튼을 클릭하여 수행할 수 있습니다. 자세한 정보는 주니퍼 Apstra 사용자 가이드를 참조하십시오.
및 편집
일반 서버를 포함한 스위치 이름을 검토하여 이름이 일치하는지 확인하는 것이 가장 좋습니다. 장치 이름을 검토하고 수정하려면 Staged > Physical > Node 로 이동하고 나열된 장치 이름을 클릭하여 그림 33과 같이 장치 속성, 태그 등을 보여주는 오른쪽 패널과 함께 장치에 대한 토폴로지 및 연결이 포함된 화면을 표시합니다 .
검토
Configlet 및 속성 세트
Configlet은 글로벌 카탈로그의 Design > Configlets에 정의된 구성 템플릿입니다. 구성 요소는 Apstra의 인텐트 기반 기능으로 관리되지 않으며 수동으로 관리해야 합니다. configlet을 사용하지 말아야 하는 경우에 대한 자세한 내용은 주니퍼 Apstra 사용자 가이드를 참조하십시오. 레퍼런스 설계 구성을 대체하는 데 컨피글렛을 사용해서는 안 됩니다. Configlet은 Junos 구성 JSON 스타일 또는 Junos 세트 기반 구성과 같은 구성 스니펫의 Jinja 템플릿으로 선언할 수 있습니다. 구성 집합 설계에 대한 자세한 내용은 Apstra 구성 집합 사용 설명서를 참조하십시오.
잘못 구성된 구성틀은 경고나 제한을 발생시키지 않을 수 있습니다. 별도의 전용 서비스에서 구성틀을 테스트하고 검증하여 구성이 의도한 대로 정확하게 수행되도록 하는 것이 좋습니다. 암호 및 기타 비밀 키는 구성 요소에서 암호화되지 않습니다.
속성 집합은 장치 속성을 정의하는 데이터 집합입니다. 구성 집합 및 분석 프로브와 함께 작동합니다. 속성 집합은 글로벌 카탈로그의 디자인 > 속성 집합 아래에 정의되어 있습니다.
Freeform Blueprint의 구성 템플릿도 속성 세트를 사용하지만 설계 카탈로그의 속성 세트와는 관련이 없습니다.
글로벌 카탈로그에 정의된 구성 집합 및 속성 집합은 필요한 청사진으로 가져와야 하며, 구성 집합이 수정되면 속성 집합의 경우와 마찬가지로 동일한 구성 집합을 청사진으로 다시 가져와야 합니다. 다음 그림에서는 Blueprint에 있는 구성 집합 및 속성 집합을 보여 줍니다.
로 Configlet 가져오기
로 프로퍼티 세트 임포트
3단계 검증 과정에서 설정 및 관리 목적(예: 네임서버, NTP 등)을 위한 일반 구성의 일부로 몇 가지 구성 요소가 적용되었습니다.
패브릭 설정
패브릭 정책
이 옵션을 사용하면 MTU, IPv6 애플리케이션 지원 및 경로 옵션과 같은 다양한 매개 변수를 패브릭 전체에 설정할 수 있습니다. 이 JVD의 경우 다음 매개 변수가 사용되었습니다. Apstra UI 내에서 패브릭 정책 > 패브릭 설정을 > 블루 프린트 내에서 이러한 설정을 보고 수정합니다.
- 데이터 센터에서 보통 트래픽을 시뮬레이션하기 위해 트래픽 확장 테스트가 수행되었습니다 자세한 내용은 표 6 을 참조하십시오. 스케일 테스트는 QFX5120-48Y 스위치에서 수행되었습니다.
Junos EVPN 다음 홉 및 인터페이스 수 최대값 설정도 활성화되어 Apstra가 관련 구성을 적용하여 리프 스위치에서 허용되는 EVPN 오버레이 다음 홉 및 물리적 인터페이스의 최대 수를 데이터센터 패브릭에 적합한 수로 최적화할 수 있습니다. 이와 함께 configlet은 그림 37과 같이 레이어 2 및 레이어 3 항목에 대한 균형 잡힌 메모리 할당을 설정하는 데에도 사용됩니다.
이러한 기능에 대한 자세한 내용은 다음을 참조하십시오.
- https://www.juniper.net/documentation/us/en/software/junos/multicast-l2/topics/topic-map/layer-2-forwarding-tables.html
- https://www.juniper.net/documentation/us/en/software/junos/evpn-vxlan/Other/interface-num-edit-forwarding-options.html
- https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/next-hop-edit-forwarding-options-vxlan-routing.html
QFX5120 리프 스위치 구성의 경우:
{master:0} root@dc1-esi-001-leaf1> show configuration forwarding-options | display set set forwarding-options vxlan-routing next-hop 45056 set forwarding-options vxlan-routing interface-num 8192 set forwarding-options vxlan-routing overlay-ecmp {master:0} root@dc1-esi-001-leaf1> show configuration chassis forwarding-options | display set set chassis forwarding-options l2-profile-three그림 37: 균형 메모리
를 위한 리프 스위치의 Configlet
- 비 EVO 리프 스위치의 경우 Junos EVPN 라우팅 인스턴스 모드 설정도 활성화되었습니다. 이는 Apstra가 Apstra 4.2의 모든 새로운 청사진에 적용하는 기본 설정이기 때문입니다. Apstra 4.2 이전에 생성된 모든 청사진의 경우, 비 EVO 스위치에 대한 기본 스위치의 Apstra 사후 업그레이드가 허용됩니다. 그러나 MAC-VRF는 Junos OS와 Junos OS Evolved의 혼합 설정에서 구성을 정규화하는 것이 좋습니다. MAC-VRF용 VLAN 인식 라우팅 인스턴스 'evpn-1'은 비 EVO Junos 디바이스에 대해서만 생성됩니다. Junos OS Evolved는 MAC-VRF만 지원할 수 있고 기본적으로 이미 구현되어 있으므로 이 옵션은 Junos OS Evolved 디바이스에 영향을 미치지 않습니다.
블루프린트가 라이브 상태이고 운영 네트워크에서 실행 중인 경우, 유지보수 기간 동안 MAC-VRF 라우팅 인스턴스 모드에 대한 위의 설정 변경을 수행하는 것이 좋으며, 이는 중단이 되고 비 EVO Junos 리프 스위치(이 경우 QFX5120s)의 '재부팅'이 필요하기 때문입니다.
QFX5120 리프 스위치 구성의 경우:
{master:0}
root@dc1-esi-001-leaf1> show configuration forwarding-options | display set
set forwarding-options evpn-vxlan shared-tunnels
{master:0}
root@dc1-esi-001-leaf1> show configuration routing-instances evpn-1 | display set
set routing-instances evpn-1 instance-type mac-vrf
set routing-instances evpn-1 protocols evpn encapsulation vxlan
set routing-instances evpn-1 protocols evpn default-gateway do-not-advertise
set routing-instances evpn-1 protocols evpn duplicate-mac-detection auto-recovery-time 9
set routing-instances evpn-1 protocols evpn extended-vni-list all
set routing-instances evpn-1 protocols evpn vni-options vni 10050 vrf-target target:10050:1
set routing-instances evpn-1 protocols evpn vni-options vni 10108 vrf-target target:10108:1
set routing-instances evpn-1 protocols evpn vni-options vni 10400 vrf-target target:10400:1
MAC-VRF 라우팅 인스턴스 모드가 활성화되면 비 EVO 리프 스위치에 대해 "장치 재부팅 필요"에 대한 이상이 발생합니다. 이러한 이상 현상을 해결하려면 CLI에서 위의 변경 사항의 영향을 받는 리프 스위치를 재부팅합니다.
그림 : MAC-VRF로 변경 후 QFX5120 디바이스 재부팅을 위해 Apstra에서 발생한 이상 현상
구성 커밋
케이블 연결이 확인되면 패브릭을 커밋할 준비가 된 것입니다. 즉, 컨트롤 플레인이 설정되고 모든 리프 스위치가 BGP를 통해 경로를 보급할 수 있습니다. 청사진에서 Blueprint > <Blueprint-name> Uncommitted 로 이동하여 변경 사항을 검토하고 커밋합니다.
Apstra 4.2부터 새로운 기능은 커밋 전에 커밋 검사를 수행하는 것인데, 이는 특히 구성 집합이 관련된 경우 의미 체계 오류 또는 누락을 확인하기 위해 도입되었습니다.
빌드 오류가 있는 경우 수정해야 합니다. 그렇지 않으면 Apstra는 오류가 해결될 때까지 변경 사항을 커밋하지 않습니다.
자세한 정보는 주니퍼 Apstra 사용자 가이드를 참조하십시오.
청사진
Apstra 패브릭 구성 검증
변경 사항을 검토하고 디바이스에 커밋한 후 기능적 패브릭을 만들어야 합니다.
데이터센터 청사진에는 모든 것이 제대로 작동하고 있다는 것을 보여주기 위해 이상 징후가 없다는 것이 표시되어야 합니다. 블루프린트 배포와 관련된 이상 현상을 보려면 Blueprint > <Blueprint-name> > Active 로 이동하여 BGP, 케이블 연결, 인터페이스 비활성화 이벤트, 경로 누락 등과 관련하여 발생한 이상 현상을 확인합니다. 자세한 정보는 Apstra 사용자 가이드를 참조하십시오.
활성 탭 표시
패브릭이 작동하고 변경 사항이 구성되었는지 확인하려면 각 스파인 스위치의 콘솔 또는 CLI에 로그인합니다. 각 스파인 스위치의 셸에서 다음 Junos OS CLI 명령을 입력합니다.
show bgp summary | no-more
이 명령의 출력은 아래 출력과 유사해야 합니다. 이는 BGP가 루프백 및 패브릭 링크 IP를 위해 각 스파인에서 7개의 리프 스위치 각각으로 설정됨을 보여줍니다.
스파인 1에서:
root@dc1-spine1> show bgp summary | no-more
Warning: License key missing; requires 'bgp' license
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 14 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
49 42 0 0 0 0
bgp.evpn.0
8263 8263 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.0.1.5 64520 100256 98745 0 12 4w3d 15:44:08 Establ
inet.0: 2/3/3/0
10.0.1.7 64518 100736 99371 0 31 4w3d 19:24:11 Establ
inet.0: 2/3/3/0
10.0.1.9 64514 17957 17900 0 73 5d 18:19:16 Establ
inet.0: 16/17/17/0
10.0.1.11 64515 17943 17889 0 34 5d 18:13:02 Establ
inet.0: 16/17/17/0
10.0.1.13 64516 100735 99370 0 30 4w3d 19:23:45 Establ
inet.0: 2/3/3/0
10.0.1.15 64517 100736 99373 0 34 4w3d 19:24:21 Establ
inet.0: 2/3/3/0
10.0.1.27 64519 100255 98745 0 18 4w3d 15:44:09 Establ
inet.0: 2/3/3/0
192.168.255.2 64514 21707 40706 0 92 5d 18:18:25 Establ
bgp.evpn.0: 1149/1149/1149/0
192.168.255.3 64515 18907 43483 0 31 5d 18:12:36 Establ
bgp.evpn.0: 1147/1147/1147/0
192.168.255.4 64516 124001 244758 0 30 4w3d 19:23:43 Establ
bgp.evpn.0: 1216/1216/1216/0
192.168.255.5 64517 238893 138433 0 34 4w3d 19:24:20 Establ
bgp.evpn.0: 1216/1216/1216/0
192.168.255.6 64518 102398 265528 0 31 4w3d 19:23:58 Establ
bgp.evpn.0: 1137/1137/1137/0
192.168.255.7 64519 101447 217804 0 16 4w3d 15:43:55 Establ
bgp.evpn.0: 1199/1199/1199/0
192.168.255.8 64520 101419 217814 0 12 4w3d 15:44:00 Establ
bgp.evpn.0: 1199/1199/1199/0
스파인 2에서:
root@dc1-spine2> show bgp summary | no-more
Warning: License key missing; requires 'bgp' license
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 3 Peers: 14 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
49 42 0 0 0 0
bgp.evpn.0
8263 8263 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.0.1.1 64520 100269 98778 0 15 4w3d 15:49:41 Establ
inet.0: 2/3/3/0
10.0.1.3 64519 100267 98778 0 20 4w3d 15:49:40 Establ
inet.0: 2/3/3/0
10.0.1.17 64518 100749 99375 0 35 4w3d 19:29:47 Establ
inet.0: 2/3/3/0
10.0.1.19 64514 17968 17915 0 92 5d 18:24:04 Establ
inet.0: 16/17/17/0
10.0.1.21 64515 17953 17903 0 36 5d 18:17:34 Establ
inet.0: 16/17/17/0
10.0.1.23 64516 100748 99374 0 36 4w3d 19:29:25 Establ
inet.0: 2/3/3/0
10.0.1.25 64517 100749 99378 0 40 4w3d 19:29:58 Establ
inet.0: 2/3/3/0
192.168.255.2 64514 21711 40714 0 93 5d 18:23:41 Establ
bgp.evpn.0: 1149/1149/1149/0
192.168.255.3 64515 18902 43498 0 28 5d 18:16:29 Establ
bgp.evpn.0: 1147/1147/1147/0
192.168.255.4 64516 124014 243943 0 35 4w3d 19:29:20 Establ
bgp.evpn.0: 1216/1216/1216/0
192.168.255.5 64517 238899 137577 0 39 4w3d 19:29:53 Establ
bgp.evpn.0: 1216/1216/1216/0
192.168.255.6 64518 102416 264691 0 34 4w3d 19:29:44 Establ
bgp.evpn.0: 1137/1137/1137/0
192.168.255.7 64519 101454 217761 0 21 4w3d 15:49:28 Establ
bgp.evpn.0: 1199/1199/1199/0
192.168.255.8 64520 101424 217769 0 13 4w3d 15:49:32 Establ
bgp.evpn.0: 1199/1199/1199/0
show bgp summary | no-more 명령의 출력이 위의 스크린샷과 유사하면 베어본 네트워크 패브릭이 완료된 것입니다. 그러나 VRF, VLAN 및 VNI가 있는 오버레이 네트워크는 여전히 적용해야 하므로 아직 프로덕션 환경에 사용할 준비가 되지 않았습니다.
show bgp summary | no-more 명령의 출력이 스크린샷과 유사하지 않은 경우 계속 진행하기 전에 컨피그레이션 오류를 해결하는 것이 중요합니다.
오버레이 네트워크 구성
빨간색 및 파란색 테넌트에 대한 VRF(라우팅 영역)를 구성하고 VNI(가상 네트워크 식별자)를 지정합니다
- 청사진에서 > -> 가상 > 라우팅 영역.
- Create Routing Zone(라우팅 영역 생성)을 클릭하고 다음 정보를 제공합니다.
- VRF 이름:파란색
- VLAN ID: 3
- VNI: 20002
- 라우팅 정책: 기본값 불변
- 다음 정보를 사용하여 다른 라우팅 영역을 생성합니다:
- VRF 이름:빨간색
- VLAN ID:2
- VNI: 20001
- 라우팅 정책: 기본값 불변
라우팅에 EVPN 루프백 할당
라우팅 영역을 생성한 후, 아래의 EVPN 루프백을 빨간색 및 파란색 라우팅 영역 모두에 할당합니다. Blueprint > Staged > Routing Zone 으로 이동하고 오른쪽 패널에서 리소스를 할당합니다.
| 리소스 | 범위 |
|---|---|
| MUST-EVPN-루프백-DC1 | 192.168.11.0/24 |
그림 : 빨간색 및 파란색 루프백 할당
빨간색 및 파란색 라우팅 영역에 가상 네트워크 생성
가상 네트워크는 VRF(라우팅 영역)와 연결되어야 합니다. 가상 네트워크(VNI)를 생성하고 이러한 가상 네트워크를 앞서 생성한 VRF(라우팅 영역)와 연결합니다. 필요에 따라 개별 요구 사항에 따라 프로덕션 환경에 대한 추가 라우팅 영역 및 가상 네트워크를 생성합니다.
아래는 생성되어 패브릭의 적절한 리프 스위치에 할당된 네트워크입니다. 입력 필드는 다음과 같습니다.
블루 네트워크의 경우:
- Create Virtual Networks(가상 네트워크 만들기)를 클릭합니다.
- 네트워크 VXLAN 유형을 설정합니다.
- 제공 이름: dc1_vn1_blue 및 dc1_vn2_blue.
- 두 네트워크 모두에 대해 파란색 보안 영역을 선택합니다.
- VNI 제공:
- dc1_vn1_blue의 경우 12001입니다.
- dc1_vn2_blue의 경우 12002.
- IPv4 Connectivity(IPv4 연결) – enabled(활성화됨)로 설정합니다.
- 연결 템플릿 만들기: 태그가 지정됨.
- IPv4 서브넷 및 가상 IP 게이트웨이 제공:
- dc1_vn1_blue용 10.12.1.0/24, 10.12.1.1
- dc1_vn2_blue용 10.12.2.0/24, 10.12.2.1
- 리프 스위치에 할당합니다.
레드 네트워크의 경우:
- Create Virtual Networks(가상 네트워크 만들기)를 클릭합니다.
- 네트워크 VXLAN 유형을 설정합니다.
- 제공 이름: dc1_vn1_red 및 dc1_vn2_red.
- 두 네트워크 모두에 대해 빨간색 보안 영역을 선택합니다.
- VNI 제공:
- dc1_vn1_red의 경우 11001
- dc1_vn2_red의 경우 11002
- IPv4 Connectivity(IPv4 연결) – enabled(활성화됨)로 설정합니다.
- 연결 템플릿 만들기: 태그가 지정됨.
- IPv4 서브넷 및 가상 IP 게이트웨이 제공:
- dc1_vn1_red용 10.11.1.0/24, 10.11.1.1
- dc1_vn2_red용 10.11.2.0/24, 10.11.2.1
- 리프 스위치에 할당합니다.
가상 네트워크
IRB 네트워크가 생성되고 연결 템플릿이 추가되어 그림 45와 같이 리프 스위치에 할당됩니다. 연결 템플릿에 대한 자세한 내용은 주니퍼 Apstra 사용자 가이드를 참조하세요.
가상 네트워크를 생성하는 동안 위에서 연결 만들기 템플릿이 태그가 지정된 것으로 선택되면 Apstra는 가상 네트워크에 대해 자동으로 생성되는 연결 템플릿을 생성합니다.
Blueprint > Staged > Connectivity Templates로 이동하여 템플릿을 보고 리프 스위치에 할당합니다. 리프 스위치에 할당되면 태그 처리된 어그리게이션 이더넷 인터페이스가 생성되어 서버를 연결합니다.
에 할당
그런 다음 Blueprint > Uncommitted 로 이동하여 커밋되지 않은 변경 사항을 검토하고 오버레이 구성을 커밋합니다. 또는 Blueprint > Staged > Physical > Node 로 이동하여 오버레이 네트워크가 생성된 각 리프 스위치에 대해 생성된 구성을 검토하고 구성을 확인합니다.
파란색 및 빨간색 네트워크에 대한 오버레이 연결 확인
Apstra UI에서 변경 사항을 커밋했으니 이제 이러한 변경 사항이 스위치에 적용됩니다.
패브릭 구성 확인을 시작하려면 각 리프 스위치의 콘솔에 로그인합니다.
리프 스위치의 CLI에서 다음 명령을 입력합니다.
! //begin QFX leaf switch commands// show interfaces irb terse show vlans instance evpn-1 vn1101 show vlans instance evpn-1 vn1102 show vlans instance evpn-1 vn1201 show vlans instance evpn-1 vn1202 !
이 출력에는 여러 IRB 인터페이스와 Blue 및 Red 네트워크에 대해 구성된 라우팅 인스턴스가 표시됩니다.
리프 스위치 중 하나에서 Red Network IRB:
{master:0}
root@dc1-esi-001-leaf1> show interfaces irb terse | match 10.11.*.1/24
irb.1101 up up inet 10.11.1.1/24
irb.1102 up up inet 10.11.2.1/24
리프 스위치 중 하나에서 Blue Network IRB:
{master:0}
root@dc1-esi-001-leaf1> show interfaces irb terse | match 10.12.*.1/24
irb.1201 up up inet 10.12.1.1/24
irb.1202 up up inet 10.12.2.1/24
Apstra는 기본적으로 MAC-VRF 라우팅 모드를 사용하므로 모든 Red 및 Blue 네트워크 VLAN에 대한 아래 명령 출력에서 동일한 것을 확인할 수 있습니다.
{master:0}
root@dc1-esi-001-leaf1> show vlans instance evpn-1 vn1101
Routing instance VLAN name Tag Interfaces
evpn-1 vn1101 1101
vtep-15.32772*
xe-0/0/50:0.0*
{master:0}
root@dc1-esi-001-leaf1> show vlans instance evpn-1 vn1102
Routing instance VLAN name Tag Interfaces
evpn-1 vn1102 1102
vtep-15.32772*
{master:0}
root@dc1-esi-001-leaf1> show vlans instance evpn-1 vn1201
Routing instance VLAN name Tag Interfaces
evpn-1 vn1201 1201
ae1.0
ae3.0*
et-0/0/52.0*
et-0/0/53.0*
vtep-15.32771*
vtep-15.32772*
vtep-15.32776*
vtep-15.32777*
xe-0/0/50:0.0*
{master:0}
root@dc1-esi-001-leaf1> show vlans instance evpn-1 vn1202
Routing instance VLAN name Tag Interfaces
evpn-1 vn1202 1202
ae2.0*
et-0/0/52.0*
et-0/0/53.0*
vtep-15.32771*
vtep-15.32772*
vtep-15.32776*
vtep-15.32777*
리프 스위치에 ERB가 구성되어 있는지 확인
리프 스위치의 CLI 내에서 다음 명령을 입력합니다.
! //begin QFX CLI commands// show evpn database | match irb.110 show evpn database | match irb.120 !
이 명령의 출력에는 모든 스위치의 분산 게이트웨이가 표시됩니다.
게이트웨이는 빨간색 네트워크에 대해 10.11.1.1, 10.11.2.1, 파란색 네트워크에 대해 10.12.1.1, 10.12.2.1을 표시합니다. 이러한 IRB 구성은 연결 템플릿에 할당된 디바이스에만 적용됩니다. 연결 템플릿을 통해 할당하지 않는 한 다른 패브릭 스위치에는 이 IRB가 구성되어 있지 않습니다.
{master:0}
root@dc1-esi-001-leaf1> show evpn database | match irb.110
11001 00:1c:73:00:00:01 irb.1101 Feb 28 11:33:36 10.11.1.1
11002 00:1c:73:00:00:01 irb.1102 Feb 28 11:33:36 10.11.2.1
{master:0}
root@dc1-esi-001-leaf1> show evpn database | match irb.120
12001 00:1c:73:00:00:01 irb.1201 Feb 28 11:33:22 10.12.1.1
12002 00:1c:73:00:00:01 irb.1202 Feb 28 11:33:22 10.12.2.1
리프 스위치 라우팅 테이블 확인
리프 스위치의 CLI 내에서 다음 명령을 입력합니다.
! //begin QFX CLI commands// show route table red.inet.0 10.11.1.0/24 show route table red.inet.0 10.11.2.0/24 show route table blue.inet.0 10.12.1.0/24 show route table blue.inet.0 10.12.2.0/24 !
이 명령의 출력에는 리프 스위치 중 하나에 대한 VRF Red 네트워크의 경로가 표시됩니다.
{master:0}
root@dc1-esi-001-leaf1> show route table red.inet.0 10.11.1.0/24
red.inet.0: 1811 destinations, 3372 routes (1811 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
10.11.1.0/24 *[Direct/0] 06:21:33
> via irb.1101
[EVPN/170] 06:14:27
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:15:18
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:17:59
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
10.11.1.1/32 *[Local/0] 06:21:33
Local via irb.1101
{master:0}
root@dc1-esi-001-leaf1> show route table red.inet.0 10.11.2.0/24
red.inet.0: 3061 destinations, 4622 routes (3061 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
10.11.2.0/24 *[Direct/0] 06:23:38
> via irb.1102
[EVPN/170] 06:16:32
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:17:43
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:19:44
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
10.11.2.1/32 *[Local/0] 06:23:38
Local via irb.1102
이 명령의 출력은 리프 스위치 중 하나에 대한 VRF Blue 네트워크의 경로를 표시합니다.
{master:0}
root@dc1-esi-001-leaf1> show route table blue.inet.0 10.12.1.0/24
blue.inet.0: 3087 destinations, 4650 routes (3087 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
10.12.1.0/24 *[Direct/0] 06:26:21
> via irb.1201
[EVPN/170] 06:26:02
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 06:26:04
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 06:19:10
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 05:58:16
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:19:51
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:22:32
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
10.12.1.1/32 *[Local/0] 06:26:21
Local via irb.1201
{master:0}
root@dc1-esi-001-leaf1> show route table blue.inet.0 10.12.2.0/24
blue.inet.0: 3087 destinations, 4650 routes (3087 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
10.12.2.0/24 *[Direct/0] 06:26:26
> via irb.1202
[EVPN/170] 06:26:07
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 06:26:09
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 06:19:15
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 06:20:38
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:20:16
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
[EVPN/170] 00:22:17
> to 10.0.1.12 via et-0/0/48.0
to 10.0.1.22 via et-0/0/49.0
10.12.2.1/32 *[Local/0] 06:26:26
Local via irb.1202
다음 명령은 ESI 리프 스위치 오버레이를 보여줍니다. 이는 원격 리프 VNI가 ESI 리프 스위치 간에 교환되는 것을 보여줍니다.
{master:0}
root@dc1-esi-001-leaf1> show ethernet-switching vxlan-tunnel-end-point remote
Logical System Name Id SVTEP-IP IFL L3-Idx SVTEP-Mode ELP-SVTEP-IP
<default> 0 192.168.255.4 lo0.0 0
RVTEP-IP L2-RTT IFL-Idx Interface NH-Id RVTEP-Mode ELP-IP Flags
192.168.255.5 evpn-1 671088642 vtep-15.32772 7000 RNVE
VNID MC-Group-IP
11001 0.0.0.0
11002 0.0.0.0
12001 0.0.0.0
12002 0.0.0.0
{master:0}
root@dc1-esi-001-leaf2> show ethernet-switching vxlan-tunnel-end-point remote
Logical System Name Id SVTEP-IP IFL L3-Idx SVTEP-Mode ELP-SVTEP-IP
<default> 0 192.168.255.5 lo0.0 0
RVTEP-IP IFL-Idx Interface NH-Id RVTEP-Mode ELP-IP Flags
192.168.254.2 1388 vtep.32771 4989 RNVE
192.168.255.2 1391 vtep.32774 4995 RNVE
192.168.254.3 1389 vtep.32772 4991 RNVE
192.168.255.3 1390 vtep.32773 4994 RNVE
192.168.255.4 1393 vtep.32776 5392 RNVE
192.168.255.6 1392 vtep.32775 4996 RNVE
192.168.255.7 1381 vtep.32777 5811 RNVE
192.168.255.8 1394 vtep.32770 5845 RNVE
L2-RTT IFL-Idx Interface NH-Id RVTEP-Mode ELP-IP Flags
192.168.255.4 evpn-1 671088646 vtep-15.32776 5392 RNVE
VNID MC-Group-IP
12002 0.0.0.0
11002 0.0.0.0
11001 0.0.0.0
12001 0.0.0.0
외부 라우터 및 VRF 간 라우팅 구성
이 JVD의 경우 MX204 라우터는 외부 라우팅을 수행하기 위한 외부 라우터로 사용되며 Red 및 Blue 네트워크 간의 VRF 간 경로 누출에도 사용됩니다. 외부 라우터를 구성하는 것은 일반 서버를 추가하는 것과 유사합니다. MX204 라우터는 데이터센터 패브릭에 대한 외부 게이트웨이 역할을 하는 경계 리프 스위치에 연결됩니다.
MX 라우터를 외부 라우터로 추가하려면 Apstra UI, Blueprint > Staged > 토폴로지 로 이동한 다음 경계 리프 스위치를 클릭하여 외부 일반 시스템과 외부 일반 시스템에 대한 연결을 추가합니다( 그림 50 참조).
다음 그래픽에서 경계 leaf1에 대한 인터페이스와 MX204 디바이스 및 해당 인터페이스를 선택하고 Add Link(링크 추가)를 클릭합니다.
추가
그런 다음, Stage > Policies(라우팅 정책) > Routing Policies(라우팅 정책 )로 이동하고 외부 라우터로 경로를 내보낼 외부 라우팅 정책 생성합니다. 그런 다음 이 정책은 다음 단계에서 다루는 대로 빨간색 및 파란색 네트워크 경로를 내보낼 수 있도록 연결 템플릿에 적용됩니다.
그런 다음 청사진의 연결 템플릿으로 이동하고 아래 연결 템플릿을 추가하여 IP 링크, BGP 피어링 및 MX204(외부 라우터)의 라우팅 정책을 추가합니다. 이 JVD의 경우 Red 및 Blue 네트워크는 VRF 간 라우팅이 수행되는 MX204로 라우팅됩니다. VLAN 299는 레드 네트워크에, VLAN 399는 블루 네트워크에 사용됩니다.
그림: 빨간색 및 파란색 VRF에 대한 IP 링크
그림 : 빨간색 및 파란색 VRF에 대한 MX로의 BGP 피어링
그림: 빨간색 및 파란색 VRF의 라우팅 정책
그런 다음 Staged > Virtual > Routing Zone(가상 라우팅 영역 )으로 이동하고 Red VRF Network(빨간색 VRF 네트워크 )를 클릭한 다음 아래로 스크롤하여 두 경계 리프 스위치에서 IP 인터페이스 링크를 추가합니다. Blue VRF 네트워크에 대해서도 동일한 작업이 수행됩니다.
대한 IP 인터페이스 링크 추가
에 대한 IP 인터페이스 링크 추가
청사진을 커밋하여 구성을 두 개의 경계 리프 스위치로 푸시합니다. Apstra가 MX204를 관리하지 않으므로 외부 라우터는 수동으로 구성해야 합니다. 구성 MX204 라우터의 경우, 인터페이스는 위의 그림 48 및 그림 56에서 사용된 IP를 사용하여 구성됩니다.
Red 및 Blue 네트워크에 대한 MX204 구성 코드 조각:
xe-0/0/2:0 {
vlan-tagging;
unit 0 {
vlan-id 0;
family inet;
}
unit 299 {
vlan-id 299;
family inet {
address 10.200.0.5/31;
}
family inet6 {
address 2001:db8:dc1:10:200::5/127;
}
}
unit 399 {
vlan-id 399;
family inet {
address 10.200.0.9/31;
}
family inet6 {
address 2001:db8:dc1:10:200::9/127;
}
}
}
xe-0/0/2:1 {
vlan-tagging;
unit 0 {
vlan-id 0;
family inet;
}
unit 299 {
vlan-id 299;
family inet {
address 10.200.0.7/31;
}
family inet6 {
address 2001:db8:dc1:10:200::7/127;
}
}
unit 399 {
vlan-id 399;
family inet {
address 10.200.0.11/31;
}
family inet6 {
address 2001:db8:dc1:10:200::b/127;
}
}
}
VRF 간 라우팅의 경우 Red 및 Blue VRF 네트워크 간의 VRF 간 라우팅을 활성화하기 위해 아래와 같이 MX에 정책이 구성됩니다. 두 VRF는 모두 MX204(외부 라우터)의 BGP 피어에 대한 경계 리프 스위치에서 구성됩니다. MX204는 BGP 라우팅 정책을 사용하여 VRF 간 경로를 교환합니다.
또한 Apstra는 외부 라우터 없이도 Red 및 Blue 네트워크 간에 VRF 간 라우팅을 구성할 수 있습니다. 자세한 정보는 Apstra 가이드를 참조하십시오. 설정에 대한 변경 사항을 철저히 테스트하는 것이 좋습니다. 이 JVD의 경우 "Route Target Overlaps Allow internal route-target policies" 설정이 사용되지 않았습니다. 이 설정을 '경고 없음'으로 설정하면 빨간색 및 파란색과 같은 각 라우팅 영역을 변경하여 Apstra 내에서 가져오기 및 내보내기 경로 대상 정책을 사용하여 경로 대상 교환을 허용할 수 있습니다.
VRF 간을 위한 MX204 구성 스니펫:
root@must-mx204-1> show configuration policy-options policy-statement RoutesToFabric
term 1 {
from interface lo0.0;
then accept;
}
term 2 {
from {
protocol [ static bgp ];
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term 3 {
from {
protocol [ static bgp ];
rib inet6.0;
route-filter::/0 exact;
}
then accept;
}
term 4 {
then reject;
}
root@must-mx204-1> show configuration protocols bgp
group fabric {
type external;
multihop {
ttl 1;
}
multipath {
multiple-as;
}
neighbor 10.200.0.4 {
export RoutesToFabric;
peer-as 64514;
}
neighbor 2001:db8:dc1:10:200::4 {
export RoutesToFabric;
peer-as 64514;
}
neighbor 10.200.0.8 {
export RoutesToFabric;
peer-as 64514;
}
neighbor 2001:db8:dc1:10:200::8 {
export RoutesToFabric;
peer-as 64514;
}
neighbor 10.200.0.6 {
export RoutesToFabric;
peer-as 64515;
}
neighbor 2001:db8:dc1:10:200::6 {
export RoutesToFabric;
peer-as 64515;
}
neighbor 10.200.0.10 {
export RoutesToFabric;
peer-as 64515;
}
neighbor 2001:db8:dc1:10:200::a {
export RoutesToFabric;
peer-as 64515;
}
}
Apstra UI: 블루프린트 대시보드, 분석, 프로브, 이상 징후
관리형 스위치는 스위치 상태 및 네트워크 상태에 대한 방대한 양의 데이터를 생성합니다. 데이터센터 네트워크와 관련하여 이를 분석하기 위해 Apstra는 그래프1 의 인텐트와 스위치 생성 데이터를 결합하는 인텐트 기반 분석을 사용하여 Apstra 대시보드를 통해 데이터센터 네트워크 보기를 제공합니다.
Apstra는 그래프 모델을 사용하여 데이터센터 인프라, 정책 등을 나타냅니다. 네트워크에 대한 모든 정보는 노드 및 노드 간의 관계로 모델링됩니다. 그래프 모델은 데이터를 쿼리하고 분석 및 자동화에 사용할 수 있습니다. Apstra 그래프 모델 및 쿼리에 대한 자세한 내용은 Apstra 사용자 가이드를 참조하십시오.
분석 대시보드, 이상징후, 프로브 및 보고서
또한 Apstra는 디바이스에서 데이터를 수집하는 사전 정의된 대시보드를 제공합니다. Apstra는 IBA 프로브를 통해 인텐트와 데이터를 결합하여 네트워크에 대한 실시간 인사이트를 제공하며, 이러한 인사이트는 Apstra GUI 또는 Rest API를 사용하여 검사할 수 있습니다. IBA 프로브는 임계값에 따라 이상 징후를 발생시키도록 구성할 수 있습니다. 프로브에서 생성되는 데이터의 양을 분석하여 Apstra 서버의 디스크 공간이 IBA 작업을 수용할 수 있는지 확인하는 것이 좋습니다. 로그 순환 설정을 조정하면 디스크 사용량을 줄일 수 있습니다.
Apstra를 사용하면 사용자 지정 대시보드를 만들 수 있습니다. 자세한 정보는 Apstra 사용자 가이드를 참조하십시오. 청사진에서 분석 > 대시보드 로 이동하여 분석 대시보드를 봅니다.
분석 대시보드에는 모든 디바이스 상태의 상태가 표시됩니다. 이상 징후가 있는 경우 이상 징후 탭을 클릭하여 이상 징후를 확인합니다. IBA 프로브에서 이상이 탐지되지 않은 경우 Blueprint 이상 징후 탭에 "이상 징후 없음!" 메시지가 표시됩니다. 자세한 정보는 Apstra 사용자 가이드를 참조하십시오.
현상
구성된 프로브를 보려면 Blueprint > Analytics > 프로브로 이동합니다. 여기에서 프로브를 편집, 복제 또는 삭제하는 작업을 수행할 수 있습니다. 예를 들어 프로브 이상을 억제해야 하는 경우 프로브를 편집하여 동일한 작업을 수행할 수 있습니다.
변칙을 발생시키거나 억제하려면 Raise Anomaly(이상 발생 ) 확인란을 표시하거나 선택 취소합니다.
그림 : 프로브 이상 구성
보고서를 생성하려면 Blueprints > Analytics > Reports로 이동합니다. 여기에서 보고서를 다운로드하여 상태, 디바이스 트래픽 등을 분석할 수 있습니다.
생성
근본 원인 식별(RCI)은 Apstra 소프트웨어에 통합된 기술로, 복잡한 네트워크 문제의 근본 원인을 자동으로 판별합니다. RCI는 실시간 네트워크 상태를 파악하기 위해 Apstra 데이터 저장소를 활용하고 텔레메트리를 각 액티브 블루프린트 인텐트와 자동으로 연계합니다. 근본 원인 사용 사례에는 예를 들어 링크 다운, 링크 케이블 불일치, 인터페이스 다운, 링크 연결 끊김 등이 포함됩니다.
사용
사용