JamesMoon Tech Note

BGP를 이용한 multihomed 환경에서 두 ISP와 연결시 Redundancy 설정

as-path 와 hsrp 사용하여 구성

< 시나리오 >

outbound traffic :
모든 192.168.21.0/24 를 소스로 하는 outbound traffic는 인터넷
접속시 R1에서 ISP-A 경로를 사용  그러나 R1 장애시 모든 트레픽은 R2 에서
ISP-B의 경로를 특별한 config 없이 사용
inbound traffic :
모든 inbound traffic는 R1을 통해 들어온다.

만약 ISP-A에서 R1의 경로 장애시 inbound traffic는 ISP-B 에서 R2경로를 사용

시나리오 redundancy 구성

1.

HSRP를 이용하여 outbound traffic을 fully redundant path 구성, 전형적으로 PC는 라우팅 정보를 선택 교환하지 못한다.

default gateway의 ip address 는 스테틱 하게 설정되어있다.

만약 gateway 가 장애가 발생하면 PC는 alternate gateway가 존재할지라도 경로정보를 잃는다. hsrp는 이런 일련의 요구사항을 충족시켜준다.


2.

BGP as-path를 이용하여 inbound traffic에 대해 경로보장이 가능하다. as-path를 이용하여 192.168.21.0 /24 네트웤에 대한 path정보를 R2-ISPB의 경로보다 R1-ISPB의 경로를 우선하여 사용할수 있다.

외부에서는 R2-ISPB의 경로보다 R1-ISPA의 경로를 192.168.21.0/24 에 대한 BEST 경로로 선택한다.

AS100 이 광고할때 R2-ISPB 의 경로 정보에 as-prepend를 사용하여 AS 정보를 한번 더 append 한다.

[설정]

R1 :
int s0
ip add 192.168.31.1 255.255.255.0
int e1
ip address 192.168.21.1 255.255.255.0
standby 1 priority 105 (R1은 HSRP MASTER 라우터 : priority 가 높은것이 우선)
standby 1 preempt (장애 복구시 다시 원상태로 복구)
standby 1 ip 192.168.21.10 (HSRP VIP를 192.168.21.10으로)
standby 1 track serial 0 (serial 0 장애시 standby 작동)


route bgp 100
no synchronization (IBGP 사이에 IGP가 동작안할경우 no syn)
network 192.168.21.0 (192.168.21.0 을 광고)
neighbor 192.168.21.2 remote-as 100
neighbor 192.168.21.2 next-hop-self (IBGP를 통한 외부 exit 정보 획득 하지만 EBGP가 우선)
neighbor 192.168.31.3 remote-as 300
no auto-summary

R2 :
int s0
ip add 192.168.42.2 255.255.255.0
int 21
ip add 192.168.21.2 255.255.255.0
standby 1 priority 100 (HSRP slave)
standby 1 preempt
standby 1 ip 192.168.21.10


router bgp 100
no synchronization
network 192.168.21.0
neighbor 192.168.21.1 remote-as 100
neighbor 192.168.21.1 next-hop-self
neighbor 192.168.42.4 remote-as 400
neighbor 192.168.42.4 route-map foo out
(neighbor 192.168.42.4 로 경로정보업데이트시 foo 적용)
no auto-summary


access-list 1 permit 192.168.21.0
route-map foo permit 10
match ip address 1 (경로정보가 access-list 1 과 매칭되면)
set as-path prepend 100
(정보에 자신의 AS 번호를 한번더 append하여 외부입장에서
R1보다 R2의 경로가 멀게 보이게한다.)

개요
생성된 Windows 인스턴스로 접속하는 방법에 대해 알아봅니다. 더 나아가 키 파일(*.pem)없이 언제 어디서나 접속할 수 있도록 설정하는 방법도 소개합니다.

Windows에서 원격 접속
Windows는 Windows로의 원격 제어에 필요한 원격 데스크톱 클라이언트를 기본적으로 내장하고 있습니다. Remote Desktop Protocol의 표준 포트는 3389 입니다. 시작에서 원격 데스크톱 연결(이하 RDP)이라고 검색한 후 클라이언트를 실행합니다. 또는 실행[Windows R]에서 mstsc(Microsoft Terminal Services Client)라고 입력해도 됩니다.


Mac에서 원격 접속
Mac App Store에서 Microsoft Remote Desktop 앱을 설치할 수 있습니다.

Android에서 원격 접속
Google Play에서 Microsoft Remote Desktop 앱을 설치할 수 있습니다.

iOS에서 원격 접속
Apple App Store에서 Microsoft Remote Desktop 앱을 설치할 수 있습니다.

클라이언트에 대한 자세한 정보
각 운영체제 별 원격 데스크톱 클라이언트 앱에 대한 자세한 정보는 Microsoft 기술문서를 참조하십시오.

접속 비밀번호 가져오기
접속할 준비가 완료된 EC2 인스턴스를 선택하고 연결 버튼을 누르면 인스턴스에 연결할 수 있는 절차가 소개됩니다. 암호 가져오기를 클릭합니다.

키 페어 생성 화면에서 생성한 *.PEM 파일을 찾아서 암호를 해독합니다.

해당 인스턴스에 대한 접속 도메인과 계정 사용자 계정명, 암호가 나타납니다. 각각 복사하여 RDP에 입력해줍니다.

