[개념] Junos 기본 개념 (2)

 

1. 소프트웨어 아키텍처

 Junos OS는 네트워크 운영 체제(Network Operating System, NOS)로 알려져 있지만, 사실상 다른 운영 체제 위에서 실행되는 애플리케이션처럼 작동한다. 예를 들어, Putty가 Microsoft Windows 위에서 실행되는 방식과 비슷하다고 할 수 있다. 그러나 Junos는 Windows에서 실행되지 않는다.

 

  Juniper가 Junos를 설계할 때는 안정적이고 보안성이 뛰어나며, 운영 체제 자체가 과도한 시스템 자원을 요구하지 않는 운영 체제가 필요했다. 그래서 Juniper는 FreeBSD라는 오픈 소스 UNIX 기반 운영 체제를 선택했다.

 

- Unix 기반 운영 체제의 특징

 UNIX 기반 운영 체제의 중요한 특징 중 하나는 데몬(daemon)을 실행하는 방식이다. 데몬은 서비스와 유사한 프로세스로, 각기 다른 메모리 공간에서 독립적으로 실행된다. 이 방식은 하나의 데몬이 실패하더라도 다른 데몬에 영향을 미치지 않게 한다. 예를 들어, 하나의 데몬이 충돌하더라도 전체 운영 체제가 다운되지 않으며, 네트워크 엔지니어는 해당 데몬만 다시 시작하면 된다.

 

- Unix 운영 체제의 이점

 Junos가 UNIX 기반 운영 체제에서 실행되는 또 다른 장점은 유지 관리가 용이하다는 점이다. 예를 들어, 파일을 백업하거나 로그 파일을 열거나 새로운 Junos 업데이트를 네트워크 장치의 플래시 메모리에 복사하는 작업 등을 UNIX 기반 운영 체제에서 직접 처리할 수 있다.

 

- 최근 Linux 기반 운영 체제로 전환

 최근 Juniper는 Linux를 새로운 기본 운영 체제로 채택하고 있다. Linux는 FreeBSD와 동일한 수준의 안정성과 보안성을 제공하며, 자동화와 같은 기능에서 더 큰 유연성을 제공한다.

 

- One Junos

 Junos는 모든 Juniper 장치(스위치, 라우터, 방화벽 등)에 동일하게 적용된다. 이는 Juniper 네트워크 장치가 갖는 독특한 장점이다. 예를 들어, 네트워크 엔지니어가 Juniper 스위치를 다룰 수 있다면, 라우터나 방화벽을 구성하는 데에도 큰 어려움이 없다. Juniper는 이를 One Junos라고 부른다.

 

 One Junos는 기본적으로 Junos 명령어가 모든 종류의 Juniper 네트워크 장치에서 동일하다는 것을 의미한다. 예를 들어, 네트워크 장치를 구성하거나 상태를 조회하는 명령어는 스위치, 라우터, 방화벽 모두 동일하게 사용된다. 물론, 일부 장치가 특정 기능을 지원하지 않는 경우가 있지만, 예를 들어 EX 시리즈의 저가형 스위치는 MPLS를 지원하지 않는 경우 등은 제외된다.

 

 이와 같은 공통된 Junos 환경은 매우 유리한 점이 있다. 즉, 조직에서 새로운 Juniper 장비를 도입했을 때, 해당 장비를 설치하고 구성하며 지원할 네트워크 엔지니어가 추가 교육을 받을 필요가 없다는 것이다.

 

