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

 

근 한달여만에 포스팅하는 vPC에서의 STP에 관한 내용입니다.

내용을 읽다보면 약간 중복된 내용이 보이기도 앞뒤가 맞지 않은 부분이 있을 수도 있지 않을까 싶습니다.

아래 내용은 한달전에 포스팅하면서 올릴 때에도 같이 정리를 하고 있던 부분이기는 하나,, 정리가 되지 않아서 하루 이틀 미루다

또 이것 저것 휘둘려 다니다보니.. 결과적으로.. 계속 늦어지는 것 같아서...

오늘 약간 정리의 일단락을 짓고.. 차츰 Update 버전으로 관리를 해야할 것 같다는 생각을 해서.. 먼저 올려봅니다..

자꾸.. 올리는게 미뤄지면 잘 안하게 될 것 같은 느낌이.. 들기도하고.. 나태해질 것 같은 생각에....


 


vPC Domain에서 STP 역할

• vPC와 관련된 일부 네트워크 이벤트로 발생 가능한 Layer 2 Loop를 방지한다.

• vPC Domain 內와 vPC 초기 설정 시의 Loop를 관리한다.

 

vPC에서의 STP 설정

• vPC를 설정한 장비 간에서 STP에 대한 Global Parameter Interface Setting은 동일하게 설정하도록 한다.

     1.  Global Parameter

          - STP mode              - MSTSTP region 설정  - pVLAN 활성화 여부

          - Bridge Assurance 설정  - STP Port type 설정  - loop Guard / BPDU Guard / BPDU filter 설정

      2. Interface Setting

          - STP Port type 설정 (edge,network, normal)    - Loop Guard / Root Guard (Enable,Disable)

만약 Parameters가 잘못 설정된 경우에는 NX-OS에서 vPC의 모든 Interface에 대해 suspends로 만든다. (Type-1 일관성 체크 에러)

  NX-OS 5.2 이후에서는 vPC graceful 일관성 체크 feature, Secondary peer 장비의 Interfacesuspends로 만들고,

  Primary peer 장비는 정상적인 운용 상태를 유지하게 된다.

• vPCMember PortSuspends 되었다는 Syslog Message가 발생을 하게 되면, show vpc brief 명령으로 vPC의 상태를 확인한다.

• Traffic 흐름이 예상치 못하지 흐르지 않도록, vPC 양 쪽의 STP Interface 설정을 동일하게 맞추도록 한다. (Type-2 일관성 체크 에러)

         - BPDU Filter  - BPDU Guard  - STP Cost(STP port path cost)

         - VLANs  - STP Link Type(auto, PtoP,shared)   - STP Priority(STP port priority)

  show run interface port-channel <id> membership  명령으로 vPC 양쪽의 설정이 동일한지 확인할 수 있다.

 

 

NX-OS-1# sh run int port 2 membership

!Command: show running-config interface port-channel2 membership

!Time: Wed Nov 28 21:08:29 2012

version 6.0(1)

interface port-channel1

  description ## ThePlmingSpace.Tistory.com ##

  switchport

  switchport mode trunk

  vpc 2

interface Ethernet1/1

  description ==네떡지기1==

  switchport

  switchport mode trunk

  channel-group 1

  no shutdown

 

 

NX-OS-2# sh run int port 2 membership

!Command: show running-config interface port-channel2 membership

!Time: Wed Nov 28 21:08:29 2012

version 6.0(1)

interface port-channel1

  description ## ThePlmingSpace.Tistory.com ##

  switchport

  switchport mode trunk

  vpc 2

interface Ethernet1/1

  description ==네떡지기2==

  switchport

  switchport mode trunk

  channel-group 1

  no shutdown

 

 

 

 

 

vPC에서의 STP 의 권고안

• STP 반드시 모든 VLAN에 활성화되어야 한다. (모든 Access 장비들이 vPC-DomainvPC로 연결되어 있더라도 마찬가지이다.)

만일 Layer 2 Domain이 필요할 경우에는 MST와 함께 vPC를 설정하도록 한다.

동일한 Layer 2 Domain에서는 동일한 STP Mode로 구현한다. (Rapid-PVSTMST를 운용하는 것이 STP Convergence를 줄인다.)

• vPC Member Port에서 VLAN pruning을 하게 되면, 내부 resource 사용을 줄일 수 있다

 

 

 

vPCSTP의 상호운용 Blueprint Diagram

 

 

vPCSTP의 상호운용의 표준 및 권고

• STPRootNetwork Aggregation Layer에 유지하도록 한다.  (vPC Domain)

각각의 vPC Peer 장비들은, Access 장비와 연결된 포트에 Root Guard를 설정한다.

• vPC Peer-link가 설정되었을 경우, DefaultBridge Assurance가 활성화 된다.  (vPC Peer-link에서 비활성화 되지 않는다)

• vPC에서 Bridge Assurance를 활성화 할 필요가 없다.

   (STP port type newtork로 선언된 vPC Member PortBridge Assurance가 활성화)  되어 있다.

• vPC member port 설정 spanning-tree port type normal로 한다. (Bridge Assurance는 사용하지 않음)

• Host와 연결된 Interfaceport fast(edge port type)을 설정하여, STP convergence를 빠르게 한다.

• Host와 연결된 Interface BPDU guard를 설정하여, Host로부터 BPDU 수신 시에 Block 되도록 한다.

 

 

vPCSTP BPDU

• vPCDual active control plane으로 동작한다.

• vPCSTPvPC primary peer에 의해 관리되고, 오직 Primary device에서만 BPDUdesignated port들을 통해 내보낸다.

  STPRoot가 어디에 있도록 구성되어졌는지와는 무관한다.

