'Guide'에 해당되는 글 2건

  1. 2017.12.29 Cisco ACI - Design Part 1 (2)
  2. 2014.05.11 Nexus : NX-OS Part31(FabricExtender-3)

 

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

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

 

○ Last Updated : 2014.05.22

○ Update History

     * NX-OS 6.2(2)의 변경 가이드라인 추가


이번 포스팅은 최근 포스팅 중에 제일 짧게 끊어가는 내용인 듯 싶습니다.

좀 더 이어서, FEX Configuration을 하려고 했으나 Configuration은 개별 포스팅을 가져가는 게 나을 듯 싶어서..

주중에 추가 포스팅을 약속하며~ 이번 포스팅은 짧게 끊어가겠습니다.


FEX Port Numbering

 

interface ethernet chassis/slot/port

•chassis ID 는 관리자에 설정된다.

•chassis ID 101 ~ 199까지 설정 가능하다.

chassic ID Fabric Extenderhost interface로 접근할 때만 필요하다.  101 이하의 값은 Parent Switch Slot을 나타낸다.

•slotFabric Extender Slot 번호이며, portslotchassis ID의 구체적인 Port 번호이다.

 

 

 

ACL & IGMP Snooping

•Fabric Extender ingress access control list를 지원한다. (Parent Switch에서 설정)

•Fabric Extender는 모든 Host Interface에서 IGMP Snooping을 지원하는 데, Destination multicast MAC Address 기반의  IGMPv2IGMPv3

   지원하며, Source MAC Addressprexy reports 기반의 snooping은 지원하지 않는다.

 

 

 

FEX 가이드라인 & 제약사항

• NX-OS 5.2 이후의 Default Port modeLayer 3이며, 그 이전에는 Layer 2이다.

          - 만약 5.2 이전 버전에서 OSUp-grade하게 될 경우에는 기존 Layer 2 설정을 유지하게 된다.

• Default VDC에서 먼저 Fabric Extender feature set Install 하여야 하며,

  이후에는 Default VDC를 포함한 모든 VDC에서  활성화하여 사용 가능하다.

• Fabric Extender를 Nexus 7000에 연결 시에는 Fabric ExtenderUplink / Host Port는 하나의 VDC에 속해있어야 한다.

   (하나의 Fabric Extender Port를 서로 다른 VDC에 할당할 수 없다.

• Fabric ExtenderNexus 7000에 연결 시에 다음 모듈에 연결해야 한다.

    -  32-port 10-Gigabit M1 module (N7K-M132XP-12)  

    -  32-port, 10-Gigabit M1-XL module (N7K-M132XP-12L

    -  M2 or  F2 module.

•Fabric Extender Feature 설정 시에, Standby Supervisorunstable state인 경우에 Reload 될 수 있다.  

   show module 명령을 통해서, Standby SupervisorStable 상태인지 체크할 수 있다. 정상인 경우에 ha-standby로 표시된다.

• Fabric Extender Interface는 오직 Edge Port로만 동작가능하며, 만약 Switch 연결이 감지되면 Error-disable 상태로 변경된다.

Fabric ExtenderHost InterfaceSpanning Tree Edge Port로만 동작하며, Network port로 설정할 수 없다.

   또한, BPDU Guard가 활성화되어 BPDU가 수신되는 Switch 연결 시에 Error-Disable 상태로 변하게 된다.

  Nexus 7000시리즈에 FEX를 연결 할 경우에 FEX host interfaceQueuing 기능이 제한된다. 

     SVI Interface를 사용한 Layer 2 혹은 Layer 3 FEX Interface로 연결된 RouterRouting Protocol Adjacency에 참여할 수 없다. 

     FEX Host Interface에서 혼잡이 발생한 경우에 Control plane Traffic이 우선순위가 아니기 때문에 FEX peer로써 사용될 수 없다.

     이러한 제약은 다른 Layer 3 Device(ASA, ACE, 기타 Dynamic Routing Protocol이 동작하는 Device)와 연결 시 동일하게 적용된다.

     , Static RouteRouterASA, ACE, 기타 Layer  3 Device로의 설정은 지원한다.

     → NX-OS 6.2(2)부터 Routing Peer 지원 (아래 참조)

• Fabric Extender PVLAN을 지원하지 않는다.

 

FEX 가이드라인 & 제약사항 (NX-OS 6.2(2) 이후 변경)

• Queuing을 지원하여, Layer 3와 Layer 2(SVI를 사용한) FEX Interface를 사용하여 Router와 연결 할 수 있다.

•  아래의 가이드 라인은 SVI를 사용한 FEX의 Layer 2 Interface를 사용한 경우이다.

       - Layer 3와 Layer 2(SVI를 사용하여 access 혹은 trunk interface 모드)의 Peer Device와 Routing Adjacency를 구성할 수 있다.

   ※ FEX Interface는 Spanning Tree Protocol을 지원하지 않기 때문에, Loop가 발생하지 않도록 네트워크를 구성해야 한다.

• CoS와 DSCP 값을 기반으로 한 Ethernet Frame Queuing과 FCoE Frame의 Queuing을 지원한다.

• FEX Port에서 Optimized Multicast Flooding(OMF)를 지원한다.

 

F2 시리즈 모듈 관련

•F2 Module은 다음 FEX Device만 지원한다.  [ 2248TP / 2248TP-E / 2232TP / 2232PP / 2232TM / 2224TP ]

•ASIC의 모든 PortIndex를 가지며, 다른 ASIC간의 Port Channel 구성 시에는 해당 Index가 동일해야 구성이 가능하다.

   예를 들어, Port 1Index 1을 갖고, Port 2 Index 2를 가질 때,

    - Supported : ASIC 1 Port 1 ASIC 2Port 1Port Channel로 구성.

    - Not Supported : ASIC 1Port 1ASIC 2 Port 2를 Port Channel로 구성 불가.

 

 

Posted by 네떡지기

티스토리 툴바