2. 제어, 전달, 관리 Plane

 상상해보자. 한 아이가 엄마에게 달려가며 "엄마, 나는 이걸 정말 원해!"라고 외치고, 또 다른 아이는 "엄마, 무릎이 아파!"라고 외쳤다. 그러나 엄마는 잠시 동안 누구의 말인지 구분하지 못한다. 보통 이런 상황은 엄마가 아이들에게 "조용히 해!"라고 소리치며 생각을 정리하는 방식으로 이어질 수 있다.

 

 이 상황을 네트워크에서 발생하는 서비스 거부(DoS) 공격처럼 비유할 수 있다. 즉, 너무 많은 요청으로 자원이 과부하되어 더 이상 처리할 수 없는 상황이다. 이게 네트워크와 무슨 관계가 있을까?

 

 잠시 상상해보면, 엄마는 라우터라고 하고, 아이들은 데이터 패킷이라고 하자. 하나의 패킷은 전화 통화를, 다른 하나는 라우팅 프로토콜 업데이트를 전달하고 있다. 네트워크 장치가 전화 통화 중인 패킷을 처리하는 동안 새로운 서브넷 정보가 추가되는 업데이트 때문에 잠시 전화 통화를 중단하는 일이 발생하는 것은 이상한 일이다.

 

 이 문제를 해결할 수 있는 방법 중 하나는 Intel Xeon E3와 같은 빠른 멀티코어 프로세서를 사용하는 것이다. 하지만 이는 비용이 많이 들고, 전력 소비가 크며, 열 발생 등의 단점이 있다. 또한, Xeon E3는 서버에서는 뛰어나지만, 데이터 패킷을 어디로 보낼지 결정을 내리는 데 최적화되지 않았다.

 

 더 실용적인 해결책은 패킷의 목적을 식별하고 라우터를 여러 부분으로 나누어 각 부분이 서로 다른 작업을 처리하도록 하는 것이다. 예를 들어, 하나는 전화 통화 관련 패킷을 처리하고, 다른 하나는 라우팅 업데이트를 처리하는 식이다. 즉, 하나의 엄마가 아닌 여러 명의 엄마가 필요하다는 것이다.

 

- 네트워크 장치의 세 가지 Plane

 라우터, EX 및 QFX 스위치, SRX 방화벽 등 네트워크 장치는 내부적으로 제어(Control) Plane, 전달(Forwarding) Plane, 관리(Management) Plane으로 분리되어 있다. 이 세 Plane은 매우 빠른 내부 링크로 연결되어 있다.

• 전달(Forwarding) Plane(Data Plane) 

 포워딩 플레인은 데이터를 장치 내에서 처리하는 역할을 한다. 예를 들어, 데이터를 네트워크의 한 노드에서 다른 노드로 전송할 때, 이 플레인은 패킷이나 프레임의 목적지 주소를 확인하고 해당 데이터를 어떤 인터페이스로 보낼지 즉시 결정한다.

 이를 효율적으로 처리하기 위해, Juniper는 ASIC(Application-Specific Integrated Circuit)이라는 특수한 프로세서를 설계했다. ASIC은 목적지 주소를 확인하고, 해당 주소에 대한 정보를 빠르게 참조하여 패킷을 해당 인터페이스로 전달하는 역할을 한다. 이 프로세서는 매우 높은 속도로 데이터를 처리할 수 있으며, 적은 전력을 사용하면서도 매우 효율적이다.

• 제어(Control) Plane

 컨트롤 플레인은 라우터 자체를 대상으로 하는 트래픽을 처리한다. 이 트래픽은 보통 라우팅 프로토콜에서 오는 새로운 경로 정보나 기존 경로의 유효성 정보를 포함하고 있다. 라우터는 새로운 서브넷을 처리하기 위해 알고리즘을 실행해야 하며, 이 작업은 상당한 처리 능력을 요구한다. 이러한 계산을 위해 컨트롤 플레인은 x86 기반의 프로세서를 사용할 수 있다. 예를 들어, 구형 J 시리즈 라우터는 Intel Celeron 프로세서를 사용하여 라우팅 정보를 처리할 수 있었다.

• 관리(Management) Plane

 관리 플레인은 장치의 관리와 관련된 트래픽을 처리한다. 이 트래픽은 반드시 사람이 직접 장치에 접근하는 것만을 의미하지 않는다. 예를 들어, 네트워크 관리 서버(SNMP)나 ICMP 요청(핑)과 같은 관리 프로토콜도 포함된다. 관리 플레인은 이들 요청을 처리하여 장치의 상태를 모니터링하거나, 문제가 발생하면 경고를 보낸다.

 