퍼블릭 DNS 주소 대신 IP 주소를 입력해도 됩니다.

키 페어(*.PEM) 파일 없이 접속하기

매번 암호 키를 해독하기 위해 PEM 파일을 갖고 다니는 것은 불편합니다. 그래서 인스턴스 내 Windows에서 Administrator에 대한 암호를 변경하겠습니다. 필수 절차는 아니므로 서버 접속 절차를 상황에 맞게 잘 판단해 구성해주세요.

이 세상에 100% 완벽한 보안은 없습니다. 기존 키 페어 방식을 계속 사용하더라도 항상 파일 관리를 조심히 해야 합니다. 또한 복잡한 비밀번호를 지정하기 어렵거나 기억하기 힘들다면 자신만의 온라인 스토리지나 비밀 공간에 해당 비밀번호를 메모해 두거나, 또는 Administrator의 암호를 변경하지 말고 기존의 키 페어 방식을 계속 사용할 것을 권장합니다.
실행에서 lusrmgr.msc(local user manager)를 입력합니다. Users에서 Administrator 계정을 오른쪽 마우스 클릭하여 Set Password...를 클릭합니다. 새 암호를 지정합니다.

AWS에서 기본적으로 키 페어 파일을 통해 암호를 복호화하는 과정을 거치는 옵션을 제공하는 이유는 서버 접속에 대한 강력한 암호를 적용하여 서버 해킹에 대한 난이도를 최대한 높이기 위해서 입니다. 다시 말해 서버 관리자의 평소 보안 습관 또한 아주 중요합니다. 기존에 사용하고 있는 암호를 그대로 서버 암호로 사용하지 마십시오.
Administrator 계정은 Windows에서 기본적으로 제공하며, 운영체제 전반에 걸쳐 최고 권한을 가진 관리자 계정입니다.
보안은 항상 편의성에 반비례합니다. 서버 해킹 피해에 대한 책임은 오직 본인에게 있습니다.

만약 새 암호를 잊어버리면 PEM 파일이 있든 없든 영영 해당 서버로 접속할 수 없습니다.

VPC Flow log란?

VPC Flow log는 VPC위에 생성된 네트워크 인터페이스에서 송수신되는 IP 트래픽 로그를 수집할 수 있는 기능입니다. AWS에서 네트워크 인터페이스를 ENI(Elastic Network Interface)라고 하는데, 대표적으로 EC2와 RDS, ELB에 ENI가 할당이되며 VPC endpoint, RDS, Elasticache 등에도 ENI가 할당이 됩니다.

ENI(Elastic Network Interface) 확인 하기

ENI는 EC2를 선택하고 왼쪽 카테고리 Netwrok Interfaces 에서 현재 생성되어있는 모든 ENI를 확인이 가능합니다. ENI는 사용자가 직접 생성하지 않아도 자동으로 생성되는 리소스들이 있기 때문에 사용자가 모르게 생성되어있는 것들이 있을 수 있습니다. (대표적인게 ELB, VPC Endpoint 같은 것들이 있죠)

VPC Flow Log를 통해 확인할 수 있는 29가지 정보

VPC Flow log를 통해 확인이 가능한 정보는 29가지가 있습니다. 각각의 파라미터에 대한 상세 설명은 AWS 문서에 아주 잘 설명이 되어있으므로 생략하겠습니다. (https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)

• version
• account-id
• interface-id
• srcaddr
• dstaddr
• srcport
• dstport
• protocol
• packets
• bytes
• start
• end
• action
• log-status
• vpc-id
• subnet-id
• instance-id
• tcp-flags
• type
• pkt-srcaddr
• pkt-dstaddr
• region
• az-id
• sublocation-type
• sublocation-id
• pkt-src-aws-service
• pkt-dst-aws-service
• flow-direction
• traffic-path

그 중 가장 중요하다고 생각되는 한가지 파라미터인 tcp-flags를 언급하자면 TCP가 핸드쉐이킹 하는 단계를 확인할 수 있는데, 각 단계에 대한 flag 값을 다음과 같습니다.

SYN: 2
ACK 16
SYN-ACK: 18
FIN: 1
SYN-ACK + FIN : 19
RST: 4

VPC Flow 생성 방법

AWS관리 콘솔에서 VPC를 검색하면 왼쪽 카테고리에 “your VPCs” 가 있습니다.

생성하고자 하는 VPC를 선택하면 하단에 Flow logs 탭이 있고 Create flow log를 선택하여 생성할 수 있습니다.

하지만 역시 AWS가 호락호락 하지 않죠. AWS리소스를 생성할때 항상 막히는 부분이 IAM Role인데요. vpc flow log가 필요한 권한이 들어간 IAM Role을 생성해 주어야합니다. (예전에는 자동으로 만들어줬는데 바뀌었네요)

AWS관리 콘솔에서 IAM을 선택하여 Role을 적절한 이름으로 아래 권한을 추가하여 생성합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "logs:DescribeLogGroups",
                "logs:DescribeLogStreams"
            ],
            "Resource": "*"
        }
    ]
}

생성한 IAM Role로 VPC Flow log를 생성하면 됩니다만 여기서 선택해야할 것이 또 2가지가 있습니다.

첫째, VPC flow log를 저장하는 위치

