Junos Node Slicing 이해
Junos Node Slicing 개요
Junos Node Slicing을 사용하면 서비스 프로바이더 및 대기업에서 여러 라우팅 기능을 하나의 물리적 디바이스로 통합하는 네트워크 인프라를 구축할 수 있습니다. 이는 관련된 운영 복잡성을 피하면서 단일 물리적 인프라에서 여러 서비스를 호스팅하는 데 도움이 됩니다. 또한 디바이스에서 호스팅되는 기능의 운영, 기능 및 관리 분리를 유지합니다.
Junos Node Slicing을 사용하면 하나의 물리적 MX 시리즈 라우터에 여러 파티션을 생성할 수 있습니다. 이러한 파티션을 게스트 네트워크 기능(GNF)이라고 합니다. 각 GNF는 자체 전용 컨트롤 플레인, 데이터 플레인 및 관리 플레인을 갖춘 독립적인 라우터처럼 작동합니다. 이를 통해 단일 컨버지드 MX 시리즈 라우터에서 여러 서비스를 실행하는 동시에 서비스 간의 운영 격리를 유지할 수 있습니다. 동일한 물리적 디바이스를 활용하여 컨트롤 플레인 또는 포워딩 플레인을 공유하지 않고 동일한 섀시, 공간 및 전원만 공유하는 병렬 파티션을 생성할 수 있습니다.
또한 최고급 이더넷 인터페이스처럼 작동하는 의사 인터페이스인 추상화된 패브릭(af) 인터페이스를 사용하여 스위치 패브릭을 통해 GNF 간에 트래픽을 전송할 수도 있습니다. 추상화된 패브릭 인터페이스는 GNF 간의 라우팅 제어, 데이터 및 관리 트래픽을 용이하게 합니다.
Junos Node Slicing은 외부 서버 모델과 섀시 내 모델의 두 가지 모델을 제공합니다. 외부 서버 모델에서 GNF는 한 쌍의 업계 표준 x86 서버에서 호스팅됩니다. 섀시 내 모델의 경우 GNF는 MX 시리즈 라우터 자체의 라우팅 엔진에서 호스팅됩니다.
Junos Node Slicing은 멀티버전 소프트웨어 호환성을 지원하므로 GNF를 독립적으로 업그레이드할 수 있습니다.
Junos Node Slicing의 이점
Converged network—Junos Node Slicing을 통해 서비스 프로바이더는 비디오 에지 및 음성 에지와 같은 여러 네트워크 서비스를 하나의 물리적 라우터로 통합하는 동시에 이들 서비스 간의 운영 분리를 유지할 수 있습니다. 수평 및 수직 수렴을 모두 달성할 수 있습니다. 수평 컨버전스는 동일한 레이어의 라우터 기능을 단일 라우터에 통합하고, 수직 컨버전스는 서로 다른 레이어의 라우터 기능을 단일 라우터로 축소합니다.
Improved scalability—물리적 디바이스 대신 가상 라우팅 파티션에 집중함으로써 네트워크의 프로그래밍 가능성과 확장성이 향상되어 서비스 프로바이더와 기업이 추가 하드웨어를 구매하지 않고도 인프라 요구 사항에 대응할 수 있습니다.
Easy risk management—여러 네트워크 기능이 단일 섀시에 통합되지만 모든 기능이 독립적으로 실행되므로 운영, 기능 및 관리 분리의 이점을 누릴 수 있습니다. BNG(Broadband Network Gateway)와 같은 물리적 시스템을 여러 개의 독립적인 논리적 인스턴스로 분할하면 장애가 격리됩니다. 파티션은 컨트롤 플레인이나 포워딩 플레인을 공유하지 않고 동일한 섀시, 공간 및 전원만 공유합니다. 즉, 한 파티션에서 장애가 발생하더라도 광범위한 서비스 중단이 발생하지 않습니다.
Reduced network costs—Junos Node Slicing은 내부 스위칭 패브릭을 통해 GNF의 상호 연결을 지원하며, 이는 최고 수준의 이더넷 인터페이스 동작을 나타내는 의사 인터페이스인 추상화된 패브릭(
af) 인터페이스를 활용합니다.af인터페이스를 구축한 기업은 더 이상 물리적 인터페이스에 의존하지 않아도 GNF를 연결할 수 있으므로 상당한 비용을 절감할 수 있습니다.Reduced time-to-market for new services and capabilities—각 GNF는 서로 다른 Junos 소프트웨어 버전에서 운영할 수 있습니다. 이러한 이점을 통해 기업은 각 GNF를 각자의 속도에 맞게 발전시킬 수 있습니다. 새로운 서비스 또는 기능을 특정 GNF에 구축해야 하고 새로운 소프트웨어 릴리스가 필요한 경우 관련된 GNF에만 업데이트가 필요합니다. 또한 향상된 민첩성과 함께 Junos Node Slicing을 통해 서비스 프로바이더와 기업은 매우 유연한 Everything-as-a-service 비즈니스 모델을 도입하여 끊임없이 변화하는 시장 상황에 신속하게 대응할 수 있습니다.
Junos Node Slicing의 구성 요소
Junos Node Slicing을 사용하면 단일 MX 시리즈 라우터를 분할하여 여러 개의 독립적인 라우터처럼 보이게 할 수 있습니다. 각 파티션에는 가상 머신(VM)으로 실행되는 자체 Junos OS 컨트롤 플레인과 전용 라인 카드 세트가 있습니다. 각 파티션을 게스트 네트워크 함수(GNF)라고 합니다.
MX 시리즈 라우터는 기본 시스템(BSYS) 역할을 합니다. BSYS는 라인 카드와 스위칭 패브릭을 포함하여 라우터의 모든 물리적 구성 요소를 소유합니다. BSYS는 라인 카드를 GNF에 할당합니다.
JDM(Juniper Device Manager) 소프트웨어는 GNF VM을 오케스트레이션합니다. JDM에서는 GNF VM을 VNF(가상 네트워크 기능)라고 합니다. 따라서 GNF는 VNF와 라인 카드 세트로 구성됩니다.
BSYS의 구성을 통해 섀시의 라인 카드를 다른 GNF에 할당할 수 있습니다. 또한 라인 카드 유형에 따라 라인 카드 내의 PFE 세트를 다른 GNF에 할당할 수도 있습니다. 자세한 내용은 서브 라인 카드 개요를 참조하십시오.
Junos Node Slicing은 다음 두 가지 모델을 지원합니다.
외부 서버 모델
섀시 내 모델
외부 서버 모델에서 JDM 및 VNF는 한 쌍의 외부 업계 표준 x86 서버에서 호스팅됩니다.
그림 1 은 외부 서버에서 실행되는 전용 라인 카드가 있는 3개의 GNF를 보여줍니다.
GNF
MX 시리즈 라우터를 한 쌍의 외부 x86 서버에 연결하는 방법에 대한 자세한 내용은 서버와 라우터 연결을 참조하십시오.
섀시 내 모델에서는 모든 구성 요소(JDM, BSYS 및 GNF)가 MX 시리즈 라우터의 라우팅 엔진 내에서 실행됩니다. 그림 2를 참조하십시오.
베이스 시스템(BSYS)
Junos Node Slicing에서 MX 시리즈 라우터는 기본 시스템(BSYS) 역할을 합니다. BSYS는 모든 라인 카드와 패브릭을 포함하여 라우터의 모든 물리적 구성 요소를 소유합니다. BSYS의 Junos OS 구성을 통해 라인 카드를 GNF에 할당하고 GNF 간에 추상화된 패브릭(af) 인터페이스를 정의할 수 있습니다. BSYS 소프트웨어는 MX 시리즈 라우터의 한 쌍의 중복 라우팅 엔진에서 실행됩니다.
게스트 네트워크 기능(GNF)
게스트 네트워크 기능(GNF)은 기본 시스템(BSYS)에 의해 할당된 라인 카드를 논리적으로 소유하고 라인 카드의 포워딩 상태를 유지합니다. MX 시리즈 라우터에서 여러 GNF를 구성할 수 있습니다( 게스트 네트워크 기능 구성하기 참조). 각 GNF의 Junos OS 컨트롤 플레인은 가상 머신(VM)으로 실행됩니다. JDM(Juniper Device Manager) 소프트웨어는 GNF VM을 오케스트레이션합니다. JDM 컨텍스트에서 GNF는 가상 네트워크 기능(VNF)이라고 합니다.
GNF는 독립형 라우터와 동일합니다. GNF는 독립적으로 구성 및 관리되며 운영상 서로 격리됩니다.
GNF를 생성하려면 BSYS와 JDM에서 각각 하나씩 두 개의 구성 세트가 필요합니다.
GNF는 ID로 정의됩니다. 이 ID는 BSYS 및 JDM에서 동일해야 합니다.
GNF 컨피그레이션의 BSYS 부분은 ID와 라인 카드 세트를 제공하는 것으로 구성됩니다.
GNF 구성의 JDM 부분은 다음 속성을 지정하는 것으로 구성됩니다.
VNF 이름입니다.
GNF ID입니다. 이 ID는 BSYS에서 사용되는 GNF ID와 동일해야 합니다.
MX 시리즈 플랫폼 유형(외부 서버 모델용).
VNF에 사용될 Junos OS 이미지.
VNF 서버 리소스 템플릿입니다.
서버 리소스 템플릿은 전용(물리적) CPU 코어 수와 GNF에 할당할 DRAM의 크기를 정의합니다. GNF에 사용할 수 있는 사전 정의된 서버 리소스 템플릿 목록은 Junos 노드 슬라이싱을 위한 최소 하드웨어 및 소프트웨어 요구 사항의 서버 하드웨어 리소스 요구 사항(GNF당) 섹션을 참조하십시오.
GNF가 구성되면 GNF의 가상 콘솔 포트에 연결하여 액세스할 수 있습니다. 그런 다음 GNF에서 Junos OS CLI를 사용하여 호스트 이름 및 관리 IP 주소와 같은 GNF 시스템 속성을 구성한 후 관리 포트를 통해 액세스할 수 있습니다.
주니퍼 디바이스 매니저(JDM)
가상화된 Linux 컨테이너인 JDM(Juniper Device Manager)을 사용하면 GNF VM을 프로비저닝하고 관리할 수 있습니다.
JDM은 Junos OS와 유사한 CLI, 구성 및 관리를 위한 NETCONF 및 모니터링을 위한 SNMP를 지원합니다.
섀시 내 모델에서 JDM은 SNMP를 지원하지 않습니다.
JDM 인스턴스는 외부 서버 모델의 각 x86 서버와 섀시 내 모델의 각 라우팅 엔진에서 호스팅됩니다. JDM 인스턴스는 일반적으로 GNF 구성을 동기화하는 피어로 구성됩니다: 한 서버에서 GNF VM이 생성되면 해당 백업 VM이 다른 서버 또는 라우팅 엔진에 자동으로 생성됩니다.
JDM에서 IP 주소 및 관리자 계정을 구성해야 합니다. 이러한 항목이 구성되면 JDM에 직접 로그인할 수 있습니다.
또한보십시오
추상화된 패브릭 인터페이스
추상화된 패브릭(af) 인터페이스는 퍼스트 클래스 이더넷 인터페이스 동작을 나타내는 의사 인터페이스입니다. af 인터페이스는 스위치 패브릭을 통해 게스트 네트워크 기능(GNF) 간의 라우팅 제어 및 관리 트래픽을 용이하게 합니다. af 두 GNF가 서로 연결되도록 구성되면 피어 GNF와 통신하기 위해 GNF에 인터페이스가 생성됩니다. 추상화된 패브릭 인터페이스는 BSYS에서 생성해야 합니다. 인터페이스의 대역폭 af 은 원격 라인 카드/MPC의 삽입 또는 도달 가능성에 따라 동적으로 변경됩니다. 패브릭은 GNF af 간의 통신 매체이기 때문에 인터페이스는 동등한 WAN 인터페이스로 간주됩니다. 그림 3을 참조하십시오.
추상화된 패브릭 인터페이스 대역폭 이해하기
추상화된 패브릭(af) 인터페이스는 패브릭을 통해 두 개의 GNF를 연결하고 두 개의 GNF를 연결하는 모든 패킷 포워딩 엔진(PFE)을 집계합니다. af 인터페이스는 인터페이스에 속한 각 패킷 전달 엔진의 대역폭 합계를 af 활용할 수 있습니다.
예를 들어, GNF1에 1개의 MPC8(각각 240Gbps 용량의 패킷 포워딩 엔진 4개가 있음)이 있고 GNF1이 인터페이스(af1 및 af2)를 사용하여 af GNF2 및 GNF3와 연결된 경우 GNF1의 최대 af 인터페이스 용량은 4x240Gbps = 960Gbps가 됩니다.
GNF1—af1——GNF2
GNF1—af2——GNF3
여기서 af1과 af2는 960Gbps 용량을 공유합니다.
각 MPC에서 지원되는 대역폭에 대한 정보는 표 1을 참조하십시오.
추상화된 패브릭 인터페이스에서 지원되는 기능
추상화된 패브릭 인터페이스는 다음과 같은 기능을 지원합니다.
통합 ISSU(in-service software upgrade)
BSYS 수준의 하이퍼 모드 구성(Junos OS 릴리스 19.3R2부터 시작). 이 기능은 MPC6E, MPC8E, MPC9E 및 MPC11E 라인 카드에서 지원됩니다.
메모:개별 GNF는 BSYS에서 구성을 상속하므로 서로 다른 하이퍼 모드 구성을 가질 수 없습니다.
SFB3를 사용하는 MX2020 및 MX2010 라우터는 기본적으로 하이퍼 모드로 작동합니다. GNF에서 하이퍼 모드를 비활성화해야 하는 경우 BSYS에서 구성해야 하며 해당 섀시의 모든 GNF에 적용됩니다.
존재하는 원격 GNF 라인 카드를 기반으로 하는 로드 밸런싱
CoS(Class of Service) 지원:
Inet-precedence 분류자 및 재작성
DSCP 분류자 및 재작성
MPLS EXP 분류자 및 재작성
IP v6 트래픽에 대한 DSCP v6 분류자 및 재작성
OSPF, IS-IS, BGP, OSPFv3 프로토콜 및 L3VPN 지원
메모:비
af인터페이스는 Junos OS에서 작동하는 모든 프로토콜을 지원합니다.-
Junos OS 릴리스 24.2R1부터 BGP, IS-IS, OSPF를 위한 BFD.
멀티캐스트 포워딩
GRES(Graceful Routing Engine Switchover)
인터페이스가 코어 인터페이스 역할을 하는
afMPLS 애플리케이션(L3VPN, VPLS, L2VPN, L2CKT, EVPN 및 IP over MPLS)지원되는 프로토콜 계열은 다음과 같습니다.
IPv4 포워딩
IPv6 포워딩
증권 시세 표시기
ISO 인증
증권 시세 표시기
JTI(Junos Telemetry Interface) 센서 지원
Junos OS 릴리스 19.1R1부터 게스트 네트워크 기능(GNF)은 가상 확장형 LAN 프로토콜(VXLAN) 캡슐화를 통해 이더넷 VPN(EVPN)을 지원합니다. 이 지원은 비
af(즉, 물리적) 인터페이스 및af코어 대면 인터페이스로서의 인터페이스에서 사용할 수 있습니다. MPC11E 라인 카드에는 이 지원을 사용할 수 없습니다.af인터페이스 구성을 통해 GNF는 -지원 MPC를 지원합니다af. 표 1 에는 -capable MPCs, MPC당 지원되는 PFE 수 및 MPC당 지원되는 대역폭이 나와af있습니다.표 1: 지원되는 추상화된 패브릭 지원 MPC 증권 시세 표시기
초기 릴리스
PFE 수
총 대역폭
MPC7E-MRATE
17.4R1
2
480G(240*2)
MPC7E-10G
17.4R1
2
480G(240*2)
MX2K-MPC8E
17.4R1
4
960G(240*4)
MX2K-MPC9E
17.4R1
4
1.6T(400*4)
MPC2E
19.1R1
2
80 (40*2)
MPC2E NG
17.4R1
1
80지
MPC2E NG Q
17.4R1
1
80지
MPC3E
19.1R1
1
130지
MPC3E NG
17.4R1
1
130지
MPC3E NG Q
17.4R1
1
130지
32x10GE MPC4E
19.1R1
2
260G(130*2)
2x100GE + 8x10GE MPC4E
19.1R1
2
260G(130*2)
MPC5E-40G10G
18.3R1
2
240G(120*2)
MPC5EQ-40G10G
18.3R1
2
240G(120*2)
MPC5E-40G100G
18.3R1
2
240G(120*2)
MPC5EQ-40G100G
18.3R1
2
240G(120*2)
MX2K-MPC6E
18.3R1
4
520G(130*4)
멀티서비스 MPC(MS-MPC)
19.1R1
1
120지
16x10GE MPC
19.1R1
4
160G(40*4)
MX2K-MPC11E
19.3R2
8
4티(500G*8)
XE/GE 인터페이스에서 허용되는 최대값에 맞추기 위해 인터페이스의 MTU 설정을 af 설정하는 것이 좋습니다. 이렇게 하면 인터페이스를 통한 패킷의 단편화가 최소화되거나 af 전혀 보장되지 않습니다.
추상화된 패브릭 인터페이스 제한
다음은 추상화된 패브릭 인터페이스의 현재 제한 사항입니다.
단일 엔드포인트
af인터페이스,af인터페이스-GNF 매핑 불일치 또는 동일한 원격 GNF에 대한 다중af인터페이스 매핑과 같은 구성은 BSYS에서 커밋하는 동안 확인되지 않습니다. 구성이 올바른지 확인합니다.대역폭 할당은 MPC 유형에 따라 정적입니다.
원격 GNF에서 호스팅되는 MPC를 오프라인/재시작하는 동안 트래픽 드롭(전송 및 호스트 모두)이 최소화될 수 있습니다.
-capable MPC
af와 -capable 가 아닌 MPCaf간의 상호 운용성은 지원되지 않습니다.
또한보십시오
추상화된 패브릭 인터페이스를 위한 패브릭 경로 최적화
패브릭 경로 최적화 모드를 구성하여 두 게스트 네트워크 기능(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 사용하여 현재 최적/비최적 경로로 흐르는 패킷 수를 볼 수 있습니다.
또한보십시오
외부 서버 모델과 섀시 내 모델 중에서 선택
외부 서버 모델을 사용하면 GNF 요구 사항에 맞는 충분한 용량의 서버를 선택할 수 있으므로 더 높은 규모로 더 많은 GNF 인스턴스를 구성할 수 있습니다. 섀시 내 모델을 통해 구성할 수 있는 GNF의 수는 구성 GNF의 확장 요구 사항과 라우팅 엔진의 전체 용량에 따라 결정됩니다.
Junos Node Slicing의 외부 서버 및 섀시 내 모델은 상호 배타적입니다. MX 시리즈 라우터는 한 번에 이러한 모델 중 하나에서만 작동하도록 구성할 수 있습니다.
BSYS와 GNF의 기본 역할 동작
다음 섹션에서는 라우팅 엔진 이중화의 맥락에서 BSYS 및 GNF의 주요 역할 동작에 대해 설명합니다.
그림 4 는 라우팅 엔진 이중화를 통한 GNF 및 BSYS의 기본 역할 동작을 보여줍니다.
BSYS 주요 역할
BSYS 라우팅 엔진 기본 역할 중재 동작은 MX 시리즈 라우터의 라우팅 엔진 동작과 동일합니다.
GNF 주요 역할
GNF VM 기본 역할 중재 동작은 MX 시리즈 라우팅 엔진의 동작과 유사합니다. 각 GNF는 VM의 기본 백업 쌍으로 실행됩니다. 에서 server0 실행되는(또는 re0 섀시 내용) GNF VM은 MX 시리즈 라우터의 라우팅 엔진 슬롯 0과 동일하며, 에서 server1 (또는 re1 섀시 내용) 실행되는 GNF VM은 MX 시리즈 라우터의 라우팅 엔진 슬롯 1과 동일합니다.
GNF 기본 역할은 BSYS 기본 역할 및 다른 GNF의 기본 역할과 독립적입니다. GNF 주요 역할 중재는 Junos OS를 통해 이루어집니다. 연결 실패 조건 하에서 GNF 기본 역할은 보수적으로 처리됩니다.
GNF 기본 역할 모델은 외부 서버 모델과 섀시 내 모델 모두에서 동일합니다.
MX 시리즈 라우팅 엔진과 마찬가지로 각 GNF에서 GRES(Graceful Routing Engine Switchover)를 구성해야 합니다. 이는 기본 GNF VM이 실패하거나 재부팅될 때 백업 GNF VM이 자동으로 기본 역할을 인수하기 위한 전제 조건입니다.
Junos Node Slicing 관리자 역할
다음 관리자 역할을 사용하여 노드 슬라이싱 작업을 수행할 수 있습니다.
BSYS 관리자 - 물리적 섀시 및 GNF 프로비저닝(GNF에 라인 카드 할당)을 담당합니다. Junos OS CLI 명령은 이러한 작업에 사용할 수 있습니다.
GNF 관리자 - GNF에서 Junos OS의 구성, 운영 및 관리를 책임집니다. 이러한 작업을 위해 GNF 관리자는 모든 일반 Junos OS CLI 명령을 사용할 수 있습니다.
JDM 관리자 - JDM 서버 포트 구성(외부 서버 모델의 경우)과 GNF VM(VNF)의 프로비저닝 및 수명 주기 관리를 담당합니다. JDM CLI 명령은 이러한 작업에 사용할 수 있습니다.
서브 라인 카드 개요
Junos Node Slicing에서 각 GNF는 일련의 라인 카드(FPC)로 구성됩니다. 기본적으로 각 GNF에는 전체 라인 카드(즉, 각 라인 카드의 전체 패킷 포워딩 엔진 세트)가 할당되기 때문에 GNF가 제공하는 가장 세밀한 수준은 라인 카드 수준입니다. SLC(Sub Line Card) 기능을 사용하면 단일 라인 카드의 패킷 포워딩 엔진 하위 집합을 서로 다른 GNF에 할당하여 파티셔닝을 더욱 세밀하게 정의할 수 있습니다.
라인 카드에 있는 패킷 전달 엔진의 이러한 사용자 정의 하위 집합을 서브 라인 카드(SLC)라고 합니다. 운영상 SLC는 독립적인 라인 카드와 같은 기능을 합니다.
라인 카드를 슬라이스할 때 해당 라인 카드의 모든 SLC는 다른 GNF에 할당되어야 합니다.
여러 라인 카드의 SLC를 동일한 GNF에 할당할 수 있습니다.
SLC 기능이 있는 Junos 노드 슬라이싱 설정에서 GNF는 전체 라인 카드 세트와 라인 카드 슬라이스(SLC) 세트로 구성될 수 있어 더 높은 수준의 유연성을 제공합니다.
라인 카드가 슬라이스되면 해당 라인 카드에서 단일 BLC(Base Line Card) 인스턴스와 여러 SLC 인스턴스(해당 라인 카드의 슬라이스 수만큼)의 두 가지 유형의 소프트웨어 인스턴스가 실행됩니다. 현재 SLC 기능은 2개의 SLC를 지원하는 MPC11E에서만 사용할 수 있습니다. BLC 인스턴스는 해당 라인 카드의 모든 SLC에 공통된 하드웨어를 관리하며, 각 SLC 인스턴스는 독점적으로 할당된 패킷 전달 엔진 세트를 관리합니다. BLC 인스턴스는 BSYS의 Junos 소프트웨어를 실행하고, 각 SLC 인스턴스는 관련 GNF의 Junos 소프트웨어를 실행합니다.
GNF에 할당된 SLC
SLC는 추상화된 패브릭 인터페이스 와 축소된 포워딩을 지원합니다( 추상화된 패브릭 인터페이스에 대한 패브릭 경로 최적화 참조). 명령을 사용하여 show interface af-interface-name 원격 FPC 슬라이스별 패킷 전달 엔진의 부하 분산 통계를 볼 수 있습니다. 자세한 내용은 인터페이스 표시(추상화된 패브릭) 를 참조하십시오.
SLC 기능은 MPC11E(모델 번호: MX2K-MPC11E)에서만 사용할 수 있습니다.
SLC를 위한 라인 카드 리소스
SLC 또는 라인 카드 슬라이스는 함께 작동해야 하는 (해당 라인 카드의) 패킷 전달 엔진 집합을 정의합니다. 라인 카드의 패킷 전달 엔진은 숫자 ID로 식별됩니다. 라인 카드에 패킷 전달 엔진이 'n'인 경우 개별 패킷 전달 엔진의 번호는 0에서 (n-1)까지입니다. 또한 라인 카드의 컨트롤 보드에 있는 CPU 코어와 DRAM도 분할되어 슬라이스에 할당되어야 합니다. SLC를 정의한다는 것은 해당 SLC 전용으로 다음과 같은 라인 카드 리소스를 정의해야 합니다.
-
패킷 전달 엔진 범위
-
라인 카드의 컨트롤 보드에 있는 CPU 코어 수
-
라인 카드의 컨트롤 보드에 있는 DRAM 크기(GB)
일정량의 DRAM은 해당 라인 카드의 BLC 인스턴스에 대해 자동으로 예약되고 나머지는 SLC 인스턴스에 사용할 수 있습니다.
모든 SLC는 사용자가 할당한 숫자 ID로 식별됩니다.
라인 카드가 슬라이스되면 해당 라인 카드의 모든 슬라이스에 대한 리소스 파티션을 완전히 정의해야 합니다.
SLC를 위한 MPC11E 라인 카드 리소스
MPC11E 라인 카드에는 다음이 있습니다.
-
8 패킷 포워딩 엔진
-
컨트롤 보드의 CPU 코어 8개
-
컨트롤 보드의 32GB DRAM
5GB의 DRAM은 BLC 사용을 위해 자동으로 예약되고, 1GB의 DRAM은 라인 카드 호스트에 할당되며, 나머지 26GB는 SLC 슬라이스에 사용할 수 있습니다.
MPC11E는 2개의 SLC를 지원할 수 있습니다.
표 2는 두 개의 SLC에 대해 MPC11E가 지원하는 두 가지 유형의 리소스 할당 프로필을 정의하며, 여기서는 SLC1 및 SLC2라고 합니다.
대칭 프로필에서 패킷 전달 엔진 및 기타 라인 카드 리소스는 슬라이스 간에 균등하게 분산됩니다. 비대칭 프로필에서는 표 2 에 표시된 지정된 라인 카드 리소스 조합만 지원됩니다.
패킷 포워딩 엔진 [0-7]이 두 SLC 간에 분할되는 방식에 따라 다음 SLC 프로필을 구성할 수 있습니다.
-
패킷 포워딩 엔진 한 SLC의 경우 0-3, 다른 SLC의 경우 4-7(대칭 프로필)
-
패킷 전달 엔진 한 SLC의 경우 0-1, 다른 SLC의 경우 2-7(비대칭 프로필)
-
패킷 포워딩 엔진 한 SLC의 경우 0-5, 다른 SLC의 경우 6-7(비대칭 프로파일)
비대칭 프로파일에서는 SLC에 9GB 또는 17GB의 DRAM을 할당할 수 있습니다. 모든 라인 카드 리소스를 완전히 할당해야 하고 SLC에 사용할 수 있는 총 DRAM이 26GB이므로 SLC에 9GB의 DRAM을 할당하려면 나머지 17GB를 다른 SLC에 할당해야 합니다.
| 대칭 프로파일 |
비대칭 프로파일 |
|||
|---|---|---|---|---|
| 리소스 종류 |
에스엘씨1 |
에스엘씨2 |
에스엘씨1 |
에스엘씨2 |
| 패킷 전달 엔진 |
4 |
4 |
2 |
6 |
| 드람 |
13 기가바이트 |
13 기가바이트 |
17GB/9GB |
9GB/17GB |
| CPU의 |
4 |
4 |
4 |
4 |
참조: 서브 라인 카드 구성 및 GNF에 할당 및 서브 라인 카드 관리.
멀티버전 소프트웨어 상호 운용성 개요
Junos OS 릴리스 17.4R1부터 Junos Node Slicing은 멀티버전 소프트웨어 호환성을 지원하여 BSYS가 BSYS의 소프트웨어 버전보다 높은 Junos OS 버전을 실행하는 게스트 네트워크 기능(GNF)과 상호 운용할 수 있도록 합니다. 이 기능은 GNF와 BSYS 간에 최대 두 가지 버전의 범위를 지원합니다. 즉, GNF 소프트웨어는 BSYS 소프트웨어보다 두 가지 버전이 높을 수 있습니다. BSYS와 GNF 모두 Junos OS 릴리스 17.4R1의 최소 버전 요구 사항을 충족해야 합니다.
다중 버전 지원의 제한 사항은 통합 ISSU 업그레이드 프로세스에도 적용됩니다.
JDM 소프트웨어 버전 관리에는 GNF 또는 BSYS 소프트웨어 버전과 관련하여 유사한 제한이 없지만 JDM 소프트웨어를 정기적으로 업데이트하는 것이 좋습니다. JDM 업그레이드는 실행 중인 GNF에 영향을 주지 않습니다.
Junos 노드 슬라이싱의 차세대 서비스
Junos Node Slicing은 MX 플랫폼에서 차세대 서비스를 실행할 수 있는 추가 처리 능력을 제공하는 보안 서비스 카드인 MX-SPC3 서비스 카드를 지원합니다. GNF에서 CLI request system enable unified-services 를 사용하여 게스트 네트워크 기능(GNF)에서 차세대 서비스를 활성화할 수 있습니다. MX-SPC3를 지원하기 위해서는 GNF에 라인 카드가 연결되어 있어야 합니다.
Junos Node Slicing 설정에서 MX-SPC3 및 MS-MPC를 모두 동일한 섀시에서 사용할 수 있지만 다른 GNF 라우팅 엔진에서 사용할 수 있습니다. GNF에서 차세대 서비스를 활성화한 경우, 를 사용하여 request system enable unified-servicesMX-SPC3가 온라인 상태가 됩니다. 차세대 서비스를 활성화하지 않은 경우 MS-MPC가 온라인 상태가 됩니다.
MX-SPC3 카드의 소프트웨어 설치 또는 업그레이드는 관련 GNF 라우팅 엔진을 설치하거나 업그레이드할 때 발생합니다.
MX-SPC3은 추상화된 패브릭 인터페이스를 지원하지 않습니다. 따라서 MX-SPC3 카드가 연결된 GNF에는 연결된 라인 카드도 있어야 합니다.
Junos Node Slicing과 논리적 시스템 비교
Junos Node Slicing은 Junos의 논리적 시스템 아래 계층입니다. 두 기술 모두 일부 중복되는 기능이 있지만 다른 측면에서는 다릅니다. Junos Node Slicing을 사용하면 전체 라인 카드와 그에 따른 물리적 인터페이스가 GNF에 할당되는 반면, 논리적 시스템에서는 물리적 인터페이스를 통해 정의된 여러 논리적 인터페이스가 모두 별도의 논리적 시스템에 할당될 수 있기 때문에 단일 물리적 인터페이스 자체를 여러 논리적 시스템에서 공유할 수 있습니다. 즉, 논리 시스템은 Junos 노드 슬라이싱보다 더 세분화된 공유를 허용합니다. 그러나 모든 논리 시스템은 단일 Junos 커널을 공유하므로 라우팅 엔진과 CPU, 메모리, 스토리지와 같은 라인 카드 물리적 리소스를 공유해야 하는 것 외에도 반드시 동일한 Junos 버전을 실행해야 합니다. Junos Node Slicing을 통해 각 GNF는 한 쌍의 라우팅 엔진과 해당 GNF 전용 라인 카드를 가지므로 GNF는 대부분의 물리적 리소스를 공유하지 않고 섀시와 스위치 패브릭만 공유합니다. GNF는 논리적 시스템과 달리 MX 독립형 라우터처럼 독립적으로 업그레이드하고 관리할 수 있습니다.
Junos Node Slicing은 GNF 자체에 여러 논리적 시스템이 있을 수 있기 때문에 논리적 시스템을 보완하고 강화하는 기술입니다. 물리적 격리, 보장된 리소스 및 완전한 관리 격리가 무엇보다 중요하다면 Junos 노드 슬라이싱이 더 적합할 것입니다. 그리고 논리적 인터페이스 수준까지 공유의 세밀한 부분이 가장 중요한 곳에서는 논리적 시스템이 더 잘 어울릴 것입니다.
Junos Node Slicing 라이선싱
Junos Node Slicing을 운영하려면 BSYS에 GNF 및 추상화된 패브릭 인터페이스를 설치하기 위한 라이선스가 필요합니다. BSYS에 설치된 라이센스 없이 GNF를 실행하면 다음과 같은 syslog 메시지와 사소한 경보가 발생합니다.
CHASSISD_LICENSE_EVENT: License Network-Slices: Failed to get valid license('216') 'gnf-creation'
Minor alarm set, 1 Guest network functions creation for JUNOS requires a license.
Junos Node Slicing 라이선스와 관련된 문의 사항이 있으면 주니퍼 네트웍스에 문의하십시오.