네트워크 인프라를 제어하는 ​​방법. XNUMX장. 청소 및 문서화

이 기사는 "네트워크 인프라를 제어하는 ​​방법" 시리즈 기사 중 두 번째 기사입니다. 시리즈의 모든 기사 내용과 링크를 확인할 수 있습니다. 여기에.

이 단계의 목표는 문서화 및 구성을 질서있게 만드는 것입니다.
이 프로세스가 끝나면 필요한 문서 세트와 그에 따라 구성된 네트워크가 있어야 합니다.

이제 우리는 보안 감사에 대해 이야기하지 않을 것입니다. 이것은 세 번째 부분의 주제가 될 것입니다.

물론 이 단계에서 할당된 작업을 완료하는 어려움은 회사마다 크게 다릅니다.

이상적인 상황은 다음과 같습니다.

• 귀하의 네트워크는 프로젝트에 따라 생성되었으며 완전한 문서 세트를 보유하고 있습니다.
• 귀하의 회사에서 구현되었습니다 변경 제어 및 관리 프로세스 네트워크용
• 이 프로세스에 따라 현재 상황에 대한 완전한 정보를 제공하는 문서(필요한 모든 다이어그램 포함)가 있습니다.

이 경우 작업은 매우 간단합니다. 문서를 연구하고 변경된 모든 사항을 검토해야 합니다.

최악의 시나리오에서는 다음과 같은 상황이 발생합니다.

• 충분한 자격을 갖추지 못한 엔지니어들에 의해 프로젝트, 계획, 승인 없이 생성된 네트워크,
• 혼란스럽고 문서화되지 않은 변경 사항, 많은 "쓰레기" 및 차선책이 있는 솔루션

귀하의 상황이 그 사이 어딘가에 있다는 것은 분명하지만 불행하게도 이 정도의 더 나은 수준에서 더 나쁜 경우에는 최악의 끝에 가까워질 가능성이 높습니다.

이 경우 "디자이너"가 원하는 것이 무엇인지 이해하고, 논리를 복원하고, 완료되지 않은 작업을 완료하고, "쓰레기"를 제거하는 방법을 배워야 하기 때문에 마음을 읽는 능력도 필요합니다.
그리고 물론 실수를 수정하고 (이 단계에서는 가능한 한 최소한으로) 디자인을 변경하고 계획을 변경하거나 다시 만들어야 합니다.

이 기사는 결코 완전하다고 주장하지 않습니다. 여기서는 일반적인 원칙만 설명하고 해결해야 할 몇 가지 일반적인 문제에 중점을 둘 것입니다.

문서 세트

예부터 시작해 보겠습니다.

다음은 설계 과정에서 Cisco Systems에서 관례적으로 생성한 일부 문서입니다.

CR – 고객 요구 사항, 클라이언트 요구 사항(기술 사양).
이는 고객과 공동으로 생성되며 네트워크 요구 사항을 결정합니다.

HLD – 상위 수준 설계(High Level Design), 네트워크 요구 사항(CR)을 기반으로 한 상위 수준 설계. 이 문서는 아키텍처 결정(토폴로지, 프로토콜, 하드웨어 선택 등)을 설명하고 정당화합니다. HLD에는 사용된 인터페이스 및 IP 주소와 같은 설계 세부 정보가 포함되어 있지 않습니다. 또한 여기서는 특정 하드웨어 구성에 대해 설명하지 않습니다. 오히려 이 문서는 고객의 기술 관리에 대한 주요 설계 개념을 설명하기 위한 것입니다.

LLD – 로우 레벨 디자인(Low Level Design), 하이 레벨 디자인(HLD)을 기반으로 한 로우 레벨 디자인.
여기에는 장비 연결 및 구성 방법에 대한 정보 등 프로젝트를 구현하는 데 필요한 모든 세부 정보가 포함되어야 합니다. 이것은 디자인 구현에 대한 완전한 가이드입니다. 이 문서는 자격이 부족한 인력이라도 구현에 필요한 충분한 정보를 제공해야 합니다.

예를 들어 IP 주소, AS 번호, 물리적 전환 방식(케이블 연결) 등은 다음과 같은 별도의 문서에 "제출"될 수 있습니다. PIN (네트워크 구현 계획).

