소개

이 문서에서는 Cisco CNC 4.1에서 Lift-and-Shift를 통한 7.1로의 복잡한 대규모 고정 무선 네트워크 마이그레이션에 대한 사례 연구에 대해 설명합니다.

요약

이 백서에서는 Cisco CNC(Crosswork Network Controller) 버전 4.1에서 버전 7.1로 대규모 고정 무선 네트워크를 마이그레이션하는 방법에 대한 자세한 사례 연구를 소개합니다. 현재 업그레이드 메커니즘이 없기 때문에 전환에는 전체 리프트 앤 시프트 구축이 필요했으며, 2,000개 이상의 네트워크 장치와 여러 상호 의존적인 시스템에 걸쳐 아키텍처, 운영 및 통합이 크게 복잡해졌습니다. 이 연구에서는 여러 영역에서 직면한 과제를 조명합니다.

특히 대량의 워크플로에서 확장성, 정확성, 운영 결정성을 보장하는 데 자동화의 필수 역할이 강조된 것이 주요 성과입니다. 그 결과 생산 환경은 통제된 실험실 조건과 상당히 다르며, 이에 따라 적응형 문제 해결, 반복적인 검증, TAC 및 사업부 엔지니어링 팀과의 지속적인 관여가 필요함을 알 수 있습니다. 이 작업은 실용적인 통찰력, 검증된 방법론, 권장 모범 사례를 바탕으로 하며, 이는 향후 CNC 업그레이드 및 대규모 오케스트레이션 플랫폼 전환에 대한 참조 청사진으로 사용됩니다.

배경

5G 네트워크의 확산, 연결된 장치의 빠른 채택, 기업 및 소비자 환경의 디지털화로 인해 트래픽 양이 크게 증가하고 규모에 맞게 안전하고 안정적으로 제공되어야 하는 서비스의 다양성이 증가했습니다. CSP(Communications Service Providers)는 이제 고도로 역동적인 네트워크를 운영합니다. 기존의 사일로화된 운영 툴은 종종 복잡성을 초래하고, 사용자 경험을 저하시키며, OpEx(운영 비용)를 높입니다.

운영자들은 경쟁력을 유지하기 위해 자동화, 가상화, SDN 원칙, 자체 최적화 분석 기반 네트워크를 기반으로 한 현대화 운영 모델을 점점 더 채택하고 있습니다.

Cisco CNC(Crosswork Network Controller)는 운영 워크플로를 간소화하고, TCO(총 소유 비용)를 줄이며, 멀티벤더 전송 네트워크 전반에서 인텐트 기반 자동화를 구현하여 이러한 변화를 지원하도록 설계되었습니다. CNC는 서비스 프로비저닝, 네트워크 상태 모니터링 및 실시간 최적화를 위한 통합 플랫폼을 제공하여 운영자가 단일 창을 통해 대규모 IP 네트워크를 보다 사전 대응적이고 효율적으로 관리할 수 있도록 합니다.

기본 Crosswork Infrastructure는 모든 CNC 애플리케이션이 실행되는 탄력적이고 확장 가능한 클러스터 프레임워크를 제공합니다. CNC 7.1의 경우 여기에는 최적화 엔진, 활성 토폴로지, 변경 자동화, 상태 인사이트, EMF(Element Management Functions), 서비스 상태 및 CWM(Crosswork Workflow Manager)과 같은 모듈이 포함되며, 각 모듈은 엔드 투 엔드 오케스트레이션 및 보장에 기여합니다.

그러나 CNC를 업그레이드하는 것은 고유한 과제를 수반합니다. CNC는 내부 업그레이드를 지원하지 않으므로 완전히 리프트 앤 시프트 방식으로 구축해야 합니다. 즉, 새 환경이 기존 환경과 병렬로 구축되고 모든 데이터 및 서비스가 새 버전으로 마이그레이션됩니다. 이 사례 연구에서는 CNC 4.1에서 CNC 7.1로 대규모 업그레이드된 제품을 살펴봅니다. 이는 다른 모든 서비스 제공업체에 백본 서비스를 제공하는 호주 주요 서비스 어그리게이터입니다.

마이그레이션은 여러 개의 맞춤형 변경 자동화 플레이북, 맞춤형 Health Insight KPI, L2/L3 VPN 서비스 조정 요건, 보안 ZTP의 필요성 때문에 특히 복잡했습니다.

이 큰 버전의 점프는 새로운 릴리스에서 기존 활용 사례가 어떻게 동작할지 예측하기 어렵게 만들었던 내부 아키텍처 및 동작 변화를 감안할 때 추가적인 불확실성을 도입했습니다. 따라서 모든 활용 사례에 대한 포괄적인 검증과 조정이 필요했습니다.

하이브리드/작업자 노드 수, CDG 배포, PCE 크기 조정, 기존 리소스 점유 공간 유지 여부 등을 포함하여 최적의 리소스 할당을 결정하는 데 상당한 계획이 투입되었습니다.

초기 CNC 7.1 구축 및 검증은 내부 CALO 랩에서 수행되었으며, 이를 통해 안전한 환경에서 실험을 수행하고, 구성을 개선하고, 신뢰성을 구축했습니다. 그 뒤를 이어 운영 환경을 면밀히 미러링하는 내부 테스트 환경이 구축되었습니다. 마지막 단계에서는 프로덕션 환경에 CNC 7.1을 구축하고, 디바이스 레벨 컨피그레이션 변경 사항을 적용하고, 새 컨트롤러에 대한 모든 디바이스 및 관련 서비스의 단계별 마이그레이션을 수행했습니다.

프로덕션 네트워크

공중 폭주 생산 네트워크는 호주 전역에 퍼져 있습니다. NCS에서 ASR9K에 이르는 2K+ 디바이스가 존재함에 따라 CNC는 라이브 토폴로지 뷰를 제공하여 이러한 모든 디바이스를 관리했습니다. IOS-XR 24.3.2를 실행하는 SWR(Small Wireless Router)로 알려진 NCS540이 약 2,000대, LWR(Large Wireless Router)로 알려진 ASR-9K(Version 7.5.2)가 30대였습니다.

Crosswork 설정은 3개의 하이브리드 노드와 2개의 작업자 노드로 구성되었습니다. 디바이스의 CDG는 총 5개였으며, 4개는 활성 상태이고 1개는 대기 노드입니다. 따라서 풀에는 대기 CDG가 1개만 있으므로 보호가 제한적입니다. 하지만 당신의 요구 사항을 고려해 볼 때, 이것은 진행되었습니다. 모든 VM이 단일 데이터 센터에 구축된다는 사실도 1개의 스탠바이 VM으로 더 쉽게 결정을 내릴 수 있도록 했습니다.

CDG는 SNMP, CLI 및 GNMI와 같은 다양한 프로토콜을 통해 디바이스에서 데이터 수집을 처리하는 구성 요소입니다. CDG가 수집한 데이터는 내부 카프카를 통해 크로스워크에 노출된다. Crosswork에 연결된 디바이스는 CDG에 연결되어 있어야 합니다. 그러면 데이터 게이트웨이가 디바이스에 연결하고 디바이스 데이터를 가져올 수 있습니다.

CDGs에 대한 장치 배포에 대해서도 많은 고민이 주어졌다. 이전 구축에서는 CDG 간에 디바이스를 임의로 배포했습니다. 이로 인해 일부 CDG는 더 많은 디바이스를 수용하는 반면 CDG는 1-2개로 매우 적은 디바이스를 보유하고 있기 때문에 매우 편중된 분포가 형성되었습니다. 이로 인해 일부 CDG가 과소비되고 과중한 부담이 되었으며 다른 CDG의 프로비저닝이 제대로 이루어지지 않았습니다.

업그레이드의 사고 프로세스는 4개의 활성 CDG에 각각 700개의 SWR을 배포하는 것이었습니다. 이는 2,100개의 SWR이 처음 3개의 CDG에 수용된 것을 설명했습니다.  인터페이스 전면에서 매우 무거운 LWR은 모두 네 번째 CDG를 위해 예약되었습니다. 30개의 카운트로 매우 적은 수였지만, 이러한 할당은 이러한 디바이스에서 더 많은 수집을 수행하더라도 CDG에 큰 부하가 발생하지 않도록 보장했습니다. 이후의 SWR 온보딩도 4^번째 CDG로 이동됩니다. 이로써 처음 세 개의 CDG에서 새 장치를 수용할 수 있는 공간이 더 많은 ^공간으로 균일하게 배포될 수 있었습니다.

SR-PCE는 2쌍으로 구축되었으며, 이는 4개의 VM이 서로 다른 호스트 시스템에 배포되었음을 의미합니다. 한 쌍이 7개의 POI 사이트를 관리하고, 나머지 8개의 POI 사이트를 관리한다. CNC GUI의 토폴로지 업데이트는 SR-PCE를 사용하여 수행됩니다. 다른 LWR 라우터와의 BGP-LS 피어링을 통해 네트워크의 토폴로지를 학습합니다. 이 구성 요소는 트래픽을 다른 경로로 전달하는 컨트롤러의 역할을 수행하는 모든 트래픽 엔지니어링 활용 사례에도 사용됩니다.

모든 서비스 프로비저닝 및 디바이스 컨피그레이션 활용 사례를 처리하려면 NSO를 CNC와 함께 사용해야 합니다. 프로덕션 네트워크의 경우 버전 6.4.1.1의 NSO 2개가 고가용성 모드에서 함께 작동하도록 구축되었습니다. SR-PCE(Segment Routing Path Computation Element)는 CNC에 토폴로지 업데이트를 제공하고 실시간 트래픽 엔지니어링 활용 사례를 처리하는 데 필요한 구성 요소입니다. 버전 25.2.1의 SR-PCE 4개가 여기에 구축되었으며 각 PCE는 서로 다른 LWR 2개로 피어링되었습니다.

CNC 4.1에서 CNC 7.1로의 마이그레이션 워크플로

CNC 구축에서는 docker 기반 구축으로 진행하는 것이 바람직했습니다. 그러나 클라이언트가 온프레미스에서 docker 설정을 승인하지 않았기 때문에 vCenter를 사용하여 수동 구축을 진행할 수 밖에 없었습니다. 이 경우 vCenter GUI에서 여러 번 입력을 제공해야 하므로 스크립트 기반 구축에 비해 구축 시간이 더 오래 걸립니다.

CNC 구축이 완료되면 필요한 모든 애플리케이션이 BU에서 제공하는 자동 작업 설치 파일과 함께 구축되었으며, 이 설치 파일은 애플리케이션을 한 번에 업로드하고 활성화하므로 수동으로 수행하는 데 걸리는 시간이 단축됩니다. Crosswork Optimization Engine, Active Topology, Service Health, Element Management Functions, Crosswork Workflow Manager를 포함하는 프리미어 계층이 구축되었습니다. 이와 함께 Change Automation 및 Health Insight가 포함된 애드온 패키지도 설정되었습니다.

CWM과 SH에는 사용 사례가 없습니다. 그러나 다음 버전에서는 이러한 애플리케이션에서 제공되는 일부 활용 사례에 관심이 있었기 때문에 구축되었습니다.

애플리케이션이 설정되면 다음 단계는 이전 버전의 CNC에서 데이터를 마이그레이션하는 것이었습니다. 이는 주로 자격 증명 프로파일, 공급자, 태그, 사용자 지정 플레이북, 사용자 지정 KPI, 역할, sZTP 바우처 및 기타 데이터로 구성됩니다. CNC는 이 모든 내보내기 옵션을 제공하며, 이 내보내기 옵션은 새 CNC에 사용 및 가져올 수 있습니다.

이러한 설정이 완료되면 디바이스 마이그레이션을 시작하는 것이 신중합니다. 업그레이드의 경우 새 CNC가 이전 서브넷에 비해 새 서브넷에 구축되어 있으면 새 CNC와 연결할 수 있도록 디바이스에서 ACL을 변경해야 합니다. 각 디바이스에 수동으로 로그인하고 컨피그레이션을 변경해야 하므로 시간이 많이 소요됩니다.

