분류없음2018.02.21 23:52

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이기 때문에 동일하게 '?' 사용

 

Posted by 네떡지기

안녕하세요. 

이번 포스팅은 ACI에서 공용 서비스를 구성하기 위한 방법 중의 하나가 될 수 있는 내용입니다.

ACI에서 Tenant 간의 통신 시에도 Border Leaf을 통한 외부를 통해서 통신하지 않고, ACI 내부 간에 통신을 하기 위한 방법입니다.

공용으로 제공하게 될 서비스를 다른 테넌트에서도 직접 통신하도록 하여, 불필요하게 트래픽이 외부로 나가지 않고

또한 공용 서비스가 아닌 서비스 간에는 서비스를 분리할 수 있게 됩니다. 


실제 구성에 있어서는 어떤 대역을 어떻게 구성하여 기존 라우팅 테이블과의 이슈가 없이 할 수 있을지에 대한 고민은 필요할 것입니다.










 

먼저 공용으로 사용 하게 될 서비스가 있는 테넌트의 EPG를 선택합니다.

이 EPG가 실제 다른 테넌트에서 공용으로 사용하게 될 서비스 그룹이 됩니다.

이제 EPG에서 서브넷을 생성합니다.

 

 

 

 

 

해당 EPG에서 생성되는 서브넷은 다른 테넌트에서 접근하기 위한 네트워크로 설정하게 됩니다.

마지막에 라우팅 테이블을 확인해보겠지만, 이 EPG에서 추가한 서브넷은 다른 VRF에서 Attatch된 네트워크로 인식됩니다.

그리고 다른 VRF에서도 이 서브넷을 사용하여야 하기 때문에 Scope를 'Shared between VRFs' 로 선택합니다.

ACI 버전에 따라서, Shared Subnet 이라는 옵션일 수도 있습니다.

 

 

 

 

다음은 이 EPG를 다른 곳에서 사용할 수 있도록 하기 위해서 Contract을 생성합니다.

다른 테넌트에서도 공용으로 사용하게 될 Contract이기 때문에 ContractScopeGlobal 이 됩니다.

 

 

 

 

 

만들어진 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
IP Route Table for VRF "DEV:SPACE-VRF"

..전략..
192.168.254.192/29, ubest/mbest: 1/0, attached, direct, pervasive
    *via 10.0.56.64%overlay-1, [1/0], 01w10d, static
192.168.254.193/32, ubest/mbest: 1/0, attached, pervasive
    *via 192.168.254.193, vlan129, [1/0], 01w10d, local, local
192.168.254.200/29, ubest/mbest: 1/0, attached, direct, pervasive
    *via 10.0.56.64%overlay-1, [1/0], 01w10d, static

...후략...

 

 

ZIGI_LEAF# show ip route vrf  Service_Admin:ZIGI-VRF
IP Route Table for VRF "Service_Admin:ZIGI-VRF"

...전략...
192.168.254.192/29, ubest/mbest: 1/0, attached, direct, pervasive
    *via 10.0.56.64%overlay-1, [1/0], 01w10d, static
192.168.254.200/29, ubest/mbest: 1/0, attached, direct, pervasive
    *via 10.0.56.64%overlay-1, [1/0], 01w10d, static
192.168.254.201/32, ubest/mbest: 1/0, attached, pervasive
    *via 192.168.254.201, vlan83, [1/0], 01w10d, local, local

...후략...

 

 


Posted by 네떡지기

안녕하세요 

이번 포스팅은 지난 번에 했던 포스팅과 마찬가지로 간단한 동영상을 올려봅니다.


Cisco ACI에서 포트설정은 Profile 형태로 구성을 하게 되는 데, 

PortProfile을 생성하는 것을 JSON을 이용해서 Post하기 위한 예제입니다. 

동영상의 내용은, 동일한 PortProfile 그룹과 거기에 설정할 AEP를 지정하고 

그리고 각 인터페이스 별로 설정할 Port정보를 기입하여, ACI에 적용할 JSON을 생성한 후, ACI에 적용하게 되는 동영상입니다.


좀 더 많은 부분은 한꺼번에 JSON 형태로 만들어서 Profile을 만들고 싶은 생각은 있지만..

