'Remote'에 해당되는 글 3건

  1. 2017.12.29 Cisco ACI - Design Part 1 (2)
  2. 2015.08.21 Docker : Part 6
  3. 2014.03.03 Nexus - NX-OS 정리 Part 25(FabricPath - 2)

 

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

이번 포스팅은 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.08.21 13:49

Docker,Remote, API,client,  library, python,host, 원격, 리모트, 도커, git : today Key

 

 Docker의 6번째 포스팅입니다. 이번 포스팅에서는 Docker를 Remote에서 제어할 수 있도록 제공되는 Remote API client libraries에 대해서 다뤄봅니다. 보안적인 측면보다는 최대한 우선 쉽게 접근하는 걸 목표로 잡고 있기 때문에 이 점은 감안해서 봐주시면 감사하겠습니다. ^^

이런 식으로 Docker를 Client에서도 다룰 수 있다는 것 정도로 보면 어떨까 싶습니다! ^^

물론 이러한 API를 활용하여 Docker Host를 관리하도록 한다면 Docker의 명령을 직접 입력하지 않고 Application을 클릭하는 것만으로도

docker를 관리할 수 있을 것입니다.


 

Docker Remote API Client libraries

    Docker에서는 Client가 Docker Host를 제어하기 위한 다양한 언어로 구성된 API Library에 대해 있음  

    Docker를 작성한 Go를 비롯한 다양한 언어에 대한 Library가 Git을 통해서 제공되기 때문에 원하는 언어를 선택 가능. 

    Client는 Host를 제어하는 역할이기 때문에 별도의 Docker Engine를 설치할 필요가 없으며,

       Windows,Mac 등에서도 직접 사용 가능.

    본 포스팅에서는 Windows기반의 PC에서 Python Library를 사용하여 Docker Host를 제어

   • Docker API LINK : https://docs.docker.com/reference/api/remote_api_client_libraries/

   

  

 

 

Docker Remote API Client libraries - Python

    Python용 Library를 설치

          - pip install docker-py  [ Docker Python Library가 있는 Git 페이지에도 나와있음 ]

          - https://github.com/docker/docker-py

 

 

    Python Shell에서 Docker Host에 접속 및 정보 확인

          - docker.client 라이브러리를 Load

          - Docker Host에 접속

              ※ Docker Host에서 기본 Unix Sock 접속이 아닌 TCP로 접속할 수 있도록 설정 필요.

          - info() 메서드를 사용하면 현재 Docker Host에 대한 정보를 확인할 수 있음.

 

 

   Docker Image 정보 확인

          - images() 메서드를 통해서 Docker Host에 있는 이미지 정보를 출력

          - docker images 역할

 

 

   Docker Image 정보 확인 변형

          - 위에 표기된 대로, 모든 정보가 다시 결과 값으로 리턴될 때의 사용자가 보기에는 조금 어렵게 리턴이 되게 되기 때문에 결과 값을

            아래와 같이 가공이 필요로 함.

          - originList() 메서드는 간략하게 결과 값을 가공하기 위해 만든 별도의 메서드

 

 

 

   Docker Image 정보 확인 변형2

      - originList() 메서드는 처음이 결과 값보다는 보기가 편하지만 그래도 여전히 보기가 쉽지 않고 필요한 정보 뿐만 아니라,

        필요 없을 수 있는 모든 정보들에 대한 결과를 보여주기 때문에 아래와 같이 필요한 정보에 대해서만 간략하게 보여줄 수 있도록

        메서드를 작성하는 것이 좋음.

      - ImageList() 메서드는 Image ID와 Repo, Tags, Virtual Size 에 대한 값만을 보여주도록 가공하도록 작성한 별도의 메서드.

 

 

   Docker Container 생성

      - create_container() 메서드를 사용하여 Container를 생성

      - start() 메서드에 매개변수로 생성된 Container 객체를 포함하여, Container를 Running 상태로 만듬.

      - start() 메서드에 의해 생성된 Container가 정상적으로 동작하는지 확인하기 위해서, 해당 Container에서 동작 중인 웹서비스 호출

 

 

      - containers() 메서드를 사용하면, 현재 동작 중인 Container의 정보를 볼 수 있음.

           : docker ps 역할

 

      - 아래의 실행 결과 값은 마찬가지로 originList() 메서드를 사용하여 전체 정보를 보기 쉽도록 가공.

 

 

 

 