이러한 ACL 변경이 완료되면 다음 단계는 디바이스를 새 CNC로 가져와 CDG에 연결하는 것입니다. 연결 가능성이 적절하고 SSH 및 SNMP 자격 증명이 올바르면 디바이스가 CNC에서 연결 가능한 것으로 표시되며 NSO(Network Services Orchestrator)에 온보딩됩니다.

NSO 전면에서 CNC가 NSO와 통신하거나 그 반대로 통신할 수 있도록 필요한 모든 패키지가 제자리에 있고 가동되어야 합니다. 예를 들어 CNC에서 NSO로 디바이스를 자동으로 온보딩하려면 DLM 기능 팩이 필수입니다. 마찬가지로, NSO가 디바이스에서 MDT 센서 경로를 구성해야 하는 경우에는 TM-TC 패키지를 NSO에 구축해야 합니다. 활용 사례에 따라 해당 패키지를 NSO에 구축해야 한다는 게 골자다.

이러한 필수 패키지, 특히 Transport-SDN 패키지를 구축하기 위해 수동 방식을 취하는 대신 프로비저닝을 위한 자동화된 스크립트가 개발되었습니다. CNC 7.1 업그레이드로 TSDN 패키지에 업데이트가 도입되었습니다. 이러한 업데이트된 패키지는 업그레이드된 환경에서 L2/L3 프로비저닝을 지속적으로 지원하기 위해 NSO 서버에 구축하기 위한 것입니다. 이 스크립트는 업데이트된 TSDN 패키지의 설치를 자동화하고 필요한 메타데이터를 NSO에 로드하여 필요에 따라 서비스를 프로비저닝할 수 있도록 합니다.

Cisco SSM(Smart Software Manager) 라이센싱 서버 인스턴스 1개와 Cisco CPNR(Prime Network Registrar) 인스턴스 3개도 서로 다른 호스트에 구축됩니다.

CNC 아키텍처 및 다른 구성 요소와의 통합

CNC는 통합된 UI를 통해 구축된 서비스를 프로비저닝, 최적화 및 시각화할 수 있는 단일 플랫폼을 제공합니다. 다음은 CNC 플랫폼 제품군에 있는 CNC 내부 구성 요소와 사용 사례에 대한 간략한 요약입니다.

• CAT(Crosswork Active Topology):
• CNC VM 노드에 분산된 내부 구성 요소 애플리케이션
• 조정된 인벤토리에 대한 실시간 엔드 투 엔드 가시성 제공
• 여러 데이터 소스의 인벤토리 정보를 단일 디스플레이로 통합
• 전송 네트워크 경로 계산
• 토폴로지 검색

• COE(Crosswork Optimization Engine):
• CNC VM 노드에 분산된 내부 구성 요소 애플리케이션
• 실시간 네트워크 최적화
• 실시간 토폴로지 시각화
• SR-TE 시각화 및 프로비저닝
• RSVP-TE 시각화 및 프로비저닝
• 온디맨드 대역폭
• CHI(Crosswork Health Insight):
• CNC VM 노드에 분산된 내부 구성 요소 애플리케이션
• KPI 모니터링
• 경고 대시보드 
• CCA(Crosswork Change Automation):
• CNC VM 노드에 분산된 내부 구성 요소 애플리케이션
• 기본 플레이북이 포함된 Dev-ops 툴
• 원하는 시간에 플레이를 실행할 수 있도록 예약 기능
• HI KPIs 알림 스티칭을 개선으로 제안 플레이

아키텍처 다이어그램

네트워크 다이어그램

CNC 4.1 → 7.1 상세 마이그레이션 워크플로

레거시 CNC 4.1에서 CNC 7.1로의 엔드 투 엔드 단계별 마이그레이션(버전에 관계없이 모든 CNC 업그레이드에 대해 동일한 흐름을 따를 수 있음)

계획

›

실습

›

고객 랩

›

제품 준비

›

생산 개시

›

소크 기간

›

인계

›

해제

	1단계 1 계획 및 준비 범위 및 계획 · 범위 정의 •용량 계획 예약 · 창 식별 변경 · 이해관계자 조정
▼
	2단계 2 내부 랩 검증 인프라 · CNC 7.1 구축(하이브리드/작업자) · 앱 설치 · HA와 함께 NSO 구축 · SR-PCE 쌍 구축 검증 · 모든 활용 사례 검증 · 기능 승인
▼
	3단계 3 고객 랩 검증 인프라 구축 · CNC 7.1 구축(하이브리드/작업자) · 앱 설치 · HA와 함께 NSO 구축 · SR-PCE 쌍 구축 데이터 마이그레이션 · CNC 4.1 아티팩트 내보내기 · 장치 그룹 다시 만들기 · CNC 7.1로 가져오기 · NSO 패키지 구축 디바이스 연결성 · ACL 업데이트 · 장치 가져오기 및 CDG 첨부 파일 서비스 및 관찰 가능성 · 서비스 조정 및 동기화 · KPI 지원 및 수집 작업 · BNM 플레이북 스크립트 구현 · HI/Grafana 관찰 가능성 · Radius 통합 · Splunk 통합 · OneFM 통합 · CNC 백업 사용
	✓ Lab에서 ATP 수행 및 승인 받기
▼
	4단계 4 생산 준비도 보안 및 액세스 · 보안 검토 · 액세스 제어 설정 인프라 · 프로덕션 VM 크기 조정 및 설정 · 네트워크 검증
▼
	5단계 5 생산 컷오버 ↻ 운영 환경에서 3단계의 모든 단계를 반복합니다. 인프라 구축 · CNC 7.1 구축(하이브리드/작업자) · 앱 설치 · HA와 함께 NSO 구축 · SR-PCE 쌍 구축 데이터 마이그레이션 · CNC 4.1 객체 내보내기(제공자, 자격 증명 프로파일, 플레이북, 태그) · 장치 그룹 다시 만들기 · CNC 7.1로 가져오기 · NSO 패키지 구축 디바이스 연결성 · ACL 업데이트 · 장치 가져오기 및 CDG 첨부 파일 서비스 및 관찰 가능성 · 서비스 조정 및 동기화 · KPI 지원 및 수집 작업 · BNM 플레이북 지원 · HI/Grafana, Splunk, OneFM · CNC 백업 사용
	✓ 배포
▼
	6단계 6 소크 기간 모니터링 · 안정성 모니터링 · 성능 기준 이슈 관리 · 이슈 추적 및 해결 · 에스컬레이션 프로세스
▼
	7단계 7 문서화 및 인계 설명서 · MOP, 설계 문서 및 운영 문서 · 아키텍처 다이어그램 인계 · 지식 전수 세션 · 인계 승인
▼
	8단계 8 레거시 CNC 4.1 서비스 해제 CLEANUP · CDG에서 모든 장치 분리 · 4.1 CDG VM을 가리키는 MDT 항목 삭제 · 프로덕션 VM 삭제 ARCHIVE · 모든 CNC 4.1 내보내기 아카이빙 · 최종 감사 및 승인

활용 사례 

L2VPN(EVPN 기반) 서비스 프로비저닝

L2VPN 서비스는 여러 SWR에서 레이어 2 이더넷 연결을 제공하며 일부 서비스는 LWR에 고정됩니다. CNC Active Topology(CNC 활성 토폴로지)는 서비스 프로비저닝에 사용되는 반면, 모든 환경별 로직은 NSO 맞춤형 템플릿을 통해 구현됩니다.

L2VPN 프로비저닝은 Day2 컨피그레이션 작업으로 처리되며 운영자 제공 서비스 특성이 필요합니다.

사용자 지정 NSO 템플릿

환경별 명명 규칙 및 인터페이스 동작에 맞게 조정되도록 다음과 같은 여러 사용자 지정 템플릿이 작성되었습니다.

• CT-l2vpn-swr-hub-and-lwr
  SWR 허브 및 LWR에서 허브 측 명명 차이 f-or bridge -group 및 bridge -domain을 처리합니다.
• CT-l2vpn-swr-nonhub-100/101/102/105
  각 VLAN별 EVI에 대한 기본 EVPN 브리지 그룹 및 브리지 도메인에서 ZTP 업링크 인터페이스를 제거합니다.

이러한 템플릿은 네트워크 전체에서 일관된 EVPN 컨피그레이션을 보장하며 하드웨어 레벨의 차이를 추상화합니다.

L3VPN(VRF 기반) 서비스 프로비저닝

L3VPN 활용 사례는 엔드포인트로서 여러 SWR에서 레이어 3 서비스 제공을 활성화합니다. 프로비저닝은 CNC Active Topology(CNC 활성 토폴로지)를 통해 수행되며, 환경별 요구 사항은 사용자 지정 NSO 템플릿을 사용하여 구현됩니다.

L2VPN과 마찬가지로 Day-2 컨피그레이션 작업으로 운영자 입력이 필요합니다.

사용자 지정 NSO 템플릿

• CT-l3vpn-swr
  VRF 관련 매개변수(AS 번호, VRF 이름, 접두사 집합, 경로 정책 이름, 경로 구별자)를 수집하고, 사용자 정의 경로 정책으로 연결된 경로의 재배포를 포함하여 필요한 BGP 가져오기/내보내기 정책을 구축합니다.

교통 공학

CNC 제품군의 COE(Crosswork Optimization Engine) 애플리케이션은 원하는 의도에 따라 네트워크의 트래픽 흐름을 제어하는 데 도움이 됩니다.

서로 다른 의도(SLA 메트릭)를 필요로 하는 트래픽에는 두 가지 유형이 있습니다.

• TC1 트래픽 - 레이턴시에 민감한 SLA로 트래픽이 가장 짧은 레이턴시 경로에 있는지 확인합니다.
• TC4 트래픽 - 전용 대역폭을 항상 TC4 트래픽에 사용할 수 있도록 하는 최소 대역폭 SLA

TC1 트래픽(최저 레이턴시)

TC1 트래픽이 항상 가장 낮은 레이턴시 경로에서 전송되도록 하려면 경로 계산 기준을 레이턴시로 하여 헤드엔드 SWR에서 생성된 SR(Segment Routing) 정책이 있어야 합니다.

이는 CNC를 사용하여 SR 정책 생성을 용이하게 함으로써 특정 색상 1001에 대해 각 헤드엔드 SWR에서 ODN(On Demand Next Hop) 컨피그레이션을 정의하여 구현됩니다.

TC4 트래픽(커밋된 대역폭)

TC4 트래픽이 항상 전용 대역폭의 경로에서 전송되도록 하려면 경로 계산 기준을 대역폭으로 하여 헤드엔드 SWR에서 SR 정책을 생성해야 합니다.

이 작업은 다음을 통해 이루어집니다.

• CNC의 BoD(Bandwidth on Demand) 기능 팩
• CNC SR 정책 생성을 사용하여 특정 색상 1004에 대해 각 헤드엔드 SWR에서 ODN(On Demand Next Hop) 컨피그레이션 정의

BoD 함수 팩은 대역폭을 경로 계산 기준으로 사용하는 SR 정책의 경로를 계산하는 데 사용됩니다. 정책에 커밋된 대역폭을 추적하고 라이프사이클 동안 정책의 현재 경로를 모니터링합니다. 

어떤 시점에서든 BWOD 정책의 현재 패치가 커밋된 대역폭을 충족하기에 충분한 용량을 제공하지 못하면 BWOD 정책 경로를 다시 계산하고 정책을 새 경로로 다시 라우팅합니다. 이 BWOD 정책 재라우팅은 지속적인 프로세스이며 수동 개입이 필요하지 않습니다.

어떤 면에서 BWOD는 지연 시간에 대해 SR-PCE와 같은 방식으로 대역폭을 위해 즉시 최적화합니다.

sZTP를 사용한 장치 켜기