- Plane 분리의 중요성

 각 플레인을 분리하는 이유는 간단하다. 만약 라우터가 라우팅 프로토콜에서 전송되는 대규모 데이터베이스를 처리해야 한다면, 라우터가 모든 작업을 한 번에 처리하려고 하면 과부하가 걸릴 수 있다. 또한, 악성 공격자가 관리 플레인에 대량의 스푸핑된 트래픽을 보내 라우터를 마비시킬 수도 있다. 이러한 상황을 방지하기 위해 각 플레인을 분리함으로써, 라우터는 관리 트래픽이나 라우팅 업데이트가 들어와도 데이터 포워딩에는 영향을 미치지 않도록 할 수 있다. 이렇게 하면 네트워크가 안정적으로 운영될 수 있다.

 

 이와 같이 네트워크 장치는 포워딩, 컨트롤, 관리의 세 가지 플레인을 분리하여 각 플레인이 수행하는 역할을 명확하게 구분하고, 서로 다른 처리 능력을 가진 프로세서를 통해 최적화된 성능을 발휘할 수 있도록 설계된다.

 

3. 전송 트래픽과 예외 트래픽

라우터나 스위치에서 처리되는 트래픽은 전송 트래픽(transit traffic)과 예외 트래픽(exception traffic)으로 나눌 수 있다.

 

- 전송 트래픽(Transit Traffic)

 전송 트래픽은 라우터를 통과하는 동안 라우터 자체가 아닌 다른 출발지와 목적지를 가진 트래픽을 의미한다. 예를 들어, 10.0.10.10 IP 주소를 가진 노트북이 192.168.1.23 주소의 서버로 패킷을 보내는 경우를 생각해보자. 이 패킷은 라우터들을 거쳐 서버로 가지만, 라우터는 그저 중계 역할을 하는 것이다. 이러한 트래픽은 전송 트래픽으로 간주된다.

 

 전송 트래픽은 대체로 전달(Forwarding) Plane에서 처리된다. 포워딩 평면은 네트워크 상에서 다른 노드로 데이터를 전달하는 데 필요한 정보를 확인하고 패킷을 해당 인터페이스로 전달하는 역할을 한다. 이때 트래픽은 단방향(unicast)뿐만 아니라 다수의 장치에 동시에 전달되는 다중 송신(multicast) 트래픽도 포함될 수 있다. 다만, 라우팅 프로토콜 업데이트가 포함된 트래픽은 전송 트래픽으로 간주되지 않는다.

 

- 예외 트래픽(Exception Traffic)

 예외 트래픽은 라우터나 스위치의 목적지 주소로 향하는 트래픽을 의미한다. 이는 라우터가 직접 처리해야 하는 트래픽으로, 일반적인 트래픽 흐름 규칙을 따르지 않는다. 예를 들어, 라우터가 라우팅 업데이트를 받거나, 관리자가 장치에 접속하려 할 때 발생하는 트래픽은 예외 트래픽으로 분류된다.

 

 예외 트래픽은 제어(Control) Plane 또는 관리(Management) Plane에서 처리된다. 

제어 평면에서 처리되는 예외 트래픽	- 라우팅 프로토콜의 업데이트 처리 (예: RIP, OSPF, IS-IS, BGP) - 라우팅 프로토콜에 대한 업데이트 송신
관리 평면에서 처리되는 예외 트래픽	- SSH, Telnet, HTTPS, HTTP를 이용한 장치 구성 - SNMP GET 요청 - VRRP 헬로 및 상태 유지를 위한 트래픽 - NTP 요청(장치 간 시간 동기화)

 

