분류없음2014.10.07 18:30

 

 


이번에는 OTV 7번째 정리입니다~ ^^

NX-OS로는... 34번째네요...  원래 다른 내용을 정리하려다가 어쩌다보니.. 순서가 바뀌어서.. 정리가 되었습니다. ^^;

이번에는.. OTV에서의 FHRP Isolation에 대한 내용입니다. ^^.

그럼 한 분이라도 도움이 되시길 바라며, 혹시 수정해야 하는 부분이 있으면 알려주시면 감사하겠습니다.


 

 

○ FHRP Isolation

   -  Overlay를 통한 FHRP(HSRP, VRRP 등) Filter를 제공하여, 양 Site에서 동일한 FHRP의 VIP를 사용할 수 있도록 한다.

   - 서로 다른 Site 간의 동일한 Default Gateway를 사용함으로써, Outbound Traffic Flow(Server → Client)에 대해 최적화 할 수 있다.

       * 서로 다른 Default Gateway 사용 시에는 Server의 위치가 변경됨에 따라서, Default Gateway를 변경해주어야 하거나,

          그렇지 않은 경우에는 Server에서 Client로 전송 시에, Gateway가 있는 Site로 Overlay를 통해서 전송된 후에 전송된다.

   - 동일한 VLAN, IP Subnet이 서로 다른 Site에서 사용될 때, FHRP Message는 OTV 연결을 통해서 하나의 Default gateway를

     선출한다.  이러한 경우에는 위에서 언급한 대로, 아래 그림과 같은 최적화되지 못한 경로로 트래픽이 전송될 수 있다.

 

 

   - 위와 같은 최적화되지 못한 트래픽 경로에 대한 문제점을 해결하기 위해서는 FHRP Message가 Overlay를 통해서 전송될 때,

     Filtering하여, 각 Site간의 동일한 FHRP의 Default Gateway를 가지는 것을 허용하게 된다.

     이는 각 Site에서 동일한 Virtual IP 및 Virtual Mac-address를 가지게 되는 것을 허용하게 되고, 이를 통해 각 Site별로

     Outbound Traffic의 경로 최적화를 만들 수 있다.

 

 

 


 

‡ FHRP Filtering을 위한 Config Example.

  

Step 1 : OTV VDC에 VLAN ACL 적용

   - Traffic을 식별하여 Filtering하기 위해 VLAN ACL이 필요로 하다.

   - OTV Overlay를 통하여 Remote Site로부터 GARP의 수신을 막아주며,  이는 'ip arp inspection filter' 명령을 사용한다.

   - 아래의 설정을 Agg VDC에서 OTV VDC로 가는 구간의 VLAN에 적용을 하게 되면 OTV VDC에서는 모든 HSRP Message에

     대해서 Drop 된다.

 

ip access-list ALL_IPs
   10 permit ip any any
!
mac access-list ALL_MACs
   10 permit any any
!
ip access-list HSRP_IP
   10 permit udp any 224.0.0.2/32 eq 1985                                                       // HSRPv1 Message         
   20 permit udp any 224.0.0.102/32 eq 1985                                                   // HSRPv2 Message (2029 인지 확인!)

!
mac access-list HSRP_VMAC
   10 permit 0000.0c07.ac00 0000.0000.00ff any                                            // HSRPv1 VIP Mac-Address
   20 permit 0000.0c9f.f000 0000.0000.0fff any                                              // HSRPv2 VIP Mac-Address 
!
arp access-list HSRP_VMAC_ARP
   10 deny ip any mac 0000.0c07.ac00 ffff.ffff.ff00
   20 deny ip any mac 0000.0c9f.f000 ffff.ffff.f000
   30 permit ip any mac any

 

vlan access-map HSRP_Localization 10
   match mac address HSRP_VMAC
   match ip address HSRP_IP
   action drop

 

