Today Keys : Transit, Gateway, AWS, VPC, 트랜짓, peer, 네트워크, 아마존, TGW, Hub, Spoke


이번 포스팅은 AWS re.Invent 2018에서 소개되었던, Transit Gateway에 대한 소개 포스팅에 이어서,

Transit Gateway를 직접 만들어서 테스트해보는 포스팅입니다.

 

 

※ 관련 포스팅 : Transit Gateway 소개 포스팅 보기


오늘 포스팅에서 구성하는 Transit Gateway에 대한 구성입니다.

2개의 VPC를 구성하고, 2개의 VPC 모두 하나의 AZ에 속합니다.

VPC-1에는 1개의 Subnet이 VPC-2에는 2개의 Subnet이 있으며, Transit Gateway에는 VPC-1과 VPC-2의

각 하나의 Subnet과 연결되어 있습니다.

 

 

그럼 이제 Transit Gateway를 생성하고 사용하는 과정을 알아 보겠습니다.

먼저 Transit Gateway를 만들어 보려고 합니다.

앞서 소개 포스팅에서 얘기했지만, 서울 Region에는 Transit Gateway를 만들 수 있는 메뉴가 없습니다.

 

미국으로 Region을 변경해서 보면, Transit Gateways 메뉴가 보이는 것을 확인할 수 있습니다.

저는 오하이오 Region에서 Transit Gateways를 만들어서 테스트를 진행합니다.

 

현재  생성한 Transit Gateway가 없기 때문에 해당 메뉴에서 [Create Transit Gateway ] 를 선택합니다.

 

다음과 같이 간단한 Name Tag와 옵션들을 선택하고, 바로 생성 가능합니다.

 

생성이 완료되면 다음과 같이 완료 메시지를 확인 할 수 있습니다.

 

완료 메시지 이후에 정상적으로 만들어지기 까지는 수 분이 소요됩니다.

초기에는 다음과 같이 pending 상태가 됩니다.

 

잠시 이후에 State가 available 상태로 되면서 Transit Gateway를 사용 할 수 있습니다.

 

 

Transit Gateway를 생성한 이후에는 연동하고자 하는 정보를 Attatch 해주어야 합니다.

Transit Gateway Attachment 메뉴를 선택해서 들어가면 다음과 같이 Transit Gateway ID에서

방금 전에 생성한 Transit Gateway를 선택 할 수 있습니다.

 

Transit Gateway를 선택하고, 어떤 type으로 attach할 것인지 정하게 되는 데

현재는 VPC와 VPN만 지원하고 있습니다.

Direct Connect 연결은 2019년 초에 지원된다고 합니다.

여기서 유의해서 볼 것은 VPC 연결 시에 특정 VPC 내에서 연결 할 서브넷을 지정할 수 있는 데,

VPC를 만들어 놓은 Region의 AZ 별로 Subnet을 선택 할 수 있습니다.

하나의 AZ에서 Subnet은 드랍박스 형태로 메뉴가 되어 있어서 1개 밖에 선택이 안됩니다. (1개만 가능)

정상적으로 VPC의 Subnet을 Attach하고 나면 다음과 같이 Attach된 내용이 보입니다.

 

동일하게 VPC-2의 서브넷에서도 동일한 과정을 진행하며, Transit Gateway 생성 및 연결이 됩니다.

하지만, 이 상태에서 10.1.1.0/24 Subnet과 10.2.1.0/24의 Subnet이 통신되지는 않습니다.

각각의 Subnet의 라우팅을 추가로 잡아야 합니다.

10.1.1.0/24이 속한 라우팅 테이블에 대해서는 Target(Next hop)을 앞서 만든 Transit Gateway를 선택합니다.

라우팅 테이블 추가 메뉴를 보면 Target 항목에 Transit Gateway를 선택 할 수 있습니다.

양 쪽 서브넷에서 라우팅을 모두 잡고 나면, 이제 정상적으로 두 VPC의 서브넷 간의 통신이 가능합니다.

다만, 라우팅을 10.1.1.0/24이 속한 라우팅 테이블에서 목적지 네트워크를 VPC-2의 CIDR로 설정한 10.2.0.0/16으로

하고 Target을 Transit Gateway로 잡더라도 Subnet 2의 10.2.2.0/24 으로는 통신이 되지 않습니다.

앞선 포스팅과 이번 포스팅 앞에서도 얘기했듯이 1개의 VPC의 1개의 AZ에서는 1개의 서브넷만 연동이 됩니다.

따라서 전체적인 설계를 할 때 이 점을 유의해서 설계해야 할 것입니다.

Posted by 네떡지기