이전의 기존 설치 및 지원 모델에서는 새 장치를 가져오는 과정에서 설치 관리자가 특정 수준의 전문성을 바탕으로 새 구성 요소를 설치, 구성, 구현의 문제를 해결해야 했습니다. 또한 솔루션 내 여러 부분에서 작업하는 많은 직원들의 지원을 받아 오프사이트 위치에서 장비를 사전 스테이징하는 긴 프로세스가 있을 수 있습니다.

사용자 환경에 구축될 예정인 새 SWR 디바이스의 경우, CNC의 보안 ZTP(Zero Touch Provisioning) 애플리케이션을 사용하여 디바이스 가동 프로세스가 자동화됩니다.

ZTP 워크플로는 최초 디바이스 부팅 시 트리거되며 수동 작업 없이 적용해야 하는 계획된 플랫폼 이미지 및 초기 컨피그레이션을 다운로드합니다.

또한 추가 오케스트레이션을 위해 CNC에서 디바이스가 자동 온보딩됩니다.

이 다이어그램은 디바이스 설정 시 보안 ZTP 프로세스의 워크플로를 보여줍니다.

포스트 ZTP 오케스트레이션(자동화 기반)

유틸리티 호스트의 Python 자동화는 구조화된 Excel 입력(체인별)을 사용하여 엔드 투 엔드 프로세스를 오케스트레이션하고 감사합니다.

• Day-1 및 사후 컨피그레이션 아티팩트를 생성하여 CNC에 업로드합니다.
• CPNR 예약(SWR 직렬에 바인딩된 DHCP 항목)을 생성합니다.
• EPNM에 디바이스를 추가합니다(가시성/보증용).
• CNC에서 ZTP 후 관리:
• CDG(텔레메트리 대상)에 SWR 할당
• 장치 그룹 및 태그에 연결
• 토폴로지 시각화를 위한 위도/경도 업데이트
• 텔레메트리 스트리밍을 활성화하기 위해 BNM KPI 프로파일 연결

CNC에서 BNM(Bandwidth Notification Message) 처리

SWR은 WAN 포트의 대역폭에 해당하는 co-located MiniLink 스위치에서 BNM을 수신할 수 있습니다. 이러한 알림 메시지는 현재 실행 중인 RBW(recorded bandwidth) 및 NBW(nominal bandwidth)라고도 하는 최대 구성 대역폭을 포함하는 표준 기반 CFM 메시지입니다.

현재 대역폭은 개별 마이크로파 링크의 집성 대역폭과 실행 중인 QAM 레벨을 기반으로 하는 마이크로파 WAN 링크의 실제 실행 대역폭입니다. 공칭 대역폭은 개별 마이크로파 링크 각각에서 최대 구성 QAM의 집성 대역폭을 기반으로 구성된 최대 가능 WAN 대역폭입니다.

대역폭 최적화는 다음 시나리오를 기반으로 수행됩니다.

임시(임시 이벤트) 변경

• SWR로 현지화된 네트워크/링크에서 일시적인 성능 저하 또는 가동 중단이 발생하는 경우(예: 악천후(Adverse Weather), 이로 인해 마이크로파 무선 경로 페이딩 및 변조 방식의 변경으로 인한 가용 대역폭 감소), 트래픽 셰이핑 수정은 영향을 받는 네트워크 인터페이스의 로컬 SWR에서 발생합니다.
• 이렇게 하면 영향을 받는 전송 경로를 통해 최소 패킷 손실이 발생합니다.

SWR이 CNC에서 BNM KPI를 사용하여 post-sZTP 활동의 일부로 활성화되면 CNC는 텔레메트리 구성을 SWR로 푸시합니다.

BNM MDT

원격 측정 모델 중심

 대상 그룹 <DGName>

  vrf VRF-OMSWR-<AreaCode>1

  주소군 ipv4 <CDG IPv4Address> 포트 9010

   인코딩 self-describing-gpb

   프로토콜 tcp

  !

 !

 센서 그룹 <그룹 이름>

  sensor-path Cisco-IOS-XR-ethernet-cfm-oper:cfm/nodes/node/bandwidth-notifications/bandwidth-notification

 !

CNC는 텔레메트리를 통해 수신된 이러한 BNM 메시지를 처리하고 필요한 경우 교정 작업을 수행합니다. CNC와 관련된 2가지 구성 요소는 다음과 같습니다. 

• HI(Health Insight): CNC 애플리케이션은 BNM 메시지의 특정 센서 경로를 모니터링하는 맞춤형 KPI를 통해 BNM 알림을 수집하는 데 사용됩니다. Health Insight는 대역폭 변경이 중대한 경우 알림을 제공할 수 있습니다.
• 변경 자동화(CA): CNC 애플리케이션은 HI 알림을 발생시킨 BNM 메시지 스트리밍에 사용됩니다. 2개의 맞춤형 플레이북이 구축되어 영향을 받는 인터페이스에 다음 변경 사항을 적용합니다.
  • QoS 쉐이퍼를 새 RBW로 설정
  • 인터페이스 용량을 새 RBW 값으로 설정합니다.

맞춤형 Python 스크립트는 HI KPI 위반 시 맞춤형 로직을 수행하고 CA 플레이북을 자동으로 실행하도록 개발되었습니다. 

플레이북 트리거링 스크립트는 다음 알고리즘을 기반으로 작동합니다.

이 표에서는 대역폭 저하 정도에 따라 설정된 사용자 지정 경고 레벨에 대해 설명합니다. 

보고된 대역폭 = RBW 

공칭 대역폭 = NBW 

알림 간격 값	알림 수준
(RBW/NBW)*100 >=70	정보
(RBW/NBW)*100 <70, >60	경고
(RBW/NBW)*100 <=60	Critical(심각)

이 센서 경로는 CNC에 의해 모니터링됩니다. 

Cisco-IOS-XR-ethernet-cfm-oper:cfm/nodes/node/bandwidth-notifications/bandwidth-notification

BNM 센서 경로를 모니터링하기 위해 CNC에서 맞춤형 KPI가 생성됩니다. 이 KPI는 120초 범위 및 경고 임계값으로 구성된 KPI 프로필에 추가됩니다. 이 프로파일에 SWR을 연결하면 NSO를 통해 필요한 텔레메트리 컨피그레이션이 디바이스에 자동으로 푸시됩니다.

활성화된 장치는 구성된 간격으로 할당된 CDG로 RBW/NBW 데이터를 스트리밍합니다. HI(Health Insight)는 RBW÷NBW 비율을 계산하고 임계값을 넘으면 경고를 발생시킵니다. 운영자는 HI 및 Grafana 대시보드를 통해 이러한 이벤트를 모니터링할 수 있습니다.

CNC의 알림 제공자는 이러한 알림을 Python 자동화를 호스팅하는 하이브리드 노드로 전달합니다. 이 스크립트는 디바이스/인터페이스/RBW/NBW 세부사항을 분석하고 적절한 변경 자동화 플레이북을 트리거합니다. 정의된 결정 논리를 기반으로 쉐이퍼 조정, 대역폭 업데이트 또는 둘 다를 수행합니다.

워크플로에 사용되는 2가지 플레이북입니다.

1. 쉐이퍼 값을 변경하는 플레이북  

2. 인터페이스 대역폭을 변경하는 플레이북

이미 언급한 것처럼 스크립트는 웹 서버를 스핀업하여 REST API를 사용하여 CNC와 통신하는 공급자 역할을 합니다. POST 요청에 대한 모든 응답은 여기에서 캡처됩니다. 알림은 JSON 형식으로 캡처한 다음 사전으로 변환되어 필요한 매개변수를 제거합니다. 

맞춤형 자동화 플레이북을 통해 2일 네트워크 운영 표준화

CA(Custom Change Automation) 플레이북은 네트워크 라이프사이클 전반에서 중요한 Day-2 운영을 간소화하고 표준화하기 위해 개발되었습니다. 여기에는 번들 이더넷 프로비저닝, 관리 인터페이스 설명 업데이트, CFM 데이지 체인 오케스트레이션, 원활한 링크 용량 확장, eNodeB 서비스 해제, 효율적인 미니 링크 온보딩이 포함됩니다. 이러한 플레이북은 재사용 가능한 워크플로에 운영 모범 사례를 포함시킴으로써 실행 일관성을 크게 높이고, 작업자 오류의 위험을 최소화하며, 수동 개입에 대한 의존도를 낮춥니다. Cisco CNC 업그레이드의 맥락에서 이 자동화 프레임워크는 운영 전환을 가속화하고, 서비스 연속성을 보장하며, 최신 네트워크 변환 목표에 맞추어 확장 가능하고 반복 가능한 프로세스를 구현하는 데 중추적인 역할을 합니다.

Cisco CNC 7.1 업그레이드의 TACACS+ 통합 연속성

Cisco CNC 4.1에서 7.1로 업그레이드하는 과정에서 기존 TACACS+ 통합은 중앙 집중식 인증, 권한 부여의 연속성을 보장하기 위해 신중하게 보존되었습니다. 업그레이드 프로세스는 Cisco CNC 7.1에서 TACACS+ 컨피그레이션을 검증 및 복제하여, 수립된 엔터프라이즈 보안 정책 및 RBAC(Role-Based Access Control) 메커니즘과 조화를 유지합니다.

CNC 및 CDG Syslog를 Splunk로 전달

syslog 전달은 경보/이벤트/syslog를 Splunk 서버로 전달하도록 설정됩니다. 이를 위해 CNC에서 syslog 서버를 설정하는 기본 기능을 사용했습니다.

OneFM으로 경보 전달

또한 CNC 경보는 CNC restconf 연결 지향 API를 사용하는 OneFM과 같은 노스바운드 시스템에도 전달됩니다.

curl -L --request GET \

--url https://{server_ip}:30603/crosswork/notification/restconf/streams/v2/alarm.json \

--header 'Accept: application/txt'). This API must be used over a websocket connection config.

일일 CNC 백업 자동화

자동화된 스크립트는 CNC 백업 API를 사용하여 CNC의 전체 백업을 가져오고 유틸리티 호스트에 백업 파일을 저장합니다. 이 작업은 매일 수행됩니다.

과제

Crosswork 버전의 Big Jump

Cross work 4.4에서 7.1로의 업그레이드는 일상적인 증분 업데이트보다는 버전 급증을 의미했습니다. 이와 같이 큰 폭으로 인해 여러 애플리케이션에서 수많은 새로운 기능이 도입되었으며 상당한 개선 및 아키텍처 변화가 수반되었습니다. 이 때문에 CNC 업그레이드는 단순한 버전 교체가 아니라 모든 통합 구성 요소의 호환성, 안정성 및 적절한 기능을 보장하기 위한 철저한 검증이 필요했습니다. 확장된 기능 세트와 근본적인 개선 덕분에 기존 워크플로, 컨피그레이션 및 통합에서 신중한 확인이 필요했으며, 이를 통해 포괄적인 테스트와 검증을 성공적으로 수행하는 것이 매우 중요해졌습니다.

업그레이드 불필요

CNC는 내부 업그레이드 모델을 지원하지 않습니다. 대신 업그레이드는 리프트 앤 시프트 방식을 따라야 합니다. 즉, 대상 버전을 사용하여 완전히 새로운 환경을 처음부터 구축하는 동시에 기존 구축은 보존해야 합니다. 새 시스템을 설치한 후에는 컨피그레이션, 데이터 및 통합을 신중하게 마이그레이션하고 검증해야 이전 환경을 폐기할 수 있습니다.

이러한 접근 방식에는 다음과 같은 몇 가지 운영 과제가 있습니다.