VPC flow log는 S3 또는 Cloudwatch logs에 저장할 수 있습니다. 비용적인 측면으로 보면 s3가 더 저렴하지만 로그 파일 형태로 일일히 다운로드 받아야하며 원하는 데이터를 필터링하기가 어렵습니다.
Cloudwatch logs를 사용하게되면 AWS관리 콘솔에서 대시보드 형태로 제공이되며 필터를 걸어서 검색하기도 수월하고, 데이터 보관주기도 쉽게 설정할 수 있습니다.

둘째, VPC flow log 포맷

위에서 설명드린바와 같이 VPC flow log로 확인할 수 있는 정보는 총 29개 정보 입니다. 하지만 default 설정으로 아래와 같이 14가지가 설정이 되어있습니다.

default 포맷으로 위 14가지를 확인할 것인지, 필요한 것만 커스텀 할 것인지를 선택할 수 있습니다. AWS에서 제시해준 커스텀 포맷은 15가지 조합 이며 아래와 같습니다. (개인적으로 default 포맷에 ${flow-direction} 가 없는게 이상하네요)

${account-id} ${instance-id} ${interface-id} ${flow-direction} ${srcaddr} ${dstaddr} ${pkt-srcaddr} ${pkt-dstaddr} ${srcport} ${dstport} ${protocol} ${tcp-flags} ${packets} ${bytes} ${action}

커스텀 VPC Flow log 확인

만약 VPC Flow log를 s3에 저장하겠다고 선택하였으면, 설정한 s3위치에서 확인할 수 있으며 Cloudwatch logs 를 선택하였다면 아래와 같이 Cloudwatch log groups에서 확인이 가능합니다. 또한 저장 주기를 설정할 수 있는데요 default가 Never expire 이기 때문에 요금 폭탄을 맞을 수 있으므로 반드시 저장 주기를 설정하는 것을 권장드립니다.

위에서 AWS에서 제시해준 15가지 조합으로 로그를 받아보면 아래와 같습니다.

● vPC (Virtual Port-Channel) Consistency check란?

시스템을 체크하여 peer 장비간의 설정이 다르거나 누락된 부분을 검증하여 호환성을 맞추는 과정을 vPC consistency check라고 합니다.  

​vPC 도메인을 구성하는 2대의 peer 장비는 control plane을 서로 가지고 있기 때문에 상호간 정보 동기화가 필요로 합니다. 상태 정보 동기화는 cfs 프로토콜을 이용하여 peer 장비간의 상태 동기화 (MAC 주소 테이블, IGMP 정보, vPC 상태, 기타 등등)를 수행 합니다.  

​
● vPC (Virtual Port-Channel) Consistency Types

vPC Consistency Type은 반드시 일치해야 하는 Type 1과 일치하지 않아도 동작은 되는 Type 2로 분류 됩니다. 설정 부분 체크는 global 설정과 인터페이스 설정으로 다시 세분화 됩니다.

  ○ Consistency Type 1 Global (반드시 일치해야 하는 항목) 

스위치의 전역(global) 설정 부분, 해당 영역의 설정이 다를 경우 vPC Role Secondary 장비의 vPC는 down 상태가 됩니다. 

○ Consistency Type 1 Interface (반드시 일치해야 하는 항목) 

스위치의 인터페이스 (per-interface) 설정 부분이며 해당 영역의 설정이 다를 경우 연계되어 있는 vPC만 사용 불가상태가 됩니다.

interface consistency parameters에서 Allowed VLANs 제외한 나머지가 Type 1 일관성 체크 항목들 입니다.  Trunk Interface에서 Allowed VLAN은 Type 2 일관성 체크 항목입니다. Allowed VLAN의 범위가 서로 다를 경우 남겨진 VLAN 정보는 해당 Port-Channel을 사용할 수 없습니다. 

  ○ Consistency Type 2 (일치를 권장) 

스위치의 전역(global) 설정 및 인터페이스 설정 부분에서 Type 2 항목에 불일치가 발생하면 SYSLOG 메시지를 발생 시킵니다. vPC 상태는 Running상태로 사용은 가능하지만 Sub-Optimal한 경로로 트래픽이 전달 될 수 있습니다. 

VLAN Database는 vPC를 구성하는 Peer 장비가 동일한 VLAN정보를 가지고 있어야 합니다. Peer 장비 하나에서 문제가 발생할 경우 Peer 장비 모두에게 영향을 주게 됩니다. 이를 Per-VLAN consistency check 라고 합니다. 

● vPC (Virtual Port-Channel) graceful consistency check

• Graceful Consistency Check가 활성화 되어 있을 경우에 Type 1 항목에서 불일치가 발생하면 Secondary 장비에서만 중지(suspend)가 발생하고 Primary 장비는 Running 상태가 됩니다. 
• Graceful Consistency Check가 비활성화 되어 있을 경우에 Type 1 항목에서 불일치가 발생하면 Primary / Secondary의 vPC에 설정 된 VLAN이 모두 중지(suspend) 상태가 됩니다. 

최신 NX-OS에서 graceful consistency check는 기본적으로 활성화 되어 있으며 해당 기능은 명령어를 통해 활성화 및 비활성화를 시킬 수 있습니다. 

#vPC 도메인 접근
switch(config)# vpc domain 10

# no를 붙일 경우 기능 비활성화
switch(config-vpc-domain)# [no] graceful consistency-check

