Cisco 300-410: 서비스 품질 및 컨트롤 플레인 보호 — 학습 가이드

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

다음의 일부입니다: Cisco CCNP Enterprise 300-410 ENARSI — 학습 가이드. 검증된 답안으로 연습하기: Cisco 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

서비스 품질(QoS)과 컨트롤 플레인 보호(CoPP/CPPr)는 함께 작동하여 부하 및 공격 상황에서도 비즈니스에 중요한 애플리케이션과 네트워크 자체가 안정적으로 유지되도록 보장합니다. QoS는 트래픽을 구별하고, 지연에 민감한 플로우의 우선순위를 지정하며, 부족한 링크의 혼잡을 관리합니다. CoPP/CPPr은 라우터 CPU와 관리 스택을 우발적인 과부하 및 악의적인 이벤트로부터 보호합니다. 올바른 설계를 위해서는 일관된 엔드투엔드(end-to-end) 마킹, 규율 있는 신뢰 경계, 적절한 컨디셔닝(폴리싱/셰이핑), 잘 조정된 크기의 큐, 선제적인 혼잡 회피, 터널/암호화에 대한 신중한 처리, 그리고 애플리케이션 동작과 연관된 카운터를 사용한 지속적인 검증이 필요합니다.

분류, 신뢰 및 엔드투엔드 마킹

트래픽 분류 및 마킹은 각 홉에서 패킷이 어떻게 큐에 들어가고 잠재적으로 폐기될지를 결정합니다.

• 분류 및 매칭

  • 액세스 리스트, DSCP/IP precedence, CoS (802.1p), NBAR 애플리케이션 시그니처 또는 터널 내부 헤더(qos pre-classify 사용)를 기준으로 매칭합니다.
  • 결정성을 유지하십시오: 가능하면 Layer 3/4 필드를 기준으로 매칭하고, 일부 플랫폼에서는 CPU에 미치는 영향을 고려하여 필요한 경우에만 NBAR을 사용하십시오.

• 신뢰 경계

  • 네트워크가 기존 마킹을 수용하는 지점을 정의합니다. 일반적인 경우: 엔드 호스트는 신뢰하지 않고, 엔터프라이즈 전화기와 알려진 QoS 도메인으로의 업링크는 신뢰합니다.
  • 엣지에서는 신뢰할 수 없는 트래픽을 정책에 정의된 DSCP 값으로 리마킹(remark)하고, 직접 관리하고 인증하는 장치만 신뢰하십시오.
  • 엔드포인트를 향하는 스위치 포트에서는 장치 유형을 명시적으로 확인하지 않는 한 신뢰를 제거하십시오(no trust dscp/cos).

• 마킹

  • DSCP(6비트)는 IP 네트워크에서 주요 엔드투엔드 마킹입니다. IP precedence(3비트)는 레거시이며 DSCP의 상위 비트에 매핑됩니다.
  • CoS(802.1p, 3비트)는 VLAN 트렁크를 통과하는 Layer 2 프레임을 마킹합니다. L2/L3 경계에서 DSCP↔CoS를 일관되게 매핑하십시오.
  • MPLS 코어에서는 3비트 Traffic Class(TC, 이전 EXP)가 QoS를 전달합니다. VPN 또는 TE 코어 전반에 걸쳐 의미를 보존하기 위해 인그레스(ingress)에서 DSCP를 TC로, 이그레스(egress)에서 TC를 다시 DSCP로 매핑하십시오.

• 마킹 일관성

  • 음성 베어러(낮은 지터)에는 EF, 통화 시그널링에는 CS3/AF31/AF32, 대화형 비디오에는 AF4x, 중요 데이터에는 AF2x/AF1x, 최선형(best effort)에는 CS0/BE, 스캐빈저(scavenger)에는 CS1을 할당하십시오.
  • 단일 엔터프라이즈 QoS 정책을 문서화하고, WAN 공급업체가 계약된 대로 이를 준수하고 매핑하는지 확인하십시오.
  • 도메인 간 변환이 필요한 경우를 제외하고는 경로 중간에서 리마킹하는 것을 피하십시오. 그렇지 않으면 우선순위 역전 및 문제 해결의 복잡성을 야기할 수 있습니다.

