[ACSA 교육#40] 안전하게 유지 관리

네트워크 관리는 네트워크 관리자와 엔지니어 모두에게 필수적인 기술입니다.
이번 포스팅에서는 가장 중요한 네트워크 관리 기술을 이해하고 수행하기 위한 여러 기초 지식에 대해 알아볼 것입니다.

Out-of-Band 관리 포트 (OOBM)

ArubaOS-CX 스위치 제품군에는 스위치의 모니터링과 관리 목적으로만 사용되는 OOBM(Out-of-Band Management) 포트가 포함되어 있습니다. ArubaOS-CX의 운영체제 내부에 별도의 관리용 VRF가 있기 때문에 관리 평면(Management Plane)과 데이터 평면(Data Plane)이 완전히 격리됩니다. 데이터 트래픽은 이 포트를 보거나 사용할 수 없습니다. 이렇게 완전한 격리로 인해 관리 트래픽은 데이터 평면에서 대역폭을 사용하지 않습니다.

ArubaOS-CX 스위치의 OOBM 포트

이를 일반적으로 대역 외 관리 또는 OOBM이라고 합니다.

일반 이더넷 포트를 통해 스위치에 원격으로 연결하고 관리할 수도 있습니다. 이를 대역 내 관리(In-Band Management)라고 합니다. 이것은 편리해보이긴 하지만, 권장되는 방법은 아닙니다. 스위치 라우팅 또는 스위치의 프로토콜을 잘못 구성할 경우 관리를 위한 접근 권한을 잃을 수 있습니다.
또한 수동으로 보안 제어를 구성하지 않으면 해커가 스위치 구성에 접근하여 장치를 제어할 수 있는 보안적인 문제도 있습니다.

관리용 VRF

이미 예전 포스팅에서 VRF에 대해 알아본 바 있습니다. VRF는 별도의 라우팅 테이블을 사용하여 물리적 라우터 내부에 또 다른 가상 라우터를 생성합니다.
ArubaOS-CX 장치에는 데이터 평면을 위한 default VRF와 OOBM 트래픽 처리를 위한 관리 포트에 대한 별도의 mgmt VRF가 존재합니다.

ArubaOS-CX 관리 인터페이스는 기본적으로 활성화되어 있습니다. DHCP를 사용하여 IP주소를 수신하도록 구성됩니다. “show interface mgmt”라는 명령어를 통해 이 인터페이스의 상태를 확인할 수 있습니다.
필요하면 아래와 같이 관리 인터페이스에서 IP주소를 수동으로 구성할 수 있습니다.

Switch(config)# interface mgmt
Switch(config-if-mgmt)# ip static <IP주소/Mask>
Switch(config-if-mgmt)# default-gateway <기본 게이트웨이 주소>
Switch(config-if-mgmt)# nameserver <DNS서버 주소>
관리용 VRF에서 Ping과 Traceroute 명령어 사용하기

기본적으로 ArubaOS-CX 스위치의 Ping과 Traceroute 명령어는 default VRF에서 동작하게 되어 있습니다.
mgmt VRF에서 연결을 확인하고 싶을 때는, 다음 그림과 같이 mgmt VRF를 명시하여 ping과 traceroute 명령어를 사용해야만 합니다.

Switch# ping 192.168.1.20 vrf mgmt

ArubaOS-CX의 SSH

ArubaOS-CX 스위치의 CLI(Command Line Interface)에 접근하기 위해서는 SSH(Secure Shell) 프로토콜을 사용해야만 합니다. SSH는 스위치와 관리자의 PC 사이의 연결을 안전하게 제공합니다.
SSH는 기본적으로 default VRF에서 활성화되어 있고, mgmt VRF에는 비활성화되어 있습니다.
mgmt VRF에서 SSH를 사용하기 위해서는 아래와 같이 별도로 활성화해야 합니다.

Switch(config)# ssh server vrf mgmt

관리 인터페이스에서 SSH 상태를 확인하기 위해서는 “show ssh server vrf mgmt” 명령어를 사용하면 됩니다.

일반적으로, 관리 평면에서의 SSH가 활성화되면, 많은 관리자들은 데이터 평면에서의 SSH를 비활성화합니다.
아무리 SSH가 인증에 대한 자격증명을 요구하고 안전하다고 하지만, 데이터 평면에서 SSH를 비활성화하게 되면 엔드유저나 악의적인 사용자가 SSH 연결하는 것을 원천적으로 막을 수 있기 때문입니다.

ArubaOS-CX의 HTTPS

HTTPS는 SSH와 같이 스위치로의 안전한 GUI 접근을 제공합니다. HTTPS 역시 기본적으로 default VRF에서만 활성화되어 있습니다. 따라서 다음의 명령어를 사용하여 관리 평면에서의 HTTPS를 활성화합니다.

Switch(config)# https-server vrf mgmt

그리고 보안을 위해서 default VRF의 HTTPS를 비활성화 합니다.

Switch(config)# no https-server vrf default
Web 인터페이스

ArubaOS-CX 스위치는 장치 모니터링과 관리를 위해 GUI 웹 인터페이스가 내장되어 있습니다.
이 인터페이스를 사용하기 위해서는 웹 브라우저에서 스위치 IP주소를 입력하고 접속하면 됩니다.

https://switch-ip-address

좌측에는 4가지 세션으로 나눠진 메뉴가 있습니다.

  • Overview: 기본적인 프로토콜과 기능 정보를 보여줍니다. 여기에는 분석, 인터페이스, VLAN, LAG, 사용자, PoE, VSF 등의 정보가 포함됩니다.
  • System: 환경 정보, 로그, DNS 서버, SNMP 구성 및 구성 관리를 표시합니다.
  • Diagnostics: Ping이나 Traceroute와 같은 기능을 포함합니다.
  • Traffic: Spanning-Tree 관련된 정보를 포함하는 메뉴입니다.

HTTPS/GUI를 사용하는 최적의 방법은 mgmt VRF에서만 활성화하여 사용하는 것을 명심해야 합니다.

AAA (Authentication / Authorization / Accounting)

AAA는 3가지 개별 프로세스를 포함한 보안 개념입니다.

  • Authentication (인증): 접근 권한을 얻는 사람을 제어 – Who are you?
    시스템은 사용자가 default VRF에 대한 데이터 평면 연결 또는 mgmt VRF로 관리적 연결을 시도할 때 자격증명의 유효성을 검사합니다.
    자격증명은 사용자 이름과 암호, 디지털 인증서 또는 PSK(Pre-Shared Key, 사전 공유 키) 형식일 수 있습니다.
  • Authorization (인가): 인증 완료시 수행할 수 있는 작업을 제어 – What can you do?
    이 프로세스는 인증된 사용자에게 권한을 부여합니다.
    예를 들어, 네트워크에 연결하여 리소스를 사용할 수 있습니까? 스위치의 CLI 또는 GUI에 대한 읽기 전용 액세스 권한이 있습니까? 스위치 CLI에 대한 전체 읽기/쓰기 액세스 권한을 가질 수 있습니까? 등등 관리자의 승인 레벨에 따라 다르게 됩니다.
  • Accounting (계정관리): 이벤트 로그를 생성하여 수행한 작업을 추적 – What did you do?
    “홍길동은 오후 3시 30분에 판매 파일에 접근했고, 김철수는 오전 2시에 회계 파일을 삭제했으며, 이영수는 지난 목요일 12시 45분에 스위치의 CLI를 수정했습니다.” 와 같은 기록을 제공

AAA는 RADIUS(Remote Authentication Dial-In User Service)서버와 함께 사용되곤 합니다.

역할 기반 접근제어 – RBAC

관리자 권한은 스위치에 접근하고 구성할 수 있습니다. 또한, 모든 스위치의 프로세스에 대한 가시성을 갖게 됩니다.
이는 잘 훈련되고 믿을 수 있는 직원에게는 완벽할 수 있지만, 직원들의 전문성이나 업무 분장에 따라 제한되어야 할 수도 있습니다. 이러한 개념이 바로 역할 기반의 접근제어, RBAC(Role based Access Control)입니다.

ArubaOS-CX 스위치는 user-group을 정의하여 RBAC을 적용합니다. 허용 가능한 스위치 명령어를 개별로 지정하여 각 그룹별로 수동으로 구성합니다. ArubaOS-CX 스위치는 기본적으로 세 가지 user-group이 정의되어 있습니다.

  • Administrators
  • Auditors
  • Operators

위 세 가지 user-group은 별도로 지우거나 수정할 수 없습니다.

“show user-group” 명령어를 사용하여 이 정보를 확인할 수 있습니다.

RBAC 구성

새로운 user-group을 구성하는 방법은 아래와 같습니다.

Switch(config)# user-group <그룹명>

새롭게 만든 그룹에 사용자 계정을 매핑합니다.

Switch(config)# user <사용자명> group <그룹명> password plaintext <패스워드>

해당 그룹에 사용할 수 있는 명령어를 제한하고 싶을 때는 아래와 같이 규칙을 사용합니다.

Switch(config)# user-group monitoring
Switch(config-usr-grp-monitoring)# permit cli command "<명령어>"

그럼 “show version”과 “show interface 1/1/1” 명령어만 사용할 수 있는 “monitoring”이라는 그룹을 만들어보겠습니다.

[Example]
Switch(config)# user-group monitoring
Switch(config-usr-grp-monitoring)# 10 permit cli command "show version"
Switch(config-usr-grp-monitoring)# 20 permit cli command "show interface 1/1/1"

RADIUS 기반 매니지먼트 인증

인증을 위해서 일부 관리자들은 각 스위치별로 로컬 계정 정보를 설정합니다. 이러한 방식은 소규모 환경에서는 좋지만, 네트워크가 커지면 커질수록 관리자 입장에서 굉장한 부담으로 다가옵니다. 만약 100개의 네트워크 장치가 있다라고 하면, 100개의 계정을 생성하고 관리해야 하는 문제가 생깁니다.

그래서 많은 사람들은 RADIUS(Remote Authentication Dial-In User Service) 서버의 AAA 서비스를 통해 중앙 관리하는 방식을 많이 사용합니다. 수백 수천 개의 장치들은 RADIUS 프로토콜(UDP 포트 1812)을 사용하여 중앙 RADIUS 서버 내 위치한 자격증명 저장소에 접근합니다.

사용자 또는 관리자는 스위치에 접근 가능할 수 있는지 문의하고, 스위치는 이것을 다시 RADIUS 서버에 문의합니다.
“Alice라는 유저가 Secret123이라는 비밀번호로 왔는데, 접근 허용해도 될까요?” 라는 식으로 말이죠.
RADIUS 서버는 이러한 요청을 받게 되면, 자신의 데이터베이스를 통해 자격증명이 맞는지 확인하고 스위치에 ACCEPT(허용) 또는 REJECT(거절) 메시지를 보내게 됩니다.

또한, RADIUS 서버는 몇 가지 속성 값을 포함하여 메시지를 전달할 수도 있습니다. 이러한 속성 값은 연결 세션이 수행되는 방법을 수정할 수 있는 “메모”나 “참고사항”과 같습니다.
예를 들어, Alice라는 사용자가 스위치에 로그인을 위해 자격증명 정보를 RADIUS 서버로 보냈을 때, 서버는 이 자격증명 정보를 확인하고 ACCEPT 메시지를 보내게 됩니다. 메시지를 보내면서 ArubaOS-CX 스위치에 Alice라는 사용자를 “Administrator” user-group으로 포함하도록 속성 값을 추가하는 것이 가능합니다.

RADIUS 표준이 대중화되어 있는 이유 중 하나는 이 표준이 제조사별 특성(VSA, Vendor Specific Attribute)을 사용하여 장비 제조사와 공급업체에 의해 커스터마이징이 가능하도록 설계되었기 때문입니다.
Aruba는 사용성과 기능을 향상시키기 위해 Aruba 제품에 특화된 VSA를 만들었고, 기본적으로 AVP(Attribute Value Pair)라는 표준 속성을 사용합니다.
사용자 지정 VSA는 RADIUS 서버에 수동으로 추가해야 합니다. 하지만, Aruba ClearPass은 별도로 추가할 필요 없이 Aruba VSA가 내장되어 강력한 RADIUS 서버로 사용할 수 있습니다.

SNMP – Simple Network Managment Protocol

SNMP는 네트워크 장치간 매니지먼트 정보를 교환하기 위해 RFC 1157에서 정의한 Layer 7(Application Layer) 프로토콜입니다. 이 프로토콜은 제조사 관계 없이 네트워크 요소를 모니터링하거나 관리, 구성하기 위한 목적으로 주로 사용됩니다. SNMP 아키텍처는 아래 그림과 같습니다.

SNMP Manager는 주로 SNMP 에이전트와 통신하기 위해 별도로 구성된 서버입니다. GUI 인터페이스를 갖고 있는 경우가 많아 관리자는 하나의 인터페이스에서 많은 네트워크 장치의 값을 확인하고 변경할 수 있습니다. 이 Manager는 네트워크 장치의 값을 수집하고 변경하기 위해 몇 가지 메시지 종류를 사용합니다.

  • 에이전트 쿼리
  • 에이전트로부터 응답 값 가져오기
  • 에이전트의 특정 값 설정
  • 에이전트로부터 비동기 이벤트 확인

관리 장치는 라우터, 스위치, 방화벽, 무선 컨트롤러, 액세스 포인트 등 어떠한 네트워크 장치들을 칭하고 중앙에서 모니터링 및 관리, 구성하게 됩니다. 이러한 관리 장치는 내부적으로 두 가지 주요 SNMP 요소를 갖추고 있습니다.

  1. SNMP Agent는 장치의 구성 정보와 상태에 대해 정보를 수집하고 SNMP Manager와 통신합니다. MIB(Management Information Base)에 이러한 정보를 저장하고 검색합니다.
  2. MIB는 계층적 데이터베이스로 장치의 상태나 수치, 구성정보를 저장합니다. 이러한 정보는 SNMP Manager와 관리 장치간 통신을 통해 교환합니다.

일반적으로 SNMP Manager는 Agent와 통신을 위해 “Pull”이라는 메커니즘을 사용합니다. Manager가 관리 장치로부터 정보를 받길 원할 때 GET, GET NEXT, GET BULK 등 간단한 명령어를 사용하여 정보를 요청합니다. 또한 장치를 수정해야 할 때는 SET 이라는 명령어를 사용합니다. 이러한 통신에는 UDP 161을 사용합니다.

“pull” 메커니즘 예외의 경우는 관리 장치가 Manager의 polling 주기(period)를 기다릴 틈 없이 중요한 정보를 바로 보내야 할 때입니다. 예를 들면, CPU 사용량이 너무 높아서 위험한 경우가 한 예가 될 수 있습니다.
이런 경우에는, 관리 장치는 SNMP Trap을 사용하여 Manager에게 정보를 바로 “밀어 넣게” 됩니다. 여기서 SNMP Trap은 UDP 162를 사용합니다.

SNMP 버전

SNMP는 보안 수준에 따라 3 가지 버전을 갖고 있습니다.

  • SNMPv1 (Version 1): SNMP 프로토콜의 첫 번째 버전으로 Community 기반의 보안 메커니즘을 사용합니다. “Community 문자열(String)”은 간단한 사전 공유 패스코드와 같습니다. 만약 관리 장치가 public이라는 Community 문자열을 갖고 있다면, community string = public 을 사용하는 한 어떠한 SNMP Manager든 해당 장치의 Agent MIB를 접근할 수 있게 됩니다.
  • SNMPv2c (Version 2c): 이건 개정된 프로토콜로 SNMPv1에서 개선되었습니다. 프로토콜 패킷 타입, 전송 매핑, MIB 구조 요소 등에 대해 개선되었습니다. SNMPv1과 동일한 community 기반의 보안 메커니즘을 사용합니다.
  • SNMPv3 (Version 3): 메시지 무결성과 인증, 암호화 등을 포함한 더 높은 보안을 제공합니다.

ArubaOS-CX에서는 다음과 같이 간단하게 SNMPv2c를 구성할 수 있습니다.

Switch(config)# snmp-server community <community-string>
Switch(config)# snmp-server vrf <vrf-name>

※ 참고: 기본적으로 ArubaOS-CX 스위치에서는 SNMP 읽기 전용 community로 public이 설정되어 있습니다.  쓰기 전용 communtiy가 설정되어 있지 않으므로 액세스 할 수 없습니다.
ArubaOS-CX 스위치는 기본적으로 읽기 전용입니다.

Configuration 파일 관리

ArubaOS-CX 스위치는 configuration file을 저장하기 위해 RAM과 Flash 메모리를 사용합니다.
RAM과 Flash 메모리 특성을 이해해야 configuration 파일의 저장되는 형태를 알 수 있습니다.

  • RAM 메모리: 장치에서 현재 운영되고 있는 구성 정보(running-config)를 저장하기 위해 사용됩니다. RAM은 영구적인 저장소가 아니기 때문에 RAM에 저장된 내용은 장치가 재부팅되거나 전원이 나갔을 때 날아갈 수 있습니다. 만약 running-config를 수정하고 스위치를 재부팅한다면, 변경 사항은 날아가게 됩니다.
    running-config를 확인하기 위해서는 “show running-config”라는 명령어를 통해 확인 가능합니다.
  • Flash 메모리: 구성 접오를 영구적으로 저장하기 위해 사용됩니다. Flah 메모리에 저장된 내용은 전원이 꺼지거나 재부팅 되더라도 그대로 남아 있게 됩니다. “show startup-config” 명령어를 통해 저장된 내용을 확인할 수 있습니다.

물론 언제든지, running-config에 반영한 변경사항을 copy 명령어를 사용하여 startup-config 파일에 복사할 수 있습니다. 운영 중인 장치의 구성 정보를 영구적으로 저장하기 위해서는 “copy running-config startup-config”라는 명령어를 사용하면 됩니다.

※ 참고: “write memory” 라는 명령어도 사용할 수 있습니다. 똑같은 작업을 수행합니다.

또한, “copy startup-config running-config”라는 명령어를 사용하여 startup-config에 있는 구성 정보를 복원할 수 있습니다.

가장 좋은 방법은, 운영 중인 running-config와 startup-config를 내보내기 해서 외부의 파일 서버에 저장하는 것입니다. 이러한 백업은 치명적인 장애가 발생했을 때 복구에 큰 도움을 줄 수 있습니다. 외부로 내보내기 위해서는 아래와 같이 명령어를 입력하면 됩니다.

Switch# copy {startup-config | running-config} {tftp:// | sftp://USER@}{IP | HOST}[:PORT][;blocksize=VAL]/FILE

명령어가 복잡하기 때문에 10.253.1.21이라는 TFTP 서버로 running-config를 복사하는 예제를 한 번 살펴보겠습니다.

Switch# copy running-config tftp://10.253.1.21/switch_config.cfg

또한, ArubaOS-CX 스위치는 USB 장치에 파일을 복사할 수도 있습니다. 스위치에 USB 메모리를 직접 연결하여 아래 명령어를 통해 구성 정보를 USB 메모리에 저장 가능합니다.

Switch# copy {running-config | startup-config} usb:/file

Checkpoint

앞서 copy 명령어를 사용하여 configuration file을 저장하고, 관리자의 실수나 전원이 나갔을 때 구성 정보를 바로 복구할 수 있다는 것을 알아봤습니다. 하지만, 이러한 백업 파일은 네트워크 프로세스 상태의 어떤 데이터도 포함하지 않습니다. 따라서 진정한 복구를 위해서는 새로운 접근 방식이 필요합니다.

Checkpoint는 운영 중인 스위치의 스냅샷을 의미합니다. 이 스냅샷을 생성할 때 동작 중인 구성 정보(running-config)와 관련 메타데이터까지 포함됩니다. 따라서, 관리자는 이전 상태로 되돌리는 등 언제든지 필요할 때 백업된 스위치 구성 정보를 적용하기 위해 checkpoint를 사용할 수 있습니다. Checkpoint는 동일한 모델의 다른 스위치에도 적용할 수 있는 아주 유연한 구조를 갖고 있습니다.

Checkpoint는 두 가지 방식을 갖고 있습니다.

  • 시스템이 생성: 구성(config)을 변경하고 5분 동안 어떠한 작업이 없는 경우 자동으로 생성합니다. 기본적으로 매 5분(300초)마다 checkpoint가 생성됩니다.
    • Checkpoint는 CP<YYYYMMDDHHMSS>의 포맷으로 생성됩니다.
  • 사용자가 생성: 관리자가 직접 수동으로 생성합니다.

Checkpoint를 생성하기 위해서는 copy라는 명령어를 사용합니다.

Switch# copy {running-config | startup-config} checkpoint <checkpoint-name>

checkpoint 리스트를 확인하기 위해서는 아래와 같이 show 명령어를 사용합니다.

Switch# show checkpoint list all

특정 checkpoint로 스위치를 되돌리기 위해서는 다음과 같이 명령어를 사용합니다.

Switch# copy checkpoint <checkpoint-name> {running-config | startup-config}

※ 참고: 외부 서버로 checkpoint를 내보낼 수 있습니다.

이 외에도 rollback이라는 명령어를 통해서 running-config를 checkpoint에 저장된 구성정보를 복원할 수 있습니다.

Switch# checkpoint rollback <checkpoint-name>

※참고: rollback 명령어는 copy checkpoint running-config 명령어와 동일한 기능을 수행합니다.

Checkpoint Auto Mode

간혹 스위치 구성을 적용한 후에 스위치에 접근할 수 없도록 잠기는 현상(lock out)이 발생하는 경우가 생깁니다. 이럴 때는 콘솔 포트를 사용하여 직접 로컬로 연결하여 문제가 되는 구성(config)을 지우는 것 밖에 방법이 없습니다.

하지만, checkpoint auto mode를 사용하면 이 부분을 좀 더 편리하게 해결할 수 있습니다.
이 솔루션은 타이머가 포함됩니다. 시스템이 현재 상태에 대한 checkpoint를 생성하고 나면, 관리자는 원하는 구성을 변경하고 시스템에 적용합니다. 적용 후 접속 하는데 문제가 없다면 관리자는 해당 구성 변경에 대해서 confirm을 합니다. 만약 관리자가 지정한 타이머 시간 내에 confirm을 하지 않는다면, 스위치는 자동으로 스냅샷 찍은 checkpoint 시점으로 원복합니다.

아래와 같은 명령어를 통해 auto mode를 사용합니다.

Switch# checkpoint auto <minutes>
Switch# checkpoint auto confirm

실제 사용 예시는 아래와 같습니다.

Switch# checkpoint auto 20
Auto checkpoint mode expires in 20 minute(s)
Switch# 
WARNING  Please "checkpoint auto confirm" within 2 minutes
Switch# checkpoint auto confirm 
checkpoint AUTO20170801011154 created

만약 config상에 문제가 생겨 접속이 안 되어서 지정 시간 내 confirm을 하지 않으면 자동으로 원복됩니다.

Switch# checkpoint auto 20
Auto checkpoint mode expires in 20 minute(s)
Switch# 
WARNING  Please "checkpoint auto confirm" within 2 minutes
WARNING: Restoring configuration. Do NOT add any new configuration.
Restoration successful

운영 체제 이미지 관리

ArubaOS-CX 스위치는 소프트웨어 이미지 파일을 저장하기 위해 두 개의 Flash 메모리 모듈 또는 파티션을 갖고 있습니다. AOS-CX는 주(Primary) 이미지와 보조(Secondary) 이미지로 이 모듈들을 참조합니다.

두 개의 Flash 메모리 위치를 갖고 있는 것은 스위치를 보다 쉽게 관리할 수 있고, 펌웨어 업그레이드를 계획하는데 도움이 됩니다. 예를 들어, 현재 사용하지 않는 Flash 메모리 공간에 새로운 펌웨어 이미지를 다운로드한 다음 유지 관리 동안 스위치에서 새로운 펌웨어 이미지를 사용하여 부팅하도록 설정할 수 있습니다.

“show image”라는 명령어를 사용하여 현재 Primary와 Secondary 이미지의 소프트웨어 정보를 확인할 수 있습니다.

Switch# show image
-----------------------------------------------------------------------
ArubaOS-CX Primary Image
-----------------------------------------------------------------------
Version : GL.10.04.0003
Size    : 415MB
Date    : 2019-10-31 12:33:52 PDT
SHA-256 : 794336ee0b1f941aac421bec5333f16b4ebbcd1f4035a388d3b79aa
-----------------------------------------------------------------------
ArubaOS-CX Secondary Image
<<<<<<Omitted output>>>>>>

Default Image : Primary
-----------------------------------------------------------------------
Management Module 1/1 (Active)
-----------------------------------------------------------------------
Active Image       : primary
Service OS Version : GL.01.05.0002
BIOS Version       : GL-01-0013
운영체제 이미지 관리 액세스

관리자는 CLI 또는 GUI를 사용하여 스위치를 업데이트 할 수 있습니다.

CLI에서는 copy 명령어를 사용합니다.

Switch# copy {tftp://|sftp://USER@}{IP|HOST}[:PORT][;blocksize=VAL]/FILE {primary | secondary}

GL.10.04.0003.swi라는 이미지 파일을 10.253.1.21의 IP주소를 갖고 있는 TFTP 서버를 통해서 복사할 경우의 예시를 살펴볼까요?

Switch# copy tftp://10.253.1.23/GL.10.04.0003.swi primary

사용자 이름 admin이라는 계정으로 Secure FTP를 사용하는 방법은 다음과 같습니다.

Switch# copy sftp://admin@10.253.1.21/GL.10.04.0003.swi primary

GUI를 사용한다면 훨씬 간단합니다. HTTPS를 통해 GUI 페이지에 접속한 후에 System → Firmware Update 메뉴로 들어갑니다. 그리고 내 PC에 다운 받은 이미지 파일 찾아서 Flash 파티션을 선택하고 업로드 하면 됩니다.

비밀번호 복구 프로세스 (Password Recovery)

만약에 스위치에 로그인하기 위한 자격증명(계정 및 비밀번호)을 잊어 먹었거나 로그인을 계속 실패할 경우에는 다음과 같이 비밀번호 복구 프로세스를 진행해야 합니다.

1. 콘솔 포트를 통해 스위치에 접속합니다.
2. 스위치의 전원을 껐다 켭니다.
3. 시스템 화면이 뜨면, 0번 메뉴인 Service OS console 옵션을 선택합니다.

Boot Profiles:

0. Service OS Console
1. Primary Software Image [FL.10.04.0003]
2. Secondary Software Image [FL.10.04.0003]

Select profile(primary): 0

4. 사용자 admin, 패스워드는 입력하지 않고 로그인합니다.
5. 로그인 후에 password라는 명령어를 통해 admin 계정에 대해 새로운 패스워드를 설정합니다.

ServiceOS login: admin
SVOS> password
Enter password: ********
Confirm password: ********

6. boot 명령어를 입력합니다.
7. 5번 항목에서 설정한 비밀번호와 함께 admin 계정으로 로그인합니다.

공장 초기화 (Factory Default)

erase all zeroize“라는 명령어를 사용하면 스위치를 공장 초기화 상태로 되돌립니다. 공장 초기화 상태가 진행되기 전에 관련된 프롬프트 내용이 나올 것입니다. 일단 진행이 완료되면, 스위치는 공장 초기화 상태의 구성(config)를 갖고 primary 이미지로 재부팅 됩니다.

Switch(config)# erase all zeroize
This will securely erase all customer data and reset the switch to factory defaults. This will initiate a reboot and render the switch unavailable until the zeroization is complete.
This should take several minutes to one hour to complete. Continue (y/n)? y
The system is going down for zeroization.

“erase-startup” 명령어는 startup checkpoint를 지웁니다. zeroize 명령어는 모든 checkpoint를 지우는 것으로 차이가 있습니다.


이렇게 ArubaOS-CX 스위치를 유지 관리하는 방법들을 알아보았습니다.
네트워크를 구축하고 구성하는 방법도 중요하지만, 구성된 환경을 잘 유지 관리하는 것이 더 중요합니다.

현재의 환경을 안전하게 유지될 수 있도록 모니터링하고 관리하기 위해서 필요한 명령어들을 잘 살펴보면서 안전한 네트워크 환경을 운영하시길 바랍니다.

이렇게 40회에 걸친 ACSA 교육을 마칩니다.
실제 ACSA 교육에 포함된 내용 중에 일부는 생략하기도 하고 일부는 다른 포스팅을 통해 전달하기도 할 것이기 때문에 Aruba에서 제공하는 강의 자료나 공식 교재를 함께 보시는 것을 권장합니다.