Graceful consistency check 기능을 활성화 이후 Global 레벨에서 Type-1 (STP Mode Missmatch)가 발생하면 Primary의 상태는 Up으로 사용 가능하지만 Secondary의 상태는 Down으로 나타납니다. 

Interface-level 에서 Type-1 Missmatch가 발생하게 되면 Secondary 장비에서만 Down이 발생하고 Primary 장비는 Up 상태 입니다. 

● vPC (Virtual Port-Channel) Consistency Check 명령어

• show vpc
  - vPC 상태와 Global and Interface-level의 vPC consistency check 결과를 확인할 수 있습니다. check에 실패한다면 실패 이유도 확인 할 수 있습니다.
  
  
• show vpc consistency-parameters global
  - vPC Peer Switch에서 Global Type-1에 해당하는 설정의 차이점을 확인 할 수 있습니다.  
  
  
• show vpc consistency-parameters interface ethernet/port-channel [slot/port]
  - 특정 인터페이스 또는 포트채널에서 발생한 불일치 항목을 확인 할 수 있습니다.

참고 URL

 -  https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/operations/n5k_vpc_ops.html#61453

● vPC Terminology  (vPC 용어 안내)

● vPC Role  (feat. vPC Operation Role) 필요성, 역할 그리고 용어의 정의

● vPC Role 특징 

  ○ vPC Non-Preemptive

장애 발생 이후 Role 변경에 따른 패킷 유실을 방지하기 위해 Role은 변경되지 않고 Operation Role만 변경 됨.

● vPC (Virtual Port-Channel)

vPC는 물리적인 2대의 장비를 묶어 논리적으로 하나의 장비처럼 동작하게 하는 시스코 전용 기술이며 오직 넥서스에서만 vPC를 사용할 수 있습니다. vPC는 Cisco 장비 사이의 연결 및 종단장비(서버, PC)가 Link Aggregation Control Protocol (LACP, IEEE 802.3ad)를 지원하는 경우 Active / Active로 구성하여 Link를 모두 사용할 수 있습니다. 

  ○ vPC (Virtual Port-Channel) 특징

  ○ vPC (Virtual Port-Channel) Traffic Flow

vPC 설정이 정상적이고 최적화 되어 있을 경우 Core Switch to End Device & End Device to Core Switch의 트래픽 흐름은 대칭적으로 전달 됩니다. 

Aggregation Layer에서 vPC를 구성하면 Core 스위치와 Access 스위치는 표준 프로토콜 LACP를 사용하면 전체 대역폭을 사용할 수 있습니다. 

트래픽의 흐름이 Core Switch → Server 또는 Server → Core Switch 발생하면 스위치의 EtherChannel Load-Balancing 설정에 따라 Egress Interface가 결정되고  vPC 스위치에서 목적지에 해당하는 장비까지 트래픽을 전달 합니다. 

● Etherchannel 운영모드

이더채널을 구성하는 방법은 정적 모드와 동적 모드 2가지가 있으며 동적 모드를 구현하기 위한 프로토콜에도 PAgP와 LaCP 2가지가 있습니다. 일반적인 스위치 사이 사용에는 정적 모드를 많이 사용하며, vPC를 사용하는 환경 또는 이더채널 구성 중간에 전용회선 또는 패치로 구성이 되어 있다면 동적 모드를 사용해야 합니다. 

그림1. 전용회선 구간 장애

그림1과 같은 장애가 발생할 경우 정적 모드에서는 장애를 감지하지 못해 이더채널의 상태는 up/up 상태를 유지하고 트래픽 유실이 발생 하게 됩니다. ​ 

동적 이더채널을 구성하기 위해서는 양측이 사용하는 프로토콜이 동일해야 하며 각 프로토콜이 제공하는 모드별 특성 이해가 필요합니다.

이더채널을 구성을 위한 동작 모드

● Etherchannel 구성 방법

이더채널의 설정은 인터페이스 모드에서 수행하며 식별을 위해서 이더채널 ID를 같이 입력해 주어야 합니다. 

PAgP는 auto | desirable 이라는 모드의 하위 모드로 silent | non-silent 모드가 존재하며 기본적으로 silent 모드로 동작합니다. PAgP non-silent 모드로 설정하면 조금 더 빠르게 이더채널 수립이 가능합니다. 스위치 포트의 L2 / L3 동작 모드의 설정은 이더채널 인터페이스에 설정을 해주면 됩니다. 

● Etherchannel 기술의 정의

물리적인 인터페이스를 논리적인 인터페이스 하나로 묶어서 사용하는 기술 입니다. Etherchannel은 IEEE 802.3AD로 정의되어 있습니다. 표준 용어는 이더채널이고 시스코에서는 포트채널로 해당 기술을 부릅니다.

