분류없음2016.12.23 08:50

 

안녕하세요.

네떡지기입니다.


본 블로그에서 나름 오랜(?)기간 포스팅 했었던.. 시리즈인..

Nexus 기초 따라잡기에 대한 PDF판을 공개합니다.


아무래도 시간이 좀 지난거라서 달라진 부분들도  있을꺼고,

미처 잘못 작성된 것을 수정하지 못한 부분들도 있을 수 있습니다.


하지만, 커다란 맥락에서는 큰 부분이 달라지지는 않았으리라.. 생각하고..

달라지는 부분들도 기존의 것들을 알고 있어야 할 것이라고 생각하기 때문에...


2016년 크리스마스를 앞두고... PDF판으로 공개를 합니다.

표지,간지를 포함하여.. 무려. 192페이지에 달하는...


누군가에게는... 도움이 되기를 바라며... ^^

 

p.s. 2016년에는.. 기존의 포스팅과 더불어... 또 다른.. 장기 시리즈가 시작되지 않을까? 싶습니다..

 

 

 

 

Nexus_기초따라잡기(공개).z01

Nexus_기초따라잡기(공개).z02

Nexus_기초따라잡기(공개).zip


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 네떡지기
분류없음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 네떡지기
분류없음2014.09.29 21:26

 


오랜만에 포스팅하는 Nexus : NX-OS 시리즈입니다.

 

예전에 포스팅했던, OTV의 Data Plane의 Unicast/Broadcast 부분에 이어서, Multcast에 대한 Data Plane입니다.

휴가 전에 대부분의 내용을 쓰고, 휴가 직전에 포스팅하지 못해서 마지막 부분만 휴가 이후에 올리게 되네요..

무척 오랫만에 올리는 Nexus 정리 포스팅입니다.  ^^;


 

OTV Data Plane – Multicast Traffic

• 특정한 경우에 Remote Site간의 Layer 2 Multicast 통신이 필요한 경우가 있을 수 있다.

• OTV Site 간의 Layer 2 Multicast의 경우에 Multicast가 지원환경과 지원불가 환경으로 나누어서 고려되어야 한다.

 


 

 

OTV Data Plane – Multicast Traffic (Multicast 지원 환경)

• Layer 2 Multicast 트래픽은 OTV overlay를 통해서  전송되며,  Suboptimal한 Head-end 복제를 방지하기 위해

   Multicast가 가능한 Transport Infrastructure가 요구된다.

•Multicast가 가능한 Transport Infrastructure를 통해 Layer 2 Multicast를 전송하는 데 하나의 SSM

  (Source Specific Multicast) Group를 이용한다.

   이 Group은 Site간의 OTV Control Protocol을 전송하기 위한 ASM group과는 독립적으로 사용된다

 

 

 

 Multicast Source 최초 활성화 시

  1. West Side에서 활성화된 Multicast Source가 Group Gs로 Traffic을 전송한다.


   2. Local의 OTV Edge Device는 첫 번째 Multicast Frame을 수신하고, Group Gs와 Transport  Infrastructure에서 사용될 특정
       SSM Gd Group간의 Mapping을 생성한다.


       Layer 2 Multicast Data Stream을 전송하는 데 사용되는 SSM Group의 범위는 Overlay Interface의 설정에 들어가게 된다.

       Ex>  NX-OS(config-if-overlay)# otv data-group 232.1.1.0/28

 

  3. OTV Control Protocol은 모든 Remote OTV Edge Device들의 Gs와 Gd 간의 Mapping을 전달하기 위해 사용된다.
      Mapping 정보는 Multicast Source가 속한 VLAN과 Mapping이 만들어진 OTV Edge Device의 IP address간의 정보로 구성된다.

                                 

 

 

 

 Multicast Source와 동일한 VLAN에 Deploy된 Receiver가 Group Gs에 Join하는 과정

  1.East Side Client가 GS group에 Join 할 수 있도록 IGMP Report를 전송

 

  2.OTV edge device가 IGMP Message를 snoop하고, VLAN A에 속한 Gs Group의 Active receiver이 있음을 확인한다.


  3.OTV Device는 OTV Control Protocol Message를 모든 Remote Edge Device로 전송한다.


  4.West Side의 Remote OTV Edge Device는 GM-Update를 수신하여, OTV Overlay를 통해서 전달될 group Gs에 대한
     OIL(Outgoing Interface List) 를 업데이트 한다.

 

  5.East Side의 OTV Edge Device는 이전에 IP A에 의해서 확인한 West side의 OTV Edge Device로부터 받은 Mapping정보를 찾는다.
      East Edge Device는  (IP A, Gd) SSM Group에 Join하기 위한 IGMPv3 report를 전송한다.

     이를 통해 Transport Infrastructure를 통해서 Multicast Gs를 전송하는데 사용될 수 있는 SSM tree(group Gd)를 만든다.

 

 

 

 

 

 OTV를 통한 Multicast 전송 과정

  1.OTV Edge Device가 Gs Stream를 수신하고, Overlay를 통하여 Gs Group을 수신하고자 하는 Receiver에게 전송하기 위해

    OIL를 확인 후에, Interface를 결정한다.

 