Posted by 네떡지기

 

Last Updated  2014.03.06


 

1월에 포스팅을 하고, 3월이 되서야 드디어 다시 포스팅을 시작하게 되었습니다.

그 사이에는 참으로 다양한 사연들이 있어서 포스팅이 늦어졌다는 핑계를 대 봅니다...

2월 9일에 CCIE DC를 보기 위해 1월 중순부터는 거의 모든 것을 내 팽개치고..(설 연휴 반납.. ㅠㅠ) 거기에만 매달리고...

벨기에까지 무사히 잘 다녀와서. 다행히. 좋은 결과를.. (떨어지면 포스팅을 당분간 더 안했을 듯... )

하지만 다녀오자마자 그닥 좋지 않은 일들이 계속 생기고... 건강도 급격히.. 나빠지기도 했습니다. 이제 회복단계에 들어섰구요..

아직까지는 머리 속이 이래저래 복잡하지만!! 그래도 이제 다시 포스팅은 시작해보려고 합니다.

오늘 오늘은 간만에 가벼웁게 짧게 끊어가봅니다.. ^^ (길이가 짧다는 것일 뿐입니다... )

다음 포스팅은 조만간 다시 금세 올리도록 하겠습니다!

내용 중에 이상하거나 수정해야할 부분이 있으면 덧글 부탁드립니다

 


 

 

 

FabricPath Tree

• Known Unicast TrafficEqual-cost 경로로 Load-balancing 된다.       

Unknown Unicast / Broadcast / Multicast traffic 과 같은 Multidestination Frame  Load Balancing을 위해서

  Multidestination Tree를 사용한다.

• Multidestination TreeFabricPath IS-IS를 통해서 자동으로 2개의 Loop-FreeTree가 생성된다.

      ※ NX-OS 6.2(2) 이후부터는 하나의 Topology마다 2개의 Tree를 구성할 수 있다.

         그 이전에는 오직 하나의 Topology만 가능.

• Multidestination Tree2개의 서로 다른 TreeRoot를 선출하는 데,  FabricPath Domain 내의 우선순위가 가장 높은 2개의

  FabricPath Switch가 각각 Tree 1(1순위) / Tree2(2순위)Root가 된다.

• Root를 선출하기 위한 요소는 다음과 같다.

     - Highest root priority  [ 8bit ] :  0-255 까지 설정이 가능하며, Default64이다.

     - Highest system-id [ 48bit ] : VDC MAC Address

  - Highest switch-id [ 12bit ]

• RootIS-IS에 의해서 자동으로 선출되기는 하지만, ‘root-priority’ 명령을 사용하여 직접 Aggregation 혹은 Spine Switch로 지정하는 것을

  권고한다. 

• root-priority 값은 Fabric-Path Domain에서 설정하며, 높은 값이 우선순위가 높다.

TreeMultidestination Frame을 전송하기 위해서 사용되는 Forwarding TAG ( FTag )를 갖는다.

 

 

 

FabricPath Tree

• FabricPath Tree 1Unknown unicast / broadcast / multicast Traffic을 전송하고, Tree 2multicast 분산 Traffic을 처리한다.

     - 이는 F1 Module 기준이며, 이후에는 어떤 Tree로 전송을 할지에 대해서 hash 함수에 의해 결정한다.

        (HashDefault로 설정은 Source/Destination IP, Layer 4 Port 이다.)

Packet treeingress FabricPath SwitchPacket header를 확인해서 결정한다. 

• Tree 1 Root는 높은 SysID (priority + mac)Switch가 선정되며, Tree 2Root는 두 번째 높은 SysID를 가진 Switch가 선정된다.

FabricPathMulticast / Broadcast / Flooded TrafficMultidestination Tree를 따라 전송.

이를 위해 FabricPath FrameTag를 붙이는 데, 이를 Forwarding Tag 또는 FTag라고 함.

 

 

 