네트워크 구축은 이러한 문서가 작성된 후에 시작되며 문서를 엄격히 준수하여 수행되며 그런 다음 고객이 설계 준수 여부를 확인(테스트)합니다.

물론, 다양한 통합업체, 고객, 국가마다 프로젝트 문서화에 대한 요구 사항이 다를 수 있습니다. 그러나 나는 형식적인 것을 피하고 그 문제의 장점을 고려하고 싶습니다. 이 단계는 디자인이 아니라 물건을 정리하는 단계이며 작업을 완료하려면 충분한 문서 세트(다이어그램, 표, 설명...)가 필요합니다.

그리고 제 생각에는 절대적인 최소치가 있으며, 그것 없이는 네트워크를 효과적으로 제어하는 ​​것이 불가능합니다.

다음 문서들이 있습니다:

• 물리적 스위칭(케이블 연결) 다이어그램(로그)
• 필수 L2/L3 정보가 포함된 네트워크 다이어그램 또는 다이어그램

물리적 스위칭 다이어그램

일부 소규모 회사에서는 장비 설치 및 물리적 스위칭(케이블 연결)과 관련된 작업이 네트워크 엔지니어의 책임입니다.

이 경우 문제는 다음 접근 방식으로 부분적으로 해결됩니다.

• 인터페이스에 대한 설명을 사용하여 인터페이스에 연결된 내용을 설명합니다.
• 연결되지 않은 모든 네트워크 장비 포트를 관리적으로 종료

이렇게 하면 링크에 문제가 있는 경우(cdp 또는 lldp가 이 인터페이스에서 작동하지 않는 경우)에도 이 포트에 무엇이 연결되어 있는지 빠르게 확인할 수 있는 기회가 제공됩니다.
또한 새로운 네트워크 장비, 서버 또는 워크스테이션의 연결을 계획하는 데 필요한 포트가 사용되고 있는지 쉽게 확인할 수 있습니다.

그러나 장비에 대한 접근 권한을 잃으면 이 정보에 대한 접근 권한도 잃게 된다는 점은 분명합니다. 또한 이 방법으로는 어떤 종류의 장비, 어떤 전력 소비, 얼마나 많은 포트가 있는지, 어떤 랙에 있는지, 어떤 패치 패널이 있는지, 어디에 있는지(어떤 랙/패치 패널에 있는지)와 같은 중요한 정보를 기록할 수 없습니다. ) 그들은 연결되어 있습니다. 따라서 장비에 대한 설명뿐만 아니라 추가 문서도 여전히 매우 유용합니다.

이상적인 옵션은 이러한 유형의 정보를 처리하도록 설계된 응용 프로그램을 사용하는 것입니다. 그러나 간단한 테이블(예: Excel)로 제한하거나 필요하다고 생각되는 정보를 L1/L2 다이어그램에 표시할 수 있습니다.

중요!

물론 네트워크 엔지니어는 SCS의 복잡성과 표준, 랙 유형, 무정전 전원 공급 장치 유형, 냉복도와 열기 통로가 무엇인지, 적절한 접지 방법 등을 아주 잘 알 수 있습니다. 기본 입자 또는 C++의 물리학을 알고 있습니다. 그러나 이 모든 것이 그의 지식 영역이 아니라는 것을 여전히 이해해야 합니다.

따라서 장비의 설치, 연결, 유지 관리 및 물리적 전환과 관련된 문제를 해결하기 위해 전담 부서나 전담 인력을 두는 것이 좋습니다. 일반적으로 데이터 센터의 경우 데이터 센터 엔지니어이고 사무실의 경우 헬프 데스크입니다.

회사에 이러한 분할이 제공되는 경우 물리적 전환 로깅 문제는 귀하의 작업이 아니며 인터페이스에 대한 설명과 사용하지 않는 포트의 관리 종료로만 제한할 수 있습니다.

네트워크 다이어그램

다이어그램을 그리는 데에는 보편적인 접근 방식이 없습니다.