2. Edge device에서 Original Multicast frame을 Encapsulation 한다.  Outer IP header의 Source는 자신의 IP A로 설정되고,

     Destination은 Multicast data를 전송하기 위해 할당된 Gd SSM Group으로 설정된다.

 

3. Multicast Stream Gd는 기존의 Transport Infrastructure를 통해 만들어진 SSM Tree를 통해서, Gs Stream을 수신하고자 하는

     Receiver들이 있는 OTV Remote Site로 전송된다.

 

4. Remote OTV edge Deivce들은 해당 Packet을 수신한다.

 

5. Packet은 De-capsulation 되어서, 각 Site 내의 Receiver들에게 전송된다.

 

 

 

 



OTV Data Plane – Multicast Traffic (Unicast only Transport Infrastructure 환경)

  • Layer 2 Multicast 트래픽은 OTV overlay를 통해서  전송되며,  Suboptimal한 Head-end 복제를 방지하기 위해

      

Unicast Core망을 통한 Multicast Group Gs에 Receiver Join 시

  1. East Site에 있는 Client가 Gs group에 Join하기 위해 IGMP report를 보낸다.

 

  2. OTV Edge Device는 IGMP Message를 확인하여, VLAN 100에서 group Gs에 Active Receiver가 있다는 것을 알게 된다.

 

  3. OTV Edge Device는 OTV control protocol message(GM-Update)를  각 Unicast List에 속해 있는 remote Edge Device로

     전송하여 2번에서 확인된 정보를 전달한다.

 

   4. Remote Edge Device들은 GM-Update Message를 수신하게  되고,  multicast group Gs1의  receiver가  IP B Address로

    확인되는 OTV Device를 통해서 연결되어 있다는 정보와 "Data Group Mapping Table"을 함께 Update 한다.

 

 

 

 

 

 

 Unicast Core망을 통한 Layer 2 Multicast Stream Gs 전송 시

  1. Gs1을 목적지로 하는 Multicast TrafficWest Site의 내부에서 만들어지게 되고, OTV Edge Device“Data Group Mapping Table’에서

      OIFLookup한다. 아래 예시의 ‘Data Group Mapping Table’에서는 해당 Multicast Traffic EastSouthOverlay를 연결된 것을 확인한다.

  2. West SiteOTV Edge Devicehead-end replication을 통해 원래  Layer 2 Multicast Frame을 캡슐화한 2개의 Unicast IP Packet를 생성한다.

      이 때, Outer IP header IPWest SiteIP A로 설정이 되고, Destination IPSouth/EastIPIPB/C로 설정된다.

  3.  Unicast FrameRouting을 통해 Transport Infrastructure를 거쳐서 Remote OTV Device로 전송되게 되어, De-capsulation이 되어

       SiteReceiver들에게 전송된다.  이 때, North Site에는 해당 Multicast TrafficReceiver가 없기 때문에 Data Group Mapping TableNorth Site가 존재하지 않고,  따라서 Frame이 전송되지 않는다.

 

 

 

 

Posted by 네떡지기