• 병렬 환경: 이전 CNC 환경과 새 CNC 환경은 모두 마이그레이션 및 검증이 완전히 완료될 때까지 동시에 실행해야 합니다.
• 하드웨어 리소스 압력: 두 개의 전체 환경을 동시에 실행하면 컴퓨팅, 스토리지 및 네트워크 리소스에 대한 수요가 크게 증가하므로 가용 인프라에 무리가 갈 수 있습니다.
• 확장된 검증 작업: 마이그레이션된 모든 데이터, 컨피그레이션, 정책 및 통합은 새 버전에서 확인되어야 제대로 작동합니다.
• 데이터 마이그레이션의 복잡성: 기록 데이터, 애플리케이션 구성 및 운영 설정을 전송하려면 일관성 또는 데이터 손실을 방지하기 위한 신중한 계획이 필요합니다.
• 서비스 해제 지연: 이전 시스템과 해당 VM은 새 구축이 안정적임을 입증할 때까지 삭제할 수 없으므로 리소스 사용과 운영 오버헤드가 연장됩니다.
• 운영 조정: 팀은 구성 변경이나 운영 중단을 방지하기 위해 전환 기간 동안 두 환경 간의 동기화를 관리해야 합니다.
• 닫힌 루프 자동화 충돌: CNC는 실시간 네트워크 조건에 따라 작업을 동적으로 트리거하는 폐쇄 루프 자동화 활용 사례를 지원합니다. 전환 중에 이전 컨트롤러와 새 컨트롤러가 모두 활성 상태일 경우 두 컨트롤러에서 동일한 자동화 논리를 실행할 수 있으므로, 컨피그레이션 변경이 중복되거나 네트워크에서 작업이 충돌할 수 있습니다. 이를 위해서는 마이그레이션 기간 동안 자동화 정책을 신중하게 제어해야 합니다.
• 기록 경보, 이벤트, 결함 레코드, 감사 정보 등의 기존 운영 데이터는 네이티브 내보내기 기능이 없으므로 새 환경으로 마이그레이션되지 않습니다. 따라서 이 기록 데이터는 업그레이드된 시스템에서 사용할 수 없으며 마이그레이션 후에는 복구 불가로 취급해야 합니다.

이러한 요인으로 인해 CNC 업그레이드는 리프트 앤 시프트 모델로 인해 표준 현장 업그레이드에 비해 리소스 집약적이고 운영이 복잡합니다.

롤백 옵션이 없는 구축 문제

CNC의 특정 구축 및 구축 후 컨피그레이션 오류는 교정 경로가 없으며 완전한 클러스터 해체 및 재구축이 필요합니다. 예를 들어, Crosswork 데이터 VIP에 대해 구성된 잘못된 FQDN, sZTP 활용 사례에 대해 필수, sZTP 비기능 렌더링된 FQDN입니다. 이 값은 구축 후 수정할 수 없으므로 전체 재구축이 필요합니다.

마찬가지로, 구축 후 변경 자동화에서 디바이스 재정의 자격 증명의 잘못된 컨피그레이션을 수정할 수 없으므로 다른 클러스터가 재구축됩니다. 잘못 구성된 게이트웨이 IP 또는 서브넷 정의와 같은 기타 오류도 복구 불가능한 것으로 식별됩니다.

이러한 시나리오에서는 초기 구축 과정에서 불변의 모든 매개변수를 검증하는 것이 매우 중요하다는 점을 강조합니다. 비용이 많이 드는 재작업과 일정에 영향을 주지 않으려면 세심한 계획과 입력 검증이 필수적입니다.

구축 후 진단 검증의 제약 조건

CNC는 디스크 읽기/쓰기 대기 시간, IOPS, 동기화 대기 시간, 네트워크 인터페이스 속도, CPU 클록 주파수 등의 VM 레벨 상태 매개변수를 평가하는 진단 유틸리티를 제공합니다. 이 유틸리티는 예상 임계값에 대한 측정 값을 보고하고 각 검사를 통과 또는 실패로 표시합니다. 그러나 이러한 진단은 클러스터를 배포한 후에만 실행할 수 있으며, 배포 전에 인프라 준비 상태를 확인하는 메커니즘은 남겨 두지 않습니다.

설치 중에 "진단 검사 무시" 플래그는 기본적으로 false로 설정됩니다. 실제로 단일 점검이 실패하면 설치 프로그램이 중단되어 구축이 진행되지 않습니다. 그 결과, 생산 등급 환경에서도 하나 이상의 검사에 실패하는 경우가 많으므로 현장 엔지니어는 이 플래그를 구현하고 진단을 완전히 우회해야 하는 경우가 많습니다. 따라서 운영상의 딜레마가 발생합니다. 팀은 기본 인프라가 권장 성능 벤치마크를 충족하는지 확인하지 않고 배포를 차단하는 엄격한 검증을 적용하거나 계속 진행하는 것 중에서 선택해야 합니다.

HI 맞춤형 KPI 생성 절차 변경

Health Insight 4.1에서 사용자 지정 KPI 생성은 Tick 스크립트 논리에 의존했습니다. 여기서 KPI 정의 및 처리 논리는 Tick 프레임워크 내의 스크립트를 사용하여 구현되었습니다. 그러나 버전 7.1에서는 이러한 접근 방식이 KPI를 정의하고 관리하기 위한 추적기 파일 기반 프레임워크로 대체되었습니다.

이러한 아키텍처 변경으로 인해 기존 사용자 지정 KPI를 직접 재사용할 수 없으며 새 추적기 파일 형식에 맞게 재작업해야 했습니다. 이를 위해서는 상당한 시간과 노력이 필요했습니다.

• 새로운 프레임워크 이해: 연구팀은 7.1에 도입된 추적기 파일 기반 KPI 정의 모델의 구조, 구문, 운영 행동을 연구해야 했다.
• 기존 논리 재설계: 이전에 Tick 스크립트에서 구현된 논리를 추적기 파일 형식으로 변환하고 수정해야 했습니다.
• BNM KPI 다시 만들기: 맞춤형 BNM KPI는 새로운 프레임워크를 사용하여 재생성해야 이전과 동일한 결과와 통찰력을 얻을 수 있었습니다.
• KPI 정확성 검증: 새로운 구현이 이전 버전에 비해 일관되고 올바른 메트릭을 생성했는지 확인하기 위해서는 광범위한 검증이 필요했습니다.
• 테스트 및 조정: 또한 새로운 모델은 실제 네트워크 조건에서 성능 및 동작을 테스트한 다음 필요한 경우 조정해야 했습니다.
• 지원 부족: 이전에 tick 스크립트로 작동했던 일부 기능은 새 추적기 파일 구현에서 더 이상 지원되지 않았습니다. 그래서, 어떤 타협들이 만들어져야 했습니다.

이러한 KPI 생성 메커니즘의 변화는 운영 통찰력의 연속성을 보장하기 위해 새로운 시스템을 학습하고 기존 맞춤형 모니터링 논리를 재구현하는 것과 관련이 있기 때문에 업그레이드 과정에서 요구되는 노력을 크게 증가시켰습니다.

BNM 플레이북의 API 시간 초과 트리거 스크립트

BNM 플레이북은 CNC API와 상호 작용하는 사용자 지정 스크립트를 통해 트리거됩니다. 업그레이드 및 검증 과정에서 API 인증 및 응답 처리와 관련된 몇 가지 문제를 파악하고 해결했습니다.

CNC API 토큰의 유효 기간은 8시간이지만, 원래 스크립트에는 만료된 토큰을 새로 고치는 적절한 로직이 포함되어 있지 않았습니다. 그 결과 CNC 4.4의 KPI 알림이 올바르게 작동했지만 토큰이 만료된 후 플레이북 트리거 스크립트 실행이 중지되었습니다. 이 문제는 오랫동안 주목을 받지 못했는데, 이는 자동화 스크립트가 1년 이상 안정적으로 실행되지 않았다는 것을 의미합니다. 이 문제는 CNC 7.1의 마이그레이션 및 검증 작업 중에만 표시됩니다.

따라서 몇 가지 개선 및 개선이 요구되었습니다.

• 토큰 새로 고침 로직: 토큰 만료를 탐지하고 API 토큰을 자동으로 새로 고치도록 적절한 논리를 구현하여 중단 없는 스크립트 실행을 보장합니다.
• API 응답 변경: CNC 버전 간의 차이로 인해 추가 문제가 발생했습니다. CNC 4.1에서는 만료된 토큰 응답에 일반적으로 "expired" 메시지가 포함된 반면, CNC 7.1에서는 "Key not authorized"가 반환됩니다. 7.1의 새로운 응답 패턴을 올바르게 해석하려면 스크립트 논리를 업데이트해야 했습니다.
• 글로벌 토큰 처리: 기존에는 토큰이 기능 내에서 로컬로 저장돼 사용됐다. 이는 함수를 입력할 때 토큰이 유효하지만 후속 API 호출 전에 만료된 시나리오를 만들었습니다. 글로벌 토큰 처리를 사용하도록 구현이 수정되어 모든 기능에 일관성과 적절한 새로 고침이 보장되었습니다.
• 향상된 오류 처리: 경우에 따라 NSO "check sync" API가 불완전하거나 예상 구조와 다른 응답을 반환했습니다. 이로 인해 KeyError 예외가 발생하여 스크립트 실행이 일시 중단되었습니다. 예기치 않은 API 응답이 수신되더라도 스크립트가 계속 실행될 수 있도록 추가 예외 처리 및 검증 논리가 도입되었습니다.
• 스크립트 안정성 향상: API 실패, 임시 응답 문제 또는 토큰 새로 고침 이벤트로 인해 스크립트가 예기치 않게 종료되지 않도록 하기 위해 추가 보호 조치 및 검사가 추가되었습니다.

이러한 개선은 업그레이드 과정에서 드러나지 않은 문제를 해결했을 뿐만 아니라 BNM 플레이북 자동화 프레임워크의 신뢰성, 탄력성 및 유지보수성을 크게 향상시켰습니다.

BNM 프로세싱 및 플레이북 트리거 디자인 변경

BNM 자동화 로직은 이벤트 기반이며 CNC 내의 Health Insight 애플리케이션에서 KPI에 의해 생성된 경고에 의존합니다. 전체 워크플로는 다음과 같이 작동합니다.

1. CNC는 디바이스에서 NB(Nominal Bandwidth) 및 RBW(Real Bandwidth) 값을 읽습니다.
2. 이 값을 사용하여 대역폭 비율(BW%)을 계산합니다.
3. Health Insight KPI는 미리 정의된 경고 임계값을 기준으로 이 비율을 평가합니다.
4. 경보가 생성되면, BNM 플레이북 트리거링 스크립트는 경보를 감지하고 대응하는 교정 플레이북을 실행한다

원래 경고 설계의 제한 사항

구성된 경고 임계값은 다음과 같습니다.

• BW% < 60 → 중요
• 60 ≤ BW% ≤ 70 → 경고
• BW% > 90 → 정보

이 설계는 대역폭 저하를 확인하는 데 효과적이었지만 대역폭 복구 시나리오에서 기능적 격차를 유발했습니다. 특히 70-90% 범위에서는 경고 수준이 정의되지 않았습니다.

이로 인해 다음과 같은 동작이 발생했습니다.

• BW%가 70% 미만으로 떨어지면 Critical 또는 Warning 경고가 생성되어 쉐이퍼 및 대역폭 값을 조정하는 플레이북이 트리거됩니다.
• 그러나 대역폭이 복구되고 BW%가 70% 이상 증가하면 해당 값이 관련 경고 수준이 없는 70-90% 대역에 해당되므로 KPI에서 경고가 생성되지 않았습니다.
• BNM 자동화 스크립트는 작업을 트리거하기 위해 경고 생성에 전적으로 의존하기 때문에 업데이트된 NBW/RBW 값을 읽거나 복원 작업을 시작할 기회가 없었습니다.
• 그 결과 충분한 대역폭을 사용할 수 있게 되었음에도 불구하고 대역폭 복원이 자동으로 수행되지 않았습니다. 원안에도 복원 논리가 없었다.

이러한 제한은 이전에 대역폭 감소를 겪었던 링크가 조건이 개선된 후에도 제한된 상태로 유지되는 생산 네트워크에서 가시화되었다.

KPI 프레임워크 변경의 영향