아무래도 실 운영 환경에서 테스트를 진행하는 부분에는 한계점이 있기 때문에.. 

가상머신이나. 에뮬레이터가.. 절실하다는.. 생각을 해보면서 포스팅을 마칩니다.



P.S 물론 본 동영상에 포함된 Profile 형태가 물론 ACI에서 하고자 하는 아키텍처의 그림은 아닐 수 있겠지만.

    위와 같은 형태의 자동화 부분도 가능하다는 점만 염두해두면 좋을 것 같습니다.

Posted by 네떡지기

안녕하세요.  이번 포스팅은 정보 공유 포스팅입니다.

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% 입맛에 맞추기는 어렵겠지만,

결국 이러한 도구들처럼, 필요한 부분들을 개발해서 사용할 수 있는 오픈 환경이 제공되어 진다는 점이

현재의 트렌드이자.. 앞으로 나아가는 방향 중에 하나가 아닐까 싶습니다.

 

 




Posted by 네떡지기
네트워크/Switching2017.03.09 12:37

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 



Posted by 네떡지기
분류없음2016.12.29 10:21

Last Update : 16.12.30

   * MMM으로는 기본 VIP 전환 시에, GARP 를 발생하여 Table 갱신이 되지는 않는 것으로 보입니다. 
     우선 조치할 수 있을만한 방법은 VIP에 대해서 VIP 전환 시점에 Source-Ping을 하던지,
     아니면 주기적으로 동일 대역 내에서 VIP에 PIng을 쳐서, 지속적으로 갱신을 해야 할 것 같습니다.
     주기적으로 VIP 전환 시 Ping을 체크하는 경우도 아래의 설정은 필요로 합니다.

     추가적으로 확인되는 사항은 업데이트 하도록 하겠습니다.

 



오랜만에 하는 포스팅은 Cisco ACI에 대한 관련 이슈 공유 내용입니다.

Bridge Domain에서의 기본 설정인 Hardware Proxy와 관련한 이슈 사항입니다.

앞으로 아마도 ACI에 대한 포스팅을 시작하게 될 듯 싶은 데... 우선 정리 포스팅 전에..

어쩌다보니.. 간단한 이슈 포스팅을 먼저하게 되었습니다 ^^;

물론 ACI 이외에도 기존처럼 다양한 포스팅 들도 함께 할 수 있도록 노력하겠습니다. ^^

즐거운 연말되세요!

 


Cisco ACI Bridge Domain 관련

 

○ 현상 

  ㆍ MySQL DB Clustering을 위한 MMM(Multi Master Replication Manager) 을 서버에서 사용 중.(Active-Standby)

  ㆍVIP가 Active 서버에서 Standby 서버로 전환될 경우에 정상적으로 통신이 되지 않음.

 

 

○ 확인 및 원인 분석

  ㆍACI 내에서 VIP에 대한 정보(IP/Mac Address)가 갱신되지 않음.

  ㆍMMM에서 VIP가 Active-Standby로 전환되면서, IP에 대한 MAC이 변경되었기 때문에 GARP를 보내서,

     Table이 갱신되어야 하나, 정상적으로 이뤄지지 않은 것으로 추정

  ㆍBridge Domain의 L2 Unknown Unicast 설정이 Hardware Proxy이고, ARP Flooding은 비활성화

  ㆍBridge Domain의 설정으로 GARP 패킷이 Drop되어서, 정상적으로 Table 갱신이 되지는 않는 것으로 추정.

 

 

○ 조치 및 결과

  ㆍBridge Domain의 ARP Flooding 설정을 활성화 상태로 변경 후, DB VIP가 Standby로 넘어감에 따라
     Table이 정상적으로 갱신되는 것을 확인

 