예전에 OTV의 Control Plane 이후의 이번에는 Data Plane에 대한 내용입니다.

정리하다보니, 예전에 정리된 내용과 비슷한 것 같네요.

Unicast와 정말 간략한 Broadcast 정리만 먼저 올리고, Multicast에 대한 부분은 다음으로 미룹니다.

예전에도 그랬지만, 차례대로라기 보다는 제가 정리하게 된 순서대로 올리게 됩니다. ^^;

혹시 수정해야 하는 부분이나 잘못된 점이 있다면 알려주시면 감사하겠습니다.

 


 

 

OTV Data Plane – Unicast Traffic

• Unicast Trafrfic 전송 순서

   1. Aggregation LayerOTV Edge Device로부터 Layer 2 Frame전송받으면, 전통적인 L2 Lookup을 수행한다.

     이 때, 원격 OTV SiteMAC 주소에 대한 Mac-address TableLocal Ethernet 혹은 원격지의 IP가 아닌 Overlay Interface이다..

 

NX-OS# sh mac address-table
Legend:
        * - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
        age - seconds since last seen,+ - primary entry using vPC Peer-Link
   VLAN     MAC Address      Type      age     Secure NTFY Ports/SWID.SSID.LID
---------+-----------------+--------+---------+------+----+------------------
G     -    0024.f714.c242    static       -       F    F  sup-eth1(R)
* 100      000d.ecb2.5088    dynamic   450        F    F  Eth2/3
O 100      000d.ecb2.5089    dynamic   0          F    F  Overlay1
O 100      0050.568d.1520    dynamic   0          F    F  Overlay1 

 

  2. OTV Edge DeviceOriginal Layer 2 Frame을 캡슐화한다.

     외부 Header Source IPJoin InterfaceIP로 설정하고, Destination IPRemote Edge DeviceJoin Interface로 설정한다.

 

 3. OTV로 캡슐화된 Frame(일반 Unicast IP Packet)Transport infrastructur를 거쳐서 remote OTV Edge Device로 전송된다.

 

  4. Remote OTV Edge Device디캡슐화 하여, Original Layer 2 Packet을 추출한다.

 

  5. Edge DeviceOriginal Layer 2 Packet의 정보로 L2 Lookup을 수행하여 물리적인 Interfrace를 통해 최종 목적지로 전달한다.

 

Ehternet FrameOTV로 캡슐화 된 후에 전송이 될 때에는 42Bytes의 전체 MTU를 증가시키게 된다.

  하지만, OTV Edge Device‘Don’t Fragment’(DF) bit set하게 되고, PMTUD 옵션을 지원하지 않는다. Fragmentation

  Reassembly도  Nexus 7000에서는 불가하기 떄문에 OTV Edge Device 사이의 모든 물리적 Interfrace에서 MTU 크기를 증가시키는

  것이 좋다.     

                                                                                                    ※ ASR 1000에서는 Packet Fragmention이 가능하다.

 

 

 

다음은 Local Site /  Remote Site 에서의 Unicast 전송에 대한 참고 그림이다.

 

○ Local Site

 

○ Remote Site

 

 

 

OTV Data Plane – Broadcast Traffic

• Multicast 환경 : OTV control protocol에서 이미 사용 하는 것과 동일한ASM multicast group 이용하여 Remote OTV Edge에

                         Broadcast를 전송한다.

 

• Unicast 환경 : OTV Device에서 Head-end 복제를 수행하고 이를 OTV unicast-only list에 있는 remote OTV edge device들로

                      전송한다.

 

Posted by 네떡지기

Last Update(2013.12.20)


 몇 달여만에 다시 정리를 하게되었습니다.

 이런 저런 일들과 마땅히 정리할 수 있는 여건이 되지 않아서.. 정말 오랜만에 정리를 해서 올립니다.

 몇 달만에 본 내용이라 다시 처음부터 보면서 하느라.. 제대로 맞는지 어떤지 모르겠습니다.

 

 이번 내용은 실제 OTV를 구축하기 위한 기본 설정에 관련한 내용입니다.

 부족한 내용이지만, 도움이 되시길 바라며 혹시 잘못되어 수정이 필요한 내용이 있으면 덧글 부탁드립니다.

  

 


 

