안녕하세요.
이번 포스팅은 간단한 동영상으로 올려봅니다.
앞으로 포스팅을 위해서 준비 중인(?) ACI와 관련한 간단한 동영상입니다.
ACI에서 EPG를 생성하고, Contract을 생성하고, Contract을 맺어주기 위한 작업을 JSON을 통해서 진행을 하는 내용입니다.
다만, JSON을 생성하는 것을 EPG와 Contract를 변수로 하여,
Ansible을 통해서 변수로 지정된 EPG와 Contract을 생성 및 연결하는 JSON을 생성하고 이를 통해서 ACI에 적용합니다.
JSON을 수동으로 변경해서 만드는 것에 비해서 잘못 수정할 부분이나,
보다 많은 부분에 적용해야 하는 경우가 발생하는 경우에 조금 유용하게 사용할 수 있지 않을까 싶습니다.
물론 이 방법 이외에도 추가적으로 보다 유연하고 편리하게 사용하게 사용하기 위한 방법들에 대해서는 고민 중입니다.
Cisco Nexus에서 ACL 적용과 관련한 간단한 내용 공유입니다.
ACL에 필요한 Rule을 설정한 이후에 정상적으로 ACL을 통해서 Permit 되거나, Deny 되었는지
각 ACL Rule을 통과되었는지를 확인하기 위해서
show ip access-list ACL_Name |
명령을 통해서 Rule에 매치된 Count를 확인을 할 수 있는 데,
NX-OS에서는 저렇게만 하면, ACL Rule에 매치된게 있는지 확인이 안됩니다.
기존처럼 Rule 매치된 Count를 확인하기 위해서는 ACL 설정 시에,
statistics per-entry 명령을 추가로 해야 합니다.
기본 설정은 no statistics per-entry로 비활성화 상태이기 떄문에 ACL에 매치된 Rule의 Count를 확인할 수 없습니다.
switch(config-acl)# statistics per-entry |
안녕하세요. 이번 포스팅은 정보 공유 포스팅입니다.
Cisco ACI의 Dashboard에 대한 내용입니다.
요즘은 많은 벤더의 장비들이 그러하듯이 Cisco ACI도 REST-API나, SDK를 사용하여 다양한 것들을
추가적으로 구현하여 사용이 가능합니다.
#앞으로 6월에 진행될 네트워크 전문가 따라잡기 커뮤니티의 N.EX.T에서도 관련 세션을 발표할려고 생각중입니다! ^^
Cisco Korea에서는 이러한 프로그래머빌리티를 위해서 시스코 본사의 Github이외에
Cisco Korea의 Git(https://github.com/CiscoKorea)을 운영하고 있는 데,
오늘은 그 Github에 공유 중인 ACI Dashboard에 대해서 간단히 살펴봅니다. ^^
ACI Dashboard로 공개되어 있는 오픈소스 프로젝트는 Webkit과 archon이 있는 데,
archon이 신 버전, Webkit이 구 버전이라고 보시면 됩니다.
우선 webkit과 archon 모두 설치해서 돌려보기는 했으나, 아래의 화면은 archon입니다. ^^
설치 방법은 Cisco Korea git에서 확인하시면 되시구요. (https://github.com/CiscoKorea/archon)
대시보드를 실행하면 아래와 같이 로그인 화면이 뜨게 됩니다. (물론 초기에는 Cisco 로고가 나옵니다.)
로그인을 하고나면, 아래와 같이 메뉴를 고를 수 있는 데,
ACI에 대한 메뉴와, ASA 그리고 Sample이라고 되어 있는 부분이 있는 데,
Sample이라고 되어 있는 부분은 NX-OS에 대한 부분이 채워질 예정이라고 합니다.
ACI Dashboard로 들어가면, 초기 개요 화면이 있으며,
추가적으로 상태, 관계도, 점검, 분석, 도구 등의 메뉴가 있습니다.
아래는 초기 개요 화면입니다 .
현재 도메인(APIC 기준입니다.)에 대한 전체 정보가 뜨고, 각 상태 정보를 한 눈에 볼 수 있습니다.
기타 다른 메뉴들을 눌러보면, 이런 저런 대시보드에 대한 기능들이 존재합니다.
기존 버전인 Webkit과 UI가 바뀐 부분 말고 대부분의 기능으 대동소이 한 것 같습니다.
우선 ACI에서 흩어져서 볼 수 있는 내용들을 한 눈에 보기 쉽게 해 놓은 부분들도 있어서 좋습니다.
물론.. 메뉴를 눌러보다 보면.. 그래서 이걸 어디에 쓰지? 라는.. 생각이 문득 들기도 합니다.
제일 좋은 건, 특정 Endpoint에 대한 정보를 검색해서 찾을 수 있다는 것?
물론 APIC에 직접 접속해서 확인도 가능하고, APIC에서 찾아보는게 보다 많은 정보를 볼 수 있겠지만
그래도 Dashboard에서 손쉽고 빠르게 찾아볼 수 있는 점은 장점인 듯 싶습니다.
물론 운영자 입장에서의 100% 입맛에 맞추기는 어렵겠지만,
결국 이러한 도구들처럼, 필요한 부분들을 개발해서 사용할 수 있는 오픈 환경이 제공되어 진다는 점이
현재의 트렌드이자.. 앞으로 나아가는 방향 중에 하나가 아닐까 싶습니다.
안녕하세요
이번 포스팅은 지난 번에 했던 포스팅과 마찬가지로 간단한 동영상을 올려봅니다.
Cisco ACI에서 포트설정은 Profile 형태로 구성을 하게 되는 데,
PortProfile을 생성하는 것을 JSON을 이용해서 Post하기 위한 예제입니다.
동영상의 내용은, 동일한 PortProfile 그룹과 거기에 설정할 AEP를 지정하고
그리고 각 인터페이스 별로 설정할 Port정보를 기입하여, ACI에 적용할 JSON을 생성한 후, ACI에 적용하게 되는 동영상입니다.
좀 더 많은 부분은 한꺼번에 JSON 형태로 만들어서 Profile을 만들고 싶은 생각은 있지만..
아무래도 실 운영 환경에서 테스트를 진행하는 부분에는 한계점이 있기 때문에..
가상머신이나. 에뮬레이터가.. 절실하다는.. 생각을 해보면서 포스팅을 마칩니다.
P.S 물론 본 동영상에 포함된 Profile 형태가 물론 ACI에서 하고자 하는 아키텍처의 그림은 아닐 수 있겠지만.
위와 같은 형태의 자동화 부분도 가능하다는 점만 염두해두면 좋을 것 같습니다.
안녕하세요.
이번 포스팅은 기존에 진행하던 Programmabiliy for Networker 라는 주제의 포스팅을..
다시 오랜만에 재개하기 위한 사전 동영상 포스팅입니다.
아래의 동영상은 Access-list를 관리하기 위한 방법으로 작성한 코드입니다.
차단하기 위한 별도의 IP리스트 파일을 관리를 하여,
기존의 있는 Access-list에 해당 파일에 있는 IP를 차단하는 역할을 해줍니다.
또한 이력관리를 위해서 앞에 Access-list Numbering을 ACL이 추가되는 현재의 날짜와 그 날의 순번대로 작성됩니다.
즉, 2017년 5월 1일에 작성되는 ACL의 경우에는 1705010000, 1705010001 과 같이 Accesss-list가 만들어집니다.
개인적으로 진행하는 스터디에서 다뤄질 소모임이기도 하고...
공부를 위한 부분이기도 하고..
6월에 진행되는 네전따 커뮤니티 세미나 발표를 위한 부분이기도 하고..
업무를 위해서 필요한 부분이기도 할...
Programmability for Networker 포스팅이.. 곧 다시.. 재개합니다. ^^
.
Keyword : netmiko, paramiko, ssh, python, programmability, automation, network, 자동화, 프로그래머빌리티
Programmability for Networker를 새롭게 시작하는 포스팅입니다. ^^; 지난번 Part에 이어서 Part 22부터 시작입니다.
당분간 진행하는 부분이 예전에 진행을 하면서 사용했던 부분이긴 하지만,
Netmiko라는 멀티벤더에서 손쉽게 Paramiko SSH를 사용할 수 있도록 해주는 라이브러리로 진행을 하게 될 예정이라서,
먼저 Netmiko 라이브러리를 설치하는 것으로 가볍게 시작해봅니다.
Netmiko
Multi-vendor library to simplify Paramiko SSH connections to network devices
* 관련 링크 : https://github.com/ktbyers/netmiko
○ Python 버전
Python 2.7, 3.4, 3.5
○ 지원되는 장비
Paramiko >= 1.13+
scp >= 0.10.0
pyyaml
pytest(for unit tests)
※ Paramiko - Python SSH 모듈 |
○ 지원되는 장비
- Regularly tested
Arista vEOS / Cisco ASA / Cisco IOS / Cisco IOS-XE / Cisco IOS-XR / Cisco NX-OS / Cisco SG300
HP Comware7 / HP ProCurve / Juniper Junos / Linux
- Limited tested
Avaya ERS / Avaya VSP / Brocade VDX / Brocade ICX,FastIron / Brocade MLX,NetIron / Cisco WLC
Dell-Force10 DNOS9 / Dell PowerConnect / Huawei / Mellanox / Palo Alto PAN-OS / Pluribus / Vyatta VyOS
- Experimental
A10 / Alcatel-Lucent SR-OS / Ciena SAOS / Cisco Telepresence / CheckPoint Gaia / Enterasys / Extreme
F5 LTM / Fortinet
○ 설치 방법
- Netmiko의 설치방법은 아래의 페이지에 안내되어 있지만, 실패하실 수 있습니다.
* https://pynet.twb-tech.com/blog/automation/netmiko-tools.html
설치 시에 아래와 같은 에러메시지를 만날 수도 있습니다.
-
혹시 설치에 실패를 하게 되면, 아래와 같이 설치를 진행하시면 됩니다. (Cent OS 7.3 기준입니다)
rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm yum install python-dev pip install netmiko |
Today Keys : ACI, App, Apps, 앱, Cisco
ACI Apps 소개
<제일 우측이 새롭게 추가된 메뉴인 Apps 입니다>
Apps로 들어가게 되면, 마치 Application 오픈마켓처럼 ACI에 추가할 수 있는 Application을 다운받을 수 있습니다.
원하는 Application을 설치하게 되면, Apps 안에 다음과 같이 Application이 추가로 내장되게 됩니다.
ACI에 또 다른 기능을 위해서 별도의 프로그램이나 사이트에 접속할 필요 없이 바로 ACI에서 볼 수 있게 되는 것입니다.
그림 메뉴로 선택할 수도 있지만, 다음과 같이 Apps를 볼 수도 있습니다.
실제 Apps를 실행하게 되면, Apps 내의 Tab에서 보여지거나, 특정 위치에 메뉴가 추가로 생기게 됩니다.
제가 설치한 Visualization Dashboard는 Apps 메뉴 내에서 보여지게 되는데,
각 인터페이스의 사용량에 따른 Top 10 을 본다던가,
혹은 아래와 같은 EPG 정보를 볼 수도 있습니다. 그 밖에 Tenant라든가, Contract 정보들도 Dashboard 형태로
ACI 내에서 볼 수 있습니다.
다른 App인 Contract Viewer은 Tenant 메뉴 내에 추가로 메뉴가 생성되어 아래와 같이 보여지게 됩니다.
해당 Tenant 에 속한 EPG와 Contract의 연결고리를 그래픽으로 알아보기 쉽게 볼 수 있습니다 .
이외에도 몇 개의 App이 추가로 있지만, 우선 2가지만 설치해 보았습니다.
Apps의 경우에는 위에서도 계속 얘기했지만, ACI 안에 추가 기능으로 들어가기 때문에 별도의 View를 보기 위해서
다른 프로그램이나 웹을 이용하지 않아도 된다는 큰 장점을 가지고 있습니다.
하지만, 사용할 수 있는 App이 무척이나 적습니다.
(하지만 위에 소개한 2개의 App만으로도 충분히 활용가치는 있을 것 같습니다.)
개발자 센터를 운영하면서, 다양한 App 생태계를 만드는 것이 가장 좋겠지만,
실질적으로 엄청나게 많은 App이 양산되기는 쉽지 않을 것 같습니다.
다만, 현재 App과 같이 실질적으로 운영 관점에서 필요한 사항에 대해서는 시스코에서만이라도 추가적인 App을 만든다면
다른 솔루션에 비해서 굉장히 좋은 강점을 가질 수 있을 것 같습니다.
지난 주 토요일(6월 10일)에 광화문에 있는 한국 Microsoft 에서
제 22회 네트워크 전문가 따라잡기 'N.EX.T' 행사를 진행했습니다.
전체적인 행사 준비와 함께.. 마지막 세션에서 'Programmable Network'라는 주제로 세션을 진행했습니다.
당일 발표된 내용 중에 많은 장수는 살짝 빠졌지만 당일 진행된 전체 흐름에는 큰 영향은 없습니다.
(내용과 함께 듣지 않으면 큰 의미가 없던 이미지라..)
세션에서 진행된 Code에 대한 부분은 앞으로의 포스팅에서 차츰 공개될 예정입니다.
Today Keys : Programmable, config, 프로그래머블, 백업, netmiko, programmability, networker, network
이번 포스팅은 다시 시작하는 Programmability for Networker의 23번째 포스팅입니다.
이번 내용은 장비의 Configuration을 백업해주는 코드입니다.
주기적으로 반복해서 수행되는 장비 백업 작업에 대해서 손쉽게 코드로 해결해 줄 수 있습니다.
이 포스팅에서는 앞 포스팅에서 소개한 netmiko 라이브러리를 사용하였고, Cisco 장비에 대해서만 진행했습니다.
하지만 유사한 방식으로 다른 장비들도 손쉽게 구현이 가능할 것입니다.
netmiko에서 지원되는 다양한 네트워크 장비들도 거의 동일한 방법으로 구현이 가능합니다.
물론 멀티벤더에 대한 부분들도 코드를 나눠서도 할 수 있겠지만, 하나의 코드에서 장비 벤더를 구분해서 코드를
실행하도록 할 수도 있을 것입니다.
하지만, 우선 시작하는 단계에서는 조금 더 쉽고 최대한 코드를 나눠서 연습해가며 진행을 하신다면 좋을 것 같습니다.
아래의 코드는 별도의 파일에서 지정된 네트워크 장비 목록을 지정하고,
해당 목록의 모든 장비의 Configuration을 Text파일로 백업해주는 역할을 하게 됩니다.
아래의 코드를 Linux에서 크론탭으로 돌리거나, Windows의 스케쥴러를 이용하시면, 간단하게 정기적으로
장비의 Configuration을 백업 받으실 수 있습니다.
[ Config Backup ]
import device from netmiko import ConnectHandler for dev in device.ZIGI_devices: nwnode = ConnectHandler(**dev) hostname = nwnode.send_command("show hostname") print("Collecting {0}Device Running Coning".format(hostname)) run_config = nwnode.send_command("show running") print("Collect Complete") filename = "c:\\backup\\" + hostname + "-" + backupdate + '.log' print("Saving configuration file") configFile = open(filename,'w') configFile.write(run_config) print("{0}Device Configuration Backup complete".format(hostname)) configFile.close() |
nwnode = ConnectHandler(**dev)
▷ 별도의 파일에 백업하고 싶은 장비의 목록을 지정해놓고, 순환문을 이용해서 장비 정보를 불러오게 됩니다.
현재 백업하고자 하는 장비를 가져오는 부분입니다.
hostname = nwnode.send_command("show hostname")
▷ 현재 장비의 hostname을 가져오는 부분입니다. 'show hostname' 명령어를 이용해서 hostname을 변수에
저장하게 하게 됩니다.
run_config = nwnode.send_command("show running")
▷ show running config 명령으로 전체 config를 가져와서 변수에 저장합니다.
filename = "c:\\backup\\" + hostname + "-" + backupdate + '.log'
▷ 파일을 저장하고 싶은 폴더에 파일명을 hostname과 백업 날짜를 해서, 텍스트 파일 형태로 이름을 지정합니다.
여기에서는 backupdate라고 적혀있는 변수는 현재 날짜를 갖고 있는 변수라고 생각하시면 됩니다.
현재 시스템 날짜를 가져와서 변수에 넣어서 사용하시면 됩니다.
configFile = open(filename,'w')
▷ 파일을 저장하기 위해서 file객체를 열고
configFile.write(run_config)
▷ running config 내용을 파일에 쓰게 됩니다.
configFile.close()
▷ 마지막으로 파일 객체를 닫습니다.
위와 같은 동작을 전체 장비 리스트를 다 백업할 때까지 반복하게 됩니다.
아래의 코드는 실제 장비 리스트를 관리하는 파일입니다.
계정은 공통 변수로 사용을 하게 되고, 각 장비의 이름과 ip를 지정해 놓았습니다.
[ device.py ]
user1='admin' pass1=‘zigipass' dv='cisco_nxos' CoreSW1={'device_type':dv,'verbose':False,'username':user,'password':pass,'ip':'10.0.0.1'} CoreSW2={'device_type':dv,'verbose':False,'username':user,'password':pass,'ip':'10.0.0.2'} ExtSW1={'device_type':dv,'verbose':False,'username':user,'password':pass,'ip':'10.0.0.3'} ExtSW2={'device_type':dv,'verbose':False,'username':user,'password':pass,'ip':'10.0.0.4'} ZIGI_devices = [CoreSW1,CoreSW2,ExtSW1,ExtSW2] |
Today Keys : cisco, aci, apic, python, package, sdk, cobra, programming, programmable, automation, installation
Cisco APIC Python SDK은 'cobra'라고 합니다.
cobra를 이용한 프로그래밍을 하기 위해서는 다음의 2개 패키지를 설치해야 합니다.
acicobra (SDK)
acimodel (ACI MIT Model Package)
이 2개이 패키지는 APIC에서 아래의 URL을 통해서 다운로드 받을 수 있습니다.
http[s]://APIC Address/cobra/_downloads/ |
이 디렉토리 내에는 다음의 2개의 .egg file들이 존해아며, 파일 이름에는 APIC과 Python 버전 정보가 함께 표기되어 있습니다.
따라서, APIC 버전에 따라서 다음의 파일명은 조금 다를 수 있습니다.
위의 패키지 2개를 다운로드 받은 이후에는 설치해야 하는 데,
이를 설치하기 위해서는 다음의 패키지가 사전에 반드시 설치 되어 있어야 합니다.
Python 2.7, easy_install, pip , virtualenv
위의 사전 설치 패키지를 모두 설치하고 나면, APIC에서 다운 받은 파일을 설치를 진행해야 하는 데,
이 때 다음의 2가지 사항에 유의해야 합니다.
◇ acicobra SDK와 acimodel Package를 설치는 반드시, acicobra SDK를 먼저 설치 후에 acimodel을 설치
◇ 기존에 설치된 acicobra SDK가 있다면, 설치 전에 먼저 Uninstall 을 한 이후에 재 설치.
APIC SDK 설치는 Windows와 Linux 환경 모두 설치가 가능하며,
이번 포스팅에서는 Windows 환경에서의 설치를 살펴보겠습니다.
Windows에 SDK 설치하기 |
1. Windows 환경 변수의 Path에 Python 경로와 Python scripts 경로를 추가
2. easy_install 명령을 이용하여 acicobra SDK egg 파일을 설치
easy_install -Z acicobra-X.X-pyX.X.egg
Windows에 ACI Model Package 설치하기 |
1. easy_install 명령을 이용하여 acicobra SDK egg 파일을 설치
easy_install -Z acimodel-X.X-pyX.X.egg
ACI SDK, Model Package 설치 확인 |
pip show 명령어를 사용하여, 정상적으로 SDK와 Package가 설치되었는지를 확인합니다.
* 관련 링크 : https://developer.cisco.com/media/apicDcPythonAPI_v0.1/install.html
Today Keys : ACI, Interface, Policies, Policy, Profile, Group
이번 포스팅은 Cisco ACI 로 시작하는 시리즈 포스팅의 첫 번째 포스팅입니다.
작년 말부터 Cisco ACI를 운영하기 시작하면서 정리를 조금씩 하면서 포스팅을 준비했는 데..
예전부터 그랬지만 항상 포스팅을 하기 위한 준비 작업 시간도 오래 걸리거니와
또 맘에 들 때까지.. 무작정 기다리기만 하면 포스팅을 하지도 못하고.. 계속 늦춰지기만 하게 되네요.
우선 짧게 짧게라도 가볍게 정리해 놓은 것들을 풀어보는 포스팅을 하려고 합니다.
전체적인 흐름과 아키텍처를 잘 짜야만 된다고 생각되는 것이 ACI 이긴 하지만..
우선 포스팅은 단편적인 부분부터 시작해봅니다. 그렇지 않으면 무작정 계속 늦어질 듯 싶으니까요..
나중에 흐름과 전체 구조는 하나씩 짜맞춰 나가는 포스팅을 하도록 하겠습니다! ^^
첫 번째 포스팅은 Interface의 설정을 어떻게 할 것인지에 대한 내용입니다.
개별 인터페이스별로 설정을 하는 것이 아니라, 기존의 Port-Profile 기능처럼 인터페이스에 적용할 Profile을 만든 후에
이를 동일하게 사용되는 전체 인터페이스에 손쉽게(?) 적용할 수 있습니다.
Interface Policies
Policies
- Switch Interface 대한속성, CDP, STP등각interface에서설정한가능한 Config에대해서세부속성.
- 기존 CLI에서의 Interface 명령안에선택되는옵션값수준.
* 설정 가능한 정책
- Link Level , CDP, LLDP, Port Channel, STP, Storm Control, Port Security 등
< Interface Policies의 Policies에서 설정할 수 있는 정책 >
< Link Level Policy 설정 >
< CDP 설정 >
Policy Group
- 각 Policies를엮어서, 하나의 Interface 설정값을만듬.
- 실질적으로 특정 인터페이스 설정 될 Port Profile 설정
- 일반 Interface 설정은 하나의 Policy Group으로 만들어서 다수의 인터페이스에 적용해서 사용.
- Policy Group은 일반 Individual Port와 Port-channel, vPC 로 나누어서 설정을 하게 되며,
Port-Channel과 vPC는 개별로 생성 해야 함.
< Policy Group의 설정 >
< 일반 Individual Interface Policy 설정 >
< Port-Channel Interface Policy 설정 >
< vPC Interface Policy 설정 >
Profile
- Policy Group에서설정된인터페이스설정값을적용할 Profile 설정
- Policy Group을 적용할 인터페이스를 지정한다고 생각하면 됨. 이 과정을 Interface Selectors를 라는 메뉴에서 지정하게 되며
여기서는어떤 Leaf에대한 Interface인지까지는지정하지않고, 단순히 Interface ID(Interface 번호)만지정 하게 됨.
실제 어떤 Leaf의 적용될지에 대한 mapping 과정은 Switch Policies에서 적용
< vPC Interface Policy 설정 >
< vPC Interface Policy 설정 >
Today Keys : profile, switch, policies, 설정, template, aci, cisco, vpc
Cisco ACI에 대한 두 번째 포스팅입니다.
Switch Policies
< Switch Policies의 Policies로 설정 가능한 메뉴 >
< VPC Domain Policies 설정 >
- ACI 를 구성하는 Leaf에서 vPC를 사용하기 위해서는 아래와 같이 vPC Group으로 묶일 스위치를 선언해주어야 합니다.
이 때에 사용되는 ID는 해당 APIC Pod에서는 Unique한 값으로 사용되어야 합니다.
그리고 vPC로 구성되는 Leaf은 2대로만 구성이 가능합니다.
만약, 이미 vPC로 구성된 스위치를 다른 vPC Group의 Switch로 선택하지 않도록 유의해야 합니다.
ACI 2.1 이후부터는 이미 vPC로 구성된 스위치를 다른 vPC Group에 선택하게 될 경우에 오류가 뜨면서 설정이 되지 않지만,
ACI 2.0 이하에서는 선택이 되면서, 기존의 vPC Group과 신규로 설정한 vPC Group 모두 비정상적으로 동작될 수 있습니다.
< VPC Domain Policies 설정 >
NetScaler
Service에서 Access Down 옵션 설정 체크
일반적으로는 비활성화 된 서비스에 대해서 요청이 들어오게 되면, 해당 요청은 허용되지 않지만 Access Down 옵션을 사용하면 됩니다.
이를 위해서는 계층 2 모드가 활성화 되어 있어야 합니다.
※ NetScaler의 동작 모드 중에서 Layer 2 Mode와 Layer 3 Mode는 한 가지를 선택할 수 있는 것이 아니라,
개별적으로 각 모드를 활성화 혹은 비활성화 해서 사용할 수 있음.
NetScaler 라이선스 별 지원 기능
장비에서 라이선스 확인 - CLI
ZIGI-NetScaler#> show ns license |
장비에서 라이선스 확인 - GUI
장비 기능별 활성화 확인 - CLI
ZIGI-NetScaler#> show ns feature Feature Acronym Status |
장비 기능별 활성화 확인 - GUI
정말 정말 오랜만에 남기는 포스팅입니다.
이번 포스팅은 Cisco ACI와 관련된 디자인 관련과 해당 디자인과 관련된 Bug Report를 포함한 내용을 정리해보았습니다.
올 한해 너무 많은 일들이 벌어져서 포스팅을 못하고 있다가, 몇 가지 이슈로 인해서 다시 정리를 하면서 공유하고자 합니다.
ACI Design Guide
ACI에서 ACI 외부 네트워크와 연결하기 위한 디자인 구성은 다음의 3가지 구성으로 볼 수 있음.
○ Computing과 Border Leaf의 용도로 함께 사용. 이 구성의 경우 해당 Leaf은 endpoint와 WAN 혹은 라우터와 같은 L3 장비 연결
○ Border Leaf 전용으로 구성. 이 구성의 경우에는 해당 Leaf은 서버가 연결되지 않고 오직 WAN 혹은 라우터와 같은 L3 장비 연결
○ Border Leaf 대신에 Spine을 통한 L3 EVPN 서비스 사용
- Layer 3 EVPN Services for Fabric WAN은 Cisco ACI GOLF로 명칭 변경
ACI GOLF는 초기의 Spine-Leaf 구조의 Border Leaf을 통한 외부 통신과는 달리 추후에 디자인 된 기능이기 때문에 보다 일반적인 Border Leaf을
사용한 디자인과 관련하여 몇 가지 알아보겠습니다.
ACI Release 2.3 디자인 가이드에 Border Leaf 디자인에 대한 고려해야 할 사항에 대한 내용이 추가되어 있습니다.
기존 ACI Release 2.0 디자인 가이드에서는
Border Leaf를 L3 Out을 사용한 순수 Border 역할을 하는 경우에는 VRF의 Policy control enforcement Direction을 ingress를 하도록 권고하며,
Border Leaf를 Border 역할과 Computing leaf 역할을 함께하는 경우에는 VRF의 Policy control enforcement Direction을 Egress로 권고합니다.
* 단, Nexus 9300 EX Leaf의 경우에는 어떤 경우든 ingress 를 권고
Policy Control Enforcement Direction옵션은 VRF 내에 설정된 모든 L3Outs에 VRF 레벨로 적용되며, Ingress가 권고사항임. 1.2(1)에서 도입되었으며, 1.2(1) 이후의 VRF 생성 시에 기본 값으로 Ingress로 설정됨 |
이후, ACI Release 2.3 디자인 가이드 에서는 보다 세부적인 Border Leaf 디자인에 대한 고려사항이 기술되어 있습니다.
그 중에 일부를 살펴보면 다음의 내용이 있습니다.
○ 모든 Leaf 스위치가 Nexus 9300-EX 혹은 9300-FX 플랫폼인 경우에는 Border Leaf에 EndPoint가 연결되어 있어도 무관합니다.
○ Computing 스위치에 1세대 Leaf 스위치가 있는 경우에는 다음의 2가지 옵션을 선택해야 합니다.
- ACI Release 2.2(2e) 혹은 그 이후 버전을 사용한 상태에서 Border Leaf 스위치가 EndPoint 학습을 비활성화 하도록 옵션을 설정해야 합니다.
이 옵션은 Fabric > Access Policies > Global Policies > Fabric Wide Setting Policy 에서 Disable Remote EP Learn을 선택 합니다.
- 다른 하나는 ACI 2.0 디자인 가이드와 동일하게 Policy control enforcement Direction을 Egress 을 선택합니다.
※가이드 문서에 따르면, 9300-EX / 9300-FX 플랫폼의 경우에 Border Leaf에 End Point가 연결되어도 무관하다고 되어 있으나, 1세대 스위치의 첫 번째 옵션과 동일하게 Disable Remote EP Learn을 설정하도록 되어 있습니다. 이 부분에서는 별도의 OS Release가 나와있지 않기 때문에 추가로 확인이 필요할 듯 싶습니다. |
※ ACI 1세대 Leaf 스위치 - Nexus 9332PQ / 9372PX-E / 9372TX-E / 9372PX / 9372TX / 9396PX / 9396TX / 93120TX / 93128TX |
이 디자인 가이드는 ACI Bug Report(CSCUz19695) 와 관련된 부분이었습니다.
해당 Bug Report는 VM의 vmotion 시의 트래픽이 끊길 수 있다는 내용인 데,
실제 VM의 vmotion이 아닌 유사 동작인 경우에도 이러한 트래픽 유실이 발생할 수 있을 것으로 보입니다.
결국 EndPoint가 특정 leaf에서 다른 leaf으로 이동되는 EP Move 상황인 경우에
Border 역할을 하는(실제 L3 Out이 설정되어 있는 leaf이 Border Leaf처럼 동작)에서는 정상적으로 갱신되지 않으면서,
기존 Border가 해당 원격 EP와 통신하기 위한 Tunnel 정보를 그대로 유지하고 있다가 통신이 끊기는 경우입니다.
이 경우에 초기에는 정상적으로 동작을 하지만, 약 10여분 후에 통신이 끊기게 되는 데, 다음과 같은 이유로 보입니다.
1. Computing Leaf의 EndPoint와 Border Leaf의 EndPoint가 통신을 하면서 서로 간의 통신 Flow입니다.
모두 Spine을 거쳐가는 Tunnel Interface를 통해서 통신하게 됩니다. 여기서 각 leaf 하단의 EndPoint는 Local로 인식을 하게 되고,
해당 EndPoint의 Interface 또한 물리 Eth입니다.
2. Leaf#1의 EndPoint가 Leaf#2로 이동 후에 Leaf#1에서 SVR#1이라는 EndPoint는 Local이 아닌 Bounce 상태가 되고, Interface는 Leaf#2로 던지는 Tunnel이 됩니다.
3. Bounce Entry aging(Default 630초)이 지난 후에 Leaf#1에서의 Leaf#2를 향한 Tunnel 인터페이스 정보가 삭제되었으나, Border쪽은 정상적으로 EndPoint 정보가 남아있게 되면서, ACI Fabric 이외의 구간에서 SVR#1과 통신이 불가한 상태가 발생하게 됩니다. (Border를 지나치지 않는 경우는 통신 가능)
이러한 이슈를 예방하기 위해서 Border Leaf에서 별도로 원격지 EndPoint의 대한 정보를 학습하지 않도록 하고,
Spine을 통해서 EndPoint 정보를 찾아갈 수 있도록 권고하고 있습니다.
이러한 권고는 ACI Release 2.3 디자인 가이드 문서를 포함하여 다양한 ACI 관련 시스코 문서에 제시되고 있습니다.
실제 원천적으로 앞서 얘기한 방법을 통해 해결 할 수도 있지만, 해당 문제가 발생할 경우에 임시적으로 Border 장비에서 별도의 커맨드를 통해서 EndPoint 정보를 삭제할 수 도 있습니다. (Ex. vsh -c "clear system internal epm endpoint vrf Tenant:VRF ip ip_Address")
Bug Report에도 동일하게 명시되어 있지만, 이러한 Bug 동작 1세대 Nexus 9000시리즈에서만 발생하고 있습니다.
정리해서 보면...
Border Leaf은 Border로만 사용하고 Computing Leaf 역할로 사용하지 않거나..
Computing Leaf 역할을 함께 사용하게 된다면, 2.2(2e)에서의 Disable Remote EP Learn옵션을 사용하거나,
전 Leaf을 2세대 이상으로 구성을 하는 방법으로 가야하지 않을까 싶습니다.
관련 Bug Report로 인한 내용은 Cisco 포럼에서 보면, 상당히 많이 처리된 점과 2.2(2e) 이후에 별도의 옵션이 만들어진 점
그리고 2.3 디자인 가이드를 비롯하여 상당 수의 문서에 동일 내용이 있는 것으로 보아 해당 이슈가 잠재되어 있는 사용자 분들이
적은 수는 아니리라 개인적으로 추정해봅니다.
마지막으로..
본 내용에 포스팅 내용에 있는 부분들과 관련해서 LST, GST과 같은 테이블에 대한 학습과 Aging, EP Move 등의 사전 내용들을 이해해야만
위와 같은 이슈에 대해서 좀 더 이해할 수 있을 것 같습니다.
관련 내용들은 올해 차례대로 포스팅을 해보고자 했으나, 1년여간 생각치도 못한 일정 등으로 인해서 미뤄두고 있었습니다.
내년에는 그간 미뤄두었던 포스팅을 좀 더 해서, 조금이나마 여러분들께 공유할 수 있도록 하겠습니다.
안녕하세요.
이번 포스팅은 ACI에서 공용 서비스를 구성하기 위한 방법 중의 하나가 될 수 있는 내용입니다.
ACI에서 Tenant 간의 통신 시에도 Border Leaf을 통한 외부를 통해서 통신하지 않고, ACI 내부 간에 통신을 하기 위한 방법입니다.
공용으로 제공하게 될 서비스를 다른 테넌트에서도 직접 통신하도록 하여, 불필요하게 트래픽이 외부로 나가지 않고
또한 공용 서비스가 아닌 서비스 간에는 서비스를 분리할 수 있게 됩니다.
실제 구성에 있어서는 어떤 대역을 어떻게 구성하여 기존 라우팅 테이블과의 이슈가 없이 할 수 있을지에 대한 고민은 필요할 것입니다.
먼저 공용으로 사용 하게 될 서비스가 있는 테넌트의 EPG를 선택합니다.
이 EPG가 실제 다른 테넌트에서 공용으로 사용하게 될 서비스 그룹이 됩니다.
이제 EPG에서 서브넷을 생성합니다.
해당 EPG에서 생성되는 서브넷은 다른 테넌트에서 접근하기 위한 네트워크로 설정하게 됩니다.
마지막에 라우팅 테이블을 확인해보겠지만, 이 EPG에서 추가한 서브넷은 다른 VRF에서 Attatch된 네트워크로 인식됩니다.
그리고 다른 VRF에서도 이 서브넷을 사용하여야 하기 때문에 Scope를 'Shared between VRFs'로 선택합니다.
ACI 버전에 따라서, Shared Subnet이라는 옵션일 수도 있습니다.
다음은 이 EPG를 다른 곳에서 사용할 수 있도록 하기 위해서 Contract을 생성합니다.
다른 테넌트에서도 공용으로 사용하게 될 Contract이기 때문에 Contract의 Scope는 Global이 됩니다.
만들어진 Global Contract은 Common EPG의 Contract에 Provided로 추가(Add)를 합니다.
Global Contract이 다른 Tenant에서도 사용될 수 있도록 Export 합니다.
다른 Tenant에서 보이는 이름은 여기서 지정한 Name으로 됩니다.
이제 Common EPG에 대한 설정은 완료되었습니다.
다음은 Common EPG를 사용하고자 하는 EPG에서 Export된 Contract을 추가하면 됩니다.
이제 모든 설정 과정이 끝났습니다.
이제 라우팅 테이블을 확인해 보면, 아래와 같이
Tenant-ZIGI에서는 Tenant-SPACE 의 BD에 대한 네트워크 대역이 라우팅 테이블로 보이고,
Tenant-SPACE에서는 Tenant-ZIGI의 EPG에 선언된 네트워크 대역이 라우팅 테이블로 보이게 됩니다.
ZIGI_LEAF# show ip route vrf DEV:SPACE-VRF ..전략.. ...후략... |
ZIGI_LEAF# show ip route vrf Service_Admin:ZIGI-VRF ...전략... ...후략... |
안녕하세요.
이번 포스팅은 Programmability for Networker의 25번째 포스팅입니다.
ACI Cobra를 이용하여 Port Channel 혹은 vPC Profile을 만들어주는 코드에 대해서 공유합니다.
세부적인 코드 설명은 포함되어 있지는 않지만, 현업에서 아래의 코드를 사용한다면
보다 쉽고, 빠르게 Profile을 만드실 수 있을겁니다.
이번 코드는 운영 중인 커뮤니티에서 진행된 '제 22회 네트워크 전문가 따라잡기 'N.EX.T''에서 발표하였던 코드이기도 합니다.
(정리해서 올리기로 하고.. 1년 가까이가 지났네요. ^^)
물론 포스팅 설명에 앞서서 한가지 미리 얘기를 드리면,
'왜 Port Channel이나 vPC Profile을 대량을 으로 만들어야 하지?' 라고 생각하실 수 있습니다.
ACI에 대한 포스팅을 준비만 하면서 계속하지 못하고 있어서 다루지 못한 부분이기는 하지만..
이 부분은 ACI를 어떻게 설계해서 사용하느냐에 따라서 많아질 수도.. 혹은 적어질 수도 있을 것이라고 생각합니다.
(물론 개인적인 생각은 최적화 된 Profile로 설계해서 사용한다면 그리 많지 않은 Profile로 모두 수용이 가능합니다.)
그럼 이제 본 내용을 시작합니다.
ACI에서 기본적으로 제공되는 APIC GUI에서 Click! Click을 이용해서 설정하는 방법 이외에
일괄적으로 대량을 설정을 하기 위해서는
JSON이나, XML 포맷의 파일을 미리 만들어 POST 하여 설정을 하거나,
ACI에서 제공되는 API를 이용해서 코드로 설정하는 방법이 있을 것입니다. (CLI를 제외하고..)
하지만, 오늘 다룰 내용인 Interface Policies 항목에서는 POST를 할 수 있는 메뉴가 없습니다.
최상단의 Interface Policies에도 없고요.
하단의 Policy Groups에도 없습니다.
물론 그 하단인 Leaf Policy Groups에도 없습니다.
그래서 PC Profile이나 vPC Profile을 생성하기 위해서 ACI SDK인 Cobra를 이용하여 Port Channel이나 vPC Profile을 만들려고 합니다.
다음은 Port Channel이나 vPC Profile을 만드는 코드입니다.
위의 코드 이외에 Port Channel 혹은 vPC Profile의 이름이 선언된 info.txt라는 파일이 있어야 합니다.
info.txt에는 단순히 Profile에 사용할 이름만 한 줄씩 나열합니다.
그러면 info 파일에서 한 줄씩 읽어서 해당 이름으로 Profile을 생성하게 됩니다.
코드 본문에 있는 AEP 변수에서 사용하실 AEP 이름을 수정하시고
Port Channel을 사용할지, vPC를 사용할지에 따라서 AccBndlGrp 메서드 호출 시에 lagT에 대해서
Port Channel은 'link'로 설정하시고, vPC의 경우에는 'node'로 설정하시면 됩니다.
위의 코드에서는 Link Level Policy, Port Channel Policy, Attach Entity Profile에 대한 속성만 설정하였지만,
기타 그 밖의 설정을 추가할 수도 있습니다.
혹시라도 대량으로 PC, vPC Profile을 설정하셔야 하는 경우에 이 코드를 사용하시면 조금은 쉽게 설정이 가능하실 겁니다.
물론 자동화의 장점은 설정에 대한 편의성도 있지만, 잘못된 설정으로 인한 휴먼에러의 방지도 가능할 것입니다.
참고로, 위의 코드에서는 설정 시의 기본 예외처리만 만들었으며
기타 다른 상황에 대한 세부 예외 처리가 되어 있지 않기 때문에 더 보완해서 사용해보시는 것도 좋을 것 같습니다.
이번 포스팅은 Cisco ACI의 Bug Report (CSCvb42851)에 대한 공유입니다.
ACI 모드의 Spine과 Leaf의 특정 Process(stats_manager)에서의 Memory Leak에 대한 Bug 입니다 .
Memory Leak으로 인한 장비 자체가 Reload되는 Bug 입니다.
일시적인 해결 방법으로는 장비를 재기동하는 것으로 일시적으로 해소되지만,
근본적인 원인 해결은 Memory Leak 문제가 해결된 2.1(2g) 이상으로 OS Upgrade가 필요로 합니다.
현재 메모리 상태를 확인하기 위해서는 다음과 같이 확인이 가능합니다.
ZIGI_leaf1#ps aux| grep stats_manager| grep-v grep |
빨간색으로 표기되는 값이 VSZ(Virtual memory SiZe)이고, 파란색으로 표기된 값이 RSS(Resident Set Size)입니다.
VSZ는 프로세스의 가상 메모리의 크기를 나타내면, RSS를 프로세스가 사용하는 물리 메모리 크기를 나타내게 되는 데,
프로세스에서 메모리가 정상적으로 반환되지 않고 Memory Leak이 발생하는 경우에는 VSZ 값이 증가하게 됩니다.
이 값이 4,194,304에 도달하기 전에 장비가 재기동 되기 때문에 해당 메모리 사이즈 근처로 가기 전에 조치를 취해야 합니다.
실제 GUI의 Inventory에서 확인 가능한 stats_manager의 값은 RSS에 대한 값이기 때문에 정확한 값을 확인하기 위해서는
CLI에서 확인해야 합니다.
그리고, stats_manager의 해당 값으로 가지 않더라도 stats_manager 프로세스에서의 Memory Leak으로 인해서 전체 메모리
사용량이 올라가면서 메모리가 소진되면, Kernel Panic이 발생할 수도 있습니다.
전체 메모리 사용량은 다음과 같이 확인이 가능합니다.
ZIGI_leaf1#show system resources |
참고로 만약에 이 Bug로 장비가 재기동된 경우에 장비의 reset-reason을 확인하면 다음과 같이 나오게 됩니다.
ZIGI_leaf1#show system reset-reason |
ACI에대한접근방법
ㆍGUI / API / CLI
fabric Node의 CLI 모드
ㆍCLI
- NX-OS, Bash Shell 명령으로스위치의정보를확인(Bash, iBash, iShell이라고함)
ㆍ vsh_lc
- Line card Shell.
- ALE(Application Leaf Engine) ASIC의 Linecard Process나, forwarding table을확인하는데사용
ㆍBroadcom Shell
- Broadcom ASIC에대한정보를확인하는 Shell.
- TAC에서다루는범위
ㆍVSH
- NX-OS CLI Shell.
- ACI 모드에서는부정확할수있으며, 사용을권고하지는않음.
일반 Bash 명령
ㆍ CLI 모드를사용하는경우에다음의일반적인 Linux 명령을사용가능
- man, what, ls, cd, cat, grep, ps, netstat, ip route show, pwd
일반 CLI 명령
ㆍ Fabric Node에는일반 NX-OS 명령어외에 ACI와관련된명령어가추가로있음
- acidiag : controller와 fabric node의상태를확인하기위한명령
acidiag avread(controller정보), acidiag fnvread(fabric node정보)가일반적으로많이사용됨.
- techsupport : CLI를통해서장비의 techsupport 파일을수집
- attach : APIC에서 Leaf에 ssh로접근하기위해서사용
- iping/itraceroute : ping과 traceroute를대신해서사용
기타
ㆍCLI창에서<ESC> 키를두번누르면, 기존 NX-OS 에서 '?' 처럼, 사용가능한키워드가화면에표기됨
- VSH에서는 NX-OS Shell이기때문에동일하게 '?' 사용
downStateFlush
서비스또는가상서버가 Down된경우기존연결을즉시종료하도록설정 (RST 발생)
- downStateFlush (Default : Enabled)
- Virtual Server 혹은 Service에설정
Down State Flush가활성화된경우에다음의 Connection 상태를모두정리(Session Table 삭제)
ㆍConnection이 Pending된서비스 (TCP handshake가정상적으로완료되지않은상태)
ㆍ기존에연결된 Connection (TCP handshake가완료된상태)
ㆍPending된요청 (HTTP 요청을수신했으나응답하지않은상태)
ㆍ진행중인요청(HTTP 요청을수신하고일정응답을받았지만, 전체응답이완료되지않은상태)
ㆍSurge Queue
각서비스는해당서비스 Health가실패하게되면 Down으로되고, 가상서버의경우에는가상서버에연결된모든서비스가 Down이되면 Down으로됩니다.
가상서버는 Down으로체크될때, 즉시혹은기존서비스가안전하게종료될수있도록허용하고연결을종료.
다음은가상서버와가상서비스에서 downStateFlush 설정에따른연결상태를나타내는표입니다.
가상서버 | 가상서비스 | State of Connection |
Enabled | Enabled | ㆍClient / Server Connection이모두종료 |
Enabled | Disabled | ㆍTCP와같은서비스는 Connection reuse를허용안함 - Client / Server Connection이모두종료 ㆍHTTP와같은서비스는 Connection reuse를허용 - 트랜잭션이활성화상태 : Client / Server Connection이모두종료 - 트랜잭션이비활성화상태 : Client Connection만종료 |
Disabled | Enabled | ㆍTCP와같은서비스는 Connection reuse를허용안함 - Client / Server Connection이모두종료 ㆍHTTP와같은서비스는 Connection reuse를허용 - 트랜잭션이활성화상태 : Client / Server Connection이모두종료 - 트랜잭션이비활성화상태 : Server Connection만종료
|
Disabled | Disabled | ㆍClient / Server Connection이모두종료시키지않음 |
서버나클라이언트로연결된 Connection을닫고자할때에는이서비스를 Disable 함.
Command line에서설정하는방법
set lb vserver <name> -downStateFlush <Value>
Example
set lb vserver Vserver-LB-1 -downStateFlush enabled
GUI 설정방법
1 Traffic Management > Load Balancing > Virtual Servers
2.Advanced Settings
3. Traffic Settings / Down State Flush.
