'isolation'에 해당되는 글 2건

  1. 2014.10.10 Nexus : NX-OS Part35(OTV 8 - Failure Isolation)
  2. 2014.10.07 Nexus : NX-OS Part34(OTV 7 - FHRP Isolation)

 

 


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

티스토리 툴바