OTV Mode

 

       • OTV에서 L2 Adjacency는 이전에 살펴본 것 처럼 2가지 Mode로 원격지 사이트와의 overlay network를 통해서 구성한다.

     1. Multicast Group을 통하여 OTV Hello message로 OTV Site 간의 자동 확인             [ Multicast Mode ]            

     2. OTV adjacency Server를 구성하고, 다른 OTV Client들의 모든 List를 관리 및 배포.   [ Unicast Mode ] 

 

      •  OTV를  Multicast 방식으로 구성하게 되면, 다수의 OTV 사이트 구성 시에 보다 유연하고 적은 Overhead를 가지게 된다.

    하지만, 2~3개의 소수의 Site를 OTV를 구성하는 경우에는 Unicast로 구성하여도 기능상의 이슈 없이 동작이 가능하다.

    그리고 Multicast를 구성하고자 할 때에는 중간의 Transport Network에서 Multicast를 지원해야 하나, ISP에서 이를 지원

   하지 않는 경우에 Unicast를 사용할 수 밖에 없게 된다.

   ※ Nexus 7000 / ASR 1000은 Multicast/Unicast 모두 지원.

      단, Unicast는 Nexus 7000 NX-OS 5.2(1) 이상 / CSR 1000 IOS-XE 3.9 이상 에서 지원된다.

 

 


OTV Configuration

 

     • OTV에서 Multicast Mode와 Unicast Mode로 구성하는 간단한 설정 확인

 

 

 OTV 설정 구성

 

 

 

Multicast Mode Simple Configuration

 

 

 ▷ 기본 환경 구성

 

[ ISP ]

 ISP(config)# int gi 1/1

 ISP(config-if)# ip address 10.12.1.2 255.255.255.0

 ISP(config-if)# ip pim sparse-mode                            

 ISP(config-if)# ip igmp version 3

 ISP(config-if)# no shut

 ISP(config)# int gi 2/1

 ISP(config-if)# ip address 10.12.2.2 255.255.255.0

 ISP(config-if)# ip pim sparse-mode

 ISP(config-if)# ip igmp version 3

 ISP(config-if)# no shut

 ISP(config)# router ospf 1

 ISP(config-router)# network 10.12.1.0 0.0.0.255 area 0

 ISP(config-router)# network 10.12.2.0 0.0.0.255 area 0 

 

 [ NX_1 ]

 NX_1(config)# router ospf 1

 NX_1(config-if)# int ether 1/1

 NX_1(config-if)# ip address 10.12.1.1 255.255.255.0

 NX_1(config-if)# ip router ospf 1 area 0

 NX_1(config-if)# ip igmp version 3

 NX_1(config-if)# no shut

 

[ NX_2 ]

 NX_2(config)# router ospf 1

 NX_2(config-if)# int ether 1/1

 NX_2(config-if)# ip address 10.12.2.1 255.255.255.0

 NX_2(config-if)# ip router ospf 1 area 0

 NX_2(config-if)# ip igmp version 3

 NX_2(config-if)# no shut

 

  - 여기까지 구성을 완료하게 되면, NX-1 Site와 NX-2 Site 간의 통신을 위한 기본 네트워크 구성을 마치게 된다.

    NX-1에서 NX-2까지 통신도 정상적으로 된다.

 

 

  ▷ OTV 설정

 

[ NX_1 ]

 NX_1(config)# feature otv

 

 NX_1(config)# vlan 111

 NX_1(config)# otv site-vlan 111

 NX_1(config)# otv site-identifier 1.1.1

 

 NX_1(config)# interface Ethernet2/1

 NX_1(config-if)# switchport

 NX_1(config-if)# switchport mode access

 NX_1(config-if)# switchport access vlan 111

 NX_1(config-if)# no shutdown

 

 NX_1(config)# vlan 100

 NX_1(config)# interface Ethernet 2/3

 NX_1(config-if)# switchport

 NX_1(config-if)# switchport mode access

 NX_1(config-if)# switchport access vlan 100

 NX_1(config-if)# no shutdown

 

 NX_1(config)# interface overlay 1

 NX_1(config-if-overlay)# otv control-group 239.1.1.1

 NX_1(config-if-overlay)# otv data-group 232.1.1.0/28

 NX_1(config-if-overlay)# otv join-interface ethernet 1/1

   OTV needs join interfaces to be configured for IGMP version 3

 NX_1(config-if-overlay)# otv extend-vlan 100

 NX_1(config-if-overlay)# no shut

 

 

