'control plane'에 해당되는 글 1건

  1. 2013.04.14 Nexus - NX-OS 정리 Part 21(OTV 3: Control Plane)

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를 주기적으로 전송하게 된다.

  OTVAdjacency ServerGraceful exit를 사용하여, Primary Adjacency Server가 설정이 되어 있지 않거나 재 부팅 할 때,

   PrimaryClient가 그것을 알고 적절하게 종료할 수 있도록 하여, Timed out를 기다리지 않고, Secondary Adjacency Server

   List로 대체할 수 있게 한다

Posted by 네떡지기

티스토리 툴바