이번 포스팅은 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
root 8869 2.3 1.6 1884628 263536?Ss 2017 844:25/isan/bin/stats_manager

 

빨간색으로 표기되는 값이 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
Load average:1 minute:1.34 5 minutes:1.46 15 minutes:1.51
Processes:608 total, 1 running
CPU states:6.9%user, 3.0%kernel, 90.1%idle
Memory usage:24500980K total, 12353268K used, 12147712K free
Current memory status:OK

 

참고로 만약에 이 Bug로 장비가 재기동된 경우에 장비의 reset-reason을 확인하면 다음과 같이 나오게 됩니다.

ZIGI_leaf1#show system reset-reason
***************module reset reason(1)***********
0)At 2018-02-24T 13:00:00.312+09:00
Reason:reset-triggered-due-to-ha-policy-of-reset
Service:stats_manager hap reset
Version:12.0(2h)

 

Posted by 네떡지기
DevOps/Programmability2018.02.07 08:02

안녕하세요.

이번 포스팅은 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을 설정하셔야 하는 경우에 이 코드를 사용하시면 조금은 쉽게 설정이 가능하실 겁니다.

물론 자동화의 장점은 설정에 대한 편의성도 있지만, 잘못된 설정으로 인한 휴먼에러의 방지도 가능할 것입니다.

 

참고로, 위의 코드에서는 설정 시의 기본 예외처리만 만들었으며

기타 다른 상황에 대한 세부 예외 처리가 되어 있지 않기 때문에 더 보완해서 사용해보시는 것도 좋을 것 같습니다.

 

 

Posted by 네떡지기
분류없음2018.01.13 17:21

Today Key : Azure, Windows, Server, 한글, Korean, 언어팩, language, pack

 


Microsoft Azure에서 Windows 서버 한글화 하기

 

이번 포스팅은 Azure에서 Windows 서버를 만든 후에 한글 언어팩을 설치하여 적용하는 간단한 포스팅입니다.

아래의 그림대로 차례대로 따라하면 손쉽게 적용이 가능할 것입니다.

본 에제는 Azure에서 Windows 2016 Datacenter를 생성 한 후에 적용한 내용입니다.

 


 

 

 

Azure에서 Windows 서버를 생성하게 되면, 기본적으로 우리에게 익숙하지 않은 영문판이 아래 처럼 '안녕!' 하고 인사를 합니다.

 

 

 

 

 

이번 포스팅에서는 Azrue에서 생성한 윈도우 서버를 우리에게 친숙하도록 한글 언어팩을 설치하고 적용하는 과정을 살펴보도록 하겠습니다.

 

 

 

먼저 언어팩 설치를 위해서 제어판(Control Panel)을 하단의 윈도우 모양 키를 눌러서 찾아, 클릭합니다.

 

 

 

 

제어판을 열면, 다음과 같은 메뉴가 나오는 데, 여기서,

'Clock, Language, and Region' 메뉴에서 Add a language를 선택합니다.

 

 

 

Language를 메뉴를 들어가면, 기본 언어로 설정된 English(United States)만 있음을 볼 수 있습니다.

여기서, Add a language 를 클릭합니다.

 

 

추가할 언어에서 '한국어(Korean)'를 선택합니다.

 

 

 

한국어를 선택하고 나서, 다시 메뉴를 보면 한국어가 추가되어 있음을 볼 수 있습니다.

여기서 한국어를 선택하고 Move-up 을해서 위로 올려줍니다.

 

 

한국어가 이제 최상단에 위치했습니다.

이제 한국어의 Option 메뉴를 들어갑니다.

 

 

Windows diplay language 아래에 Download and install language pack 메뉴를 선택하여 언어팩을 설치합니다.

 

 

이제 드디어 언어팩을 설치하고 있습니다.

 

 

 

설치가 모두 완료되면,

 

 

 

현재 로그인된 서버를 sign-out으로 다시 나간 후에 새로 들어옵니다.

 

 

새로 윈도우로 붙으니, 드디어 우리눈에 익숙한 한글이 보이는 것을 확인 할 수 있습니다.

 

 

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 네떡지기
분류없음2018.01.04 13:00

