이번 포스팅은 ACI Bug Report 관련 내용입니다.

 

지난 포스팅(http://zigispace.net/957) 에 이어서, ACI OS Upgrade 중에 발생할 수 있는 Bug Report(CSCvb94260)입니다.

2.1미만의 버전에서 발생할 수 있다고 하기 때문에 2.1이상의 버전에서 더 상위 버전으로의 Upgrade에는 발생하지 않을 수 있습니다.

 

이 버그에 대한 증상은

 1. APIC 업그레이드 중에 먼저 진행된 APIC은 정상적으로 Upgrade가 완료되었으나, 이후에 업그레이드 되는 APIC의 상태가 75%에서 멈춰있게 됩니다.  이 경우 75%에서 멈춰있는 APIC에서 확인 할 때, 정상적으로 완료된 APIC의 정보가 기존 버전으로 표기

 

 2. 모든 APIC이 정상적으로 업그레이드가 되고, fully fit 상태까지 되었으나 각 장비에서 acidiag로 확인 시에는 local APIC에 대한 버전만 최신 버전이고 다른 APIC은 기존 버전으로 표기

 

상태를 확인해보면, APIC 2번기가 정상적으로 Upgrade된 상태에서 APIC 3번기가 Stuck이 걸려있을 때,

APIC 2번에서는 2번기 상태를 보면 정상적으로 Upgrade가 되어 있고

APIC 3번기에서 2번기를 상태를 보면, 기존 OS이고 time stamp도 정상적으로 업그레이드 된 시간보다 더 이후 시간으로 체크되어 있음.

 

apic2# acidiag avread | egrep "id=2.*version" | cut -d ' ' -f 7-10,20-21
appliance id=2 version=2.2(2k) lm(t):2(2017-07-25T11:24:01.244+10:00)

apic3# acidiag avread | egrep "id=2.*version" | cut -d ' ' -f 7-10,20-21
appliance id=2 version=2.0(2f) lm(t):2(2017-07-25T11:40:02.248+10:00)

 

2.1 이상에서는 해당 버그가 없기 때문에 2.1 미만의 버전에서만 발생합니다.

 

해당 버그가 발현될 경우에는

위의 예의 APIC 3에서 APIC 2의 정보를 정상적으로 가져오지 못한 상태가 되는 데,

APIC 2에서 "acidiag restart mgmt"를 통해서 APIC에 서비스를 재기동하면

APIC 3에서 APIC 2에 대한 정보가 업데이트 되면서, 정상적으로 Upgrade를 진행 할 수 있습니다.

 

 

 

Posted by 네떡지기

이번 포스팅은 ACI Bug Report 관련 내용입니다.

 

ACI OS Upgrade를 위해서 관리서버인 APIC을 먼저 OS Upgrade를 진행을 합니다.

APIC OS 업그레이드 과정 시, APIC의 재부팅을 하는 도중에 정상적으로 부팅을 하지 못하는 문제가 발생할 수 있습니다.

이 경우 장비에 Console을 붙여서 확인을 하면 다음과 같이 표기됨을 확인할 수 있습니다.

 

APIC 1 Console shows:
do_boot_cpu failed(-1) to wakeup CPU#2
do_boot_cpu failed(-1) to wakeup CPU#3
do_boot_cpu failed(-1) to wakeup CPU#4
do_boot_cpu failed(-1) to wakeup CPU#5
.
.
.
.
do_boot_cpu failed(-1) to wakeup CPU#23

 

 

관련하여 Bug Report(CSCvd84590:scale1-apic1: do_boot_cpu() failed at GRUB starting to boot the Kernel)가 있습니다.

 

해당 버그에 대해서 알려진 버전은 2.2(1.210a), 2.2(2i)이며,

fixed 버전은 3.1(1i), 3.1(0.154), 2.2(3.13)입니다.

 

실제 영향 받는 버전은 더 있을 것으로 보입니다.

 

해당 버그에 대한 조치 방법은 APIC 자체를 실제 전원까지 제거하여 Cold Reboot를 진행하시면 됩니다.

Posted by 네떡지기

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

 

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

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

티스토리 툴바