네트워크 자동화에 대해 제가 공유한 관련 기사는 "NetDevOps from Scratch" 카탈로그를 참조하세요.
최근 몇 년 동안 글로벌 클라우드 컴퓨팅 분야의 지속적인 발전과 비즈니스의 지속적인 성장으로 네트워크 기술도 계속 발전해 왔으며 SDN 기술이 등장했습니다. Openflow를 기반으로 한 포워딩과 제어의 분리라는 원래 핵심 아이디어에서 사람들은 계속 확장하고 있습니다. SDN의 확장에서 사람들은 현재 Openflow가 더 이상 필요 조건이 아니라는 합의에 도달할 수 있습니다(그러나 포워딩과 제어의 분리는 여전히 핵심 조건), 네트워크 프로그래밍 가능성은 천천히 SDN 아키텍처를 측정하는 중요한 기준 중 하나가 되었습니다.
기존 네트워크 장비의 프로그래밍 가능한 작동은 일반적으로 CLI 및 SNMP 프로토콜을 기반으로 합니다. 스크립트든 네트워크 관리 소프트웨어든 모두 오늘 이야기할 광범위한 네트워크 프로그래밍 기능을 달성하기 위해 이러한 기반으로 개발되었습니다. 기능을 통해 다양한 시나리오의 자동화를 실현합니다. 일부 장치는 일부 웹 인터페이스의 구성과 xml을 통한 전체 구성 대체를 지원합니다. 이는 매우 드물기 때문에 이 기사에서는 자세히 설명하지 않습니다.
CLI (영문)
CLI(Command-Line Interface)는 명령줄을 통해 인간-컴퓨터 상호 작용을 실현합니다. 네트워크 작업자에게 필요한 기술입니다. 사람들은 매일 장치에 대한 소프트웨어 SSH 또는 Telnet을 연 다음 구성을 붙여넣고 저장하고 적용합니다. 어느 날 사람들은 이런 반복에 지쳐서 자동으로 구성 스크립트를 생성하고, 일괄적으로 장치에 로그인하고, 구성을 발행하여 적용하는 프로그램을 사용하여 자동화를 실현했습니다. 이는 네트워크 프로그래밍이 가능한 방법입니다. 사람들의 생각, 아이디어, 기존 기술 시스템과 매우 일치하는 장점에 대해 이야기해 보겠습니다. 그러나 궁극적으로 이 접근 방식은 네트워크 장치보다 사람을 선호합니다. 다음과 같은 단점이 있습니다.
-제조업체마다 명령 세트에 큰 차이가 있습니다. 제조업체뿐만 아니라 동일한 모델의 소프트웨어 버전에 따라 차이가 매우 다를 수 있습니다.
-개발자는 명령어 세트와 사용 방법에 익숙해야 합니다. 구성 수준에는 보안 위험이 있습니다. 예를 들어, 손을 가볍게 치면 열려고 했던 포트가 포트를 닫는 것으로 바뀌었는데…
-전송 프로토콜(SSH 및 Telnet)에 대한 필수 요구 사항이 없으며 생산 보안 위험이 있습니다.
- 구성을 구문 분석하고 생성하는 과정은 매우 복잡합니다. 많은 경우, 작성된 일반 규칙은 "진실"에 무한히 가까울 수 있지만 전체 "진실"은 아닙니다.
-트랜잭션성이 없으며 구성이 부분적으로 적용되고 일부는 적용되지 않을 수 있습니다.
- 자동화된 검사 메커니즘이 없으며 전적으로 사람에게 의존합니다. 예를 들어 생성된 스크립트가 올바른지 테스트하고 싶습니다. 방법이 있지만 매우 어렵고 쉽게 구현하기 어려운 경우가 많습니다.
- 데이터 모델링에 대한 개념이 없음
CLI는 항상 인간과 컴퓨터의 상호 작용 방식입니다. 프로그램을 통해 네트워크에 특정 프로그래밍 기능을 제공할 수 있지만 결국 본질적으로 네트워크 프로그래밍이 가능한 방법은 아닙니다. 현재의 클라우드 컴퓨팅 및 SDN 물결에서는 네트워크의 대규모 자동화 배포에 적합하지 않으며 프로그래밍 가능성이 제한됩니다. 개발의 어려움을 외부인이 이해하기는 어렵습니다.
SNMP (SNMP)
SNMP(SNMP, Simple Network Management Protocol)인 이 프로토콜은 네트워크 관리 시스템을 지원하여 네트워크에 연결된 장치에 관리 주의를 유발하는 상황이 있는지 여부를 모니터링할 수 있습니다. 이는 애플리케이션 계층 프로토콜, 데이터베이스 스키마 및 데이터 개체 집합을 포함한 일련의 네트워크 관리 표준으로 구성됩니다.
Wikipedia의 일부 콘텐츠에서는 네트워크 관리, 모니터링 및 데이터 개체를 강조합니다. 네트워크를 관리하는데 사용되며, 구성 및 수집이 가능하며 주로 모니터링에 사용됩니다. 네트워크 장비의 일부 모듈, 특성, 상태 데이터를 구조화하기 위한 데이터 모델링 기능을 갖추고 있습니다. 주로 네트워크 관리 시스템(주로 모니터링)에 사용됩니다. 그런 다음 단점에 대해 이야기 해 봅시다.
-가독성이 좋지 않습니다. 인간-기계 중 "기계"를 선호합니다. 사용 시 읽을 수 없으며, 모델링 데이터도 읽을 수 없습니다. ASN.1의 상위 집합을 사용합니다.
- 보안이 제한되어 있습니다. v1, v2c, v3의 세 가지 버전이 있으며 보안이 순차적으로 향상됩니다. 그러나 가장 일반적인 것은 보안이 제한된 v2c입니다. v3 버전은 설계상 매우 안전하지만 보편적이지는 않습니다. . .
-백업, 복구 또는 롤백 메커니즘이 없습니다. 명령줄을 백업하기 위한 show run 및 기타 방법도 있지만 snmp는 없습니다. . .
- 쓰는 일이 거의 없습니다. 많이 읽고 적게 쓰며 주로 모니터링에 사용됩니다.
- 수집할 수 있는 데이터 항목이 제한되어 있으며, 기기 전체의 구성을 알 수 없습니다. 많은 경우 cli를 사용하여 수집할 수 있지만 snmp를 사용하여 수집할 수는 없습니다.
- 성능 병목 현상이 발생합니다. 수집되는 데이터의 상한은 64K이며, 수집 단위가 너무 큽니다. 크고 복잡한 네트워크에서는 몇 분 이상 걸릴 수 있습니다. 이것은 또한 중요한 점을 강조합니다. 세분화에 대한 요구 사항도 매우 엄격합니다. 우리는 몇 초마다 포트 트래픽을 수집하기를 희망하는 경우가 많습니다. 대규모 네트워크에서 전통적인 네트워크 관리 소프트웨어는... 한 문장으로 더 확장하자면 현재의 방법은 마이크로초 수준을 달성할 수 있는 Telemetry(예: gRPC)이며, 일부는 소프트웨어와 하드웨어의 조합이 필요합니다. 아직 대중화되지는 않았지만 앞으로는 트렌드가 될 것 같습니다. 앞으로 언제 이런 일이 일어날지...
- SNMP는 탄생 이후 모니터링용 데이터를 얻기 위해 네트워크 모니터링 분야에서 많이 사용되었습니다. 구성 기능이 부족하고 복잡하기 때문에 네트워크 구성에서 이를 거의 사용하지 못했습니다. 읽기 전용 네트워크 프로그래밍 가능.
Netconf 프로토콜 및 YANG 모델
차세대 네트워크에 직면하여 네트워크 프로그래밍 가능성을 더 잘 실현하고 자동화 수준을 향상하려면 어떤 종류의 네트워크 관리 프로토콜이 필요합니까?
IETF는 2002년 RFC3535에서 다음 아이디어를 제안했습니다(실제로는 33개가 있습니다. 온라인 정보와 작성자의 지식을 바탕으로 다음 아이디어를 작성했습니다).
1. 네트워크 구성을 위한 프로그래밍 가능한 인터페이스가 있습니다.
2. 제조업체와 모델에 걸쳐 동일한 구성을 사용할 수 있습니다.
3. 가독성이 좋은 모델링 언어의 통일성 필요
4. 완벽한 오류 확인 및 복구 기능
5. 거래
아이디어가 있다면 구현해 보세요. 2006년에 IETF는 RFC3535에서 제기된 문제를 해결한 Netconf 프로토콜을 제안했습니다. 초기 Netconf에서는 프로토콜의 기본 프레임워크와 작동만 규정하고 RFC3535의 일부 문제점을 고려한 솔루션을 정의했습니다. 통일된 모델링 언어를 규정하지 않았습니다. 따라서 일부 초기 제조업체의 장비는 Netconf의 일부 기본 작업만 지원하고 통합된 하위 계층을 사용하지 않았습니다. 데이터 모델링 언어.
RFC6020은 2010년에 출시되어 YANG 모델 모델링 언어와 이를 NETCONF와 결합하는 방법을 제안했습니다. 한 정의는 제조업체 간의 기본 리소스 논리를 통합하는 데이터 모델링 언어이고, 다른 정의는 구성 데이터 및 상태 데이터에 대한 각 제조업체의 작업에 대한 통합 명령 세트입니다. YANG 모델에 의해 생성된 데이터 인스턴스는 Netconf 프로토콜로 래핑됩니다. 전송, 두 가지가 서로 결합되어 YANG 모델을 기반으로 하고 Netconf 프로토콜에 의해 구동되는 새로운 시대를 위한 새로운 범용 네트워크 프로그래밍 가능 인터페이스 세트를 구축합니다.
2016년 이후 Netconf 프로토콜은 YANG 모델과 긴밀하게 통합되어 인기를 얻었습니다. 지금까지 일부 SDN 아키텍처 소프트웨어 측면을 살펴보면 이 두 가지 용어를 어느 정도 들어본 적이 있습니다.
YANG과 Netconf는 음과 양처럼 하나는 정적이고 다른 하나는 동적입니다. 두 사람은 차세대 네트워크 프로그래밍 가능 세계를 이끌어냈습니다. (github에서 YANG 창고를 보면 아이콘이 태극권이라는 것을 알 수 있으며, 이름과 "Yang"의 연관성은 원래 디자이너의 디자인 아이디어를 어느 정도 드러냅니다.)
다음으로 YANG Model과 Netconf 프로토콜에 대해 간략하게 설명하겠습니다. 먼저 데이터 모델링 언어 YANG에 대해 이야기하여 이 네트워크 세계의 디지털 트윈을 어떻게 설명하는지 살펴보겠습니다.
양 모델
RFC6020 문서의 첫 장에는 네트워크 구성 프로토콜용 데이터 모델링 언어인 YANG이 명시되어 있습니다. Yet Another Next Generation(Yang) 데이터 모델링 언어의 약어입니다. 네트워크 개념을 설명하는 데 사용되는 모델링 언어입니다.
목록, 사전 및 훨씬 더 복잡한 데이터 구조의 정의를 지원하고 제약 조건, 열거, 참조 가져오기, 버전 관리 및 네임스페이스를 지원합니다. 지면 관계로 간략한 설명을 드리겠습니다. 자세한 내용은 다음을 참조하세요.
이 네트워크 장치를 구조화된 언어로 매우 간단하게 설명할 수 있습니다. 예를 들어 포트 정의의 경우 다음과 같습니다.
전문 운영 및 유지보수 담당자로서 약간의 네트워크 기본 지식과 약간의 프로그래밍 기본 지식을 갖추고 있으면 포트의 정의를 비교적 명확하게 이해할 수 있습니다. 목록 구조이며 여러 개가 있을 수 있습니다. 해당 속성 중 하나는 인터페이스 이름(키이기도 함)입니다. , 고유, 반복 불가능), 속도 속성 및 이중 속성(둘 다 문자열)입니다.
구성 상태 및 작동 상태를 포함하여 네트워크 장치의 많은 속성이 YANG 모델로 설명됩니다.
이런 방식으로 YANG 모델은 구조화된 언어를 사용하여 온라인 세계를 설명합니다. 관심이 있으시면 위의 인터넷 블로그 게시물을 읽어보실 수 있습니다. 이 게시물에는 매우 자세한 설명이 나와 있습니다.
이는 XML 데이터로 매우 잘 변환되고 전송을 위해 Netconf 프로토콜로 래핑될 수 있습니다(나중에 설명하겠습니다).
동시에 공급업체 간의 차이를 평준화하기 위해 Google이 주도하는 Openconfig는 데이터 모델을 표준화했습니다. 공식 웹사이트에는 사용자와 크로스 플랫폼에 의해 디자인된 "사용자가 설계한 공급업체 중립적, 모델 중심 네트워크 관리"라는 슬로건이 표시됩니다. 공급업체 공통, 모델 기반 네트워크 프로그래밍(먼저 이런 식으로 번역해 보겠습니다). 쉽게 말하면 여러 제조사 간의 모델링을 동일하게 만들어 특정 데이터를 구성할 때 각 제조사의 전용 양 모델을 일일이 살펴보지 않아도 되도록 하는 것입니다. 그러나 인터넷에는 항상 개인 프로토콜이 있으며, 다양한 제조업체는 항상 "더 나은 사용자 경험"과 "더 나은 비즈니스 전략"을 위해 새롭고 더 나은 개인 프로토콜을 만들 것입니다(이것이 실제로 네트워크 제조업체의 원죄입니다). 그림은 더 일반적으로 사용되는 openconfig 양 모델 구현 중 일부를 보여줍니다.
사진으로 보면 꽤 많은 것 같고 일반적으로 사용되는 구성도 비교적 완성도가 높은 것 같습니다. 그러나 실제로는 제조업체가 이러한 양 모델도 지원하는지 여부에 따라 다릅니다. 특정 주제의 일부 상위 버전 장치는 기본적으로 지원됩니다. 아직 국내 제품은 자세히 살펴보지 못했습니다.
네트워크는 완전히 동일할 수 없습니다. 네트워크 운영 및 유지보수 개발에 종사하는 엔지니어에게 동일한 목표를 달성할 수 있다는 것은 축복입니다!
openconfig는 https://github.com/openconfig/public/tree/master/release/models에서 찾을 수 있습니다.
다양한 공식 웹사이트에서 개인 양 모델을 찾을 수 있습니다.
Netconf 프로토콜
양 모델에 대해 이야기한 후 Netconf 프로토콜에 대해 이야기해 보겠습니다. Yang 모델은 네트워크 세계의 디지털 설명을 정의하고 Netconf는 데이터 획득(가져오기) 및 조정(구성)을 정의합니다.
Netconf는 양 모델이 설명하는 세계의 데이터를 캡슐화하여 네트워크 세계의 관리를 실현합니다.
Yang 데이터는 xml로 캡슐화되어 Netconf 프로토콜을 통해 관리됩니다. 이는 프로토콜의 일부 세부 사항을 계층적 방식으로 설명하는 훌륭한 계층적 아이디어를 갖춘 프로토콜입니다. 위의 그림을 살펴보자.
-전송: Netconf는 SSH 프로토콜을 통해 전송되며 연결 지향적이며 보안이 보장됩니다.
-메시지: RPC를 통해 네트워크 장치에 원격 호출을 하면 네트워크 관리자가 rpc 요청을 발행하고 네트워크 장치는 rpc-reply를 재개합니다.
-작동: 이것이 Netconf의 영혼입니다. get(구성 및 실행 데이터), get-config(구성 데이터 가져오기 및 장치는 여러 구성 데이터, 하나는 실행 중, 하나는 시작, 여러 후보 후보를 가질 수 있음), edit -config(네트워크 장치 매개변수 구성, 추가 지원, 삭제 및 수정), delete-config, copy-config(구성을 대상에 복사, 대상은 ftp, 파일 또는 실행 중인 구성 등일 수 있음), lock\unlock(구성 충돌이나 오류로 인한 오류를 방지하기 위해 구성 잠금) 다중 프로세스 작업) 등이 있습니다.
-데이터: 데이터는 xml로 감싼 양 데이터입니다. 위에서 설명한 포트와 마찬가지로 구조화된 데이터는 프로그래밍하기 쉽습니다. 구성, 삭제 또는 획득할 데이터를 설명하는 데 사용됩니다.
이것이 Netconf의 4개 계층입니다. 제어 측과 네트워크 장치는 Netconf 하위 시스템을 사용하여 기존 SSH 프로토콜을 통해 Netconf를 통해 통신하며 기본 포트는 830입니다. 아래와 같습니다.
이 그림은 원시 SSH를 사용한 상호 작용을 보여 주지만 실제로는 프로그래밍을 통해 이 프로세스를 구현합니다. 나중에 프로그래밍 구현 방법을 보여 드리겠습니다.
Netconf는 네트워크 장치를 구성합니다. 상호 작용 프로세스는 대략 다음과 같습니다.
이 그림은 너무 낮아서 제가 그린 그림이라는 것도 알 수 있습니다… 제가 Netconf에 대해 이해한 바는 위와 같습니다. 인터넷에 옳지 않은 사진이 많고, 서버 에이전트의 행동도 옳지 않은 경우가 많은 것 같아요. 이는 기기에 로그인할 때 직감적으로 느끼는 점이며, 물론 공식문서와도 1:1로 대응됩니다.
몇 가지 Netconf 예제를 볼 수 있습니다:
안녕하세요, 링크를 구축해 보세요.
Netconf 버전, 지원되는 YANG 모델, 세션 ID 등 여러 키워드를 확인했습니다. 동시에 hello는 우리가 어떤 네임스페이스에서 작업하고 있는지를 나타냅니다. 이 경우 해당 버전의 Netconf입니다.
구성 가져오기
get-cofig의 매개변수 중 하나는 구성 데이터(실행, 시작 또는 기타)를 가져오는 소스입니다. 또 다른 매개변수는 필터, 즉 어떤 양 모델이 설명하는 데이터 모델로부터 어떤 데이터를 얻는가이다. 이는 원래 네트워크 장치에서 보낸 기능에 해당합니다. 성공하면 해당 구성 데이터가 반환됩니다.
구성 또는 실행 데이터 가져오기
get-config와 유사하지만 얻는 것은 실행 중인 구성(개인 이해) 또는 실행 중인 데이터입니다. 필터를 지정할 수 있습니다.
구성 복사
복사 작업에는 소스와 대상이라는 두 가지 매개변수가 있습니다. 성공적인 응답은 ok 태그입니다.
구성 수정
구성을 편집할 때 편집할 데이터 항목, 기능의 네임스페이스 및 해당 레이블을 지정합니다. 예를 들어 이는 yang 모델 http://tail-f.com/ns/example/dhcp에 설명된 dhcp를 구성하는 것입니다.
세션을 정상적으로 종료합니다.
SSH에서 주고받는 메시지가 바로 이런 종류의 메시지입니다. 모든 사람의 이해를 돕기 위해 메시지의 일부만 추출합니다.
그런 다음 참조할 내용을 추가하기만 하면 됩니다.
-Netconf는 세션을 기반으로 하며 모든 성공에는 세션 ID가 있습니다.
-각 요청에는 메시지 ID가 있으며 점차 커지는 한
- 데이터 구성은 잠금을 통해 잠금, 배타적, 작동이 가능합니다.
-Netconf는 트랜잭션 방식이며 작업이 모두 구현되거나 구현되지 않습니다. 동시에 공식 웹사이트 문서에 따르면 이 트랜잭션은 N개의 네트워크 장치 구성을 위한 것입니다. 즉, 일회성 구성 다형성이 트랜잭션을 지원할 수 있습니다. 하지만 아직 해본 적은 없어요…
-Netconf는 구독을 지원합니다. 장치 성능 측면에서 보면 약 5세션 정도입니다. 특정 데이터 항목을 구독하면 해당 항목이 변경될 때 장치에서 알려줍니다.
-능력, 나는 이렇게 이해한다. 네트워크 장치는 Netconf 버전과 YANG 모델을 보내고 제어 터미널은 Netconf 버전을 보냅니다. Netconf 버전이 두 버전과 일치하는 경우에만 계속할 수 있습니다. 이것이 나의 직감적인 느낌이다. 어떤 조언이라도 환영합니다.
-편집 가져오기와 같은 작업은 변경될 데이터를 지정하며, 이는 필터를 사용하여 필터링할 수 있습니다.
-copy-config는 전체 구성 세트를 어딘가에서 다른 곳으로 복사하는 것을 지원합니다. 어딘가는 장치의 FTP 파일, 실행, 시작 및 후보 구성일 수 있습니다.
-Netconf는 유효성 검사 작업을 사용하여 구성 확인도 지원합니다.
이 기사는 여전히 과학의 대중화를 희망하고 있으므로 자세한 내용은 다루지 않겠습니다. 실제로는 그리 길지 않은 RFC의 관련 프로토콜을 읽을 수 있습니다.
실제로 Python의 ncclient와 같은 일부 오픈 소스 소프트웨어를 기반으로 네트워크 장치를 자동으로 쉽게 구성하고 네트워크 프로그래밍 기능을 달성할 수 있습니다. 이것이 Netconf와 YANG Model의 사명입니다.
네트워크 담당자는 잘 구성된 YANG 모델 정의를 읽고 관련 프로그래밍 언어를 사용하여 Netconf에서 정의한 작업을 기반으로 네트워크 장치에서 프로그래밍 가능한 작업을 수행합니다. 이러한 방식으로 네트워크 프로그래밍 가능성이 형성됩니다.
YANG 모델이 네트워크 장치의 데이터 구조를 정의했다고 확장하고 상상해 봅시다. Netconf를 통해 운영할 수 있습니다. 다른 프로토콜을 통해서도 작동할 수 있나요?
대답은 '예'입니다. 실제로 RESTConf와 같은 다른 많은 프로토콜이 Netconf에서 파생되었습니다. 아래 그림과 같이,
YANG 모델(퍼블릭 및 네이티브)은 데이터 구조를 정의하며 그 위에는 새로운 네트워크 관리 프로토콜인 Netconf, RESTCon, gRPC 등이 있습니다. 이러한 방식으로 HTTP RESTful API를 기반으로 하는 RESTConf를 통해 네트워크 장치를 운영할 수 있으며, 네트워크도 운영할 수 있습니다. SSH 기반 Netconf를 통해 장치를 작동하거나 HTTP2 기반 gRPC를 통해 네트워크 장치를 작동할 수 있습니다.0. 그들은 모두 좋은 데이터 구조를 가진 YANG을 기반으로 합니다. 모델링하고 해당 데이터를 작성하고 이를 xml 또는 json으로 캡슐화하여 네트워크 장치를 프로그래밍합니다. 이것이 네트워크 프로그래밍 가능성의 미래입니다. 정확하게 말하면 Model Driven Program, 즉 모델 기반 네트워크 프로그래밍 기능입니다. 네트워크 엔지니어는 점차적으로 명령 세트 대신 장치의 매개변수에 집중하고 해당 데이터 모델을 읽어 네트워크 매개변수를 구성합니다.
마지막에는 왜 이 공개계좌를 열어야 하는가라고 적었습니다. 저는 학교 다닐 때 컴퓨터 과학과 기술을 공부했습니다. 입사 후 네트워크 운영 및 유지보수 업무를 담당하였습니다. 생각해보면 제가 팀으로 나뉘어진 이유는 제가 네트워크기술연구소 대학원생이었기 때문이 아닐까 합니다(설명서 웃기네요). 저는 처음부터 네트워크 운영에 참여했습니다. 운영 및 유지보수 후기 단계에서는 CLI를 기반으로 작업을 단순화하고 효율성을 높이기 위한 도구를 사용했습니다. 나중에 도구는 점차적으로 BS 구조의 웹 애플리케이션으로 개발되었습니다. 그들은 끊임없이 새로운 기술에 노출되었고 새로운 기능을 계속해서 풍부하게 만들었습니다.
다행스럽게도 그들은 오픈 소스 기술과 SDN의 발전을 따라잡았고 점차적으로 NetDevOps 작업으로 전환하여 프로그래밍 기술을 사용하여 팀의 운영 및 유지 관리 능력을 향상시켰습니다. 나는 또한 이 코드 줄을 작성하는 것을 즐겼습니다. 집필이 진행됨에 따라 NetDevOps는 모든 네트워크 엔지니어가 미래에 보유해야 하는 기술(모든 사람이 불에 연료를 추가함)이 되어야 높은 수준의 계획과 신속한 구현을 모두 달성할 수 있다는 사실이 점차 발견됩니다. 인터넷에 떠도는 정보들을 되돌아보면 솔직히 중국에는 정보도 거의 없고 국내 분위기도 그다지 강하지 않습니다. 국내 소프트웨어 중에는 예전 CLI와 snmp를 기반으로 하는 소프트웨어가 많으며, 여전히 업무용으로 텍스트 도구와 SSH 도구를 사용하고 있습니다. 그래서 나는 희망한다다른 사람들에게 낚시 방법을 가르치고 내 경험(구덩이)과 기술을 더 많은 네트워크 운영 및 유지 관리 엔지니어와 공유할 수 있습니다., 그리고 최선을 다하세요. Xiao Chu는 작업량을 줄이기 위해 무언가를 배울 수 있으며 먼 미래에 집중함으로써 국내 네트워크 운영 및 유지 관리가 진정으로 자동화를 향해 발전할 수 있다고 말했습니다.
앞으로는 동영상도 녹화하고 기사도 쓸 예정입니다. 문서를 작성한다는 건 정말 힘든 일인 것 같아요. 구독,수집,좋아요,시청 모두 환영합니다.
부록: Netconf 일반 작업
DWDM OTN 솔루션 설계 및 비용 견적, 저와 연결해 주세요, Taylor Huang