Today Key : Team, Windows, 가용성, 이중화, 네트워크, Teaming, 티밍


이번 포스팅은 서비스 가용성을 확보하기 위한 서버의 네트워크 이중화에 관한 내용입니다.

운영체제에 따라서, 이러한 이중화 기술을 부르는 명칭이 다른 데,

Windows의 경우에는 Teaming, Linux의 경우에는 Bonding이라고 합니다.

이번 포스팅에서는 Windows의 Teaming 설정 방법에 대해서 알아보겠습니다.

본 포스팅의 예제는 Windows Server 2016 Datacenter에서 진행 했습니다.


Windows Server Teaming 설정

 

 

서버 관리자에서 '로컬 서버' 를 선택합니다.

중간 쯤에 NIC 팀(Team)설정 을 선택합니다.

 

 

 

 

NIC 팀에서는 어댑터 및 인터페이스에서 '네트워크 어댑터' 에서 현재 사용가능한 어댑터 확인이 가능합니다.

왼쪽의 팀에서 '작업'을 클릭해서 보면, '새 팀' 이 있습니다. '새 팀'을 눌러서 새로운 Team 설정을 합니다.

 

 

 

 

새로운 팀 인터페이스 설정을 합니다.

팀 인터페이스의 이름을 지정하고, 해당 인터페이스에 할당한 어댑터를 선택합니다.

 

 

 

 

 

추가 속성을 설정하고자 할 때에는 '추가 속성'을 클릭해서 지정합니다.

 

 

 

 

설정이 끝나고 나면, '팀' 인터페이스가 좌측에 만들어 진 것을 확인 할 수 있습니다.

 

 

 

 

네트워크 연결 상태에서도 보면, 새로운 팀 인터페이스에 대한 어댑터가 생성된 것을 볼 수 있습니다.

 

 

 

 

 

 

 




 

Posted by 네떡지기
분류없음2018.01.02 09:47

 

Today Key : Server, Network, Check, 서버, 네트워크, 확인, 체크, 명령어, command, ping, tcping, tracert, tcproute


이번 포스팅은 서버에서의 네트워크를 확인하기 위한 몇 가지 명령에 대해서 알아 보겠습니다.

 

이번 포스팅에서 다뤄지는 내용은 서버를 네트워크에 연결하는

초기 구성 시에  서버의 네트워크 설정이 잘 되었는지 확인 하기 위해서 사용하기도 하지만,

갑자기 서버가 정상적으로 통신이 되지 않거나 서비스가 정상적으로 제공 되지 않는 문제가 발생 할 경우에  더 유용하게 사용될 수 있습니다.

 

이번 포스팅에서는 윈도우에서 사용 가능한 명령에 대해서 살펴보지만,

실제 리눅스에서도 거의 동일하게 사용이 가능합니다.

향후 포스팅에서는 리눅스에서의 사용 방법이나, 아래의 명령어 이외에 추가적인 네트워크 확인을 위한 명령에 대해서 살펴보도록 하겠습니다.


 

Ping

네트워크 상태를 확인하는 데, 가장 많이 사용되는 명령어이며 또한

네트워크 엔지니어나 서버 엔지니어에게나 모두 익숙한 명령입니다.

Ping은 IP 네트워크를 통해서 목적지까지 정상적으로 네트워크가 잘 도달하는지를 확인 할 수 있습니다.

 

 ping [옵션] 목적지_IP주소

 

ping에서 사용되는 주요 옵션은 다음과 같습니다.

주요 옵션

리눅스

-n count

Ping을 보내는 패킷(ECHO_REQUEST) 을 몇 번 보내고 종료할 것인지를 지정.

기본 설정은 4회 전송

-t

중지될 때가지 지정한 호스토로 지속적으로 ping 전송..

-S srcaddr

사용할 원본 IP주소로, 리눅스의 –I 옵션과 동일

-size

패킷 크기를 지정. 기본 설정 값은 32바이트

-r count

count 홉의 경로를 기록(최대 9홉까지 설정 가능)

 

 

 

tcping

ping이 목적지까지의 네트워크가 정상적으로 도달하는지 주로 사용하는 명령어이지만,

실제 목적지까지 가는 경로 상에서는 ping에 대해서 보안장비에서 차단하는 경우가 있습니다. 

