'Leak'에 해당되는 글 2건

  1. 2018.02.09 [Bug Report] ACI : Memory Leak
  2. 2018.01.04 Cisco ACI - Inter Tenant / Inter EPG

이번 포스팅은 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 네떡지기

안녕하세요. 

이번 포스팅은 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 네떡지기

티스토리 툴바