vlan access-map HSRP_Localization 20                                           // HSRP에 해당하지 않는 모든 MAC , IP
   match mac address ALL_MACs
   match ip address ALL_IPs
   action forward
!
feature dhcp
ip arp inspection filter HSRP_VMAC_ARP <OTV_Extended_VLANs>
vlan filter HSRP_Localization vlan-list <OTV_Extended_VLANs>
 

 

 ※ FHRP Message

 - GLBP : UDP / 224.0.0.102 / 3222

 - VRRP : IP / 224.0.0.18 / 112

 - HSRPv1 : UDP / 224.0.0.2 / 1985

 - HSRPv2 : UDP / 224.0.0.102 / 1985 (IPv6는 2029)

 

Step 2 : OTV Control Protocol(IS-IS)에 Route-map 적용

  - Step 1에서 HSRP Filter를 VCAL를 통해서 적용하였지만, HSRP packet의 Source로 사용된 vMAC을 OTV VDC를 통해서 학습한다.

    따라서, 이러한 MAC 정보는 IS-IS update를 통해서 OTV 광고가 이뤄지고 이는 Remote OTV Edge Device에서 vMAC이

 

    Internal Interface와 Overlay Interface 사이에서 계속 이동하는 것을 볼 수 있게 된다.

 

  - 이러한 vMAC 이동을 예방하고, 보다 나은 Design을 위해서 아래와 같이 OTV Route-map을 적용해야 한다.

 

 

mac-list OTV_HSRP_VMAC_deny seq 10 deny 0000.0c07.ac00 ffff.ffff.ff00
mac-list OTV_HSRP_VMAC_deny seq 11 deny 0000.0c9f.f000 ffff.ffff.f000
mac-list OTV_HSRP_VMAC_deny seq 20 permit 0000.0000.0000 0000.0000.0000
!
route-map OTV_HSRP_filter permit 10
   match mac-list OTV_HSRP_VMAC_deny
!
otv-isis default
   vpn Overlay0
      redistribute filter route-map OTV_HSRP_filter

 

 

◇ 적용 전, HSRP 상태 : Center쪽이 Active 상태

CENTER_N7K-BB(config)# sh hsrp bri
*:IPv6 group   #:group belongs to a bundle
                     P indicates configured to preempt.
                     |
 Interface   Grp    Prio P State    Active addr      Standby addr     Group addr
  Vlan400     10   100    Active  local                  192.168.250.3  192.168.250.1   (conf)
  Vlan400     20   100    Active  local                  192.168.250.3 192.168.250.250 (conf)

 

DR_N7K-BB(config)# sh hsrp bri
*:IPv6 group   #:group belongs to a bundle
                     P indicates configured to preempt.
                     |
 Interface   Grp  Prio P State    Active addr      Standby addr     Group addr
  Vlan400     10   100    Standby  192.168.250.2    local            192.168.250.1   (conf)
  Vlan400     20   100    Standby  192.168.250.2    local            192.168.250.250 (conf)

 

 

◇ 적용 후, HSRP 상태 : Center와 DR 모두 각각이 Active 상태

CENTER_N7K-BB(config)# sh hsrp bri
*:IPv6 group   #:group belongs to a bundle
                     P indicates configured to preempt.
                     |
 Interface   Grp  Prio P State    Active addr      Standby addr     Group addr
  Vlan400     10   100    Active   local            unknown          192.168.250.1   (conf)
  Vlan400     20   100    Active   local            unknown          192.168.250.250 (conf)
CENTER_N7K-BB(config)#


DR_7K-BB(config)# sh hsrp bri
                     P indicates configured to preempt.
                     |