○ Bridge Domain 관련 내용 

  ㆍBridge Domain은 기존의 전통적인 네트워크의 VLAN 컨셉과 유사. Brocast와 Flooding Domain으로 동작 가능
       - 물론 관련 설정이 활성화 되어 있어야 하며, 완전하게 동일하지는 않음.

  ㆍBridge Domain의 Unknwon Unicast 프레임에 대해서, 아래의 2가지 모드로 동작 가능.

       - Optimized mode : Hardware Proxy

           Mapping Database 사용하여 처리

       - Flood mode : Flood

           Bridge Domain의 Multicast Tree를 이용해서 L2 Unknown unicast가 Flood됨.

  ㆍBridge Domain의 기본 L2 Unknown Unicast의 동작 방식은 Hardware Proxy임.

  ㆍBridge Domain의 ARP Flooding은 Default Disable 상태.  

  ㆍHardware Proxy의 기본동작은 L2 Unknown Unicast에 대해서 Spine으로 보내게 되고, Spine의 Mapping Database에

      해당 정보가 없을 경우, 패킷이 Drop 됨.

  

 

○ 정리하면..

ㆍDB서버에서 Active가 Standby로 Failover되면서, VIP가 DB2번기에서 올라오면서 GARP를 발생 시키는 데 기존 Hardware proxy/ARP Flooding Disable에서는 해당 패킷을 Drop시켜서 정상적으로 Table이 갱신되지 않았고, Hardware Proxy  설정을 Flood로 전환하게 되면, ARP Flooding이 같이 Enable되지만, 이 경우에는 해당 BD에 연결이 일시적으로 끊기기 때문에 (Test 시에 Ping 3개정도 빠짐), Hardware Proxy 설정은 유지한 채, ARP Flooding만 Enable로 변경 후, 정상 동작 확인

  

  

※ 참조 : Cisco Application Centric Infrastructure Release 2.0 Design Guide

 

 ARP Flooding
If ARP flooding is disabled, a Layer 3 lookup occurs for the target IP address of the ARP packet. ARP behaves like a Layer 3 unicast packet until it reaches the destination leaf switch.
ARP flooding is required when you need Gratuitous ARP (GARP) requests to update host ARP caches or router ARP caches. This is the case when an IP address may have a different MAC address (for example, with clustering of failover of load balancers and firewalls).

 

.  

 

Bridge Domain 관련 설정

 

 

 

 

 

 

* Bridge Domain 설정에서 ARP Flooding 설정을 활성화하게 되면, L3 설정에 아래와 같은 설정이 가능.  

  우선 해당 설정까지는 하지 않은 상태였으나, MMM VIP가 전환되는 데에는 문제가 없었음.

  아래 설정은 어느 경우에 사용되는지는 추가로 확인 필요.

 

 

 

 

GARP

   - Source / Destination IP는 모두 패킷을 보내는 시스템 IP로 설정

   - Destination MAC은 Broadcast MAC 으로 설정 (ff:ff:ff:ff:ff:ff)

   - 일반적으로 GARP는 Request만 발생하고, Response는 발생하지 않음.

   - IP 충돌을 감지하거나, 다른 시스템의 ARP 테이블을 갱신하기 위해서 사용(특히나, Clustering Solution에서 Active가 전환되는 경우에 동일한 IP에 대한 Mac 주소가 변경되기  때문에 필요)

 

※ 참조 : https://wiki.wireshark.org/Gratuitous_ARP

Posted by 네떡지기
분류없음2016.12.23 08:50

 

안녕하세요.

네떡지기입니다.


본 블로그에서 나름 오랜(?)기간 포스팅 했었던.. 시리즈인..

Nexus 기초 따라잡기에 대한 PDF판을 공개합니다.


아무래도 시간이 좀 지난거라서 달라진 부분들도  있을꺼고,

미처 잘못 작성된 것을 수정하지 못한 부분들도 있을 수 있습니다.


하지만, 커다란 맥락에서는 큰 부분이 달라지지는 않았으리라.. 생각하고..

달라지는 부분들도 기존의 것들을 알고 있어야 할 것이라고 생각하기 때문에...


2016년 크리스마스를 앞두고... PDF판으로 공개를 합니다.

표지,간지를 포함하여.. 무려. 192페이지에 달하는...


누군가에게는... 도움이 되기를 바라며... ^^

 

p.s. 2016년에는.. 기존의 포스팅과 더불어... 또 다른.. 장기 시리즈가 시작되지 않을까? 싶습니다..

 

 

 

 

Nexus_기초따라잡기(공개).z01

Nexus_기초따라잡기(공개).z02

Nexus_기초따라잡기(공개).zip