CNC 7.1에서 도입된 프레임워크 변경으로 문제가 더욱 악화되었습니다. Health Insight 4.1에서는 Tick 기반 KPI 구현이 최대 5개의 경고 레벨을 지원하여 임계값 범위를 더 세밀하게 제어하고 복원 논리를 더 쉽게 구현할 수 있게 되었습니다.

그러나 CNC 7.1에서는 추적기 파일 기반 KPI 프레임워크가 세 가지 경고 레벨만 지원하므로 여러 복구 임계값을 정의할 때 유연성이 떨어지며 이러한 제약 조건에 맞게 경고 로직을 재설계해야 합니다.

과도한 플레이북 트리거

원래 구현에서 확인된 또 다른 문제는 플레이북 실행 빈도가 매우 높다는 것이었다. 자동화 로직에 보류 시간 또는 안정화 기간이 포함되지 않았습니다. CNC가 경고 조건을 충족한 디바이스에서 값을 읽는 즉시

• 경보가 즉각 발효되었다.
• 자동화 스크립트는 즉시 수정 플레이북을 트리거했습니다.

실시간 네트워크에서 텔레메트리 값이 자주 변동되므로 네트워크 안정성과 애플리케이션 성능 측면에서 모두 이상적이지 않은 수백 개의 플레이북이 매시간 트리거됩니다.

재설계된 자동화 로직

이러한 제한을 해결하기 위해 BNM 자동화 설계는 몇 가지 개선 사항과 함께 재작업되었습니다.

• 수정된 경고 임계값 로직: 복구 대역이 세 가지 알림 레벨 내에서 캡처되도록 로직을 수정하여 70%보다 큰 BW%는 이제 INFO 레벨 알림으로 처리되도록 함으로써 90%를 초과하는 값만 INFO로 분류된 이전 방식을 대체했습니다. 이를 통해 70-90% 복구 대역이 능동적으로 모니터링되므로 대역폭 조건이 개선될 때 복구 플레이북이 트리거될 수 있습니다.
• 보류 시간 소개: 플레이북을 트리거하기 전에 대역폭 조건이 정의된 기간 동안 안정적으로 유지되도록 하기 위해 20분의 보류 시간 메커니즘이 도입되었습니다. 따라서 자동화가 단기적인 변동에 대응하는 것이 방지됩니다.
• 통제된 플레이북 실행: 수정된 논리와 대기 시간으로 플레이북 실행 빈도가 대폭 감소해 불필요한 자동화 작업을 막았다.
• 심각한 성능 저하를 방지하는 부스터 메커니즘: 심각한 대역폭 저하의 경우 부스터(booster) 방식이 도입되었습니다. 이러한 시나리오에서 자동화는 트래픽 셰이퍼 및 대역폭 할당을 NBW의 40%로 사전 대응적으로 조정하므로 혼잡에서 더 빨리 복구할 수 있습니다.
• 자동화 안정성 향상: 다시 설계된 워크플로를 통해 추적기 기반 KPI 프레임워크의 제한 내에서도 대역폭 감소 및 대역폭 복원 시나리오를 모두 효과적으로 처리할 수 있습니다.

결과

이러한 설계 변경과 더불어 API 처리, 토큰 관리 및 스크립트 견고성의 초기 개선으로 BNM 자동화 프레임워크는 훨씬 안정적이고 효율적이며 예측 가능한 방식으로 운영됩니다. 시스템은 혼잡과 복구 조건에 모두 올바르게 대응할 수 있으며, 과도한 플레이북 실행을 방지하고 안정적인 네트워크 대역폭 최적화를 보장할 수 있습니다.

디바이스 알람 억제

CNC 4.1에서 경보는 RESTCONF API를 통해 OneFM이라는 노스바운드 시스템으로 전달되었습니다. CNC 4.1 스택에 EMF 기능이 포함되지 않았기 때문에 플랫폼은 시스템 레벨 경보만 생성했습니다. 이러한 경보는 경보 분류와 관련된 복잡성 없이 업스트림으로 전달되었습니다.

CNC 7.1의 구축으로 EMF 애플리케이션이 도입되어 경보 모델이 크게 확대되었다. 경보는 이제 세 가지 유형으로 분류됩니다.

• 시스템 경보 - CNC 플랫폼 및 애플리케이션 상태 관련
• 네트워크 경보 - 네트워크 서비스 조건과 관련
• 디바이스 경보 - 네트워크 디바이스에서 직접 생성되고 CNC를 통해 전달됨

그러나 이미 장치 수준 알람을 수집하고 관리하는 EPNM이 있었습니다. CNC가 이러한 알람을 OneFM에도 전달하면 두 시스템에서 중복 알람을 수신하게 됩니다. 따라서 시스템 및 네트워크 경보를 전달하는 동안 CNC에서 디바이스 경보를 제외해야 했습니다.

기본 과제는 OneFM에 경보를 전달하는 데 사용되는 RESTCONF 노스바운드 API의 제한이었습니다. API에서 경보 범주를 기반으로 하는 경보 필터링을 지원하지 않았습니다. 이러한 필터링을 사용할 수 있었다면 다음과 같은 간단한 방법으로 해결할 수 있었을 것입니다. 장치 경보를 노스바운드 시스템으로 전달하기 전에 API 레벨에서 제외하기만 하면 됩니다.

몇 가지 잠재적 솔루션을 평가하고 논의했습니다.

• 소스에서 디바이스 트랩을 중지하는 중: 디바이스가 CNC에 트랩을 전송하지 못하게 합니다.
• 노스바운드 시스템(OneFM)에서 경보 필터링: CNC에서 모든 경보를 전송하되 OneFM 내에서 디바이스 경보를 필터링하도록 허용합니다.
• 경보를 전달하기 전에 CNC 내에서 필터링.

CNC는 디바이스 이벤트를 탐지하고 네트워크 상태에 대한 운영 인식을 유지하기 위해 이러한 트랩을 사용하기 때문에 디바이스 레벨에서 트랩을 중지하는 것은 실행 가능한 것으로 간주되지 않았습니다. 트랩을 비활성화하면 CNC가 네트워크 문제에 대응하는 능력이 크게 저하됩니다.

이 솔루션은 궁극적으로 Device Alarm Suppression이라는 내장형 CNC 기능을 활용했습니다. 이 기능을 사용하면 관리자가 디바이스 그룹을 기준으로 특정 유형의 디바이스 알람을 억제하여 더 이상 업스트림에서 처리 또는 전달되지 않도록 할 수 있습니다.

디바이스 알람 억제 정책을 구성함으로써 시스템은 다음을 수행할 수 있었습니다.

• CNC 내에서 디바이스에서 생성한 경보를 억제합니다.
• 시스템 및 네트워크 알람을 계속 처리하고 전달합니다.
• 중복 장치 경보가 OneFM 시스템에 도달하지 않도록 합니다.

이 접근 방식은 디바이스에서 트랩을 수신하는 CNC의 기능에 지장을 주지 않고 깨끗하고 확장 가능한 솔루션을 제공했습니다. 그 결과 OneFM으로의 경보 흐름이 간소화되어 관련 시스템 및 네트워크 경보만 전달되었으며 EPNM의 장치 경보 관리와의 중복을 방지했습니다.

대역 외 변경

기존 설정에서는 운영 팀이 직접 CLI 기반 스크립트를 사용하여 네트워크 디바이스에 컨피그레이션 업데이트를 푸시하는 경우가 많았으며, 특히 ACL 수정 및 디버깅 작업과 같은 작업에 사용되었습니다. 이러한 접근 방식은 단기적으로는 효과적이지만 시스템 내에서 NSO 외부의 변경 사항이 추적되지 않아 구성 표류가 발생했습니다. 그 결과, 의도한(모델링된) 상태와 실제 디바이스 컨피그레이션 간의 불일치로 인해 NSO의 프로비저닝 워크플로가 영향을 받아 장애 및 운영상의 비효율성이 초래되었습니다.

L2/L3 VPN 조정

OOB(Out of Band) 컨피그레이션 변경으로 인해 네트워킹 팀은 CNC/NSO 및 TSDN 워크플로를 벗어난 디바이스에서 VPN 관련 컨피그레이션을 업데이트했습니다. 그 결과 NSO에 저장된 상태(CNC 4.1 시대)가 항상 디바이스의 상태와 일치하는 것은 아닙니다.

이러한 불일치로 인해 여러 조정 실패와 불일치가 발생했습니다. 몇몇 경우, NSO에는 디바이스에 더 이상 존재하지 않는(또는 NSO가 반영하지 않는 방식으로 수정된) VPN 서비스 데이터가 포함되었습니다. NSO를 네트워크에 맞추려면 NSO에만 있고 디바이스에는 없는 VPN 서비스 항목을 제거하고 대역 외 변경으로 인한 다른 불일치를 수정해야 했습니다.

영향 예약

이러한 문제를 해결하려면 원래 조정 계획보다 약 2주가 더 추가로 필요합니다. 불일치를 식별하고, 디바이스 상태를 검증하고, NSO CDB 데이터를 안전하게 정리하거나 수정하는 데 추가 시간이 소요되었습니다.

관찰

1. 구성 기관: VPN(또는 TSDN 관리) 컨피그레이션에 대한 대역 외 변경 사항으로 인해 NSO와 네트워크 간에 드리프트가 발생하고 조정이 복잡해집니다.
2. 마이그레이션 전 기준: 마이그레이션 전에 NC/NSO 매니지드 대 디바이스 전용 상태의 명확한 베이스라인으로 불일치를 더 쉽게 탐지하고 해결할 수 있었습니다.
3. 자동화 및 변환: 4.1과 7.1 사이의 형식과 모델 차이를 일관되게 처리하기 위해서는 페이로드 변환 스크립트와 사용자별 사용자 지정이 필수적이었습니다.

유사한 업그레이드에 대한 권장 사항

1. 조정 창에서 VPN(및 기타 TSDN 관리) 서비스에 대한 변경 중단을 시행합니다. 단, 제어된 프로세스를 통해서만 수행할 수 있습니다.
2. 조정을 시작하기 전에 NSO CDB와 디바이스 컨피그레이션을 비교하여 불일치를 정량화하고 나열하는 사전 검증 감사를 실행합니다.
3. VPN 변경 사항이 CNC/NSO TSDN 사후 업그레이드를 거쳐야 대역 외 편류가 재발하지 않는다는 점을 문서화하고 이를 널리 알리십시오.
4. 변환 및 조정 스크립트를 보존하여 향후 업그레이드 또는 문제 해결에 다시 사용할 수 있습니다.

유지 관리 모드 종속성에 따른 CNC 백업 실패

CNC 백업 메커니즘에서는 백업 작업을 시작하기 전에 플랫폼을 유지 보수 모드로 전환하도록 요구합니다. 백업 API는 기본적으로 이 전제 조건을 적용합니다. CNC가 유지 보수 모드로 전환되지 않으면 백업 프로세스가 자동으로 중단됩니다.

실제로 다음과 같은 지속적인 시스템 활동으로 인해 유지 보수 모드로 들어가는 데 실패하는 경우가 많습니다.

• 활성 MOP(Change Automation) 실행
• 지속적인 sZTP 워크플로
• DLM 서비스 작업
• KPI 프로필 연결 또는 분리 활동
• 온디맨드 쇼테크 컬렉션
• 백그라운드 오케스트레이션 작업

이러한 작업이 있으면 CNC가 유지 관리 모드로 들어가지 못하므로 백업 작업이 실행되기 전에 실패합니다.

운영 영향

규정 준수 및 운영 보증을 위해 매일 필요한 CNC 백업 그러나 자주 자동화 활동이 이루어졌으며, 특히 BNM에서 트리거된 플레이북은 시스템이 유지 보수 모드로 들어갈 수 없는 경우가 많았다는 것을 의미했습니다. 그 결과, 백업 실패가 반복적으로 발생하여 운영상의 큰 위험이 초래되고 수동 개입이 필요하게 되었습니다.

완화 전략