[ NX_2 ]

 NX_2(config)# feature otv

 

 NX_2(config)# vlan 112

 NX_2(config)# otv site-vlan 112

 NX_2(config)# otv site-identifier 1.1.2

 

 NX_2(config)# interface Ethernet2/1

 NX_2(config-if)# switchport

 NX_2(config-if)# switchport mode access

 NX_2(config-if)# switchport access vlan 112

 NX_2(config-if)# no shutdown

 

 NX_2(config)# vlan 100

 NX_2(config)# interface Ethernet 2/3

 NX_2(config-if)# switchport

 NX_2(config-if)# switchport mode access

 NX_2(config-if)# switchport access vlan 100

 NX_2(config-if)# no shutdown

 

 NX_2(config)# interface overlay 1

 NX_2(config-if-overlay)# otv control-group 239.1.1.1

 NX_2(config-if-overlay)# otv data-group 232.1.1.0/28

 NX_2(config-if-overlay)# otv join-interface ethernet 1/1

      OTV needs join interfaces to be configured for IGMP version 3

 NX_2(config-if-overlay)# otv extend-vlan 100

 NX_2(config-if-overlay)# no shut

 

  - OTV 양쪽 Site의 설정을 위와 같이 마치고 나면, OTV의 기본 구성이 완료된다.

    구성이 완료된 상태에서는 다음과 같은 결과값을 확인할 수 있다.

  ※ 단, 여기에서는 Site VLAN과 Extened VLAN으로 연결된 Interface의 반대편 장비는 연결되어 정상적으로 Up된 상태로 가정.

 

 

 

NX_1# show otv adjacency

 Overlay Adjacency database

 Overlay-Interface Overlay1  :

 Hostname                         System-ID         Dest Addr       Up Time   State

 NX_2                               0022.5579.f742    10.12.2.1        00:00:09   UP  

  - OTV Adjacency 정보를 볼 수 있다.

 

 

NX_1# sh otv vlan 100 detail

 OTV Extended VLANs and Edge Device State Information (* - AED)

 Legend: F - Forwarding B - Blocked

 VLAN   Auth. Edge Device                     Vlan State       Overlay

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

  100*  NX_1                                        active              Overlay1

        MRD packets originated: 125 

 

 

 

[정상 상태]

 NX_1# show otv overlay 1

 OTV Overlay Information

 Site Identifier 0001.0001.0001

 Overlay interface Overlay1

  VPN name            : Overlay1

  VPN state           : UP

   Extended vlans      : 100 (Total:1)

  Control group       : 239.1.1.1

  Data group range(s) : 232.1.1.0/28

  Join interface(s)   : Eth1/1 (10.12.1.1)

  Site vlan           : 111 (up)

  AED-Capable         :  YES

  Capability          : Multicast-Reachable 

  - Overlay Interface의 전체적인 정보로, Extended VLAN / Multicast Group / Join interface / Site vlan등의 전반적인

    구성 정보를 볼 수 있다.

 

 

 NX_1# sh mac address-table

 Legend:

         * - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC

         age - seconds since last seen,+ - primary entry using vPC Peer-Link

    VLAN     MAC Address      Type      age     Secure NTFY Ports/SWID.SSID.LID

 ---------+-----------------+--------+---------+------+----+------------------

 G     -    0024.f714.c242    static       -       F    F  sup-eth1(R)

 * 100      000d.ecb2.5088    dynamic   450        F    F  Eth2/3

 O 100      000d.ecb2.5089    dynamic   0          F    F  Overlay1

 O 100      0050.568d.1520    dynamic   0          F    F  Overlay1

 * 100      0050.568d.1a06    dynamic   180        F    F  Eth2/3

 * 100      0050.568d.4aa6    dynamic   90         F    F  Eth2/3

 * 100      0050.568d.6583    dynamic   30         F    F  Eth2/3 

  - OTV가 정상적으로 구성된 상태에서 Overlay Interface를 통한 MAC Address Table이 만들어지게 된다.

 

 