Fabric Path Conversational MAC Address Learning

 • NX-OS 5.1부터 F 시리즈 Module을 사용하는 경우에 Conversational MAC Address 학습을 할 수 있다.

    - 설정에 따라서 Conversational 또는 Traditional한 방법으로 학습

• F Series Module들은 16개의 Forwarding Engine을 가지고 있으며, Engine별로 별도의 Mac-Address Table을 가지고 학습을 한다.

• Traditional EthernetMac Address 학습은 Source address 기반으로 무조건 학습함으로써, Resource를 낭비하게 된다.

Conversational MAC 학습은 전체 도메인을 대상으로 하지 않고 각 Interface에서 관심 있는 Host에 대해서는 학습을 한다.

  Conversational MAC 학습은 3 way handshake로 구성되는 데,

  이러한 Conversational MAC 학습을 통해서 개별 Switch Mac Address Table의 한계를 넘어서 네트워크를 확장할 수 있게 된다.

Destination MAC 자신의 Local MAC Table에 존재하는 경우에만 Source MAC을 학습한다(Outer SA가 아님).

  , 상대방이 보내온 Frame에서 DestinationLocal MAC이라는 것은 자신이 Local이 목적지인 경우에만 MAC을 학습한다는 것이다.

모든 FabricPath VLANConversational MAC 학습을 한다.  CE VLAN은 기존의 Traditional MAC학습을 하지만, 설정을 통해서

  Conversational MAC 학습을 할 수 있게 할 수 있다.

• FabricPath Core switch어떠한 Mac-Address도 학습하지 않으며, 모든 Frame은 오직 FabricPath HeaderOuter DA 정보를 기반

   으로 (정확하게는 Destination SID) 전송을 한다.

FabricPath에서 기존의 Mac Address 학습은 FabricPath Port에서 수행하며, FabricPath Core Switch에서는 MAC Address 학습이 필요

   없다.

• NX-OS 6.1 이후로 F2 모듈의 FEX with VPC+가 지원되며, 이러한 Forwarding 지원을 위해서 Core Port 학습이 사용되며,

    F2 VDC에서는 Core Port Learning이 기본으로 활성화되어 있다.

• FabricPath Edge Switch는 두 가지 TypeMac-Address Table을 가지고 있다.

    - Local MAC Entry  : Switch와 직접 연결된 Device들의 정보

    - Remote MAC Entry  : 다른 FabricPath Swtich에 연결된 Device들의 정보

Directly-connected access 또는 Trunk Port에서 들어온 Ethernet Frame들은 기존 STP Switch처럼 모든 Source MAC을 기반으로

    학습한다.

• FabricPath EncapsulationUnicast Frame을 수신한 경우에는 FrameDestination MAC AddressLocal-MAC Entry에 있는

    경우에만 Frame의 목적지가 자신일 경우에만 해당 FrameSource MAC-Address를 학습하게 된다.

• Unknown Unicast Frame과 같은 Flooded되는 Frame에 대해서는 학습을 하지 않는다.

• Broadcast FrameEdge Switch에서 학습하지 않는다. 하지만, Broadcast Frame은 이미 기존에 Table에 있는 MAC Entry들에

    대해서 Update 하는데 사용된다.

• Multicast Frame(IP 혹은 non-IP Multicast) Core/Edge FabricPath Switch에서 모두, 주요한 LAN Protocols(ex. HSRP) 적절한

    동작을 위해 Multicast Frame으로부터 Source MAC을 학습한다.

위에서 논의된 Conversational LearningNexus 7000에서 각각의  Forwarding Engine ASIC에서 독립적으로 수행된다.

     - F1 I/O Module에서는 Front-Panel 10G Interface의 한 쌍 단위로 Forwarding Engine ASIC이 동작한다.   (Ex. e1/1-2 , e1/3-4, …)

     - F2/F2E I/O Module에서는 4개의 Front-Panel 10G Interface 단위로 Forwarding Engine ASIC이 동작한다. . (Ex. E1/1-4, e1/5-8.. )

     - F1 Module에는 16개의 독립된 Forwarding Engine이 있고, F2/F2E Module 에는 12개의 독립된 Forwarding Engine있다.

 

 

 

Posted by 네떡지기

티스토리 툴바