컨피글렛

컨피글렛은 자동화된 패브릭 관리를 표준 참조 설계 이상으로 확장하는 벤더별 구성 템플릿입니다.

하나 이상의 발전기로 구성됩니다. 각 생성기는 NOS 유형(구성 스타일), 구성을 렌더링할 시기 및 CLI 명령(및 해당하는 경우 파일 이름)을 지정합니다. 구성 세트를 작성할 때 선택하는 섹션에 따라 구성이 렌더링되는 시기가 결정됩니다.

구성(configlet)을 사용하려면 글로벌 카탈로그에서 블루프린트 카탈로그로 구성(configlet)을 가져와 하나 이상의 역할 및/또는 배포된 디바이스에 할당합니다. 청사진 구성(Configlet)에서 역할 및/또는 디바이스를 편집할 수 있지만, 구성 요소 자체를 변경하려면 구성을 글로벌 카탈로그로 내보내고 수정한 다음 청사진으로 다시 가져와야 합니다.

엔터프라이즈 전체에서 동일한 구성 요소(configlet)를 사용할 수 있지만 대신 지역별 속성 세트 를 생성하고 적용하는 것이 좋습니다.

메모:

잘못 구성된 구성(configlet)은 경고나 제한을 발생시키지 않을 수 있습니다. 구성의 정확성을 테스트하고 검증하는 것은 최종 사용자의 책임입니다. 별도의 전용 서비스에서 구성(configlet)을 테스트하여 구성(configlet)이 의도한 대로 정확하게 작동하는지 확인하는 것이 좋습니다.

비밀번호와 기타 비밀 키는 컨피글렛에서 암호화되지 않습니다.

컨피글렛 애플리케이션

컨피글렛의 일부 응용 분야는 다음과 같습니다.

시스템 로그
SNMP 액세스 정책
TACACS / RADIUS
관리 ACL
컨트롤 플레인 폴리싱
NTP
사용자 이름/비밀번호

컨피글렛을 사용하지 말아야 하는 경우

주의:

구성 요소(configlet)를 사용하여 네이티브가 아닌 구성을 추가하는 것이 항상 적절하거나 가능한 것은 아닙니다. 컨피글렛은 강력하지만, 부적절하게 사용할 경우 구축 안정성과 레퍼런스 설계 기능 상호 작용에 위험을 초래할 수 있습니다. 구성의 정확성을 테스트하고 검증하는 것은 최종 사용자의 책임입니다.

라우팅 또는 연결과 같은 레퍼런스 설계 구성을 대체하기 위해 컨피글렛을 사용하지 마십시오. 인터페이스 구성을 변경할 경우, 인터페이스 구성 인텐트를 덮어쓸 수 있습니다. 예를 들어, 컨피글렛이 네트워크 범위 포트를 생성하는 경우 이 컨피글릿을 사용되지 않는 포트에 적용해야 하며, 그렇지 않으면 이미 사용 중인 포트를 실수로 덮어쓸 수 있습니다.

Cisco NX-OS 및 Arista EOS 디바이스에서는 입력할 수 없는 추가 비 ASCII 문자가 문제가 있으므로 구성 let을 사용하여 여러 줄 배너(예: 배너 motd)를 구성하지 마십시오. 대신 디바이스 에이전트를 설치하기 전에 Cisco POAP(Power-on Auto Provisioning) 또는 ZTP(Arista Zero Touch Provisioning)로 여러 줄로 구성된 배너를 구성합니다. 배너 구성은 디바이스의 원래 구성의 일부가 되며 구성 전체에 걸쳐 유지됩니다. 또 다른 옵션은 디바이스에 여러 줄 배너를 수동으로 구성하는 것입니다. 이 방법은 새 구성을 골든 구성으로 수락하여 해결할 수 있는 구성 편차 이상을 유발합니다. 자세한 내용은 구성 편차를 참조하십시오.

구성 요소 매개 변수

컨피글렛에는 다음과 같은 세부 정보가 포함됩니다. 선택한 구성 스타일(NOS 유형) 및 섹션에 따라 템플릿 텍스트, 부정 템플릿 텍스트 및 파일 이름이 필요한지 여부가 결정됩니다.