가장 대표적인 예를 들면, ping naver.com 을 하게 되면 다음과 같은 결과를 확인할 수 있습니다.  

따라서, 목적지까지 정상적으로 서비스가 되는지 확인하기 위해서는 단순히 ping이 아니라

실제 서비스 포트까지도 고려해서 테스트 해야 하는 경우가 있을 수 있습니다.

이럴 때 사용할 수 있는 것이 tcping 입니다.

tcp의 서비스 포트를 사용해서 테스트를 하는 것으로 실제 목적지까지의 서비스가 정상적으로 열리는지를 확인 할 수 있습니다.

실행 결과는 다음과 같이 볼 수 있습니다.

 

tcping의 사용 방법은 일반 ping의 사용법과 동일합니다.

 tcping [옵션] 목적지_IP주소

 

tcping에서 사용되는 주요 옵션은 다음과 같습니다.

주요 옵션

윈도우

-n count

tcping을 전송하는 횟수 (기본 5)

-t

중지될 때가지 지정한 호스토로 지속적으로 ping 전송..

-i interval

tcping을 전송하는 시간 간격

serverport

tcping으로 확인하고자 하는 서비스 포트이며, 미 설정 시에 80이 기본 값

 

* tcping은 기본 윈도우 프로그램이 아니기 때문에 아래의 사이트에서 다운받아서 사용할 수 있습니다.

      https://elifulkerson.com/projects/tcping.php

 

 

 

tracert

 

ping은 네트워크 상태를 확인하는 데, 가장 많이 활용되지만 그만큼 많이 사용되는 명령어가 tracert입니다.

ping 출발지부터 목적지까지의 통신이 되는지 단순히 체크만 한다면, tracert는 출발지부터 목적지까지의 통신이 되는지에 대한 체크를

통과하는 중간 경로를 출력해서 확인하게 됩니다.

 

tracert는 IP 헤더의 TTL(Time To Live) 필드를 이용합니다.

TTL을 1부터 1씩 증가시키면서 목적지에 도달 할 때까지 반복해서 패킷을 전송하면서 경로를 추적하게 됩니다.

네트워크 구간에서 라우터 장비를 하나 지날 때 마다 패킷의 TTL 값이 1씩 줄어들게 되고,

TTL 이 0이 되는 순간 해당 라우터에서 이 패킷을 드랍시키고

패킷 드랍의 이유를 출발지 단말에 icmp 메시지를 이용해서 알려주게 됩니다.

 TTL이 1인 경우에는 1홉까지의 장비로 전달이 되고, TTL이 0으로 만료가 되면서

해당 장비는 ‘ICMP time exceed’ 메시지를 출발지로 전달하게 됩니다.

tracert는 이 메시지를 전달한 장비의 IP를 출력하는 과정을 반복하면서 경로를 추적하는 작업을 하게 됩니다

tracert의 사용법은 다음과 같습니다 .

 tracert [옵션] 목적지_IP주소

 

tracert에서 사용되는 주요 옵션은 다음과 같습니다

주요 옵션

리눅스

-d

IP 주소를 도메인이 아닌 숫자 형식으로 표시(도메인 리졸브 미 수행)

-h maximum_hops

대상 검색을 위한 최대 홉 수

 

 

tcproute

tcproute는 이름에서 대충 감을 잡을 수 있듯이, tracert의 tcp 버전입니다.

마치 앞에서 알아본 ping에 대한 tcping 과 같은 명령어입니다.

tracert를 통해서 출발지부터 목적지까지의 경로를 체크하는 것을 서비스 포트를 이용해서 체크하는 방법입니다.

사용하는 방법은 tracert와 동일하며, 서비스 포트를 별도로 지정하는 등의 옵션을 사용할 수 있습니다 .

 tcproute [옵션] 목적지_IP주소          

tcproute 에서 사용되는 주요 옵션은 다음과 같습니다 

주요 옵션

리눅스

-p PORT

목적지 서비스 포트 지정

-d

IP 주소를 도메인이 아닌 숫자 형식으로 표시(도메인 리졸브 미 수행)

-i INT#

특정 인터페이스로 출발지 인터페이스를 지정

