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

2014년 첫 포스팅입니다.

FabricPath에 대한 포스팅입니다.  이 주제에 대해서 몇 번에 걸쳐서 정리를 진행하게 될지는 모르겠지만..

차근 차근... 정리를 시작해보려고 합니다.

물론 기존의 정리하고 있던 주제들도 함께 추가적으로 정리 및 포스팅 될 예정입니다.

 

제가 정리된 부분에서 잘못되서 수정해야 할 부분, 업데이트 해야할 부분 등이 있으면 알려주시면 업데이트 하도록 하겠습니다.


 

FabricPath

하나의 Ethernet Fabric구조를 만들어 주는 기술

Network 구성이 Flat하게 구성된다.

• Fabric 외부 관점에서는 하나의 Switch처럼 인식된다.

• Layer2Mobility & Flexible의 장점과 L3Loop Prevention의 장점을 동시에 가져옴

MAC in MAC : MAC을 또 다른 MAC으로 Encapsulation.

    - IP Address는 미 변경되어, 어디서나 바로 사용 가능 (Plug & Play)

• STP를 사용하지 않음 : IS-IS로 대체 (내부적으로 동작하기 때문에 설정할 필요는 없음)

• Fabric 내에서의 통신은 STP가 아닌 Shortest pathSwitching되기 때문에 Optimal하고 Low Latency Switching이 가능하다.

ECMP Multi-topology Forwarding으로 통해서 Bandwidth를 충분히 활용할 수 있다.

 

Fabric Path 지원 하드웨어/License

• N7K F1 Linecard   : 5.1.1  N7K F2 Linecard   : 6.0.1

N7K F2E Linecard  : 6.1.2  • N5500 : 5.1.3 (no L3 module required)

License : Enhanced L2

 

 

 

 

Fabric Path의 이점.

• Conversational learning을 통한 MAC Address확장성을 가져옴.

     - 필요한 Mac Address만을 학습하여, 동일한 공간에 저장 가능한 Mac-addres를 늘려주는 효과를 가져옴.

설정이 매우 간단하다. (Fabric로 사용할 PortMode를 단순히 Fabric mode로만 설정하면 된다.)

• ECMP가 가능하기 때문에 High BandwidthHigh Resiliency를 가져온다.

• STP에 의존하지 않고 독립적으로 동작. 각각의 Switch들은 Layer 2 Topology로 운영되지만, 실제 동작은 Shortest-pathfirst

 기반으로 Layer 2 forwarding을 한다.

• STP에 상관없이 동작되기 때문에 FabricPath를 구성하는 장비간에 보다 더 직접적인 통신 경로로 통신하게 된다.

• Multicast Traffic2개의 Multi-destination Tree를 통해 분산된다.

• FabricPath에서 Frame 전송 시에, TTL Filed를 사용하여 Layer 2 loop을 완화시킨다.

 

 

Fabric Path 구성 요소

leaf (Edge) Device

    - CE(Classic Ethernet) Device와 연결하면서, Fabric Path Port와도 연결

    - Edge Device는 목적지를 Mac-AddressSwitch-idMapping하여 확인

    - Locally MacPortMapping되며, Remote MacSwitch-idMapping.

 

Spine (Core) Device

    - FabricPath Edge Device간의 연결을 하는 Device.

    - Spine Device는 오직 Switch-id를 통해서 목적지와 통신

    - Mac-address Learning을 하지 않음. 오직 Switch-id를 기반으로만 동작

    - Spanning-Tree가 동작하지 않음

    - Topology 정보는 Layer ISIS Adjacency를 통해서 교환

    - /수신 TrafficFabricPath Header와 함께 이동.

 

• Edge SwitchCE Port를 통해서 Local Source Mac-addres뿐 아니라, Switch-id로의 MappingMac-address Table에 유지한다.

 

 

FabricPath Interface

FabricPath Edge Port

    - FabricPath DomainEdge에 있는 Port로 일반 CE(Classic Ethernet)에 연결된 Interface

    - Edge PortMac Learning을 하며, 일반 Ethernet Frame을 전송을 한다.

    - Access 혹은 Trunk로 설정 가능.

FabricPath Core Port

    - Core PortEthernet Frame을 캡슐화하여 FabricPath Header  붙여서  FabricPath을 통해 전송을 한다

 

 

 

 

FabricPath 동작

• FabricPath 동작 순서

    1. Edge port에서 FrameIngress FabricPath switch로 수신된다.

    2. Ingress FabricPath switchDestination Mac Address을 찾아가기 위한 SID 위해 MAC addressLookup 하며,

       어떤 Interface로 전송을 할지에 대해서, 결정한 후 전송한다.

    3. Core FabricPath switchFabricPath core port로부터 Frame 수신하고, FabricPath Header에 있는 SID를 통해서,

       Next-Hop을 결정하여 Frame을 전송한다.

    4. Egress FabricPath switchFabricPath Header를 제거하고 적절한 CE PortFrame을 전송한다.

.

 

 

 

FabricPath Encapsulation