예시 (인그레스 엣지 마킹):

undefined

장애 모드 및 절충점:

• 잘못된 엣지를 신뢰하면 우선순위 남용으로 이어져, 중요도가 낮은 플로우가 중요 큐를 고갈시킬 수 있습니다.
• 일관되지 않은 DSCP↔CoS 매핑은 L2/L3 전환 지점에서 QoS를 깨뜨립니다.
• 소프트웨어 플랫폼에서 NBAR을 과도하게 사용하면 CPU 사용률이 높아질 수 있으므로 정적 매치를 선호하십시오.

컨디셔닝, 큐잉 및 혼잡 회피

트래픽 컨디셔닝은 네트워크가 감당할 수 있는 속도로 트래픽을 셰이핑하고, 엄격한 제한이 필요한 곳에 폴리싱을 적용합니다.

• 폴리싱 vs. 셰이핑

  • 폴리싱은 토큰 버킷을 사용하여 속도를 강제합니다. 초과분은 폐기되거나 선택적으로 리마킹됩니다. 이는 링크 용량을 보존하지만 손실을 증가시키고 TCP 백오프 및 애플리케이션 재시도를 유발할 수 있습니다.
  • 셰이핑은 버스트를 완화하고 다운스트림에서의 폐기를 줄이기 위해 목표 속도(일반적으로 통신사 CIR)로 버퍼링하고 전송합니다. 이는 큐 깊이에 비례하여 지연과 지터를 추가합니다.

• 버스트 매개변수

  • 단일 속도 2-매개변수 폴리서는 보장 정보 속도(CIR)와 보장 버스트(Bc), 그리고 선택적으로 초과 버스트(Be)를 사용합니다.
  • RTT 및 MTU에 비해 Bc가 너무 작으면 단편화 수준의 폐기와 비효율적인 처리량을 유발합니다. 셰이핑의 경우 Bc 크기를 최소 대역폭-지연 곱의 1~2배로, 폴리싱의 경우 여러 MTU 크기로 설정하십시오.

• CBWFQ 및 LLQ

  • 클래스 기반 가중 공정 큐잉(CBWFQ)은 클래스별 최소 대역폭을 보장합니다. 셰이핑 하에서 대역폭을 kbps 또는 백분율로 설정하십시오.
  • 저지연 큐(LLQ)는 클래스에 엄격한 우선순위 처리(priority)를 추가하며, 기아(starvation) 상태를 방지하기 위해 설정된 속도로 폴리싱됩니다. 실시간 음성/영상 베어러만 LLQ에 포함되어야 합니다.
  • 큐 제한(queue-limit)은 클래스당 버퍼링할 수 있는 최대 패킷 수를 설정합니다. 너무 높으면 지연이 증가하고, 너무 낮으면 폐기가 증가합니다. 애플리케이션의 허용 범위와 균형을 맞추십시오.

• WRED vs. 테일 드롭

  • 테일 드롭(Tail drop)은 큐가 가득 찼을 때만 패킷을 폐기합니다. 이는 전역 TCP 동기화와 큰 변동을 유발할 수 있습니다.
  • 가중 임의 조기 탐지(WRED)는 큐가 가득 차기 전에 확률적 폐기를 시작합니다. DSCP 기반 WRED는 우선순위가 높은 클래스가 더 낮은 조기 폐기 확률로 더 깊은 큐를 견딜 수 있게 합니다.
  • WRED는 TCP 플로우에 유용합니다. 주로 UDP(음성)인 경우 백오프 없이 손실만 추가합니다. LLQ에서는 WRED를 활성화하지 마십시오.

예시 (자식 CBWFQ/LLQ 및 WRED를 포함한 부모 셰이핑):

undefined

주요 설계 포인트:

