이 페이지의 내용
Junos 노드 슬라이싱 설정
외부 서버 모델을 사용하는 경우 Junos 노드 슬라이싱 설정 작업을 수행하기 전에 Junos 노드 슬라이싱 설정 준비 장에 설명된 절차를 완료해야 합니다.
BSYS 모드에서 작동하도록 MX 시리즈 라우터 구성(외부 서버 모델)
서버와 라우터 연결에 설명된 대로 MX 시리즈 라우터가 x86 서버에 연결되어 있는지 확인합니다.
Junos Node Slicing을 사용하려면 MX 시리즈 라우터가 기본 시스템(BSYS)으로 작동해야 합니다.
다음 단계를 사용하여 BSYS 모드에서 작동하도록 MX 시리즈 라우터를 구성합니다.
BSYS 모드의 라우터는 Junos 노드 슬라이싱의 기본 관리 기능을 실행하는 데 필요한 기능 이외의 기능을 실행하지 않을 것으로 예상됩니다. 예를 들어, BSYS는 시스템에 설치된 라인 카드와 연관된 인터페이스 구성을 갖지 않을 것으로 예상됩니다. 대신 게스트 네트워크 기능(GNF)은 완전한 라우터 구성을 갖게 됩니다.
RHEL(외부 서버 모델)을 실행하는 x86 서버에 JDM RPM 패키지 설치
x86 서버용 JDM RPM 패키지를 설치하기 전에 JDM용 추가 패키지 설치에 설명된 대로 추가 패키지를 설치했는지 확인하십시오.
다음과 같이 RHEL을 실행하는 x86 서버용 JDM RPM 패키지를 다운로드하여 설치합니다.
RHEL을 실행하는 x86 서버에 패키지를 설치하려면 각 서버에서 다음 단계를 수행합니다.
두 번째 서버에 대해 이 단계를 반복합니다.
Ubuntu 20.04를 실행하는 x86 서버에 JDM Ubuntu 패키지 설치(외부 서버 모델)
x86 서버용 JDM Ubuntu 패키지를 설치하기 전에 추가 패키지를 설치했는지 확인합니다. 자세한 내용은 JDM용 추가 패키지 설치를 참조하십시오.
다음과 같이 Ubuntu 20.04를 실행하는 x86 서버용 JDM Ubuntu 패키지를 다운로드하여 설치합니다.
Ubuntu 20.04를 실행하는 x86 서버에 JDM 패키지를 설치하려면 각 서버에서 다음 단계를 수행합니다.
두 번째 서버에 대해 이 단계를 반복합니다.
x86 서버에서 JDM 구성(외부 서버 모델)
다음 단계를 사용하여 각 x86 서버에서 JDM을 구성합니다.
JDM에서 루트가 아닌 사용자 구성(Junos Node Slicing)
외부 서버 모델에서는 Junos OS 릴리스 18.3R1부터 Junos 노드 슬라이싱을 위해 JDM(Juniper Device Manager)에서 루트가 아닌 사용자를 생성할 수 있습니다. 루트가 아닌 사용자를 생성하려면 루트 계정이 필요합니다. 루트가 아닌 사용자는 JDM 콘솔 또는 SSH를 사용하여 JDM에 로그인할 수 있습니다. 루트가 아닌 각 사용자에게는 사용자 이름이 제공되고 사전 정의된 로그인 클래스가 할당됩니다.
루트가 아닌 사용자는 다음 기능을 수행할 수 있습니다.
JDM과 상호 작용합니다.
게스트 네트워크 기능(GNF)을 오케스트레이션하고 관리합니다.
JDM CLI 명령을 사용하여 JDM, 호스트 서버 및 GNF의 상태를 모니터링합니다.
루트가 아닌 사용자 계정은 호스트 서버가 아닌 JDM 내에서만 작동합니다.
JDM에서 루트가 아닌 사용자를 생성하려면 다음을 수행합니다.
표 1 에는 JDM이 루트가 아닌 사용자에 대해 지원하는 사전 정의된 로그인 클래스가 포함되어 있습니다.
로그인 클래스 |
권한을 |
|---|---|
슈퍼 사용자 |
|
연산자 |
|
읽기 전용 |
사용자가 JDM 내에서 데몬을 다시 시작할 수 없다는 점을 제외하면 운영자 클래스와 유사합니다. |
무단 |
Ping 및 경로 추적 작업. |
JDM 인터페이스 구성(외부 서버 모델)
JDM에 구성된 서버 인터페이스를 수정하려면 다음 단계를 수행합니다.
JDM에서 다음을 구성해야 합니다.
MX 시리즈 라우터에 연결된 2개의 10Gbps 서버 포트.
JDM 관리 포트로 사용할 서버 포트입니다.
GNF 관리 포트로 사용할 서버 포트입니다.
따라서 포트 구성을 시작하기 전에 각 서버에서 다음을 식별해야 합니다.
MX 시리즈 라우터에 연결된
CB0CB1서버 인터페이스(예:p3p1및p3p2)입니다.JDM 관리 및 GNF 관리에 사용할 서버 인터페이스(예:
em2및em3)입니다.
자세한 내용은 서버와 라우터 연결 그림을 참조하십시오.
및
server1에server0대해 이 정보가 필요합니다.이러한 인터페이스는 Linux 호스트에서만 볼 수 있습니다.
JDM에서 x86 서버 인터페이스를 구성하려면 두 서버 모두에서 다음 단계를 수행합니다.
샘플 JDM 구성은 Junos Node Slicing 샘플 구성을 참조하십시오.
JDM에 구성된 서버 인터페이스를 수정하려면 GNF를 삭제하고(구성된 경우), 위에서 설명한 대로 인터페이스를 구성하고, 셸에서 JDM을 재부팅하고, GNF를 재구성 및 활성화하고, 변경 사항을 커밋해야 합니다.
Junos OS 릴리스 19.2R1부터 Junos Node Slicing은 GNF에 대해 전역적으로 고유한 MAC 주소 범위(주니퍼 네트웍스에서 제공) 할당을 지원합니다.
MX 시리즈 라우터가 섀시 내 모드에서 작동하도록 구성
섀시 내 Junos Node Slicing을 구성하기 위해 MX 시리즈 라우터에 다음 유형의 라우팅 엔진 중 하나가 설치되어 있어야 합니다.
-
RE-S-X6-128G(MX480 및 MX960 라우터에서 사용)
-
REMX2K-X8-128G(MX2010 및 MX2020 라우터에서 사용)
-
REMX2008-X8-128G(MX2008 라우터에 사용)
-
섀시 내 모델에서는 기본 시스템(BSYS), 주니퍼 디바이스 관리자(JDM) 및 모든 게스트 네트워크 기능(GNF)이 MX 시리즈 라우터의 라우팅 엔진 내에서 실행됩니다. BSYS 및 GNF는 호스트에서 VM(가상 머신)으로 실행됩니다. 먼저 다음과 같이 독립형 MX 시리즈 라우터의 리소스 공간을 줄여야 합니다.
로그 파일(/var/log) 및 코어 파일(/var/crash)을 포함하여 /var/ 위치의 모든 파일은 문을 구성한 set vmhost resize vjunos compact 후 VM 호스트를 재부팅할 때 삭제됩니다. 참조용으로 사용하려는 경우 VM 호스트 크기 조정 구성을 진행하기 전에 현재 /var/log 또는 /var/crash에 있는 파일을 저장해야 합니다.
섀시 내 모델을 위한 JDM 설치 및 구성
이 주제에 나열된 단계는 섀시 내 Junos 노드 슬라이싱 구성에만 적용됩니다.
MX 시리즈 라우터에 JDM RPM 패키지 설치(섀시 내 모델)
MX 시리즈 라우터에 JDM(Juniper Device Manager) RPM 패키지를 설치하기 전에 MX 시리즈 라우터가 섀시 내 BSYS 모드에서 작동하도록 구성해야 합니다. 자세한 내용은 섀시 내 모드에서 작동하도록 MX 시리즈 라우터 구성을 참조하십시오.
RPM 패키지는 섀시 내 Junos 노드 슬라이싱 구축을 위한 것이며, RPM 패키지는 jns-jdm-vmhost jns-jdm 외부 서버 기반 Junos 노드 슬라이싱 구축을 위한 것입니다.
JDM 구성(섀시 내 모델)
다음 단계를 사용하여 MX 시리즈 라우터의 라우팅 엔진 모두에서 JDM을 구성합니다.
섀시 내 Junos 노드 슬라이싱에서는 동일한 라우팅 엔진의 관리 인터페이스(예: GNF1의 라우팅 엔진 0에서 GNF2의 라우팅 엔진 0으로 또는 GNF1의 라우팅 엔진 0에서 JDM으로) 간에 트래픽을 ping하거나 전송할 수 없습니다.
섀시 내 모드에서는 BSYS와 JDM 관리 인터페이스 간에 작업을 수행할
scp수 없습니다.8단계를 시도하기 전에 7단계에서 설명한 대로 ssh 키 교환을 완료해야 합니다. 7단계를 완료하지 않고 8단계를 시도하면 다음 예제와 같이 오류 메시지가 표시됩니다.
Failed to fetch JDM software version from server1. If authentication of peer server is not done yet, try running request server authenticate-peer-server.
Junos OS 릴리스 19.2R1부터 Junos Node Slicing은 GNF에 대해 전역적으로 고유한 MAC 주소 범위(주니퍼 네트웍스에서 제공) 할당을 지원합니다.
GNF에 MAC 주소 할당
Junos OS 릴리스 19.2R1부터 Junos Node Slicing은 GNF에 대해 (주니퍼 네트웍스가 제공하는) 전역적으로 고유한 MAC 주소 범위 할당을 지원합니다.
GNF에 대한 전 세계적으로 고유한 MAC 주소 범위를 받으려면 주니퍼 네트웍스 담당자에게 연락하여 GNF 라이선스 구매 시 전자적으로 배송되는 GNF 라이선스 SSRN(소프트웨어 지원 참조 번호)을 제공하십시오. GNF 라이선스에서 SSRN을 찾으려면 주니퍼 네트웍스 기술 자료 문서 KB11364를 참조하십시오.
각 GNF 라이선스에 대해 주니퍼 네트웍스가 해당 GNF 라이선스에 대해 할당한 전역적으로 고유한 MAC 주소 범위를 포함하는 '증강된 SSRN'이 제공됩니다. 그런 다음 다음과 같이 JDM CLI에서 이 증강된 SSRN을 구성해야 합니다.
root@jdm#set system vnf-license-supplement vnf-id gnf-id license-supplement-string augmented-ssrn-stringroot@jdm#commit
증강된 SSRN은 하나의 GNF ID에만 사용해야 합니다. JDM에서는 GNF VM을 VNF(가상 네트워크 기능)라고 합니다. GNF ID는 그 속성 중 하나입니다. VNF의 속성은 게스트 네트워크 기능 구성의 후속 섹션에 자세히 설명되어 있습니다.
기본적으로 증강된 SSRN의 유효성이 검사됩니다. 이 검증을 건너뛰어야 하는 경우 다음과 같이 CLI에서 no-validate 속성을 사용할 수 있습니다. 예:
set system vnf-license-supplement vnf-id gnf-id license-supplement-string augmented-ssrn-string [no-validate].
GNF가 작동하지 않고 아직 프로비저닝되지 않은 경우에만 GNF ID에 대해 증강된 SSRN을 구성할 수 있습니다. GNF를 구성하기 전에 먼저 GNF ID에 대한 증강된 SSRN을 구성해야 합니다. GNF ID가 이미 프로비저닝된 경우, 강화된 SSRN을 구성하기 전에 먼저 두 서버(외부 서버 모델의 경우) 또는 라우팅 엔진(섀시 내 Junos 노드 슬라이싱 모델의 경우)에서 해당 GNF ID에 대한 GNF를 삭제해야 합니다.
마찬가지로, GNF ID에 대한 증강된 SSRN을 삭제하기 전에 먼저 서버(외부 서버 모델의 경우) 또는 라우팅 엔진(섀시 내 Junos 노드 슬라이싱 모델의 경우)에서 지정된 GNF ID에 대한 GNF를 삭제해야 합니다.
Junos OS 19.1R1 또는 이전 버전을 기반으로 하는 GNF에는 증강된 SSRN을 적용할 수 없습니다.
GNF에 할당된 MAC 주소 범위가 적용되었는지 확인하려면 GNF가 작동할 때 Junos CLI 명령을
show chassis mac-addresses사용합니다. 출력은 증강된 SSRN의 하위 문자열과 일치합니다.
게스트 네트워크 기능 구성
게스트 네트워크 기능(GNF) 구성은 BSYS와 JDM에서 수행되는 두 가지 작업으로 구성됩니다.
- GNF를 생성하기 전에 JDM 인스턴스에서 생성된 임의의 MAC 접두사가 동기화되도록 JDM 구성의 일부로 커밋 동기화를 구성했는지 확인해야 합니다. 임의의 MAC 접두사가 동기화되었는지 확인하려면 CLI 명령
show server connections또는show system random-mac-prefixJDM을 사용합니다. 임의의 MAC 접두사가 동기화되지 않은 경우 소프트웨어는 다음과 같은 주요 경보Mismatched MAC address pool between GNF RE0 and GNF RE1를 발생시킵니다. 알람을 보려면 show system alarms 명령을 사용합니다. -
GNF를 생성하기 전에 서버(또는 섀시 내 모델의 경우 라우팅 엔진)에 해당 GNF에 대한 충분한 리소스(CPU, 메모리, 스토리지)가 있는지 확인해야 합니다.
-
각 GNF에 ID를 할당해야 합니다. 이 ID는 BSYS와 JDM에서 동일해야 합니다.
BSYS에서 다음 예와 같이 구성을 적용하여 ID와 라인 카드 집합을 할당하여 GNF를 지정합니다.
user@router# set chassis network-slices guest-network-functions gnf 1 fpcs 4
user@router# commit
JDM에서는 GNF VM을 VNF(가상 네트워크 기능)라고 합니다. VNF에는 다음과 같은 속성이 있습니다.
VNF 이름입니다.
GNF ID입니다. 이 ID는 BSYS에서 사용되는 GNF ID와 동일해야 합니다.
MX 시리즈 플랫폼 유형입니다.
-
GNF에 사용될 Junos OS 이미지로, 주니퍼 다운로드 페이지에서 다운로드할 수 있습니다.
다운로드 페이지에서 Junos Node Slicing - Guest Network Function> 모든 제품을 선택하여 GNF용 Junos 이미지를 다운로드합니다.
VNF 서버 리소스 템플릿입니다.
JDM에서 VNF를 구성하려면 다음 단계를 수행합니다.
JDM 셸 명령을
scp사용하여 GNF에 대한 Junos OS 노드 슬라이싱 이미지를 검색하고 JDM 로컬 디렉토리 / var/jdm-usr/gnf-images 에 배치합니다(이 단계를 반복하여 GNF 구성 파일을 검색합니다).root@jdm:~#
scp source-location-of-the-gnf-image /var/jdm-usr/gnf-imagesroot@jdm:~#scp source-location-of-the-gnf-configuration-file /var/jdm-usr/gnf-config다음 예제와 같이 JDM CLI 명령을 사용하여 이 이미지를 GNF에 할당합니다.
root@test-jdm-server0>
request virtual-network-functions test-gnf add-image /var/jdm-usr/gnf-images/junos-install-ns-mx-x86-64-17.4R1.10.tgz all-serversServer0: Added image: /vm-primary/test-gnf/test-gnf.img Server1: Added image: /vm-primary/test-gnf/test-gnf.img-
다음 예와 같이 구성 문을 적용하여 VNF를 구성합니다.
root@test-jdm-server0#
set virtual-network-functionstest-gnfid1root@test-jdm-server0#
set virtual-network-functionstest-gnfchassis-type mx2020root@test-jdm-server0#
set virtual-network-functionstest-gnfresource-template2core-16groot@test-jdm-server0#
set system vnf-license-supplement vnf-id 1 license-supplement-string RTU00023003204-01-AABBCCDDEE00-1100-01-411C섀시 내 모델의 경우 플랫폼 유형(
set virtual-network-functionstest-gnfchassis-type mx2020)을 구성하지 마십시오. 자동으로 감지됩니다.Junos OS 릴리스 19.2R1부터 Junos Node Slicing은 GNF에 대해 (주니퍼 네트웍스가 제공하는) 전역적으로 고유한 MAC 주소 범위 할당을 지원합니다.
또한 GNF에 대한 기본 또는 초기 Junos OS 구성을 지정하려면 외부 서버 모델의 경우 서버(server0 및 server1)와 섀시 내 모델의 라우팅 엔진(re0 및 re1)에서 GNF 구성 파일(예: / var/jdm-usr/gnf-config/test-gnf.conf)을 준비하고 아래와 같이 명령문에서
base-config파일 이름을 매개 변수로 지정합니다.root@test-jdm-server0#
set virtual-network-functions test-gnf base-config /var/jdm-usr/gnf-config/test-gnf.confroot@test-jdm-server0#
commit synchronize참고:다음 사항을 확인합니다.
-
앞서 BSYS에서 지정한 것과 동일한 GNF ID를 사용합니다.
-
기본 구성 파일 이름(경로 포함)은 서버/라우팅 엔진 모두에서 동일합니다.
-
기준 파일 내용의 구문은 Junos OS 구성 형식입니다.
-
여기에 사용된 GNF 이름은 2단계에서 GNF용 Junos OS 이미지에 할당된 이름과 동일합니다.
-
VNF가 생성되었는지 확인하려면 다음 JDM CLI 명령을 실행합니다.
root@test-jdm-server0입니다>
show virtual-network-functions test-gnf다음 JDM CLI 명령을 실행하여 VNF의 콘솔에 로그인합니다.
root@test-jdm-server0입니다>
request virtual-network-functions test-gnf console참고:구성 작업을 완료한 후에는 VNF 콘솔에서 로그아웃해야 합니다. 명령을
set system login idle-timeout minutes사용하여 유휴 시간 제한을 설정하는 것이 좋습니다. 그렇지 않고 사용자가 VNF 콘솔 세션에서 로그아웃하는 것을 잊어버린 경우 다른 사용자가 액세스 자격 증명을 제공하지 않고 로그인할 수 있습니다. 자세한 내용은 시스템 로그인(Junos Node Slicing)을 참조하십시오.MX 시리즈 라우팅 엔진을 구성하는 것과 동일한 방법으로 VNF를 구성합니다.
섀시 내 모델에 대한 CLI 프롬프트는 입니다
root@jdm#.샘플 구성은 Junos Node Slicing 샘플 구성을 참조하십시오.
외부 서버 모델의 경우, 이전에 Linux 셸에서 물리적 x86 CB 인터페이스 또는 GNF 관리 인터페이스를 중단한 경우(명령
ifconfig interface-name down사용) GNF가 시작될 때 자동으로 실행됩니다.
한 쌍의 GNF 간 추상화된 패브릭 인터페이스 구성
두 게스트 네트워크 기능(GNF) 간에 추상화된 패브릭() 인터페이스를 생성하려면 기본 시스템(afBSYS)과 GNF에서의 구성이 모두 필요합니다. 추상화된 패브릭 인터페이스는 BSYS 구성을 기반으로 GNF에서 생성되며, 이 구성은 해당 GNF로 전송됩니다.
-
한 쌍의 GNF 간에는 하나의
af인터페이스만 구성할 수 있습니다. - 각 GNF가 단일 FPC와 함께 할당되는 Junos 노드 슬라이싱 설정에서 원격 GNF에 할당된 FPC의 패킷 포워딩 엔진이 패브릭을 통해 도달할 수 없게 되면 관련 추상화된 패브릭 인터페이스가 중단됩니다. 이 동작의 원인이 될 수 있는 오류의 예로는 pfe 패브릭 연결성 오류 및 작업을 유발하는
pfe disablecmerror 이벤트가 있습니다(자세한 내용은 명령 사용show chassis fpc errors). GNF에 여러 FPC가 할당되어 있는 경우, 모든 피어 패킷 포워딩 엔진이 중단되었다고 보고하는 로컬 FPC는 추상화된 패브릭 인터페이스 상태를 결정하는 것에서 제거됩니다.
한 쌍의 GNF 간 인터페이스를 구성하려면 af 다음을 수행합니다.
-
BSYS에서 다음 예와 같이 구성을 적용합니다.
user@router#
set chassis network-slices guest-network-functions gnf 2 af4 peer-gnf id 4user@router#set chassis network-slices guest-network-functions gnf 2 af4 peer-gnf af2user@router#set chassis network-slices guest-network-functions gnf 4 af2 peer-gnf id 2user@router#set chassis network-slices guest-network-functions gnf 4 af2 peer-gnf af4이 예에서 은(는)
af2추상화된 패브릭 인터페이스 인스턴스 2이고af4은(는) 추상화된 패브릭 인터페이스 인스턴스 4입니다.참고:허용되는
af인터페이스 값의 범위는af0에서 까지입니다af9.GNF
af인터페이스가 표시되고 작동합니다. 다른 인터페이스를 구성하는 방법으로 인터페이스를 구성할af수 있습니다. GNF에서 다음 예와 같이 구성을 적용합니다.
user@router-gnf-b#
set interfaces af4 unit 0 family inet address 10.10.10.1/24user@router-gnf-d#set interfaces af2 unit 0 family inet address 10.10.10.2/24
인터페이스에 MPLS 제품군 구성을
af적용하려는 경우 인터페이스가 구성된 두 GNF 모두에 명령을set interfaces af-name unit logical-unit-number family mpls적용할 수 있습니다af.샘플 구성은 Junos Node Slicing 샘플
af구성을 참조하십시오.
추상화된 패브릭 인터페이스의 서비스 등급
CoS(Class of Service) 패킷 분류는 패킷의 포워딩 클래스를 기반으로 수신 패킷을 출력 대기열에 할당합니다. 자세한 내용은 CoS 구성 가이드를 참조하십시오.
다음 섹션에서는 포워딩 클래스-대기열 매핑, 추상화된 패브릭(af) 인터페이스에서 지원되는 동작 집계(BA) 분류자 및 재작성에 대해 설명합니다.
포워딩 클래스-큐 매핑
af 인터페이스는 원격 패킷 전달 엔진에 지정된 트래픽이 여전히 두 개의 패브릭 대기열(낮음/높음 우선 순위)을 거쳐야 한다는 점을 제외하고 다른 인터페이스의 대부분의 기능을 갖춘 시뮬레이션된 WAN 인터페이스입니다.
현재 af 인터페이스는 2-대기열 모드에서만 작동합니다. 따라서 스케줄링, 폴리싱, 셰이핑과 같은 모든 대기열 기반 기능을 인터페이스에서 사용할 수 af 없습니다.
인터페이스의 패킷은 해당 패킷 af 이 속한 포워딩 클래스에 대해 구성된 패브릭 우선 순위에 따라 결정되는 패브릭 대기열을 상속합니다. 예를 들어, 대기열 맵 구성에 대한 다음 포워딩 클래스를 참조하십시오.
[편집]
user@router# show class-of-service forwarding-classes
class Economy queue-num 0 priority low; /* Low fabric priority */
class Stream queue-num 1;
class Business queue-num 2;
class Voice queue-num 3;
class NetControl queue-num 3;
class Business2 queue-num 4;
class Business3 queue-num 5;
class VoiceSig queue-num 6 priority high; /* High fabric priority */
class VoiceRTP queue-num 7;
앞의 예에서 볼 수 있듯이 패킷이 포워딩 클래스 VoiceSig로 분류되면 포워딩 경로의 코드는 해당 포워딩 클래스의 패브릭 우선순위를 검사하고 이 패킷에 대해 어떤 패브릭 대기열을 선택할지 결정합니다. 이 경우 우선 순위가 높은 패브릭 대기열이 선택됩니다.
BA 분류자 및 재작성
BA(Behavior Aggregate) 분류자는 CoS(Class of Service) 값을 포워딩 클래스 및 손실 우선순위에 매핑합니다. 포워딩 클래스와 손실 우선순위 조합은 라우터의 패킷에 부여되는 CoS 처리를 결정합니다. 다음 BA 분류자 및 재작성이 지원됩니다.
Inet-Precedence 분류자 및 재작성
DSCP 분류자 및 재작성
MPLS EXP 분류자 및 재작성
또한 MPLS 터널로 들어오는 IP 패킷에 대한 재작성을 적용하고 EXP 및 IPv4 서비스 유형(ToS) 비트의 재작성을 모두 수행할 수 있습니다. 이 접근 방식은 다른 일반 인터페이스에서와 마찬가지로 작동합니다.
IP v6 트래픽에 대한 DSCP v6 분류자 및 재작성
다음은 지원되지 않습니다.
IEEE 802.1 분류 및 재작성
IEEE 802.1ad(QinQ) 분류 및 재작성
CoS BA 분류자에 대한 자세한 내용은 CoS 구성 가이드를 참조하십시오.
추상화된 패브릭 인터페이스를 위한 패브릭 경로 최적화
패브릭 경로 최적화 모드를 구성하여 두 게스트 네트워크 기능(GNF) 사이에서 추상화된 패브릭(af) 인터페이스를 통해 흐르는 트래픽을 최적화할 수 있습니다. 이 기능은 패킷이 최종적으로 대상 패킷 전달 엔진에 도달하기 전에 추가 패브릭 홉(한 패킷 전달 엔진에서 다른 패킷 전달 엔진으로 트래픽 플로우 전환)을 방지하여 패브릭 대역폭 소비를 줄입니다. MPC9E 및 MX2K-MPC11E를 통해 MX2008, MX2010 및 MX2020에서 지원되는 패브릭 경로 최적화는 추상화된 패브릭 인터페이스 로드 밸런싱으로 인한 단일 추가 트래픽 홉만 방지합니다.
다음 패브릭 경로 최적화 모드 중 하나를 구성할 수 있습니다.
monitor- 이 모드를 구성하면, 피어 GNF는 트래픽 플로우를 모니터링하여 현재 트래픽이 전달되고 있는 패킷 전달 엔진과 최적화된 트래픽 경로를 제공할 수 있는 원하는 패킷 전달 엔진에 대한 정보를 소스 GNF에 보냅니다. 이 모드에서 소스 GNF는 원하는 패킷 전달 엔진으로 트래픽을 전달하지 않습니다.optimize- 이 모드를 구성하면, 피어 GNF는 트래픽 플로우를 모니터링하여 현재 트래픽이 전달되고 있는 패킷 전달 엔진과 최적화된 트래픽 경로를 제공할 수 있는 원하는 패킷 전달 엔진에 대한 정보를 소스 GNF에 보냅니다. 그런 다음 소스 GNF는 트래픽을 원하는 패킷 전달 엔진으로 전달합니다.
패브릭 경로 최적화 모드를 구성하려면 BSYS에서 다음 CLI 명령을 사용합니다.
user@router#set chassis network-slices guest-network-functions gnf id af-name collapsed-forward (monitor | optimize)user@router#commit
패브릭 경로 최적화를 구성한 후 GNF에서 명령을 show interfaces af-interface-name 사용하여 현재 최적/비최적 경로로 흐르는 패킷 수를 볼 수 있습니다.
또한보십시오
SNMP 트랩 지원: NMS 서버 구성(외부 서버 모델)
JDM(Juniper Device Manager)은 다음 SNMP 트랩을 지원합니다.
JDM 인터페이스에 대한 LinkUp 및 linkDown 트랩.
표준 linkUp/linkDown SNMP 트랩이 생성됩니다. 기본 커뮤니티 문자열
jdm이 사용됩니다.호스트 인터페이스에 대한 LinkUp/linkDown 트랩.
표준
linkUp/linkDownSNMP 트랩이 생성됩니다. 기본 커뮤니티 문자열host이 사용됩니다.JDM에서 JDM으로의 연결 손실/회복 트랩.
JDM에서 JDM으로의 연결 끊김/회복 트랩은 호스트 관리 인터페이스를 통해 일반 syslog 트랩(jnxSyslogTrap)을 사용하여 전송됩니다.
JDM 연결 다운 트랩
JDM_JDM_LINK_DOWN은 JDM이 또는cb1링크를 통해cb0다른 서버의 피어 JDM과 통신할 수 없을 때 전송됩니다. 다음 예를 참조하십시오.{ SNMPv2c C=host { V2Trap(296) R=1299287309 .1.3.6.1.2.1.1.3.0=42761992 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.2636.4.12.0.1 .1.3.6.1.4.1.2636.3.35.1.1.1.2.1="JDM_JDM_LINK_DOWN" .1.3.6.1.4.1.2636.3.35.1.1.1.3.1="" .1.3.6.1.4.1.2636.3.35.1.1.1.4.1=5 .1.3.6.1.4.1.2636.3.35.1.1.1.5.1=24 .1.3.6.1.4.1.2636.3.35.1.1.1.6.1=0 .1.3.6.1.4.1.2636.3.35.1.1.1.7.1="jdmmon" .1.3.6.1.4.1.2636.3.35.1.1.1.8.1="JDM-HOST" .1.3.6.1.4.1.2636.3.35.1.1.1.9.1="JDM to JDM Connection Lost" .1.3.6.1.6.3.1.1.4.3.0.0=”” } }JDM-JDM 연결 업 트랩
JDM_JDM_LINK_UP은 또는cb1링크가 나타나면 전송cb0되고 두 서버의 JDM이 다시 통신할 수 있습니다. 다음 예를 참조하십시오.{ SNMPv2c C=host { V2Trap(292) R=998879760 .1.3.6.1.2.1.1.3.0=42762230 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.2636.4.12.0.1 .1.3.6.1.4.1.2636.3.35.1.1.1.2.1="JDM_JDM_LINK_UP" .1.3.6.1.4.1.2636.3.35.1.1.1.3.1="" .1.3.6.1.4.1.2636.3.35.1.1.1.4.1=5 .1.3.6.1.4.1.2636.3.35.1.1.1.5.1=24 .1.3.6.1.4.1.2636.3.35.1.1.1.6.1=0 .1.3.6.1.4.1.2636.3.35.1.1.1.7.1="jdmmon" .1.3.6.1.4.1.2636.3.35.1.1.1.8.1="JDM-HOST" .1.3.6.1.4.1.2636.3.35.1.1.1.9.1="JDM to JDM Connection Up" .1.3.6.1.6.3.1.1.4.3.0.0="" } }VM(GNF) up/down -
libvirtGuestNotif알림.GNF 시작/종료 이벤트의 경우 표준
libvirtGuestNotif알림이 생성됩니다. 알림에 대한 자세한 내용은libvirtMIB이 웹 페이지를 참조하십시오. 또한 다음 예를 참조하십시오.HOST [UDP: [127.0.0.1]:53568->[127.0.0.1]]: Trap , DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (636682) 1:46:06.82, SNMPv2-MIB::snmpTrapOID.0 = OID: LIBVIRT-MIB::libvirtGuestNotif, LIBVIRT-MIB::libvirtGuestName.0 = STRING: "gnf1", LIBVIRT-MIB::libvirtGuestUUID.1 = STRING: 7ad4bc2a-16db-d8c0-1f5a-6cb777e17cd8, LIBVIRT-MIB::libvirtGuestState.2 = INTEGER: running(1), LIBVIRT-MIB::libvirtGuestRowStatus.3 = INTEGER: active(1)
SNMP 트랩은 대상 NMS 서버로 전송됩니다. JDM에서 대상 NMS 서버 세부 정보를 구성하려면 다음 예를 참조하십시오.
[편집]
root@jdm#show snmp | display setroot@jdm#set snmp name nameroot@jdm#set snmp description descriptionroot@jdm#set snmp location locationroot@jdm#set snmp contact user's emailroot@jdm#set snmp trap-group tg-1 targets target ip address1root@jdm#set snmp trap-group tg-1 targets target ip address2
JDM은 호스트 snmp 구성 파일(/etc/snmp/snmpd.conf)에 구성을 쓰지 않습니다. 따라서 JDM 설치 및 후속 구성은 호스트 SNMP에 영향을 미치지 않습니다. JDM의 SNMP 구성 CLI 명령은 컨테이너 내에 있는 JDM의 snmpd.conf 파일을 구성하는 데만 사용됩니다. linkUp/Down 트랩을 생성하려면 호스트 서버의 snmpd.conf 파일(/etc/snmp/snmpd.conf)에 다음 예와 같이 구성을 수동으로 포함해야 합니다.
createUser trapUser iquerySecName trapUser rouser trapUser defaultMonitors yes notificationEvent linkUpTrap linkUp ifIndex ifAdminStatus ifOperStatus ifDescr notificationEvent linkDownTrap linkDown ifIndex ifAdminStatus ifOperStatus ifDescr monitor -r 10 -e linkUpTrap "Generate linkUp" ifOperStatus != 2 monitor -r 10 -e linkDownTrap "Generate linkDown" ifOperStatus == 2 trap2sink <NMS-IP> host
위의 예에서 <NMS-IP>를 NMS(Network Management Station)의 IP 주소로 바꿉니다.
BSYS 및 GNF의 섀시 구성 계층
Junos Node Slicing에서 BSYS는 라인 카드와 패브릭을 포함하여 라우터의 모든 물리적 구성 요소를 소유하는 반면, GNF는 각각의 라인 카드에서 포워딩 상태를 유지합니다. 이러한 분할 책임에 따라 계층 아래(있는 경우) 아래의 chassis Junos CLI 구성을 다음과 같이 BSYS 또는 GNF에 적용해야 합니다.
구성 계층 아래의
chassis물리적 수준 매개 변수는 BSYS에서 적용되어야 합니다. 예를 들어, FPC에서 물리적 오류를 처리하기 위한 구성은 물리적 수준 매개 변수이므로 BSYS에 적용해야 합니다.At BSYS Junos CLI: [edit] user@router#
set chassis fpc fpc slot error major threshold threshold value action alarm구성 계층 아래의
chassis논리적 또는 기능 수준 매개 변수는 FPC와 연결된 GNF에 적용되어야 합니다. 예를 들어, 라인 카드당 max-queues 구성은 논리 수준 매개 변수이므로 GNF에서 적용해야 합니다.At GNF Junos CLI: [edit] user@router#
set chassis fpc fpc slot max-queues value예외로, 구성 계층 아래의
chassis다음 두 매개 변수는 BSYS와 GNF 모두에 적용되어야 합니다.At both BSYS and GNF CLI: [edit] user@router#
set chassis network-services network services modeuser@router#set chassis fpc fpc slot flexible-queueing-mode
하위 라인 카드 구성 및 GNF에 할당
서브 라인 카드에 대한 개요는 서브 라인 카드 개요를 참조하십시오.
-
이 기능은 외부 서버 기반 Junos 노드 슬라이싱 설정에 사용되는 MX2010 및 MX2020 라우터의 MPC11E 라인 카드(모델 번호: MX2K-MPC11E)에 적용됩니다.
-
모든 GNF 및 BSYS의 각 라우팅 엔진이 Junos OS 릴리스 21.2R1 이상 버전을 실행하는지 확인합니다.
MPC11E를 서브 라인 카드(SLC)로 더 슬라이스하려면 BSYS의 계층 구조에서 fpc-slice CLI 옵션을 set chassis network-slices guest-network-functions gnf 사용해야 합니다.
구성을 커밋하기 전에 라인 카드에서 지원하는 모든 SLC를 구성하고 코어, DRAM 및 패킷 전달 엔진과 같은 모든 필수 리소스를 SLC에 할당해야 합니다. MPC11E 라인 카드는 2개의 SLC를 지원합니다.
GNF는 다음과 같은 전체 라인 카드와 SLC 조합을 지원합니다.
-
MPC11E SLC를 사용하는 GNF
-
MPC11E SLC 및 MPC9를 사용하는 GNF
-
MPC11E SLC 및 MPC11E를 사용하는 GNF
-
MPC11E SLC가 있는 GNF, MPC9, MPC11E
SLC를 구성하고 GNF에 할당하려면 다음 단계를 따르십시오.
-
모든 SLC에 대해 다음의 모든 CLI 문을 한 번에 구성해야 합니다(아래 단계 참조). 나중에 이 컨피그레이션을 수정하면 전체 라인 카드가 재부팅됩니다.
- 잘못된 값(예: 지원되지 않는 패킷 전달 엔진 범위, CPU 코어 또는 DRAM 값)을 구성하면 오류를 나타내는 적절한 메시지와 함께 구성 커밋이 실패합니다.
또한보십시오
Junos 노드 슬라이싱을 위한 샘플 구성
이 섹션에서는 Junos 노드 슬라이싱을 위한 샘플 구성을 제공합니다.
- 샘플 JDM 구성(외부 서버 모델)
- 샘플 JDM 구성(섀시 내 모델)
- 추상화된 패브릭 인터페이스를 사용한 샘플 BSYS 구성
- 서비스 등급이 적용된 GNF의 추상화된 패브릭 구성 샘플
- GNF에서 추상화된 패브릭 인터페이스 상태에 대한 샘플 출력
샘플 JDM 구성(외부 서버 모델)
root@test-jdm-server0> show configuration
groups {
server0 {
system {
host-name test-jdm-server0;
}
server {
interfaces {
cb0 p3p1;
cb1 p3p2;
jdm-management em2;
vnf-management em3;
}
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.112/21;
}
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
server1 {
system {
host-name test-jdm-server1;
}
server {
interfaces {
cb0 p3p1;
cb1 p3p2;
jdm-management em2;
vnf-management em3;
}
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.113/21;
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
}
}
apply-groups [ server0 server1 ];
system {
root-authentication {
encrypted-password "..."; ## SECRET-DATA
}
services {
ssh;
netconf {
ssh;
rfc-compliant;
}
}
}
virtual-network-functions {
test-gnf {
id 1;
chassis-type mx2020;
resource-template 2core-16g;
base-config /var/jdm-usr/gnf-config/test-gnf.conf;
}
}
샘플 JDM 구성(섀시 내 모델)
root@test-jdm-server0> show configuration
groups {
server0 {
system {
host-name test-jdm-server0;
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.112/21;
}
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
server1 {
system {
host-name test-jdm-server1;
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.113/21;
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
}
}
apply-groups [ server0 server1 ];
system {
root-authentication {
encrypted-password "..."; ## SECRET-DATA
}
services {
ssh;
netconf {
ssh;
rfc-compliant;
}
}
}
virtual-network-functions {
test-gnf {
id 1;
resource-template 2core-16g;
base-config /var/jdm-usr/gnf-config/test-gnf.conf;
}
}
추상화된 패브릭 인터페이스를 사용한 샘플 BSYS 구성
user@router> show configuration chassis
network-slices {
guest-network-functions {
gnf 1 {
af2 {
peer-gnf id 2 af1;
}
af4 {
peer-gnf id 4 af1;
}
description gnf-a;
fpcs [ 0 19];
}
gnf 2 {
af1 {
peer-gnf id 1 af2;
}
af4 {
peer-gnf id 4 af2;
}
description gnf-b;
fpcs [ 1 6 ];
}
gnf 4 {
af1 {
peer-gnf id 1 af4;
}
af2 {
peer-gnf id 2 af4;
}
description gnf-d;
fpcs [ 3 4 ];
}
}
}
서비스 등급이 적용된 GNF의 추상화된 패브릭 구성 샘플
GNF1과 GNF2 사이에 추상화된 패브릭(af) 인터페이스가 있다고 가정합니다. 다음 샘플 구성은 트래픽이 GNF1에서 GNF2로 들어오는 시나리오에서 GNF1의 인터페이스에 재작성 af 을 적용하고 GNF2의 인터페이스에 분류기를 af 적용하는 방법을 보여줍니다.
GNF1 Configuration
interfaces {
xe-4/0/0 {
unit 0 {
family inet {
address 22.1.2.2/24;
}
}
}
af2 {
unit 0 {
family inet {
address 32.1.2.1/24;
}
}
}
}
class-of-service {
classifiers {
dscp testdscp {
forwarding-class assured-forwarding {
loss-priority low code-points [ 001001 000000 ];
}
}
}
interfaces {
xe-4/0/0 {
unit 0 {
classifiers {
dscp testdscp;
}
}
classifiers {
dscp testdscp;
}
}
af1 {
unit 0 {
rewrite-rules {
dscp testdscp; /*Rewrite rule applied on egress AF interface on GNF1.*/
}
}
}
}
rewrite-rules {
dscp testdscp {
forwarding-class assured-forwarding {
loss-priority low code-point 001001;
}
}
}
}
GNF2 Configuration
interfaces {
xe-3/0/0:0 {
unit 0 {
family inet {
address 42.1.2.1/24;
}
}
}
af1 {
unit 0 {
family inet {
address 32.1.2.2/24;
}
}
}
}
class-of-service {
classifiers {
dscp testdscp {
forwarding-class network-control {
loss-priority low code-points 001001;
}
}
}
interfaces {
af1 {
unit 0 {
classifiers {
dscp testdscp; /*Classifier applied on AF at ingress of GNF2*/
}
}
}
}
}
GNF에서 추상화된 패브릭 인터페이스 상태에 대한 샘플 출력
user@router-gnf-b> show interfaces af9
Physical interface: af9, Enabled, Physical link is Up
Interface index: 209, SNMP ifIndex: 527
Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Speed: 370000mbps
Device flags : Present Running
Interface flags: Internal: 0x4000
Link type : Full-Duplex
Link flags : None
Current address: 00:90:69:2b:00:4c, Hardware address: 00:90:69:2b:00:4c
Last flapped : 2018-09-12 01:44:01 PDT (00:01:02 ago)
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
Bandwidth : 370 Gbps
Peer GNF id : 9
Peer GNF Forwarding element(FE) view :
FPC slot:FE num FE Bandwidth(Gbps) Status Transmit Packets Transmit Bytes
6:0 130 Up 0 0
12:0 120 Up 0 0
12:1 120 Up 0 0
Residual Transmit Statistics :
Packets : 0 Bytes : 0
Fabric Queue Statistics :
FPC slot:FE num High priority(pkts) Low priority(pkts)
6:0 0 0
12:0 0 0
12:1 0 0
FPC slot:FE num High priority(bytes) Low priority(bytes)
6:0 0 0
12:0 0 0
12:1 0 0
Residual Queue Statistics :
High priority(pkts) Low priority(pkts)
0 0
High priority(bytes) Low priority(bytes)
0 0
Logical interface af9.0 (Index 332) (SNMP ifIndex 528)
Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2
Input packets : 0
Output packets: 13
Protocol inet, MTU: 1500
하위 라인 카드에 대한 샘플 구성
이 섹션에서는 SLC(Sub Line Card)에 대한 샘플 구성을 제공합니다.
대칭 서브 라인 카드 프로파일에 대한 샘플 구성
대칭 프로필에서는 한 가지 리소스 조합만 가능합니다.
다음은 대칭 하위 라인 카드 프로필에서 FPC 1(MPC11E)을 슬라이스하는 샘플 구성입니다.
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 pfe-id-list 0-3set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 cores 4set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 dram 13set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 pfe-id-list 4-7set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 cores 4set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 dram 13
이 구성은 아래와 같이 나타납니다.
root@bsys> show chassis network-slices guest-network-functions
gnf 1{
fpc-slice {
fpc 1{
slc 1{
pfe-id-list 0-3;
cores 4;
dram 13;
}
}
}
}
gnf 2{
fpc-slice {
fpc 1{
slc 2{
pfe-id-list 4-7;
cores 4;
dram 13;
}
}
}
}
비대칭 서브 라인 카드 프로파일에 대한 샘플 구성
비대칭 프로필에서는 PFE 또는 패킷 전달 엔진[0-7]이 두 SLC 간에 분할되는 방식에 따라 두 가지 구성이 가능합니다. 한 가지 예시 구성에서, 처음 두 개의 패킷 전달 엔진[0-1]은 하나의 SLC에 할당되고 나머지 패킷 전달 엔진[2-7]은 다른 SLC에 할당됩니다. 다른 예제 구성에서는 마지막 두 개의 패킷 전달 엔진[6-7]이 하나의 SLC에 할당되고 나머지 패킷 전달 엔진[0-5]은 다른 SLC에 할당됩니다.
아래 샘플 구성은 [0-1 2-7] 분할의 예입니다.
아래 예에서 SLC에 대한 CPU 코어 및 DRAM 할당은 서브 라인 카드 개요 페이지의 MPC11E에서 지원하는 SLC 프로파일 표에 표시된 대로 '비대칭 프로파일' 리소스 조합 아래의 열 중 하나와 일치합니다.
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 pfe-id-list 0-1set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 cores 4set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 dram 17set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 pfe-id-list 2-7set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 cores 4set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 dram 9
이 구성은 다음과 같이 나타납니다.
root@bsys> show chassis network-slices guest-network-functions
gnf 1{
fpc-slice {
fpc 1{
slc 1{
pfe-id-list 0-1;
cores 4;
dram 17;
}
}
}
}
gnf 2{
fpc-slice {
fpc 1{
slc 2{
pfe-id-list 2-7;
cores 4;
dram 9;
}
}
}
}