Interface   Grp Prio P State    Active addr      Standby addr     Group addr
Vlan400     10  100    Active   local            unknown          192.168.250.1   (conf)
Vlan400     20  100    Active   local            unknown          192.168.250.250 (conf)

 

 

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

        이런 저런 이유들로 다시 또 오랜만에 남기게 되는 포스팅입니다.

    OTV를 정리해 봐야지하고 하면서 OTV에 대해 처음 정리한 게 언제였는지 보니.. 벌써 2달전이네요..

   그 사이에 다른 걸 포스팅은 안한건 아니지만 바쁘다는 이유로 나태지고 있는건 아닌지 반성해봅니다.

  원래 Multicast와 Unicast 부분을 모두 정리한 이후에 올리려다가, 현재까지 작성해놓은 Multicast 부분만 먼저 올려봅니다..


 OTV Control Plane

• OTV 동작의 기본 원칙은, Data Plane 학습을 사용하는 대신에, OTV Edge Device간의 MAC address reachability 정보를  광고하는

 Control Protocol을 사용하는 것이다.   물론 MAC reachability 정보를 교환하기 전에, 모든 OTV edge Device들은 반드시 각각

 “Adjacent”를 관계  맺어져야만 한다. 이것은 다음의 2가지 방법에 의해서 가능하게 된다.

 

  1. Multicast 가능

     - OTV Edge Device 간의 특정 Multicast group를 사용하여 Control Protocol message를 교환하여 “Adjacent”를 맺는다.

 

  2. Multicast 불가능

     - 한 대 이상의 OTV Edge Device“Adjacency Server” 설정을 하여, 모든 Edge Device들이 해당 Server로 등록을 하게 되면, Server에서는 해당 Overlay에 속하는 Device List를 전달하여 “Adjacent”를 맺게 된다.

     - NX-OS release 5.2(1)부터 사용 가능.

 

 

 

OTV Control Plane – Multicast Enabled Transport Infrastructure

• Multicast가 가능한 전송계층일 경우에 , 모든 OTV Edge Devicereceiversource의 역할을 동시에 하는 특정 ASM(Any Source

 Multicast)  groupJoin 하도록 설정할 수 있다.

만약 전송계층이 Service Provider 것이며, EnterpriseService Provider과 함께 이러한 ASM Group 사용에 대한 협의를 해야 한다.

  

 

 

 

OTV Control Plane – Multicast Enabled Transport Infrastructure

 동작 절차

  1. OTV Edge DeviceIGMP report로 특정 ASM GroupJoin하여 Control Protocol을 교환한다. (이 예에서는 group G)

    Edge DeviceJoin Interface를 사용하여, GroupHost로써 Join한다.

     The only requirement is to specify the ASM group to be used and associate it with a given Overlay interface.

  2.  OTV Control Protocol이 동작 중인,  왼쪽 OTV Edge Device는 다른 모든 OTV Edge Device로 보낼 Hello 패킷을 생성한다.

     이를 통해서 Control Plane Adjacency를 맺게 된다.

  3. OTV Hello message는 모든 OTV remote device들에 도달할 수 있는 논리적인 overlay를 통해 전송 되야 한다.

    이 때에 Original FrameOTV 캡슐화되고, 외부에 IP header가 추가된다.  추가된 외부의 headerSource IP Address

    Edge Devive  Join InterfaceIP address로 설정되고, DestinationASM Group Multicast address가 된다. 

    결과적으로 Multicast FrameJoin Interface로 보내어, Layer 3 Network Domain으로 전송된다.

  4.  Multicast frame들은 Transport를 통해 전송되며, Multicast group GJoinOTV edge device들에게 도달되도록 최적 복제가

     된다.

  5. Packet을 수신한 OTV Edge DeviceDecapsulate 한다.

  6. Hello MessageControl Protocol 프로세스로 전달된다.

 

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

• Hello message를 통한 ASM group의 사용으로 Edge device들이 서로 Shared LAN segment에 있는 것처럼 상대 Edge Device를 인식한다.

• LAN segment는 기본적으로 OTV overly를 통해서 구현된다.

 

 

 

 

OTV Control Plane – Multicast Enabled Transport Infrastructure