Today Keys : Transit, Gateway, AWS, VPC, 트랜짓, peer, 네트워크, 아마존, TGW, Hub, Spoke

 


이번 포스팅은 AWS re.Invent 2018에서 소개되었던, Transit Gateway에 대한 간단한 포스팅입니다.

기존에 제공하지 않던 VPC 간의 Transit을 가능하도록 제공하는 기능입니다.

Transit를 허용하여 기존에 디자인 하던 방식을 좀 더 관리하기 편하도록 제공할 것입니다.

실제 Transit Gateway를 구성해서 테스트해보는 포스팅은 다음 포스팅을 확인하시면 됩니다.

※ 관련 포스팅 : VPC Transit Gateway 테스트 포스팅-1

 


AWS Transit Gateway (TGW)

Transit Gateway
  ▪ VPC 간의 Transit이 가능하도록 해주는 게이트웨이 서비스
      - 기존에 제공하지 않던 VPC 간의 Trasit이 가능하도록 제공
  ▪ Hub & Spoke 방식으로 Transit Gateway가 다른 VPC들의 Hub가 되어VPC 간을 통신 연계 가능
  ▪ Hub & Spoke 방식으로 연결되기 때문에 각 VPC는 직접 연결하지 않고 Transit Gateway만 연결하여 관리 및 확장 용이
  ▪ Resource Manager를 통해서 Transit Gateway를 타 계정에 공유해서 타 계정의 VPC와도 연동이 가능.
      - Resource Manager를 통해서 관리가 가능한 Resource 유형 중의 하나로 Transit Gateway를 사용
  ▪ On-premise에서 Transit Gateway로의 접근은 현재 VPN 방식만 지원하며, Direct Connect 기능은 2019년초 제공 예정
  ▪ 현재 한국 Region에서는 Transit Gateway 생성 불가

 

 < VPN을 이용하여 On-Premise와 VPC 간을 Transit Gateway로 구성한 예 >


Transit Gateway 특징
  ▪ VPN ECMP 지원
  ▪ 연결당 최대 50Gbps 트래픽 처리 가능
  ▪ 각 게이트웨마다 최대 5000개의 VPC 연결 
  ▪ 1개의 VPC에서는 1개의 AZ에 1개의 Subnet만 Transit Gateway에 연결 가능 
      - 동일 AZ 내에서 추가 Subnet을 Transit Gateway에 Attatch 시도 시에 오류발생

 

  < 동일 VPC의 동일 AZ에 Subnet 추가 연동 시에 에러 >

   

 

 < VPC, AZ, Subnet을 고려한 Transit Gateway 연동 예 >

 

 

Posted by 네떡지기

FabricPath에 대한 5번째 정리입니다.

오늘 정리까지로 보면, 대략적인 부분은 정리가 끝난 듯 싶습니다.

다음 포스팅은 FEX 혹은 그 전에 vPC 구성과 관련한 구성 가능한 디자인과 불가능한 디자인에 대해서 하게 될 듯 싶습니다.

그리고, 네트워크 전문가 따라잡기 카페에 게시글을 올렸던 내용이지만..

현재 정리 중인 Nexus에 대한 내용으로 공부할 수 있는 자리를 2~3회 분량으로... 해보려고 하는데.. 어떻게 될지 잘 모르겠네요.. ^^;

제 머리속에도 한 번 더 정리하는 기회가 될 수 있을 듯 싶고.. 오프라인에서도 함께 나눌 수 있는 자리를 마련해보려고 합니다..

물론 참여하실 분들이 있으셔야 하고.. 저도 정리가 되어야 하겠죠..

그럼 다음 포스팅에서 뵙겠습니다.


 

 

FabricPath – vPC+

• FabricPath networkedge switcheshostFabricPath가 활성화되지 않은 legacy Ethernet switchPort channel을 통해서

  연결할  있는 데, 이를 vPC+라고 한다. , 기존 Ethernet 환경의 Nexus Device가 사용하는 것이 vPC이고, FabricPathEnable

  Nexus  Device 사용하는 것을 vPC+라고 한다.

vPC+가 동작하는 switch는 가상화 된 switch에서 발생한 Packet은 가상화 된 switch(Emulated Switch 라고 함)의 정보,

   switch-id를  Source로 하여서 FabricPath network로 보내진다.

vPC peer switch들은 가상의 FabricPath switch-id공유하며, 이는 vPC Domain에서 관리자가 설정해주어야 한다.

  만약 이 설정이 되어 있지 않을 경우에는 Peer-Link는 정상적으로 살지 않고 vPC+SwitchIDNotCfgd 상태가 되면서 동작하지 않는다.  

   [ FabricpathvPC+에서의 switch-idvPC peer 간의 동일하며, Peer mac 정보는 그대로 유지한다. ]