해당 옵션 미 사용 시에는, 명령 실행 시 인터페이스를 선택하게 됨.

--http

HTTP request를 보내서 접속 확인

* tcping과 마찬가지로 tcproute도 기본 윈도우 프로그램이 아니기 때문에 아래의 사이트에서 다운받아서 사용할 수 있습니다.

https://www.elifulkerson.com/projects/tcproute.php

 

 



Posted by 네떡지기

 

정말 정말 오랜만에 남기는 포스팅입니다.

이번 포스팅은 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 DirectionEgress로 권고합니다.

* 단, 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 DirectionEgress 을 선택합니다.

※가이드 문서에 따르면, 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 key 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년여간 생각치도 못한 일정 등으로 인해서 미뤄두고 있었습니다.

내년에는 그간 미뤄두었던 포스팅을 좀 더 해서, 조금이나마 여러분들께 공유할 수 있도록 하겠습니다.


Posted by 네떡지기
네트워크/L4 Swtich2017.12.21 09:41

NetScaler 라이선스 별 지원 기능

 

장비에서 라이선스 확인 - CLI

ZIGI-NetScaler#> show ns license
        License status:
                           Web Logging: YES
                      Surge Protection: YES
                        Load Balancing: YES
                     Content Switching: YES
                     Cache Redirection: YES
                          Sure Connect: YES
                   Compression Control: YES
                     Delta Compression: NO
                      Priority Queuing: YES
                        SSL Offloading: YES
          Global Server Load Balancing: YES
                        GSLB Proximity: YES
                   Http DoS Protection: YES
                       Dynamic Routing: YES
                     Content Filtering: YES
                   Content Accelerator: YES
                    Integrated Caching: YES
                               SSL VPN: YES  (Maximum users = 5)  (Maximum ICA users = Unlimited)
                                   AAA: YES
                          OSPF Routing: YES
                           RIP Routing: YES
                           BGP Routing: YES
                               Rewrite: YES
             IPv6 protocol translation: YES
                  Application Firewall: YES
                             Responder: YES
                        HTML Injection: YES
                        NetScaler Push: YES
                   Web Interface on NS: YES
                               AppFlow: YES
                           CloudBridge: YES
                          ISIS Routing: YES
                            Clustering: YES
                              CallHome: YES
                                AppQoE: YES
                       Appflow for ICA: YES
                                  RISE: YES
                                 vPath: YES
                Front End Optimization: YES
                          License Type: Platinum License
 Done
ZIGI-NetScaler#>

장비에서 라이선스 확인 - GUI

 

장비 기능별 활성화 확인 - CLI

ZIGI-NetScaler#> show ns feature

        Feature                        Acronym              Status
        -------                        -------              ------
 1)     Web Logging                    WL                   OFF
 2)     Surge Protection               SP                   OFF
 3)     Load Balancing                 LB                   ON
 4)     Content Switching              CS                   OFF
 5)     Cache Redirection              CR                   OFF
 6)     Sure Connect                   SC                   OFF
 7)     Compression Control            CMP                  OFF
 8)     Priority Queuing               PQ                   OFF
 9)     SSL Offloading                 SSL                  ON
 10)    Global Server Load Balancing   GSLB                 OFF
 11)    Http DoS Protection            HDOSP                OFF
 12)    Content Filtering              CF                   ON
 13)    Integrated Caching             IC                   OFF
 14)    SSL VPN                        SSLVPN               ON
 15)    AAA                            AAA                  ON
 16)    OSPF Routing                   OSPF                 OFF
 17)    RIP Routing                    RIP                  OFF
 18)    BGP Routing                    BGP                  OFF
 19)    Rewrite                        REWRITE              OFF
 20)    IPv6 protocol translation      IPv6PT               OFF
 21)    Application Firewall           AppFw                OFF
 22)    Responder                      RESPONDER            ON
 23)    HTML Injection                 HTMLInjection        OFF
 24)    NetScaler Push                 push                 OFF
 25)    AppFlow                        AppFlow              OFF
 26)    CloudBridge                    CloudBridge          OFF
 27)    ISIS Routing                   ISIS                 OFF
 28)    CallHome                       CH                   OFF
 29)    AppQoE                         AppQoE               OFF
 30)    vPath                          vPath                OFF
 31)    Content Accelerator            ContentAccelerator   OFF
 32)    RISE                           RISE                 OFF
 33)    Front End Optimization         FEO                  OFF
 Done