1. 백업 예약 최적화: 시스템 작업을 최소화한 유지 관리 기간이 식별되었습니다. 트래픽 및 자동화 분석을 기반으로, 오케스트레이션 및 플레이북 실행이 활성화될 가능성이 가장 낮은 오전 5시(AEST)에 백업 작업이 예약되었습니다.

2. 사전 백업 작업 검증: 백업 API를 호출하기 전에 자동화된 사전 검사가 도입되었습니다.

• 스크립트는 CNC API를 쿼리하여 실행 중인 변경 자동화 MOP 작업을 탐지합니다.
• 작업이 실행 중으로 보고되면 스크립트는 5초 동안 기다렸다가 다시 시도합니다.
• 이 루프는 시스템이 활성 작업을 보고하지 않을 때까지 계속됩니다.
• 환경이 유휴 상태로 확인된 후에만 스크립트는 유지 관리 모드를 활성화하고 백업을 트리거하려고 시도합니다.

이렇게 하면 시스템이 사용 중 작업 상태에 있는 동안 불필요한 백업 시도를 방지할 수 있습니다.

3. 재시도 및 탄력성 메커니즘: 일시적인 시스템 상태를 수용하기 위해, 추가 안전장치가 추가되었습니다.

• 백업 API에서 오류를 반환하는 경우 최대 3번의 재시도
• 재시도 사이의 짧은 지연 간격
• 스크립트 종료를 방지하기 위한 정상적인 오류 처리

결과 및 결과

이러한 통합 차단 기능을 통해 백업 안정성이 크게 향상되었습니다.

• 백업 장애 대폭 감소
• 구현 후 두 가지 실패만 관찰되었으며, 두 가지 모두 스크립트의 제어 범위를 벗어나는 sZTP 프로세스가 중단되었기 때문입니다.
• BNM 플레이북 자동화에서 실행 지연이 도입됨에 따라 유지 보수 모드와의 경합이 더욱 감소했습니다.

Splunk에 syslog 전달

TLS를 통해 Splunk에 로그를 전달하도록 CNC에서 syslog 대상이 구성되었습니다. 그러나 로그를 받은 후에는 Splunk 측에서 로그를 읽을 수 없습니다. Splunk 환경에서 발생하는 이 문제로 인해, 로그를 성공적으로 처리한 후 UDP 전송으로 되돌리는 옵션이 선택되었습니다.

장치 그룹화 마이그레이션 문제

사용자가 이전에 CNC 4.1에서 18개의 디바이스 그룹을 생성했습니다. 그러나 이 릴리스에서는 디바이스 그룹을 내보내거나 가져올 수 있는 UI 기반 또는 API 기반 메커니즘을 제공하지 않았습니다. 따라서 이러한 그룹을 CNC 7.1로 마이그레이션하려면 비표준 접근 방식이 필요했습니다. 2개의 내부 CNC API가 식별되었습니다. 하나는 장치 그룹 계층 구조를 표시하고 다른 하나는 각 계층 노드에 매핑된 장치를 나열합니다. 이러한 API를 사용하여 모든 디바이스 그룹 및 연결된 디바이스를 추출하여 JSON 출력으로 저장했습니다. 그런 다음 응답을 구문 분석하고 각 그룹에서 디바이스 호스트 이름만 추출하기 위해 사용자 지정 스크립트가 개발되었습니다.

CNC 7.1은 CSV 기반 가져오기 템플릿을 비롯한 디바이스 그룹에 대한 기본 가져오기/내보내기 기능을 도입했습니다. 레거시 시스템에서 호스트 이름을 추출한 후 두 번째 자동화 스크립트가 생성되어 CSV 템플릿을 필요한 형식으로 채우므로, 각 장치 그룹을 정확하고 독립적으로 가져올 수 있습니다. 이러한 자동화는 필수적이었습니다. 그렇지 않았다면 장치 그룹을 CNC 7.1로 마이그레이션하는 데 훨씬 더 많은 시간이 소요되고 운영이 복잡했을 것입니다.

대역폭이 심각하게 저하된 디바이스 격리

낮은 RBW/NBW 비율을 자동으로 해결하는 BNM 활용 사례를 구현했음에도 불구하고, 일부 디바이스는 장기간 동안 계속 심각한 성능 저하 상태를 유지했습니다. 쉐이퍼 및 대역폭 조정 플레이북은 일반적으로 성능 저하 이벤트 직후에 디바이스를 복원했지만, 몇몇 디바이스는 위험 상태로 1주일 이상 유지되었으며 수동 개입이 필요했습니다. 그러나 이러한 디바이스를 파악하는 데 어려움이 있었습니다. CNC UI는 경고문 및 대역폭 메트릭에 대한 명확한 시각화를 제공하지만, 긴 간격 동안 Critical 상태로 독점적으로 유지된 디바이스는 쉽게 드러나지 않습니다.

이러한 운영 격차를 해소하기 위해 API 기반 솔루션이 개발되었습니다. CNC는 구성 가능한 시간 창(예: 7일, 1개월)을 통해 최상위 경고 생성 디바이스 목록을 검색하는 API를 제공합니다. 선택한 기간 동안 Critical 알림만 생성한 디바이스에 대해 이 데이터를 가져오고 필터링함으로써 수동 교정이 필요한 디바이스를 신속하게 격리할 수 있었습니다. 이러한 자동화된 접근 방식을 통해 문제 해결 효율성이 크게 향상되었으며 지속적인 성능 저하 사례를 식별하는 데 필요한 시간이 단축되었습니다.

디바이스 텔레메트리 컨피그레이션 제거

CNC 4.1에서는 디바이스가 HI(Health Insight) KPI 프로필과 연결될 때 ttm-tcfunction 팩을 통해 NSO에서 푸시된 텔레메트리 컨피그레이션이 자동으로 적용되었습니다. 그러나 CDG VIP 참조를 포함하여 이러한 구성은 나중에 KPI 프로파일을 분리할 때 제거되지 않았습니다. 그 결과, 디바이스는 시간이 지남에 따라 오래된 중복 텔레메트리 항목이 누적되었습니다.

이 문제는 CNC 7.1로 업그레이드하는 동안 더욱 두드러졌습니다. 디바이스는 CNC 4.1에서 생성된 새 항목과 함께 CNC 4.1의 레거시 CDG VIP 텔레메트리 컨피그레이션을 보유하는 경우가 많았으며, 이로 인해 2,000개 이상의 디바이스에서 여러 개의 텔레메트리 컨피그레이션이 충돌합니다. CNC 7.1 CDG VIP 구성만 활성 상태로 유지해야 하는 등 운영 영향과 구성 위생에 대한 우려가 제기되었다.

이를 해결하기 위해 각 장치의 텔레메트리 컨피그레이션에서 오래된 CDG VIP 참조를 식별하고 제거하기 위한 자동화된 스크립트가 개발되었습니다. 이 솔루션은 컨피그레이션 불일치를 없애고, 예상되는 7.1 텔레메트리 모델과의 일치를 복원했으며, 대규모 디바이스 제품군 전체에서 며칠간 수작업으로 정리해야 했던 작업을 방지했습니다.

MDT 수집 문제 해결

CNC 7.1에서는 대부분의 HI(Health Insight) KPI 수집이 MDT(Model-Driven Telemetry)에 의존합니다. 디바이스에서 KPI 프로파일이 활성화되면 NSO는 필요한 센서 경로를 자동으로 프로그래밍하고 CDG VIP를 텔레메트리 대상으로 구성합니다. 이 컨피그레이션이 적용되면 해당 CDG 수집 작업이 생성되어 디바이스의 텔레메트리 상태를 추적합니다.

검증 과정에서 100개 이상의 디바이스에 텔레메트리 컨피그레이션이 누락된 것으로 보고되었습니다. CNC 사용자 인터페이스를 통해 이러한 디바이스를 식별하는 것은 비현실적이었습니다. UI가 디바이스별 필터링만 지원하고 디바이스 2,000개를 초과하는 플릿에서는 효율적으로 확장되지 않기 때문입니다. 이를 위해서는 어떤 장치에 텔레메트리 컨피그레이션이 부족한지, KPI 재활성화가 필요한지 판단하기 위한 자동화된 방법이 필요했습니다.

이를 해결하기 위해 KPI 프로파일이 활성화될 때마다 디바이스에 할당된 BNM 태그를 활용했습니다. 먼저 BNM 태그가 있는 모든 장치의 내보내기가 생성되었습니다. 그런 다음 CNC Collection API와 상호 작용하도록 Python 스크립트를 개발하여 페이지화 논리를 통합하여 전체 컬렉션 작업 집합을 검색했습니다(각 API 호출에서 최대 100개의 항목 반환). 스크립트는 수집 작업 데이터에서 호스트 이름을 추출하여 내보낸 BNM 태그가 지정된 디바이스 목록과 비교했습니다.

이 비교는 태그가 지정되었지만 BNM 수집 작업에 나타나지 않은 디바이스 목록을 산출하여 MDT 텔레메트리 컨피그레이션이 적용되지 않았음을 나타냅니다. 그런 다음 이러한 디바이스에서 KPI 프로필이 다시 활성화되었으며, 검증에서 해당 수집 작업이 모두 올바르게 생성되었음을 확인했습니다.

이 자동화는 문제 해결 프로세스를 대폭 간소화하여, 수동 검사를 통해서는 불가능한 작업인 모든 영향을 받는 장비를 하루 만에 식별하고 치료할 수 있게 해줍니다.

NSO 6.4.1.1의 HA 행동 변화 및 합의 알고리즘 조정

Cisco NSO 5.7.5.1에서 Cisco CNC 7.1 전환의 일환으로 6.4.1.1로 업그레이드하는 동안, 새로운 NSO 버전에서 합의 알고리즘이 암시적으로 지원됨에 따라 고가용성(HA) 동작에서도 주목할 만한 변화가 관찰되었습니다. 이는 NSO 5.7.5.1의 기본 동작이 아니므로 업그레이드 후 장애 조치 특성이 변경되었습니다. 특히 기본 노드가 중단되면 보조 노드가 읽기 전용 상태로 전환되어 프로비저닝 작업을 처리할 수 없습니다. 마찬가지로, 보조 노드가 중단되면 기본 노드가 활성 기본 상태에서 "없음" 상태로 전환되어 서비스 연속성에 영향을 미칩니다.

이전 구축에 맞게 조정된 예상 HA 동작을 복원하기 위해 NSO 6.4.1.1에서는 합의 알고리즘이 명시적으로 비활성화되었습니다. 이렇게 조정하면 장애 조치 시나리오에서 기본 및 보조 노드가 의도된 역할을 다시 시작하도록 하여 중단 없는 프로비저닝을 허용하고 이전 NSO 버전과 일관된 운영 안정성을 유지할 수 있습니다.

NSO 버전 업그레이드 및 패키지 호환성 향상

Cisco CNC 4.1에서 7.1로 전환하는 과정에서 기본 Cisco NSO 버전이 5.7.5.1에서 6.4.1.1로 업그레이드되었습니다. 이 버전 업그레이드로 기존 NSO 패키지 내에서 XML 템플릿 구조가 변경되었으며 레거시 템플릿 동작에 종속된 특정 회귀 테스트 사례에서 오류가 발생했습니다.

이러한 호환성 격차를 해결하기 위해 영향을 받은 NSO 패키지 템플릿을 NSO 6.4.1.1의 수정된 스키마 및 처리 요구 사항에 맞게 분석 및 업데이트했습니다. 이러한 개선 사항을 통해 모든 자동화 워크플로 및 서비스 모델이 예상대로 작동하여 회귀 안정성을 회복하고 업그레이드된 CNC 환경 전반에서 일관성을 유지할 수 있었습니다.

규모에 맞는 KPI 지원 문제

CNC는 디바이스에서 KPI 프로파일을 활성화하는 기본 UI 메커니즘을 제공합니다. 이러한 접근 방식은 소규모 사업자에게 잘 작동하지만 대규모 사업에서는 비효율적이고 신뢰할 수 없게 됩니다. 이 구축에서는 2,000개 이상의 SWR 디바이스에 KPI 지원이 필요했으며, UI에서 디바이스를 대량으로 선택하거나 처리할 수 있는 효과적인 방법을 제공하지 않았습니다.