Posted by 네떡지기
DevOps/Programmability2015.02.17 20:35

NX-API

 

기존의 Python for Networker라는 주제로 포스팅하던 것을, 주제를 넓혀보고자..

Programmability for Networker로 이름을 변경하고 지속해서 시작합니다. ^^;

이번 포스팅은 Cisco의 Programmability를 지원하는 NX-API에 대한 포스팅입니다.  


 

NX-API  - Cisco Programmability

 

◈ NX-API

    - HTTP/HTTPS의 RPC 기반의 API 기능 수행

    - 'show', 'configuration', 'Linux Bash' 지원

    - JSON-RPC를 지원

    - Cisco Nexus 9000 platform 적용

 

 

◈ NX-API 동작

    - HTTP/HTTPS로 전송되며, 해당 CLI는 HTTP/HTTPS의 POST body로 encode된다.

    - Nexus 장비에서는 이러한 NX-API를 위해서 Nginx HTTP Server를 사용한다.

    - Nginx와 모든 하위 Process는 Linux cgroup의 메모리 제한 값을 초과하면, Process가 재시작 되도록 하여, 본 장비 리소스를 보호한다.

 

 

◈ NX-API 명령 포맷

    - Nexus 9000의 향상된 NX-OS CLI

    -  XML 출력,JSON 형태 출력

 

 

◈ NX-API 기능 활성화

    - NX-API feature 활성화 필요 ( Default : Disable)

NX-OS#(config)# feature nxapi

 

 

◈ NX-API Sandbox

    - HTTP/HTTPS를 사용하여, 사용자가 Cli 명령을 특정 Command Type, Output Type을 지정해서 사용할 수 있는 웹기반 인터페이스

    - NX-API Feature를 활성화 후, nxapi sandbox를 사용 할 수 있다.

NX-OS#(config)# nxapi sandbox

     - 접속 방법 : Web 브라우저에서 http://mgmt-ip  로 접속

 

 

◈ NX-API Request Element

    ○ Input

         - 1개 이상의 명령어 입력 가능. (단, 동일한 Messaage Type이어야 함 : Show, Configuration, bash)

         - Show와 Conf의 경우에는 다수의 명령어 입력 시, ';'(세미콜론)을 사용하며, 명령어와 세미콜론 사이는 1칸의 공백 필요

              ex) show interface brief ; show version  or  interface eth2/1 ; switchport ; no shut

         - Bash의 경우에는 다수의 명령어 입력 시, 마찬가지로 ';'(세미콜론)을 사용하지만, 명령어와 세미콜론 사이의 공백이 없어야 함.

             ex) cd /bootflash;mkdir zigi_dir

     

 

    ○ Type

        - cli_show : 구조화 된 결과값을 나타냄. 만약 XML을 지원하지 않는 명령 입력 시에는 error 메시지를 리턴

                              즉, 특정 명령어에 대해서만 구조화된 결과값을 나타내도록 지원. 

        - cli_show_ascii : ASCII 값으로 결과 출력.

        - cli_conf : Configuraion 명령 사용 시 사용

        - bash : Bash 명령 사용 ( NX-API에서는 non-interacitve Bash 명령을 지원)

        * 최대 10개의 Show 명령을 동시에 지원. (10개 이상 입력 시, 11번째부터는 무시 됨.)

        * ASCII의 경우에는 '|' (Pipe) 가 지원 됨. (XML의 경우에는 미 지원)

 

    ○ output_format 

        -  XML / JSON 포맷을 지원

        -  N9K는 XML을 지원하며, JSON은 XML을 전환하여 결과 값을 만든다.

   

 

◈ NX-API Response Element

     ○ version

         - NX-API Version (현재 1.0 / dCloud에서는 0.1 Version 지원)

     ○ type

         - 명령 실행 타입 (cli_show, cli_show_ascii, cli_conf, bash)

     ○ sid

         - 응답에 대한 Session ID.

         - 응답메시지가 chunked인 경우에만 유효함.

    ○ outputs

         - 요청한 전체 명령에 대한 출력 값을 감싸고 있는 Tag

         - cli_show, cli_show_ascii 의 경우에 다수의 명령어를 요청한 경우 각 개별 명령은 output tag가 붙는다.

    ○ output

         - 요청한 개별 명령에 대한 출력 값을 감싸고 있는 Tag

    ○ intput

         - 요청한 명령어

    ○ body

         - 요청한 명령어에 대한 응답

    ○ msg

         - 요청에 대한 응답의 처리 결과 메세지. code Element의 내용으로 확인 가능.

    ○ code

         - 요청에 의한 응답의 결과에 따른 Code번호.

         - NX-API에서는 표준 HTTP의 Status Code값을 사용한다.  

 

