라우팅 엔진 이중화 구성
아래의 단계와 예에 따라 라우팅 엔진 이중화를 구성하십시오.
다음 섹션의 작업을 완료하려면 re0 및 re1 구성 그룹을 정의해야 합니다. 구성 그룹에 대한 자세한 내용은 Junos OS CLI 사용자 가이드를 참조하십시오.
기본 라우팅 엔진 기본 역할 수정
두 개의 라우팅 엔진을 가진 라우터의 경우, 어떤 라우팅 엔진이 기본이고 어떤 것이 백업인지 구성할 수 있습니다. 기본적으로 슬롯 0의 라우팅 엔진는 기본(re0)이고 슬롯 1의 은 백업(re1)입니다.
두 개의 라우팅 엔진이 있는 시스템에서는 두 라우팅 엔진을 동시에 기본으로 구성할 수 없습니다. 이 구성으로 인해 커밋 검사에 실패합니다.
기본 구성을 수정하려면 계층 수준에서 문을 [edit chassis redundancy]
포함합니다routing-engine
.
[edit chassis redundancy] routing-engine slot-number (master | backup | disabled);
slot-number 0 또는 1일 수 있습니다. 기본 라우팅 엔진으로 구성하려면 master 옵션을 지정합니다. 백업으로 구성하려면 백업 옵션을 지정합니다. 라우팅 엔진 을(를) 비활성화하려면 비활성화 된 옵션을 지정하십시오.
기본 라우팅 엔진과 백업 라우팅 엔진 간에 전환하려면 라우팅 엔진 기본 역할 수동 스위칭을 참조하십시오.
백업 라우팅 엔진으로의 자동 페일오버 구성
다음 섹션에서는 기본 라우팅 엔진에서 특정 장애가 발생할 때 백업 라우팅 엔진으로 자동 페일오버를 구성하는 방법에 대해 설명합니다.
- 패킷 포워딩 중단 없이
- 기본 라우팅 엔진에서 하드 디스크 오류 감지 시
- VM과 RE 간의 깨진 LCMD 연결이 감지된 경우
- 기본 라우팅 엔진에서 Keepalive 신호 손실 감지 시
- 기본 라우팅 엔진에서 em0 인터페이스 실패 감지 시
- 소프트웨어 프로세스가 실패하는 경우
패킷 포워딩 중단 없이
두 개의 라우팅 엔진을 갖춘 라우터의 경우 GRES(Graceful 라우팅 엔진 Switchover)를 구성할 수 있습니다. Graceful Switchover가 구성되면 소켓 재연결이 패킷 전달 중단 없이 원활하게 이루어집니다. Graceful 라우팅 엔진 스위치오버를 구성하는 방법에 대한 자세한 정보는 Configuring Graceful 라우팅 엔진 Switchover를 참조하십시오.
기본 라우팅 엔진에서 하드 디스크 오류 감지 시
백업 라우팅 엔진을 구성한 후 기본 라우팅 엔진에서 하드 디스크 오류를 감지하면 자동으로 기본 역할을 수행하도록 지시할 수 있습니다. 이 기능을 사용하려면 계층 수준에서 문을 [edit chassis redundancy failover]
포함합니다on-disk-failure
.
[edit chassis redundancy failover] on-disk-failure;
on-disk-failure
계층 수준의 명령문 [edit chassis redundancy]
은 Junos Evolved를 실행하는 PTX 플랫폼에서 지원되지 않습니다. 이러한 플랫폼은 기본적으로 디스크 장애가 감지되면 전환됩니다.
VM과 RE 간의 깨진 LCMD 연결이 감지된 경우
VM과 RE 간의 LCMD 연결이 끊어질 때 자동 RE 전환이 발생하도록 다음 구성을 설정합니다. 이 기능을 사용하려면 계층 수준에서 문을 [edit chassis redundancy failover]
포함합니다on-loss-of-vm-host-connection
.
[edit chassis redundancy failover] on-loss-of-vm-host-connection;
LCMD 프로세스가 기본에서 충돌하는 경우 백업 RE LCMD 연결이 안정적이면 시스템이 1분 후에 전환됩니다. 백업 RE LCMD 연결이 불안정하거나 현재 기본이 방금 기본 역할을 얻은 경우 시스템이 전환되지 않습니다. 기본이 막 기본 역할을 얻은 경우 전환은 4분 후에만 발생합니다.
기본 라우팅 엔진에서 Keepalive 신호 손실 감지 시
백업 라우팅 엔진을 구성한 후, 기본 라우팅 엔진에서 keepalive 신호 손실이 감지되면 자동으로 기본 역할을 수행하도록 지시할 수 있습니다.
Keepalive 손실 신호 수신 시 페일오버를 활성화하려면 계층 수준에서 문을 [edit chassis redundancy failover]
포함합니다on-loss-of-keepalives
.
[edit chassis redundancy failover] on-loss-of-keepalives;
on-loss-of-keepalives
계층의 [edit chassis redundancy]
문은 Junos Evolved를 실행하는 PTX 플랫폼에서 지원되지 않습니다. 이러한 플랫폼은 keepalive 메시지가 탐지되지 않을 때 기본적으로 전환으로 설정됩니다.
그레이스풀 라우팅 엔진 스위치오버가 구성되지 않은 경우 기본적으로 300초(5분) 후에 페일오버가 발생합니다. 더 짧거나 긴 시간 간격을 구성할 수 있습니다.
기본 라우팅 엔진이 수동으로 재부팅되거나 중단되면 keepalive 시간 주기가 360초로 재설정됩니다.
Keepalive 기간을 변경하려면 계층 수준에서 문을 [edit chassis redundancy]
포함합니다keepalive-time
.
[edit chassis redundancy] keepalive-time seconds;
keepalive-time의 범위는 2초에서 10,000초입니다.
다음 예는 기본 라우팅 엔진에서 keepalive 신호 손실을 감지하도록 백업 라우팅 엔진을 구성하는 경우의 이벤트 시퀀스를 설명합니다.
-
25초의 keepalive-time 을 수동으로 구성합니다.
-
기본 라우팅 엔진에 대한 패킷 포워딩 엔진 연결이 손실되고 keepalive 타이머가 만료되면 패킷 전달이 중단됩니다.
-
25초 동안 keepalive 손실이 발생하면 메시지가 기록되고 백업 라우팅 엔진이 기본 역할을 수행하려고 시도합니다. 백업 라우팅 엔진이 활성화되면 알람이 생성되고 디스플레이가 라우팅 엔진의 현재 상태로 업데이트됩니다.
-
백업 라우팅 엔진이 기본 역할을 맡은 후에는 계속해서 기본 역할을 수행합니다.
그레이스풀 라우팅 엔진 스위치오버가 구성되면 keepalive 신호가 자동으로 활성화되고 페일오버 시간이 2초(M20 라우터의 경우 4초)로 설정됩니다. keepalive 시간을 수동으로 재설정할 수 없습니다.
기본 라우팅 엔진을 중단하거나 재부팅하면 Junos OS는 keepalive 시간을 360초로 재설정하고 백업 라우팅 엔진은 360초의 keepalive 시간이 만료될 때까지 기본 역할을 맡지 않습니다.
이전의 기본 라우팅 엔진은 백업 라우팅 엔진으로의 페일오버 후 다시 서비스를 시작하면 백업 라우팅 엔진이 됩니다. 이전 기본 라우팅 엔진으로 기본 상태를 복원하려면 운영 모드 명령을 사용할 request chassis routing-engine master switch 수 있습니다.
라우팅 엔진 중 하나가 없으면 중복 구성 방식에 관계없이 나머지 라우팅 엔진이 자동으로 기본 엔진이 됩니다.
기본 라우팅 엔진에서 em0 인터페이스 실패 감지 시
백업 라우팅 엔진을 구성한 후, 기본 라우팅 엔진에서 em0 인터페이스가 실패하면 자동으로 기본 역할을 수행하도록 지시합니다. 이 기능을 사용하려면 계층 수준에서 문을 [edit chassis redundancy failover]
포함합니다on-re-to-fpc-stale
.
[edit chassis redundancy failover] on-re-to-fpc-stale;
소프트웨어 프로세스가 실패하는 경우
소프트웨어 프로세스가 실패할 경우 백업 라우팅 엔진으로 자동 전환을 구성하려면 계층 수준에서 문을 [edit system processes process-name]
포함합니다failover other-routing-engine
.
[edit system processes process-name] failover other-routing-engine;
process-name 는 유효한 프로세스 이름 중 하나입니다. 이 문이 프로세스에 대해 구성되고 해당 프로세스가 30초 이내에 4번 실패하면 라우터는 다른 라우팅 엔진에서 재부팅됩니다. 계층 수준에서 사용할 수 있는 [edit system processes]
또 다른 문은 failover alternate-media입니다. 대체 미디어 옵션에 대한 자세한 내용은 라우팅 디바이스용 Junos OS 관리 라이브러리를 참조하십시오.
라우팅 엔진 기본 역할 수동 스위칭
라우팅 엔진 주요 역할을 수동으로 전환하려면 다음 명령 중 하나를 사용합니다.
-
백업 라우팅 엔진에서 명령을 실행하여
request chassis routing-engine master acquire
백업 라우팅 엔진이 기본 역할을 수행하도록 요청합니다. -
기본 라우팅 엔진에서 명령을 사용하여
request chassis routing-engine master release
백업 라우팅 엔진이 기본 역할을 수행하도록 요청합니다. -
라우팅 엔진 중 하나에서 명령을 실행하여 기본 역할을 전환합니다
request chassis routing-engine master switch
.
라우팅 엔진 이중화 상태 확인
/var/log/mastership의 중복 로깅을 위해 별도의 로그 파일이 제공됩니다. 로그를 보려면 명령을 사용합니다file show /var/log/mastership
. 표 1에는 기본 역할 로그 이벤트 코드 및 설명이 나열되어 있습니다.
이벤트 코드 |
묘사 |
---|---|
E_NULL = 0 |
이벤트가 null 이벤트입니다. |
E_CFG_M |
라우팅 엔진은 기본으로 구성됩니다. |
E_CFG_B |
라우팅 엔진은 백업으로 구성됩니다. |
E_CFG_D |
라우팅 엔진이 비활성화된 것으로 구성됩니다. |
E_MAXTRY |
기본 역할을 획득하거나 해제하려는 최대 시도 횟수를 초과했습니다. |
E_REQ_C |
클레임 기본 역할 요청이 전송되었습니다. |
E_ACK_C |
클레임 기본 역할 승인을 받았습니다. |
E_NAK_C |
클레임 기본 역할 요청이 승인되지 않았습니다. |
E_REQ_Y |
기본 역할에 대한 확인이 요청됩니다. |
E_ACK_Y |
기본 역할이 인정됩니다. |
E_NAK_Y |
기본 역할은 인정되지 않습니다. |
E_REQ_G |
릴리스 기본 역할 요청이 라우팅 엔진에 의해 전송되었습니다. |
E_ACK_G |
라우팅 엔진이 기본 역할의 릴리스를 인정했습니다. |
E_CMD_A |
request chassis routing-engine master acquire 명령이 백업 라우팅 엔진에서 실행되었습니다. |
E_CMD_F |
백업 라우팅 엔진에서 명령 request chassis routing-engine master acquire force 가 실행되었습니다. |
E_CMD_R |
request chassis routing-engine master release 명령이 기본 라우팅 엔진에서 발행되었습니다. |
E_CMD_S |
request chassis routing-engine master switch 명령이 라우팅 엔진에서 실행되었습니다. |
E_NO_ORE |
다른 라우팅 엔진은 감지되지 않습니다. |
E_TMOUT |
요청 시간이 초과되었습니다. |
E_NO_IPC |
라우팅 엔진 연결이 끊어졌습니다. |
E_ORE_M |
기타 라우팅 엔진 상태가 기본으로 변경되었습니다. |
E_ORE_B |
기타 라우팅 엔진 상태가 백업으로 변경되었습니다. |
E_ORE_D |
기타 라우팅 엔진 상태가 비활성화로 변경되었습니다. |
전체 CPU 및 메모리 사용량 확인
목적
라우터에서 실행 중이고 제어 터미널이 있는 소프트웨어 프로세스에 대한 완전한 시스템 프로세스 정보를 표시할 수 있습니다. 이 명령은 UNIX top 명령과 동일합니다. 그러나 UNIX top 명령은 메모리 값이 지속적으로 변경되는 실시간 메모리 사용량을 표시하는 반면, show system processes extensive 명령은 지정된 순간의 메모리 사용량에 대한 스냅샷을 제공합니다.
행동
전체 CPU 및 메모리 사용량을 확인하려면 다음 Junos OS 명령줄 인터페이스(CLI) 명령을 입력합니다.
user@host> show system processes extensive
샘플 출력
user@R1> show system processes extensive
last pid: 5251; load averages: 0.00, 0.00, 0.00 up 4+20:22:16 10:44:41 58 processes: 1 running, 57 sleeping Mem: 57M Active, 54M Inact, 17M Wired, 184K Cache, 35M Buf, 118M Free Swap: 512M Total, 512M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 4480 root 2 0 3728K 1908K select 231:17 2.34% 2.34% chassisd 4500 root 2 0 1896K 952K select 0:36 0.00% 0.00% fud 4505 root 2 0 1380K 736K select 0:35 0.00% 0.00% irsd 4481 root 2 0 1864K 872K select 0:32 0.00% 0.00% alarmd 4488 root 2 0 8464K 4600K kqread 0:28 0.00% 0.00% rpd 4501 root 2 -15 1560K 968K select 0:21 0.00% 0.00% ppmd 4510 root 2 0 1372K 812K select 0:13 0.00% 0.00% bfdd 5 root 18 0 0K 0K syncer 0:09 0.00% 0.00% syncer 4485 root 2 0 3056K 1776K select 0:07 0.00% 0.00% snmpd 4499 root 2 0 3688K 1676K select 0:05 0.00% 0.00% kmd 4486 root 2 0 3760K 1748K select 0:05 0.00% 0.00% mib2d 4493 root 2 0 1872K 928K select 0:03 0.00% 0.00% pfed 4507 root 2 0 1984K 1052K select 0:02 0.00% 0.00% fsad 4518 root 2 0 3780K 2400K select 0:02 0.00% 0.00% dcd 8 root -18 0 0K 0K psleep 0:02 0.00% 0.00% vmuncachedaemo 4 root -18 0 0K 0K psleep 0:02 0.00% 0.00% bufdaemon 4690 root 2 0 0K 0K peer_s 0:01 0.00% 0.00% peer proxy 4504 root 2 0 1836K 968K select 0:01 0.00% 0.00% dfwd 4477 root 2 0 992K 320K select 0:01 0.00% 0.00% watchdog 4354 root 2 0 1116K 604K select 0:01 0.00% 0.00% syslogd 4492 root 10 0 1004K 400K nanslp 0:01 0.00% 0.00% tnp.sntpd 4446 root 10 0 1108K 616K nanslp 0:01 0.00% 0.00% cron 4484 root 2 0 15716K 7468K select 0:01 0.00% 0.00% mgd 4494 root 2 15 2936K 2036K select 0:01 0.00% 0.00% sampled 5245 remote 2 0 8340K 3472K select 0:01 0.00% 0.00% cli 2 root -18 0 0K 0K psleep 0:00 0.00% 0.00% pagedaemon 4512 root 2 0 2840K 1400K select 0:00 0.00% 0.00% l2tpd 1 root 10 0 852K 580K wait 0:00 0.00% 0.00% init 5244 root 2 0 1376K 784K select 0:00 0.00% 0.00% telnetd 4509 root 10 0 1060K 528K nanslp 0:00 0.00% 0.00% eccd 4508 root 2 0 2264K 1108K select 0:00 0.00% 0.00% spd 2339 root 10 0 514M 17260K mfsidl 0:00 0.00% 0.00% newfs 4497 root 2 0 2432K 1152K select 0:00 0.00% 0.00% cosd 4490 root 2 -15 2356K 1020K select 0:00 0.00% 0.00% apsd 4496 root 2 0 2428K 1108K select 0:00 0.00% 0.00% rmopd 4491 root 2 0 2436K 1104K select 0:00 0.00% 0.00% vrrpd 4487 root 2 0 15756K 7648K sbwait 0:00 0.00% 0.00% mgd 5246 root 2 0 15776K 8336K select 0:00 0.00% 0.00% mgd 0 root -18 0 0K 0K sched 0:00 0.00% 0.00% swapper 5251 root 30 0 21732K 840K RUN 0:00 0.00% 0.00% top 4511 root 2 0 1964K 908K select 0:00 0.00% 0.00% pgmd 4502 root 2 0 1960K 956K select 0:00 0.00% 0.00% lmpd 4495 root 2 0 1884K 876K select 0:00 0.00% 0.00% ilmid 4482 root 2 0 1772K 776K select 0:00 0.00% 0.00% craftd 4503 root 10 0 1040K 492K nanslp 0:00 0.00% 0.00% smartd 6 root 28 0 0K 0K sleep 0:00 0.00% 0.00% netdaemon 4498 root 2 0 1736K 932K select 0:00 0.00% 0.00% nasd 4506 root 2 0 1348K 672K select 0:00 0.00% 0.00% rtspd 4489 root 2 0 1160K 668K select 0:00 0.00% 0.00% inetd 4478 root 2 0 1108K 608K select 0:00 0.00% 0.00% tnetd 4483 root 2 0 1296K 540K select 0:00 0.00% 0.00% ntpd 4514 root 3 0 1080K 540K ttyin 0:00 0.00% 0.00% getty 4331 root 2 0 416K 232K select 0:00 0.00% 0.00% pccardd 7 root 2 0 0K 0K pfeacc 0:00 0.00% 0.00% if_pfe_listen 11 root 2 0 0K 0K picacc 0:00 0.00% 0.00% if_pic_listen 3 root 18 0 0K 0K psleep 0:00 0.00% 0.00% vmdaemon 9 root 2 0 0K 0K scs_ho 0:00 0.00% 0.00% scs_housekeepi 10 root 2 0 0K 0K cb-pol 0:00 0.00% 0.00% cb_poll
의미
샘플 출력은 라우팅 엔진 및 소프트웨어 프로세스에서 사용하는 가상 메모리의 양을 보여줍니다. 예를 들어, 실제 메모리의 118MB는 사용 가능하고 스왑 파일의 512MB는 사용 가능하며, 이는 라우터의 메모리가 부족하지 않음을 나타냅니다. processes 필드는 58개 프로세스 중 대부분이 휴면 상태이고 1개는 실행 중 상태임을 보여줍니다. 실행 중인 프로세스 또는 명령이 최상위 명령입니다.
명령 열에는 현재 실행 중인 프로세스가 나열됩니다. 예를 들어, 섀시 프로세스(chassisd)의 프로세스 식별자(PID)는 4480이고 현재 우선 순위(PRI)는 2입니다. 낮은 우선 순위 번호는 더 높은 우선 순위를 나타냅니다.
프로세스는 활동 수준에 따라 나열되며 가장 활동적인 프로세스가 출력의 맨 위에 있습니다. 예를 들어 섀시(섀시) 프로세스는 2.34%로 가장 많은 양의 CPU 리소스를 사용하고 있습니다.
메모리 필드(Mem)는 라우팅 엔진에서 관리하고 프로세스에서 사용하는 가상 메모리를 보여줍니다. 메모리 필드의 값은 KB 및 MB 단위이며 다음과 같이 분류됩니다.
-
활성 - 프로그램에서 할당되고 실제로 사용 중인 메모리입니다.
-
Inact - 할당되었지만 최근에 사용되지 않은 메모리 또는 프로그램에 의해 해제된 메모리입니다. 비활성 메모리는 여전히 하나 이상의 프로세스의 주소 공간에 매핑되므로 해당 프로세스의 상주 집합 크기에 포함됩니다.
-
유선—스왑할 수 없는 메모리로, 일반적으로 라우팅 엔진 메모리 구조 또는 프로세스에 의해 물리적으로 잠긴 메모리에 사용됩니다.
-
캐시 - 프로그램과 연결되지 않고 재사용하기 전에 스왑할 필요가 없는 메모리입니다.
-
buf - 디스크에서 최근에 호출된 데이터를 보관하는 데 사용되는 메모리 버퍼의 크기입니다.
-
사용 가능 - 프로그램과 연결되지 않은 메모리입니다. 프로세스에서 해제된 메모리는 프로세스에서 메모리를 해제하는 데 사용하는 방법에 따라 비활성, 캐시 또는 사용 가능이 될 수 있습니다.
시스템이 메모리 부족 상태일 때 페이지 아웃 프로세스는 사용 가능한 페이지, 캐시, 비활성 페이지 및 필요한 경우 활성 페이지의 메모리를 재사용합니다.
스왑 필드에는 사용 가능한 총 스왑 공간과 사용되지 않은 공간이 표시됩니다. 예제에서 출력은 512MB의 총 스왑 공간과 512MB의 여유 스왑 공간을 보여줍니다.
마지막으로 각 프로세스의 메모리 사용량이 나열됩니다. SIZE 필드는 가상 주소 공간의 크기를 나타내고, RES 필드는 RSS 또는 Resident Set Size라고도 하는 실제 메모리에서 프로그램의 양을 나타냅니다. 샘플 출력에서 섀시(섀시) 프로세스에는 3728KB의 가상 주소 공간과 1908KB의 실제 메모리가 있습니다.
초기 라우팅 엔진 구성 예
구성 그룹을 사용하여 각 라우팅 엔진에 올바른 IP 주소가 사용되도록 하고 두 라우팅 엔진에 대해 단일 구성 파일을 유지할 수 있습니다.
다음 예는 별도의 IP 주소를 사용하여 구성 그룹 re0 및 re1 을 정의합니다. 이러한 잘 알려진 구성 그룹 이름은 적절한 라우팅 엔진에서만 적용됩니다.
groups { re0 { system { host-name my-re0; } interfaces { fxp0 { description "10/100 Management interface"; unit 0 { family inet { address 10.255.2.40/24; } } } } } re1 { system { host-name my-re1; } interfaces { fxp0 { description "10/100 Management interface"; unit 0 { family inet { address 10.255.2.41/24; } } } } } }
두 라우팅 엔진의 관리 이더넷 인터페이스(이 예에서는 fxp0 )에 추가 IP 주소를 할당할 수 있습니다. 할당된 주소는 master-only 키워드를 사용하며 두 라우팅 엔진 모두에서 동일하므로 기본 라우팅 엔진의 IP 주소에 언제든지 액세스할 수 있습니다. 주소는 기본 라우팅 엔진의 관리 이더넷 인터페이스에서만 활성화됩니다. 라우팅 엔진 전환 중 주소는 새로운 기본 라우팅 엔진으로 이동합니다.
예를 들어, re0에서 구성은 다음과 같습니다.
[edit groups re0 interfaces fxp0] unit 0 { family inet { address 10.17.40.131/25 { master-only; } address 10.17.40.132/25; } }
re1에서 구성은 다음과 같습니다.
[edit groups re1 interfaces fxp0] unit 0 { family inet { address 10.17.40.131/25 { master-only; } address 10.17.40.133/25; } }
듀얼 라우팅 엔진의 초기 구성에 대한 자세한 내용은 Junos OS 소프트웨어 설치 및 업그레이드 가이드를 참조하십시오. 두 라우팅 엔진에서 master-only 키워드를 사용하여 관리 이더넷 인터페이스에 추가 IP 주소를 할당하는 방법에 대한 자세한 내용은 Junos OS CLI 사용자 가이드를 참조하십시오.
참조
한 라우팅 엔진에서 다른 로 구성 파일 복사
콘솔 포트 또는 관리 이더넷 포트 중 하나를 사용하여 두 라우팅 엔진 간의 연결을 설정할 수 있습니다. 그런 다음 FTP를 복사하거나 사용하여 기본에서 백업으로 구성을 전송하고 파일을 로드하여 일반적인 방법으로 커밋할 수 있습니다.
관리 이더넷 포트를 사용하여 다른 라우팅 엔진에 연결하려면 다음 명령을 실행합니다.
user@host> request routing-engine login (other-routing-engine | re0 | re1)
TX Matrix 라우터에서 관리 이더넷 포트를 사용하여 다른 라우팅 엔진에 연결하려면 다음 명령을 실행합니다.
user@host> request routing-engine login (backup | lcc number | master | other-routing-engine | re0 | re1)
명령에 대한 request routing-engine login
자세한 내용은 CLI 익스플로러를 참조하십시오.
한 라우팅 엔진에서 다른 로 구성 파일을 복사하려면 명령을 실행합니다.file copy
user@host> file copy source destination
이 경우, 은(는) source 구성 파일의 이름입니다. 이러한 파일은 /config 디렉터리에 저장됩니다. 활성 구성은 /config/juniper.conf이며 이전 구성은 /config/juniper.conf {1...9}에 있습니다. 은 destination (는) 다른 라우팅 엔진의 파일입니다.
다음 예는 라우팅 엔진 0에서 라우팅 엔진 1로 구성 파일을 복사합니다.
user@host> file copy /config/juniper.conf re1:/var/tmp/copied-juniper.conf
다음 예는 TX Matrix 라우터의 라우팅 엔진 0에서 라우팅 엔진 1로 구성 파일을 복사합니다.
user@host> file copy /config/juniper.conf scc-re1:/var/tmp/copied-juniper.conf
구성 파일을 로드하려면 계층 수준에서 명령을 [edit]
입력합니다load replace
.
user@host> load replace /var/tmp/copied-juniper.conf
라우팅 엔진 0의 관리 이더넷 인터페이스 구성에 지정된 모든 IP 주소를 라우팅 엔진 1에 적합한 주소로 변경해야 합니다.
참조
다른 라우팅 엔진에서 소프트웨어 패키지 로드하기
기존 request system software add package-name
명령을 사용하여 다른 라우팅 엔진에서 로컬 라우팅 엔진으로 패키지를 로드할 수 있습니다.
user@host> request system software add re(0|1):/filename
URL의 re 부분에 다른 라우팅 엔진의 번호를 지정합니다. filename URL 부분에서 패키지의 경로를 지정합니다. 패키지는 일반적으로 /var/sw/pkg 디렉토리에 있습니다.