● Etherchannel 특징

  1) Spanning-Tree는 이더채널에만 적용되고 이더채널에 소속된 멤버 포트는 영향을 받지 않음

     - STP는 이더채널의 Path Cost값은 소속된 물리 포트의 수량과 연관성 존재 함

  2) 이더채널을 통해서는 반드시 동일한 BPDU를 수신 해야 함

    - 이더채널을 통해 받는 BPDU값이 다를 경우 Err-Disable 상태로 빠짐 (MLAG 환경에서 장애가 발생 할 수 있음)

  3) Etherchannel의 운영모드 Layer 2(switchport)와 Layer 3(no switchport) 로 운영 가능

    - 운영모드가 한번 정해지면 변경 할 수 없으며, 변경을 원할 경우 이더채널 설정을 삭제 후 다시 생성해야 함

    - Layer 2 ↔ Layer 3 를 혼합하여 사용 할 수 있으나 권장하지 않음. (Not Best Practice)

  4) 이더채널 사용 시 트래픽 부하분산이 가능 함

    - Layer2 (MAC 주소) / Layer 3(IP 주소) / Layer 4 (Port 번호)를 사용하여 이더채널 부하분산이 가능

    - 단일 트래픽은 이더채널의 부하분산 효과를 사용 할 수 없음. 해쉬 함수를 통해 정해진 포트를 사용

    - 부하분산 방법은 플랫폼과 운영체제 버전에 따라 다르게 제공 됨

  5) 이더채널의 최소/최대 수량

    - IOS 버전에 따라 이더채널을 구성하는 최소 물리 링크 수량을 지정할 수 있음

    - 이더채널을 구성하는 최대 수량은 8개, 8개 이상 묶는 것보다 상위 등급의 케이블을 사용하는 것이 효율적이다.

  6) 이더채널의 속도와 대역폭

    - 속도와 대역폭은 이더채널을 구성하고 있는 멤버 포트의 누적값으로 계산 됨

● Etherchannel 트래픽 분배 비율

이더채널을 구성하는 수량은 8개 이하면 어떤 수량을 사용하든 상관없지만, 이상적인 구성 수량은 2개, 4개, 8개로 이더채널을 묶어 동일한 비율로 트래픽을 분배하는 것입니다

● Etherchannel 구성 시 지켜야 할 사항 

아래 항목들은 정상적인 이더채널을 구성하기 위해서 반드시 지켜야 할 항목 입니다.

  1) 멤버 포트의 Speed와 Duplex 동일해야 함

  2) 멤버 포트의 운영모드가 같아야 함 (Trunk, Access, Dynamic)

  3) 트렁크 모드가 아닐 경우 Access VLAN이 같아야 함

  4) 트렁크 모드일 경우 trunk type, allowed VLAN, native VLAN이 같아야 함

  5) 멤버 포트들은 모든 VLAN의 Path Cost값이 동일해야 함 
    - 명령어를 통해 특정 VLAN에 대해서 Path Cost값을 변경하면 이더채널 구성 불가능

  6) SPAN 포트는 이더채널을 구성 할 수 없음

● DTP (Dynamic Trunking Protocol)

Trunking 구성 시 패킷을 통해 자동으로 협상하여 Trunking을 구성하는 기술 입니다. DTP는 시스코 독점 기술이며 Trunk 구성 시 동적으로 구성하는 방법을 제공 합니다.

  ○ DTP (Dynamic Trunking Protocol) 운영 모드

Auto / Auto를 제외한 모든 운영모드에서 동적으로 Trunk Port를 구성 할 수 있습니다

DTP 메시지를 보내지 않을려면 switchport nonegotiate 명령어를 인터페이스에 입력해 주어야 하며, Trunk를 구성하기 위해서는 Trunk를 정적으로 설정해 주어야 합니다.

 ● VTP (VLAN Trunking Protocol)

VTP는 VLAN Provisioning의 부담을 줄여주는 기술 입니다. 동일한 VTP Domain에 속해 있을 경우 해당 도메인의 VTP Server가 VLAN 생성 시 VTP Client 스위치에게 전파하는 기술을 의미 합니다. 

  ○ VTP (VLAN Trunking Protocol)의 4가지 역할

  ○ VTP (VLAN Trunking Protocol)의 통신 유형

VTP 광고는 멀티캐스트 주소를 통해 동일한 VTP 도메인에 속한 스위치에게 전달 되며, 전달되는 광고의 유형은 3가지가 있습니다.

● Spanning-Tree Tuning - UDLD (Undirectional Link Detection)

UDLD는 광케이블의 양방향 모니터링을 수행하는 기술이며, UDLD 패킷에 포함되는 정보는 송신 장비의 SYSTEM ID와 UDLD를 전송하는 포트의 Port ID가 포함됩니다. 

UDLD는 시스코 전용 프로토콜이고 다른 벤더의 제품들은 단방향 링크 단절을 감지하기 위해서 BFD를 사용 합니다.

  ○ Spanning-Tree Tuning - UDLD 동작 방식

UDLD 패킷을 상대편 장비에게 보내고 이를 수신한 장비가 자신의 정보로 UDLD 패킷을 생성하여 다시 돌려주는 방식으로 송신/수신의 정상 여부를 확인합니다.  UDLD가 동작하는 방식은 2가지가 있습니다. 

  ○ Spanning-Tree Tuning - UDLD 적용 방법과 명령어

UDLD의 적용은 1) 스위치 전체에 활성화 하는 방법과 2) 특정 인터페이스에서 활성화 시키는 방법 2가지가 존재하며, UDLD가 정상적으로 동작하기 위해 이웃 장비에서도 UDLD가 동일하게 적용이 되어야 합니다.  

  1) 스위치 전역 설정 명령어
전역 설정 후 UDLD가 필요없는 포트의 경우 수동으로 비활성화가 필요 합니다.

# 스위치 전역 설정
Switch(config)# udld enable [aggressive]