• vPC+ switch-ID를 설정 시에는 vPC Domain Configuration 모드에서 fabricpath switch-id 명령으로 설정할 수 있다.

FabricPath의 다른 Switch들은 이 Emulated switch의 동작을 별도로 인식하지 않고, FabricPath 내에서 동일하게 접근이 가능한

    Switch로만 인지한다. (switch-id 값으로만 인지)

 vPC+FabricPath가 활성화된 VDCF module이나 Nexus 5500 Series가 필요 하다.

vPC+Peer-linkswitchport modeFabricPath 로 설정해야 한다.

vPC+의 모든 VLAN들은 반드시 FabricPath VLAN이어야 한다.

• vPC+Peer-linkDown될 경우에는 vPC와 유사하게 동작한다.

    * Primary switch는 아무런 동작을 하지 않으며, Secondary switch는 모든 vPC Linkdown된다.

    * 또한, vPC+ 에서는 Secondary switchTraffic이 유입되지 않도록 개입하게 되는 데, 이는 Secondary Switchemulated

      switch에 대한  정보를 FabricPath쪽으로 광고하지 않도록 하기 위해 IS-IS에서 제공되는 기능이다.

      이 기능은 Emulated Switch로 향하는 TrafficSecondary쪽으로 가지 않도록 하기 위한 필수적인 기능이다.

vPC+가 동작중인 FabricPath Edge Switch들은 Mac-address 광고 시, 각자의 switch-id가 아닌 emulated switch-id로 광고된다.,

 이는 vPC+와 연결된  Orphan port의 단말기도 마찬가지이며, 이로 인해 Orphan port 단말의 경우에는 Peer-link를 통해서 통신을

 할 수도 있게 된다. (기존 vPC의 경우에는 Orphan port의 단말의 경우에는 vPC Peer DeviceLocal Mac을 사용)

 

 

◈ vPC+ 구성 설정

    - vPC+ 에 대한 간략한 구성을 통해서 설정방법을 다음과 같이 알아보겠습니다.

    - 본 예제서는 N7K2의 대부분의 설정은 생략하지만, N7K1과 거의 동일하기 때문에 이해하는 데 큰 문제는 없습니다.

 

.

 

1. fabricpath로 동작할 vlan에 대해서 mode을 fabricpath로 변경하고, fabric-switch를 지정해준다.

    그리고 일반적인 vpc를 구성한다. 

 

2. 현재 Keep-alive만 구성하였기 떄문에 peer keep-alive만 alive 상태가 됨을 확인할 수 있다.   

 

3. vPC+ 동작을 위해서, vPC 도메인에 fabricpath switch-id를 지정한다.

    이 때에 vPC Peer간에는 반드시 동일한 fabricpath switch-id를 지정해 주어야 한다.

    fabricpath switch-id를 설정한 이후에 vPC정보를 보면, 기존의 vPC정보에서 vPC+에 대한 정보도 확인할 수 있다.

 

4. vPC간의 peer-link를 구성한다. 이 때에 peer-link의 mode  또한 fabricpath로 변경해주어야 한다.

 

5. vPC+를 위한 peer-link 설정 이후에 vPC 정보를 보면, vPC fabricpath statue가 fabricpath를 통해서 맺어진게 확인된다.

 

6. vPC+에서 설정한 switch-ID 정보도 한 번 살펴보면, 아래와 같이 70이라는 가상의 switch-id가 각각의 peer의 System-ID값으로

    동일하게 설정된 것을 볼 수 있다. 그리고 이 switch-id는 가상으로 설정된 것이기 때문에  Emulated가 Yes로 보인다.

 

 

 

7. 이번엔 vPC를 통해서 연결된 하단의 interface 설정을 한다. vPC+와 연결되는 장비는 fabricpath mode는 아니다.

    하단의 장비는 일반 Port-channel 설정을 그대로 하면 된다.

 

8. 모든 설정 이후에 vPC의 정보를 아래와 같이 모두 정상적으로 올라온 것을 볼 수 있다.

 

 

※ 만약 Peer간의 가상의 switch-id를 서로 동일하게 설정하지 않으면, 아래와 같이 vPC 구성이 되지 않음을 확인 할 수 있다.

 

 

 

 

Posted by 네떡지기

올 한해도 벌써 다 지나가고 있네요. 날씨도 엄청나게 춥구요..

Nexus 정리 16번째 입니다.  두서없이 정리하느라 순서도 잘 없고.. 원래 말쯤에는 pdf로 쭈~욱 정리를 해보고 싶었지만..