처음에는 태깅 기반 접근 방식을 시도했습니다. 모든 SWR 장치에는 SWR 태그가 할당되었으며, 수동 장치 선택이 아닌 태그 선택을 사용하여 KPI 활성화가 실행되었습니다. 그러나 단일 워크플로에서 2,000개 이상의 장치를 처리하면서 상당한 운영 문제가 발생했습니다. 그 일은 3시간 이상 실행되었고 수백 번의 실패로 끝났다. 모든 디바이스가 인텐트에 포함되었지만, ~750개만 KPI 지원을 성공적으로 받았고, 반복적인 시도는 점진적인 진행만을 낳았습니다. 이 접근 방식은 확장성도, 반복성도 입증하지 못했습니다. 그것은 부하와 관련하여 중요한 문제를 보였다.

NSO 디바이스 동기화 문제에서 두 번째 문제가 발생했습니다. 많은 장애는 NSO가 해당 디바이스와 동기화되지 않았음을 나타냅니다. 수동 동기화 시작 작업 후 KPI 다시 활성화는 비현실적이며 광범위한 운영자 노력이 필요했습니다.

이러한 제한을 해결하기 위해 배치 중심의 자동화된 워크플로가 개발되었습니다.

1. 전체 CNC 인벤토리를 내보냅니다.
2. 50개(조정을 통해 최적의 크기로 식별)의 배치로 장치를 처리합니다.
3. 각 배치에 대해 디바이스 UUID를 사용하여 자동 동기화 시작을 트리거합니다.
4. CNC API를 통해 KPI 지원을 실행합니다.
5. 프로그래밍 방식으로 KPI 작업 기록 및 로그 오류를 모니터링합니다.
6. 동기화 및 KPI 활성화 단계를 반복하여 실패한 디바이스를 재처리합니다.
7. 배치가 성공적으로 완료되면 다음 디바이스 50대로 이동합니다.

자동화에는 KPI 프로파일을 비활성화하는 기능도 포함되어 전체 라이프사이클 관리가 가능해졌습니다.

이 솔루션은 KPI 프로비저닝을 위해 효율적이고, 확실하며, 확장성이 뛰어난 프로세스를 제공했습니다. 수동 개입이 필요 없고, 일관된 결과를 보장하며, 며칠에 걸친 운영 수고를 덜었습니다. BNM 설계 변경 후 KPI 프로파일을 비활성화했다가 다시 활성화해야 했을 때 동일한 자동화가 매우 유용하여 전체 2,000개 디바이스 플릿에서 신속하고 오류 없이 재구성할 수 있었습니다.

관리자 액세스로 제한된 RESTCONF 노스바운드 API

CNC에서 경보 및 이벤트를 전달하는 데 사용되는 RESTCONF 기반 노스바운드 API에는 관리자 계정을 통해서만 호출할 수 있는 제한이 있습니다. 서비스 계정을 통해 API에 액세스하려는 시도는 해당 계정에 필요한 운영 역할이 있음에도 불구하고 성공하지 못했습니다. 이를 해결하려면 사용자가 노스바운드 시스템에 대한 경보 전달을 위해 관리자 자격 증명을 사용해야 했으며, 이로 인해 운영 제약이 도입되고 최소 권한 액세스 원칙의 준수가 제한되었습니다.

전략적 조력자로서의 자동화

CNC 업그레이드 및 마이그레이션 프로그램의 규모와 복잡성을 감안할 때, 운영 작업의 수동 실행은 빠르게 지속 가능하지 않은 것으로 판명되었습니다. 디바이스 온보딩, KPI 프로비저닝, 컨피그레이션 조정, 조정, 텔레메트리 검증과 같은 활동에는 수작업으로 수행할 경우 사람에 의한 오류 가능성이 높은 수천 개의 네트워크 요소와 반복적인 워크플로가 포함됩니다. 따라서 자동화는 실행을 가속화하는 것뿐만 아니라 일관성을 보장하고 운영 위험을 줄이며 시간이 많이 들고 반복적인 작업에서 제공 팀을 자유롭게 만드는 데 필수적이었습니다.

스크립팅된 워크플로 및 API 중심 작업을 통해 이러한 프로세스를 체계화함으로써 업그레이드 프로그램은 상당한 효율성 향상을 달성했습니다. 자동화를 통해 작업 완료 시간이 단축되고, 정확성이 향상되었으며, 모든 섹션에서 예측 가능한 결과를 얻을 수 있었습니다. 그 결과 절감된 비용은 전체 구축 시간을 단축했을 뿐만 아니라 엔지니어가 일상적인 운영 작업 대신 더 높은 가치의 검증 및 설계 작업에 집중할 수 있게 되었습니다.

자동화 활동 중 일부는 업그레이드 프로젝트가 시작되기 전에 확인되었고, 일부는 문제가 발생했을 때 진화했습니다. 또한 프로젝트 과정에서 발생한 문제로 인해 필요했던 부분도 있었습니다.

이 표에서는 자동화가 프로그램 전체에 상당한 영향을 미친 영역을 보여 줍니다.

작업 설명	수동 작업(일)	자동화 작업(일)	예상 절감액(일)
ACL 업데이트(SWR/LWR)(2K+)	30.0	2.0	28.0
CDG(2K+)로의 장치 마이그레이션 및 연결	5	1.0	4.0
장치에 대한 BNM KPI 첨부(2K+)	4.0	1.5(평균)	2.5
서비스 조정	7	2.5	4.5
장치 그룹 마이그레이션	4	0.5	3.5
대역폭이 심하게 저하된 디바이스 격리	3	0.5	2.5
MDT 수집 문제 해결	3	0.5	2.5
총계	56일	8.5일	47.5일

습득한 교훈

업그레이드가 간단하지 않음

CNC는 내부 업그레이드를 지원하지 않으며, 전환기 모델은 운영상의 상당한 복잡성을 초래합니다. 특히 버전 점프가 큰 경우에는 프로세스가 결코 간단하다고 가정해서는 안 됩니다. 애플리케이션, 통합, 워크플로 전반에 걸쳐 예상치 못한 문제가 발생하며, 각 문제를 해결하려면 시간, 분석, 주의 깊은 대처가 필요합니다. 주요 버전의 비약으로 인해 이러한 문제가 증폭되어 철저한 계획, 검증, 단계별 실행이 필수적입니다. TAC 케이스 및 트러블슈팅 작업에 많은 시간을 할애해야 했습니다. 이를 위한 버퍼 시간을 유지하지 못해 어려움이 가중되었습니다.

CX는 Heavy Lifting을

구축, 통합, 마이그레이션, 엔드 투 엔드 활용 사례 검증 전반에 걸쳐 상당한 CX 솔루션이 필요합니다. 이전 릴리스에서 입증된 워크플로가 새 릴리스에서 동일하게 동작한다고 가정하지 마십시오.- 제대로 작동하려면 많은 문제 해결 및 분석이 필요합니다.

자동화 툴킷은 필수입니다.

업그레이드 과정에서 자동화는 선택 사항이 아니라 대규모 CNC 구축을 위한 기본적인 요구 사항임을 입증했습니다. 우리는 초기에 필요한 지원자를 위해 자동화를 계획했지만, 그 정도면 충분할 것이라고 결코 예상할 수 없습니다. 프로젝트 중간에 앞서 살펴본 것처럼 자동화가 가치를 분명히 부가하는 활용 사례에서 문제를 확인할 수 있습니다.

마이그레이션 과정에서 이중 컨트롤러 충돌 방지

업그레이드 과정에서 레거시 CNC 환경과 새 CNC 환경이 동시에 활성화되지 않도록 하는 것이 중요합니다. 검증에 짧은 소크 기간이 필요하지만, 이 프로젝트에서 2개월 이상 발생한 것처럼 크게 연장하면 운영 위험이 발생합니다. 두 CNC가 15-20일 이상 활성화된 상태에서 Bandwidth On Demand와 같은 폐쇄 루프 자동화 기능은 두 컨트롤러에서 동시에 자동화 논리를 실행했기 때문에 네트워크 전체에서 일관되지 않고 충돌하는 작업을 생성했습니다.

중요한 교훈은 이주 중에 명확한 가드레일을 구현하는 것이다. 이전 CNC에서 관리적으로 디바이스를 비활성화하거나, 자동화 워크플로를 일시 중지하거나, 텔레메트리 서브스크립션을 제한하는 등의 조치가 이러한 충돌을 방지했을 것입니다. 향후 업그레이드에서는 이중 컨트롤러 간섭을 방지하고 네트워크 동작을 예측할 수 있도록 엄격한 컨트롤러 격리를 명시적으로 계획해야 합니다.

MOP는 신성 불가침이 아니다

MOP(Method of Procedure) 문서는 모든 배포, 통합 및 사용 사례에 대해 생성되지만 랩 조건에서 검증된 MOP가 프로덕션 환경에서 동일하게 작동한다고 가정하는 것은 비현실적입니다. 생산 환경은 편차가 일부 사소한 것으로 일관되게 드러났으며, 일부 중요한 것으로 나타나 통제된 테스트 중에 드러나지 않았던 격차가 부각되었습니다. 실제 네트워크, 레거시 동작, 외부 종속성 및 라이브 트래픽 조건에서는 실험실 시뮬레이션에서 항상 복제할 수 없는 변수를 도입합니다.

핵심 학습 사항은 팀이 예상치 못한 행동, 에지 사례, 새로운 발견에 직면할 것을 예상하여 프로덕션 롤아웃에 접근해야 한다는 것입니다. 규모에 맞게 성공적으로 실행하려면 유연성, 신속한 문제 해결 기능, 즉석에서 절차를 조정할 준비가 필수적입니다.

TAC 케이스의 효율성

사후 생산 문제는 불가피하며, 초기 배송 팀의 문제 해결은 중요하지만, 내부 작업에만 의존할 경우 불필요한 지연이 발생할 수 있습니다. 특히 제품 관련 문제나 즉시 진단할 수 없는 복잡한 행동에 대해서는 TAC 케이스를 안전망으로 동시에 여는 것이 신중합니다. TAC 조사에는 시간이 필요한 경우가 많으며, 케이스 생성을 며칠 연기하면 프로젝트 추진력이 크게 저하될 수 있습니다. TAC를 조기에 도입하면 필요할 때 전문가의 지원을 받을 수 있으며 근본 원인을 신속하게 파악하고 불가피한 일정으로 인한 손실을 방지할 수 있습니다.

효과적인 지식 지원을 위해 CNC BU 참여

CNC 사업부의 강력한 지원은 모든 CNC 프로젝트 과정에서 매우 중요합니다. 사용자는 제공 팀만으로는 쉽게 이용할 수 없는 상세한 제품 정보와 설명을 필요로 하는 경우가 많습니다. 서비스 기간 동안 BU 담당자를 액세스할 수 있게 되면 문제 해결 속도가 빨라지고 기술 정확성이 강화되며 더 큰 신뢰와 사용자 관계를 구축할 수 있습니다.

CNC 업그레이드 모범 사례

최적화된 업그레이드 전략 계획

CNC는 내부 업그레이드를 지원하지 않으므로 병렬 구축이 불가피합니다. 새로운 환경을 신규 설치로 간주하고 두 환경을 동시에 실행할 수 있도록 충분한 컴퓨팅, 스토리지 및 관리 용량을 할당합니다. 검증 단계, 마이그레이션 순서 지정 및 컷오버 활동을 미리 계획합니다.

엄격한 구축 전 검증은 특히 불변의 매개 변수에 필수적입니다.