표 1: 구성 요소 매개 변수
이름	설명
컨피글렛 이름	컨피글렛을 식별하기 위한 고유한 이름(64자 이하)
구성 스타일(NOS 유형)	Junos, NX-OS, EOS, SONiC
섹션: 시스템 (NX-OS, EOS, SONiC) 섹션: 최상위 수준: 계층적(이전에는 시스템이라고 불림)(Junos)	루트 사용자로 명령을 실행합니다. 부적절한 변경은 레퍼런스 설계의 기능을 손상시키고 네트워크를 중단시킬 수 있습니다. 디바이스가 노드에서 할당 해제되면 부정 템플릿 텍스트가 구성을 제거합니다. 예를 들어, 템플릿 텍스트가 `username example privilege 15 secret 0 MyPassword`인 경우 부정 템플릿 텍스트는 다음과 같을 수 있습니다 no username example 파일 구성(configlet)과 함께 사용하여 파일을 다시 시작하거나 파일 구성(File configlet)이 렌더링된 후 관리 작업을 수행할 수 있습니다. 시스템 구성은 다른 구성을 중첩할 수 있습니다. NX-OS 및 EOS의 경우, 적절한 구성 터미널 컨텍스트가 적용됩니다. 구성 요소의 일부가 될 필요는 없습니다.
섹션: 최상위 수준: 설정/삭제 (Junos)	구조화된 JSON이 아닌 주니퍼 "설정" 스타일을 사용하여 컨피글렛 작성
섹션: 인터페이스 (NX-OS, EOS) 섹션: 인터페이스 수준: 계층적 (Junos)	물리적 디바이스 전용. 구성을 청사진(범위)으로 가져올 때 인터페이스를 지정합니다.
섹션: 인터페이스 수준: 설정 (Junos)	구조화된 JSON 대신 주니퍼 "설정" 명령을 사용하여 구성(configlet)을 작성합니다. 텍스트는 'set'으로 시작하도록 검증됩니다.
섹션: 인터페이스 수준: 삭제 (Junos)	구조화된 JSON 대신 주니퍼 "삭제" 명령을 사용하여 구성(configlet)을 작성합니다. 텍스트는 'delete'로 시작하도록 검증됩니다.
섹션: 파일 (SONiC)	전체 파일을 덮어쓰기 때문에 파일의 전체 내용은 구성 요소 내에 있어야 합니다. 원본 파일 내용의 버전 관리 또는 저장이 없으므로 원본 내용으로 복원할 수 없습니다. 부적절하게 사용하면 네트워크가 다운될 수 있습니다. 중요한 프로세스의 구성 파일(예 `/etc/frr/frr.conf` : 또는 `/etc/network/interfaces/`)에는 사용하지 마십시오. 내용은 루트 사용자 `/etc` 로 디렉터리 파일에 기록됩니다(Docker 컨테이너 호스트 마운트로 인해). 외부의 파일에 `/etc` 쓰려면(`/usr` 예를 들어) 파일 구성렛을 빌드한 다음 나중에 시스템 구성렛을 사용하여 파일을 이동합니다.
섹션: 시스템 최상위(NX-OS, EOS)	프로그래밍된 인텐트를 구현하기 위해 설정을 덮어쓸 수 있는지 확인합니다. 레퍼런스 설계를 적용하면 이 구성 요소에서 "꺼진" 모든 필요한 기능이 다시 활성화됩니다.
섹션: FRR(SONiC)	구성let 구성은 생성된 `/etc/frr/frr.conf` 파일의 끝에 추가되며 FRR 인텐트의 일부가 됩니다. 구성은 frr-reload에 점진적으로 포함됩니다. 템플릿 텍스트가 유효성이 검사되지 않습니다. 오류로 인해 구축 오류, 의도하지 않은 구성 및 디바이스 영향이 발생할 수 있습니다.
템플릿 텍스트	디바이스에 구성을 추가하기 위한 CLI 명령. 검증 없이 디바이스에 직접 발급됩니다.
부정 템플릿 텍스트	구성 요소 기능을 비활성화하기 위한 CLI 명령(디바이스가 할당 해제된 경우). 검증 없이 디바이스에 직접 발급됩니다.
파일	파일 구성의 경우

구성 렌더링 순서

구성 렌더링 순서는 다음과 같습니다.

시스템 상단: 부정 템플릿 텍스트(NX-OS, EOS)
시스템 상단: 템플릿 텍스트(NX-OS, EOS)
레퍼런스 설계
인터페이스: 부정 템플릿 텍스트(Junos, NX-OS, EOS)
시스템: 부정 템플릿 텍스트(Junos, NX-OS, EOS, SONiC)
파일(SONiC)
시스템: 템플릿 텍스트(Junos, NX-OS, EOS, SONiC)
인터페이스: 템플릿 텍스트(Junos, NX-OS, EOS)

섹션 내 작업 순서를 제어하려면 숫자 이름으로 구성(configlet)을 생성합니다. 예를 들어, 01_syslog 02_ntp. 그런 다음 구성 요소의 상태(예: 스파인 또는 리프 역할)에 따라 구성 요소의 순서가 지정된 다음 구성 요소의 노드 ID에 따라 정렬됩니다.