• 항상 제어 가능한 가장 낮은 다운스트림 병목 구간에 맞춰 셰이핑하십시오. 공급자의 폐기 정책이 아닌 자체 큐잉 정책에 따라 결정되도록 하십시오.
• 코덱과 통화량을 기준으로 LLQ 크기를 정하십시오. 헤더 및 VAD 변동성을 고려하여 5~10%의 오버헤드를 포함하십시오.
• 다중화된 TCP 플로우가 지배적인 곳에서만 WRED를 활성화하고, 조기 폐기를 방지하기 위해 가중치를 보수적으로 조정하십시오.

터널 및 WAN 링크에서의 QoS

터널링과 암호화는 내부 헤더를 가리고 MTU를 변경하여, 트래픽 분류(classification)와 단편화(fragmentation)에 영향을 줍니다.

• GRE/DMVPN 및 IPsec

  • 특별한 처리가 없으면, 트래픽 분류 시 외부 헤더만 볼 수 있습니다. 터널 인터페이스에 qos pre-classify를 사용하여 장비가 캡슐화/암호화 전에 내부 5-tuple 및 DSCP를 기준으로 트래픽을 분류하도록 해야 합니다.
  • 전송 구간에서 네트워크 QoS 동작을 유지하기 위해 DSCP 값을 외부 헤더에 보존하거나 복사합니다.
  • MTU와 MSS를 조정하여 단편화 및 PMTUD 실패를 방지합니다. IPsec의 경우, 특정 플랫폼 및 통신사에서는 암호화 후 단편화(fragmentation after-encryption)가 필요할 수 있습니다.

• 터널별 QoS 및 계층적 설계

  • mGRE/DMVPN에서는 계층적 QoS(터널별 셰이핑 후 클래스별 LLQ/CBWFQ 적용)를 적용하여 스포크(spoke) 간에 공정한 대역폭 공유를 보장합니다.
  • 회선 사업자가 엄격한 폴리서(policer)로 CIR을 강제하는 경우, 사업자에 의한 tail drop을 피하기 위해 CIR과 같거나 약간 낮은 속도로 셰이핑(shape)해야 합니다.

예시 (터널에 대한 DMVPN 허브/스포크 QoS): interface Tunnel30 ip address 10.0.30.1 255.255.255.0 tunnel mode gre multipoint qos pre-classify ip mtu 1400 ip tcp adjust-mss 1360 service-policy output PM-WAN-PARENT ! crypto ipsec transform-set TS esp-aes 256 esp-sha-hmac crypto ipsec profile DMVPN-PROFILE set transform-set TS ! ! 플랫폼에 따라 다름: crypto ipsec fragmentation after-encryption

일반적인 문제점 및 완화 방안:

• qos pre-classify가 누락되면 암호화 후 모든 트래픽이 class-default로 분류되어 실시간 플로우(flow)가 대역폭을 할당받지 못하게 됩니다.
• 잘못된 MTU/MSS 설정은 대용량 세그먼트의 블랙홀링(blackholing)과 비정상적인 애플리케이션 성능을 유발합니다. 경로 MTU를 종단 간(end-to-end)으로 검증해야 합니다.
• 소프트웨어 터널에 라인 레이트(line rate)로 복잡한 정책을 적용하면 CPU에 부하를 줄 수 있습니다. 가능한 경우 하드웨어 오프로드를 사용하는 것이 좋습니다.

컨트롤 플레인 보호(CoPP/CPPr) 및 운영 검증

CoPP는 컨트롤 플레인 경로의 제어 및 관리 트래픽을 분류하고 속도를 제한하여 라우터 CPU를 보호합니다. CPPr은 host, transit, CEF-exception 서브인터페이스를 사용하여 더 세분화된 제어를 추가합니다.

• CoPP 기본 사항

  • 데이터 인터페이스가 아닌 컨트롤 플레인에 정책을 연결합니다.
  • 일반적으로 지원되는 매치 유형은 ip dscp, ip precedence, access-group입니다. CoPP에서 참조하는 ACL 항목에는 log 키워드를 사용하지 마십시오.
  • 중요한 라우팅 프로토콜(BGP, OSPF, 해당되는 경우 RSVP/LDP)을 최선형(best-effort) 관리(HTTP) 및 대량 제어 트래픽(예외적인 경우 CPU로의 NetFlow export)과 분리하십시오. 중요한 프로토콜에는 넉넉한 CIR을 제공하십시오.