[ NX-API SandBox 실행화면 ]

 

 

◈ NX-API Sandbox 화면 구성

     ○ 상단 화면

 

 

         - 실행행하고자 하는 Command 와 Meassage format, Command Type을 지정할 수 있다.

            - POST 버튼은 위에서 지정한 Command와 Format/Type에 맞춰서 Request 코드가 만들어면서, Request가 이뤄진다.

 

    ○ 하단 좌측

 

 

 

 

            - 상단화면에서 지정한 내용에 따라서 만들어진 Request 내용을 출력

            - Python 버튼을 누르면, 해당 Request를 사용 할 수 있는 Python 코드로 생성 됨.

 

      ○ 하단 우측

 

 

         - 상단화면에서 요청한 내용에 대한 결과 값을 출력.

 

 

 

 NX-API Sandbox 실행 예제 -  JSON - cli_show

    

 

 

 NX-API Sandbox 실행 예제 -  JSON - bash

 

 

 NX-API Sandbox 실행 예제  -  Request를 Python Code로 변경

 

 

◈ NX-API Response Code

 

NX-API Response

Code

Message

SUCCESS

200

Success.      

CUST_OUTPUT_PIPED

204

Output is piped elsewhere due to request.

BASH_CMD_ERR

400

Input Bash command error.   

CHUNK_ALLOW_ONE_CMD_ERR

400

Chunking only allowed to one command. 

CLI_CLIENT_ERR

400

CLI execution error.    

CLI_CMD_ERR

400

Input CLI command error.   

IN_MSG_ERR

400

Request message is invalid.   

NO_INPUT_CMD_ERR

400

No input command.    

PERM_DENY_ERR

401

Permission denied.     

CONF_NOT_ALLOW_SHOW_ERR

405

Configuration mode does not allow show .

SHOW_NOT_ALLOW_CONF_ERR

405

Show mode does not allow configuration. 

EXCEED_MAX_SHOW_ERR

413

Maximum number of consecutive show
commands exceeded. The maximum is 10.

MSG_SIZE_LARGE_ERR

413

Response size too large.   

BACKEND_ERR

500

Backend processing error.    

FILE_OPER_ERR

500

System internal file operation error.  

LIBXML_NS_ERR

500

System internal LIBXML NS error.  

LIBXML_PARSE_ERR

500

System internal LIBXML parse error.  

LIBXML_PATH_CTX_ERR

500

System internal LIBXML path context error. 

MEM_ALLOC_ERR

500

System internal memory allocation error.  

USER_NOT_FOUND_ERR

500

User not found from input or cache.

XML_TO_JSON_CONVERT_ERR

500

XML to JSON conversion error.  

BASH_CMD_NOT_SUPPORTED_ERR

501

Bash command not supported.   

CHUNK_ALLOW_XML_ONLY_ERR

501

Chunking allows only XML output.

JSON_NOT_SUPPORTED_ERR

501

JSON not supported due to large amount of output.

MSG_TYPE_UNSUPPORTED_ERR

501

Message type not supported.   

PIPE_OUTPUT_NOT_SUPPORTED_ERR

501

Pipe operation not supported.   

PIPE_XML_NOT_ALLOWED_IN_INPUT

501

Pipe XML is not allowed in input.

RESP_BIG_JSON_NOT_ALLOWED_ERR

501

Response has large amount of output. JSON not
supported.

STRUCT_NOT_SUPPORTED_ERR

501

Structured output unsupported.    

 

 

※ 참고