그렇게 부지런하게 살지도 못하고 있네요. 내년 이른 전반기쯤에는.. 그래도 간략하게나마 정리본을 만들 수 있지 않을까?

라는 생각을 해봅니다.  내용 중에 수정 및 보완해야할 점 있으면 알려주세요! ^^

 

 


 

 

vPC Roles

• vPC System에서 Priority 값에 의해서 Primary, Secondary 로 나뉜다. (낮은 값의 Priority 값이 우선순위가 높다)

• vPC Roles을 결정하는 Priority 값에 따라서 Roles을 즉시 가져오지는 않기 때문에(nonpreemptive), 현재 Primary로 동작하는

  경우에도 설정값으로는 Secondary일 수도 있다.

   ※ Spanning TreePreemptive하기 때문에, Spanning Tree RootvPC Operational Primary Device가 불일치 할 수 있다.

vPC System들이 vPC Domain에 소속될 때,  Priority에 의해서 PrimarySecondary를 결정한다.

• Primary DeviveReload하게 되면, Sercondary DevicePrimary로 동작(Operational primary) 을 하게되며, 기존의 Primary

  Device 다시 Online되어서 연결이 되더라도, OperationalRole은 변하지 않고 Primary DeviceSecondary로 동작

  (Operational  Secondary)한다.

  이와 같은 동작은 sticky bit 방법으로 되는데, sticky 정보는 startup configuration에 저장되지 않기 때문에 , Up상태로 동작 중

 인  장비가 reloaded된 장비보다 Primary로 운영되도록 한다.  따라서, vPC PrimaryvPC operational secondary 상태가 된다.

만약, Peer link가 끊기더라도 vPC Peer들은 vPC peer keepalive link를 통해 연결되어 있기 때문에 vPC Operational roles이 변

 하지 않지만,  peer linkpeer keepalive link가 모두 끊기게 되면, 두 대의 vPC Peer 모두 Operational Primary가 된다.

  그러나 peer-keepalive linkpeer link가 다시 연결되면,  vPC secondary deviceOperational Primary 상태로 Primary Role

 유지하고,  vPC PrimaryOperational Secondary Device로 된다. 

   왜냐하면 Peer 장비가 Reload되지 않고 Up상태로 유지되고 있었기 때문에 Sticky에 의해서 Primary장비가 이전의 Operational

 Secondary 상태로 다시 돌아가려고 하기  때문이다.

 • Primary DeviceOperational Secondary로 동작 중일 때에, Operational Primary로 변경하려면, Operational Primary로 동작

  중인 Secondary  Device Reload 하면 된다.

 

※ 참고하세요!

 -  Sticky bit (운영체제 개념)

    예전 Unix에서 제한된 메모리 사용을 위해서 main memorysecondary memory의 내용을 /dev/swap 하는 경우가 있었는

   데이는 속도저하를 발생시켜서 자주사용되는 program들은 Sticky bit를 설정해서 swap되지 않고 memory에 유지되도록 함.

 

  

 

 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

 

 

 

 

 

 

Posted by 네떡지기

지난 번에 포스팅했던 vPC에서의 HSRP의 연장선상의 내용인 Peer-gateway에 대한 부분입니다.

문의사항이나, 잘못된 부분이 있으면 댓글 부탁드립니다 .^^

 


vPC Peer-gateway

일부 Third-Party 단말기는 HSRP의 가상 Mac-Address를 무시하고, HSRP RouterSource Mac-Address를 사용한다 vPC 환경에서 HSRP RouterPeer-link를 통해 Source Mac-Address가 전달되기 때문에, 위와 같은 비정상적인 ARP동작은 Loop Prevention에 의해 잠재적이 패킷 유실 가능하게 한다.

 

 

 

 

 

vPC Peer-gateway를 설정하면, vPC Peer 간의 BIA(Burned-In-Address)정보를 G flag(Gateway flag)와 함께 복사하여  Peer-link거치지 않고 트래픽 전송을 가능하게 해준다.  (Loop Prevention에 의한 패킷 유실 방지) 

 

vPC Peer-gateway 설정은 항상 활성화하는 것을 권고한다. 표준 ARP Request를 수행하지 않는 장비가 연결되지 않아서 해당 기능이 반드시 필요하지 않아도 vPC DomainPeer-gateway 설정을 해두는 것이 좋다. (활성화에 따른 문제점 없음)

 

• Traffic 기능적으로 기존에 영향을 미치지 않는다.

 

• ICMP redirects는 비활성화 된다 .

 

• Peer-gateway 설정 및 활성화 상태 확인

 

 

 • Peer-gateway 설정에 따른 Mac-Address Table 비교

 

 

Posted by 네떡지기

티스토리 툴바