FabricPath에서는 CE Port에서 FE Port로 전송되는 모든 Ethernet Frame들이 16ByteFabricPath Header로 붙여서 캡슐화한

  후에 전송을 하게 된다.

FabricPath의 캡슐화는 MAC-in-MAC 캡슐화 포맷을 사용한다.

캡슐화 시에는 802.1Q tag를 포함한 기본 Ethernet Frame48bitOuter Source Address48bitOuter Destination Address,

  32bitFabricPath Tag를 추가하게 된다.  (16Byte = 128bit)

 

 

 

 

FabricPath Header [Outer Address]

Endnode ID

    - NX-OS 6.2(2)에서는 현재 이 Filed에 대해서는 구현되어 있지 않다.

 

• U/L (1bit)

    - 모든 UnicastOSAODA field에 설정

 

I/G (1bit)

    - Multi-destination Address인 경우에 설정

 

OOO/DL (1bit)

    - NX-OS 6.2(2)에서는 현재 이 Filed에 대해서는 구현되어 있지 않다.

    - 향후 ECMP시에, 패킷별 Load-Sharing이 기능을 제공할 수 있다.

 

Switch ID [SID] (12bit)

    - FabricPath Domain에 있는 모든 Switch에 할당되는 ID.

    - DARP를 이용하여 자동할당 받거나, 수동으로 직접 입력 가능. , 유일한 값으로 설정해야 함.

        동일한 ID를 갖는 경우에는 DARP에 의해서 한 쪽의 Switch ID 값을 유일한 값으로 변경

    - FabricPath MAC-in-MAC Frame"Outer MAC Address"이다.

 

  Sub-Switch ID

    - NX-OS 6.1(2)이전 버전에서는 Source 또는 Destination vPC+ PortChannel Interface를 식별하기 위해서 사용.

      bit를 통해서 최대 244개의 vPC+ PortChannel을 구분할 수 있다.

    - NX-OS 6.1(2)부터는 "no port-channel limit" 명령을 사용하여 개수의 제한을 없앨 수 있다. (F2/F2E만 가능 / F1 불가)

    - vPC+를 사용하지 않는 경우에는 이 Filed0으로 설정된다.

 

LID (Local ID / Port ID)

  - Source / Destination에 대한 Physical 혹은 Logical Interface

  - Outer DA에 있는 LID 값은 Egress SwitchFrame Forwarding할 때, 별도의 MAC-Address TableLookup하지 않게 해준다.

 

 

 

 

FabricPath Header [ FP Tag ]

• FabricPath packet 0x8903 이다.

 

• TTL은 초기 32이며, FabricPath Switch를 지날 때마다(hop) 1감소하며 Field를 통해서 Looping을 예방.

    - NX-OS 5.2(1) 에서는 모든 Frame에 대해서 32가 초기값

    - NX-OS 6.2(2) 부터는 fabricpath ttl 명령으로 Unicast Multicast frame을 구분하여 변경 가능하다.

         * BroadcastUnknown FrameUnicast TTL 값을 사용

         * IPv4/v6, non-IP Multicast FrameMulticast TTL 값을 사용

 

• FTAG(Forwarding TAG)

    - Topology , Distribution TreeUniqueID.

    - Unicast에서는 FabricPath IS-IS Topology를 식별하기 위해 사용하고, Multidestination에서는 Distribution tree를 식별하기 위

      해 사용한다.

 

 

 

 

 

STP & FabricPath

• FabricPath Network 내부에서는 STP가 없다.

• TCN을 제외한 BPDUFabricPath Network 애서 전달되지 않고 FabricPath edge에서 Drop된다.

• FabricPath network 1대의 Swtich처럼 보이기 위해서 모든 BPDU는 같은 Bridge ID를 가지고 BPDU를 전송한다.

  c84c.75fa.60XX : XXDomain IDHex 값이며, default 값은 00 이다

• FabricPath Port Upe되기 전까지 Switch 기존 STP에서 사용하는 Bridge ID를 사용한다.

 

 

 

Posted by 네떡지기

OTV Control Plane의 지난 번 포스팅의 Multicast 환경에 이어서, Unicast 환경에서의 OTV Control입니다.

언제쯤 포스팅을 하면서, 이번에는 지난 포스팅 이후에 빨리 올렸다고 쓸 수 있을지..

이래저래 정신 없는 일도 많고 그러네요... 그래도 조금 더 부지런해져야겠다는 다짐을 오늘도 해봅니다.


 

OTV Control Plane – Unicast-Only Transport Infrastructure (Adjacency-Server Mode)

• OTV에서 Unicast를 사용한 동작은 NX 5.2(1)부터 지원되기 시작하였다.

• Multicast 방식과 동일한 동작 방식으로 운영이 되지만, 다른 차이점은 각 OTV Device가 각 Control Plane 패킷을 복사하여

 동일한 논리적 Overlay의 각 Remote OTV Device로 보내게 된다는 점이다. 이러한 Head-End 복제 문제 때문에 다수의

 DataCenter Site를 구축하는 경우에 Multicast를 사용한 방법을 권장하기도 한다.

 동시에, Unicast-Only를 모델을 사용하는 경우의 단순한 운영에 대한 이점으로 소수의 DC 사이트를 연결할 경우에 유용하다.