- 전송 트래픽과 예외 트래픽의 변환

 흥미로운 점은 일부 트래픽이 한 라우터를 통과할 때 전송 트래픽으로 분류되다가, 다른 라우터에 도달하면 예외 트래픽으로 변할 수 있다는 것이다. 예를 들어, 노트북이 Telnet을 통해 ACME-GLA-RTR-01 라우터에 접속하려고 할 때, 트래픽은 여러 서브넷을 거쳐야 한다. 이 트래픽은 중간에 있는 라우터들에서는 전송 트래픽으로 분류되지만, 최종 목적지인 ACME-GLA-RTR-01 라우터에서는 예외 트래픽으로 분류된다.

 

4. 라우팅 엔진(RE)과 패킷 포워딩 엔진(PFE)

 네트워크 장치는 데이터 포워딩, 라우팅 프로토콜 제어, 구성 및 모니터링을 담당하는 관리 기능 등 포워딩, 제어, 관리 평면으로 나뉘어진다. 이 분할은 논리적인 것처럼 보이지만, 실제로는 하드웨어에 의해 물리적으로 분리되어 있다. 이 구조는 성능 향상을 위해 설계된 중요한 특징이다.

라우팅 엔진(RE)	- 장치의 두뇌 역할을 수행하며, 라우팅 프로토콜 및 정적 경로에서 입력된 정보를 바탕으로 네트워크 경로를 계산함. - 제어(Control) Plane과 관리(Management) Plane이 RE의 일부로 포함되어 있어, 네트워크 엔지니어가 장치에 연결하여 설정을 변경하거나 라우팅 프로토콜이 네트워크 업데이트를 전송할 때 RE가 이를 처리함. - Junos 운영체제도 RE에서 실행되며, 장치의 핵심적인 소프트웨어 역할을 담당합니다.
패킷 포워딩 엔진(PFE)	- 포워딩(Forwarding) Plane을 관리하며, 패킷이나 프레임을 적절한 인터페이스로 전환하거나 라우팅하는 역할을 함. - ASIC(Application-Specific Integrated Circuits) 기반으로 설계되어 고속 처리를 지원하지만, 자체적으로는 복잡한 판단을 내릴 수 없으며 RE에서 제공하는 지침을 따라야 함. - RE가 생성한 포워딩 테이블을 PFE로 전달받아 이를 기반으로 패킷을 처리함

 

- RE와 PFE 동작 원리

라우팅 정보 수집	라우팅 프로토콜을 통해 새로운 경로를 학습하거나 네트워크 엔지니어가 설정을 변경함.
라우팅 테이블 생성	RE는 수집된 정보를 바탕으로 라우팅 테이블을 생성하고, 이를 처리하여 출구 인터페이스 정보를 포함한 포워딩 테이블을 작성함.
포워딩 테이블 전달	작성된 포워딩 테이블은 PFE로 전송되어 패킷 처리에 활용됨.

 

- 내부 링크의 역할

• RE와 PFE를 연결하는 내부 링크는 양방향으로 빠른 데이터 전송을 지원하며, 라우팅 프로토콜 메시지나 특수 패킷을 처리할 때 사용된다.
• 대부분의 트래픽은 PFE에서 처리되지만, ICMP 메시지 생성이나 특이한 IP 옵션 필드가 포함된 패킷은 RE로 전달된다.

 

- 보안 및 안정성

DoS 공격 방지	- RE로 전달되는 과도한 트래픽을 제한하기 위해 내부 링크에 속도 제한(Rate Limiting)이 적용됨. - 이를 통해 RE가 과부하로 인해 다운되는 상황을 예방함.
RE 장애 시 대응	- RE가 다운되더라도 PFE는 독립적으로 동작하며, 트랜짓 트래픽(Transit Traffic)을 계속 처리할 수 있음. - RE가 복구되면 정상적인 작업을 재개함.
안정성	- Junos는 데몬(Daemon) 기반으로 설계되어 있어 안정적인 동작을 보장하며, RE의 완전한 고장은 드문 편임.

 

5. 프로토콜 데몬(Protocol Daemons)