• OTV Control Protocol의 중요 고려사항

   1. ProtocolOTV Edge Device들 간에 “overlay” Control Plane으로 동작한다.

     , Data CenterLayer 3에서 사용되는 Routing Protocol이나, 전송 인프라에 의존적이지 않고 동작을 하게 된다.

   2. OTV Control PlaneOTV Overlay Interface를 생성한 후에는 명시적으로 설정할 필요 없이 활성화가 된다.

      timer와 같이 Parameter들의 조정이 OTV Protocol에서 허용은 되지만, 일반적으로 하지는 않는다.

• MAC Address 광고 동작 순서

  1. West Datacenter에서 새로운 MAC A, B, C를 내부 Interface를 통해서 학습한다.

  2. 내부 Interface를 통해서 학습한 MAC A, B, C 정보를 포함하여 OTV Update Message를 만든 후에 캡슐화하여 Layer 3 Transport

     보낸다.

  3. OTV UpdateTransport에서 최적화된 복제를 하여, 모든 원격지 Edge Device들로 보내진 후에,  Decapsulation되어서 OTV

     Control Process로 전달된다.

  4. MAC reachability 정보는 Edge DeviceMAC Address Table(CAM)에서 가져 오게 된다.

    기존 CAM Entry와의 차이점은 물리적인 Interface 대신에 해당 MAC Address 정보가 생성된 Edge DeviceJoin Interface

    IP  Address로 대체된다는 점이다.

• MAC reachability 정보가 제거될 때에도 동일한 Control Plane 통신을 통해 제거된다.

 예를 들어, 특정 Network Entry가 통신이 끊겼을 경우에 OTV Edge DeviceCAM Table로부터 MAC Entry가 제거된다.

  (Default 30min) 

 MAC Entry 제거는 OTV Protocol Update를 통해서 모든 원격지 Edge Device들에게 동일한 MAC Entry를 제거시킨다.

Posted by 네떡지기

이번에 포스팅을 하면서... 이번에 올려야 하나.. 또 좀 더 정리를 해야 하나... 하다가..

쪼개더라도.. 역시.. 그냥 올리는게 나을 거 같다는 생각으로 올려봅니다..

요즘 조금 몸과 마음이 힘든 상태인지라.. 더 정리가 잘 안되는듯.. 한건.. 아마도 핑계겠지요... ^^;


vPC check (Loop Prevention)

• vPC 에서 vPC Member Port로 들어온 PacketPeer-link를 통해서 다시 vPC Member Port로 전송이 될 경우에, 동일한 Packet이 중복되어서 목적지에 도달하고, 동일한 Source Mac-Address에 대해서 서로 다른 Port에서 Learning하게 되어 Loop가 발생할 수 있다.

이처럼 Peer-link를 통해서 들어온 PacketvPC Member Port를 통해서 나가는 경우에 발생할 수 있는 문제점들로 인해서,

  vPCControl Plane 대신에 Data Plane을 통해서 Loop를 회피한다. CPU를 사용하지 않고, vPC Peer-link port가 있는 Hardware

  모든 Logic이 구현되어 있어서 Peer-link들어오는 PacketvPC가 동작 중인 Port를 통해서 나가지 않도록 Egress Port ASICs

  서 모두 Drop 시킨다.  이것을 VPC check’라고 하며, 모든 Traffic(Layer 2, Layer 3, Unicast, multicast, broadcast, flooded )에 대

  해서 적용된다.  물론, Peer-link를 통하더라도 vPC가 동작하지 않는 Port로는 정상적으로 Packet이 전송 된다

 , vPC Member PortDown될 경우 예외적으로 vPC peer DeviceMember Port상태와 vPC Loop avoidance logic을 재 프로그

  램하여 peer-link가 최적의 복구를 위한 백업 경로로써 사용이 된다

 

 

 

 

 

 

vPC Layer 3 Designs

• Layer 3 DevicevPC를 사용하여, vPC Domain에 연결하는 것은 구성은  vPC loop avoidance rule 때문에 지원되지 않는다.

