Today Keys : VPC, AWS, 아마존, Cloud, 클라우드, 서브넷, Subnet, 라우팅, Routing, NAT, Gateway, IGW


이번 포스팅은 예전 포스팅에서 마법사를 통해서 만들었던 VPC를 마법사를 통하지 않고

각 개별 항목 별로 생성해보는 실습 예제입니다. 

마법사를 통한 구성은 편리하지만, 직접 개별 항목으로 생성해 보는 작업을 통하면 실제 VPC의 구성이 어떻게 이뤄지는지

이해하는 데 많은 도움이 되리라 생각됩니다. 

관련 포스팅 : AWS - VPC : Part 3 [VPC 생성 및 테스트:마법사]


이번 포스팅에서 만들게 될 VPC 구성은 다음과 같습니다. 

하나의 VPC 내에 공인 서브넷과 사설 서브넷을 각각 1개씩 구성합니다.

VPC가 외부와 통신하기 위해서 Internet Gateway와 사설 서브넷이 외부와 통신하기 위한 NAT Gateway를

각각 만들고, 라우팅 테이블을 조정 합니다.

 

 

먼저 VPC를 생성합니다

VPC 생성 시에는 VPC에서 사용한 네트워크를 선언하는 데, 초기에 설정한 네트워크(CIDR)은

삭제나 변경이 불가하며, 초기 설정한 대역을 기준으로 추가 CIDR 설정도 영향을 받기 때문에 잘 설계하여 결정해야 합니다.

 

 

 

  생성된 VPC의 정보는 다음과 같이 확인 할 수 있습니다. 

 

  VPC가 만들어졌으며, 이제 VPC 내에서 사용할 서브넷을 생성합니다.

여기에서는 공인 서브넷과 사설 서브넷을 각각 1개씩 생성합니다. 서브넷에서도 네트워크 대역을 정해야 하는 데,

VPC 내의 서브넷의 네트워크 대역은 VPC의 네트워크 내에 포함되어야 합니다.  

 

  본 예제에서는 AZ는 1개로만 구성하였습니다. 

 

  생성된 서브넷 정보는 다음과 같이 확인 할 수 있습니다. 

 

  이제 외부와 통신하기 위한 Internet Gateway를 생성합니다.

 Internet Gateway를 생성 할 때는 별다른 정보없이 Name만 지정합니다. 

 

  생성된 Internet Gateway는 아직 어느 VPC에서 사용될지 결정된 상태가 아니기 때문에 상태 값이 detached 입니다.  

 

  이제 처음에 만들었던 VPC에서 사용하기 위해서 방금 만든 Internet Gateway를 VPC에 연결합니다. 

 

   VPC를 선택해서 Internet Gateway를 연결하고나면,

 

  Internet Gateway의 상태가 attached로 되고, 연결된 VPC의 정보가 뜹니다.  

 

 다음은 라우팅 테이블입니다. VPC 생성 시에 만들어진 라우팅 테이블에는 VPC의 네트워크(CIDR)이 Local로 되어 있으며,

추가적인 라우팅이 없습니다. (Local이기 때문에 VPC 내에서 설정한 서브넷 간에는 통신이 가능합니다.)

 

 

 인터넷을 나가기 위해서 라우팅 테이블의 Default Route(0.0.0.0/0)의 Target(Next Hop)을 앞에서 만들었던

Internet Gateway로 지정합니다.

 

다음은 Elastic IP를 생성합니다.

 

Elastic IP는 바로 할당 버튼을 누르면 별다른 정보 입력없이 다음과 같이 바로 할당이 됩니다.

 

Elastic IP를 만든 것은 사설 서브넷이 인터넷과 통신하기 위한 NAT Gateway를 만들기 위한 것이었습니다.

사설 서브넷이 인터넷과 통신하기 위해서 만들지만, NAT Gateway를 생성할 때 설정하는 서브넷은

사설 서브넷이 아니라, 공인 서브넷으로 설정하고, 방금 전에 할당받은 Elastic IP를 연결합니다.

 

 

실제  서브넷 정보를 보면 공인 서브넷으로 생성한 '~cefe1' 로 끝나는 ID임을 확인할 수 있습니다.

 

이제 사설 서브넷을 위한 라우팅 테이블을 추가로 만듭니다.

서브넷 별로 라우팅 테이블을 적용 할 수 있습니다.

 

라우팅 테이블 생성하고  라우팅 정보를 수정합니다.

사설 서브넷을 위한 라우팅 테이블이기 때문에 Default Route에 대한 Target(Next hop)을 NAT Gateway로 합니다.

 

이제 초기에 만든 사설 서브넷의 기본 라우팅 테이블을을 확인해서

 

 방금 전에 만든 사설 서브넷용 라우팅 테이블로 변경합니다.

서브넷에 대한 라우팅 테이블을 변경하면 해당 라우팅 테이블의 정보를 볼 수 있습니다.

 여기까지하면, VPC 마법사를 통해서 만든 VPC 구성을 직접 만드는 작업이 끝나게 됩니다.

이제 실제 EC2를 생성해서 여기서 만든 공인 서브넷과 사설 서브넷으로 할당해서 각각 외부와 통신이 되는지

사설 서브넷의 EC2의 경우 공인 IP 주소가 NAT Gateway에 할당된 Elastic IP로 보이는지 확인하면 됩니다.

 

앞서 얘기 했듯이 AWS에서 제공되는 VPC를 생성하는 마법사를 이용하면 좀 더 쉽고 빠르게

VPC를 구성 할 수 있지만, 직접 만드는 작업을 통해서 실제 VPC 구성에 대한 이해를 도울 수 있을 것 입니다.

 

그리고 이렇게 만들어진 VPC는 최소한의 통신을 위한 기본 구성이기 때문에 VPC 설계를 위한 다른 컴포넌트들은

추가로 적절하게 생성하여 연결해야 합니다.

 

Posted by 네떡지기

Today Keys : VPC, AWS, Endpoint, Gateway, Interface, services, cloud, 아마존, public


이번 포스팅은 지난 포스팅에 이어서 VPC Endpoint에 대해서 알아봅니다.

VPC Endpoint 중에서 Interface 타입의 Endpoint를 생성해서 어떻게 Endpoint를 이용해서

서비스를 접근 할 수 있는지를 알아 볼 수 있는 간단한 예제 포스팅입니다.

* 관련 포스팅 : VPC Endpoint 알아보기

                        Gateway Endpoint 만들어보기 - 포스팅 준비 중
                       
 


이번 포스팅에서는 Interface 타입의 Endpoint인 CloudFormation을 생성해 보겠습니다.

먼저 Endpoint를 생성하기 위해서 '엔드포인트 생성' 메뉴를 선택하여 Endpoint를 만드는 메뉴로 들어갑니다.

 

EndPoint를 만들 때에는 서비스 유형에 따라서 Interface로 만들지 Gateway로 만들지 다음과 같이 나옵니다.

각 서비스 별로 유형이 정해져 있는 것이며, 서비스를 Interface 혹은 Gateway 유형을 선택하는 것은 아닙니다.

 

Endpoint 생성의 전체 메뉴는 다음과 같습니다.

서비스를 고르고, 어느 VPC에 적용할지를 선택하면 해당 VPC의 AZ 정보가 나오고

각 AZ 별로 어떤 Subnet에 생성할지 나옵니다.

그리고 'Private DNS 이름 활성화' 라는 메뉴가 기본적으로 체크되어 있습니다.

이 부분은 아래에서 다시 설명합니다.

보안 그룹은 우선 기본으로 설정합니다.

 

여기까지하면, 손쉽게 Endpoint를 만들 수 있습니다.

 

생성이후, '사용가능' 상태로는 약 1~2분정도 소요 될 수 있습니다.

정상적으로 생성되면 다음과 같이 생성된 Endpoint 정보를 확인 할 수 있습니다.

 

하단의 서브넷 탭을 보면 실제 생성 시에 선택한 AZ 별로 서브넷에 속하는 IP 주소를 갖고 있는 것을 확인 할 수 있습니다.

 

Endpoint를 생성하기 전에는 해당 VPC 내에서 CloudFormation 서비스에 대한 URL을 확인하면

AWS의 리전 내의 공인 IP 주소를 받아오는 것을 확인 할 수 있습니다.

 

하지만, Endpoint 생성 이후에 동일한 URL에 대한 질의를 하면 Endpoint가 갖고 있는 IP 주소를

도메인에 질의에 대한 결과로 받게 되는 것을 확인 할 수 있습니다.

앞에서  'Private DNS 이름 활성화' 을 뒤에서 알아보겠다고 하였는 데, Endpoint 생성 시에

'Private DNS 이름 활성화' 옵션을 활성화하면(default 값이 활성화) 서비스 별 기본 도메인 값을 VPC 내의 Private DNS에

자동으로 등록이 되어서 해당 값을 응답 받을 수 있게 됩니다.

일반 URL이 아닌 별도 URL을 사용하여 접근하고자 할 경우에는 해당 옵션에 대한 체크를 해제하고

별도 도메인으로 Endpoint IP 주소를 관리 할 수도 있습니다.

 

 

Posted by 네떡지기

Today Keys : VPC, AWS, Endpoint, Gateway, Interface, Private, links, services, cloud, 아마존, public


 

 이번 포스팅은 VPC 네트워크에서 AWS 서비스를 AWS 네트워크를 통해서 직접 접근하기 위한 Endpoint에 대해서 알아보는 포스팅입니다. Endpoint는 접근하는 서비스에 따라서 Gateway와 Interface 타입으로 나뉩니다. 이번 포스팅에서는 Endpoint에 대한 간략한 소개를 하고, 다음 포스팅에서는 Endpoint를 생성해서 접근하는 방법에 대해서 알아 볼 예정입니다.

* 관련 포스팅 : Gateway Endpoint 만들어보기 - 포스팅 준비 중
                       
 Interface Endpoint 만들어보기


 VPC Endpoints

Endpoints

  ▪ VPC 네트워크 내에서 VPC 외부에 위치한 Public한 서비스를 IGW를 거치지 않고 VPC내부에서 직접 접근하도록 지원
  ▪ VPC의 내부의 인스턴스가 AWS 서비스와 통신하기 위해 공인 IP를 가지지 않아도 됨.
  ▪ Endpoint는 Gateway 타입 Interface 타입 으로 구분
  ▪ Endpoint는 VPC에서 접근하고자 하는 AWS Public 서비스 별로 개별 생성하며, Gateway타입 지원하는 서비스와
    인터페이스 타입을 지원하는 서비스가 나누어져 있음. 
       - 타입 별 지원 서비시는 아래에 참고
  ▪ VPC와 AWS 서비스 사이의 트래픽이 AWS 네트워크에서 처리하며, IAM 정책을 사용하여 액세스 제어 가능.


Gateway Endpoint 
  ▪ Endpoint가 Gateway 타입으로 지원하여 AWS 서비스 접근 시, 라우팅으로 접근
  ▪ 라우팅 테이블에서 S3나 DynamoDB의 목적지 네트워크에 대한 Target(Next Hop)으로 Gateway Endpoint를 지정
  ▪ S3와 DynamoDB 접근을 지원


Interface Endpoint
  ▪ Endpoint가 AZ 내의 Elastic Network Interface(ENI)로 생성하고, 해당 서비스에 대한 도메인 Lookup을 해당 ENI 응답
  ▪ Kinesis, Service Catalog, Amazon EC2, EC2 Systems Manager(SSM), Elastic Load Balancing(ELB) API 등을 지원
  ▪ Interface Endpoint 생성 시에는 어느 VPC의 어떤 AZ의 어떤 Subnet을 사용할지 선택
  ▪ Interface Endpoint 는 생성 시에 지정한
 각 서브넷의 IP를 각각 할당 받음.
  ▪ Interface Endpoint 를 이용해서 서비스를 호출하는 경우에는, AWS에서 기본으로 사용하는 도메인을 사용하거나, 
    별도의 서비스 도메인을 지정하여 VPC 내에서 서비스 도메인 Lookup 시에  Interface Endpoint 의  IP로 응답하여
    접근하도록 할 수 있음.
  ▪ 기존에 AWS Public 서비스를 사용하도록 어플리케이션이 만들어진 경우에 기본 도메인으로 Interface Endpoint 
   사용하게 되면  어플리케이션에서 AWS 서비스 호출 시에 별도의 변경 과정없이 Endpoint를 이용한 서비시 호출이 가능.

  

Endpoint 타입별 지원 서비스
  ▪ Gateway
    - Amazon S3
    - DynamoDB
 
  ▪ Interface
    - Amazon API Gateway
    - AWS CloudFormation
    - Amazon CloudWatch
    - Amazon CloudWatch Events
    - Amazon CloudWatch Logs
    - AWS CodeBuild
    - AWS Config
    - Amazon EC2 API
    - Elastic Load Balancing API
    - AWS Key Management Service
    - Amazon Kinesis Data Streams
    - Amazon SageMaker and Amazon SageMaker Runtime
    - Amazon SageMaker Notebook Instance
    - AWS Secrets Manager
    - AWS Security Token Service
    - AWS Service Catalog
    - Amazon SNS
    - AWS Systems Manager
    - Endpoint services hosted by other AWS accounts
    - Supported AWS Marketplace partner services

 

 

 

 

 

Posted by 네떡지기

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


Last Updated : 18.12.14


이번 포스팅은 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를 만들 수 있는 메뉴가 없습니다.

18.12.06 기준 

18.12.14 기준 - 서울 Region에서도 Transit Gateways 사용 가능

 

미국으로 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

 


Last Updated : 18.12.14 

    - 서울 Region에서 사용 가능.


이번 포스팅은 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 네떡지기

Today Keys : AWS, VPC, Route, Table, IGW, Internet, Gateway, EIP, Elastic, IP address, NAT, 네트워크, 아마존



AWS VPC 대시보드를 보면 다음과 같이 VPC에서 사용되는 다양한 컴포넌트가 있습니다.

이번 포스팅에서는 VPC의 다양한 컴포넌트 중에서 라우팅 테이블과 인터넷 게이트웨이, 탄력적 IP, NAT 게이트웨이에 대해서 알아보겠습니다.

Last Updated : 2018.11.30 



 

라우팅 테이블(Route Tables)

 · 특정 네트워크 대역에 대해서 어떤 경로를 통해서 갈지에 대한 테이블 

 · 목적지 네트워크 대역을  '도착(Destination)'으로 표기하고, 목적지로 가기 위한 Next Hop을  '대상(Target)'이라고 나타냄

 · 라우팅 테이블은 서브넷 별로 적용 되기 때문에, 하나의 서브넷은 하나의 라우팅 테이블에만 속함.

 · 서브넷은 하나의 라우팅 테이블에 속하지만, 하나의 라우팅 테이블에는 다수의 서브넷이 속할 수 있음.

 · 라우팅 선언 시에 하나의 목적지 네트워크(Destination)에 대한 라우팅은 1개만 선언 가능하기 때문에 라우팅 테이블 선언으로 백업 경로 지정 불가

 · VPC의 CIDR로 선언한 네트워크 대역은 'Local'로 인식

 

 ·

 

인터넷 게이트웨이(IGW : Internet Gateways)

 · VPC 내부에 존재하는 인스턴스가 외부로 나가기 위한 관문

 · 공인 서브넷이 되기 위해서는 라우팅 테이블에서 Next-hop(Target)이 인터넷 게이트웨이(IGW)인 경우 임.

 · 사설 서브넷 인스턴스의 경우에도 외부와 통신하기 위해서는 NAT 게이트웨이를 통한 이후에 다시 인터넷 게이트웨이를 경유하는 데, 
   NAT 게이트웨이 자체가 공인 서브넷에 존재하기 때문에 결국 공인 서브넷의 라우팅 테이블을 적용 받아서 IGW를 지나기 때문.

 ·

 

탄력적 IP(Elastic IPs)

 · AWS 내에서 할당되는 Static한 공인 IP

 · EIP 생성 시점에는 Public EIP만 할당이 되지만, 해당 EIP를 바인딩하게 되면, 사설 IP와 1:1로  매핑 됨.

 

 

NAT 게이트웨이(NAT Gateways)

 · 사설 IP를 가진 인스턴스가 별도의 공인 IP를 할당받지 않은 상태에서 외부와 통신하기 위해서 사용하는 NAT 컴포넌트

 · NAT 게이트웨이에는 NAT를 Public 서브넷과 실제 NAT되는 EIP를 할당.

 · 특정 서브넷에 대한 NAT 기능을 수행하도록 사설 서브넷과 공인 IP가 매핑된 형태의 컴포넌트로 볼 수 있음.

 · 라우팅 테이블의 Next Hop을 NAT 게이트웨이로 지정하게 되면, NAT 동작을 수행.

 · 최대 1G 대역폭 지원




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

티스토리 툴바