• CPPr 세부 정보

  • control-plane host는 라우터에서 종단되는 트래픽(예: SSH, SNMP, 라우팅 세션)을 관리합니다.
  • control-plane transit는 하드웨어에서 punt된 예외 트래픽(예: TTL-exceeded, MTU exceeded)을 처리합니다.
  • control-plane cef-exception은 CEF 관련 punt를 관리합니다.
  • 한 클래스가 비정상적으로 동작할 때 부수적인 피해를 방지하기 위해 서브인터페이스별로 다른 정책을 적용하십시오.

• 제외 및 올바른 연결을 포함한 CoPP 예제:

undefined

undefined

undefined

!

undefined

undefined

undefined

!

undefined

undefined

undefined

undefined

undefined

! ! 정책이 데이터 인터페이스가 아닌 컨트롤 플레인에 있는지 확인:

undefined

undefined

undefined

참고:

• BGP 속도를 너무 공격적으로 제한하면 keepalive 누락, 세션 재설정, 경로 변동(route churn)이 발생할 수 있습니다. 폴리싱을 해야 한다면 충분한 CIR을 설정하고, 스파이크 동안 드롭을 피하기 위해 exceed-action transmit을 고려하십시오.

• 허용(permit) 전에 ACL 거부(deny)를 사용하여 특정 신뢰할 수 있는 관리 소스를 제외하십시오. 해당 클래스 아래에 ACL을 매치로 적용합니다.

• 관리 플레인 보완 사항

  • IPv6 RA Guard는 L2 포트에서 악의적인 Router Advertisement를 차단하지만, RA가 터널링될 때는 보호할 수 없습니다. 터널 엔드포인트에서 강제하거나 가능한 경우 인증을 사용하십시오.
  • IPv6 Source Guard는 바인딩 테이블을 사용하여 유효한 소스 주소만 허용합니다. 액세스 포트에서 알 수 없거나 할당되지 않은 IPv6 소스로부터의 트래픽을 드롭하여 CPU 바운드 예외 트래픽을 줄입니다.
  • 장치 보안 강화(사용하지 않는 서비스 비활성화, vty에 ACL 사용, SNMP 커뮤니티 제한)는 컨트롤 플레인 노출을 줄입니다.

• 검증 및 카운터

  • show policy-map interface 및 show policy-map control-plane을 사용하여 패킷 수, 드롭, 폴리스 작업을 확인하십시오. CPU 바운드 증상(예: 느린 SSH, 간헐적인 SNMP)이 나타나면 먼저 show policy-map control-plane을 실행하십시오.
  • 하드웨어 포워딩 플랫폼에서는 WRED/tail 드롭에 대해 show platform hardware qfp active statistics drop 또는 동등한 ASIC 카운터와 연관 지어 확인하십시오.
  • 큐의 경우, show policy-map interface 및 show queueing interface를 사용하여 큐 깊이, tail/WRED 드롭, 우선순위 큐 폴리싱을 확인하십시오.
  • 애플리케이션 증상을 찾으십시오:
    • 음성 지터, 패킷 손실 또는 끊기는 오디오는 LLQ가 너무 작거나 신뢰 경계(trust boundary)가 잘못되었음을 시사합니다.
    • 정상적인 ping에도 불구하고 SSH가 느리거나 연결이 끊기는 것은 CoPP가 관리 트래픽을 폴리싱하고 있음을 나타낼 수 있습니다.
    • 간헐적인 SNMP는 관리 클래스 드롭 또는 한도를 초과하는 CEF 예외 punt와 관련이 있습니다.
    • WRED 드롭이 증가하면서 부하 시 TCP 처리량이 붕괴되는 것은 예상된 동작입니다. tail drop만 있는 경우, 동기화된 톱니파(sawtooth) 흐름을 찾으십시오.

실제 문제 시나리오