ZIGI-NetScaler#>

 

 

장비 기능별 활성화 확인 - GUI

Posted by 네떡지기
네트워크/L4 Swtich2017.12.20 00:30

NetScaler

Service에서 Access Down 옵션 설정 체크

일반적으로는 비활성화 된 서비스에 대해서 요청이 들어오게 되면, 해당 요청은 허용되지 않지만 Access Down 옵션을 사용하면 됩니다.

이를 위해서는 계층 2 모드가 활성화 되어 있어야 합니다. 

※ NetScaler의 동작 모드 중에서 Layer 2 Mode와 Layer 3 Mode는 한 가지를 선택할 수 있는 것이 아니라,

    개별적으로 각 모드를 활성화 혹은 비활성화 해서 사용할 수 있음.

 

 

 

 

 

 

Posted by 네떡지기
분류없음2017.12.08 16:48

인터페이스 타입

 

  • OTU1: OTN services with the rate being 2.67 Gbit/s.
  • 10GE LAN: Ethernet services with the rate being 10.31 Gbit/s. The 10GE LAN services can be mapped in two modes: Bit Transparent Mapping (11.1 G) and MAC Transparent Mapping (10.7 G).
  • 10GE WAN: Ethernet services with the rate being 9.95 Gbit/s.
  • STM-1: SDH services, the rate is 155.52 Mbit/s.
  • STM-4: SDH services, the rate is 622.08 Mbit/s.
  • STM-16: SDH services, the rate is 2.488 Gbit/s.
  • STM-64: SDH services, the rate is 9.95 Gbit/s.
  • OC-3: SONET services, the rate is 155.52 Mbit/s.
  • OC-12: SONET services, the rate is 622.08 Mbit/s.
  • OC-48: SONET services, the rate is 2.488 Gbit/s.
  • OC-192: SONET services, the rate is 9.95 Gbit/s.
  • FE: Fast Ethernet services with the rate being 125 Mbit/s. Supports FE optical signals and FE electrical signals.
  • GE: Gigabit Ethernet services with the rate being 1.25 Gbit/s. Supports GE optical signals and GE electrical signals.
  • ESCON: Enterprise system connection services with the rate being 200 Mbit/s.
  • FC100: Fiber channel services with the rate being 1.06 Gbit/s.
  • FC200: Fiber channel services with the rate being 2.12 Gbit/s.
  • FC400: Fiber channel services with the rate being 4.25 Gbit/s.
  • FC800: Fiber channel services with the rate being 8.5 Gbit/s.
  • FC1200: Fiber channel services with the rate being 10.51 Gbit/s.
  • FICON: Fiber channel services with the rate being 1.06 Gbit/s.
  • FICON 4G: Fiber channel services with the rate being 4.25 Gbit/s.
  • FICON 8G: Fiber channel services with the rate being 8.5 Gbit/s.
  • FICON 10G: Fiber channel services with the rate being 10.51 Gbit/s.
  • FICON EXPRESS: Fiber channel services with the rate being 2.12 Gbit/s.
  • DVB-ASI (Digital Video Broadcasting -Asynchronous Serial Interface): Digital TV services with the rate being 270 Mbit/s.
  • SDI (Digital Video Broadcasting - Serial Digital Interface): Digital TV services with the rate being 270 Mbit/s.
  • HD-SDI: High-definition digital TV services with the rate being 1.485 Gbit/s or 1.4835 Gbit/s.
  • 3G-SDI: High-definition digital TV services with the rate being 2.97 Gbit/s.
  • CPRI option2: the rate is 1.2288 Gbit/s.
  • CPRI option3: the rate is 2.4576 Gbit/s.
  • CPRI option6: the rate is 6.144 Gbit/s.
  • CPRI option7: the rate is 9.83 Gbit/s.  
  • Metropolitan_and_Wide_Area_Storage_Networking.pdf

     

    Posted by 네떡지기

    티스토리 툴바