가장 중요한 것은 다이어그램을 통해 네트워크의 논리적, 물리적 요소를 통해 트래픽이 어떻게 흐르는지에 대한 이해를 제공해야 한다는 것입니다.

물리적 요소란 다음을 의미합니다.

• 활성 장비
• 활성 장비의 인터페이스/포트

논리 아래 -

• 논리 장치(N7K VDC, Palo Alto VSYS, ...)
• VRF
• 빌란스
• 하위 인터페이스
• 터널
• 지역
• ...

또한 네트워크가 완전히 기본이 아닌 경우 다양한 세그먼트로 구성됩니다.
예를 들면

• 데이터 센터
• 인터넷
• WAN
• 원격 액세스
• 사무실 LAN
• DMZ
• ...

큰 그림(이러한 모든 세그먼트 간의 트래픽 흐름 방식)과 각 개별 세그먼트에 대한 자세한 설명을 모두 제공하는 여러 다이어그램을 갖는 것이 현명합니다.

최신 네트워크에는 많은 논리 계층이 있을 수 있으므로 서로 다른 계층에 대해 서로 다른 회로를 만드는 것이 아마도 좋은(필수는 아니지만) 접근 방식일 수 있습니다. 예를 들어 오버레이 접근 방식의 경우 다음과 같은 회로가 될 수 있습니다.

• 오버레이
• L1/L2 언더레이
• L3 언더레이

물론 디자인 아이디어를 이해하는 것이 불가능한 가장 중요한 다이어그램은 라우팅 다이어그램입니다.

라우팅 방식

최소한 이 다이어그램은 다음을 반영해야 합니다.

• 어떤 라우팅 프로토콜이 사용되며 어디에 사용됩니까?
• 라우팅 프로토콜 설정에 대한 기본 정보(지역/AS 번호/라우터 ID/…)
• 어떤 장치에서 재배포가 발생합니까?
• 필터링 및 경로 집계가 발생하는 곳
• 기본 경로 정보

또한 L2 체계(OSI)가 유용한 경우가 많습니다.

L2 체계(OSI)

이 다이어그램에는 다음 정보가 표시될 수 있습니다.

• 어떤 VLAN
• 어떤 포트가 트렁크 포트인지
• 어떤 포트가 이더넷 채널(포트 채널), 가상 포트 채널로 통합되는지
• 어떤 STP 프로토콜이 사용되며 어떤 장치에서 사용됩니까?
• 기본 STP 설정: 루트/루트 백업, STP 비용, 포트 우선순위
• 추가 STP 설정: BPDU 가드/필터, 루트 가드…

일반적인 디자인 실수

네트워크 구축에 대한 잘못된 접근 방식의 예입니다.

간단한 사무실 LAN을 구축하는 간단한 예를 들어보겠습니다.

학생들에게 통신을 가르친 경험이 있기 때문에 XNUMX학기 중반에는 사실상 모든 학생이 간단한 사무실 LAN을 설정하는 데 필요한 지식(내가 가르친 과정의 일부로)을 갖추고 있다고 말할 수 있습니다.

스위치 상호 연결, VLAN 설정, SVI 인터페이스(L3 스위치의 경우) 설정, 정적 라우팅 설정이 뭐가 그렇게 어렵나요?

모든 것이 작동합니다.

그러나 동시에 이와 관련된 질문은 다음과 같습니다.

• 보안
• 예약
• 네트워크 확장
• 생산력
• 처리량
• 신뢰성
• ...

때때로 나는 사무실 LAN이 매우 단순한 것이라는 말을 듣습니다. 일반적으로 네트워크 이외의 모든 일을하는 엔지니어 (및 관리자)로부터 이런 말을 듣습니다. 그들은 LAN이 놀라지 않을 정도로 자신있게 말합니다. 연습과 지식이 부족한 사람들이 만든 것이며 아래에 설명할 것과 거의 같은 실수를 저지르게 될 것입니다.

일반적인 L1(OSI) 설계 실수

• 그럼에도 불구하고 귀하가 SCS에 대한 책임도 갖고 있다면 귀하가 받게 될 가장 불쾌한 유산 중 하나는 부주의하고 잘못된 전환입니다.

또한 사용된 장비의 자원과 관련된 유형 L1 오류로 분류하겠습니다. 예를 들어,