• Laver 3 DevicevPCDomain에 연결하고자 할 때에는 Layer 3 link로 각각의 vPC Peer Device에 연결해야 합니다.

vPC Domain상에서 Layer 2 Port-channel을 통해서 RouterRouting 연결을 하려고 할 경우에 neighbor를 맺을 때 vPCPeer 

  과의 neighbor를 직접 맺지 못하고, 각각의 Peer와 연결된 vPC Port로 분산되서 통신을 하기 때문에 정상적인 neighbor을 맺을 수

  없다.  따라서, vPC Domain에서는 해당 vPC가 동작 중인 vPC PortRouting Protocol이 동작 중인 장비를 연결하면 안된다.

• vPC DomainLayer 3 Device를 연결하는 것은,  Layer 3 Device에서 HSRP addressStatic route를 하는 구성은 가능하다.

만약 RoutedBridged Traffic을 동시에 운용하기 위해서는 Routed  Traffic 위한 개별 layer 3 LinkBridged Traffic를 위한

  Layer 2 Port-Channel별도의 Link구성해야 한다

 

 

 

Posted by 네떡지기

이번 포스팅은 그나마 그 전 포스팅 올린 시기와 비교해서 조금 빠른(?) 간격을 두고 올려봅니다.

이번 것도 지난 번과 마찬가지로 기존에 정리를 하고 있었지만, 딱 정리를 됐다는 느낌을 가지지 못해서 계속 가지고 있던

부분이었는데, 그것보다는 포스팅을 하고 버전 관리를 하는 편이 더 좋을 듯 싶어서 올려봅니다.

버전관리를 위해서 혹시 이상한 부분이나 수정해야 하는 부분이 있으면 알려주시면 감사하겠습니다.


 

vPC System-MAC & vPC Local System-MAC

• vPC peer device간에는 vPC Domain ID를 사용하여 자동적으로 vPC System Mac-Address가 아래와 같이 할당된다.

  (수동설정도 가능)

      -  vPC system-mac = 00:23:04:ee:be:<vPC domain-id 값의 16진수>  

      -  vPC Domain ID (27) : 00:23:04:ee:be: 1b

• vPC System macPeer device 간에 동일하며, 이것은 vPCLayer 2 가상화를 위한 바탕이 된다.

• vPC System들에서 논리적인 Device라는 것을 나타내기 위해서, vPC System Mac을 사용하게 된다. 

   (Peer간에는 서로 공유하고 있는 동일힌 값이면서, 다른 장비의 값과 다른 유일한 값을 가진 주소)

• vPC Peer 간의 구분을 하기 위해서 Peer별로 System 혹은 VDC Mac-address로부터 파생된 vPC Local System Mac Address

  가 있다.

• vPC Local System Macorphans Port와 같이 vPC System들에서 논리적인 Deivce로써의 역할이 필요 없는 경우에 사용된다.

• vPC system mac-addressvPC Local system Mac-Address 모두 LACP Protocol에서 LCAP system ID로 사용이 된다.

      - vPC System Mac-Address : vPC  Access Device와 연결된 경우.

      - vPC Local System Mac-Address : Orphan PortActvie/Standby와 같이 단독으로 연결된 경우

 

 

 

 

vPC System-MAC & vPC Local System-MAC 확인

 - vPC Domain ID :   sh vpc  - vPC System Mac , Local Mac :  sh  vpc role   - VDC Mac :  sh  vdc

 

NX-OS# sh vpc

Legend:

  (*) - local vPC is down, forwarding via vPC peer-link

vPC domain id  : 1 

Peer status  : peer adjacency formed ok 

vPC keep-alive status  : peer is alive 

Configuration consistency status  : success

Per-vlan consistency status  : success 

Type-2 consistency status  : success

vPC role  : primary

Number of vPCs configured  : 1 

Peer Gateway  : Disabled