모든 OTV NodeControl 패킷을 복제하여 전송하기 위한 Remote OTV Device Neighbor list를 알고 있어야 한다.

  이는 Adjacency Server라고 부르는 특정 역할을 하는 하나 이상의 OTV Edge Device 두어서 Neighbor List를 전달할 수 있게

   한다.

OTV Device는 특정 OTV logical overlay Join을 원하는 경우에 Adjacency ServerOTV Hello 메시지를 보내서 ‘register’

  하게 된다 다른 OTV Neighbor 주소는 Adjacency Server를 통해서 전달을 받게 된다. 따라서, 기존의 OTV Service새로운

  DataCenter Site연결 시 별도의 추가적인 설정이 필요 없이 Adjacency Server 주소에 대한 설정만 하면 된다.

• OTV Edge Device에서의 Hello 메시지 수신을 통해서 Adjacency Server 동일한 Overlay(unicast-replication-list) List를 만

   들게 된다 List는 정기적으로 Network에 있는 모든 OTV Neighbor이 인지될 수 있도록 Unicast 방식으로 전송된다.

 

 

OTV Control Plane - Adjacencies를 맺기 위한 동작 절차

1. 왼쪽 OTV Edge Device OTV Control Protocol은 다른 모든 OTV Edge Device에게  Control Plane Adjacencies 맺기 위해 

   Hello Packet을 보낸다. 

  2. OTV Hello 메시지는 모든 OTV Remote Device에게 Logical overlay를 통해 보내지게 된다.  Hello 메시지는 이전에

    Adjacency Server에서 받은 다른 OTV Edge Device List(Unicast-replication-list)에게 각각 전송하기 위해서 Head-end 복제가

    이뤄지게 된다 이러한 Frame들은 OTV 캡슐화하여 External IP Header를 추가한다. External headerSource IPLocal

    Edge DeviceJoin Interface로, Destination IPRemote OTV Edge DeviceJoin Interface로 설정하여 전송한다.

  3. Unicast FrameUnicast only Network Infrastructure를 통해서 라우팅 되어 목적지 사이트로 전송된다.

  4. 수신지의 OTV Edge Device는 수신 받은 Frame디캡슐화한다.

  5. Hello 메시지는 Control Protocol Process로 보내지게 된다.

 

다른 Edge Device들도 동일한 절차를 거쳐서 모든 Edge device들과의 Adjacency를 맺게 된다.

• OTV Control Protocol 특징은 기존 Multicast와 유사하다.

• OTV Edge Device들 간의 서로 확인이 되면, MAC Address Reachability 정보를 교환을 통해서 통신을 하게 된다.

 

 

.

 

 

OTV Control Plane – Unicast-Only Transport Infrastructure : MAC Address를 광고하는 동작 절차

 1. West DataCenter의 내부에서 VLAN 10, 20, 30에 대한 MAC-Address(A, B, C)Interface Interface를 통해서 학습하다

 2. 내부에서 학습한 MAC-Address A,B,C를 포함한, OTV Update 메시지를 Remote OTV Edge Device로 보내기 위해 OTV 캡슐

    화되어 Layer 3를 통해 전송된다. (Head-end 복제)

 3. OTV Update들은 Unicast를 통해 모든 Remote Edge Device에 보내지고, 디캡슐화되어, OTV Control Process으로 보내진다.

 4. MAC reachability 정보는 Edge Device들의 MAC Address Tables(CAMs)를 가져오게 되는 데, 기존 CAM Entry와 다른 점은

    물리적인 Interface 정보가 아니라,  해당 MAC-Address 정보를 보내온 Edge DeviceJoin Interface IP를 참조한다는 것이다.

 

 

 

 

OTV Control Plane – Unicast-Only Transport Infrastructure : Adjacency Server 이중화 구성

Adjacency ServerRedundancy를 위해 이중화 구성이 가능하다. 

이중화 된 Adjacency Server 간에는 OTV Edge Device(OTV Client)에 대한 정보를 독립적으로 관리하기 때문에, OTV Edge

  Device들은 각각의 Adjacency Server에 자신을 등록하며, 이를 위해서 OTV Edge Device에는 PrimarySecondary

  Adjacency Server를 설정한다.

OTV ClientPrimary Adjacency ServerTimed out 전까지는 Secondary Adjacency Server에서 보내온 OTV Client List를 처

  리하지 않는다.

Primary Adjacency Server  Time-out 될 경우에, Secondary Adjacency Server Replication List(OTV Client List)를 사용한

  다 그리고 10분 동안은 기존 Replication List를 유지하고 있다가, 10분 이내에 Primary Adjacency Server가 돌아올 경우에

  OTV는 기존 PrimaryReplication List로 돌아가게 된다. 만약 PrimaryReplication List가 삭제된 후에 Primary가 복구될 경

  우에는 모든 OTV Neighbor를 학습 한 후에, 새로운 Replication List를 주기적으로 전송하게 된다.

  OTV