http://www.google.co.kr/url?url=http://www.jedelman.com/home/introduction-to-using-cisco-nx-api&rct=j&frm=1&q=&esrc=s&sa=U&ei=R2HhVIi2Ioqa8QXqtYAw&ved=0CDMQFjAF&usg=AFQjCNE6Udq_iqse1vYQpq12BtIIiKVOXA

http://keepingitclassless.net/2014/02/cisco-aci-nexus-9000-nxapi/

http://jeffostermiller.blogspot.kr/2015/01/my-first-python-script.html#!/2015/01/my-first-python-script.html

 

Posted by 네떡지기
분류없음2015.02.15 17:42

 

Nexus Ping Drop 관련 이슈가 예전에  있어서 확인하고 조치하였다가,

네전따 카페에서 다른 분이 동일한 증상이 있어서, 알려드렸었는데 오늘 문득 또 다른 분이

쪽지로 물어오신 김에 아주 짧고 간단하게 정리하고 넘어가봅니다. (그 분도 이 증상이 맞는지 모르겠네요..)

 

Nexus 장비에서 간헐적으로 Ping Loss가 발생하는 경우가 있었습니다.

(짧게 정리할 것이기 때문에 각설하고 바로 결론..)

Nexus 7K에서는 Control Plane을 보호하기 위해서 CoPP(Control Plane Policing)이 기본적으로 활성화 되어 있습니다.

아래와 같이 내용을 확인할 수 있으며,

 

NX-OS# show run copp
<snip>
control-plane
   service-policy input copp-system-policy

 

해당 설정을 제거하고, 다시 Ping을 해보면 정상적으로 Ping이 나가는 것을 볼 수 있습니다.

 


※ 관련 링크
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/4_1/nx-os/security/configuration/guide/sec_nx-os-cfg/sec_cppolicing.html#wp1082584

 

 

https://supportforums.cisco.com/document/59621/icmpping-drops-when-pinging-nexus-7000?utm_source=twitterfeed&utm_medium=twitter

 

http://www.cisco.com/c/en/us/support/docs/switches/nexus-7000-series-switches/116043-copp-nexus7000-tshoot-00.html

 

http://www.cisco.com/c/en/us/support/docs/switches/nexus-7000-series-switches/116043-copp-nexus7000-tshoot-00.html#anc5

 

 

 

Posted by 네떡지기
분류없음2015.01.26 18:39

Nexus 7000 6.2(8) Bug Issue 공유 

 

Nexus 7000 운영 중, 서버쪽에서 Polling Target IP를 중간 중간 놓치는 지속적으로 놓치는 이슈가 있었습니다.

확인해보니, Nexus 7000에서의 Mac-Address Table이 지속적으로 갱신되고 있었습니다.

Mac-Address  Table이 계속 갱신되면서, Mac-Address의 수량도 계속 오르락 내리락을 반복하였습니다.

 

이런 저런 내용들을 확인해보다 보니, 아래와 같이 TCN이 지속적으로 발생하여 Mac-Address Table이 갱신됨을 확인하였습니다.

 

Nexus# sh spanning-tree detail | inc exec|from|occur

VLAN0100 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 77117 last change occurred 0:00:01 ago
          from port-channel1
 VLAN0101 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 77203 last change occurred 0:00:01 ago
          from port-channel1
 VLAN0102 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 12746 last change occurred 0:00:00 ago
          from port-channel1
 VLAN0103 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 63911 last change occurred 0:00:01 ago
          from port-channel1

 

계속해서 TCN에 의해 지속적으로 Mac-Address Table이 갱신됩니다.

 

결론만 얘기하자면, Nexus 7000시리즈 6.2(8)에서의 OS Bug Issue였습니다.


Bug에 대한 정보는 아래와 같습니다.


DDTS No(s): 

CSCuo80937
Headline: Nexus 7000 Stuck Sending TCNs Every 35 Seconds

 

Maintenance DDTS [These are defects that did not cause this advisory, however fixes are included in the solution]:


100일 이상 Uptime 시에 해당 이슈가 발생 가능한 OS Bug로, 2014년 6월에 확인되었다고 합니다.

해당 버그는 6.2(8)a 버전에서 해결되었다고 합니다. 


동일 버전을 사용하시는 분들은 참고하시면 될 것 같습니다. 

 

 

Posted by 네떡지기

티스토리 툴바