'Unicast'에 해당되는 글 2건

  1. 2014.10.10 Nexus : NX-OS Part35(OTV 8 - Failure Isolation)
  2. 2014.09.29 Nexus : NX-OS Part33(OTV 6 - DataPlane)

 

 


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

티스토리 툴바