섀시 클러스터 설명 및 구축 시나리오
섀시 클러스터의 다양한 구축
방화벽 배포는 액티브/패시브 또는 액티브/액티브일 수 있습니다.
액티브/패시브 섀시 클러스터 모드는 섀시 클러스터 방화벽 구축의 가장 일반적인 유형이며 클러스터의 두 방화벽 멤버로 구성됩니다. One은 라우팅, 방화벽, 네트워크 주소 변환(NAT), VPN(가상 사설망) 및 보안 서비스를 적극적으로 제공하며 섀시 클러스터의 제어를 유지합니다. 다른 방화벽은 활성 방화벽이 비활성화될 경우 클러스터 장애 조치 기능에 대한 상태를 수동적으로 유지합니다.
SRX 시리즈 디바이스는 가능하면 섀시 클러스터 멤버 모두에서 트래픽을 유지하려는 환경을 위해 액티브/액티브 섀시 클러스터 모드를 지원합니다. SRX 시리즈 디바이스 액티브/액티브 구축에서는 데이터 플레인만 액티브/액티브 모드에 있는 반면, 컨트롤 플레인은 실제로 액티브/패시브 모드에 있습니다. 이를 통해 하나의 컨트롤 플레인이 두 섀시 멤버를 단일 논리적 디바이스로 제어할 수 있으며, 컨트롤 플레인에 장애가 발생할 경우 컨트롤 플레인이 다른 유닛으로 장애 조치될 수 있습니다. 이는 데이터 플레인이 컨트롤 플레인과 독립적으로 장애 조치될 수 있음을 의미하기도 합니다. 또한 활성/활성 모드에서는 수신 인터페이스가 하나의 클러스터 멤버에 있고 송신 인터페이스가 다른 클러스터 멤버에 있을 수 있습니다. 이 경우 데이터 트래픽은 데이터 패브릭을 통과하여 다른 클러스터 멤버로 이동하고 송신 인터페이스를 나가야 합니다. 이를 Z 모드라고 합니다. 또한 액티브/액티브 모드를 사용하면 라우터가 페일오버 시 클러스터 간에 공유되지 않고 단일 섀시에만 존재하는 개별 클러스터 멤버에 로컬 인터페이스를 가질 수 있습니다. 이러한 인터페이스는 필요한 경우 트래픽을 다른 클러스터 멤버로 장애 조치하는 동적 라우팅 프로토콜과 함께 사용되는 경우가 많습니다. 그림 1 은 클러스터에 있는 두 개의 SRX5800 디바이스를 보여줍니다.
SRX5800 장치
SRX 클러스터를 효과적으로 관리하려면 네트워크 관리 애플리케이션이 다음을 수행해야 합니다.
기본 및 보조 노드 식별 및 모니터링
이중화 그룹 및 인터페이스 모니터링
컨트롤 및 데이터 플레인 모니터링
전환 및 장애 모니터링
그림 2 는 대역 외 관리 및 운영을 위한 SRX 시리즈 하이엔드 디바이스 구성을 보여줍니다.
그림 3 은 대역 외 관리 및 운영을 위한 SRX 시리즈 브랜치 디바이스 구성을 보여줍니다.
기본 및 보조 노드 연결
다음은 관리 시스템에서 클러스터에 연결하는 데 가장 적합한 구성입니다. 이 구성을 사용하면 관리 시스템이 기본 노드와 보조 노드 모두에 연결할 수 있습니다.
user@host# show groups
node0 {
system {
host-name SRX3400-1;
backup-router 172.19.100.1 destination 10.0.0.0/8;
services {
outbound-ssh {
client nm-10.200.0.1 {
device-id A9A2F7;
secret "$9$T3Ct0BIEylIRs24JDjO1IRrevWLx-VeKoJUDkqtu0BhS"; ## SECRET-DATA
services netconf;
10.200.0.1 port 7804;
}
}
}
syslog {
file messages {
any notice;
structured-data;
}
}
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 172.19.100.164/24;
}
}
}
}
}
node1 {
system {
host-name SRX3400-2;
backup-router 172.19.100.1 destination 10.0.0.0/8;
services {
outbound-ssh {
client nm-10.200.0.1 {
device-id F007CC;
secret "$9$kPFn9ApOIEAtvWXxdVfTQzCt0BIESrIR-VsYoa9At0Rh"; ## SECRET-DATA
services netconf;
10.200.0.1 port 7804;
}
}
}
}
}
# The following syslog configuration is not applicable for Branch SRX Series Services Gateways:
syslog {
file default-log-messages {
any notice;
structured-data;
}
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 172.19.100.165/24;
}
}
}
}
user@host# show apply-groups
apply-groups "${node}";
{primary:node0} [edit]
user@host# show interfaces
interfaces {
fxp0 {
unit 0 {
family inet {
filter {
input protect;
}
address 172.19.100.166/24 {
master-only;
}
}
}
}
}
{primary:node0}[edit]
user@host# show snmp
location "Systest lab";
contact "Lab Admin";
view all {
oid .1 include;
}
community srxread {
view all;
}
community srxwrite {
authorization read-write;
}
trap-options {
source-address 172.19.100.166;
}
trap-group test {
targets {
10.200.0.1;
}
}
v3 {
vacm {
security-to-group {
security-model usm {
security-name test123 {
group test1;
}
security-name juniper {
group test1;
}
}
}
access {
group test1 {
default-context-prefix {
security-model any {
security-level authentication {
read-view all;
}
}
}
context-prefix MGMT_10 {
security-model any {
security-level authentication {
read-view all;
}
}
}
}
}
}
target-address petserver {
address 116.197.178.20;
tag-list router1;
routing-instance MGMT_10;
target-parameters test;
}
target-parameters test {
parameters {
message-processing-model v3;
security-model usm;
security-level authentication;
security-name juniper;
}
notify-filter filter1;
}
notify server {
type trap;
tag router1;
}
notify-filter filter1 {
oid .1 include;
}
}
{primary:node0}[edit]
user@host# show routing-options
static {
route 10.200.0.1/32 next-hop 172.19.100.1;
}
primary:node0}[edit]
root@SRX3400-1# show firewall
term permit-ssh {
from {
source-address {
10.200.0.0/24;
}
protocol tcp;
destination-port [ ssh telnet ];
}
then accept;
}
term permit-udp {
from {
source-address {
207.17.137.28/32;
}
protocol udp;
}
then accept;
}
term permit-icmp {
from {
protocol icmp;
icmp-type [ echo-reply echo-request ];
}
then accept;
}
term permit-ntp {
from {
source-address {
149.20.68.16/32;
}
protocol udp;
port ntp;
}
then accept;
}
term permit-ospf {
from {
protocol ospf;
}
then accept;
}
term permit-snmp {
from {
source-address {
10.200.0.0/24;
}
protocol udp;
port [ snmp snmptrap ];
}
then accept;
}
term deny-and-count {
from {
source-address {
0.0.0.0/0;
}
}
then {
count denied;
reject tcp-reset;
}
}
}
구성 설명
fxp0 인터페이스(새로운 유형의 인터페이스)를 통해 SRX 시리즈 섀시 클러스터에 연결하는 가장 좋은 방법은 그룹을 사용하여 기본 및 보조 노드의 관리 포트 모두에 IP 주소를 할당하는 것입니다.
클러스터 전체에서 기본 전용 IP 주소를 사용합니다. 이렇게 하면 단일 IP 주소를 쿼리할 수 있으며 해당 IP 주소는 항상 중복 그룹 0의 기본 주소입니다. 기본 전용 IPv4 주소를 사용하지 않는 경우 각 노드 IP 주소를 추가하고 모니터링해야 합니다. 보조 노드 모니터링은 이 항목에 설명된 대로 제한됩니다.
참고:특히 SNMP를 사용하는 동안 관리를 위해 기본 전용 IPv4 주소를 사용하는 것이 좋습니다. 이렇게 하면 장애 조치(failover) 후에도 장치에 연결할 수 있습니다.
앞서 표시된 fxp0 인터페이스 구성에서는 섀시 클러스터에 있는 보조 노드의 fxp0 인터페이스에 있는 관리 IPv4 주소에 연결할 수 없습니다. 보조 노드 라우팅 서브시스템이 실행되고 있지 않습니다. fxp0 인터페이스는 관리 IPv4 주소와 동일한 서브넷에 있는 호스트에서 연결할 수 있습니다. 호스트가 관리 IPv4 주소와 다른 서브넷에 있는 경우 통신이 실패합니다. 이는 예상된 동작이며 설계된 대로 작동합니다. 보조 클러스터 멤버의 라우팅 엔진은 페일오버까지 작동하지 않습니다. 라우팅 프로토콜 프로세스는 기본 노드가 활성 상태일 때 보조 노드에서 작동하지 않습니다. 관리 액세스가 필요한
backup-router경우 구성 문을 사용할 수 있습니다.backup-router문을 사용하면 관리 목적으로 외부 서브넷에서 보조 노드에 액세스할 수 있습니다. 시스템 제한으로 인해 에 지정된backup-router대상 주소를 '0.0.0.0/0' 또는 '::/0'으로 구성하지 마십시오. 마스크는 0이 아닌 값이어야 합니다. 관리 IP 주소 범위가 연속되지 않은 경우 여러 대상을 포함할 수 있습니다. 이 예에서 백업 라우터 172.19.100.1은 fxp0 인터페이스를 통해 연결할 수 있으며 대상 네트워크 관리 시스템 IPv4 주소는 10.200.0.1입니다. 네트워크 관리 주소는 백업 라우터를 통해 연결할 수 있습니다. 백업 라우터가 네트워크 관리 시스템에 연결되려면 백업 라우터 구성에 대상 서브넷을 포함시킵니다.아웃바운드 SSH 주소를 사용하여 SSH 프로토콜, NETCONF XML 관리 프로토콜 또는 Junos OS XML 관리 프로토콜을 사용하여 관리 시스템에 연결하는 것이 좋습니다. 이렇게 하면 전환 후에도 장치가 자동으로 다시 연결됩니다.
각 노드에 대해 동일한 SNMP 엔진 ID를 사용하는 것이 좋습니다. 이는 SNMPv3가 프로토콜 데이터 유닛(PDU)의 인증을 위해 SNMP 엔진 ID 값을 사용하기 때문이며, SNMP 엔진 ID 값이 각 노드마다 다르면 라우팅 엔진 전환 후 SNMPv3가 실패할 수 있습니다.
샘플 구성에 표시된 대로 SNMP 커뮤니티, 트랩 그룹 등과 같은 다른 SNMP 구성을 노드 간에 공통으로 유지합니다.
참고:SNMP 트랩은 기본 노드에서만 전송됩니다. 여기에는 보조 노드에서 감지된 이벤트 및 실패가 포함됩니다. 보조 노드는 SNMP 트랩 또는 경고를 전송하지 않습니다. 구성 가능한 옵션을
client-only사용하여 SNMP 액세스를 필요한 클라이언트로만 제한합니다. 암호화 및 인증에 SNMPv3를 사용합니다.로그 메시지는 노드별로 다르므로 Syslog 메시지는 두 노드에서 별도로 전송해야 합니다.
관리 스테이션이 관리 IP 주소와 다른 서브넷에 있는 경우 백업 라우터 구성에서 동일한 서브넷을 지정하고 필요한 경우 계층 수준 아래에
[edit routing-options]정적 경로를 추가합니다. 이전 샘플 구성에서 네트워크 관리 주소 10.200.0.1은 백업 라우터를 통해 연결할 수 있습니다. 따라서 정적 경로가 구성됩니다.방화벽 필터를 사용하여 디바이스에 대한 액세스를 제한할 수 있습니다. 이전 샘플 컨피그레이션은 SSH, SNMP 및 Telnet이 10.0.0.0/8 네트워크로 제한됨을 보여줍니다. 이 구성은 UDP, ICMP, OSPF 및 NTP 트래픽을 허용하고 다른 트래픽은 거부합니다. 이 필터는 fxp0 인터페이스에 적용됩니다.
보안 영역을 사용하여 트래픽을 제한할 수도 있습니다. 자세한 내용은 Junos OS 보안 구성 가이드를 참조하십시오.
SRX 시리즈 브랜치 디바이스를 위한 추가 구성
SRX100, SRX210 및 SRX240 디바이스의 공장 기본 구성은 레이어 2 이더넷 스위칭을 자동으로 활성화합니다. 레이어 2 이더넷 스위칭은 섀시 클러스터 모드에서 지원되지 않기 때문에 이러한 디바이스의 경우 공장 기본 구성을 사용하는 경우 섀시 클러스터링을 활성화하기 전에 이더넷 스위칭 구성을 삭제해야 합니다.
전용 fxp0 관리 인터페이스가 없습니다. fxp0 인터페이스는 내장 인터페이스에서 용도가 변경되었습니다. 예를 들어, SRX100 디바이스에서 fe-0/0/06 인터페이스는 관리 인터페이스로 용도가 변경되고 자동으로 fxp0으로 이름이 변경됩니다. 관리 인터페이스에 대한 자세한 내용은 Junos OS 보안 구성 가이드를 참조하십시오.
Syslog는 주의해서 사용해야 합니다. 클러스터가 불안정해질 수 있습니다. 데이터 플레인 로깅은 SRX 시리즈 브랜치 디바이스의 syslog를 통해 전송해서는 안 됩니다.
섀시 클러스터 관리
중복 이더넷 인터페이스를 통한 섀시 클러스터 관리—SRX 시리즈 섀시 클러스터는 중복 이더넷(RETH) 인터페이스를 사용하여 관리할 수 있습니다. 중복 그룹 및 reth 인터페이스의 구성은 active/active 모드 및 active/passive 모드와 같은 구축에 따라 다릅니다. 구성에 대한 자세한 내용은 Junos OS 보안 구성 가이드를 참조하십시오. reth 인터페이스가 구성되고 관리 스테이션에서 연결할 수 있게 되면 reth 인터페이스를 통해 보조 노드에 액세스할 수 있습니다.
reth 인터페이스가 중복 그룹 1+에 속하는 경우 관리 스테이션에 대한 TCP 연결이 새 기본으로 원활하게 전환됩니다. 그러나 중복 그룹 0 페일오버가 발생하고 라우팅 엔진이 새 노드로 전환하면 몇 초 동안 모든 세션에 대한 연결이 끊어집니다.
전송 인터페이스를 통한 클러스터 관리 - 클러스터된 디바이스는 전송 인터페이스를 사용하여 관리할 수 있습니다. 전송 인터페이스는 보조 노드에 도달하는 데 직접 사용할 수 없습니다.
대역 내 관리 및 운영을 위한 장치 구성
SRX 시리즈 서비스 게이트웨이용 Junos OS에서 사용할 수 있는 섀시 클러스터 기능은 Junos OS 기반 디바이스에서 발견되는 중복 기능을 기반으로 모델링됩니다. 별도의 컨트롤 플레인과 데이터 플레인으로 설계된 Junos OS 기반 디바이스는 두 플레인 모두에서 중복성을 제공합니다. Junos OS의 컨트롤 플레인은 라우팅 엔진에 의해 관리되며, 라우팅 엔진은 다른 기능과 별도로 모든 라우팅 및 포워딩 계산을 수행합니다. 컨트롤 플레인이 통합되면 포워딩 엔트리가 시스템의 모든 패킷 포워딩 엔진으로 푸시됩니다. 그런 다음 패킷 전달 엔진은 경로 기반 조회를 수행하여 라우팅 엔진의 개입 없이 각 패킷에 대한 적절한 대상을 결정합니다.
SRX 시리즈 서비스 게이트웨이에서 섀시 클러스터를 활성화하면 그림 4와 같이 동일한 모델 디바이스를 사용하여 컨트롤 플레인 이중화를 제공합니다.
두 개의 라우팅 엔진이 있는 디바이스와 마찬가지로 SRX 시리즈 클러스터의 컨트롤 플레인은 액티브/패시브 모드에서 작동하며 주어진 시간에 하나의 노드만 컨트롤 플레인을 능동적으로 관리합니다. 이 때문에 포워딩 플레인은 항상 컨트롤 플레인으로 전송되는 모든 트래픽(호스트 인바운드 트래픽이라고도 함)을 클러스터의 기본 노드로 보냅니다. 이 트래픽에는 다음이 포함되지만 이에 국한되지는 않습니다.
BGP, OSPF, IS-IS, RIP 및 PIM 트래픽과 같은 라우팅 프로세스에 대한 트래픽
IKE(Internet Key Exchange) 협상 메시지
SSH, Telnet, SNMP 및 NETCONF와 같은 관리 프로세스로 전달되는 트래픽
모니터링 프로토콜(예: BFD 또는 RPM)
이 동작은 호스트 인바운드 트래픽에만 적용됩니다. 통과 트래픽(즉, 클러스터에서 전달되었지만 클러스터의 인터페이스로 전달되지 않는 트래픽)은 클러스터의 구성에 따라 두 노드 중 하나에서 처리할 수 있습니다.
포워딩 플레인은 항상 호스트 인바운드 트래픽을 기본 노드로 전달하기 때문에 fxp0 인터페이스는 컨트롤 플레인의 상태에 관계없이 각 노드에 독립적인 연결을 제공합니다. fxp0 인터페이스로 전송된 트래픽은 포워딩 플레인에 의해 처리되지 않지만 Junos OS 커널로 전송되므로 보조 노드에서도 노드의 컨트롤 플레인에 연결할 수 있는 방법을 제공합니다.
이 주제에서는 fxp0 인터페이스를 사용할 필요 없이 기본 노드를 통해 섀시 클러스터를 관리하는 방법, 즉 대역 내 관리를 설명합니다. 이는 SRX 시리즈 브랜치 디바이스에 특히 필요한데, 이러한 디바이스의 일반적인 구축은 원격 브랜치 오피스를 모니터링하는 데 사용할 수 있는 관리 네트워크가 없기 때문입니다.
Junos OS 릴리스 10.1 R2 이전에는 SRX 시리즈 브랜치 섀시 클러스터를 관리하려면 클러스터의 두 멤버 모두의 컨트롤 플레인에 연결해야 했기 때문에 각 노드의 fxp0 인터페이스에 액세스해야 했습니다. Junos OS 릴리스 10.1 R2 이상에서 SRX 시리즈 브랜치 디바이스는 reth 인터페이스 또는 레이어 3 인터페이스를 사용하여 원격으로 관리할 수 있습니다.
기본 노드를 통한 SRX 시리즈 브랜치 섀시 클러스터 관리
클러스터의 기본 노드에 액세스하는 것은 노드의 인터페이스(fxp0 인터페이스 제외)에 대한 연결을 설정하는 것만큼 쉽습니다. 레이어 3 및 reth 인터페이스는 항상 노드에 관계없이 트래픽을 기본 노드로 보냅니다. 두 배포 시나리오는 모두 공통적이며 그림 5 와 그림 6에 나와 있습니다.
두 경우 모두 로컬 주소에 대한 연결을 설정하면 기본 노드에 연결됩니다. 정확히 말하면 중복 그룹 0의 기본 노드에 연결되어 있습니다. 예를 들어, 중복 그룹 1의 멤버인 reth 인터페이스가 다른 노드에서 활성 상태인 경우에도 기본 노드에 연결할 수 있습니다(백업 노드에 물리적으로 상주하더라도 레이어 3 인터페이스에도 동일하게 적용됨). SSH, Telnet, SNMP 또는 NETCONF XML 관리 프로토콜을 사용하여 SRX 섀시 클러스터를 모니터링할 수 있습니다.
그림 5 는 RETH 인터페이스를 통해 관리되는 SRX 시리즈 브랜치 디바이스의 예를 보여줍니다. 이 모델은 Junos OS 릴리스 10.4 이상을 사용하는 SRX 시리즈 하이엔드 디바이스에도 사용할 수 있습니다.
그림 6 은 레이어 3 인터페이스를 사용한 대역 내 관리를 위한 물리적 연결을 보여줍니다.
페일오버가 있는 경우 대역 내 연결만 reth 또는 레이어 3 인터페이스를 통해 새 기본 노드에 도달할 수 있어야 관리 스테이션과 클러스터 간의 연결을 유지할 수 있습니다.
표 1 에는 서로 다른 인터페이스를 사용할 때의 장점과 단점이 나와 있습니다.
fxp0 인터페이스 |
Reth 및 전송 인터페이스 |
|---|---|
기본 전용 IP 주소와 함께 fxp0 인터페이스를 사용하면 시스템 내의 모든 라우팅 인스턴스 및 가상 라우터에 액세스할 수 있습니다. fxp0 인터페이스는 inet.0 라우팅 테이블의 일부만 될 수 있습니다. inet.0 라우팅 테이블은 기본 라우팅 인스턴스의 일부이므로 모든 라우팅 인스턴스 및 가상 라우터의 데이터에 액세스하는 데 사용할 수 있습니다. |
전송 또는 reth 인터페이스는 자신이 속한 라우팅 인스턴스 또는 가상 라우터의 데이터에만 액세스할 수 있습니다. 기본 라우팅 인스턴스에 속해 있으면 모든 라우팅 인스턴스에 액세스할 수 있습니다. |
기본 전용 IP 주소가 있는 fxp0 인터페이스는 페일오버 후에도 디바이스 관리에 사용할 수 있으며, 이 기능을 사용하는 것이 좋습니다. |
전송 인터페이스는 reth 그룹의 일부가 아닌 한 페일오버 후(또는 인터페이스를 호스팅하는 디바이스가 작동 중단되거나 비활성화된 경우) 연결이 끊어집니다. |
fxp0 인터페이스를 통한 관리에는 노드당 하나씩 두 개의 IP 주소가 필요합니다. 이는 또한 fxp0 인터페이스를 사용하여 클러스터 노드에 연결하려면 스위치가 있어야 함을 의미합니다. |
reth 인터페이스에는 두 개의 IP 주소가 필요하지 않으며 SRX 시리즈 섀시 클러스터에 연결하는 데 스위치가 필요하지 않습니다. 관리에 사용되는 경우 각 노드의 전송 인터페이스에는 각 인터페이스에 대해 두 개의 명시적 IP 주소가 필요합니다. 그러나 이것은 전송 인터페이스이므로 IP 주소는 관리와 별도로 트래픽에도 사용됩니다. |
비이더넷 링크(ADSL, T1\E1)가 있는 SRX 시리즈 브랜치 디바이스 클러스터는 fxp0 인터페이스를 사용하여 관리할 수 없습니다. |
비이더넷 링크가 있는 SRX 시리즈 브랜치 디바이스는 reth 또는 전송 인터페이스를 사용하여 관리할 수 있습니다. |
섀시 클러스터 디바이스와 통신
관리 스테이션은 다음 방법을 사용하여 SRX 시리즈 섀시 클러스터에 연결할 수 있습니다. 이는 모든 Junos OS 디바이스에서 동일하며 SRX 시리즈 섀시 클러스터로 제한되지 않습니다. SRX 시리즈 섀시 클러스터에서 다음 프로토콜 중 하나에 대해 기본 전용 IP 주소를 사용하는 것이 좋습니다. Reth 인터페이스 IP 주소는 다음 인터페이스 중 하나를 사용하여 클러스터에 연결하는 데 사용할 수 있습니다.
메서드 |
설명 |
|---|---|
CLI 액세스를 위한 SSH 또는 Telnet |
이는 단일 클러스터의 수동 구성 및 모니터링에만 권장됩니다. |
Junos OS XML 관리 프로토콜 |
Telnet, SSH 및 SSL을 통해 실행할 수 있는 XML 기반 인터페이스이며 NETCONF XML 관리 프로토콜의 선구자입니다. CLI를 사용하여 입력할 수 있는 모든 구성 및 운영 명령에 대해 Junos OS XML API에 대한 액세스를 제공합니다. 운영 정보에 액세스하는 데 이 방법을 사용하는 것이 좋습니다. NETCONF XML 관리 프로토콜 세션을 통해서도 실행할 수 있습니다. |
NETCONF XML 관리 프로토콜 |
이는 구성을 위해 IETF에서 정의한 표준 XML 인터페이스입니다. 이를 사용하여 디바이스를 구성하는 것이 좋습니다. 이 세션은 Junos OS XML 관리 프로토콜 RPC(Remote Procedure Call)를 실행하는 데에도 사용할 수 있습니다. |
Snmp |
SRX 시리즈 섀시 클러스터의 관점에서 SNMP 시스템은 클러스터 내의 두 노드를 단일 시스템으로 간주합니다. 기본 라우팅 엔진에서 실행되는 SNMP 프로세스는 하나뿐입니다. 초기화 시 프로토콜 기본은 라우팅 엔진 기본 구성을 기반으로 활성화해야 하는 SNMP 프로세스(snmpd)를 나타냅니다. 패시브 라우팅 엔진에는 실행 중인 snmpd가 없습니다. 따라서 기본 노드만 SNMP 쿼리에 응답하고 언제든지 트랩을 보냅니다. 보조 노드는 직접 쿼리할 수 있지만 MIB 지원이 제한되어 있으며 자세한 내용은 섀시 인벤토리 및 인터페이스 검색에 나와 있습니다. 보조 노드는 SNMP 트랩을 전송하지 않습니다. 보조 노드에 대한 SNMP 요청은 보조 노드의 fxp0 인터페이스 IP 주소 또는 reth 인터페이스 IP 주소를 사용하여 전송할 수 있습니다. |
Syslog |
표준 시스템 로그 메시지를 외부 syslog 서버로 보낼 수 있습니다. 기본 노드와 보조 노드 모두 syslog 메시지를 보낼 수 있습니다. syslog 메시지를 별도로 전송하도록 기본 노드와 보조 노드를 모두 구성하는 것이 좋습니다. |
보안 로그 메시지(SPU) |
애플리케이션 추적 도구인 AppTrack은 네트워크의 대역폭 사용량을 분석하기 위한 통계를 제공합니다. 사용하도록 설정하면 AppTrack이 지정된 영역의 애플리케이션 흐름에 대한 바이트, 패킷 및 기간 통계를 수집합니다. 기본적으로 각 세션이 닫히면 AppTrack은 바이트 및 패킷 수와 세션 기간을 제공하는 메시지를 생성하고 메시지를 호스트 디바이스로 보냅니다. AppTrack 메시지는 세션 로그 메시지와 유사하며 syslog 또는 구조화된 syslog 형식을 사용합니다. 메시지에는 세션에 대한 응용 프로그램 필드도 포함됩니다. AppTrack이 사용자 지정 정의 애플리케이션을 식별하고 적절한 이름을 반환하는 경우 사용자 지정 애플리케이션 이름이 로그 메시지에 포함됩니다. 이를 위해서는 응용 프로그램 ID를 구성해야 합니다. 애플리케이션 식별 및 추적 구성 및 사용에 대한 자세한 내용은 Junos OS 보안 구성 가이드를 참조하십시오. |
J-웹 |
모든 Junos OS 디바이스는 구성 및 관리를 위한 그래픽 사용자 인터페이스를 제공합니다. 이 인터페이스는 개별 장치를 관리하는 데 사용할 수 있습니다. |