Dual-active excluded VLANs  : -

Graceful Consistency Check  : Enabled

Auto-recovery status  : Disabled

vPC Peer-link status

---------------------------------------------------------------------

id  Port  Status   Active vlans 

--  ----  ------  ----------------

1  Po1  up  1-2,20-22 

vPC status

------------------------------------------------------------------------------------------------------

id  Port  Status  Consistency   Reason  Active vlans

--  ----  ------  -----------   ------  ---------------

2  Po2  up  success  success  1-2,20-22

 

 

NX-OS# sh vpc role

vPC Role status

----------------------------------------------------

vPC role  : primary, operational secondary

Dual Active Detection Status  : 0

vPC system-mac  : 00:23:04:ee:be:01 

vPC system-priority  : 32667

vPC local system-mac  : 00:26:98:0d:19:41 

vPC local role-priority  : 1

 

 

NX-OS#  sh vdc

vdc_id  vdc_name  state  mac    type  lc 

------  --------  -----  ----------    ---------  ------ 

1  VDC1  active  00:26:98:0d:19:41  Ethernet  m1 f1 m1xl

2  VDC2  active  00:26:98:0d:19:42  Ethernet  m1 f1 m1xl

3  VDC3  active  00:26:98:0d:19:43  Ethernet  m1 f1 m1xl

4  VDC4  active  00:26:98:0d:19:44  Ethernet  m1 f1 m1xl

 

 

 

vPC Domain 구성  절차

1. vPC를 구성하는 장비 양단 간에 동일한  vPC Domain ID를 설정한다. (반드시 Domain ID는 동일해야 함.)

     - 상하단의 장비에서 모두 vPC를 구성할 때, 동일한 위치 상의 Peer 장비 간에는 vPC Domain이 동일해야 한다.

     - Double-sided vPC topology(.하단 모두 vPC 구성-아래그림참조) 구성 시에는 반드시 상하단의 vPC Domain ID

       달라야 한다.   이 정보가 LACP Protocol의 일부로 사용되며, 동일한 ID를 사용하게 되면, vPC 사이에서 flaps이 발생한다.

2. vPC peer-keepalive link를 양단 간 peer 장비 모두 설정한다.

   Link가 정상적으로 동작하여야만, vPC Domain 구성이 가능하다.

 

NX-OS(Config)# vpc domain 1

NX-OS(Config-vpc-domain)# peer-keepalive destination 1.1.1.2 source 1.1.1.1 vrf vPC_Keepalive

 

3. vPC peer장비 사이의 Inter Switch Link(ISL) L2 trunk port-channel이 설정한다. (기존에 구성된 Link로도 가능)

4. Access Device에서 Nexus 장비와 연결된 포트를 Port-Channel을 구성한다. (기존에 구성된 Port-Channel로도 가능

 

 

 

 

유의사항

 vPCDCI(Data Center Interconnect)를 목적으로 사용하는 경우에, Data center간의 vPC Domain은 서로 달라야 한다. 

 Double-sided vPC 구성과 마찬가지 이유로 LACP Protocol의 일부로 vPC domain ID가 사용되기 때문이다.

 만일, 동일한 domain ID를 사용하고자 할 때에는 vPC Domain 설정에서 System-macvPC system-mac 값과 다른 값으로

설정하면, 사용이 가능하지만, 다른 domain ID를 사용하는 것을 권고함.

 

 

 

vPC Type 1 일관성 체크

vPC Feature 활성화와 vPC peer-link 설정을 양쪽 Peer 장비에 한 후, CFS MessageRemote vPC Peer 장비로 Local vPC peer장비 구성 설정의 사본을 보내서, peer간의 vPC를 구성하는 주요 vPC 구성 매개 변수가 서로 다른 것이 있는지 확인을 한다.

자동으로 vPC 구성을 위한 매개변수의 호환성을 체크한다. 

• Interface별 매개변수는 Interface별로 동일해야 하며, Global