# UDLD 비활성화 명령어 
Switch(config-if)# udld port disable

  2) 스위치 포트 설정 명령어

# 스위치 포트 설정
Switch(config)# udld port [aggressive]

  3) UDLD 설정 확인 명령어

# UDLD Neighbor 확인 명령어
Switch# show udld neighbor

# UDLD 인터페이스 설정 확인 명령어
Switch# show udld [interface number]

● Spanning-Tree Tuning - Loop Guard

기존 Root Port 또는 Alternated Port에서 BPDU를 수신하지 못할 경우 AP(Alternated Port) or RP (Root Port)상태에서 DP(Designated Port, 데이터 전송) 상태로 변경 되는 것을 방지하는 기술 입니다. 

Root Port에서 BPDU를 수신하지 못하기 때문에 새로운 RP를 선출하게 되고 기존 RP는 BPDU를 수신하지 못하는 상태이기 때문에 Designated Port로 변경 되어 트래픽을 전송하게 됩니다. 

Alternated Port에서 BPDU를 수신하지 못할 경우 종단 장비에 연결된 것으로 판단하고 Designated Port로 변경되어 트래픽이 전송되게 됩니다. 

결과적으로 차단 구간 (BLK 상태)가 존재하지 않기 때문에 Loop가 발생하는 환경이 만들어 지고, BPDU를 수신하지 못해 발생하는 Network Loop를 방지하기 위해 사용하는 기술이 Loop Guard 입니다. 

Loop Guard를 적용하는 방법은 (1) 스위치 전체에 활성화 하는 방법과 (2) 특정 인터페이스에서만 활성화 시키는 방법 2가지가 존재하며, 해당 기능은 Portfast와 같이 사용 할 수 없습니다. 

  1) 스위치 전체에 활성화 하는 방법

# loop guard 전역 설정
Switch(config)# spanning-tree loopguard default

  2) 스위치 포트에서 활성화 방법

# loop guard 특정 포트 설정
Switch(config-if)# spanning-tree guard loop

● Spanning-Tree Tuning - Loop Guard 동작 검증

BPDU Filter를 설정하여 BPDU 송/수신을 차단하면 Loop Guard가 동작하는 것을 확인 할 수 있습니다. 

※ SW2의 RP에 Loop Guard를 설정 (BPDU 수신 할 수 없을 경우 Err-Disabled 상태 변경)

※ SW2의 RP에 BPDU Filter 기능을 활성화 하여 수신 차단 (장애 상황 유발)

※ BPDU를 Timeout (20초) 시간 동안 받지 못해 RP는 BLK 상태로 변경

※ Loop Guard에 의해 불안정 상태(Inconsistency)로 취급되며 전송 불가 상태가 됨

● Spanning-Tree Tuning - Root Guard

Port 기반으로 수행되며 특정 포트가 RP(Root Port)가 되는 것을 방지하는 기술로 Root Bridge가 변경되어 Spanning-Tree 재계산으로 인해 프레임 손실을 막기 위한 Spanning-Tree 보호 기술 입니다. 

Root Guard가 설정 된 포트에서 현재 Best BPDU보다 더 좋은 Superior BPDU를 수신한 다면 해당 포트를 즉시 Err-Disable 상태로 전환 됩니다. 

Root Guard 활성화 방법은 아래 명령어와 같습니다. 

Switch(config-if)#spanning-tree guard root

●Spanning-Tree Tuning - BPDU Filter

BPDU Filter는 BPDU 송/수신을 차단하는 기능을 수행하지만 설정하는 위치 (스위치 전역 or 인터페이스)에 따라서 다르게 작동 하며, 일반적인 환경의 경우 BPDU Filter 적용은 필요하지 않습니다.

BPDU Filter를 적용하는 방법은 (1) 스위치 전체에 활성화 하는 방법과 (2) 특정 인터페이스에서만 활성화 시키는 방법 2가지가 존재하며 설정 위치에 따라 BPDU Filter가 다르게 동작 합니다. 

  1) 스위치 전체에 활성화 하는 방법

# bpdufilter 전역 설정
Switch(config)# spanning-tree portfast bpdufilter default

BPDU 전역설정은 portfast가 적용 된 인터페이스에만 적용 됩니다. portfast가 적용된 인터페이스가 활성화 되면 스위치는 BPDU를 전송하지만 hello inverval * 10 (20초) 시간동안 BPDU를 수신하지 못할 경우 더 이상 BPDU를 전송하지 않습니다.  그래서 결과적으로 10개 ~ 12개 사이의 BPDU를 전송하게 됩니다. 

만약 BPDU FIlter가 적용된 인터페이스에 BPDU를 받게 된다면 BPDU Filter 기능은 중지되고 일반적인 Spanning-Tree 규칙이 적용됩니다. 

  2) 특정 인터페이스에서 활성화 하는 방법

# bpdufilter 특정 포트 설정
Switch(config-if)# spanning-tree bpdufilter enable

인터페이스에 적용할 경우 BPDU는 전송하지 않고, 받은 BPDU는 폐기 합니다. (Silent Drop)

● Spanning-Tree Tuning - BPDU Guard

BPDU Guard가 적용된 포트에서 BPDU를 수신하게 되면 해당 인터페이스를 즉시 사용 불가 상태 (Err-Disable)로 변경시키는 스위치 보호 기술 입니다. 