Acme Engineering은 인터넷 브로드밴드를 통해 IPsec+mGRE를 사용하는 DMVPN 단일 허브 네트워크를 운영하고 있습니다. 사용자들은 피크 시간대에 HQ로의 VoIP 끊김, 브랜치 라우터의 간헐적인 SNMP 폴링, 허브로의 느리거나 끊기는 SSH 연결을 보고합니다.

1. 신뢰 경계(trust boundary) 설정 및 엣지에서 리마킹(remark)

• 근거: 전화기와 신뢰할 수 있는 업링크만이 EF/CS3를 설정할 수 있는 유일한 장치입니다. 다른 모든 액세스 트래픽은 BE로 리마킹됩니다. 이는 실시간 클래스를 고갈시킬 수 있는 우선순위 남용을 방지합니다.

2. DMVPN 터널에 계층적 QoS 구현

• 근거: 업스트림 폴리싱을 피하기 위해 측정된 공급자 속도(예: 20 Mbps)로 터널에 부모 셰이퍼(parent shaper)를 적용합니다. 부모 셰이퍼 아래에서 EF 음성에는 LLQ를, 비디오 및 중요 데이터에는 대역폭 클래스를, TCP 위주 클래스에는 WRED를, 기본값에는 fair-queue를 사용합니다. 이는 통신 사업자가 패킷을 드롭하기 전에 혼잡 관리를 로컬에서 처리하도록 합니다.

3. qos pre-classify 활성화 및 MTU/MSS 조정

• 근거: qos pre-classify는 GRE/IPsec 캡슐화 전에 정책이 내부 IP/포트/DSCP와 일치하도록 보장합니다. ip mtu 1400 및 ip tcp adjust-mss 1360은 캡슐화 오버헤드로 인한 단편화/블랙홀링을 방지합니다. after-encryption fragmentation은 공급자 동작을 수용하도록 설정됩니다.

4. 인터페이스에 적용된 CoPP 제거 및 컨트롤 플레인에 연결

• 근거: CoPP는 수신 인터페이스에 관계없이 CPU를 보호해야 합니다. 물리적 인터페이스에서 모든 input service-policy를 분리하고 PM-COPP를 컨트롤 플레인에 적용하여 punt된 트래픽과 호스트에서 종단되는 트래픽을 중앙에서 관리합니다.

5. 안전한 CIR을 가진 별개의 CoPP 클래스 생성; 신뢰할 수 있는 소스 제외

• 근거: BGP를 keepalive와 버스트에 충분한 CIR을 가진 자체 클래스에 배치하고, 세션 재설정을 피하기 위해 conform/exceed transmit을 구성합니다. CPU로의 웹 관리를 제한하기 위해 HTTP/HTTPS를 낮은 속도로 폴리싱합니다. Telnet/SSH 예외의 경우, ACL에서 신뢰할 수 있는 관리 IP를 거부하여 정책이 해당 IP를 속도 제한하지 않도록 하면서 다른 모든 소스는 계속 제어합니다.

6. 카운터와 증상을 기반으로 검증 및 반복

• 근거: show policy-map control-plane을 사용하여 관리 드롭이 관찰된 SSH/SNMP 문제와 일치하는지 확인하고, 드롭이 멈출 때까지 CIR을 조정합니다. show policy-map interface Tunnel30을 사용하여 LLQ 사용률을 확인하고 정상적인 통화량에서 우선순위 오버플로우 폴리싱이 발생하지 않는지 확인합니다. 중요 클래스에서 WRED 및 tail 드롭을 모니터링합니다. LLQ 드롭 없이 음성 품질이 계속 나쁘면 LLQ 백분율을 약간 높이고, 드롭이 발생하면 코덱과 대역폭에 맞게 LLQ와 부모 셰이퍼의 크기를 더 정확하게 조정합니다.

올바른 신뢰 경계를 적용하고, 병목 지점 이전에 셰이핑하고, 캡슐화 전에 분류하고, 적절한 범위의 CoPP/CPPr 정책으로 컨트롤 플레인을 보호함으로써 Acme Engineering은 전체 처리량을 희생하지 않으면서 음성 품질을 복원하고 관리 액세스를 안정화합니다.

← 멀티캐스트 라우팅 및 분배 · 모든 도메인 · VPN →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →