안녕하세요. 

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

 

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

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

안녕하세요 

이번 포스팅은 지난 번에 했던 포스팅과 마찬가지로 간단한 동영상을 올려봅니다.


Cisco ACI에서 포트설정은 Profile 형태로 구성을 하게 되는 데, 

PortProfile을 생성하는 것을 JSON을 이용해서 Post하기 위한 예제입니다. 

동영상의 내용은, 동일한 PortProfile 그룹과 거기에 설정할 AEP를 지정하고 

그리고 각 인터페이스 별로 설정할 Port정보를 기입하여, ACI에 적용할 JSON을 생성한 후, ACI에 적용하게 되는 동영상입니다.


좀 더 많은 부분은 한꺼번에 JSON 형태로 만들어서 Profile을 만들고 싶은 생각은 있지만..

아무래도 실 운영 환경에서 테스트를 진행하는 부분에는 한계점이 있기 때문에.. 

가상머신이나. 에뮬레이터가.. 절실하다는.. 생각을 해보면서 포스팅을 마칩니다.



P.S 물론 본 동영상에 포함된 Profile 형태가 물론 ACI에서 하고자 하는 아키텍처의 그림은 아닐 수 있겠지만.

    위와 같은 형태의 자동화 부분도 가능하다는 점만 염두해두면 좋을 것 같습니다.

Posted by 네떡지기

 

 


지난 OTV 7번째 포스팅과 살짝 순서가 바뀐 OTV 8번째 포스팅입니다.

앞으로 몇 번이 될지는 모르겠으나, 우선 OTV 관련 포스팅이 몇 번 더 올라갈 듯 싶습니다.

그렇다고 그 몇 번으로 OTV 완결이라는 것은 아니지만요. ^^;

그럼 한 분이라도 도움이 되시길 바라며...


 

Failure Isolation

   - 모든 LAN 확장 솔루션의 주요 요구 사항 중에 하나는 Remote Site 간의 resiliency, stability, scalability 등의 장점을 유지한 채,

     Layer 2 연결성을 Routed Transport Infrastructure을 통해서 제공하는 것이다.

   - OTV는 STP 분리 / Unknown Unicast 억제 / ARP 최적화 / Broadcast 정책 제어를 통해서 이 목표를 달성하고 있다.

 

 

STP Isolation

     -  OTV는 기본적으로 Overlay를 통해서 STP BPDU를 전송하지 않는다. 이는 별도의 BPDU Filtering과 같은 설정을 추가로 하지

       않아도 되는, 기본적인 동작 방식이다.  이를 통해 각 OTV Site는 STP Domain을 독립적으로 운용된다.

     -  STP Domain이 독립적으로 운용되기 떄문에 STP Control Plane에서 발생할 수 있는 문제점들은 Remote Site에 영향을 미치지

        못하게 된다. 하지만, 이러한 STP BPDU를 전송하지 않고 Transport Infrastructure를 통해 Layer 2를 확장함으로써 잠재적인

        end-to-end Loop 구조가 발생할 수 있게 된다. OTV에서 STP Frame을 전송하지 않으면서 이러한 end-to-end loop를 예방하기

        위한 내용은 추후에 Multi-Homing 부분에서 언급되게 된다.

                                                             ※ Multi-Homing은 다음 포스팅에서 다뤄지며, 추후 포스팅 시에 링크로 연결해 놓겠습니다.

 

Unknown Unicast Handling

     - OTV Control Protocol은 OTV edge Device들 간의 MAC-Address와 Destination의 IP Next hop에 대한 Mapping정보로

       MAC Address reachability 정보를 광고하게 된다. 결과적으로 기존에 Remote Site의 MAC Address로 통신이 가능하도록

       Mapping정보를 받게 되며, Overlay를 통한 Layer 2 Traffic은 OTV Device를 통하여 Routing을 하는 것처럼 동작한다.

     - OTV Edge device가 자신의 Mac Table에 존재하지 않는 Mac 주소를 목적지로 하는 Frame을 받으면(Unknown Unicast),

       Layer 2 Lookup을 하게 되고, Table에 없는 것을 확인하고 Layer Traffic을 Internal interface들로 Flooding하며,

       Overlay로는 전송하지 않는다.

       ※ 이는 비정상적인 Mac을 생성하여 DoS Attack을 하는 경우에 대한 문제를 예방할 수 있다.

     - Microsoft의 Network Load Balancing Services(NLBS)와 같은 Layer 2 Traffic에 대한 Flooding이 필요한 특정 Application을

       위해서 선택적으로 Flooding을 할 수 있도록 설정을 할 수 는 있다. 이러한 개별 MAC-Address를 Static하게 설정하여,

       Frame이 Drop되지 않고 모든 Remote OTV Edge Device로 Broadcast 하도록 하는 것처럼 Overlay를 통해서 Flooding 하는

      것은 매우 예외적으로 사용되는 설정이며, 기본 동작은 Unknown unicast에 대해서는 Drop된다고 보면 된다.

       ※ NX-OS Release 6.2(2)부터 이러한 선택적인 Unicast Flooding에 대한 DCI간의 Flooding을 지원한다.

 

 

ARP Optimization

     - ARP Optimization은 Transport Infrastructure를 통해서 흐르는 Traffic을 감소시키는 기능이다.

  

     - 동작 방식은 다음과 같다.

        Step 1. West Site의 Device가 IP A에 대한 Host의 Mac-Address를 확인하기 위해 ARP Request를 보낸다.

        Step 2. ARP Request는 OTV Overlay를 통해서 모든 Remote Site로 전송되어, IP A를 가지는 Host에서 ARP Reply를 보낸다.

        Step 3. West Site의 OTV Edge Device는 ARP Reply를 감지하고 이를 ARP Neighbor-Discovery(ND) Cache라고 부르는

                    Local Data Structure안에  (MAC, IP)를 Mapping한 정보를 저장한다.

        Step 4. 이후, West Site의 다른 Host가 IP A에 대한 ARP Request를 보내게 된다.

        Step 5. West Site OTV Edge Device는 IP A를 가진 Remote Host 대신에 Local에 저장해 놓은 정보를 대신 응답을 한다.

 

 

 

 

    - 하지만, 위와 같은 ARP caching 동작은 ARP와 CAM Table간의 Aging Timer의 차이로 인해서 Black-holing Traffic이

       발생할 수도 있다. 이는 위에서 다루었던 OTV에서의 Unknown Unicast를 Drop시키는 특징 때문이기도 한다.

        Step 1. West Site의 Device가 IP A에 대한 Host의 Mac-Address를 확인하기 위해 ARP Request를 보낸다.

        Step 2. ARP Request는 OTV Overlay를 통해서 모든 Remote Site로 전송되어, IP A를 가지는 Host에서 ARP Reply를 보낸다.

                    West Site의 OTV Edge Device는 ARP Reply를 감지하고 이를 ARP Neighbor-Discovery(ND) Cache라고 부르는

                    Local Data Structure안에  (MAC, IP)를 Mapping한 정보를 저장한다.

        Step 3. IP A의 Host가 East Site에서 CAM aging 만료로 인해서, East Site OTV Edge Device의 Table에서

                    IP A Host의 MAC이 사라지게 되고, 이는 OTV Update를 통해서 West Site OTV Edge Device로 전파되고,

                    마찬가지로 West Site OTV Edge Device의 CAM Table에서도 사라지게 된다.

                    하지만, ARP Cache는 이 때 영향을 받지 않기 때문에 그대로 유지되게 된다.

                    ※ 이 시나리오에서는 ARP aging Timer가 CAM aging Timer보다 크다고 가정한다.

         Step 4. West Site의 다른 Host에서 IP A로 트래픽을 전송하려고 할 때, ARP Cache를 보고 Unicast로 전송을 한다.

         Step 5. West Site OTV Edge Device에서는 해당 Unicast의 MAC이 이미 사라졌기 때문에, Unknown Unicast로 처리되어

                     전송되지 못하고 해당 Frame은 Drop되게 된다.

              

 

 

      - 따라서, OTV Edge Device의 ARP Aging Timer는 항상 CAM Table Aging Timer보다 낮게 설정해야 한다.

        N7K의 Default 값은 다음과 같다.

           ▷ OTV ARP aging-timer : 480 초                                  ▷ MAC aging-timer : 1800 초

        ※ 일반적으로 사용되는 OS 등에서도 ARP는 1800초 미만으로 설정되어 있기 때문에 사실 위와 같은 시나리오는 크게

            신경쓰지 않아도 무관하다.

       -  Host의 Default Gateway가 Nexus 7000이 아닌 경우에 ARP aging-timer를 MAC aging-timer보다 작게 하는 것은 중요하다.

 

 

Broadcast Policy Control

     - 위에서 언급된 ARP Optimization과 같이 Broadcast를 줄이기 위해서 Broadcast white-listing과 같은 추가적인 기능을 제공하여,

       Overlay를 통하여 Layer 2 Broadcast Traffic을 줄일 수 있다. 이에 대한 내용은 추후에 가용성 부분에서 다뤄질 예정이다.

     - NX-OS 6.2(2)부터 Dedicated Broadcast Group을 통해서 Broadcast Traffic에 대해서 별도의 Multicast 주소로 설정할 수 있다.

       이 기능은 Broadcast Traffic에 대한 별도의 QoS 정책을 필요로 하는 경우에 유용하다.

 

Posted by 네떡지기

Last Updated : 2014.07.02

 


 

Network 장비에서 Python을 활용한 부분에 간단히 정리를 해보려고 합니다.

우선 처음 진행 부분은 현재 실제 테스트가 가능한 Nexus 7000 / 5000으로 먼저 간단히 시작합니다.

물론 완전 초기 부분이라서, 아마도 잘못된 부분 등에 대해서는 업데이트가 지속적으로 필요할 것 같습니다.

그리고 Nexus에서는 9000 / 3000 시리즈 기반으

Python 활용도가 더 높은 것으로 알고 있지만..(잘못 알고 있을수도? ^^)

현재 테스트가 가능한 부분이 Nexus 7000과 5000이라 이것으로 시작하며, 추후에 다른 테스트 장비(VM포함)로..

추가적인 포스팅을 진행할까합니다.

 

 


 

Cisco Nexus 7000  Python 특징

 Nexus 7K에서는 Python 2.7.2Interactive / noninteractive(script)에 대한 모드를 모두 지원합니다.

 NX-OS 6.2(8) 부터는 JavaScript Object Notation(JSON)logging module을 지원합니다.

 

 

Cisco Nexus 5000  Python 특징

 Nexus 5K에서는 Python 2.7.2모든 Feature를 사용할 수 있다.

 • Python Script를 이용하여 다음과 같은 기능을 구현할 수 있다.

       -  Swtich Bootup 시에 Configuration을 확인하는 Script 실행

       - Configuration 백업

       - Monitoring Buffer 이용량에 따라서, 사전에 혼잡 관리가 가능

       - 일정 시간 간격으로 작업을 수행

       - 프로그래밍 방식으로 SwitchCLI 명령을 수행하고 다양한 업무에 활용 가능

 

 

Third Party Pure Python Packages

 •Nexus에서 Third Party Python Package를 다음과 같은 방법으로 설치하고 사용할 수 있다.  

    ) ZIGI.tgz 를 서버로부터 복사하여 설치하는 경우.

     Step 1. 다음의 명령으로 tar fileSecure Copy 한다.

                      copy scp://user@server/path/to/ZIGI.tgz bootflash:ZIGI.tgz vrf management

     Step 2. Packge의 압축을 해제

                      tar extract bootflash:ZIGI.tgz

     Step 3. 압축이 풀린 Packgebootflash로 옮긴다

                      move bootflash:ZIGI/* bootflash:          

     Step 4. PackgeInstall 한다.

                      python setup.py install

     Step 5. bootflash에 복사된 파일을 제거한다.

     Step 6. Python Mode에서 해당 Packge를 사용한다.

                      NX-OS# python

                      >>> import ZIGI

 

 

 

Python Mode 접근

 

NX-OS# python

Python 2.7.2 (default, Nov 27 2012, 17:50:33)

[GCC 4.3.2] on linux2

Type "help", "copyright", "credits" or "license" for more  information.

Loaded cisco NxOS lib!

 >>> exit()

NX-OS#

 

 

 

 

Python 모드에서 Cli  명령 

 

 API

내  용 

1.  NX-OS# >>> cli("명령어")
    string = cli(“
명령어”)

 Python Mode에서 NexusCLI 명령어를 실행하고 Raw 결과를 리턴받게.

‘;’ 이용하여 다수의 명령어를 한 줄에 실행 가능

제어/특수 문자도 함께 출력. 이는 ‘\n’과 값도 함께 출력된다는 것을 의미하며,

    이는 가독성을 떨어지므로, clip() 명령을 사용하는 것이 보다 가독성에 좋다

2. NX-OS# >>> clid(“명령어”)

    dictionary= cli(“명령어”)

XML을 지원하는 CLI 명령어로 결과를 Dictionary 형식으로 리턴 받게 됨.

3. NX-OS#>>> Clip(“명령어”)

CLI 명령어에 대한 결과를 표준 Output으로 출력을 하며, 별도의 리턴 값은 없다.

 clip(“명령어”) r = cli(“명령어”) , print r  은 동일한 역할을 한다.

※ Nexus 7000 기준이며, Nexus 5000에서는 cli만 지원이 됩니다.

 

 Python Mode / CLI Mode 관련

 •Python Mode에서 Cli 명령을 사용하여 Switch Mode를 변경하는 경우에, Python Mode를 벗어나게 되면 변경된 Switch
   
Mode  유지되지는 않고, Python Mode 들어올 때의 기존 Mode로 가게 된다.

 •Python Mode에서 선언된 Data는 해당 Python Shell에서만 유효하며, Shell을 나간 후에 다시 들어오게 되면 사용 할 수 없게 된다. 

 

EX-1

EX - 2

NX-OS# python

NX-OS# >>> cli("conf t")

NX-OS(config)# >>> cli(“int e1/1”)

NX-OS(config-if)# >>> exit

NX-OS# 

NX-OS# python

NX-OS# >>> ZIGI = “JaeSung

NX-OS# >>> print ZIGI

JaeSung

NX-OS# >>> exit

NX-OS# python

NX-OS>>> pint ZIGI

Error:variable ‘ZIGI’ undefined

 

 

Posted by 네떡지기

 

이번에는 FEX에 대한 실제 설정과 관련한 부분입니다.

 

 

설정과 관련한 부분도 우선 현재 계획은 이번 포스팅과 다음 포스팅으로 나눠서 진행될 예정이긴 하나,

 

 

더 나눠질지는 아직 모르겠습니다.

 

 

 

 

 

 

 

 


 

FEX 설정 [Static Pinning]

-   Fabric Interface로 사용하게된 Parent Switch에서 Switchport mode를 Fex-fabric 설정을 하고, Fex를 Associate한다.

 

5K-1(config)# install feature-set fex                                                                              fex feature-set 설치

5K-1(config)# feature-set fex                                                                                        fex feature-set 활성화

 

5K-1(config)# int e2/3 

5K-1(config-if)# switchport mode fex-fabric                                                                InterfaceFex Mode 설정

5K-1(config-if)# fex associate 101                                                                                Fex  번호 설정(가상 슬롯 형태)

 

5K-1(config)# int e101/1/1                                                                                           Fex Interface 설정

5K-1(config-if)# switchport mode access                      

5K-1(config-if)# switchport access vlan 10 

 

 

-   Static pinning으로 연결된 포트의 상태 정보이다.

5K-1(config)# sh fex 101 detail

FEX: 101 Description: FEX0101   state: Online

  FEX version: 5.2(1)N1(4) [Switch version: 5.2(1)N1(4)]

  FEX Interim version: 5.2(1)N1(4)

  Switch Interim version: 5.2(1)N1(4)

  

  Pinning-mode: static    Max-links: 1

  Fabric port for control traffic: Eth2/3

   ...

  Fabric interface state:

    Eth2/3 - Interface Up. State: Active

Fex Port        State  Fabric Port

       Eth101/1/1    Up      Eth2/3

       Eth101/1/2  Down      Eth2/3

       Eth101/1/3  Down      Eth2/3

       

      Eth101/1/47  Down      Eth2/3

      Eth101/1/48  Down      Eth2/3 

 

 

-   Static Pinning 시에 상단 Parent Switch와 구성하는 Fabric Interface의 개수를 지정할 수 있는다.

    이 때 해당 FEX 설정 모드에 들어가서 pinning max-link 명령으로 설정을하게 된다. 

5K-1(config)# fex 101

5K-1(config-fex)# pinning max-links  2                                                           [Static Pinning Max Up Link]

 

5K-1(config)# int e2/4                                                                                       2번째 Uplink 설정

5K-1(config-if)# switchport mode fex-fabric                                                     - fabric interface

5K-1(config-if)# fex associate 101 

 

 

-  Mac-link로 설정 후에, 현재의 Fex 상태 정보를 보면 max-link로 설정된 Interface 수에 따라서 Fabric Extender의 포트 구성이

  되어 있음을 볼 수 있다. 아래의 예에서는 2개의 Max-link로 48Port의 Fabric Extender에서 1~24, 25~48 나뉘어서 Fabric Inteface

  가 지정된 것을 확인할 수 있다.

5K-1(config)# sh fex 101 detail

FEX: 101 Description: FEX0101   state: Online

  Pinning-mode: static    Max-links: 2                                                                              Max Uplink 개수

  Fabric port for control traffic: Eth2/3                                                                            FEX Control Traffic 관리 포트

  

  Fabric interface state:  현재 Static PinningPort

    Eth2/3 - Interface Up. State: Active

    Eth2/4 - Interface Up. State: Active

  Fex Port  State  Fabric Port

       Eth101/1/1  Up  Eth2/3

     

      Eth101/1/24  Down   Eth2/3

      Eth101/1/25  Down  Eth2/4

     

      Eth101/1/48  Down  Eth2/4

 

 

-   Static Pinning 상태에서 1개의 Uplink가 Down되었을 때의 상태정보이다.

    Static Pinning 상태에서 Fabric Interface Down시에 각 Port별 재할당에 관련한 내용은 다음 포스팅에서 다뤄질 예정이다.

 

 

 

 

5K-1(config)# sh fex 101 detail

FEX: 101 Description: FEX0101   state: Online

  Pinning-mode: static    Max-links: 2                                                                     Max Uplink 개수

  Fabric port for control traffic: Eth2/4                                                                   FEX Control Traffic 관리 포트

  

  Fabric interface state:                                                                                             현재 Static PinningPort

    Eth2/3 - Interface Down. State: Configured

    Eth2/4 - Interface Up. State: Active

  Fex Port  State  Fabric Port

       Eth101/1/1  Down  Eth2/3

     

      Eth101/1/24  Down   Eth2/3

      Eth101/1/25  Down  Eth2/4

     

      Eth101/1/48  Down  Eth2/4

 

 

 

 

FEX 설정 [Port-Channel]

-  Port-Channel로  FEX 설정은 Static Pinning과 거의 동일하나 Fabric Interface를 Port-channel로 만들고,

   해당 Port-Channel에서 Switchport mode를 Fex-fabric 설정을 하게 된다.

 

5K-1(config)# install feature-set fex                                                                  fex feature-set 설치

5K-1(config)# feature-set fex                                                                             fex feature-set 활성화

 

5K-1(config)# int e2/3-4

5K-1(config-if)# channel-group 52

5K-1(config-if)# no shutdown

 

5K-1(config)# int port 52

5K-1(config-if)# switchport mode fex-fabric                                                     InterfaceFex Mode 설정

5K-1(config-if)# fex associate 101                                                                     Fex  번호 설정(가상 슬롯 형태)

 

5K-1(config)# int e101/1/1                                                                                Fex Interface 설정

5K-1(config-if)# switchport mode access                      

5K-1(config-if)# switchport access vlan 10

    

 

 

 

 -  Port-Channel로 설정된 Fabric Interface의 정보

 

5K-1(config-if)# sh fex detail

FEX: 100 Description: FEX0100   state: Online

  FEX version: 5.2(1)N1(4) [Switch version: 5.2(1)N1(4)]

  FEX Interim version: 5.2(1)N1(4)

  Switch Interim version: 5.2(1)N1(4)

  ..

  pinning-mode: static    Max-links: 1

  Fabric port for control traffic: Eth1/7

   ..

  Fabric interface state:

    Po10 - Interface Up. State: Active  Port-Channel

    Eth1/7 - Interface Up. State: Active

    Eth1/8 - Interface Up. State: Active

  Fex Port        State  Fabric Port

       Eth100/1/1    Up        Po10

       Eth100/1/2    Up        Po10

       Eth100/1/3  Down        Po10

 

 

 

 

 

-  Port-Channel로 설정된 FEX에서 Fabric Interface가 Down된 경우, 전체적은 Port-Channel은 Up을 유지하고

   실제 Down된 Interface만 Down으로 체크된다. 하지만 각 Fabric Interface의 Port는 Port-channel로 연결되어 있기 때문에

   전체적인 하단 Interface는 기존 상태를 유지하게 된다.

 

5K-1(config)# sh fex 101 detail

FEX: 101 Description: FEX0101   state: Online

  Pinning-mode: static    Max-links: 1  Max Uplink 개수

  Fabric port for control traffic: Eth2/4  FEX Control Traffic 관리 포트

  

  Fabric interface state:  현재 Static PinningPort

   Po10 - Interface Up. State: Active  Port-Channel

    Eth2/3 - Interface Down. State: Configured

    Eth2/4 - Interface Up. State: Active 

Fex Port  State  Fabric Port

 Eth100/1/1      Up  Po10

 Eth100/1/2    Up  Po10

 Eth100/1/3    Down  Po10

 

 

 

 

FEX 설정 [Fabric Extender Type 설정]

   - Fabric Extender를 구성하기 전에, Pre-Provision 기능을 이용하여 아래와 같이 설정을 하게 되면 Fabric Extender를 연결하기 전에

     Fabric Extender Port 설정을 할 수 있다. .

   - , 사전에 설정한 Type과 맞지 않는 TypeFabric Extender를 연결 시에는 Type Mismatch로 사용할 수 없게 된다

 

5K-1(config)# fex 101

5K-1(config-fex)# type N2232TP                                                                           // FEX Type 사전에 설정하기

5K-1(config-if)# sh fex detail

FEX: 100 Description: FEX0100   state: Fex Type Mismatch 

  FEX version: 5.2(1)N1(4) [Switch version: 5.2(1)N1(4)]

  FEX Interim version: 5.2(1)N1(4)

  Switch Interim version: 5.2(1)N1(4)

  Extender Serial: SSI14280VS8

  Extender Model: N2K-C2248TP-1GE,  Part No: 73-12748-05                          // 실제 FEX Model

  Card Id: 99, Mac Addr: 58:8d:09:c9:41:02, Num Macs: 64

  Module Sw Gen: 12594  [Switch Sw Gen: 21]

  post level: complete

 pinning-mode: static    Max-links: 1

  Fabric port for control traffic: Eth1/7

  FCoE Admin: false

  FCoE Oper: true

  FCoE FEX AA Configured: false

  Fabric interface state:

    Po10 - Interface Up. State: Active

    Eth1/7 - Interface Up. State: Active

    Eth1/8 - Interface Up. State: Active

   ...

 

 

 

 

FEX 설정 [Fabric Extender Serial 설정]

   - FEX 연결 전에 연결할 Fabric Extender Serial을 지정하여 사전 설정을 할 수 있다.

   - , 사전에 설정한 Serial과 맞지 않는 TypeFabric Extender를 연결 시에는 Identity Mismatch로 사용할 수 없게 된다.

 

5K-1(config)# fex 101

5K-1(config-fex)# serial SSI14280VX  // FEX Serial 사전에 설정하기

5K-1(config-if)# sh fex detail

FEX: 100 Description: FEX0100   state: Discovered

  FEX version: 5.2(1)N1(4) [Switch version: 5.2(1)N1(4)]

  FEX Interim version: 5.2(1)N1(4)

  Switch Interim version: 5.2(1)N1(4)

  Extender Serial: SSI14280VS8

  Extender Model: N2K-C2248TP-1GE,  Part No: 73-12748-05

  Card Id: 99, Mac Addr: 58:8d:09:c9:41:02, Num Macs: 64

  Module Sw Gen: 12594  [Switch Sw Gen: 21]

  post level: complete

 pinning-mode: static    Max-links: 1

  Fabric port for control traffic:

  FCoE Admin: false

  FCoE Oper: true

  FCoE FEX AA Configured: false

  Fabric interface state:

    Po10 - Interface Down. State: Configured

    Eth1/7 - Interface Up. State: Identity-Mismatch

    Eth1/8 - Interface Up. State: Identity-Mismatch

  Fex Port        State  Fabric Port

       Eth100/1/1  Down        Po10

       Eth100/1/2  Down        Po10   ...

 

 

 

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 네떡지기

Fabric Extender의 2번째 정리입니다.

지난 주부터 포스팅 주제를 좀 다양하게 하려다보니 기존 NX-OS 정리도 포스팅 텀이 생기지 않을까 싶네요. ^^;

(사실 기반 지식도 바닥(?)이 나는 것이기 때문이겠지만요. ^^;)

다음 NX-OS 포스팅은... Fabric Extender 3이 될지.. FabricPath를 이어서 할지.. ^^ 아직은 미정이지만..

곧 다시 또 올리도록 하겠습니다.

 


 

FEX 구성 방법

Nexus 2000은 개별 PortPinning을 하는 방법과 Port-Channel을 사용하는 2가지 Load-Balancing 방법이 있다

 

• Static Pinning

     - Front-panel PortUplink를 직접 구성하는 방법

     - Uplink의 구성 가능한 수를 기반으로 Pinning을 구성할 수 있다.

     - 모든 Host Interface는 하나의 Uplink에 할당이 되어야 한다.   

     - pinning max-links 명령을 통해서 각 Host Interface와 구성하는 Uplink의 수를 지정할 수 있다. [max-link : 1 ~ 4]

     - BandwidthOversubscription를 제어하는 데 있어서 좋은 구성 모드이다.

     - UplinkDown 경우에 DownLink에서 사용 가능한 Link로 자동 전환되지 않으며,

       삭제된 Uplink를 다시 추가하는 경우에도 재할당이 순서대로 되지는 않기 때문에 통신 상에 문제가 발생 할 수 있게 된다.

     - 재할당을 위해 DownUplink(Parent Switch Interface)에서 ‘no fex associate fex_nofex연결을 해제해주어야 한다

     - Fex 2148-T, 2148TP의 경우에는 1~4개의 Upstream Fabric Interface를 사용하며,

       Fex 2224TP1~2개의 Fabric Interface, Fex 2232PP1~8개의 Fabric Interface를 지원한다.

     -  해당 FEX와 연결된 Front-panel Port 확인 : show interface ethernet 1/17 fex-intf        

 

 

 

 

 

 

 

Ether-channel

     - Uplink Port가 하나의 논리적인 Interface로 구성(Port-channel)되어서, 모든 Front-panel portMapping 된다.

     - Uplink가 추가되거나 삭제될 때에도 Host Port는 그대로 Up 상태를 유지할 수 있다.

     - 모든 TrafficL2/L3 정보에 따라 Hash되어 Load Balancing되며, 하나의 UplinkFail된 경우에는 나머지 Link로 계속

       Load Balancing된다.

     - Host Interface에 대해서 L2 / L3 모두 각각 Standard Mode일 때에는 최대 8Interface, LACP Mode일 때에는 최대 16개의

       Interface 묶어서 구성할 수 있다

     - vPC를 이용하여 Uplink Port-channel을 구성할 수 있다.

 

 

 

 

FEX Static / Port Channel 차이

• StaticPortChannel의 차이를 이해하기 위해서는 Fabric Extender에 대한 컨셉의 기본 구조에 대해서 이해해야 한다.

     1. Fabric Extender는 중앙 SupervisorLine card를 연결하는 것과 유사한 방법이다.

     2. Fabric ExtenderLocal Switching을 하지 않고, 모든 SwitchingSupervisor에서 발생하게 된다.

• Static Pinning을 사용하는 경우에는 혼잡에 의해 영향을 받는 Server Port에 대해서 제어를 더 잘할 수 있다.

     Port ChannelTrafficHash에 의해서 Uplink로 보내지기 때문에 제어가 불가능하고,

     그래서 혼잡에 의해서 Host에 영향을 어떻게 받을지에 대해서 예측이 어렵다.

• Static PinningHost별로 직접 Port 지정이 가능하기 때문에 사용량에 따라 혼잡이 발생하지 않도록 Port 구성을 분배할 수 있으나,

     PortChannel의 경우에는 Hash 함수에 의해 자동지정이기 때문에 Port 구성 분배를 지정할 수 없기 때문에 특정 Port에 혼잡이 발생

    하면서 다른 Port는 여유대역폭이 남을 수 있다.

 • Static Pinning의 경우에는 Fabric Link중에 하나가 문제가 발생할 경우를 대비하기 위해서, Host 단에서 이중화(NIC Teaming같은)

    해두어야  하지만, Port-channelFabric Link중에 하나가 문제가 발생하더라도 나머지 Link로 전송이 가능하기 때문에 별도의 Host

    이중화를 하지 않더라도 통신이 가능하다.

    * Host단을 이중화로 구성한 경우,  상단 Static PinningUplink Down 시에 해당 Host InterfaceDown되어 Host단의 Fail-over

       된다.

 

 

 

FEX 구성 Topology

 

 

 

 

Enhanced Virtual PortChannel

• NX-OS 5.2(1)부터 Fabric Extender에서 host vPC를 서로 다른 FEX 통해 vPC 설정이 가능하다.

• Enhanced vPCHost에서 FEX FEX에서 Nexus 5500으로의 모든 구간을 Active 구간으로 만들어서,

   사용 가능한 Bandwidth를 효율화 한다.

지원 가능 플랫폼 (NX-OS 5.1.(3)N1(1))

     - Nexus 5548P / 5548UP / 5596UP (지원)

     - Nexus 5010 / 5020 (지원 불가)

Single Homed 구성은 Host802.3ad(LACP) 지원 가능 시, Dual-Homed802.3ad(LACP) 지원 불가능 시에 A/S 구조로 사용한다

 

 

Posted by 네떡지기

VXLAN 2번째 정리입니다.

뭔가 아직 정리가 되지 않은 듯하여 포스팅을 미루려 하였으나..

미루기만하면... 계속 미루기만 할 것 같아서... 우선 先 포스팅... 後 업데이트로 갑니다.

 


 

 

VXLAN이 필요한 배경


1.  Limitations imposed by Spanning Tree & VLAN Ranges

     - 현재의 Layer 2 Network는 중복된 경로에 대해서 Loop를 예방하기 위해 STP를 사용한다.

     - STP를 사용하게 되면, Blocking Point가 생기면서 모든 경로에 대해서 다 사용할 수가 없게 된다.

       따라서, STP 모델은 Multipathing에서의 Resiliency로써는 적합하지 않다.
     - 최근에는 TRILL이나 SPB로써 STP의 이러한 제약사항을 해소하도록 제안되고 있다.

       이러한 기술은 동일한 Layer 3 Network에서의 Rack간의 서버들의 통신에서는 STP의 제약사항을 해결하지만,

       Inter-VM 통신을 위한 Layer 2 Model로는 적합하지 않다.
     - VLAN은 Broadcast Domain을 나누는 역할을 하는 데, 12bit로 VLAN을 구분하게 되며 이는 총 4094개의 VLAN을 생성하여

       사용할 수 있다. 하지만, 가상화가 채택되면서 보다 많은 VLAN 사용이 필요로 하게 된다.


 

2. Multitenant Environments
     - Cloud  Computing은 Multi-tenant 환경을 위해 탄력적인 Resource의 Provisioning을 포함한다. 
     - 대표적인 Cloud Computing의 예는 Public Cloud 인데, Cloud Service 사업자는 이러한 탄력적인 서비스를 제공하여

       동일한 물리적인 인프라에서 다수의 고객/Tenants을 수용하게 된다. 
     - Tenant의 독립적인 Network Traffic 분리는 Layer 2 혹은 Layer 3 Network를 통해 가능하다.
     - Layer 2 Network VLAN을 통해서 Traffic을 분리할 수 있는 , 이를 통해 Tenant간에 구분이 가능하다.
     - Cloud Provider은 다수의 Tenant를 구분해야 하기 때문에, 기존 VLAN에서의 최대 값인 4094개는 서비스를 제공하는 데,

       부족할 수 있다. 더욱이 하나의 Tenant(Customer)에서 다수의 VLAN이 필요한 경우도 발생하게 된다. 

3. Inadequate Table Sizes at ToR Switch
    - 오늘날 가상화 환경에서는 기존의 Server와 연결된 Link에 대해서 하나의 Mac-Address 학습했던 것과는 달리 각 개별 VM 단위로

      Mac-Address를 학습하게 된다.

   - 이는 VM과 다른 물리적인 서버로 통신하기 위해 필요로 하다. 일반적인 ToR Switch는 24개 혹은 48개의 서버에 연결될 수 있고,

     이러한 랙들로 DataCenter가 구성되게 된다.

   - 그래서 각각의 ToR Switch는 VM들이 다수의 서버들과 통신하기 위해 Mac-Address Table을 유지해야 한다.

     이러한 환경은 기존의 비가상화 환경보다 더 많은 수의 Table용량이 필요로 하게 된다.

 

 

 

VXLAN
  - VXLAN은 Layer 2와 Multi-tenant 환경에 VM동작하는 Layer 3 DataCenter Network 인프라에서 위의 요구사항들을 해결한다.     -  - VXLAN은 기존 Network 인프라에서 Layer 2 Network를 확장하도록 제공해준다. 
  - 즉, VXLAN은 Layer 3를 통한 Layer 2의 Overlay 방식이다. 각 Overlay를 VXLAN segment라고 하며,

  - 동일한 VXLAN segment내의 Device간에만 통신이 가능하게 된다.

  - 각 VXLAN segment는 24bit의 Segment ID라는 식별자를 통해서 식별되며, 이를 VXLAN Network Identifier(VNI)라고 한다.

  - 이 VNI는 동일한 Domain 내에서 최대 1600만개의 VXLAN Segment를 가질 수 있다.
  - VNI는 개별 VM이 만든 내부 MAC frame의 범위를 식별한다. 

  - 따라서, VNI로 구분된 Segment간에는 서로 MAC Address가 중복이 되어도 문제가 없다. 
  - VNI 정보는 개별 VM이 만든 내부 MAC frame을 캡슐화한 Outer header에 있다.

  - 이러한 캡슐화 때문에, VXLAN을 Tunnel 방식이라고 할 수 있다.

  - 이 Tunnel은 Stateless이며, 각 Frame는 일련의 규칙에 의해서 캡슐화된다.
  - Tunnel의 End-Point(종단/VXLAn Tunnel End Point-VTEP)은 VM을 호스팅하는 Server의 Hypervisor내에서 위치한다.

    (Hypervisor이외에 물리적인 별도의 스위치에서 VTEP역할을 할 수도 있다.) 

  - 따라서 VNI와 VXLAN은 tunnel/outer header 캡슐화 정보이기 때문에 VTEP에서만 알고 있으며, VM에서는 이 정보를

    알 수 없다.                                                                              

 

 

 

VXLAN Deployment Scenarios

 

 VXLAN은 일반적으로 여러 랙의 흩어져있는 가상화 Host들이 있는 Data Center에 Deploy되어 있다.

 각각의 랙은 서로 다른 Layer 3 Network에 있거나 혹은 하나의  Layer 2 Network에 있을 수 있다.

 VXLAN Segments/overlay network은 이러한 Layer 3 혹은 Layer 2 Network의 상단에 놓여있게 된다.

 

 다음의 VXLAN의 Deployment 시나리오를 위한 가상의 구성이다.

 2대의 가상화 서버가 Layer 3 인프라를 통해서 연결되어 있다. 이 서버는 동일 랙 일 수도 있으며, 혹은 서로 다른 랙이거나

 다른 데이터센터에 각각 구축되어 있을 수 있으나 동일한 관리 Domain내에 있다.

 가상화 서버 내의 4개의 VM은 4개의 VXLAN Overlay Network로 구성되며 22, 34, 74, 98의 VNI 값을 가지고 있다.

 

 

 

하나의 Deployment 시나리오는 Tunnel 종단 지점의 서버에서 VXLAN을 이해할 수 있는, 즉 VTEP 기능을 수행 할 수 있는 경우이다.

 

 또 다른 시나리오는 VXLAN Overlay network에 있는 Node가 기존 VLAN기반의 Legacy Network와 통신하고자 하는 경우이다.

이러한 Node는 Physical Node이거나 혹은 VM일 수 있다. 이 둘 간의 통신을 하기 위해서 Network에 VXLAN과 Non-VXLAN 사이의 Traffic을 전송하는 VXLAN Gateway가 필요하다.

 

다음은 VXLAN과 Non-VXLAN간의 통신을 하는 경우에 대한 것이다.

 

 VXLAN 연결 Interface에 들어온 Frame을 Gateway에서는 VXLAN header을 제거하고, Inner Ethernet Frame의 Destination Mac Address로 Physical Port로 전송을 하게 된다. 

명시적으로 Non-VXLAN interface로 전달하기 위한 설정이 되어있지 않으면, Inner VLAN ID와 함께 디캡슐화된 Frame은 폐기된다.

 

 반대로, Non-VXLAN Interface로부터 들어온 Frame은 내부의 VLAN ID를 기반으로 특정 VXLAN Overlay network로 Mapping된다.

이 경우에 명시적으로  캡슐화된 VXLAN Frame으로 전달하는 설정을 하지 않으며, VLAN ID는 VXLAN으로 캡술화 되기 전에 제거된다.

 

 VXLAN Tunnel 종단 기능을 하는 Gateway들은 ToR/Access Switch 혹은 Core 심지어 WAN edge Device가 될 수 있다.

WAN Edge Device가 이러한 Gateway 역할을 하는 경우에 Hybrid Cloud 환경에서 VXLAN Tunnel 종단인 Provider Edge Route를 포함할 수 있다.  이러한 모든 경우에 Gateway 기눙은 Software나 Hardware 모두 구현될 수 있다.

 

 

 

Inner VLAN Tag 처리

 VTEP와 VXLAN Gateway는 Inner VLAN Tag 처리를 위하여 다음과 같이 해야 한다.

 - 설정이 되어 있지 않으면, 디캡슐화된 VXLAN Frame은 Inner VLAN Tag과 함께 Dircard 된다.

 - 설정이 되어 있지 않으면, 캡슐화 시에 Tunnel Packet에 VTEP는 Inner VLAN tag를 포함하지 않는다.

 - VLAN-tagged Packet이 VXLAN Tunnel을 해야 하는 경우에 별도의 설정이 되어 있지 않으면,

   VTEP는 VLAN Tag를 제거하고 캡슐화한다.

 

 

 

 

 

 

 

Posted by 네떡지기

Last Update : 2014.04.28


 

새롭게 지난 주말부터 정리를 시작한 VXLAN입니다.

수정이 필요한 부분은 말씀해주시면, 확인 후 수정하도록 하겠습니다.


 

 

VXLAN

  물리적인 환경의 제약이 없이 Layer 2 Segment를 확장한다.

  〮 VM 이동 후에도 기존 IP 주소를 지속적으로 사용.

  표준화된 방법으로 Overlay를 구성할 수 있게하여,  다양한 Vendor들의 Ecosystem을 구축할 수 있음.

    ※ Cisco,Vmware, F5, Broadcom, Brocade, Arista etc

  기존 Layer 212bitVLAN ID4094 VLAN지원, VXLAN24bitVNID1600만개의 VXLAN을 지원한다.

  기존 Layer2 VLANSTP 사용하여