● Spanning-Tree Tuning - BPDU Guard 적용 방법

BPDU Guard 설정 시 (1) 스위치 전체에 활성화 하는 방법과 (2) 특정 인터페이스에서만 활성화 시키는 방법 2가지가 존재합니다. 일반적으로 portfast 기능과 같이 사용합니다. .

  1) 스위치 전체에 활성화 하는 방법

# portfast 설정 시 bpdu guard도 같이 설정 됨
Switch(config)#spanning-tree portfast bpduguard default

  2) 특정 인터페이스에서 활성화 하는 방법

# 개별 포트에서 bpdu guard 설정
Switch(config-if)spanning-tree bpduguard {enable|disable}

  3) BPDU Guard 설정 확인 방법

Switch# show spanning-tree interface {interface-id} detail

  4) Err-Disabled 포트 자동 복구 방법

Switch(config)# errdisable recovery cause bpduguard

recovery 간격의 기본값은 5분이며 명령어를 통해 5초부터 86,400초 사이 값으로 변경 가능합니다. 

● Spanning-Tree Tuning - Portfast

Portfast 기능은 TCN (Topology Change Notification) BPDU 프레임을 access port로 보내지 않는 기능입니다. 추가적인 이득은 802.1D의 Listening과 Learning단계를 건너뛰어 곧장 Forwarding 상태로 전이되어 트래픽 전송이 가능합니다. 

● Spanning-Tree Tuning - Portfast 적용 방법

Portfast를 적용하는 방법은 (1) 스위치 전체에 활성화 하는 방법과 (2) 특정 인터페이스에서만 활성화 시키는 방법 2가지가 존재 합니다. 스위치 전역에서 기능을 활성화 할 경우 portfast 기능이 불필요한 인터페이스는 개별적으로 비활성화 시켜 주어야 합니다. 네트워크 장비와 연결된 포트에서는 portfast 기능을 비활성화 시켜 주어야 합니다.

  1) 스위치 전체에 활성화 하는 방법

Switch(config)#spanning-tree portfast default

## 포트에서 portfast 비활성화 방법
Switch(config-if)#spanning-tree portfast disable

  2) 특정 인터페이스에서 활성화 하는 방법

Switch(config-if)#spanning-tree portfast

● Spanning-Tree Tuning - Portfast 적용 시 주의사항

Trunkport에서도 Portfast를 활성화 할 수 있으나 hypervisor 또는 vmware와 같은 호스트 장비에서 단일 포트로 여러개의 VLAN 정보를 사용하는 경우에만 가능합니다. 네트워크 장비와 연결 된 포트에서 portfast를 적용할 경우 bridge loop가 발생합니다. 

● Block Port 변경 방법 

Spanning-Tree에서 포트의 역할을 변경하는 것은 Port에 할당 된 Port Cost를 변경하는 방법을 이용하여 변경 할 수 있습니다. 

Block Port 선출 방법

아래는 Block Port를 선출하는 기준입니다. 2번째기준을 이용하면 RP의 Port Cost값을 변경해 주면 BLK와 DP의 상태를 변경할 수 있습니다. 

    1) Root Port의 Port Cost값 변경을 이용한 DP와 BLK 변경

SW3 RP의 COST값 변경 (4 &amp;amp;amp;rarr; 1)

SW3 Root Port의 Path Cost를 1로 변경하였고 해당 작업의 영향은 STP 전체에 영향을 주게 됩니다. 

  - SW2 ↔ SW3 구간 : RP 선출 기준 2번에 따라 SW3이 Root Bridge까지 거리가 가깝기 때문에 SW2에서 BLK를 선출해야 함.

  - SW4 ↔ SW5 구간 : SW5 Root Path는 5이고, SW4의 Root Path는 8이기 때문에 SW5의 BLK가 모두 DP 상태로 변경 됨

Spanning-Tree에서 포트의 역할을 변경하는 것은 Port에 할당 된 Priority 값을 변경하는 것과 Port Cost를 변경하는 방법을 이용하여 변경 할 수 있습니다.

  ○ Root Port 변경 방법

※ Root Port 선출 과정

    1) Root Port의 Port Cost 변경

1번 규칙에 의거하여 Root Port의 STP Path Cost값을 높여주면 RP가 변경이 됩니다. 

(Root Bridge와 직접적으로 연결 된 스위치는 해당하지 않습니다.)

    2) Port Priority 변경을 통해 Root Port 선정

Port Priority 수정 시 영향을 받는 영역은 스위치간 다중 링크로 연결되어 있을 경우 Alternated Port가 영향을 받습니다. (아래 이미지의 SW4와 SW5의 인터링크 구간)

SW3 RP의 COST값 변경 (4 &amp;rarr; 1)

SW5의 RP에 장애가 발생 할 경우 BLK 포트 중 하나가 RP가 되어야 하며 기본값을 사용할 경우 선출기준 5번에 의해 Gi1/0/4가 RP로 선출 됩니다. 

Remote Switch Port Priority 변경 전

Port Priority 수정을 통해 RP를 변경할 수 있으며 Priority 수정은 Remote Switch에서 수행하면 Local Switch의 RP가 변경이 됩니다. 

SW4에서 Port Priority 수정