많은 경험을 통해 초기 구축 시 성실성이 매우 중요함을 강조합니다. 모든 주요 입력을 미리 검증합니다. 특히 변경 불가능한 구성 매개변수는 비용이 많이 드는 재구축을 방지하고 일정에 영향을 미치는 것을 방지하는 데 필수적입니다. 따라서 비가역적 컨피그레이션 오류의 위험을 최소화하기 위해 구조화된 구축 전 체크리스트, 피어 검토 및 리허설 검증을 사용하는 것이 좋습니다.

생산에 영향을 미치기 전에 전용 검증 환경 사용

프로젝트 초기에 내부 CALO/테스트 환경을 구축하면 팀에서 프로덕션 작업에 착수하기 전에 워크플로를 실험하고 검증하며 버전별 변경 사항을 발견하고 신뢰도를 높일 수 있습니다. 이렇게 하면 최종 롤아웃 중에 알 수 없는 부분이 크게 줄어듭니다.

분산형 Crosswork 구성요소를 위한 증거 기반 사이징

클러스터, CDG 배포 및 PCE 할당을 설계할 때 단순한 장치 수가 아닌 장치 유형, 인터페이스 규모, 토폴로지 복잡성 및 수집 강도에 대한 기본 결정을 내립니다. 균형이 잡힌 배포는 과부하를 방지하고 클러스터 전반의 예측 가능한 성능을 보장합니다.

반복적인 대량 작업을 위한 자동화

반복적, 대량 또는 운영상 중요한 킥오프(kick-off) 작업에서 자동화 백로그를 설정하고 자동화가 필수적인 곳에 투자합니다. SIT 환경의 자동화를 먼저 검증하고 개선하여 생산에서 막판 수정에 의존하지 않도록 합니다. 규모 확대로 수작업 비용 증대 표준화된 자동화는 품질, 속도 및 제어를 향상시킵니다. 결과를 재사용 가능한 자산(문서화된 인터페이스, 매개 변수가 있는 작업, 공유 라이브러리)으로 패키지화하여, 팀이 향후 크로스워크 업그레이드 및 인접 프로젝트에 동일한 자동화를 활용할 수 있도록 함으로써 재작업과 온보딩 시간을 줄일 수 있습니다.

병렬 실행 중 이중 닫힌 루프 제어 방지

공존하는 동안 폐쇄 루프 자동화를 단일 작성기 기능으로 처리합니다. 하나의 오케스트레이션 경로만 능동적으로 교정 또는 정책 기반 구성을 추진할 수 있습니다. 기존 스택과 새 스택의 동시 CLA는 트리거 및 분산 의도가 중복되어 디바이스 상태가 불안정해질 수 있습니다. 기능 검증과 새 컨트롤러에 대한 확실한 컷오버 후에 CLA go-live를 최종 단계 이정표로 계획하십시오.

정형 업그레이드 영향 평가 수행

주요 버전의 점프는 이전 버전의 점프를 중단하거나 변경하는 동시에 새로운 기능을 도입합니다. 이러한 변화를 고려하는 것은 매우 중요합니다. 업그레이드 버전의 릴리즈 노트에 변경 내용이 문서화되지 않고 현장에 도착하면 변경 내용이 표시되는 경우가 많습니다. 다음에 대한 구조화된 평가 실시:

• 사용되지 않는 API
• KPI 프레임워크 변경
• 애플리케이션 수준의 동작 차이
• 컨피그레이션 모델 편차
• 알림, 토폴로지 처리 및 플레이북 실행 변경

통합 표면 전반의 호환성 및 동작 테스트

CNC는 NSO, SSM, CPNR, EPNM, OneFM, Splunk, 오케스트레이션 프레임워크 등 여러 외부 시스템과 상호 작용합니다.
마이그레이션 전:

• 버전 호환성 검증
• 모든 노스바운드/사우스바운드 통합 테스트
• 데이터 모델, 트랩, 텔레메트리 흐름 확인
• SSL/RESTCONF 인증 동작 확인

마이그레이션 후 발견된 통합 실패로 인해 운영 사각지대가 발생합니다.

강력한 마이그레이션 전 데이터 내보내기 전략 수립

마이그레이션을 시작하기 전에 모든 항목을 내보냅니다.

• 자격 증명 프로파일
• 공급자
• 태그
• 사용자 지정 플레이북
• 사용자 지정 KPI
• 역할 및 RBAC
• sZTP 바우처
• 장치 그룹
• 내역 서비스 메타데이터

내장된 검증 게이트를 통한 배치 디바이스 마이그레이션

수천 개의 디바이스를 마이그레이션할 때 제어된 배치로 마이그레이션을 수행합니다.

• 고정된 코호트로 장치 이동(예: 지역, CDG 로드 또는 장치 유형별)
• 다음 배치로 이동하기 전에 텔레메트리, NSO 동기화 상태 및 연결성 검증
• 지속적인 이상 징후 발생 시 배치 롤백

이렇게 하면 짧은 시간 간격으로 CDG 및 CNC에 높은 로드가 발생하지 않습니다.

NSO 통합을 통한 대역 외 컨피그레이션 변경 처리

CNC 4.1~7.1 업그레이드의 일환으로 대역 외 과제를 해결하기 위해 NSO 중심 운영으로의 구조적 전환이 구현되었습니다. 운영 팀에는 NSO CLI에 대한 사용자 기반 액세스 제어 권한이 제공되었고, 디바이스 CLI에 대한 직접 관리 액세스는 대역 외 변경을 방지하기 위해 제한되었습니다. 또한 레거시 CLI 스크립트는 NSO와 통합된 RESTCONF 기반 자동화로 체계적으로 변환되어 리허설 검증 및 트랜잭션 롤백과 같은 기능을 사용할 수 있게 되었습니다. 이러한 접근 방식을 통해 모든 구성 변경 사항을 중앙에서 관리하고, 감사가 가능하며, NSO의 서비스 모델과 일관되도록 하여 구성 변경을 효과적으로 제거하고 프로비저닝 안정성을 복원했습니다.

변경 동결에 강한 강조 표시

중요한 마이그레이션 기간 중:

• 사용자가 시작한 네트워크 변경 동결
• 컨피그레이션 푸시 제한
• 필드 및 NOC 팀과 동기화
• CNC/ZTP 등을 사용한 장치 교체와 같은 비상 작업을 수용할 수 있는 몇 가지 창을 계획하십시오.

따라서 소음이 줄어들고 업그레이드 내내 네트워크 상태가 안정적으로 유지됩니다

결론

CNC 4.1에서 CNC 7.1로의 마이그레이션은 대규모 네트워크 오케스트레이션 플랫폼 업그레이드의 복잡성에 관한 중요한 사례 연구입니다. 이 프로젝트는 이러한 전환이 단순한 버전 향상이 아니라 아키텍처 레이어, 운영 워크플로 및 자동화 에코시스템 전반에 걸친 포괄적인 변화임을 보여줍니다. 내부 업그레이드 경로가 존재하지 않아 완전한 리프트 앤 시프트 구축이 필요했으며, 그에 따라 병렬 환경 문제가 발생했으며, CNC, NSO, SR-PCE, CDG 및 외부 시스템 통합 전반에서 세심한 조율이 필요했습니다. 그 결과 운영 환경은 강력한 마이그레이션 방법론, 철저한 검증 주기, 운영 환경의 위험을 완화할 수 있도록 엄격하게 제어되는 컷오버 프로세스의 중요성을 강조했습니다.

이번 업그레이드로 확장성과 정확성을 위해 자동화가 필수불가결한 요소라는 사실이 더욱 드러났다. 2,000개 이상의 장치, 광범위한 텔레메트리 구성, 여러 종속 구성 요소, 동적 폐쇄 루프 자동화 워크플로를 통해 이 규모의 환경에서 수동 절차의 한계를 강조했습니다. ACL 업데이트, 디바이스 온보딩, KPI 프로비저닝, 텔레메트리 정리, 오류 격리 등 목적에 맞게 구축된 자동화는 결정성을 보장하고 인적 오류를 줄이며 상당한 효율성 향상을 달성하는 데 필수적임이 입증되었습니다. 자동화 프레임워크는 마이그레이션 과정에서 운영 연속성을 지원할 뿐 아니라 지속적인 네트워크 최적화를 위한 지속 가능한 기반을 구축했습니다.

생산 행동이 통제된 실험실 조건으로부터 현저히 벗어난다는 인식도 동일하게 중요하였다. Tick 기반 KPI 논리에서 추적기 기반 정의로의 전환과 같은 프레임워크 변경으로 인해 재엔지니어링, 재테스트 및 반복적 구체화가 필요한 예기치 않은 동작 변화가 도입되었습니다. 마찬가지로, 폐쇄형 루프 자동화, 텔레메트리 신뢰성, API 동작과 관련된 운영 과제에서도 적응형 문제 해결, 사전 대응적 위험 평가, TAC 및 사업부 SME(Subject Matter Expert)와의 지속적 참여가 필요했습니다. 이러한 요인은 주요 버전 전환에 기술 수준과 조직의 준비 상태가 모두 필요하다는 것을 종합적으로 보여 줍니다. 다음 crosswork 버전 7.2에서 해결될 것으로 예상되는 미해결 문제는 거의 남아 있지 않습니다.

전반적으로 이번 업그레이드는 대규모 CNC 마이그레이션의 성공을 위해서는 다음과 같은 네 가지 기본 요소가 필요하다는 것을 보여 줍니다. 엄격한 사전 구축 검증, 체계적이고 탄력적인 자동화, 강력한 다기능 조정, 랩 환경과 프로덕션 환경 간의 분산을 예측하는 적응형 운영 상태. 이 서비스를 통해 얻은 통찰력은 안정적인 CNC 7.1 구축에 기여했을 뿐만 아니라 향후 전환에 대한 청사진을 제시하고, 모범 사례를 알리고, 아키텍처 가드레일을 강화하고, 네트워크 자동화 에코시스템의 후속 진화를 위한 기관 지식을 강화합니다.

용어집

용어	정의
BNM	대역폭 알림 메시지입니다.
고양이	Crosswork Active 토폴로지
CCA	크로스워크 변경 자동화
CDG	Crosswork Data Gateway
키	Crosswork Health 인사이트
CNC	Cisco Crosswork Network Controller
COE	크로스워크 최적화 엔진
CPNR	Cisco Prime Network Registrar
CWM	Crosswork Workflow Manager
기전력장치	요소 관리 기능
KPI	핵심 성과 지표
LWR	대형 무선 라우터
MDT	모델 기반 텔레메트리
자루걸레	절차 방법
NBW	명목상 대역폭
NSO	네트워크 서비스 오케스트레이터
RBW	기록된 대역폭
SR-PCE	세그먼트 경로계산 요소
SSM	Cisco 스마트 소프트웨어 관리자
SWR	소형 무선 라우터
TAC	기술 지원 센터
TSDN	전송 소프트웨어 정의 네트워킹
ZTP	제로 터치 프로비저닝
RR	경로 리플렉터
RP	경로 프로파일
포이	상호 연결 지점
EVPN	이더넷 가상 사설망.

참조

• Cisco Systems, Cisco Crosswork Network Controller 릴리스 정보, 릴리스 7.1.0 
• Cisco Systems, Cisco Crosswork Infrastructure 7.1 설치 설명서
• Cisco Systems, Cisco Crosswork Infrastructure 7.1 관리 설명서 — 개념 개요: 
• Cisco Systems, Crosswork Network Controller Traffic Engineering and Optimization Guide, 릴리스 7.1
• Cisco Systems, Cisco Crosswork Health Insights 사용 설명서, 릴리스 7.1
• Cisco Systems, ZTP(Crosswork Zero Touch Provisioning) 구축 설명서
• Cisco Systems, Cisco NSO Transport SDN Function Pack 번들 설치 설명서, 릴리스 7.1.0  
• Cisco Systems, Cisco SR-PCE 컨피그레이션 가이드

개정 이력

개정	게시 날짜	의견
2.0	04-May-2026	초기 릴리스, 서식, 머리글, 링크, 문법, 맞춤법.
1.0	30-Apr-2026	최초 릴리스