• Secondary vPC에서도 STP가 활성화되어 있지만, 그것은 vPC member port 상태를 변경할 수 없다.

• vPC secondary peer deviceAccess switch들로부터 BPDU를 받아서, Primary Peer로 다시 보내게 된다.

• vPCPrimary/Secondary device 모두 항상 동일한 STP Port 상태를 유지한다. (Forward)

 

 

 

vPC에서의 STP  

• STP rootvPC Primary 장비가 되도록 설정하는 것을 권고한다.

• peer-linkCFSoE 같은 중요한 트래픽이 전송되기 때문에 절대 Blocking되지 않기 때문에 모든 VLAN에 있어서 항상 Forwarding상태다.

• vPC peer-link로서, port-channel을 설정하게 되면, 자동으로 Bridge AssuranceLink에 활성화 된다.

     - vPC peer-link에 활성화된 Bridge Assurance는 비활성화 하지 않도록 하고, vPC member Port에는 활성화하지 않도록  권고.

vPC Peer 장비의 포트 중에 Access 장비와 연결된 포트에는 Root Guard를 설정하도록 한다.

• vPC Primary Switch에서만, vPC Port에 대해서 STP Topolog가 동작한다. , vPCSpanning Tree ProtocolvPC Primary Peer장비에  의해서 제어되고, BPDU를 생성하고 보내게 된다.

• Secondary vPC Switch에서는 반드시 STP가 활성화 되어야 하지만, vPC member 포트 상태에 영향을 미치지는 못한다

Posted by 네떡지기

 

Last Update 13.01.23 (Bridge Assurance)

 

또, 정신없이 시간이 흘러가네요. ^^;

정리가 자꾸 더뎌지네요... 오늘은 기존에 정리했던 내용 중에 좀 더 마무리를 지으려던 내용 중에 우선 일부 올립니다. ^^

추가적인 보완은 계속 해 나가야 할 듯 싶네요. ^^

 

 

 


 

STP

• NX-OSRapid-PVST+ DefaultEnable되어 있다.

• Rapid-PVSTMST와 상호 운용된다. (Default Enable)

• STP extended system-id가 항상 Enable 상태이다. (IOS에서는 Spanning-tree extend system-id 명령이  필요)

• BPDU GuardLoop Guard, Root Guard, BPDU Filter 기능을 지원한다.

• VDC별로 오직 하나의 STP만 활성화가 가능하다.

현재 구성된 L2 구성상에 STP가 필요하지 않더라도 STPDisable하지 않아야 한다. (Configuration이나 Cabling Error의 방지)

기존 IOS Command와 사용은 동일하다.

• MST에서 VLANMAC은 동일한  Instance 간에는 동일하다

 

 

Spanning-Tree Port Type

• Normal ports : 기본 Port Type이다.

• Network ports : Bridges 사이에 설정되며, Bridge AssuranceDefaultEnable된다.

• Edge ports : 이전의 PortFast와 같다. L2 Loop를 발생하지 않는 종단 장비에만 설정되어야 한다

 

 

Virtualization Hosts

최근 데이터센터의 가상화에 따라서 두 가지의 Interface Type이 혼용될 수 있다.

• 802.1Q Trunk는 원래 네트워크 장비 간을 위해서 사용되지만, 가상화 Host가 연결된 포트에서도 사용되야 한다.

   하지만, 이 경우에 실제 물리적으로 1대의 장비이기 때문에 Edge 설정을 통해서, 바로 동작할 수 있도록 해주는 것이 좋다

 

  NX-OS(config-if)# spanning-tree port type edge trunk

 

 

Bridge Assurance

• Spanning-Tree 오동작에 의한 Loop를 제거할 수 있는 새로운 기술로, 다음과 같은 문제점을 해결할 수 있다.

 

      -  Unidirectional link failure (단방향 링크 문제)

      -  Software failure (Control Plane 비정상/Data Plane 정상 시, Blocking PortForwarding 상태로 되면서 Loop 발생 가능)

모든 Port는 현재 상태와 상관없이 모든 VLANBPDU를 주고 받는다.

  일반적으로 STP에서는  BPDURoot로부터 다른 Switch로의 전송이 되지만,  Bridge Assurance가 활성화 되면 모든 Port

   현재의 상태  상관없이 모든 VLANBPDU를 주고 받는다.

• BPDU를 사용하여 양방향 Keepalive를 확인하여, BPDU의 수신이 끊기는 포트의 전송상태는 Inconsistent 로 된다.

  이러한 기능을 통해서 Bridge 오동작에 의한 Loop를 방지할 수 있다.

• Rapid PVST+ MST에서만 지원된다.

양 쪽 장비 모두에서 설정이 되어야 있어야만 하며, 그렇지 않을 경우에 연결된 PortBlock 상태가 된다.

Bridge AssuranceSpanning Tree Port 상태가 Network Type인 경우  기본적으로 Enable 상태이다. 

다음 명령을 통해서 bridge assuranceGlobally mode에서 비활성화 시킬 수 있으며,

  또한 포트에서 Spanning-Tree port type의 설정을 통해서 활성화 할 수 있다.

Loopguard와 유사한 동작을 수행하지만, loopguard의 경우에는 현재 차단된 포트에서 BPDU 수신시에만 동작한다.

   또한 동일한 Port에서는 LoopGuardBridge Assurance 중의 하나만 사용이 가능하다.

 

  NX-OS(config)# no spanning-tree bridge assurance                            : 전체 비활성화

  NX-OS(config-if)# spanning-tree port type network                            : 포트별 활성화

 

 

 

 

 

Nexus_정리자료(STP_BA).pdf

 

Posted by 네떡지기

티스토리 툴바