[Extended VLAN 미활성화 시에]

 NX_1# show otv overlay 1

 OTV Overlay Information

 Site Identifier 0001.0001.0001

 Overlay interface Overlay1

  VPN name            : Overlay1

  VPN state           : UP

  Extended vlans      : 100 (Total:1)

  Control group       : 239.1.1.1

  Data group range(s) : 232.1.1.0/28

  Join interface(s)   : Eth1/1 (10.12.1.1)

  Site vlan           : 111 (up)

  AED-Capable         : No (No extended vlan is operationally up)

  Capability          : Multicast-Reachable 

- Extended VLAN중에 활성화 된 Interface가 없으면, AED 상태가 'No'로 표기되며 () 안에 사유가 표기된다.

 

 

[Site  VLAN 활성화 시에]

 

 NX_1# show otv overlay 1

 OTV Overlay Information

 Site Identifier 0001.0001.0001

 Overlay interface Overlay1

  VPN name            : Overlay1

  VPN state           : UP

  Extended vlans      : 100 (Total:1)

  Control group       : 239.1.1.1

  Data group range(s) : 232.1.1.0/28

  Join interface(s)   : Eth1/1 (10.12.1.1)

  Site vlan           : 111 (down)

  AED-Capable          No (Site-VLAN is Down)

  Capability          : Multicast-Reachable

-  Site VLAN중에 활성화 된 Interface가 없으면, AED 상태가 'No'로 표기되며 () 안에 사유가 표기된다.

 

 

[Site VLAN / Extend VLAN 비 활성화 시에]

 NX_1# sh mac address-table

 Legend:

         * - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC

         age - seconds since last seen,+ - primary entry using vPC Peer-Link

    VLAN     MAC Address      Type      age     Secure NTFY Ports/SWID.SSID.LID

 ---------+-----------------+--------+---------+------+----+------------------

 G     -    0024.f714.c242    static       -       F    F  sup-eth1(R)

 * 100      000d.ecb2.5088    dynamic   450        F    F  Eth2/3

 * 100      0050.568d.1a06    dynamic   180        F    F  Eth2/3

 * 100      0050.568d.4aa6    dynamic   90         F    F  Eth2/3

 * 100      0050.568d.6583    dynamic   30         F    F  Eth2/3

 

 NX_1# show otv adjacency

 Overlay Adjacency database

 Overlay-Interface Overlay1  :

 Hostname                         System-ID         Dest Addr       Up Time   State

 NX_2                               0022.5579.f742    10.12.2.1        00:21:25   UP  

 

-  Extended VLAN이나 Site VLAN 중의 활성화 된 Interface가 없으면 Overlay Interface MAC Addess Table이 사라진다.

-  하지만, OTV Adjacency는 그대로 Up 상태를 유지하게 된다.

 

 

Unicast Mode Simple Configuration

 

[ NX_1 ]

 NX_1(config)# interface overlay 1

 NX_1(config-if-overlay)# otv adjacency-server unicast-only

 NX_1(config-if-overlay)# otv join-interface ethernet 1/1

      OTV needs join interfaces to be configured for IGMP version 3

 NX_1(config-if-overlay)# otv extend-vlan 100

 NX_1(config-if-overlay)# no shut

 