- 데몬이란?

 데몬은 Microsoft Windows의 서비스와 유사하며, 각 데몬은 독립적인 메모리 공간에서 실행된다. 이러한 구조는 특정 데몬이 충돌하더라도 운영 체제 및 다른 데몬에 영향을 주지 않도록 설계되었다.

 

- Junos 운영 체제에서의 데몬

• Junos를 실행하는 네트워크 장치는 여러 데몬을 실행한다.
• CLI 명령어 'show system processes'를 통해 현재 실행 중인 데몬을 확인할 수 있으며, summary 옵션을 추가하면 시작된 데몬의 총 수를 확인할 수 있다.
  • ex) SRX-110 장치에서 134개의 데몬이 시작되었으며, 그중 14개는 실행 중이고 107개는 휴면 상태이다.

 

- 데몬 상태와 Junos 데몬 식별

• 휴면 상태의 데몬은 특정 기능이 구성되었지만 사용 중이지 않을 때 FreeBSD와 Junos가 이를 비활성화한 것이다.
• 'show system processes' 명령의 출력에서 경로가 /usr/sbin/로 시작하는 데몬이 Junos와 관련된 데몬이다.
  • 필터를 사용해 /usr/sbin/ 경로의 데몬만 출력할 수도 있다.

 

- 주요 데몬과 역할

 Junos에서 중요한 데몬을 알아두는 것은 네트워크 엔지니어에게 유용하다.

Daemon	Name	Description
rpd	Routing Protocol Daemon	라우팅 프로토콜 기능 유지 : BGP, OSPF, RIP와 같은 라우팅 프로토콜의 동작을 관리함
chassisd	Chassis Daemon	섀시 및 환경 프로세스 제어 : 장치의 섀시와 관련된 프로세스와 환경 상태를 제어함
Snmpd	SNMP Daemon	SNMP 서버와의 상호작용 지원 : SNMP 서버가 장치와 상호작용할 수 있도록 지원하며, SNMP 에이전트에서 서버로 데이터를 보고할 수 있도록 함.
mgd	Management Daemon	관리 연결 제어 : SSH, Telnet, HTTPS를 통해 네트워크 장치와의 관리 연결을 제어함
dcd	Device Control Daemon	하드웨어 및 인터페이스 카드와의 통신 지원 : Junos가 하드웨어 및 인터페이스 카드와 통신할 수 있도록 dcd 데몬이 이를 지원함
inetd	Internet Service Daemon	네트워크 간 연결 제공 : Junos가 네트워크 간 연결성을 제공함
dhcpd	DHCP Daemon	동적 IP 주소 및 DHCP 지원 : Junos가 동적 IP 주소를 제공하고 DHCP 검색을 수행할 수 있도록 함

 

- 데몬 문제 해결

데몬 충돌 상황	- 특정 데몬이 응답하지 않을 경우, 이를 재시작하여 문제를 해결할 수 있음. - CLI 명령어 restart를 사용하며, 데몬 이름(풀 네임)을 입력해야 함.   · 예: restart chassis-control
라우팅 프로토콜 문제 해결 예시	- rpd 데몬 충돌 시, CLI에서 restart routing을 입력해 라우팅 데몬을 재시작함.

 

- 데몬 재시작 옵션

restart 명령에는 다음 세 가지 옵션이 제공된다.

Gracefully	다른 프로세스에 영향을 주지 않도록 부드럽게 재시작함.
Immediately	즉시 데몬을 종료하고 재시작함.
Softly	설정을 다시 읽고 활성화하지만 소프트웨어 프로세스를 완전히 재시작하지 않음.

 

- 로그 확인 및 프로세스 ID(PID)

• 데몬 재시작 후 로그 파일에 관련 기록이 남는다.
  • ex) "데몬이 신호 번호 9로 종료되었습니다."
  • 로그에 표시된 PID(Process ID)를 통해 특정 데몬을 확인할 수 있다.
• CLI 명령어에서 PID로 필터링하여 해당 데몬이 제대로 재시작되었는지 확인 가능하다.