port-priority를 수정할 때 Vlan 키워드로 특정 VLAN에서만 port-priority가 변경 되도록 수정할 수 있습니다. vlan 키워드가 없으면 전체 spanning-tree에 적용 됩니다. 

Remote Switch Port Priority 변경 후

● OSPF 최적 경로 선출 과정

OSPF에서 최적 경로를 선출하기 위해 Route Type을 사용합니다. Network 경로정보 학습의 기준에 따라 Intra, Inter, External로 나뉩니다. 

동일한 네트워크 경로정보가 존재하더라도 아래의 기준에 따라 최적 경로가 선출되고, 다시 COST값을 비교 한 뒤 최종적으로 최적 경로가 선출 됩니다.

● OSPF Loop Avoidance 방법과 부작용

OSPF는 Link-State Protocol 이지만, Area 사이는 Distance Vector 처럼 동작합니다. 동일 Area에서 발생하는 정보는 LSA Type 1 / 2 정보로 OSPF에 참여하는 모든 라우터가 동일한 토폴로지를 생성하고 동일한 LSDB를 가지고 있지만 외부 Area의 정보는 상세한 정보 대신 요약된 정보가 넘어 옵니다. 

OSPF에서 Loop 가 발생하지 않도록 하기위해 2가지 규칙이 존재 합니다. 일부 LSA Type에 Distance Vector 계열의 프로토콜에서 사용하는 Split-Horizon과 같은 기능을 적용하여 Area 사이에서 Loop 가 발생하지 않도록 합니다. 

  ○ OSPF Loop 방지 규칙 2가지

1. Non-Backbone은 Intra 경로만 Backbone으로 전달 가능하고, Backbone은 Intra & Inter 경로 정보를 Non-Backbone으로 전달 가능
   
   → Area에서 다른 Area의 경로를 학습하는 유일한 방법은 Backbone Area를 통해서만 가능 합니다. 해당 규칙은 모든 Non-Backbone Area는 Backbone Area에 연결되어 있어야 정상적인 경로 학습이 가능합니다. 
   
   
2. ABR은 SPF 알고리즘 계산 시 Non-Backbone에게 받은 LSA Type 3은 무시한다. 즉, Backbone Area or Other Area의 네트워크에 접근하기 위해 Non-Backbone Area를 거치지 않는다.
   
   → Loop를 방지하고 대역폭 낭비를 예방하기 위한 규칙 입니다. 해당 규칙으로 인해 최적 경로대신 비효율적인 경로가 선택 될 수 있습니다.
   
   

※ 규칙 2 세부 설명

ABR3's Subnet 1 네트워크 정보가 OSPF로 광고되고 해당 정보는 Area 1의 ABR1 & ABR2에게 전달 됨. 

R2에서 Subnet1로 가기 위해 선택되는 경로는 2번 경로를 통해서 목적지로 도달하게 됨. 

1. R2 → ABR2 → ABR1 → ABR3 = COST 4 (X)

2. R2 → ABR2 → ABR3 = COST 102 (O)

ABR1에게 받은 Subnet1에 대한 LSA Type 3 정보를 무시하고 SPF 계산에 포함시키지 않습니다. 다른 Area 도달하기 위해서는 Backbone Area를 반드시 경유해야 합니다. 

## 중요 ##
Type 7 ->  Type 5 로 넘기는 건 Backbone Area (Area0) 의 ABR 중 하나만 가능!!!!

넘길때 Forwarding address 는 바뀌지 않음!!

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

● OSPF NSSA 정의

Stub Area의 특징을 가지고 있고, ASBR이 존재하여 외부 경로를 재분배를 통해 OSPF Domain 내부로 삽입할 수 있는 Area 입니다.

● OSPF NSSA 특징

• 외부 경로 정보 (LSA Type 5)정보를 받지 않는 Stub 특성을 가지고 있지만 ASBR을 가질 수 있는 특수 AREA.
• ASBR within NSSA에서 재분배를 수행하게 되면 O N1, O N2의 Route Type으로 라우팅 테이블에 나타남
• NSSA에서 재분배되는 네트워크 경로 정보는 LSA Type 7으로 전달되며, NSSA ABR이 LSA Type 5로 변경하여 다른 Area로 광고를 수행 함.
• NSSA ABR 2개 이상 있을 경우 가장 높은 Router-ID를 가진 NSSA ABR이 Type 7 → Type 5 변경을 수행
• LSA Type 7 헤더에는 P bit (Propagation bit)가 설정되어 있어 NSSA ↔ Backbone 사이 Loop 방지 역할 수행
• Stub와 달리 Default Route가 자동으로 생성되지 않음. 생성을 위해 ABR에서 추가 명령어 입력이 필요함.
• NSSA의 기능을 확장 한 Cisco 전용 기술인 Totally NSSA가 있으며 NSSA ABR이 LSA Type 3 ~ 5 정보 Filtering을 수행하고 Default Route를 생성하여 NSSA Neighbor에게 전달

● OSPF NSSA Default Routing 생성 방법

NSSA는 ASBR이 존재하기 때문에 기본적으로 Default 경로 정보를 전달하지 않습니다. 그래서 Default Route 정보를 NSSA OSPF Router에게 전달하기 위해 NSSA ABR은 별도의 명령어를 사용해야 합니다.

NSSA_ABR(router-config)#area area-id nssa default-information-originate

● OSPF Stub & NSSA 비교