[ NX_2 ]

 NX_2(config)# interface overlay 1

 NX_2(config-if-overlay)# otv use-adjacency-server 10.12.1.1 unicast-only

 NX_2(config-if-overlay)# otv join-interface ethernet 1/1

      OTV needs join interfaces to be configured for IGMP version 3

 NX_2(config-if-overlay)# otv extend-vlan 100

 NX_2(config-if-overlay)# no shut

 

  - Multicast 구성과 Unicast 구성은 기본적인 설정은 모두 동일하며, Overay Interface에서 Multcast 통신을 위한 설정 대신에

    Unicast로 Adjacency Server를 구성하기 위한 설정이나, Adjacency Server를 지정하는 설정(Client)을 넣으면 된다.

  - 또한 Multicast를 위해 설정된 IGMP 관련 설정도 모두 제거해도 된다.

 

 

 [Adjacency-Server 상태]

 NX_1# show otv overlay 1

 OTV Overlay Information

 Site Identifier 0001.0001.0001

 Overlay interface Overlay1

  VPN name            : Overlay1

  VPN state           : UP

  Extended vlans      : 100 (Total:1)

 Join interface(s)   : Eth1/1 (10.12.1.1)

  Site vlan           : 111 (up)

  AED-Capable         :  YES

  Capability          : Unicast-Only

  Is Adjacency Server : YES

  Adjacency Server(s) :  [None] / [None]

  - Unicast에서 기본적인 상태 정보는 Multicast와 기능상 동일하기 때문에 동일하며, Overlay Interfac 부분만 확인해보면 된다.

  - Unicast 인 경우에 Capability가 Unicast-only로 표기된다.

  - Adjacency Server로 지정되었지는를 표기하며, Adjacency Server 정보를 등록하였지를 알 수 있다.

    Master의 경우에는 자신만 Adjacency Server이므로, Adajacncy Server정보가 [None] / [None]으로 표기된다.

 

 

[Client 상태]

 NX_2# show otv overlay 1

 OTV Overlay Information

 Site Identifier 0001.0001.0001

 Overlay interface Overlay1

  VPN name            : Overlay1

  VPN state           : UP

  Extended vlans      : 100 (Total:1)

 Join interface(s)   : Eth1/1 (10.12.2.1)

  Site vlan           : 112 (up)

  AED-Capable         :  YES

  Capability          : Unicast-Only

  Is Adjacency Server : No

  Adjacency Server(s) : 10.12.1.1 / [None] 

  - Adjacency Client는 자신이 Adjacency Server가 아니므로, 'No'라고 표기되며 Adjacency Server 정보에 IP가 나온다.

  - 참고로 이 예에에서는 2대만 있지만, 3대 이상에서 OTV Device가 있는 경우에는 "MASTER" "Secondary" "Client"로

    구성할 수 있다.

   : "Secondary" 역할의 OTV Device는 [Is Adjacency Server : YES]로 표기되며 또한 Master 장비의 IP정보도 가지고 있게 된다.

 -  "Client"는 Adjacency Server에 MASTER와 Secondary 장비에 대한 IP 정보만 갖게 된다.

 

☆ Unicast 방식에서 Adjacency Server 설정과 관련한 내용

   • Unicast로 OTV를 할 때에는 Primary Adjacency Server에  "otv adjacency-server" 명령만 이용하면 된다.

     마찬가지로 Secondary Adjacency Server 설정 또한 동일한 명령어로 하면 된다. 

 

  "use-adjacency-server" 명령을 사용하여, 

     Adjacency Server가 아닌 일반 OTV Edge Device들은 Primary 와 Secondary를 모두 지정한다. 

 

  • Adjacency Server 설정 시에, Primary나 Secondary에 대한 역할에 따른 설정 옵션은 없으며, 일반 OTV Edge Device에서

   입력한 Adjacency Server의 IP Address의 순서대로 Primary와 Secondary에 대한 Role이 정해지게 된다.

 

  • 모든 OTV Adjacency Address는 Primary Adjacency Server에서 전달을 하여 모든 OTV Edge Device에 전달되기 때문에

    모든 Client OTV Edge Device는 Primary Adjacency Server를 지정을 해야한다. 

 

  •신규 OTV 사이트가 추가될 경우에도 신규 사이트의 OTV Edge Device에서 Adjacency Server만 지정하게 되면,

  다른 OTV 사이트 에서는 별도의 설정이 추가로 필요없이 OTV Adjacency를 맺을 수 있게 된다.

 

 

 

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

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

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

   List로 대체할 수 있게 한다

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한다.