• 대역폭이 부족함
• 장비에 대한 TCAM 부족(또는 비효율적 사용)
• 성능 부족(종종 방화벽과 관련됨)

일반적인 L2(OSI) 설계 실수

STP의 작동 방식과 이로 인해 발생하는 잠재적인 문제에 대해 잘 이해하지 못하는 경우 스위치는 추가 STP 조정 없이 기본 설정으로 혼란스럽게 연결되는 경우가 많습니다.

결과적으로 우리는 종종 다음과 같은 상황을 겪습니다.

• 브로드캐스트 폭풍으로 이어질 수 있는 큰 STP 네트워크 직경
• STP 루트는 무작위로 결정되며(mac 주소를 기준으로) 트래픽 경로는 최적이 아닙니다.
• 호스트에 연결된 포트는 에지(portfast)로 구성되지 않으므로 최종 스테이션을 켜거나 끌 때 STP가 다시 계산됩니다.
• 네트워크는 L1/L2 레벨에서 분할되지 않습니다. 그 결과 스위치에 문제(예: 전력 과부하)가 발생하면 STP 토폴로지가 다시 계산되고 모든 스위치의 모든 VLAN에서 트래픽이 중지됩니다(예: 연속성 서비스 부문의 관점에서 중요한 것)

L3(OSI) 설계 실수의 예

초보 네트워크 사용자의 몇 가지 일반적인 실수:

• 정적 라우팅을 자주 사용(또는 사용만)
• 특정 설계에 대해 최적이 아닌 라우팅 프로토콜 사용
• 최적이 아닌 논리적 네트워크 분할
• 경로 집계를 허용하지 않는 주소 공간의 차선적인 사용
• 백업 경로 없음
• 기본 게이트웨이 예약 없음
• 경로 재구축 시 비대칭 라우팅(NAT/PAT, 상태 저장 방화벽의 경우 중요할 수 있음)
• MTU 문제
• 경로가 재구축되면 트래픽은 다른 보안 영역이나 심지어 다른 방화벽을 통과하므로 이 트래픽이 삭제됩니다.
• 열악한 토폴로지 확장성

설계 품질 평가 기준

최적성/비최적성에 관해 이야기할 때, 이를 어떤 기준으로 평가할 수 있는지 관점에서 이해해야 합니다. 내 관점에서 볼 때 가장 중요한(전부는 아니지만) 기준(및 라우팅 프로토콜과 관련된 설명)은 다음과 같습니다.

• 확장성
  예를 들어 다른 데이터 센터를 추가하기로 결정했습니다. 얼마나 쉽게 할 수 있나요?
• 사용 용이성(관리성)
  새로운 그리드를 발표하거나 경로를 필터링하는 등 운영 변경이 얼마나 쉽고 안전합니까?
• 유효성
  시스템이 필요한 서비스 수준을 제공하는 시간은 몇 퍼센트입니까?
• 보안
  전송된 데이터는 얼마나 안전합니까?
• 가격

변경 사항

이 단계의 기본 원칙은 “해를 끼치지 말라”는 공식으로 표현될 수 있습니다.
따라서 설계 및 선택한 구현(구성)에 완전히 동의하지 않더라도 항상 변경하는 것이 권장되는 것은 아닙니다. 합리적인 접근 방식은 두 가지 매개변수에 따라 식별된 모든 문제의 순위를 지정하는 것입니다.

• 이 문제를 얼마나 쉽게 해결할 수 있나요?
• 그녀는 얼마나 많은 위험을 감수합니까?

우선, 현재 제공되는 서비스 수준을 수용 가능한 수준 이하로 낮추는 요인, 예를 들어 패킷 손실을 초래하는 문제를 제거하는 것이 필요합니다. 그런 다음 위험 심각도가 낮은 순서로(고위험 설계 또는 구성 문제부터 저위험 문제까지) 수정하기 가장 쉽고 안전한 것을 수정합니다.

이 단계의 완벽주의는 해로울 수 있습니다. 설계를 만족스러운 상태로 만들고 이에 따라 네트워크 구성을 동기화합니다.

출처 : habr.com