choiyoonjun111의 등록된 링크
choiyoonjun111로 등록된 네이버 블로그 포스트 수는 496건입니다.
[MPLS] MPLS Packet Forwarding 간략 동작 과정 [내부링크]
MPLS 간략 동작 과정 RIB Update 라우팅 프로토콜은 Control Plane에서 Routing Update를 진행하여 RIB를 채움 RIB → Routing Table Routing Protocol의 Preference 및 Metric을 기반으로 각 RIB에서 Best-Path를 선택하여 Routing Table로 업데이트 시킴 Routing Table → FIB 실제 Data Forwarding을 하기 위해 Data Plane에 속하는 FIB를 생성함 - RIB 정보는 Data Plane으로 전송되고 FIB에 저장됨 Control Plane은 라우팅 정보를 교환하고 RIB를 유지함 Data Plane은 FIB를 저장하고 해당 Table의 정보를 기반으로 Data를 Forwarding함 Nokia 7750 SR은 RIB 정보를 CPM에 저장하며 FIB 정보를 IOM에 저장함 IP Packet Forwarding FIB는 IP Packet을 전달하는 데 사용됨
[MPLS] MPLS Packet Forwarding 상세 동작 과정 (Cisco) [내부링크]
MPLS 상세 동작 과정 (Cisco) Routing Protocol Enable MPLS는 Best-Path를 찾는 알고리즘이 없으므로 Routing Protocol을 Enable 해야 함 C Network는 R4와 Direct Connect로 구성됨 MPLS Enable 후 Label 생성 MPLS을 Enable하면 LIB Table와 LFIB Table이 생성됨 LIB Table이 생성되면 Routing Table에 있는 네트워크 중 BGP를 제외하고 모든 네트워크에 대해 Label을 할당함 Nokia 7750 SR은 Default로 System IP에 대한 Label만 할당함 - 다른 IP에 대해 Label을 할당하려면 Policy를 설정을 해야 함 LDP Enable 후 Label 교환 LDP를 이용해 Label을 서로 교환하여 본인이 할당한 Label 정보와 Neighbor가 할당한 Label 정보를 LIB Table에 넣음 LFIB Table 생성 eLER(
[MPLS] LDP 개요 [내부링크]
LDP 개요 Label Signaling으로 LSP를 생성함 MPLS Transport Label Signaling Protocol 종류는 LDP, RSVP가 있음 LDP(Label Distribution Protocol) Overview IGP 알고리즘에 의해 결정됨 - IGP 경로에 따라 해당 FEC에 사용하는 최적 경로(LSP)가 결정됨 - Only IGP Base Tunnel(LSP) - IGP Convergence Time에 의존함 Tunnel(LSP)이 자동으로 생성됨 Traffic Engineering을 지원하지 않음 "Link LDP" 또는 "Interface LDP"라고도 함 D-FEC에 대한 FIB Best-Path를 기준으로 LFIB 항목을 선택함 Nokia 7750 SR은 System IP가 아닌 다른 FEC Label을 광고하려면 Export Policy를 적용해야 함 - System IP가 없으면 LDP Session 및 Tunnel을 생성하지
[MPLS] Target LDP 개요 [내부링크]
Target LDP 개요 T-LDP(Target-LDP) 개요 Nokia 7750 SR은 LDP와 T-LDP(Targeted LDP)라는 두 가지 LDP를 사용함 T-LDP를 사용하여 Service Label을 교환하고 L2 VPN Service에 대한 Service Tunnel을 설정함 - PE는 Service Label을 사용하여 특정 VPN의 트래픽을 식별함 - Service Tunnel은 PE에서 PE로 VPN Traffic을 Tunneling 함 - Service Tunnel은 End-to-End 간 Traffic Forwarding을 위해 MPLS Transport Tunnel에 의존함 Link LDP와 독립적으로 사용됨 - T-LDP는 Link LDP를 사용하지 않고 동작 가능 Link LDP는 직접 연결된 Peer 사이에 Neighbor를 형성함 T-LDP Remote으로 연결된 Peer 사이에 Neighbor를 형성함 L3 VPN의 경우 Service La
[MPLS] Link LDP Base LSP 설정 및 확인 [내부링크]
Link LDP 설정 Link LDP Config Link LDP 상태 확인 Link LDP Session 상태 확인 "show router ldp session" 명령어 - LDP Peer State를 보여줌 LDP Session Adjacency Type Link 인접한 모든 LDP Node Session Targeted SDP Node Session Both Link + Targeted Link LDP Statistics 상태 확인 "show router ldp statistics" 명령어 - LDP Process의 Session의 수, Adjacency Neighbor의 수, LDP가 활성화 된 인터페이스의 수 등 정보를 확인할 수 있음
[MPLS] MPLS 개요 및 개발 배경 [내부링크]
MPLS(Multiprotocol Label Switching) 개요 MPLS(Multiprotocol Label Switching) 개요 RFC 3031에 정의되어 있음 IPv4, IPv6, Ethernet, ATM, Frame-Relay 등 다양한 프로토콜의 데이터를 전송할 수 있음 MPLS 장비는 미리 결정된 Label을 사용하여 데이터를 전달함 하나의 물리적인 망에서 여러 개의 독립적인 서비스 수용이 가능함 요즘 MPLS만을 이용하는 것만으로는 크게 의미가 없으며 VPN이나 TE 등의 추가 서비스를 이용하기 위한 기반 기술로 많이 사용함 MPLS의 Best-Path 정보는 Routing에 Best-Path가 계산되면 해당 정보를 이용함 - Routing Protocol에서 Loop가 발생하면 MPLS에도 Loop가 발생됨 MPLS Label을 교환하고 Tunnel을 생성하기 위해 Signaling Protocol이 필요함 MPLS 개발 배경 IP Routing(C
[MPLS] LSP 및 FEC 개념 [내부링크]
LSP Signaling Type Static LSP(Label Switched Path) 관련된 모든 라우터(Ingress, Transit, Egress)에 Label을 수동으로 할당 LDP(Label Distribution Protocol) Signaling Hop-by-Hop 단위 Traffic Engineering 미지원 Dynamic하게 Transport Tunnel(LSP) 설정 RSVP(Resource Reservation Protocol) Signaling Traffic Engineering 지원 Static하게 Transport Tunnel(LSP) 설정 - LSP를 생성하기 위해 별도의 Config가 필요 MPLS Service Label Signaling Protocol T-LDP(Targeted LDP) L2 VPN Service에 사용함 두 PE 간 Session을 생성함 MPLS를 통한 Service 구현에 사용됨 eLER → iLER(VP
[MPLS] MPLS POP(Imp-Null) 및 Untagged Label 개념 [내부링크]
POP(Imp-Null) 개념 POP(Imp-Null) Label Distribution POP은 상대방에게 Label 3을 받은 것 eLER에서 수행됨 상대 장비가 MPLS가 동작하는 것을 알고 있음 - 해당 Label(= 3)만 제거 후 Forwarding POP(Imp-Null) Label Forwarding 장비의 Table에 Outgoing Label이 3으로 표시되지만 MPLS Label에는 해당 값이 존재하지 않음 - R2는 Incoming MPLS Packet을 Label 3으로 Swap하지 않음 R2가 Label을 POP하는 해당 동작을 PHP(Penultimate Hop Popping)라고 함 R2는 Transport Label만 POP함 R2는 R3이 Service Label을 기반으로 Service 선택을 할 수 있도록 Service Label은 제거하지 않음 Nokia 7750 SR PHP 기능 Nokia 7750 SR OS는 LDP와 RSVP-
[MPLS] MPLS Explicit Null Label 동작 과정 [내부링크]
Explicit Null 개념 Explicit Null Label Distribution R3은 EXP 비트에 포함된 QoS 정보가 필요한 상황일 때 사용함 R3은 Label 0을 R2로 전송함 R2는 Explicit Null Label을 전달 받았으므로 EXP 값을 유지함 - eLER는 Explicit Null Label을 POP하기 전에 EXP 값을 기준으로 Packet을 처리할 수 있음 R3은 직접 Label을 POP하며 R3는 QoS 처리를 위한 EXP 비트 값을 기록함 - Explicit Null Label은 Packet의 QoS가 손실된 PHP 문제를 해결함 Explicit Null Label Forwarding R2는 R3의 요청을 수락하고 Label 값이 0인 데이터를 전송함 R3는 Label 값이 0인 데이터가 들어오면 Table을 Lookup하지 않고 즉시 Label을 PoP함 - 유입된 데이터의 두 번째 MPLS Header를 조회함 - 두 번째 Hea
[MPLS] MPLS Label Stack [내부링크]
Label Stack 개념 Label Stack 구조 Nokia 7750 SR OS는 최대 6개의 Label을 지원함 VPN Service에 따른 Label Stack의 필요성 P장비는 Transport Tunnel만 인식하며 PE장비가 Service를 인식함 VPN Service의 MPLS Label Stack 간략 동작 과정 VPN Service의 Label Stack 간략 동작 과정 R3(eLER)은 Packet을 수신하면 먼저 Transport Label을 T2로 처리함 R3(eLER)은 Data에 대한 Service를 선택할 수 있도록 Service Label이 필요함 - R3(eLER)이 Service Label(S1)을 R1로 송신했기 때문에 R3은 해당 Data가 Service[Number]과 Customer[Number]에 속한다는 것을 알고 있음 VPN Service의 MPLS Label Stack 동작 과정 L2 VPN Service와 L3 VPN Ser
[MPLS] MPLS Header [내부링크]
MPLS Header MPLS Header 필드 내용 Label Value - 0 ~ 1,048,575 값을 사용 · IP Routing과 비교하면 D-IP의 역할을 수행함 EXP (Experimental) - 어떤 것을 우선하여 Forwarding할 것인지 정함 · 우선순위를 표시함 - RFC 5460에서는 TC(Traffic Class)로 이름이 변경됨 - EXP 처리 방법 1. Uniform Mode 2. Pipe Mode (Nokia SR OS는 Pipe Mode만 구현됨) S (Bottom-of-stack) - 1 : 마지막 Label 임을 알림 - 0 : 마지막 Label이 아님을 알림 TTL (Time-to-Live) - IP Header의 TTL과 목적이 같음 · Loop 방지 목적 -TTL=0일 시 해당 Data는 Drop됨 - TTL 처리 방법 1. Uniform Mode 2. Pipe Mode (Nokia SR OS는 Pipe Mode만 구현됨) Nokia SR
[MPLS] MPLS Mode [내부링크]
MPLS Label Stack Mode MPLS Frame Mode Nokia SR OS는 Frame Mode만 구현됨 MPLS Cell Mode Cell Mode에서 MPLS Label 정보는 ATM VPI/VCI 또는 Frame Relay DLO 필드에 전송될 수 있음 ATM에서는 Cell Header의 VPI/VCI 필드가 MPLS Label로 사용됨 Label Distribution Mode FEC에 대한 Label을 배포하는 Mode를 정의함 Downstream Unsolicited Mode (DU) 라우팅 변화에 대한 적용이 빠름 Neighbor가 Label을 요청하지 않아도 본인의 FEC(Z)에 대한 Label을 즉시 광고함 - FIB에서 Local로 가지고 있는 Prefix에 대한 Label을 광고함 - 모든 Upstream Router에 전파됨 R2는 R3로부터 Label Binding을 수신하고 기록함 - R2는 Label 값이 200인 Local Bi
[Emulator Guide] Windows 10 설치 ① [내부링크]
Windows 10 설치 ① 1. "File" 선택 → "New Virtual Machine" 선택 - "Power on this virtual machine"을 선택하여 가상 머신에 전원을 넣어줌 2. "Custom(advanced)" 선택 → "Next" 선택 3. "Next" 선택 - 각자 PC에 설치된 Workstation의 Version에 맞는 것을 선택함 4. "I will install the operating system later." 선택 - 설치하려는 운영체제는 나중에 설치하기 위해 선택함 5. "Microsoft Windows" 선택 → "Windows 10 x64" 버전 선택 → "Next" 선택 - Windows를 설치해야 하므로 "Microsoft Windows"를 선택함 6. Virtual Machine Name 및 설치 위치 선택 → "Next" 선택 - "Virtual Machine Name" : 설치하려는 Virtual Machine 이름 - "Loc
[Emulator Guide] Windows 10 설치 ② [내부링크]
Windows 10 설치 ② 1. "Power on this virtual machine" 선택 - "Power on this virtual machine"을 선택하여 가상 머신에 전원을 넣어줌 2. Windows에 설치할 언어 선택 3. "지금 설치" 선택 4. "제품 키가 없음" 선택 - 제품 키는 돈을 지불해야 하므로 제품 키 없이 설치 진행함 5. 설치할 Windows 운영체제 선택 6. 동의 후 "다음" 선택 7."사용자 지정: Windows만 설치(고급)(C)" 선택 8. Windows를 설치할 드라이버 선택 → "다음" 선택 9. Windows 자동 설치 - Windows가 설치되면 자동으로 재부팅됨 10. 국가 선택 11. 자판 배열 선택 12. Microsoft 계정 없이 설치 - 임의의 Microsoft 계정 입력 후 "다음" 선택 - 임의의 비밀번호 입력 후 "다음" 선택 - "지금은 건너뛰세요." 선택 - "제한된 환경" 선택 13. PC 계정 생성 - PC 이
[Win SV 2019] Windows Tools 설치 방법 [내부링크]
필자는 VMware에 Windows를 설치하면 "VMware Tools"를 설치하는 것을 권장한다. "VMware Tools"를 설치하여 얻는 이점 1) Host PC와 Guest PC 간에 "Drag & Drop" 기능이 가능해져 파일 및 폴더를 쉽게 이동할 수 있음 2) VMware 프로그램 창을 최대로 했을 때 Guest PC의 Windows도 같이 커짐 - VMware Tools 설치 전에는 Guest PC의 Windows가 커지지 않음 3) Host PC와 Guest PC 간에 마우스 이동이 원활해짐 - VMware Tools 설치 전에 Guest PC → Host PC로 마우스 이동 시 "Ctrl + Alt"를 눌러야 함 Windows Tools 설치 방법 1. "VM" 탭 선택 → "Install VMware Tools..." 선택 2. 파일 탐색기 열기 → "내 PC" 선택 → "DVD 드라이브 (D:) VMware Tools" 열기 3. "VMware Tools"
[CentOS 8.0] 자동 업데이트 기능 제거 방법 [내부링크]
CentOS 8.0 자동 업데이트 기능 제거 방법 1. "Activities" 선택 → 바둑판 모양 선택 → "Settings" 선택 2. 자동 업데이트 기능 제거 - 해당 명령어를 입력한 계정이 관리자 계정이 아닌 사용자 계정이므로 관리자의 허가가 필요함 - root 계정의 비밀번호를 입력하면 됨 명령어 [root@localhost ~]# gsettings set org.gnome.software download-updates false [root@localhost ~]# systemctl disable dnf-makecache.service [root@localhost ~]# systemctl disable dnf-makecache.timer CentOS 8.0 소프트웨어를 설치할 때 구 버전으로 다운로드 받는 방법 리눅스는 패키지를 서버에서 다운로드 받는데 해당 서버는 최신 OS에 대한 파일도 다운로드 시킴 - 리눅스는 구 버전인데 서버에서 최신 OS에 대한 파일을 다운로드
[CentOS 8.0] CLI로 Static IP 설정 방법 [내부링크]
CLI로 Static IP 설정 방법 1. IP 설정 전 기본적으로 할당된 IP 확인 IP 설정 전 IP가 기본적으로 "192.168.111.128/24"로 자동 세팅되어 있음 기본적으로 DHCP를 이용하여 IP를 자동으로 할당받기 때문에 초기 세팅이 없어도 할당받은 IP가 있음 2. IP를 관리자가 원하는 IP로 설정 명령어 [root@localhost ~]# cd /etc/sysconfig/network-scripts/ [root@localhost network-scripts]# ls ifcfg-ens160 [root@localhost network-scripts]# gedit ifcfg-ens160 파일 수정 전에 IP를 "dhcp"로 할당받음 "gedit"명령어를 이용하여 "ifcfg-ens160 "파일을 수정함 명령어 BOOTPROTO="none" IPADDR="192.168.111.100" NETMASK="255.255.255.0" GATEWAY="192.168.1
[Emulator Guide] VMware Snapshot 설정 방법 [내부링크]
VMware Snapshot 설정 방법 1. "VM" 탭 선택 → "Snapshot" 선택 → "Snapshot Manager" 선택 - "Power on this virtual machine"을 선택하여 가상 머신에 전원을 넣어줌 2. "Take" Snapshot..." 선택 3. Snapshot Name 적은 후 "Take Snapshot" 선택 4. VMware Snapshot 저장 확인 - VMware에 문제가 발생했다면 돌아갈 시점을 선택한 후 "Go To" 버튼을 누르면 됨
[유튜브] 유튜브 재생목록 다운로드 받는 방법 [내부링크]
요즘 유튜브를 시청하시는 분들이 많이 늘어나고 있다. 인터넷이 잘 되는 곳에서 컴퓨터로 유튜브를 시청하시는 분들은 상관이 없지만 인터넷이 원활하지 않는 곳에서 유튜브를 시청하시는 분들은 유튜브 영상 화질이 내려가거나 영상이 자주 끊어져 불편함이 많았을 것이다. 인터넷에서는 유튜브 영상을 무료로 다운로드 하는 방법은 많이 공유되고 있는데 보통 하나의 영상을 다운로드 받는 방법이었다. 하나의 재생 목록에 있는 여러 영상을 한 번에 다운로드 받는 방법을 찾아보기 힘들었다. 이번 글에는 유튜브에서 하나의 재생 목록에 있는 여러 영상을 한 번에 무료로 다운로드 받는 방법을 공유하려고 한다. 유튜브 자동 종료 설정하는 방법 1. 아래 사이트로 이동 https://github.com/KurtBestor/Hitomi-Downloader/releases Releases · KurtBestor/Hitomi-Downloader :cake: Desktop utility to download images/
[iPhone] 아이폰 들어서 깨우기 설정 끄는 방법 [내부링크]
현대인이 가장 많이 사용하는 물건 중 하나가 스마트폰이라고 한다. 보통 사람들이 스마트폰으로 부재중 전화, 문자, 알림, 시간 확인을 하는데 이때 스마트폰을 들기만 하면 화면이 켜져 쉽게 확인이 가능하도록 도와줄 수 있는 기능이 있다. 보통 스마트폰 사용자들은 해당 기능이 편하다고 생각하여 활성화시켜 놓는다. 하지만 몇몇 사용자들은 해당 기능이 불필요하고 배터리 소모 등 여러 불편한 점이 있다고 생각하여 해당 기능을 비활성화하여 사용한다. 이번 글에는 아이폰을 들어서 깨우는 설정을 끄는 방법을 공유하려고 한다. 아이폰 들어서 깨우기 설정 끄는 방법 1. "설정" 앱 선택 2. "디스플레이 및 밝기" 선택 3. "들어서 깨우기" 선택하여 비활성화 - "들어서 깨우기"를 선택하여 해당 기능을 비활성화한다.
[유튜브] 유튜브 PIP 모드 설정하는 방법 [내부링크]
요즘 스마트폰을 보유하고 있는 분들이라면 보통 가장 많이 사용하는 앱 중 하나가 유튜브라고 생각한다. 유튜브 앱을 화면에 작게 띄어놓고 다른 앱을 사용하여 사용성을 높일 수 있다. 해당 모드를 PIP 모드라고 하며 화면이 작은 스마트폰에서도 편리하지만 큰 화면을 가진 패드에서 PIP 모드를 사용했을 때, 훨씬 편리하다. PIP 모드는 프리미엄 멤버십을 유료로 구매한 분들만 사용할 수 있는 기능이다. 만약 프리미엄 멤버십을 구매하지 않은 분들이라면 유튜브 앱을 바로 활용하는 것이 아닌 다른 웹브라우저를 이용하여 PIP 모드를 사용하여 동일한 효과를 볼 수 있다. 이번 글에는 유튜브 앱을 PIP 모드로 설정하는 방법을 공유하려고 한다. 유튜브 PIP 모드 설정하는 방법 1. "YouTube" 앱 선택 2. 계정 아이콘 선택 3. "설정" 선택 4. "일반" 선택 5. "PIP 모드"를 선택하여 활성화 6. "PIP 모드" 동작 확인 - 유튜브 앱에서 영상을 시청하다 홈으로 돌아가면 유튜
[유튜브] 유튜브 앞뒤로 건너뛰기 시간 설정하는 방법 [내부링크]
많은 분들이 모바일로 유튜브를 시청할 때 시간을 앞뒤로 건너뛰는 기능을 자주 이용한다. 유튜브 앱에서는 기본 값으로 앞뒤로 건너뛰는 시간이 10s이지만 사용자가 변경할 수 있다. 사용자가 변경할 수 있는 시간은 5s, 10s, 15s, 20s, 30s, 60s이다. 이번 글에는 모바일 유튜브 앱에서 앞뒤로 건너뛰는 시간을 설정하는 방법을 공유하려고 한다. 유튜브 앞뒤로 건너뛰기 시간 설정하는 방법 1. "YouTube" 앱 선택 2. 계정 아이콘 선택 3. "설정" 선택 4. "일반" 선택 5. "앞뒤로 건너뛰기" 선택 6. 앞뒤로 건너뛰고 싶은 시간을 선택 - 여기까지 정상적으로 설정을 했다면 유튜브 영상 시청을 하는 중에 화면 왼쪽을 두 번 연속 터치하면 설정한 시간 전으로 이동할 수 있고 화면 오른쪽을 두 번 연속 터치하면 설정한 시간 후로 이동할 수 있다.
[유튜브] 유튜브 자동 종료 설정하는 방법 [내부링크]
대부분 자기 전에 침대에 누워 휴대폰이나 태블릿PC로 유튜브를 시청한다. 유튜브를 시청하다 잠이 들어 아침에 배터리가 없는 경우가 많을 거라고 생각한다. 배터리가 없어 휴대폰이 꺼지는 경우가 발생한다면 알람이 울리지 않는 불상사가 생길 수 있다. 유튜브 앱에서 자동으로 종료되게 설정하여 위와 같은 걱정을 줄일 수 있다. 이번 글에는 모바일 유튜브 앱에서 자동으로 동영상 시청을 종료할 수 있는 자동 종료 기능을 설정하는 방법을 공유하려고 한다. 유튜브 자동 종료 설정하는 방법 1. "YouTube" 앱 선택 2. 계정 아이콘 선택 3. "시청 시간" 선택 4. "시청 중단 시간 알림" 선택 5. 유튜브를 시청하고 싶은 시간을 설정 6. "시청 중단 시간 알림" 설정 확인 - 위와 같이 설정했다면 5분마다 시청 중단 알림이 뜬다. 7. "시청 중단 시간 알림" 동작 확인 - 위 캡처 자료와 같이 시청 중단 알림이 뜬다. 여기서 "닫기"를 누르면 영상이 이어서 재생되고 5분 뒤에 시청 중
[Emulator Guide] CentOS 8 설치 ① [내부링크]
CentOS 8 설치 ① 1. "File" 선택 → "New Virtual Machine" 선택 2. "Custome(advanced)" 선택 → "Next" 선택 3. "Workstation 17.x" 선택 → "Next" 선택 - 각 사용자 컴퓨터에 설치된 Workstation 버전에 맞는 것을 선택함 4. "I will install the operating system later." 선택 - 가상머신에 운영체제를 나중에 설치하기 위해 "I will install the operating system later."를 선택함 5. "Linux" 선택 → "CentOS 8 64-bit" 선택 → "Next" 선택 - CentOS는 Linux의 종류 중 하나이기 때문에 Linux를 선택함 - 현재 설치하려는 CentOS 버전(CentOS 8)을 선택하면 됨 6. Virtual Machine Name 및 설치 위치 선택 → "Next" 선택 - "Virtual Machine Name"
[Emulator Guide] CentOS 8 설치 ② [내부링크]
CentOS 8 설치 ② 1. "Power on this virtual machine" 선택 - "Power on this virtual machine"을 선택하여 가상 머신에 전원을 넣어줌 2. "Install CentOS Linux 8.0 1905" 선택 - "Install CentOS Linux 8.0 1905"를 선택하여 CentOS 8을 설치함 - 위, 아래 방향 키를 이용하여 이동할 수 있고 엔터키를 이용하여 선택할 수 있음 3. "English" 선택 → "Continue" 선택 - 설치할 때 사용할 언어를 선택함 4. "Time & Date" 선택 - 한국 시간으로 맞추기 위해 "Time&Date"를 선택함 5. "Asia" / "Seoul" Timezone 선택 - "Asia" / "Seoul" Timezone을 선택 6. "Software Selection" 선택 7. "Workstation" 선택 → "Done" 선택 - CentOS에 설치할 소프트웨어를 선택함
[CentOS 8.0] 리눅스 화면 보호기 설정 해제 방법 [내부링크]
CentOS 8.0 리눅스 화면 보호기 설정 해제 방법 1. "Activities" 선택 → 바둑판 모양 선택 → "Settings" 선택 2. "Privacy" 선택 → "Screen Lock" 선택 3. "Automatic Screen Lock"을 선택하여 비활성화 - "Show Notifications"도 선택하여 비활성화하는 것이 테스트하는 환경에 좋음 4. "Power" 선택 → "Blank Screen" 시간 선택 5. "Never" 선택
[iPhone] 아이폰 와이파이 비번 알아내기 [내부링크]
요즘 인터넷 보급이 아주 잘 되어 있어 카페, 도서관, 식당, 가정집 등 다양한 곳에서 와이파이를 사용할 수 있다. 데이터 무제한 요금제를 사용하는 분들에게는 와이파이를 사용하지 않는 것에 대해 큰 문제가 없지만 데이터가 제한적인 요금제를 사용하는 분들에게는 와이파이를 이용하여 인터넷을 사용하는 것이 중요할 수 있다. 이렇게 다양한 장소에서 와이파이를 잡아 인터넷을 사용하고 있는 상황에서 다른 사람에게 와이파이 비밀번호를 쉽게 공유할 수 있다. 아이폰 와이파이 비번 알아내기 1. "설정" 앱 선택 2. "Wi-Fi" 선택 3. "i" 선택 4. 암호 선택 5. 와이파이 비번 확인
[iPhone] 아이폰 핫스팟 비번 변경/확인하기 [내부링크]
요즘 데이터를 많이 사용할 수 있는 요금제가 많아 도서관, 카페 등 집 밖에서 패드, 노트북 등 다양한 기기에서 인터넷을 사용하기 위해 스마트폰으로 핫스팟을 사용할 상황이 많이 생긴다. 핫스팟을 사용할 때 원하지 않는 다른 사람들이 내 데이터를 사용하는 상황을 방지하기 위하여 비번을 설정하는 것이 좋다. 또한, 비번은 주기적으로 변경하는 것을 추천한다. 이번 글에는 아이폰 핫스팟 비번을 확인하는 방법과 변경하는 방법을 공유하려고 한다. 아이폰 핫스팟 비번 확인하기 1. "설정" 앱 선택 2. "개인용 핫스팟" 선택 3. "Wi-Fi" 암호 확인 - 핫스팟을 사용하려면 "다른 사람의 연결 허용"을 선택하여 활성화시킨다. 아이폰 핫스팟 비번 변경하기 1. "설정" 앱 선택 2. "개인용 핫스팟" 선택 3. "Wi-Fi 암호" 선택 - 핫스팟을 사용하려면 "다른 사람의 연결 허용"을 선택하여 활성화시킨다. 4. 핫스팟 암호 변경
[iPhone] 아이폰 음량버튼으로 벨소리 크기 조절하기 [내부링크]
아이폰의 음량 조절 버튼은 기본적으로 벨소리 크기를 조절하는 것이 아닌 미디어 소리 크기를 조절한다. 필자도 아이폰을 3달이나 사용했는데 처음 알았다....... 분명히 음량버튼을 이용하여 볼륨을 최대로 설정해 놨는데 벨소리가 안 커져 너무 답답했었다. 아이폰 음량버튼은 기본적으로 미디어 소리 크기를 조절한다고 해서 알아보니 아주 간단한 설정을 통하여 음량버튼을 벨소리 크기 조절에 사용할 수 있었다. 이번 글에는 아이폰 음량버튼을 이용하여 벨소리 크기를 조절하는 방법을 공유하려고 한다. 아이폰 음량버튼으로 벨소리 크기 조절하기 1. 설정 전 음량 버튼 확인 - 설정 전에 음량버튼을 사용하면 화면 좌측에서 볼륨 조절이 된다. - 여기서 볼륨 조절이 되는 것은 벨소리 크기가 아닌 미디어 볼륨 크기이다. 2. 제어센터에서 미디어 볼륨 조절 - 아이폰의 미디어 볼륨을 제어센터에서 쉽게 조절할 수 있어 음량버튼으로 조절 할 필요성이 떨어진다. 3. "설정" 앱 선택 4. "사운드 및 햅틱"
[iPhone] 아이폰 제어 센터 설정 [내부링크]
아이폰을 오래 사용한 분이라면 제어 센터를 잘 활용할 수 있겠지만 아이폰을 사용한지 얼마 안 된 분이라면 제어 센터를 효율적으로 사용하지 못할 가능성이 크다고 생각한다. 제어 센터에 기본 앱을 등록하여 사용하면 확실히 편하다. 필자도 아이폰을 사용한 기간이 고작 3개월뿐이라 아이폰에 대한 기능을 잘 알지 못한다. 필자도 제어 센터 기능을 모르고 사용하다가 기본 앱을 등록한 후 사용하니 확실히 아이폰을 사용하기 편해졌다. 이번 글에는 아이폰을 사용하는 분들이 더 편하게 사용할 수 있도록 아이폰 제어 센터에 기본 앱을 등록하고 정리하는 방법을 공유하려고 한다. 아이폰 제어 센터 설정 1. 제어 센터 확인 - 요즘 판매하고 있는 아이폰들은 배경화면에서 위에서 아래로 쓸어내리면 제어 센터가 열린다. - 구형 아이폰들은 아래에서 위로 쓸어 올리면 제어 센터가 열리는 모델들이 있다. - 위 캡처 사진처럼 제어 센터의 아랫부분이 기본 앱을 보이게 설정할 수 있는 부분이다. 2. "설정" 앱 선택
[iPhone] 아이폰 True Tone 및 Night Shift 설정하는 방법 [내부링크]
요즘 아이폰은 "True Tone"과 "Night Shift" 기능을 제공한다. "True Tone"이란, 전자기기를 많이 시청할 때 눈 건강을 지키기 위하여 주변 환경에 맞추어 디스플레이 색감을 자동적으로 주변 빛 색감에 맞춰 조절해 주는 기능이다. 주변의 밝기에 따라 자동으로 센서가 동작하여 화면의 색온도를 조절한다. "Night Shift"란, 사용자가 설정한 시간 동안 디스플레이의 색감을 변경하여 "블루 라이트"를 줄여주는 기능이다. 너무 많은 블루 라이트는 숙면에 방해가 된다고 보통 알려져 있다. 이번 글에는 요즘 아이폰이 제공하는 "True Tone"과 "Night Shift" 기능을 설정하는 방법을 공유하려고 한다. 아이폰 True Tone 설정하는 방법 1. "설정" 앱 선택 2. "디스플레이 및 밝기" 선택 3. "True Tone" 설정 - "True Tone"을 눌러 기능을 활성화 또는 비활성화로 선택할 수 있다. 아이폰 Night Shift 설정하는 방법 1.
[iPhone] 아이폰 키보드 햅틱 진동 설정하는 방법 [내부링크]
아이폰의 기본 설정값으로 사용하면 키보드를 입력할 때 진동(햅틱)이 없다. 키보드를 입력할 때 진동(햅틱) 기능이 있으면 잘못 입력했을 때 쉽게 알 수 있기 때문에 해당 기능을 사용하는 것을 추천한다. 필자도 키보드 진동(햅틱) 기능을 알고 난 후에 계속 진동(햅틱)을 사용하고 있다. 이번 글에는 키보드를 사용할 때 진동(햅틱)을 설정하는 방법을 공유하려고 한다. 아이폰 키보드 햅틱 진동 설정하는 방법 1. "설정" 앱 선택 2. "사운드 및 햅틱" 선택 3. "키보드 피드백" 선택 4. "햅틱"을 선택하여 활성화 - "햅틱"을 활성화하면 보통 키보드 입력 시 진동(햅틱)이 발생된다. - 여기까지 설정했는데 진동(햅틱)이 발생되지 않으면 아이폰에서 진동을 비활성화했을 가능성이 있다. 아래 설정도 이어서 진행하면 된다. 5. "설정" 앱 선택 6. "손쉬운 사용" 선택 7. "터치" 선택 8. "진동"을 선택하여 활성화 - 여기까지 무사히 설정했다면 키보드 입력 시 진동(햅틱)이 느껴
[iPhone] 아이폰 벨소리 변경하는 방법 [내부링크]
아이폰 기본 벨소리로 생활하다 보면 다른 사람과 같은 벨소리가 똑같다 보니 다른 사람의 핸드폰에 전화가 오는 건지 본인 핸드폰에 전화가 오는 건지 헷갈릴 때가 있다. 이러한 이유 때문이나 같은 벨소리를 너무 오래 사용하여 다른 벨소리를 설정하고 싶을 때가 있다. 이번 글에는 아이폰 벨소리를 변경하는 방법을 공유하려고 한다. 아이폰 벨소리 변경하는 방법 1. "설정" 앱 선택 2. "벨소리" 선택 3. 변경하고 싶은 벨소리 선택
[iPhone] 아이폰 뒷면 터치 설정 [내부링크]
아이폰은 뒷면을 터치하여 유용한 기능을 사용하여 활용성을 높일 수 있다. 뒷면을 두 번 또는 세 번 터치하여 미리 설정한 기능을 사용할 수 있다. 이번 글에는 아이폰 뒷면을 두 번 또는 세 번 터치하여 미리 설정한 기능을 사용할 수 있는 방법을 공유하려고 한다. 아이폰 뒷면 터치 설정 1. "설정" 앱 선택 2. "손쉬운 사용" 선택 3. "터치" 선택 4. "뒷면 탭" 선택 5. "이중 탭" 선택 6. 원하는 기능 선택 - 아이폰 뒷면을 두 번 연속 터치했을 때 실행되었으면 하는 기능을 선택한다. - 필자는 아이폰 스크린샷을 사용할 일이 많아 "스크린샷"을 선택했다. 7. "삼중 탭" 선택 8. 원하는 기능 선택 - 아이폰 뒷면을 세 번 연속 터치했을 때 실행되었으면 하는 기능을 선택한다. - 필자는 업무상 카메라를 사용할 일이 많아 "카메라"를 선택했다. 9. 뒷면 탭 기능 설정 확인 - 위와 같이 설정되었을 경우 아이폰 뒷면을 두 번 터치했을 때는 "스크린샷"이 활성화되고 세
[Basics] Banner 설정(Cisco) [내부링크]
Banner 설정 Incoding Bit 설정 conf t default-value exec-character-bits 8 // 8Bit로 인코딩(모든 언어를 표현하기 위해 사용) end 기본적으로 7bit로 인코딩함 7bit 문자 - ASCII(American Standard Code for Information Interchange) - 컴퓨터에서 영문자, 숫자, 그 외 기호를 표현하기 위한 표준 코드임 8bit 문자 - Uni-Code - 각 나라별 언어를 모두 표현하기 위해 생성됨 - 한글도 사용 가능함 - 사용 중인 운영체제, 프로그램, 언어에 관계없이 문자마다 고유한 코드 값을 제공하는 새로운 개념의 코드임 장비 접속 시 Banner 설정 conf t banner motd * ============================================================================ ===============================
[Basics] Telnet 및 SSH 설정(Cisco) [내부링크]
Telnet 설정 및 확인 Telnet 설정 conf t enable password admin // enable 입력 시 설정한 패스워드를 입력해야 함 username admin password admin // Username : admin, password : admin으로 설정함 line vty 0 4 transport input none // 모든 프로토콜 접속 차단 transport input telnet // 텔넷 접속 허용 login local // 텔넷 접속 시 사용자 계정으로 인증함 end Telnet 동작 확인 SSH 설정 및 확인 SSH 설정 conf t enable password admin // enable 입력 시 설정한 패스워드를 입력해야 함 username admin password admin // Username : admin, password : admin으로 설정함 hostname R1 // SSH 키 생성을 위해 Hostname 설정 ip doma
[Basic] IOS 부팅 순서 및 백업/복구 명령어 [내부링크]
IOS 부팅 순서 IOS 부팅 순서 1) Power on 2) ROM에 있는 POST체크 3) ROM에 있는 Bootstrap이 RAM에 loading (Flash에서 OS를 loading하려면 Bootstrap필요) 4) Flash에 있는 OS를 압축 풀며 DRAM으로 loading 5) Flash에 OS가 없을 때 TFTP Server 사용 6) TFTP server에 OS가 있으면 DRAM으로 loading, 없으면 부팅 안 함 7) OS가 정상적으로 부팅되면 NVRAM에 있는 startup-config를 찾고 DRAM에 있는 OS에 적용 8) NVRAM에 startup-config가 없으면 TFTP Server에, 여기도 없으면 Console로 들어가 setup mode로 시작 백업 및 복구 명령어 Running-Config 백업 및 복구 명령어 copy running-config tftp: Address or name of remote host []? 1.1.1.1 // S
[Basics] 사용자 별 권한 설정(Cisco) [내부링크]
사용자 별 권한 설정 사용자 별 권한 설정 conf t username L5 privilege 5 password L5 // Privilege Level 5의 사용자를 생성(계정 : L5/L5) privilege exec level 5 show running-config // exec(Privilege mode)에서 사용할 수 있는 명령어 추가 // Privilege Level 5의 사용자가 "show running-config"의 명령어를 볼 수 있게 해줌 privilege exec level 5 show ip interface brief privilege configure level 5 interface // "configure mode"에서 사용할 수 있는 명령어 추가 end Cisco는 Privilege Level을 0~15까지 정할 수 있음 관리자가 계정 별 Privilege Level을 달리 설정할 수 있음 관리자가 Privilege Level 별 사용할 수 있는 명
[iPhone] 아이폰 수동 업데이트하는 방법 [내부링크]
애플에서 아이폰의 새로운 OS 버전을 배포하면 해당 버전으로 업데이트하는 것이 좋다. 보통 새로운 OS의 버전일수록 성능이 많아지고 보안에 대한 취약성이 보완된다. 만약 오래된 OS를 사용하면 최신 보안 기능을 적용받지 못한다. 이번 글에는 아이폰 OS 업데이트하는 방법을 공유하려고 한다. 아이폰 수동 업데이트하는 방법 1. "설정" 앱 열기 2. "일반" 선택 3. "소프트웨어 업데이트" 선택 4. "다운로드 및 설치" 선택 5. 아이폰 비밀번호 입력 6. 이용 약관 "동의" 선택 7. 이용 약관 "동의" 선택 8. "셀룰러 데이터 사용" 선택 - 사용할 수 있는 데이터양이 적을 경우, "셀룰러 데이터 사용"이 아닌 "셀룰러 데이터 사용 안 함"을 선택하여 데이터가 아닌 와이파이를 사용하여 업데이트를 진행한다. 9. "업데이트 요청함" 확인 10. "업데이트 진행도" 확인 11. "지금 설치" 선택 11. "지금 설치" 선택 - 소프트웨어 업데이트를 나중에 해야 될 상황일 경우,
[iPhone] 아이폰 자동 업데이트하는 방법 [내부링크]
애플에서 아이폰의 최신 OS 버전을 공유하면 해당 버전으로 바로 업데이트하는 것이 좋다. 보통 최신 OS의 버전일수록 성능이 많아지고 보안에 대한 취약성이 보완된다. 만약 예전에 공유된 OS를 사용하면 최신 보안 기능을 적용받지 못해 보안에 취약한 상태가 된다. 애플에서 최신 OS를 공유할 때마다 수동으로 업데이트하는 게 생각보다 귀찮을 때가 많다. 이번 글에는 아이폰 OS 자동 업데이트하는 방법을 공유하려고 한다. 아이폰 자동 업데이트하는 방법 1. "설정" 앱 열기 2. "일반" 선택 3. "소프트웨어 업데이트" 선택 4. "자동 업데이트" 선택 5. 자동 업데이트 설정 - "IOS 업데이트 다운로드" 활성화 - "IOS 업데이트 설치" 활성화 아이폰 자동 업데이트 설정이 끝났다. 애플에서 최신 OS를 공유하면 자동으로 업데이트를 진행한다.
[iPhone] 아이폰 배터리 잔량 표시하는 방법 [내부링크]
삼성의 갤럭시 스마트폰이나 다른 안드로이드 스마트폰은 화면 상단에 있는 배터리 아이콘에 배터리 잔량이 표시되어 이용자가 배터리 잔량을 쉽게 확인할 수 있다. 하지만 아이폰 IOS 16이전까지는 화면 상단에 있는 배터리 아이콘에 배터리 잔량이 정확히 표시되지 않았다. 아이폰 IOS16부터는 설정을 통해 화면 상단에 있는 배터리 아이콘에 배터리 잔량을 숫자로 표시하여 사용자가 배터리 잔량을 보다 정확히 파악할 수 있게 되었다. 이번 글에는 아이폰 배터리 잔량을 표시하는 방법을 공유하려고 한다. 아이폰 배터리 잔량 표시하는 방법 1. 설정 전 배터리 아이콘 모양 확인 2. "설정" 앱 선택 3. "배터리" 선택 4. "배터리 잔량 표시(%)" 선택 - "배터리 잔량 표시(%)"을 선택하여 활성화시키면 화면 상단에 있는 배터리 아이콘에 숫자로 배터리 잔량을 표시해 준다.
[iPhone] 아이폰 배터리 수명 확인하는 방법 [내부링크]
스마트폰뿐만 아니라 배터리가 장착된 전자제품을 사용하면 배터리의 수명이 줄어든다. 배터리 수명이 줄어들면 완충 후 실제 사용할 수 있는 배터리 용량이 줄어들게 된다. 때문에 배터리 수명이 일정 수준 이하가 되면 배터리 교체하는 것을 권장한다. 아이폰 배터리 수명 확인하는 방법 1. "설정" 앱 선택 2. "배터리" 선택 3. "배터리 성능 상태 및 충전" 선택 4. "성능 최대치" 수치 확인 - "성능 최대치" 수치를 확인한다. - 최대 배터리 용량은 아이폰 배터리 용량을 새 배터리와 비교하여 측정한 것이다. - 배터리 성능이 83%이면 실제 배터리를 완충했을 때 실질적으로 배터리는 83% 충전된 만큼의 에너지를 사용할 수 있다는 의미이다. - 정상 배터리는 충전 사이클 500번을 반복했을 때 원래 용량의 최대 80%를 보유하도록 설계되었다고 한다.
[iPhone] 아이폰 자동 완성 및 자동 수정 끄는 방법 [내부링크]
아이폰을 초기 설정값으로 사용하는 분들이 아이폰 키보드를 사용할 때 원하지 않는데 자동적으로 단어가 완성되고 자동적으로 수정이 되는 상황이 많았을 것이다. 이번 글에는 위와 같은 불편함을 없애기 위하여 아이폰 키보드의 자동 완성 및 자동 수정을 비활성화하는 방법을 공유하려고 한다. 아이폰 자동 완성 및 자동 수정 끄는 방법 1. "설정" 앱 선택 2. "일반" 선택 3. "키보드" 선택 4. "자동 수정" 및 "자동 완성" 비활성화 - "자동 수정" 및 "자동 완성"을 비활성화하면 아이폰 키보드를 사용할 때 텍스트가 자동으로 수정이 되거나 자동으로 단어가 완성되는 상황을 방지할 수 있다.
[ACL] RACL/DACL 명령어(Cisco) [내부링크]
RACL(Reflexive Access Control List) 설정 명령어 RACL 설정 명령어 conf t ip access-list extended [ACL_NAME1] // "ACL_NAME1"이라는 이름으로 Named ACL 생성 permit tcp any any reflect [RACL] // "reflect" 뒤에 사용할 이름을 지정 permit udp any any reflect [RACL] permit icmp any any reflect [RACL] permit ip any any end conf t ip access-list extended [ACL_NAME2] // "ACL_NAME2"라는 이름으로 Named ACL 생성 evaluate [RACL] // 위에 설정한 ACL에 "reflect" 뒤에 사용했던 이름을 사용 // 출발지/목적지 IP 반전 end conf t interface serial 1/0 ip access-group [ACL_NAME1] out
[ACL] ACL Case Study - RACL(Cisco) [내부링크]
RACL Case Study(Cisco) 작업 개요 목적 RACL 설정하고 동작을 확인한다. 일자 2023.02.07(화) 테스트 내용 01. RACL Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Telnet 설정 07. RACL 설정 08. RACL 설정 확인 09. RACL 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS / 3745 C3745-ADVENTERPRISEK9_SNA-M, Version 12.4(11)T 결과 RACL을 설정 및 적용한 후, 내부 → 외부로 데이터를 송신할 때 Access-List에 임의의 List가 추가되어 정상적으로 통신이 이루어짐 RACL을 이용한 통신이 모두 끝나면 임의의 Access-List가 사라짐 01. RACL Case Study - 구성도 02. 기본 인터페이스 설정 R1 conf t interface loo
[ACL] ACL Case Study - DACL(Cisco) [내부링크]
DACL Case Study(Cisco) 작업 개요 목적 DACL 설정하고 동작을 확인한다. 일자 2023.02.07(화) 테스트 내용 01. DACL Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Telnet 설정 07. DACL 설정 08. DACL 설정 확인 09. DACL 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS / 3745 C3745-ADVENTERPRISEK9_SNA-M, Version 12.4(11)T 결과 DACL을 설정한 후 "외부→내부"로 통신을 하려면 DACL을 설정한 장비에게 인증을 받아야 함 DACL을 설정한 장비에게 인증을 받으면 DACL을 설정한 장비에 임의의 Access-List가 생성됨 - 임의의 Access-List는 일정 시간 이후에 사라짐 01. DACL Case Study - 구성도 02. 기본 인터페이스 설정 R
[ACL] CBAC 개요 및 동작 원리 [내부링크]
CBAC(Context-Based Access Control) CBAC(Context-Based Access Control) Stateful 기반으로 동작함 여러 개의 세션을 사용하는 애플리케이션에 대해서도 Stateful 기능을 지원함 CBAC는 Permit 정책만 가능하여 보통 단독으로 사용하지 않음 - 내부에서 출발하는 것은 CBAC를 먼저 보고 외부에서 오는 것은 ACL를 먼저 적용됨 ACL에서 사용하는 L3/L4의 트래픽을 제어할 뿐만 아니라 다양한 응용 계층의 트래픽을 제어함 내부에서 외부로 패킷 발생 시 허용하는 임시 ACL이 생성되며 이로 인해 돌아오는 패킷이 허용됨 일반적으로 CBAC는 내부에서 출발한 패킷이 돌아올 때 허용하는 역할을 하므로 허용하지 않을 나머지 패킷들을 거부하는 ACL과 함께 사용함 CBAC 동작 방식 CBAC는 "내부→외부"로 나간 패킷들이 돌아올 때 허용하는 역할을 하므로 차단할 나머지 패킷들을 차단하는 ACL을 함께 사용함 인터
[ACL] CBAC 명령어(Cisco) [내부링크]
CBAC(Context-Based Access Control) 명령어 CBAC 기본 설정 명령어 conf t ip inspect name [CBAC_NAMA] tcp // 내부→외부로 나갈때 TCP 패킷은 임시 ACL을 생성하여 상단의 추가함 // 외부→내부로 응답이 올 땐 임시 ACL을 보고 허용됨 ip inspect name [CBAC_NAMA] udp ip inspect name [CBAC_NAMA] icmp end conf t interface fa1/0 ip inspect [CBAC_NAME] out // 인터페이스에 CBAC Outbound적용 no ip unreachables // 외부→내부로 ICMP 패킷을 송신하면 "unreachables"가 뜨는데 보안상 취약해 "Time Out"이 뜨게 설정 end CBAC TCP 중 HTTP만 허용하는 명령어 conf t ip inspect name [CBAC_NAME] http audit-trail on // 내부에서 외부로
[ACL] ACL Case Study - CBAC(Cisco) [내부링크]
CBAC Case Study(Cisco) 작업 개요 목적 CBAC 설정하고 동작을 확인한다. 일자 2023.02.09(목) 테스트 내용 01. CBAC Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Telnet 설정 07. CBAC 설정 08. CBAC 설정 확인 09. CBAC 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS / 3745 C3745-ADVENTERPRISEK9_SNA-M, Version 12.4(11)T 결과 CBAC를 설정 및 적용한 후, "내부 → 외부"로 데이터를 송신할 때 임의의 List가 추가되어 정상적으로 통신이 이루어짐 CBAC의 이용이 끝나면 해당 임의의 List가 사라짐 CBAC는 보통 단독으로 사용하지 않고 다른 ACL과 함께 사용함 "외부 → 내부"로 먼저 패킷을 전송할 때는 CBAC가 아닌 일반 ACL List를 참
[Basic] 기본 명령어(Cisco) [내부링크]
기본 명령어 기본 설정 명령어 conf t line console 0 exec-timeout 0 0 // Timeout 없이 계속 사용 logging synchronous // 로그메시지와 입력 명령어를 동기화하는 명령어 exit ip domain-name ANT_CHOI // 장비에 "ANT_CHOI"라는 도메인 설정 no ip domain-lookup // 명령어 오타 시 DNS 서버를 찾는 과정을 없애기 위해 설정 end conf t hostname SW1 enable password PASSWORD // Privileged mode로 진입 시 사용할 비밀번호 설정 enable secret PASSWORD // Privileged mode로 진입 시 사용할 비밀번호 설정(암호화) ip default-gateway 1.1.1.1 // Default-Route 설정 end enable // User Mode → Privileged mode로 변경 conf t // Privilege
[ACL] ACL Case Study - VTY ACL(Cisco) [내부링크]
VTY ACL Case Study(Cisco) 작업 개요 목적 VTY ACL 설정하고 동작을 확인한다. 일자 2023.02.05(일) 테스트 내용 01. VTY ACL Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Telnet 설정 07. Telnet 동작 확인 08. ACL 설정 09. ACL 설정 확인 10. ACL 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS / 3745 C3745-ADVENTERPRISEK9_SNA-M, Version 12.4(11)T 결과 ACL을 VTY에 적용하면 일반적인 트래픽은 영향을 받지 않음 01. VTY ACL Case Study - 구성도 02. 기본 인터페이스 설정 R1 conf t interface loopback0 ip address 1.1.1.1 255.255.255.255 no shutdown exit inte
[ACL] RACL/DACL 개요 및 동작 원리 [내부링크]
RACL(Reflexive Access Control List) RACL(Reflexive Access Control List) "내부 → 외부"로 데이터가 전송될 경우 임시 Access-List가 생성되어 외부에서 돌아오는 트래픽을 허용함 S-IP, D-IP와 S-Port, D-Port 정보를 확인한 후 응답 트래픽을 수신하기 위해 임시 ACL을 생성함 - 임시 ACL 이란, Source와 Destination의 정보가 역으로 변경된 것임 - Evaluate 기능 "내부 → 외부"로 전송되는 프로토콜을 정책적으로 정의함 "내부 → 외부"로 제한 없이 외부와 통신이 가능하고 "외부 → 내부"로의 접속은 차단할 수 있음 기능적으로 일반 ACL의 Established와 유사하지만 Established는 TCP만 제어할 수 있지만 RACL은 TCP/UDP를 제어할 수 있음 RACL을 사용할 경우 Extended Named Access-List만 사용할 수 있음 FTP처럼 포트
[ACL] 명령어(Cisco) [내부링크]
ACL 설정 명령어 Standard Access List 설정 conf t access-list [access-list-number] [permit | deny] [s-ip] [wildcard mask] // 해당 조건에 맞는 패킷을 Permit할지 Deny할지 결정함 end conf t interface fa0/0 [protocol] access-group [access-list-number] [in|out] // 미리 정의한 ACL을 인터페이스에 정의함 end Extended Access List 설정 conf t access-list [access-list-number] [permit|deny] [protocol] [s-ip] [source-wildcard] [operator port] [d-ip] [destination-wildcard] [operator port] [established] [log] // 해당 조건에 맞는 패킷을 Permit할지 Deny할지 결정함 end c
[ACL] ACL Case Study - Standard ACL(Cisco) [내부링크]
Standard ACL Case Study(Cisco) 작업 개요 목적 Standard ACL 설정하고 동작을 확인한다. 일자 2023.02.04(토) 테스트 내용 01. Standard ACL Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. ACL 설정 07. ACL 설정 확인 08. ACL 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS / 3745 C3745-ADVENTERPRISEK9_SNA-M, Version 12.4(11)T 결과 Standard ACL을 설정하여 특정 S-IP를 가진 장비를 차단하거나 허용할 수 있음 01. Standard ACL Case Study - 구성도 02. 기본 인터페이스 설정 R1 conf t interface loopback0 ip address 1.1.1.1 255.255.255.255 no shutdown exit
[ACL] ACL Case Study - Extended ACL(Cisco) [내부링크]
Extended ACL Case Study(Cisco) 작업 개요 목적 Extended ACL 설정하고 동작을 확인한다. 일자 2023.02.04(토) 테스트 내용 01. Extended ACL Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Telnet 및 SSH 설정 07. Telnet 및 SSH 동작 확인 08. ACL 설정 09. ACL 설정 확인 10. ACL 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS / 3745 C3745-ADVENTERPRISEK9_SNA-M, Version 12.4(11)T 결과 Extended ACL을 설정하여 특정 서비스를 차단하거나 허용할 수 있음 - 서비스란, 특정 S-IP, D-IP, Protocol, Port 등이 있음 Access-List에서 Permit 설정을 하지 않으면 기본적으로 Deny됨 01. Exte
[ACL] ACL Case Study - Named ACL(Cisco) [내부링크]
Named ACL Case Study(Cisco) 작업 개요 목적 Named ACL 설정하고 동작을 확인한다. 일자 2023.02.05(일) 테스트 내용 01. Named ACL Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Telnet 설정 07. Telnet 동작 확인 08. ACL 설정 09. ACL 설정 확인 10. ACL 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS / 3745 C3745-ADVENTERPRISEK9_SNA-M, Version 12.4(11)T 결과 Extended ACL을 설정하여 특정 서비스를 차단하거나 허용할 수 있음 - 서비스란, 특정 S-IP, D-IP, Protocol, Port 등이 있음 Access-List에서 Permit 설정을 하지 않으면 기본적으로 Deny됨 01. Named ACL Case Study - 구성
[ACL] ACL 개요 및 종류 [내부링크]
ACL(Access Control List) 개요 ACL(Access Control List) 개요 정책으로 데이터의 접근을 결정하는 기술 - 네트워크의 보안성을 향상시킬 수 있음 - 불필요한 트래픽을 차단할 수 있음 트래픽을 제어하는 방식으로 어떤 패킷을 어떤 방식으로 제어할 것인지 정의함 각 패킷을 검사해야하므로 라우터의 성능이 저하될 수 있음 ACL을 사용하여 라우팅을 조절할 수 있음 라우터에 설정되지만 "Layer 7"부분도 관리하기 때문에 "Layer 3"까지라고 단정할 수 없음 - ACL만으로 "Layer 7"까지 완벽히 막을 수 없어 방화벽 등 보안장비가 필요함 ACL은 패킷을 허용할 것인지 정의하는 기능임 - ACL을 적용하지 않으면 아무 변화가 없다는 것을 주의 해야함 ACL 암묵적 Deny Access-List에 매칭되는 것이 없으면 "암묵적인 Deny"가 발생됨 - Access-List의 마지막에 Deny List가 생략되어 있음 암묵적 Deny가
[ACL] ACL Logic [내부링크]
ACL First-Match Rule Logic ACL First-Match Rule Logic 여러 개의 정책 중에 가장 먼저 기준이 매칭되는 정책에 따라 패킷이 처리되는 것 First-Match Rule에 따라 Access-List 생성 시 좁은 범위가 먼저 선언되어야 함 - 특정 대상에 대해 Permit 정책을 먼저 선언하는 것 Inbound와 Outbound Logic Inbound Logic ACL을 Inbound 정책을 적용했으면 라우팅 테이블 참조하기 전에 ACL List를 먼저 참조함 장비의 인터페이스로 패킷이 들어오는 경우 설정 패킷이 장비 내부로 들어올 때 필터링 여부를 결정 ACL이 설정되어 있을 때 장비 인터페이스로 패킷이 들어올 경우 패킷 정보와 ACL 설정 내용을 비교하여 통과 여부를 결정함 Outbound Logic ACL을 Outbound 정책을 적용했으면 라우팅 테이블 먼저 참조하고 ACL List를 참조함 장비의 인터페이스에서 패킷이 나
[Basics] Wildcard Mask 개념 및 계산 방법 [내부링크]
Wildcard Mask 개념 Wildcard Mask 개념 특정 비트의 검사 여부를 결정하기 위해 사용함 Subnet Mask와 관련이 없음 Subnet Mask는 IP와 AND 연산을 하여 N-ID를 정하기 위해 사용함 Subnet Mask와 달리 이진수로 나타낼 때 0 다음 1이 와도 상관없음 Wildcard Mask 검사 bit 0 - Wildcard Mask 0bit와 대응하는 bit 값을 검사하여 같은 bit만 통과됨 - Wildcard Mask 값이 0.0.0.0은 하나를 의미하므로 "host"로도 사용됨 - "172.30.16.29 0.0.0.0" = "host 172.30.16.29" bit 1 - Wildcard Mask 1bit와 대응하는 bit 값을 무시함 - WIldcard Mask 값이 255.255.255.255는 모든 사람의 의미이므로 "any"로도 사용됨 - "0.0.0.0 255.255.255.255" = "any" Wildcard Mask 계
[NAT] NAT Case Study - HSRP를 이용한 Stateful NAT(Cisco) [내부링크]
Stateful NAT Case Study(Cisco) 작업 개요 목적 Stateful NAT 설정하고 동작을 확인한다. 일자 2023.02.01(수) 테스트 내용 01. Stateful NAT Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. EIGRP 설정 05. EIGRP 설정 확인 06. 공인 IP 생성 후 라우팅 설정 07. 공인 IP 생성 및 라우팅 설정 상태 확인 08. EIGRP Load Balancing 변경 설정 09. EIGRP Load Balancing 변경 설정 확인 10. HSRP 설정 11. HSRP 동작 확인 12. Stateful NAT 설정 13. Stateful NAT 동작 과정 14. Main Route 절체 후 Stateful NAT 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS / 3745 C3745-ADVENTERPRISEK9_SNA-M, Version 12.4(11)T
[Windows 11] Windows 마우스 속도 조절 및 위치 표시하는 방법 [내부링크]
컴퓨터를 쓰는 사용자라면 마우스의 속도가 빠르거나 느려 컴퓨터를 사용하기에 불편했던 기억이 있을 것이다. 또한, 마우스의 현재 위치를 정확히 알지 못해 화면에 있는 마우스 위치를 찾아 헤맸던 적이 있을 것이다. 이번 글에는 윈도우 컴퓨터에서 마우스 속도 조절을 하는 방법과 마우스의 현재 위치를 표시하는 방법을 공유하려고 한다. Windows 마우스 속도 조절 1. "설정" 창 → "Bluetooth 및 장치" 탭 → "마우스" 열기 - "Windows + I"를 눌러 "설정" 창을 연다 - "Bluetooth 및 장치" 선택 →"마우스" 선택 2. "마우스 포인터 속도" 변경 - "마우스 포인터 속도"부분을 변경하여 마우스의 속도를 조절한다. Windows 마우스 위치 표시 1. "설정" 창 → "Bluetooth 및 장치" 탭 → "마우스" 열기 - "Windows + I"를 눌러 "설정" 창을 연다 - "Bluetooth 및 장치" 선택 →"마우스" 선택 2. "더 많은 마우스
[NAT] NAT Case Study - Mapping-ID를 이용한 Stateful NAT(Cisco) [내부링크]
Stateful NAT Case Study(Cisco) 작업 개요 목적 Stateful NAT 설정하고 동작을 확인한다. 일자 2023.02.01(수) 테스트 내용 01. Stateful NAT Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. EIGRP 설정 07. EIGRP 설정 확인 08. 공인 IP 생성 후 라우팅 설정 09. 공인 IP 생성 및 라우팅 설정 상태 확인 10. EIGRP Load Balancing 변경 설정 11. EIGRP Load Balancing 변경 설정 확인 12. Stateful NAT 설정 13. Stateful NAT 동작 확인 ① 14. Stateful NAT 동작 확인 ② 15. Main Route 절체 후 Stateful NAT 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS / 3745 C3745-ADVENTERPRISE
[NAT] NAT Case Study - Dynamic NAT - Load Balancing(Cisco) [내부링크]
Dynamic NAT - Load Balancing Case Study(Cisco) 작업 개요 목적 Dynamic NAT에서 Load Balancing이 되도록 설정하고 동작을 확인한다. 일자 2023.01.30(월) 테스트 내용 01. Dynamic NAT Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Default-Route 설정 07. Default-Route 설정 확인 08. Telnet 설정 09. Dynamic NAT - Load Balancing 설정 10. Dynamic NAT - Load Balancing 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS / 7206VXR C7200-ADVIPSERVICESK9-M / Version 15.2(4)S5 결과 Dynamic NAT를 이용하여 Load Balancing을 이용할 수 있음 외부→내부로
[NAT] NAT Case Study - Dynamic NAT(Cisco) [내부링크]
Dynamic NAT Case Study(Cisco) 작업 개요 목적 Dynamic NAT를 설정하고 동작을 확인한다. 일자 2023.01.31(화) 테스트 내용 01. Dynamic NAT Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Default-Route 설정 07. Default-Route 설정 확인 08. Dynamic NAT 설정 - ACL 09. Dynamic NAT 설정 - Route-Map 10. Dynamic NAT 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS / 7206VXR C7200-ADVIPSERVICESK9-M / Version 15.2(4)S5 결과 Dynamic NAT를 이용하여 주소변환을 할 수 있음 Dynamic NAT에 "overload" 옵션을 추가하면 NAT-PAT로 동작함 01. Dynamic NAT Case S
[NAT] NAT Case Study - Stateless NAT(Cisco) [내부링크]
Stateless NAT Case Study(Cisco) 작업 개요 목적 Stateless NAT 설정하고 동작을 확인한다. 일자 2023.01.31(화) 테스트 내용 01. Stateless NAT Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. EIGRP 설정 05. EIGRP 설정 확인 06. 공인 IP 생성 후 라우팅 설정 07. 공인 IP 생성 및 라우팅 설정 상태 확인 08. VRRP 설정 09. VRRP 동작 확인 10. Stateless NAT 설정 11. Stateless NAT 동작 확인 12. Gateway 절체 후 Stateless NAT 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS / 7206VXR C7200-ADVIPSERVICESK9-M / Version 15.2(4)S5 결과 Static NAT와 게이트웨이 이중화 프로토콜을 이용하여 Stateless NAT(Redundancy
[NAT] NAT 개요 및 종류 [내부링크]
NAT(Network Address Translation) 개요 NAT Overview NAT는 공인 IPv4의 부족으로 개발됨 사설 IP를 "Inside" 또는 "Trust"라고 부름 공인 IP를 "Outside" 또는 "Untrust"라고 부름 NAT란 패킷의 IP 헤더 부분에 있는 S-IP나 D-IP를 변경하는 기술임 - NAT는 "주소 변환 기술"임 - NAT는 "사설 IP → 공인 IP로 변경해 주는 기술"이라고 하면 적절한 정의가 아님 - 보통 편의상 NAT는 "사설 IP → 공인 IP로 변경해 주는 것"이라고 설명함 주로 Stub Domain에서 사용됨 - Stub Domain 이란, 외부 네트워크로 가는 경로가 단일 경로인 Domain을 뜻함 NAT의 목적 - IP 변환 - 보안성 강화 (IP가 변환되기 때문) NAT는 IP를 변환하는 기술이기 때문에 전용 테이블이 있어야 함 - NAT 테이블이 없으면 외부망과 정상적으로 통신하지 못함 NAT Redunda
[NAT] NAT 동작 과정 [내부링크]
Static NAT 동작 과정 사설 IP → 공인 IP로 변경하는 정보를 NAT 테이블에 정적으로 기록함 Static NAT 동작 과정 Static NAT는 미리 사설 IP와 공인 IP를 매핑 시켰기 때문에 다른 내부 호스트들은 외부망과 통신을 할 수 없음 - 정해진 특정 사설 IP를 가진 호스트만 정해진 공인 IP를 이용하여 외부망과 통신할 수 있음 Dynamic NAT 동작 과정 NAT 장비는 내부 호스트가 외부로 송신하려는 데이터를 수신하면 Pool을 이용하여 "사설 IP → 공인 IP"로 변환한 후 외부망으로 전송함 사설 IP → 공인 IP로 변경하는 정보를 NAT 테이블에 동적으로 기록함 - 사설 IP → 공인 IP로 변환시킨 정보를 NAT Table에 120s간 저장함 외부망에서 응답이 돌아오면 NAT 테이블에 있는 정보를 확인하여 D-IP를 사설 IP로 변환한 후, 내부망으로 송신함 Dynamic NAT(Basic) 동작 과정 주소 변환 시 3계층 주소를 사용
[NAT] 명령어(Cisco) [내부링크]
NAT 설정 명령어 Static NAT 설정 conf t ip nat inside source static [local-ip] [global-ip] // 내부 "Inside Local"과 "Inside Global" 주소 간의 정적 주소 변환 관계를 설정 // 어떤 공인 IP를 어떤 사설 IP로 사용할 것인지 정함.(사설 IP가 사용할 공인 IP를 설정) // Local-IP(Inside Local) : 변경 전 사설 IP // Global-IP(Outside Local) : 변경 후 공인 IP end conf t interface fa0/0 ip nat inside // 내부망 방향의 인터페이스에 적용 (내부 인터페이스 지정) ip nat outside // 외부망 방향의 인터페이스에 적용 (외부 인터페이스 지정) end Dynamic NAT 설정 conf t ip nat pool [name] [start-ip] [end-ip] [netmask Netmask | prefix-len
[NAT] NAT Case Study - Static NAT(Cisco) [내부링크]
Static NAT Case Study(Cisco) 작업 개요 목적 Static NAT를 설정하고 동작을 확인한다. 일자 2023.01.29(일) 테스트 내용 01. Static NAT Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Default-Route 설정 07. Default-Route 설정 확인 08. Static NAT 설정 09. Static NAT 설정 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS / 7206VXR C7200-ADVIPSERVICESK9-M / Version 15.2(4)S5 결과 Static NAT는 내부망↔외부망의 통신이 없어도 NAT 테이블이 유지됨 Static NAT는 하나의 공인 IP는 하나의 사설 IP만 매핑 시킬 수 있음 Static NAT는 NAT 테이블을 유지하므로 외부망→내부망으로 접근이 가능함 01. Stat
[NAT] NAT Case Study - Static PAR NAT(Cisco) [내부링크]
Static PAR NAT Case Study(Cisco) 작업 개요 목적 Static PAR NAT(PAR-Port Address Redirection)를 설정하고 동작을 확인한다. 일자 2023.01.30(월) 테스트 내용 01. Static PAR NAT Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Default-Route 설정 07. Default-Route 설정 확인 08. Telnet 설정 09. HTTP Server 설정 10. Static NAT 설정 11. Static NAT 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS / 7206VXR C7200-ADVIPSERVICESK9-M / Version 15.2(4)S5 결과 Static NAT에 포트 번호를 추가하여 하나의 공인 IP로 내부망의 여러 장비들이 외부와 통신이 가능함 01. Sta
[Windows 11] Windows 노트북 배터리 수명 확인 및 관리하는 방법 [내부링크]
노트북 배터리의 수명은 사용할 수로 효율성이 점점 떨어진다. 배터리를 충전, 사용, 방전이 되면서 배터리의 전체 충전 용량이 설계 용량보다 줄어들게 되는 것이다. 배터리의 수명이 떨어져 배터리를 완충하더라도 사용시간이 짧아진다. 이번 글에는 노트북 배터리의 수명 상태를 확인할 수 있는 방법과 배터리를 효율적으로 관리하는 방법을 공유하려고 한다. Windows 노트북 배터리 수명 확인하는 방법 1. "명령 프롬프트" 창 열기 - "Windows + R"를 눌러 실행 창을 연다. - "cmd"입력 → "확인" 선택하면 "명령 프롬프트" 창이 열린다. 2. "배터리 보고서" 저장 - "powercfg /batteryreport"를 입력하면 "배터리 사용 시간 보고서"가 "HTML" 확장자 문서로 저장된다. 명령어 powercfg /batteryreport - "배터리 사용 시간 보고서"는 "HTML" 확장자로 저장되기 때문에 추가적인 프로그램 필요 없이 웹으로 확인할 수 있다. - "배터
[Windows 11] Windows 로그인 비밀번호 설정/변경/제거하는 방법 [내부링크]
Windows 10 이상에서는 보안을 위해 윈도우 설치 시 기본 관리자 계정에 패스워드 등록을 의무화하고 있다. 간단하지만 계정에 패스워드만 설정해도 다른 사람들이 본인의 컴퓨터에 접근하는 것을 방지할 수 있다. 기본적으로 같은 패스워드로 오래 사용하는 것은 보안에 취약하므로 패스워드를 변경하는 것을 추천한다. 이번 글에는 Windows 로그인 시 사용하는 비밀번호를 생성, 변경, 제거하는 방법을 공유하려고 한다. Windows 로그인 비밀번호 생성하는 방법 1. "설정" 창 열기 - "Windows + I"를 눌러 설정 창을 연다. 2. "계정" → "로그인 옵션" 열기 - "계정" 선택 → "로그인 옵션" 선택 3. "암호" 추가하기 - "암호"를 선택한다. - 만약 "암호"가 아닌 "PIN"을 사용하려 한다면 "PIN"을 선택하여 비밀번호를 추가하면 된다. - "추가"를 선택한다. - 추가하려는 암호를 기재한 다음 "다음"을 누른다. - "마침"을 누르면 암호 생성이 완료된다.
[Windows 11] Windows 지문 인식 설정/추가/제거하는 방법 [내부링크]
윈도우 10 이상에서는 보안을 위해 윈도우 설치 시 기본 관리자 계정에 패스워드 등록을 의무화하고 있다. 간단하지만 계정에 패스워드만 설정해도 다른 사람들이 본인의 컴퓨터에 접근하는 것을 방지할 수 있다. 그렇지만 보통 로그인할 때마다 비밀번호를 입력하는 것이 불편하다고 느끼는 사람이 많다. 이럴 때 비밀번호 대신 "지문 인식"이나 "얼굴 인식"을 이용하여 비밀번호보다 편한 방법으로 보안을 높일 수 있다. 요즘 노트북은 보통 "지문 인식"이나 "얼굴 인식" 기능이 기본적으로 제공되고 있다. 데스크톱같이 기본적으로 "지문 인식"이나 "얼굴 인식" 기능이 기본적으로 제공되지 않는 컴퓨터는 "지문 인식" 기능을 지원하는 USB나 "얼굴 인식"을 지원하는 웹캠을 구매 후 연결하면 생체 인식 기능을 사용할 수 있다. 이번 글에는 윈도우 로그인 시 지문 인식을 사용할 수 있게 "지문 인식" 생성, 추가, 제거하는 방법을 공유하려고 한다. Windows 지문 인식 설정하는 방법 1. "설정" 창
[Windows 11] Windows 부팅 USB 만드는 방법 [내부링크]
데스크톱이나 노트북을 처음 구입하여 윈도우를 설치할 때나 윈도우 운영체제를 변경, 재설치를 할 때 윈도우 부팅 USB가 있어야 한다. 윈도우 10과 윈도우 11은 부팅 USB를 만드는 방법이 동일하다. 이번 글에는 윈도우 부팅 USB를 만드는 방법을 공유하려고 한다. 부팅 USB를 만들기 위해서 반드시 8GB 이상의 USB가 있어야 한다. 부팅 USB를 만들면 해당 USB는 포맷이 되므로 중요한 자료가 있다면 반드시 먼저 백업을 받아야 한다. Windows 부팅 USB 만드는 방법 1. "Windows 설치 미디어" 실행 파일 다운로드 - 구글 검색창에 "윈도우 부팅 USB"를 검색한 뒤 Microsoft 홈페이지로 접속한다. - 부팅 USB를 생성할 운영체제를 선택한다. - 이번 글에는 윈도우 11의 부팅 USB를 만드는 방법을 고유하는 것이므로 "윈도우 11"을 클릭한다. - "윈도우 11 설치 미디어 만들기" 부분의 "지금 다운로드"를 클릭하면 실행파일을 다운로드 받을 수 있다
[Windows 11] Windows ISO 파일 만드는 방법 [내부링크]
ISO 파일이란 - ISO 이미지를 이용하여 CD 또는 DVD를 굽기 위해 사용한다. - ISO 파일은 프로그램의 모든 파일이 하나의 ISO 파일 안에 포함되어 있어 공유하기 편해 많이 사용된다. - ISO 이미지 안에 있느 파일은 압축되지 않는다. - ISO 파일은 가상화 프로그램에서 운영체제를 설치할 때에도 많이 사용된다. 이번 글에는 Windows ISO 파일을 만드는 방법을 공유하려고 한다. 윈도우 10의 ISO 파일을 생성하는 방법은 윈도우 11의 ISO 파일을 생성하는 방법과 동일하다. Windows 부팅 USB 만드는 방법 1. "Windows 설치 미디어" 실행 파일 다운로드 - 구글 검색창에 "윈도우 11 iso"를 검색한 뒤 Microsoft 홈페이지로 접속한다. - "Windows 11 설치 미디어 만들기" 부분의 "지금 다운로드"를 클릭하면 실행파일을 다운로드 받을 수 있다. - 다운로드 받은 실행 파일은 연다. - 브라우저마다 다운로드 되는 경로가 다를 수
[Windows 11] Windows 수동 업데이트하는 방법 [내부링크]
윈도우 운영체제를 사용하는 사용자들은 주기적으로 윈도우 업데이트를 하는 것이 좋다. 윈도우 업데이트를 하지 않으면 취약점으로 드러난 문제점들을 보안하지 못하기 때문이다. 보통 일반 사용자들은 윈도우 업데이트를 하는 이유가 기능을 추가하거나 제거하는 용도로만 알고 있다. 실제로 기능을 변경하는 것 이외에 개발자들이 취약점을 발견하면 이 취약점을 보안하여 운영체제를 배포하는데 해당 운영체제는 사용자가 업데이트를 해줘야 취약점을 보안한 소프트웨어를 사용할 수 있다. 이번 글에는 수동으로 윈도우 업데이트를 하는 방법을 공유하려고 한다. Windows 수동 업데이트하는 방법 "설정" 창 열기 - "Windows + I"를 눌러 "설정" 창을 연다 - "Windows 업데이트" 선택 → "업데이트 확인" 선택 - 업데이트를 해야 될 항목이 있는지 확인한다. - 자동으로 업데이트를 해야 할 항목들을 다운로드 받는다. - 업데이트를 해야 할 모든 항목들을 다운로드 받으면 "지금 다시 시작"을 누른
[Windows 11] Windows 컴퓨터 사양/윈도우 버전 확인하는 방법 [내부링크]
컴퓨터를 사용하다 보면 CPU, RAM, SSD, HDD, 그래픽 카드 등 컴퓨터의 사양을 알아야 할 때가 있다. 이번 글에는 컴퓨터 사양과 윈도우 버전을 확인하는 방법을 공유하려고 한다. 컴퓨터 사양을 확인하는 세 가지 방법과 윈도우 버전을 확인하는 한 가지 방법을 공유한다. Windows 컴퓨터 사양 확인하는 방법 ① 1. "작업 관리자"를 이용하여 컴퓨터 사양 확인하기 - "Control + Shift + Esc"를 누르면 "작업 관리자" 창이 열린다. - 추가 프로그램 설치 없이 가장 간단하게 확인할 수 있는 방법이라고 판단된다. - CPU의 모델명, 이용률, 속도, 캐시 용량, 코어, 논리 프로세서 등 CPU에 대한 정보를 확인할 수 있다. - CPU 이용률을 그래프로 간략하게 확인할 수 있다. - RAM의 실제 총 용량, 사용 중인 용량, 사용 가능한 용량, 속도 등 RAM에 대한 정보를 확인할 수 있다. - RAM 사용률을 그래프로 간략하게 확인할 수 있다. - 디스크의
[SNMP] SNMP Overview [내부링크]
SNMP Overview 처음에는 네트워크 장비를 ICMP로 관리했으나 네트워크가 커지고 관리가 복잡해져 SNMP가 탄생함 SNMP는 ICMP의 기능과 다르게 네트워크 동작을 알 수 있음 1) 구성관리(Configuration Management) - 네트워크가 어떤 구조를 이루고 있는지 확인 가능 2) 성능관리(Performance Management) - 응답 시간, 사용량, 처리 속도 등의 통계 데이터 제공 가능 3) 고장관리(Fault Management) - 문제의 검색, 추출 및 해결을 제공하는 기능 4) 보안관리(Security Management) - 정보의 제어 및 보호 기능 SNMP는 Version 및 Community가 같아야 함 SNMP 구성요소 Manager 정보를 수집하는 장비 Manager를 NMS(Network Management System)라 부름 NMS는 SNMP를 이용해 네트워크 장비의 정보를 수집하고 장애 발생 시(SNMP 정보 변경
[Basics] Ethernet 개념 및 Header [내부링크]
Ethernet 개념 Ethernet 개념 IEEE 802.3 주소 : MAC CSMA/CD 방식을 기반 버스형 토폴로지 사용 - 장점 : 트래픽 제어 간단, 비용 저렴, 확장 용이 - 단점 : TS가 복잡, 병목현상 가능성 MAC(Media Access Control) MAC(Media Access Control) Ethernet의 주소로 사용 각 장비를 구분하기 위한 주소 48bit(6Byte)이며 16진수로 표기 - 앞 24bit : 제조업체 (24bit 중 앞 8bit는 예약됨) - 뒤 24bit : 시리얼 번호 Ethernet Header Ethernet II(DIX II) Frame Header IEEE 802.3 Frame Header Ethernet Header : Destination Address ~ Type - Preamble, FCS는 Ethernet Header에 포함되지 않음 Preamble 송신기와 수신기가 통신을 동기화 송수신 측 간의
[Routing Basic] Distance Vector / Link-State [내부링크]
Distance Vector Distance Vector Distance - 해당 네트워크까지 거리 정보 - 상대방에 따라 결정 - Distance = 거리 Vector - 해당 네트워크에 대한 방향 정보 - 본인이 받은 방향으로 결정 - Vector = 방향 (interface) RIP의 알고리즘(Bellman-Ford)은 RIP DB를 주기적으로 복사본을 전달함 - Distance Vector Protocol은 인접 라우터를 넘어 전송되지 않음 광고받은 정보로 라우팅을 해야 하므로 광고받은 정보를 신뢰할 수밖에 없음 - 경로 계산을 직접 하지 못함 - 전체 토폴로지를 모름 Convergence Time이 많음 Loop 발생 위험이 있음 Link-State Link-State Link - 각 장비의 connection 정보 - Link = Interface State - 네트워크 및 연결 상태 정보 - 인터페이스의 네트워크와 누구와 연결되어 있는지 정보 - State
[SNMP] SNMP Version [내부링크]
SNMPv1, v2, v3로 구분 보안을 강화하기 위해 버전을 업그레이드 함 - Manager와 Agent간 인증을 위한 값인 Community String의 보안 취약성 강화 - Community값은 NMS솔루션과 네트워크장비간 인증에 사용되는 값 NMS가 장비를 관리하고자 Community값이 동일해야 함(일종의 비밀번호) SNMP v1 SNMPv1 Manager(NMS)와 Agent(네트워크 장비)간 인증을 구현함 Community 값이 평문으로 전달되어 보안에 취약함 보안기능 없음 - Community String만 일치하면 모든 정보 획득가능 장비 정보 값을 대량으로 수집 요청이 불가능함 Sniffing에 취약 SNMP v2 SNMPv2 DES 알고리즘과 MD5 알고리즘을 사용해 데이터 보안 기능과 인증정차에 대한 보안 기능을 추가함 → 많은 사이트에서 SNMPv2에 보안 기능이 있다고 하지만 잘못된 정보임(보안기능 없음) SNMP Message 추가 -
[SNMP] Message [내부링크]
SNMP의 목적은 장비의 정보를 수집해 NMS와 같은 관리 솔루션이나 관리자에게 전송하는 것 - 때문에 SNMP의 정보를 전달할 Message가 존재하며 Message에도 Type이 존재함 Get Get 정보를 가져오는 메시지 Type 장비의 기능/설정 확인을 위해 SNMP 정보를 요청/응답하는 것 GetRequest - Manager가 Agent에게 보내며 "내가 요청하는 instance id 의 instance 를 달라" 라는 의미 - Manager가 Agent에게 정보(OID, Instance ID, Instance Value)를 요청함 - Manager는 Agent의 정확한 OID를 알아야 정보를 요청할 수 있음 - 한 개의 정보만을 수집하기 위한 메시지(기본 메시지) GetNextRequest - Manager가 Agent에게 보내며 "내가 요청하는 object id 혹 은 instance id 의 가장 근접한 instance 를 달라" 라는 의미 - GetRequ
[Link Aggregation] Link Aggregation Overview [내부링크]
Link Aggregation 사용 목적 Link Aggregation 사용 목적 물리적인 여러 개의 포트를 논리적으로 하나의 포트처럼 사용 링크의 대역폭을 확장하기 위한 용도 링크 이중화 용도로 사용 링크 별 부하분산 용도로 사용 Link Aggregation 필요성 및 문제점 Link Aggregation 필요성 Link Aggregation 없이 여러 개의 링크를 연결할 경우 STP의 Block이 잡혀 실제로 하나의 링크만 사용 Link Aggregation 문제점 BUM 트래픽을 받으면 포워딩 시킴 → 루프가 발생하는 이유 Link Aggregation은 가상의 포트를 만들고 데이터를 받은 포트로 내보내지 않는 필터링 특징을 이용 → Link Aggregation에서 물리적인 포트가 죽어도 STP를 재 계산하지 않으므로 로스에 대한 문제가 없음 Link Aggregation이 아닌 물리적인 링크에 BPDU를 송신하면 한쪽이 Block 됨 → Link Aggreg
[Link Aggregation] Link Aggregation Load Balancing [내부링크]
Link Aggregation Load Balancing 보통 로드밸런싱 종류(MAC/IP/Port) 중 하나 사용 가능 → 여러 개 중 가장 최상위 로드밸런싱을 선택하여 사용 → 상위 순서 : MAC - IP - Port MAC or IP or Port의 마지막 3개 Bit를 이용해 로드밸런싱 → 0~7 → Source or Destination or XOR을 사용 XOR을 사용하면 한쪽으로 부하가 일어나지 않음 → AND, OR, NOR, NAND는 데이터가 한쪽으로 몰릴 수 있음 정확한 로드밸런싱을 위하여 링크를 2 or 4 or 8개를 사용하는 것을 추천 Link Aggregation 포트 수 Load Balancing 1 No Load Balancing 2 4 : 4 3 3 : 3 : 2 4 2 : 2 : 2 : 2 5 2 : 2 : 2 : 1 : 1 6 2 : 2 : 1 : 1 : 1 : 1 7 2 : 1 : 1 : 1 : 1 : 1 : 1 8 1 : 1 : 1 :
[Link Aggregation] Link Aggregation Protocol [내부링크]
Link Aggregation Protocol Link Aggregation이 정상적으로 되지 않는 경우 한쪽은 Link Aggregation을 맺지 못하므로 STP 이슈가 발생할 수 있음 → Link Aggregation은 On(수동)보다 프로토콜을 사용하는 것을 추천 PAGP(Port Aggregation Protocol) PAGP(Port Aggregation Protocol) Cisco 전용의 Link Aggregation Protocol Etherchannel은 Cisco 전용 프로토콜 On Mode : Protocol을 사용하지 않고 수동으로 Link Aggregation 생성 요즘 잘 사용하지 않음 Mode Desirable Auto On Desirable Yes Yes No Auto Yes No No On No No Yes LACP(Link Aggregation Control Protocol) LACP(Link Aggregation Control Protoco
[Link Aggregation] PAGP Header [내부링크]
PAGP(Port Aggregation Protocol) Header PAGP Header 상대방에게 수신한 정보를 기반으로 Partner 정보를 채워 송신 → 상대방이 보낸 정보가 맞는지 확인하기 위한 작업 L2 헤더의 Type이 0x0104이면 PAGP 필드 값 설명 Version - 0x01 Flag - Slow Hello · No = 0 / Yes = 1 - Auto Mode · Auto = 0 / Desirable =1 - Consistent State · False = 0 / True = 1 - Slow Hello · 0 : Hello TIme = 1s / Hold TIme = 3s · 1 : Hello Time = 30s / Hold Time = 90s - Consistent State · 0 : 상대방에게 수신한 정보에 대해 Consistent 실패 · 1 : 상대방에게 수신한 정보에 대해 Consistent 성공 Local ID - Local System ID -
[Link Aggregation] LACP Header [내부링크]
LACP(Link Aggregation Control Protocol) Header LACP Header BPDU는 STP만을 위해 만들어진 기술이 아님 - BPDU는 L2에서 사용하는 기술들을 위해 만들어진 것 L2 헤더의 Type이 0x8809이면 Slow Protocol PAGP는 기본적인 헤더 뒤에 TLV를 추가하는 형식이지만 Slow Protocol은 기본적으로 TLV 형식으로 전달함 LACP Header Format LACP Header Format 필드 설명 Subtype - 어떤 프로토콜을 사용하는지 알려줌 · 0x01 : LACP Version - LACP Version을 알려줌 · 0x01 Subtype Subtype Value Protocol Name 0 Unused - Illegal Value 1 Link Aggregation Control Protocol (LACP) 2 Link Aggregation - Marker Protocol 3 Operations
[Link Aggregation] 명령어(Cisco) [내부링크]
Link Aggregation 설정 명령어 Link Aggregation Load Balancing 설정 conf t interface Port-channel 1 load-balancing dst-mac // Link Aggregation의 Load Balancing 방법 설정 end Link Aggregation 설정 conf t interface range Fa 1/1 – 2 // 인터페이스를 따로 설정하면 Link Aggregation이 안 묶일 수 있음 // Trunk인 상태에서 Link Aggregation을 설정하면 정상적으로 구성되지 않을 수 있음 Channel-protocol [lacp / pagp] // Link Aggregation 프로토콜 설정 Channel-group [1] mode [desirable/auto/active/passive] // 채널 번호와 협상 모드 설정 end conf t interface Port-channel [1] // Link Aggr
[VRRP] VRRP Overview [내부링크]
Gateway Redundancy 개념 Gateway Redundancy 필요성 단일 게이트웨이 구성일 때 게이트웨이 장애 시 외부와 통신 단절 Single Point of Failure를 막기 위해 게이트웨이 이중화 필요 Gateway Redundancy 종류 1. Client에서 2개 이상의 Default Gateway 설정 2. Proxy ARP 이용 - 보안상 문제가 될 수 있으며 장애발생 시 기존의 ARP-Cache가 갱신되기 전까지 사용 불가능 3. IRDP (ICMP Router Discovery Protocol) 사용 - Client에 라우팅 프로토콜을 사용해야 해 번거롭고 OS지원이 되어야 함 4. 라우팅 프로토콜 사용 - Client에 라우팅 프로토콜을 사용해야 해 번거롭고 리소스 낭비가 심함 5. 게이트웨이 이중화 프로토콜 사용 (HSRP, VRRP, GLBP) - Client는 설정 및 설치가 필요 없으며 백업경로로 이전하는 시간이 빠름 - 간편하고 안정적이
[VRRP] VRRP 동작 원리 [내부링크]
VRRP(Virtual Router Redundancy Protocol) 동작원리 VRRP 상세 동작 원리 1. 같은 VRRP 그룹의 멤버인 라우터는 VRRP advertisement 패키킷을 송수신하고 서로 Priority를 비교해 Master/Backup 을 선정하고 Active가 VIP, VMAC를 가져감 2. Master는 GARP를 보내 L2 SW의 MAC Table과 하단의 노드들의 ARP를 갱신시킴 3. 사용자는 외부와 통신하기 위해 게이트웨이로 ARP Request를 날리게 되고 VIP와 VMAC을 가지고 있는 라우터가 응답함 4. Master는 Advertisement-Interval 주기로 VRRP Advertisement 패킷을 Backup으로 송신하여 자신이 살아있음을 알림 (Default : 2s) 5. 하단 노드들이 게이트웨이로 보내는 패킷은 SW의 MAC Table에 의해 Master로 이동 됨 6. Active 장비 장애 발생 시 Backup에게 Dead
[VRRP] VRRP 옵션(Preempt / Owner / Track 등) [내부링크]
Preempt Preempt Master가 장애 후 복구 되었을 때 Master를 가져오는 옵션 1. VRRP Priority가 큰 R1이 Master로 선출 2. R1 Down을 감지한 R2는 Master로 변경 3-1. Preemption=False인 경우 R1이 살아나도 R2가 Master를 유지 3-2. Preemption=True인 경우 R1이 살아나면 R1이 Master를 가져옴 Preempt O / Preempt X Owner Owner VIP를 R1의 RIP로 사용하는 경우 R1을 Owner라 부름 Master 선정 시 Priority 값은 255을 가지며 항상 Preempt mode=True라 가정함 → 설정된 값은 무시 VRRP Load Balancing VRRP Load Balancing Backup 장비를 통해 Load Balancing 시킴 - 두 개의 Virtual 라우터를 설정(VRID=1, VRID=2) VRID=1에 대해서는 R1을 Master
[HSRP] HSRP Overview [내부링크]
HSRP Overview HSRP 개념 전반적인 개념은 VRRP와 동일하니 VRRP 개념을 참고하면 됨 Cisco 프로토콜 HSRP 기본 동작 원리 1. 같은 HSRP 라우터는 서로의 Priority를 비교해 ACTIVE/STANDBY를 선정하게 되고 Active가 VIP를 가져감 2. PC는 Default-gateway로 VIP를 설정 3. PC는 외부로 나가기 위해 Default-gateway로 ARP Request를 날리게 되고 VIP와 VMAC을 가지고 있는 라우터가 응답 4. PC는 VIP와 VMAC을 통해 외부와 통신 5. 지속적으로 HSRP 라우터끼리는 서로 상태를 체크 6. Active 장애 발생 시 Standby를 Active로 변경시키고 VIP와 VMAC을 가져옴 7. PC는 VIP와 VMAC의 변동이 없으므로 장애가 발생한 지 모름 8. 중간 SW는 MAC Table(L2 Switch)이 변경됨 HSRP 상태변화 상태 설명 Initial - HSRP Proce
[SLA] SLA Overview [내부링크]
SLA(Service Level Agreement) ICMP는 도달성 테스트만 가능하지만 SLA는 Prove로 초당 보내는 개수를 정할 수 있음 성능 측정하려는 목적 (품질 측정) 특정 Action을 취할 수 없음 (측정만 가능) 가용성의을 높이는 목적 (고가용성) Sender →Prove를 송신하는 장비 Responder →Sender에게 응답
[EEM] EEM Overview [내부링크]
EEM(Embedded Event Manager) 이벤트 발생 시 관리자가 미리 설정한 특정 Config로 정책을 수행 보통 SLA로 Event를 감지하고 그에 대한 정책을 EEM으로 처리함
[EEM&SLA] 명령어(Cisco) [내부링크]
EEM - Event Syslog Pattern conf t event manager applet e0/0_DOWN // EEM Name 지정 event syslog pattern "%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to down" // 해당 로그 발생 시 아래 Action(설정) 실행 action 1.0 syslog msg "L3_SW e0/1_DOWN LLCF_Process_Start" // Syslog 발생 action 2.1 cli command "enable" // "Cli Command" Action을 지정할 땐 반드시 처음엔 "enable" 입력 action 2.2 cli command "conf t" action 2.3 cli command "interface e0/1" action 2.4 cli command "shutdown" action 2.5 cli command
[Routing Basic] IGP / EGP [내부링크]
IGP(Internal Gateway Protocol) IGP(Internal Gateway Protocol) 같은 AS 안에 목적지까지 도달하기 위해 Next-Hop까지 경로를 알려주는 것 단일 AS내에서 동작하는 라우팅 프로토콜 (RIPv2, OSPF, EIGRP) 인터넷의 모든 장비를 한 번에 관리하기 힘들어 영역으로 나눠 관리 (영역 : AS) 구름 = 하나의 AS EGP(Exterior Gateway Protocol) EGP(Exterior Gateway Protocol) 다른 AS에 있는 목적지까지 도달하기 위해 Next-Hop까지 경로를 알려주는 것 AS 간에는 하나의 IGP 망이 하나의 라우터라 생각해도 무방 EGP는 IGP를 사용하는 하나의 망을 하나의 라우터처럼 생각하고 처리 서로 다른 AS 간에 동작하는 라우팅 프로토콜 (EGP, BGP) AS 간에 Best-Path를 찾음 IGP와 EGP 비교 IGP vs EGP 구분 IGP EGP Priority
[Routing Basic] 라우팅 Overview [내부링크]
라우팅 개념 Routing / Routing Table Routing Table - 네트워크별 OIL(Outgoing Interface)과 Next-Hop IP를 저장해 놓은 DB 라우터 기능 - 라우팅 : 경로 설정 - 스위칭 : 결정된 경로로 패킷 전달 - 방화벽, VPN 등 Layer별 스위칭 - L2 스위칭 : MAC 정보(Mac Table)를 보고 스위칭 - L3 스위칭 : IP 정보(Routing Table)를 보고 스위칭 → 라우팅 기능이 추가됨 - L4 스위칭 : IP+Port를 보고 스위칭 → 로드밸런싱을 위해 사용 Default Route와 Default Gateway Default-Route - 라우팅 기능과 함께 동작 Default Gateway - 라우팅 기능이 동작하지 않는 장비에서 다른 네트워크로 데이터를 전송할 때 사용 - Default-Gateway는 동작하지 않다가 라우팅 기능이 정지되면 동작함 Routed Protocol / Routing
[Static Routing] Static Routing Type [내부링크]
Static Routing Protocol Dynamic Routing Protocol은 자동으로 네트워크를 광고함 Static Routing Protocol은 관리자가 수동으로 각 네트워크마다 경로를 설정해야 함 Static Routing Type OIF(Outgoing Interface) 라우팅 테이블에 Direct로 표시됨 보안에 문제가 있어 추천하지 않음 → Client가 임의의 IP로 Ping 시도 시 GW가 ARP의 응답을 하여 Client는 GW의 정보를 알 수 있음 왼쪽 라우터에서 오른쪽으로 패킷을 송신할 때 패킷의 D-IP는 192.168.1.0/24 대역 패킷을 받은 가운데 라우터는 Gi0/0에 Porxy ARP가 Enable 되어 있으면 D-IP가 본인이 아니더라도 ARP응답을 할 수 있음(단, 라우팅 테이블에는 있어야 됨) → Proxy ARP가 Disable 되면 통신이 안 됨 Next-Hop 라우팅 테이블에 Next-Hop으로 표시됨 Next-
[MPLS-TE] MPLS Traffic Engineering Overview [내부링크]
Traffic Engineering Solution 장단점 MPLS를 이용하지 않은 Traffic Engineering Solution의 단점 새 링크 구매(대역폭 추가) - 비용이 많이 듦 - 일부 링크가 충분히 활용되지 않을 수 있음 - 시간이 지남에 따라 트래픽 패턴이 변경될 수 있음 Load Balancing이 가능하도록 IGP Metric 수정 - 모든 트래픽에 대한 솔루션을 찾는 것은 거의 불가능함 - 관리가 어렵고 확장성이 없음 각 Hop에서 PBR 사용 - 구현 및 유지관리가 매우 복잡함 - 오류 및 라우팅 루프 및 블랙홀화가 발생하기 쉬움 MPLS RSVP-TE를 이용한 Traffic Engineering Solution의 이점 관리자가 정의한 LSP "Path"를 관리적으로 정의 가능 IGP Cost 이외의 추가 제약 조건을 사용 가능 Protection LSP(Secondary LSP, FRR SLP) 제공 다른 이점들도 많음 Traffic Engin
[MPLS-TE] Constraints for RSVP-TE LSP Path [내부링크]
Constraints를 이용한 RSVP-TE LSP Path Strict LSP Path 정의 LSP Path는 Hop을 정의하여 수동으로 정의할 수 있음 - 수동으로 정의된 Path는 IGP의 Path와 다를 수 있음 Next Strict Hop은 Connection된 장비의 System IP나 Interface IP를 설정해야 함 - 단, Interface IP는 Direct Connection된 IP만 해당됨 제약조건(Constraints)을 이용한 RSVP-TE 경로 계산 LSP의 "Path"를 정의하는 대신 LSP에 제약조건을 설정하여 LSP Path를 제어할 수 있음 Ex) SPF 알고리즘은 경로를 계산할 때 "Link Cost"라는 제약조건을 사용함 - Link Cost(BW) 제약조건을 단독으로 경로 계산을 했을 때 옵션이 제한됨 → Delay와 같은 다른 특성들을 고려하길 원할 수 있음 RSVP-TE Constraints 종류 Explicit Route (s
[MPLS-TE] OSPF Traffic Engineering - Opaque LSA [내부링크]
IGP Traffic Engineering Extension IGP Traffic Engineering Extension TE는 추가적인 Link 속성에 대한 정보가 네트워크 모든 곳에 광고되어야 함 → 제약조건 변동 시 해당 정보는 즉시 다른 모든 라우터에 광고되어야 함 Distance Vector Routing Protocol은 전체 토폴로지가 아닌 Direct Connection된 Neighbor에 대한 정보만 광고하기 때문에 적합하지 않음 기존의 Link-State Routing Protocol은 Link IGP Metric 정보만 광고함 MPLS-TE를 위해 OSPF와 IS-IS에 대한 Extension을 정의함 - TE 측면에서 두 Protocol 모두 유사한 기능을 제공함 Nokia는 OSPF와 IS-IS에 대한 TE Extension을 지원함 - Extension된 버전을 각각 OSPF-TE 및 IS-IS-TE라고 함 OSPF Opaque LSA Overvie
[MPLS-TE] OSPF Opaque LSA Header Format 및 TLV [내부링크]
OSPF Opaque LSA Header Format OSPF Opaque LSA Header Format Option Bit 내용 DN - BGP/MPLS IP VPN에서의 루프를 방지하기 위해 사용 0 - Opaque LSA를 수신 및 전송에 대한 라우터의 의향을 나타냄 DC - 라우터의 Demand Circuit 처리를 설명 EA - 더 이상 사용 안 함 N/P - LSA Type 7의 처리에 대해 설명 MC - IP 멀티캐스트 데이터그램이 [MOSPF]의 사양에 따라 전송되는지 여부를 나타냄 E - AS-External LSA가 Flooding되는 방법을 설명 MT - Router의 Multi-Topology 링크 제외 기능에 대해 설명 - OSPF-MT에서 자세한 설명 나옴 MPLS-TE 정보는 Type 10 Opaque LSA TLV로 전달됨 OSPF LSA Type 10 TLV Type OSPF LSA Type 10 TLV Type OSPF LSA Type 10의 TL
[MPLS-TE] IS-IS Traffic Engineering [내부링크]
IS-IS Extension Header Format IS-IS Extension Header Format Link-State Routing Protocol로서의 내용은 RFC 1195에 정리됨 단일 영역 IS-IS에 적용되는 TE에 대한 내용은 RFC 3784에 정리됨 IS-IS Extension을 위해 기존의 IS-IS에 새로운 TLV를 추가함 IS-IS TLV Type IS-IS에서 사용되는 TLV IS-IS에서 사용되는 TLV Traffic Engineering Router ID TLV - Router-ID를 광고하는 데 사용됨 Extended IP Reachability TLV - IP 포함 - TE 용도로 사용되지 않음 Extended IS Reachability TLV - TE 관련 정보(BW, admin-group 등)를 전송하는 데 사용됨 - Link에 7가지 Type의 Sub-TLV가 포함됨 Shared Risk Link Group TLV - SRLG 멤버십
[MPLS-TE] CSPF Overview & Example [내부링크]
CSPF(Constraint-Based Shortest Path First) CSPF(Constraint-Based Shortest Path First) SPF 알고리즘은 Link Cost만 고려함 CSPF 알고리즘은 경로 계산 시 제약조건을 고려함 - CSPF는 경로를 계산하기 위해 사용됨 - LSP Path를 생성, 유지, 해제하는 것은 RSVP가 하는 것 SFP는 모든 노드까지 최적 경로를 계산하지만 CSPF는 MPLS-TE Tunnel 종단까지만의 최적 경로를 계산함 BW 예약은 CSPF 없이 수행이 가능함 - BW 예약 요청은 RSVP PATH Message의 FLOW_SPEC 개체 내에서 신호됨 CSPF는 하나의 경로만 찾음 - 동등한 경로가 계산될 경우 미리 정의된 Priority에 따라 하나의 경로를 선택함 - CSPF는 ECMP가 없음 CSPF Algorithm 작동 과정 1. 지정된 제약조건을 충족하지 않는 Link를 제거함 2. SPF 알고리즘을 사용하여
[MPLS-TE] CSPF Failure Case [내부링크]
Failure Case 1 - Invalid Strict First Hop Failure Case 1 - Invalid Strict First Hop R6는 R1에 대한 바로 다음 Hop이 아님 R1에서 PATH Message를 전송하지 않음 - CSPF가 Disable이어도 R1은 IGP 테이블을 참조함으로써 R6가 바로 다음 Hop이 될 수 없다고 결정함 Failure Case 2 - Incorrect Hop Failure Case 2A - Incorrect Hop (CSPF Disable) R1은 중간 Hop Error임에도 불구하고 PATH Message를 보냄 - CSPF가 Disable되어 있으므로 Hop Error를 확인할 수 없음 R5가 ERO에서 Error를 감지함 R5는 PATH Error Message를 송신함 "show router mpls lsp [LSP-Name] path detail" 명령어 - Failure Code : Bad Node - Fa
[MPLS-TE] ERO Overview & Signaling 동작 과정 [내부링크]
ERO(Explicit Route Object) Overview ERO(Explicit Route Object) Overview CSPF에 의해 계산된 Hop 정보는 RSVP PATH Message의 ERO 필드에 포함됨 - 종단 간 Path 정보는 RSVP PATH Message의 ERO에 삽입됨 ERO 필드는 각 Hop에서 수정되어 다음 수신 라우터가 Hop 목록의 맨 위에 있는 자신의 IP를 볼 수 있음 - 각 Hop마다 ERO가 업데이트됨 RSVP PATH Message를 수신하면 ERO를 확인하여 LSP Path에 대한 다음 Hop을 결정함 - ERO는 CSPF에 의해 계산된 Hop 정보로 채워짐 - RSVP PATH Message에 있는 ERO를 확인하여 RSVP PATH Message의 Next-Hop을 결정함 ERO를 이용한 Path Signaling 동작 과정 ERO를 이용한 Path Signaling 동작 과정 위 그림에서 CSPF는 R1→R5→R6→R4로
[MPLS-TE] RSVP-TE Explicit Path Hop [내부링크]
LSP Path Hop Overview LSP Path Hop Path 정의에 LSP Path가 통과해야 하는 Node List가 포함될 수 있음 - 해당 Node를 각각 Hop이라고 함 - Hop은 "Strict" 또는 "Loose"로 구분됨 - Hop은 IP(System or Interface)로 구성 가능 Path 구성은 LSP가 사용하는 실제 경로를 조절하는 데 사용됨 - 이 값은 CSPF 계산에서 제약조건으로 간주됨 Strict Hop & Loose Hop 정의 Strict Hop - Next Hop은 List의 이전 Hop에 대하여 바로 다음 Hop에 해당하는 장비이어야 함 - CSPF가 Enable인 경우 Strict Hop이 유효한지 확인함 Loose Hop - Next-Hop은 List의 이전 Hop에 대해 Downstream Node일 수 있음 - 즉, 바로 다음 Hop일 필요는 없음 - CSPF가 Enable인 경우 Loose Hop에 도달하기 위해 중간
[MPLS-TE] CSPF LSP Path Hop Check Case [내부링크]
CSPF를 사용한 RSVP-TE 가용성 확인 CSPF를 사용한 RSVP-TE 가용성 확인 "tools perform router mpls cspf to [D-IP] [Constraints] [Constraints Value]" 명령어 - CSPF를 사용해 LSP를 설정하여 Signal할 필요 없이 RSVP-TE Path를 사용할 수 있는지 확인할 수 있음 - 다른 S-IP를 지정할 수 있음 - iLER→eLER로 제약조건을 고려해 LSP Path는 어떻게 구성되는지 확인할 수 있음 CSPF Path Check Case 1 - Bandwidth CSPF Path Check Case 1 - Bandwidth R1→R6 LSP Path 중 500Mbps의 BW를 예약할 수 있는 Path가 있는지 확인할 수 있음 - 해당 명령어는 Link에서 LSP가 Signaling이 되지 않고 BW가 예약되지 않음 CSPF Path Check Case 2 - Exclude CSPF Path Chec
[MPLS-TE] RSVP-TE Metric [내부링크]
Traffic Engineering Metric 설정 Traffic Engineering Metric 설정 Default로 TE Metric와 IGP Metric이 같음 - Default로 LSDB에 저장된 정보로 TE Metric 값으로 설정함 "use-te-metric"을 설정해야 CSPF가 TE Metric 값을 고려함 - 해당 명령어를 설정하면 TED에 있는 정보로 TE Metric 값으로 설정함 TE Metric 값은 MPLS Interface에서 설정함 Traffic Engineering Metric 동작 과정 Traffic Engineering Metric 동작 과정 CSPF에서 "use-te-metric" 명령어를 설정한 경우 LSP Path는 TE Metric 값이 작은 아래 Link로 잡힘
[MPLS-TE] Connection Admission Control [내부링크]
CAC(Connection Admission Control) Overview Bandwidth Reservaions BW Reservatio은 RSVP PATH Message의 FLOW_SPEC 개체에 포함됨 BW Reservation Downstream Node에서 CAC 작업이 실패되면 RSVP Error Message가 전송됨 CSPF가 Disable일 경우 예약 가능한 BW가 부족한 Link를 통해 LSP Signal을 계속 시도할 수 있음 CAC(Connection Admission Control)의 필요성 CSPF Enable 후 CSPF 계산 시 TED가 100% 최신 상태가 아닐 수 있음 - CSPF 계산과 LSP Signal하는 사이에 Reservation 내용이 변경되었을 수 있음 - CSPF 계산과 LSP Signal하는 사이에 다른 LSP가 원하는 Link의 BW를 Reservation할 수 있음 - CSPF 계산과 LSP Signal하는 사이에 Link
[MPLS-TE] IGP-TE Bandwidth Update Trigger [내부링크]
IGP-TE Bandwidth Update Trigger Overview IGP-TE Bandwidth Update Trigger Default로 LSP가 연결된 Link에서 BW를 예약 or 해제 or 변경할 때 즉시 IGP-TE Update를 생성함 - 많은 LSP가 지속적으로 BW를 수정하는 경우 오버헤드가 발생할 수 있음 IGP-TE BW Update Trigger 기능을 Enable하면 BW 임계값을 정의할 수 있음 - 예약된 BW값이 Link의 특정 임계값을 초과할 때만 Update가 Trigger됨 - 임계값은 "상승" 또는 "하행" 방향으로 정의할 수 있음 - RSVP Interface에서 BW에 대한 임계값을 설정할 수 있음 IGP-TE Bandwidth Update 동작 과정 Default Mode 동작 과정 Default로 Link의 BW 예약 상태가 변경되는 즉시 Update됨 - LSA가 즉시 생성되고 Flooding됨 LSA를 수신하면 모든 라우터는
[MPLS-TE] LSP Path Bandwidth Reservation Style [내부링크]
Bandwidth Reservation Style Overview RSVP-TE Bandwidth Reservation Style Overview 여러 LSP Path가 같은 Link를 통해 BW을 예약할 때 "Reservation Style"에 따라 LSP가 예약하는 BW이 결정됨 Reservation Style Type - Shared Explicit (SE) · 총 예약은 LSP-Path 중 최대 BW를 Reservation한 하나의 LSP-Path의 BW임 · Default로 SE Type이 적용됨 - Fixed Filter (FF) · 총 예약은 모든 개별 LSP-Path BW 예약의 합계임 Bandwidth Reservation Style 동작 과정 Shared Explicit(SE) 동작 과정 여러 LSP Path가 같은 Tunnel ID를 가진 경우 같은 LSP에 속한 것임 - 같은 Tunnel ID를 보유해도 LSP ID로 구분함 SE Style의 경우 공유
[MPLS-TE] MBB(Make-Before-Break) Overview & 동작 과정 [내부링크]
MBB(Make-Before-Break) Overview MBB(Make-Before-Break) Overview MBB는 RSVP-TE 복원 기능 중 하나임 Traffic 손실 없이 LSP를 변경할 수 있음 MBB(Make-Before-Break) Mechanism 사용 시기 1. LSP의 Constraints 변경 시 MBB 사용 2. FRR 사용 시 FRR Path → Primary Path 전환 시 MBB 사용 3. LSP Resignalling 시 더 좋은 Path가 발견될 시 MBB 사용 4. LSP Soft Pre-Emption 기능 사용 시 MBB 사용 MBB(Make-Before-Break) 설정 및 확인 MBB(Make-Before-Break) 설정 MBB는 Default로 Enable됨 "config router mpls lsp [LSP-Name] no adaptive" 명령어 - LSP 당 MBB를 Disable할 수 있음 - 권장하지 않음 MBB(Mak
[MPLS-TE] Least-Fill Bandwidth Reservation Rule [내부링크]
Least-Fill Bandwidth Reservation Rule Overview Least-Fill Bandwidth Reservation Rule Overview 특정 LSP 대상으로의 IGP Cost이 동일한 Path가 여러 개 있는 경우에 적용됨 Default로 CSPF는 동일한 Cost Link 중 하나를 무작위로 선택함 - 이로 인해 Link에서 BW Reservation이 불균형적으로 분배될 수 있음 "Least-fill" 옵션은 CSPF에 BW Reservation이 가장 적은 Link를 선택하도록 함 - 단, CSPF를 Enable 해야 함 - Least-Fill 기능을 작동하기 위해 ECMP를 Enable할 필요는 없음 Least-Fill 동작 과정 LSP Path 구성 2개의 LSP는 서로 다른 BW Reservation을 가지고 서로 다른 Link에 구성되어 있음 - CSPF는 Enable 되어 있음 두 Path의 IGP Cost는 동일함 Least-
[MPLS-TE] LSP Soft Preemption [내부링크]
LSP Soft Preemption Overview LSP Soft Preemption Overview BW Reservation을 사용하는 LSP에 대한 상대적으로 우선순위를 정의할 수 있음 LSP Soft Preemption 기능을 사용하기 위해 8(0~7) 종류의 우선순위 값을 지정해야 함 Link의 각 우선순위 수준에서 예약되지 않은 BW 값은 IGP-TE를 통해 업데이트됨 LSP Soft Preemption - LSP Priority 각 LSP에 대해 Priority가 정의됨 Priority는 8종류(0 ~ 7)로 구성 가능함 - 값이 낮을수록 우선순위가 높음 (0의 우선순위가 가장 높음) - 값이 높을수록 우선순위가 낮음 (7의 우선순위가 가장 낮음) LSP Priority는 "Setup Priority"와 "Hold Priority"와 연결됨 - Setup Priority · LSP가 다른 LSP를 선점하는 데 얼마나 중요한지를 나타냄 - Hold Priori
[MPLS-TE] Differentiated Services(MAM 및 RDM) [내부링크]
DiffServ(Differentiated Services) Overview Differentiated Services RFC 2475는 다양한 QoS Mechanism을 정의하는 DiffServ Architecture를 설함 목적은 최적의 BW 관리를 위해 다양한 Traffic Type에 대해 서로 다른 QoS를 제공하는 것임 Data Plane에서 수행됨 특정 Forwarding Class에 속하는 Packet은 Policy 구성에 따라 별도의 Rate Limiting(속도 제한), Queuing, Buffering, Qolicing, Shaping, Dropping 특성을 가질 수 있음 Differentiated Services 모델은 TE의 주요 개념을 설명하기 위해 간략하게 언급됨 Qos의 Forwarding Class 모든 IP 또는 MPLS Traffic은 8가지 QoS Forwarding Class에 Mapping 할 수 있음 Default Class Typ
[MPLS-TE] Multiple Area Traffic Engineering(LDP-over-RSVP) [내부링크]
Multiple Area Traffic Engineering Issue Single Area IGP 확장성 문제 Single Area IGP를 사용하면 설계 및 운영 측면에서 간단함 매우 큰 규모의 Single Area IGP에서는 확장성 문제가 발생할 수 있음 Multiple Area IGP Multiple Area를 사용함으로써 확장성이 향상됨 TE는 Multiple Area에서 종단 간 작동할 수 없음 - Type 10 Opaque LSA는 Local Area 외부에 전파되지 않음 LSP-over-RSVP 솔루션은 OSPF 및 IS-IS에 지원됨 Area 간 Traffic Engineering Limitation Type 10 Opaque LSA는 ABR에서 차단됨 라우터는 Local Area에 대한 TE 정보만 가지고 있음 - 다른 Area에 대한 CSPF 기반 LSP(TE 기능)가 작동하지 않음 Multiple Area Traffic Engineering Sol
[MPLS Resiliency] Failure Detection [내부링크]
Network Failure IGP는 오류가 발생한 후 복구 작업(경로 계산)이 수행됨 RSVP-TE는 장애가 발생하기 전에 조치를 취할 수 있음 LDP를 사용하면 IGP 의존성 때문에 수렴 시간이 IGP 수렴에 의존함 Failure Type - Local vs Remote Local Failure는 즉시 감지됨 - 라우터는 Local Port가 Down됨 Remote Failure의 경우 보통 라우터 포트는 UP 상태를 유지할 수 있음 - 라우터는 Neighbor 관계가 Down 되었음을 감지하기 위해 IGP 또는 RSVP Hello와 같은 메커니즘에 의존함 Failure Detection Protocol IGP Hello - Default Timer를 사용하면 Neighbor Down을 감지하는 데 약 30s 소요 RSVP Hello - Default Timer를 사용하면 Neighbor Down을 감지하는 데 약 9s 소요 IGP 및 RSVP Hello Timer
[MPLS Resiliency] LDP Convergence - LDP-IGP Sync [내부링크]
LDP Convergence 동작 과정 LDP는 IGP에 대한 의존도가 높음 장애 발생 후 LDP Convergence에 가장 중요한 요소는 IGP Convergence임 Prefix에 대한 LDP Next-Hop은 IGP Next-Hop(Forwarding Path)과 동일해야 함 - LDP는 FIB의 Next-Hop 정보와 동일한 내용을 LFIB에 있어야 함 - 장애 감지 후 SPF의 결과를 FIB에 업데이트하고 LDP는 FIB의 정보를 기반으로 Label을 LFIB에 설치함 → 두 개의 Forwarding Table이 동기화된 후 Label Switching이 발생할 수 있음 LDP Convergence - Initial 위 그림의 LIB는 R1이 두 Peer한테 서로 다른 Label을 수신했음을 보여줌 R1은 IGP에 의해 결정된 대로 LFIB에서 R2의 Label을 사용함 LDP Tunnel은 IP Forwarding과 동일한 경로를 따름 LDP Convergen
[MPLS Resiliency] Secondary Path 동작 과정 [내부링크]
Secondary Path Protection Overview Secondary Path Protection Overview Head-End에서 LSP 당 최대 8개의 Path 구성 가능 - Primary Path는 1개, Secondary Path는 최대 7개 구성 가능 - Primary Path 없이 Secondary Path로만 LSP를 구성할 수 있지만 권장하지 않음 LSP에서 한 번에 하나의 Path만 Traffic을 전달함 - LSP는 여러 Path를 통해 Traffic Load Balancing을 하지 않음 Primary Path가 항상 선호됨 Secondary LSP는 (Hot)Standby Secondary, Non-Standby Secondary로 구성할 수 있음 Standby Secondary LSP 동작 과정 Standby Secondary LSP - Primary Path 설정 Primary Path가 먼저 Signaling됨 Secondary Pa
[MPLS Resiliency] Secondary Paths Selection [내부링크]
Secondary Path Selection "Path-Preference"는 어떤 Secondary LSP를 사용할지 정할 수 있음 Default Secondary Path Selection 사용 순위 Standby Secondary Path 1) "Path-Preferences" 값이 낮은 Path를 우선함 2) 가동 시간이 가장 높은 Path를 우선함 · "Retry-Timer"마다 LSP 복구를 시도함 Non-Standby Secondary Path 1) 구성 순서의 첫 번째 Path를 우선함 Standby Secondary Path가 Non-Standby Secondary Path보다 우선됨 Default Secondary Path Selection 동작 과정 Default Secondary Path Selection - Initial Traffic이 Primary Path에 있음 두 개의 Standby Secondary Path를 사용함 Default Secon
[MPLS Resiliency] Secondary Paths Selection(Path-Preferences Option) [내부링크]
Path-Preferences Option Secondary Path Selection(Path-Preferences Option 이용) "Path-Preference"는 어떤 Secondary LSP를 사용할지 정할 수 있음 Standby Secondary Path에 대해 Path-Preferences를 정의할 수 있음 - Value : 1~255 (Default : 255) - Value가 낮을수록 우선순위가 높음 Non-Standby Secondary Path에 적용되지 않음 Secondary Path Selection(Path-Preference) 동작 과정 Secondary Path Selection(Path-Preference) - Initial Traffic이 Primary Path에 있음 두 개의 Secondary Path를 구성함 Secondary Path Selection(Path-Preference) - Primary Path Down Primary P
[MPLS Resiliency] LSP-Path 다양성 - Strict Hop 구성 [내부링크]
Strict Hop만을 사용한 경로 다양성 Strict Hop Path 설정 관리 제어 - 정확하게 정의된 Path를 생성함 유연성 저하 - Strict Hop 중 하나가 Down 되면 LSP Path를 설정할 수 없음 확장성 저하 - 대규모 네트워크에서 관리 및 확장이 어려울 수 있음 관리 용이성 저하 - LSP Path 정의가 증가하여 대규모 네트워크에서는 경로를 유지하고 관리하는 문제를 해결하기 어려움 많은 Config 및 Signal Overhead를 초래함 Primary Path & Secondary Path 설정 Strict Hop 경로 정의는 작은 토폴로지에서는 더 실용적임 Strict Hop Path를 이용해 다양한 LSP Path 구성 Strict Hop을 사용하여 LSP-Path는 지정된 Hop을 통과해야 함 - Link or Node Failure 시 대체 Link를 사용할 수 없음
[MPLS Resiliency] LSP-Path 다양성 - Administrative Groups 구성 [내부링크]
Administrative Groups을 사용한 경로 다양성 Administrative Group 적용 전 Path 확인 Administrative Group "UPPER"와 "LOWER"는 서로 다른 Admin Group에 할당됨 Primary Path 및 Secondary Path는 특정 Admin Group을 제외한 경로를 구성할 수 있음 Administrative Group 설정 Admin Group의 구성원인 Link가 있는 라우터 설정 상단 Link는 Admin Group "UPPER"의 Member임 상단 Link는 Admin Group "LOWER"의 Member임 R1→R4 LSP에 Admin Group을 적용시키려면 R2, R7에 "UPPER" Admin Group을 적용시키고 R5, R8에 "LOWER" Admin Group을 적용시킴 R4→R1 LSP에 Admin Group을 적용시키려면 R4, R7에 "UPPER" Admin Group을 적용시키고
[MPLS Resiliency] LSP-Path 다양성 - Shared Risk Link Group 구성 [내부링크]
Shared Risk Link Group을 사용한 경로 다양성 SRLG(Shared Risk Link Group)는 Primary Path를 자유롭게 결정할 수 있음 Secondary LSP-Path는 Primary LSP-Path에서 자동으로 분리됨 CSPF가 Enable 되어야 함 동일한 SRLG에 속하는 Link가 공유 위험의 가능성을 제시함 여러 Standby Secondary Path가 동일한 "path-preference" 값을 공유하는 경우 SRLG Constraint으로 설정된 경로가 설정되지 않는 경로보다 우선함 Shared Risk Link Group 적용 전 Path 확인 Shared Risk Link Group Shared Risk Link Group 설정 SRLG의 멤버인 Link가 있는 장비 설정 상부 Link는 "SRLG-U"라고 불리는 SRLG의 Member임 하부 Link는 "SRLG-L"이라고 불리는 SRLG의 Member임 SRLG C
[MPLS Resiliency] Fast Reroute Mode, Type, Role [내부링크]
Fast Reroute Overview RFC 4090에 정의되어 있음 FRR(Fast Reroute)은 장애 발생 전에 자동으로 Protection Path를 설정하는 방법을 정의함 장애 감지 후 50ms 미만의 Failover를 보장함 FRR을 사용하기 위해 IGP는 TE를 구성하고 LSP에 CSPF를 설정해야 함 - FRR이 작동하려면 Head-End가 LSP-Path의 정확한 경로를 알고 Signal을 보내야 하기 때문 Fast Reroute는 자동으로 경로 계산을 해주며 구성 OverHead를 줄이는 데 도움이 됨 FRR을 위해 CSPF를 사용하야 하는 경우 - Strict Hop만 사용 · CSPF를 사용하지 않아도 FRR 동작 · 단, CSPF를 Disable 하면 장애에서 복귀하는 경우 Global Revertive가 Head-End에서 작동하지 않음 - Loose Hop을 사용 · CSPF를 Enable 해야만 FRR 동작 FRR 설정 시 RSVP PAT
[MPLS Resiliency] Fast Reroute Signaling_1 [내부링크]
Fast Reroute Signaling Fast Reroute Signaling FRR Protection Tunnel을 자동으로 Signaling 하기 위해 Object를 RSVP PATH Message에 넣어 전송함 - FRR을 Enable 하면 Head-End가 FRR Object를 PATH Message에 포함함 - FRR Object는 FRR Option에 대한 구성 정보를 전달하는 데 사용됨 Protection Mode는 FRR Object의 Flags 필드에 표시됨 - One-to-One (0x01) - Facility (0x02) Protection Type은 PATH Message의 Session Attribute Object에 표시됨 - local-protection-desired · Node-Protection을 Disable 한 경우 - node-protection-desired · Node-Protection을 Disable 하지 않은 경우 Sessi
[MPLS Resiliency] Fast Reroute Signaling_2 [내부링크]
Detour Tunnel PATH Message의 Detour Object Detour Tunnel PATH Message PLR이 CSPF를 이용해 Detour Path를 계산한 Hop 정보는 PLR이 전송하는 PATH Message의 ERO에 삽입됨 - 각 PLR은 별도의 PATH Message를 전송하여 Detour Tunnel에 Signal을 보냄 - CSPF 계산 결과는 PATH Message의 ERO(Explicit Route Object)에 포함됨 Detour Tunnel은 원래 Primary Path와 동일한 Tunnel-ID 및 LSP-ID를 사용함 - Tunnel-ID 및 LSP-ID는 라우터 연결을 식별하기 위한 것 Detour Tunnel의 LSP-Name은 "_detour"가 추가되어 Detour Path를 식별함 Detour Object Detour Path를 알리기 위해 PATH Message에 포함됨 다른 PLR과 Detour Tunnel을 구분
[MPLS Resiliency] Fast Reroute Signaling_3 - RRO [내부링크]
RSVP RRO(Record Route Object) RSVP RRO(Record Route Object) RRO는 PATH 및 RESV Message에 포함됨 LSP-Path를 따라 각 라우터는 RRO 필드를 업데이트함 경로 상의 모든 Hop에 대한 Interface IP 및 Label에 대한 정보를 제공함 RSVP RRO(Record Route Object) 동작 과정 RSVP PATH Message에 RRO Field Update RRO는 PATH Message의 각 Hop에서 업데이트됨 각 라우터는 Downstream에 연결하는 Interface IP를 추가함 R4는 RSVP PATH Message가 통과한 경로에 대해 완전한 가시성을 가짐 RSVP RESV Message에 RRO Field Update 각 라우터는 Interface IP와 LSP에 할당된 Label 정보를 추가함 R1은 Label Reservation 정보와 함께 LSP-Path를 완전히 볼
[MPLS Resiliency] Protection Tunnel - DMP [내부링크]
Detour Merging Overview Detour Merging Overview One-to-One Mode는 LSP에 대하여 각 PLR마다 별도의 Detour Tunnel을 만듦 - 다수의 Detour Tunnel로 Overhead가 발생할 수 있음 Overhead 문제를 해결하기 위해 같은 LSP에 대해 여러 Detour Tunnel이 동일한 Link에서 나가는 경우 Merging 할 수 있도록 함 - 모든 공통 Detour Path에 있는 Detour Object의 정보가 단일 PATH Message로 Merging됨 DMP(Detour Merge Point) - Merging 작업을 수행하는 라우터 Detour Merging은 Disable 할 수 없음 Detour Merge Point 동작 과정 Detour Merge - R5 R1은 Node Protection Detour Tunnel을 Signaling 함 R1이 송신한 PATH Message에 Detou
[MPLS Resiliency] One-to-One Detour Path Traffic Flow_Label [내부링크]
One-to-One Detour Path Traffic Flow Fast Reroute One-to-One - Original Path Traffic은 Primary Path로 전달됨 R6, R7을 DMP(Detour Merge Point)라고 함 Fast Reroute One-to-One - Detour Path R2가 R2↔R3 Link Failure를 감지함 R2는 Primary Path에서 Detour Tunnel로 Label Swap을 진행함 40, 60, 70, 80의 Label은 Detour Tunnel에서 RSVP-TE에 의해 이전에 Signaling된 Label임
[MPLS Resiliency] Fast Reroute Facility Mode [내부링크]
Fast Reroute Facility Mode Facility Mode는 아래 항목을 제외하면 One-to-One과 유사함 - 여러 LSP를 동일한 Bypass Tunnel로 Protection할 수 있도록 함 - MP(Merge Point)선택이 다름 - PLR 수행은 Swap이 아닌 Push로 진행됨 동일한 Bypass Tunnel을 사용해 많은 LSP를 Protection하는 것이 목적임 Facility Node Protection FRR Path Calculation Node Protection을 사용한 Topology 확인 One-to-One Mode와 마찬가지로 PLR은 Protection Type(Node 또는 Link)에 따라 Topology를 구분함 Merge Point(MP) 선택이 다름 Facility Mode의 Merge Point 선택 Facility Mode는 여러 LSP가 모두 동일한 Bypass Tunnel로 Protection할 수 있음 -
[MPLS Resiliency] Bypass Tunnel 동작 과정 - Signaling [내부링크]
Facility Mode의 Bypass Tunnel Facility Mode의 Bypass Tunnel Facility Mode는 여러 LSP를 동일한 Bypass Tunnel로 Protection할 수 있도록 함 - 이를 위해 PLR은 Bypass Tunnel을 요청하는 LSP의 RRO를 확인함 Detour Tunnel(Bypass Tunnel) - "bypass-node x.x.x.x" 또는 "bypass-link x.x.x.x"로 Bypass Tunnel의 유무를 결정함 - 이미 Bypass Tunnel이 있는 경우 · LSP가 동일한 Bypass Tunnel에 연결됨 - 아직 Bypass Tunnel이 없는 경우 · New Bypass Tunnel이 설정됨 RRO를 점검하는 방법 - PLR은 RRO를 확인하고 목록의 다음 노드를 결정함 - PLR은 Bypass Tunnel이 이미 설정되었는지 확인함 → Bypass Tunnel이 이미 존재한다면 기존 Byspass Tun
[MPLS Resiliency] Bypass Tunnel Traffic Flow_Label [내부링크]
Facility Bypass Tunnel Traffic Flow - Link Protection Fast Reroute Facility - LSP Setup 두 LSP는 동일한 Bypass Tunnel에 의해 보호됨 R2는 두 LSP에 대해 PLR 역할을 가정하여 Bypass Tunnel을 만듦 Fast Reroute Facility - Bypass Tunnel R2↔R3 Link Failure 발생 두 LSP의 Traffic은 동일한 Bypass Tunnel를 통해 Protection됨 R3(MP)는 각각 올바른 Label로 전달하기 위해 두 LSP의 Traffic을 구별할 수 있어야 함 Fast Reroute Facility - Original Path R3가 수신되는 Label은 300임 Bypass Tunnel은 R2에 설정되며 Link Failure 시 Enable됨 Link Failure 시 R3은 Traffic이 속한 원래 LSP-Path를 식별하기 위해
[MPLS Resiliency] Fast Reroute Recovered after Failure [내부링크]
Fast Reroute Recovered Fast Reroute Recovered FRR 설정 후 장애 발생 시 PLR은 Traffic을 Protectino Tunnel로 전환하고 Head-End로 ERR Message를 전송함 - Error Code : RSVP Notify Error - Error Value : Tnnel Locally Repaired (Local에서 복구한 것을 의미) Head-End는 Primary Path를 UP 상태로 유지함 Head-End가 PLR이 Traffic을 Protection Tunnel로 전환했을 때 - Standby Secondary Path 있을 때 · Head-End가 MBB를 사용해 Traffic을 Standby Secondary Path로 전환시킴 → 단, Secondary Path가 FRR Path 보다 CSPF 계산 결과가 좋아야 됨 - Non-Standby Secondary Path만 있을 때 · Protection Tunn
[DHCP] DHCP 동작 과정 [내부링크]
DHCP(Dynamic Host Configuratino Protocol) Overview DHCP Overview RFC 2131에 정리됨 Bootstrap Protocol을 개선함 DHCP는 Client와 Server만 통신함 DHCP 동작 과정 - IP 할당 DHCP Discover 단말은 DHCP Server를 찾기 위해 DHCP Discover를 Broadcast로 전송함 Client와 같은 Net에 있는 모든 DHCP Server들은 해당 Message를 수신함 DHCP Offer 해당 Message 내에는 단말이 필요로 하는 Net 정보들이 포함되어 있음 - 정보 : 단말 IP, Subnet Mask, Default Gateway IP, DNS IP, Lease Time 등 DHCP Server는 Table에 등록하지 않음 - DHCP가 여러개 있어 Client가 다른 DHCP Server를 이용할 수 있기 때문 Unicast로 응답할 때도 있고 Broad
[DHCP] DHCP Message Format [내부링크]
DHCP Message Format (IP 할당) - DHCP Discover Ethernet Header Destination MAC Address - Broadcast MAC · DHCP Server의 MAC을 모르기 때문 Source MAC Address - Client Mac(A) EtherType - 상위 Header에 IP Packet이 위치함을 나타냄 - Ex) IP=0x0800, ARP=0x0806 IP Header Protocol ID - 상위 Header에 UDP가 위치함을 나타냄 - Ex) UDP=17, TCP=6 Source IP Address - 단말에 할당된 IP가 없기 때문에 0.0.0.0을 사용 Destination IP Address - Broadcast로 DHCP Discover Message를 Flooding함 - DHCP Server의 IP를 모르기 때문 UDP Header Source Port - 68=BOOTP Client - Cl
[DHCP] DHCP Relay Agent 동작 과정 [내부링크]
DHCP Relay Agent 필요성 일반적으로 DHCP Message는 Broadcast로 송신되기 때문에 Client와 DHCP Server는 같은 Net이어야 함 - 이와 같은 문제를 해결하기 위해 DHCP Relay Agent라는 개발됨 DHCP Message의 Broadcast Packet을 Unicast로 변경해 Forwarding함 DHCP Relay Agent 동작 과정 - IP 할당 DHCP Relay Agent는 DHCP Message의 Broadcast Packet을 Unicast로 변경함 - 이때 DHCP Message의 Relay Agent IP(=Gateway IP) 필드에 자신의 주소를 기록함 DHCP Server는 D-IP를 Relay Agent IP로 설정해 DHCP Offer와 DHCP Ack를 Unicast로 전송함 - Unicast를 수신한 DHCP Relay Agent는 Message의 Broadcast Flag 값에 따라 D-IP를 Cl
[DHCP] DHCP Relay Agent Message Foramt [내부링크]
IP 임대기간 연장 절차 및 IP 반납 절차는 DHCP Relay Agent에 의한 Message 변경이 없기 때문에 생략함 DHCP Relay Agent Message Format (IP 할당) - DHCP Discover Ethernet Header Destination MAC Address - Broadcast MAC → DHCP Server MAC (D) Source MAC Address - Client MAC (A) → DHCP Relay Agent Uplink MAC (C) IP Header Source IP Address - 0.0.0.0 → DHCP Relay Agent Uplink IP (100.1.1.254) Destination IP Address - 255.255.255.255→ DHCP Server IP (100.1.1.1) DHCP Message Payload Gateway IP Address - IP 0.0.0.0 → DHCP Relay Agen
[DHCP] DHCP Proxy Agent 동작 과정 [내부링크]
DHCP Proxy Agent Overview DHCP Relay Agent는 DHCP Broadcast Packet(DHCP Discover/ Request)을 수신하여 다른 Net에 있는 DHCP Server로 전달하는 기능을 수행함 DHCP Proxy Agent는 단순히 DHCP Message를 Client와 Server간에 전달해 주는 기능 외에 Client와 Server 사이에서 Server와 Client 기능을 모두 지원함 - 즉, Client에게는 DHCP Proxy Agent가 DHCP Server로 보이도록 함 - 즉, DHCP Server에게는 DHCP Proxy Agent가 Client로 보이도록 함 DHCP Relay Agent와 DHCP Proxy Agent 차이 DHCP Proxy Agent를 Relay Agent와 비교 했을 때 장점 DHCP Server IP가 Client에게 보이지 않아 DHCP Server를 대상으로 하는 DoS 같은 공격에 보호
[DHCP] DHCP Proxy Agent - IP-to-Mac Binding Table [내부링크]
DHCP Proxy Agent를 통한 DHCP 보안 기능 DHCP Proxy Agent는 IP-to-MAC Binding Table을 참조하여 DHCP로 IP할당을 받지 않은 단말이 ARP Request를 보낸 경우 해당 Packet을 Drop시킴 - 해당 단말은 외부망에 접근이 불가능함 IP-to-MAC Binding Table 생성 절차 DHCP IP 할당 ① DHCP Ack의 값을 IP-to-MAC Binding Table에 기록함 IP-to-MAC Binding Table에 아래 항목을 기록함 - Client MAC - Client IP - IP Lease Time - Client와 연결된 DHCP Proxy Agent의 Interface - Expired Time (남은 임대 시간) DHCP IP 임대 시간 연장 ② Client의 T1 Timer가 Expire되면(IP Lease TIme의 절반) Client는 IP 임대기간 연장 절차를 시작함 DHCP Proxy Ag
[DHCP] DHCP Proxy Agent Message Format [내부링크]
DHCP Proxy Agent Message Format (IP 할당) - DHCP Discover Ethernet Header Destination MAC Address - Broadcast MAC → DHCP Server MAC (D) Source MAC Address - Client MAC (A) → DHCP Proxy Agent Uplink MAC (C) IP Header Source IP Address - 0.0.0.0 → DHCP Proxy Agent Uplink IP (100.1.1.254) Destination IP Address - 255.255.255.255 → DHCP Server IP (100.1.1.1) DHCP Message Payload Gateway IP Address(giaddr) - 0.0.0.0 → DHCP Proxy Agent Downlink IP (1.1.1.254) DHCP Proxy Agent Message Format (IP 할당)
[DHCP] DHCP Case Study - DHCP 기본 동작 과정(Cisco) [내부링크]
DHCP 기본 동작 과정 Case Study (Cisco) 작업 개요 목적 Cisco 라우터로 DHCP를 설정하고 DORA Message를 확인한다. 일자 2022.08.06(토) 테스트 내용 1. DHCP 기본 동작 과정 Case Study - 구성도 2. DHCP_SV Interface 설정 3. DHCP_SV DHCP Pool 설정 4. Client DHCP Enable 5. IP 할당 Discover/Offer/Request/Ack Message 확인 6. IP 임대 시간 연장 Request/Ack Message 확인 7. IP 반납 Release Message 확인 8. IP 할당 DORA Unicast 설정 9. Client 상태 확인 10. DHCP Server 상태 확인 테스트 계측기 - 장비 / OS L2 Cisco i86bi-linux-l2-adventerprisek9-15.1c / IOL L3 Cisco c3725-adventerprisek9-mz.124-15.t
[DHCP] DHCP Case Study - DHCP Relay Agent 동작 과정(Cisco) [내부링크]
DHCP 기본 동작 과정 Case Study (Cisco) 작업 개요 목적 Cisco 라우터로 DHCP Rleay Agent를 설정하고 DORA Message를 확인한다. 일자 2022.08.07(일) 테스트 내용 1. DHCP 기본 동작 과정 Case Study - 구성도 2. DHCP_SV 및 Relay Agent Interface 설정 3. DHCP_SV DHCP Pool 설정 4. DHCP_SV Routing 설정 5. DHCP Relay Agent 설정 6. Client DHCP Enable 7. IP 할당 Discover/Offer/Request/Ack Message 확인 8. IP 임대 시간 연장 Request/Ack Message 확인 9. IP 반납 Release Message 확인 10. Client 상태 확인 11. DHCP Server 상태 확인 테스트 계측기 - 장비 / OS L2 Cisco i86bi-linux-l2-adventerprisek9-15.1c /
[DHCP] DHCP Case Study - DHCP Static 동작 과정(Cisco) [내부링크]
DHCP Static 동작 과정 Case Study (Cisco) 작업 개요 목적 Cisco 라우터로 DHCP Static을 설정하고 DORA Message를 확인한다. 일자 2022.08.07(일) 테스트 내용 1. DHCP Static 동작 과정 Case Study - 구성도 2. DHCP_SV Interface 설정 3. DHCP_SV DHCP Pool 설정 4. Client DHCP Enable 5. IP 할당 Discover/Offer/Request/Ack Message 확인 6. IP 임대 시간 연장 Request/Ack Message 확인 7. IP 반납 Release Message 확인 8. IP 할당 DORA Unicast 설정 9. Client 상태 확인 10. DHCP Server 상태 확인 테스트 계측기 - 장비 / OS L2 Cisco i86bi-linux-l2-adventerprisek9-15.1c / IOL L3 Cisco c3725-adventerpris
[DHCP] 명령어(Cisco) [내부링크]
DHCP 명령어 DHCP Server 명령어 conf t // DHCP를 Dynamic하게 할당할 때 아래 명령어 사용 ip dhcp pool DYNAMIC_POOL // DHCP "Pool" Name 지정 network 192.168.10.0 255.255.255.0 // 할당할 IP 대역 지정 default-router 192.168.10.1 // Default-Route IP 지정 dns-server 168.126.63.1 168.126.63.2 // Primary 및 Secondary DNS-Server 지정 lease 0 2 1 // Lease Time을 0일 2시간 1분으로 할당 bootfile DHCP_Server // BootFile 지정 netbios-name-server 100.100.100.100 100.100.100.1 // NetBIOS(WINS) Server 지정 domain-name CISCO.com // Domaint-Name을 CISCO.com으로 지정
[EEM] EEM Case Study - Event Syslog 동작 과정(Cisco) [내부링크]
Event Syslog 동작 과정 Case Study (Cisco) 작업 개요 목적 Event Syslog를 설정하여 동작을 확인한다. 일자 2022.08.09(화) 테스트 내용 1. Event Syslog 동작 과정 Case Study - 구성도 2. EEM 설정 3. EEM 동작 확인 4. EEM Debug 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL i86bi-linux-l2-adventerprisek9-15.1c L3 Cisco / IOS c3725-adventerprisek9-mz.124-15.t14 결과 1. "cli command" 입력 시 반드시 처음에 "enable"을 입력해야 동작함 1. Event Syslog 동작 과정 Case Study - 구성도 위 토폴로지의 IP대로 Interface 설정함 라우터의 모든 Interface에 OSPF 설정함 L2 SW에 Default-Route(192.168.0.1) 설정함 L3 SW는 아무 설정하
[EEM] EEM Case Study - Event Cli 동작 과정(Cisco) [내부링크]
Event Cli 동작 과정 Case Study (Cisco) 작업 개요 목적 EEM 설정 중 "Event Cli Pattern"을 설정하여 동작 과정을 확인한다. 일자 2022.08.09(화) 테스트 내용 1. Event Syslog 동작 과정 Case Study - 구성도 2. EEM 설정 3. EEM 동작 확인 4. EEM Debug 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL i86bi-linux-l2-adventerprisek9-15.1c L3 Cisco / IOS c3725-adventerprisek9-mz.124-15.t14 결과 1. "cli command" 입력 시 반드시 처음에 "enable"을 입력해야 동작함 1. Event Cli 동작 과정 Case Study - 구성도 위 토폴로지의 IP대로 Interface 설정 라우터의 모든 Interface에 OSPF 설정 L2 SW에 Default-Route(192.168.0.1) 설정 L3
[EEM] EEM Case Study - Event Timer 동작 과정(Cisco) [내부링크]
Event Timer 동작 과정 Case Study (Nokia 7750 SR) 작업 개요 목적 EEM 설정 중 "Event Timer Watchdog"을 설정하여 동작 과정을 확인한다. 일자 2022.08.10(수) 테스트 내용 1. Event Syslog 동작 과정 Case Study - 구성도 2. EEM 설정 3. EEM 동작 확인 4. EEM Debug 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL i86bi-linux-l2-adventerprisek9-15.1c L3 Cisco / IOS c3725-adventerprisek9-mz.124-15.t14 결과 1. "cli command" 입력 시 반드시 처음에 "enable"을 입력해야 동작함 1. Event Syslog 동작 과정 Case Study - 구성도 위 토폴로지의 IP대로 Interface 설정 라우터의 모든 Interface에 OSPF 설정 L2 SW에 Default-Route(192.
[EEM&SLA] EEM&SLA Case Study - ICMP Loss 동작 과정(Cisco) [내부링크]
ICMP Loss 동작 과정 Case Study (Cisco) 작업 개요 목적 EEM 설정 중 "Event Track"을 설정하여 동작 과정을 확인한다. 일자 2022.08.10(수) 테스트 내용 1. ICMP Loss 동작 과정 Case Study - 구성도 2. EEM 설정 3. SLA 설정 4. EEM&SLA 매핑 5. EEM&SLA 동작 과정 테스트 계측기 - 장비 / OS L2 Cisco / IOL i86bi-linux-l2-adventerprisek9-15.1c L3 Cisco / IOS c3725-adventerprisek9-mz.124-15.t14 결과 1. "cli command" 입력 시 반드시 처음에 "enable"을 입력해야 동작함 1. ICMP Loss 동작 과정 Case Study - 구성도 위 토폴로지의 IP대로 Interface 설정 라우터의 모든 Interface에 OSPF 설정 L2 SW에 Default-Route(192.168.0.1) 설정
[Static Routing] Static Case Study - Floating Static Routing(Cisco) [내부링크]
Floating Static Routing Case Study (Cisco) 작업 개요 목적 Floating Static Routing을 설정하여 Main Route가 Down될 시 Routing Table이 어떻게 변경되는지 확인한다. 일자 2022.08.10(수) 테스트 내용 1. Floating Static Routing Case Study - 구성도 2. Cisco 기본 설정 3. Interface 설정 4. OSPF 설정 5. Floating Static Routing 설정 6. Main Route Down 후 Routing Table 확인 7. Main Route Up 후 Routing Table 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS c3725-adventerprisek9-mz.124-15.t14 결과 1. AD=10, AD=20인 Static Routing을 구성했을 때 AD가 낮은 Route만 Routing Table에 올라옴 - AD가 높은
[Routing Basic] RTM 및 FIB 생성과정 [내부링크]
RTM, FIB Table 생성 과정 RTM(Routing Table Management) FIB(Forwarding Information Base) RTM(Routing Table Management) 각 Routing Protocol은 Route를 RIB에 채움 각 Protocol의 Best-Path가 RTM으로 전송됨 RTM은 각 목적지에 대한 Route 중 하나를 선택함 - 같은 목적지에 대해 서로 다른 Routing Protocol에서 학습한 Route를 같이 선택할 수 없음 Preference = AD(Administrative Distance) RTM은 여러 Protocol로부터 Best-Path를 받으면 가장 낮은 Preference 값을 기준으로 선택함 RTM은 최적의 Best-Path를 FIB로 전송함 하나의 목적지에 대해 여러 경로가 동일한 Routing Protocol과 동일한 Metric을 가질 경우 ECMP가 가능함 FIB는 SR의 물리적 인
[Routing Basic] Ping, Traceroute, CPE Check(Nokia 7750 SR) [내부링크]
Ping (Nokia 7750 SR) Ping 대상 호스트에 ICMP 응답을 기다림 Round-Trip 및 Packet Loss를 측정함 Ping Command Option - TTL · Ping Request에 포함할 IP TTL 값 - Size Bytes · Ping Request Packet의 Size(Byte) - Source IP · Ping Request에 사용할 S-IP · Direct Connection에 Ping을 시도할 때 S-IP는 Interface IP임 · Hop이 떨어진 대상에게 Ping을 시도하면 S-IP는 System IP임 - Interval Seconds · 연속 Ping Request 사이의 Interval(s) - Next-Hop IP · Routing Table을 무시하고 지정된 Next-Hop IP로 이 Packet을 보냄 - Count · Remote Host로 보낸 Ping 개수 - Do-not-Fragment · Request Fra
[Static Routing] Static Routing Overview [내부링크]
Static Routing Overview Static Route는 Link나 CPU에 Overhead를 부과하지 않음 - 라우터 간에 통신을 하지 않기 때문 Static Routing Option Next-Hop - 직접 연결된 Next-Hop IP를 지정함 - 해당 라우터는 Next-Hop의 장비와 직접 연결되어 있어야 함 Indirect - 직접 연결되지 않은 Next-Hop IP를 지정함 - Indirect에서 사용한 Next-Hop IP의 정보가 Routing Table에 있어야 유효한 항목으로 인정됨 Blackhole - Blackhole을 설정한 장비에서 Packet이 Drop됨 Static Route Option 별 Config 및 동작 과정 (Nokia 7750 SR) Static Route Option - Next-Hop R1 configure router static-route-entry 2.2.2.2/32 next-hop 1.1.12.2 no shutdo
[Static Routing] Static Case Study - Floating Static Routing(Nokia 7750 SR) [내부링크]
Floating Static Routing Case Study (Nokia 7750 SR) 작업 개요 목적 Floating Static Routing을 설정하여 Main Route가 Down될 시 Routing Table이 어떻게 변경되는지 확인한다. 일자 2022.08.20(토) 테스트 내용 1. Floating Static Routing Case Study - 구성도 2. Interface 설정 3. Floating Static Routing 설정 4. Main Route Down 후 Routing Table 확인 5. Main Route Up 후 Routing Table 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 1. Preference=5, Preference=100인 Static Routing을 구성했을 때 Preference가 낮은 Route만 Routing Table에 올라옴 - Preference가 높은
[RIP] RIP Overview [내부링크]
RIP(Routing Internet Protocol) Overview RIP(Routing Internet Protocol) Overview 표준 Routing Protocol 최대 Hop Count는 16이지만 Update는 최대 Hop Count가 15까지만 업데이트 - Hop Count가 16(unreachable) 이상이면 건너가지 못함 - Hop Count가 16(unreachable) 이상인 정보는 버려짐 - 광고할 때 Metric+1의 값을 Update 함 Default로 주기적으로 30s마다 Routing 정보를 업데이트함 Link-State가 아닌 Hop Count만 봄 - Topology를 인지할 수 없으므로 라우터는 Neighbor가 광고한 정보를 믿어야 함 - RIP의 Metric = Hop-Count RIP Database에 있는 정보를 광고함 B/F(Bellman Ford)의 알고리즘을 이용 Connected로 된 라우팅 테이블 변화가 즉각적
[RIP] RIP 간단 동작 과정 [내부링크]
RIP Update 동작 과정 최종 정보 RIB DB를 통째로 던지므로 R3은 R2에게 받았던 네트워크를(1.1.23.0)을 다시 R2에게 광고함 R2는 광고 받은 대역 중 1.1.23.0/24은 Metric에서 밀려 Routing Table에 안 생김 최종 정보에서 변화가 있을 시 업데이트하며 주기적으로 업데이트함 RIP 간략 동작 원리 각 라우터는 A 네트워크 광고 시 A 네트워크로 가려면 '나'에게 보내라고 광고 - R1은 전체 토폴로지를 모르고 연결된 네트워크만 알고 있음 - R1은 A 네트워크로 가기 위해 오른쪽 라우터로 보내면 됨
[RIP] RIP Split Horizon [내부링크]
Split Horizon Overview Split Horizon Overview 정보를 받은 인터페이스를 통해 같은 정보가 나가는 것을 방지 Database에서 각 네트워크마다 Best-Path 쪽인 인터페이스로 업데이트를 하지 않음 - 해당 네트워크의 Best-Path라고 생각하는 인터페이스로 광고하지 않음 Split Horizon 동작 과정 Split Horizon 적용 전 Network 1.1.34.0/24가 Down 시 R3이 업데이트하기 전에 R2가 업데이트하면 R3은 Down 된 네트워크를 다시 DB에 생성함 R2는 1.1.34.0/24를 Hop Count를 3으로 업데이트를 받으므로 R2는 네트워크 구성이 변경된 것으로 인식하고 Hop Count를 3으로 변경 R1, R3는 1.1.34.0/24의 업데이트를 R2에게 받음 → R2는 DB가 변경되었으므로(Hop Count : 3) R1, R3에게 DB를 업데이트함 R1, R3는 R2에게 1.1.34.0/24에
[RIP] RIP Route Poisoning [내부링크]
Route Poisoning Overview Route Poisoning Overview Poisoning을 수신하면 다른 장비에게 송신해 줌 Direct Network가 Down 시 Hop Count 16으로 광고해 도달 불가능한 Network라고 바로 알려줌 - 해당 광고를 받으면 바로 Possibly Down으로 들어가 60s 후에 삭제 네트워크 변화 시 빠르게 정보를 삭제하려고 만든 것이 Routing Poisoning Distance Vector Time Route Poisoning 적용 전 Distance Vector Timer 마지막으로 업데이트를 수신하면 Invalid Time, Flushed Time이 시작됨 Invalid Time - 타임 완료 시 해당 네트워크가 죽었을 수도 있다고 인식 (180s) Flushed Time - 타임 완료 시 DB에 정보를 삭제함(240s) Invalid time이 끝나면 Hold Down Time(180s)이 동작함
[RIP] RIP Poison Reverse [내부링크]
Poison Reverse Overview Poison Reverse Overview Poisoning을 수신하면 Hop-Count가 16인 Poison Revserse을 다시 보냄 - Poisoning을 받은 라우터가 응답하는 것 - Poisoning을 송신하면 Poison Reverse가 바로 돌아옴 Poison Reverse가 아닌 Update를 송신할 땐 바로 송신하지 않음 (30초마다 주기적으로 업데이트 진행) Hop Count 16을 받으면 Possibly Down이 되기 전에 본인 DB를 확인해 해당 네트워크로 가는 다른 경로를 찾음 - 다른 경로가 있으면 그 경로를 알려주고 없으면 Possibly Down 함 - 다른 경로가 없다고 알려주는 것이 Poison Reverse Poison Reverse 동작 과정 Poison Reverse 적용 전 (Hold Down Time Issue) A 네트워크에 대한 Best-Path Poisoning 수신 후 A 네트워크가
[RIP] RIP Hold Down Time [내부링크]
Hold Down Time Hold Down Time 적용 전 A 네트워크가 Down 되어 오른쪽 라우터가 Poisoning을 송신 위로 Poisoning을 던진 것이 늦게 도착하거나 Loss 발생되었을 때 (밑으로는 업데이트됨) R1은 위아래로 로드밸린싱을 하고 있었는데 한쪽에서는 죽었다고 날아오지만 한쪽에서는 아직 죽었다는 메시지가 없음 - R1은 위쪽 경로로 가면 A 네트워크로 갈 수 있고 아래로 가면 해당 네트워크로 못 간다고 인식함 - 그러므로 R1은 아래쪽으로 업데이트를 송신 Poisoning을 수신한 인터페이스는 네트워크가 죽었다고 인식했으므로 업데이트가 들어오면 해당 경로로 바꿔 줌 - 오른쪽 장비도 업데이트를 수신해 경로가 생겼으므로 오른쪽 장비도 위로 업데이트를 던짐 - Loop가 발생함 Hold Down Time 적용 후 Invalid Time이 끝나는 시점에 내가 Best-Path라고 알고 있던 경로에 대한 Hop-Count를 자신의 경로로 기억을 해
[EIGRP] EIGRP Overview [내부링크]
EIGRP Overview EIGRP(Enhanced Interior Gateway Routing Protocol) Overview IGRP를 개량해서 만듦 Cisco 전용 프로토콜 Network 변화가 생기면 즉시 업데이트 Reliable Transport Protocol(RTP) - EIGRP는 UDP or TCP 없이 메시지를 보냄 - EIGRP Packet의 송수신을 관리함 - EIGRP Packet은 Ack를 사용해 모든 Neighbor에게 신뢰성을 보장 Load balancing은 최대 16개까지 지원 - Unequal Cost Load Balancing 가능 EIGRP Metric = K 상숫값 - k1=bandwidth = 1 - k2=Load = 0 - k3=Delay = 1 - k4=Reliability = 0 - k5=MTU = 0 - MTU는 업데이트에 포함되지만 Metric 계산엔 사용되지 않음 Maxium Hop : 224 Routing 정보
[EIGRP] EIGRP DUAL, Unequal-Cost Load Balancing [내부링크]
DUAL(Diffusing Update Algorithm) FD(Feasible Distance) 1번 경로 최적 경로상의 Next-Hop(R3)을 Successor라고 함 출발지에서 목적지까지 계산한 최적의 Metric 값 목적지 네트워크까지 FD값이 가장 낮은 경로 RD(Reported Distance) 2번 경로 R1의 Next-Hop(R3)부터 목적지까지의 메트릭 값 출발지 Next-Hop에서 목적지까지 계산한 EIGRP Metric 값 - 최적경로 FD > 후속 RD FS(Feasible Successor) 3번 경로 Successor가 아닌 것 중에 자기의 RD 값이 Successor의 FD 값보다 작은 경우를 Feasible Successor라 함 남아있는 경로 중 AD값이 FD값보다 작은 경우 Unequal-Cost Load Balancing 최적 경로에게 더 많은 데이터를 보냄 조건 - Unequal-Cost Load Balancing의 대상이
[EIGRP] EIGRP Packet 종류 [내부링크]
Hello Packet Hello Packet Neighbor 생성 및 연결유지 기능을 수행 주기적인 업데이트는 없음 Hello 패킷을 보냄으로써 Routing Table 유지 Hello 패킷 주기 링크 정보 Hello 주기 Hold Time 주기 Multi-Point, Frame-Relay 60s 180s T1, PPP 5s 15s Hold Time 동안 Hello 패킷이 수신되지 않으면 Neighbor를 끊고 Routing Table에 해당 내용 삭제 Multicast(224.0.0.10)로 뿌림 Update Packet Update Packet 경로 정보를 교환할 때 사용 Neighbor에게만 실제 정보를 송신할 수 있음 Update를 수신하면 정보들을 Topology Table에 저장 Topology Table에 있는 정보가 동기화될 때까지 정보를 교환함 동기화가 완료되면 Dual 알고리즘을 사용해 Best-Path 계산 - Dual 알고리즘은 Bandwi
[OSPF] OSPF Overview [내부링크]
OSPF(Open Shortest Path First) Overview OSPF(Open Shortest Path First) Overview Link-State Routing Protocol Link-State Database Table(LSDB)을 이용해 전체 Topology를 계산하여 직접 경로 계산이 가능함 - Distance Vector Routing Protocol은 전체 Topology를 계산하지 못하므로 직접 경로 계산이 불가능함 - Distance Vector Routing Protocol은 Neighbor에게 받은 정보로만 경로 계산함 IP Packet에서 Protocol 번호 89번을 사용 - TCP/UDP가 아닌 IP 데이터그램에 의해 운반됨 - OSPF 업데이트는 RIP와 달리 Transport Layer Protocol을 사용하지 않음 - OSPF는 IP Packet으로 Encap됨 Passive-interface 지원 - OSPF Packet을 송신
[OSPF] OSPF DR/BDR [내부링크]
DR / BDR(Backup Designated Router) Overview DR / BDR(Backup Designated Router) Overview DROTHER 라우터 - DR와 BDR로 선출되지 않은 라우터 DROTHER 라우터들의 연결 상태는 Two-way Broadcast 단위로 DR, BDR, DROTHER이 구분됨 DR은 한 번 결정되면 변경되지 않음 BDR은 변경될 수 있음 DR / BDR 선출 이유 DR/BDR이 없는 Broadcast는 모든 라우터 간에 OSPF Packet을 송수신하여 대역폭 및 리소스 낭비가 발생함 DR/BDR을 선출하여 DR과 다른 장비 간에만 OSPF Packet을 송수신하여 대역폭 및 리소스 낭비의를 해결함 DR/BDR 선출 전 OSPF Packet 송수신 DR/BDR 선출 후 OSPF Packet 송수신 DR과 BDR 선출 순서 (Cisco 및 Nokia 기준) 1. OSPF Priority가 가장 높은 라우터가 DR로
[OSPF] OSPF Neighbor State Type [내부링크]
OSPF Neighbor State Overview OSPF Neighbor State Type OSPF Neighbor State는 아래 8가지의 상태로 나타냄 - Down State - Attempt State - Initializing(Init) State - Two-Way State - Exstart State - Exchange State - Loading State - Full State OSPF Neighbor State OSPF Neighbor State Type Down State Hello Packet을 전송했지만 받지 못한 상태 Full State에서 Dead Interval동안 Hello 패킷을 받지 못한 상태 Attempt State NBMA에서만 적용되는 상태 Neighbor명령어로 지정한 Neighbor에게 Hello Packet을 수신하지 못한 상태 Neighbor와 연결이 끊긴 경우에도 해당 상태가 됨 Initializing(Init) Sta
[OSPF] OSPF Algorithm 및 Packet Header [내부링크]
OSPF Packet 동작 Algorithm OSPF Packet 동작 Algorithm OSPF Packet 요약정리 OSPF Packet 요약정리 Packet Name Description Hello Neighbor 연결 및 유지 Database Description 데이터베이스 내용요약 Link State Request 데이터베이스 상세 내용 요청 Link State Update 데이터베이스 업데이트 Link State Ack Ack 전송 OSPF Packet Header OSPF 공통 Header 필드 설명 Version - OSPF Version 2 사용 Type - 수신 중인 Packet Type - Type 1 : Hello Packet - Type 2 : Database Description Packet - Type 3 : Link State Reauest Packet - Type 4 : Link State Update Packet - Type 5 : Link Stat
[OSPF] OSPF LSA Type [내부링크]
OSPF LSA(Link-State Advertisement) Type 요약 정보 OSPF LSA(Link-State Advertisement) Type 요약 정보 네트워크(라우팅) 정보를 LSA(Link-State Advertisement)라 함 Type1 ~ Type11까지 11개의 종류의 LSA를 이용해 라우팅 정보를 전송 LSA는 20Byte의 Header를 가짐 LSDB는 Area 별로 관리되며 같은 Area 면 동일함 LSA Type LSA Name Create Router Scope Description LSA 1 Router All Router Within Area 인터페이스 상태 LSA 2 Network DR Within Area DR과 연결된 R-ID LSA 3 Network Summary ABR Inter-Area 타 Area 네트워크 LSA 4 ASBR Summary ABR Within Area ASBR R-ID LSA 5 AS-External ASBR
[OSPF] OSPF Routing Table Code [내부링크]
OSPF Routing Table Code Routing Table에 나타나는 OSPF Code는 Cisco 장비에 해당하는 내용 OSPF Routing Table Code 별 내용 네트워크 타입 코드 우선순위 내용 에어리어 내부 네트워크 O 1 - 동일 Area에 소속된 Network - LSA Type 1, 2 다른 에어리어 네트워크 O IA 2 - 다른 Area에 소속된 Network - LSA Type 3, 4 도메인 외부 네트워크 O E1 3 - 변동 코스트 값을 가지는 External Network O N1 4 - 변동 코스트 값을 가지는 NSSA External Network O E2 5 - 고정 코스트 값을 가지는 External Network O N2 6 - 고정 코스트 값을 가지는 NSSA External Network OSPF Code 예시 E1 External Network Type 1 외부 네트워크라 부름 다른 라우팅 프로토콜에서 OSPF로 재분배된 네트
[OSPF] OSPF Summarization [내부링크]
OSPF Summarization OSPF Summarization LSA Type 3, 5만 축약 가능 - ABR은 LSA type 3을, ASBR은 LSA type 5를 축약함 - 경계 라우터만 축약 가능 (ABR, ASBR) 축약된 경로의 Metric은 축약된 범위 중 가장 작은 Metric 값으로 전달 축약의 한계 - 축약은 경계 라우터에서 주는 최소한의 정보는 받아야 함 - Stub은 외부의 경로가 Default Route로 외부의 경로를 하나로 처리하는 것 Backbone Area에 소속된 라우터의 라우팅 테이블의 크기는 감소시키지 않음 내부 네트워크 축약 - 축약을 수행한 ABR에서는 루프를 방지하기 위해 라우팅 테이블에 Null 0 경로가 만들어짐 · 축약에 포함되는 상세 네트워크가 다운되었을 때 라우팅 루프를 방지하기 위한 것 외부 네트워크 축약 - 축약된 네트워크에 Null 0이 없음 - 내부 라우터에서 "O E2"로 보임
[OSPF] OSPF Stub Area/NSSA [내부링크]
Stub / NSSA(Not-So-Stubby Area) Area 요약 정보 Stub Area / NSSA(Not-So-Stubby Area) 요약 정보 ABR이 내부 라우터에게 외부 경로에 대한 LSA를 차단하고 Default-Route를 전달 NSSA가 표준 Stub Area 종류 종류 차단 네트워크 Stub Area E1, E2 (Type 4, 5) Totally Stub Area E1, E2, IA (Type 3, 4, 5) NSSA E1, E2 (Type 4, 5) NSSA Totally Stub Area E1, E2, IA (Type 3, 4, 5) Stub Area / Totally Stub Area Stub Area ABR이 내부로 Type 4, Type 5 LSA를 모두 차단하고 Default-Route를 생성해 전송 외부 네트워크를 광고하지 않으므로 ASBR을 알릴 필요가 없어 Type 4 LSA도 차단함 Totally Stub Area "Totally
[OSPF] OSPF Virtual Link [내부링크]
OSPF Virtual Link OSPF Virtual Link Stub Area, NSSA, 또는 Unnumbered link를 통해 Virtual Link를 생성할 수 없음 모든 Area가 Backbone Area에 직접 연결되어야 하는 조건을 해결 Virtual Link는 Virtual Link의 끝점인 다른 ABR의 R-ID로 식별됨 Virtual Link는 Router-ID를 통해 연결해야 하므로 Router-ID에 변화가 생기면 Virtual Link도 끊김 마치 두 라우터 사이의 Unnumbered Point-to-Point Network인 것처럼 동작함 Virtual Link의 Interface-Type은 항상 Point-to-Point Interface로 간주되어 구성할 수 없음
[OSPF] OSPF Authentication [내부링크]
OSPF Authentication OSPF Authentication OSPF Hello 패킷을 송•수신할 때 인증 Text 인증 방식의 Password는 전송된 Packet에 포함되며 네트워크를 통해 일반 Text로 이동함 인증 방식 - Clear Test - MD5 Hello Message의 Authentication Type 필드 Type 내용 0 인증 X 1 Clear Text 2 MD5
[OSPF] 명령어(Nokia) [내부링크]
OSPF 명령어 OSPF 기본 설정 config router ospf // OSPF Protocol 실행 config router router-id 1.1.1.1 // 해당 라우터의 R-ID 지정 config router ospf router-id 1.1.1.1 // 해당 라우터 OSPF 프로세서의 R-ID 지정 config router ospf area 0 // OSPF Area 구성 config router ospf area 0 interface p1/1/1 // OSPF Interface 구성 config router ospf area 0 interface p1/1/1 interface-type broadcast // OSPF Interface-Type 설정 config router ospf area 0 interface p1/1/1 metric 500 // OSPF Interface의 Metric 구성 config router ospf area 0 interface p1/1/
[OSPF] 명령어(Cisco) [내부링크]
OSPF 설정 명령어 OSPF 광고 설정 conf t router ospf [process- ID] // OSPF Process-ID 설정 // Process-ID : 한 라우터에서 OSPF를 구분하는 식별자 router-id [ router-id] // Router-ID 설정 network [network] [wildcard mask] area [area-id] // 해당 네트워크 OSPF Process 시작 end conf t interface fa0/0 ip ospf network broadcast // OSPF Interface-Type 정의 end 동일한 라우터에 다수의 OSPF를 동작시킬 때 구분하기 위한 목적으로 사용 - 라우터 내부적으로 사용하는 ID 라우터별로 다른 값을 가져도 상관없음 Router-ID는 OSPF Domain에서 라우터를 고유하게 식별함 서로 다른 라우터의 Router-ID가 중복되면 안 됨 OSPF Default-Route 설정 conf t
[OSPF] Redistribution 및 Route Filtering [내부링크]
Redistribution Overview Redistribution Overview 다른 Routing Domain으로 Routing 정보를 전달하는 것 Redistribution은 Border Router에 의해 수행됨 Redistribution Preference 라우팅 프로토콜마다 사용하는 알고리즘이 다르기 때문에 Redistribution된 라우팅 프로토콜은 Metric으로 Best-Path를 계산할 수 없음 Redistribution된 Protocol에 기본적으로 할당되는 Preference가 있음 Route Filtering Overview Route Filtering 특정 Route에 대해 광고하거나 받는 것을 허용 또는 거부를 결정함 Route Filtering은 Packet Filtering이 아님 Route Filter의 사용은 RIB 내용을 변경하여 FIB의 정보에도 영향을 미침 Route Filtering - Default Route Policy
[OSPF] ECMP(Equal Cost Multiple Paths) [내부링크]
EMCP(Equal Cost Multiple Paths) Overview ECMP(Equal Cost Multiple Paths) Overview 서로 다른 라우팅 프로토콜의 Preference를 동일한 값으로 설정했을 시 각 라우팅 프로토콜에 대한 Default Preference 값을 따름 동일한 라우팅 프로토콜을 사용하고 Metric도 동일한 경우 ECMP가 가능함 ECMP는 Packet을 여러 경로로 라우팅을 가능하게 함 ECMP Not Enable R1→R4의 두 경로를 동일한 Metric으로 인식함 일반적으로 IGP SPF 알고리즘은 Next-Hop을 선택하기 위해 타이브레이커 규칙을 사용함 - 타이브레이커는 가장 작은 Nest-Hop IP를 선택함 ECMP 없이 R1→R4까지 통신하기 위한 OSPF Next-Hop을 확인할 수 있음 ECMP Enable (Nokia 7750 SR) R1 configure router ecmp 2 // 최대 ECMP 경로 개수
[OSPF] BFD(Bidirectional Forwarding Detection) [내부링크]
BFD(Bidirectional Forwarding Detection) Overview BFD(Bidirectional Forwarding Detection) Overview BFD는 두 시스템 사이의 경로에서 발생하는 장애를 대비하여 사용함 Overhead가 작고 짧은 시간에 장애를 감지하는 기능을 제공 - 1s 이내에 장애 감지를 제공할 수 있음 BFD Packet은 D-Port가 3784이며 S-Port가 49152 ~ 65535에 해당하는 UDP를 통해 전송됨 BFD Session을 맺을 때 3-Way-Handshake 발생함 BFD Session을 끊을 때 4-Way-Handshake 발생함 BFD Session 인증 사용 가능 BFD Session을 생성하려면 BFD를 Interface 및 라우팅 프로토콜에서 설정해야 함 - BFD는 양단의 Interface와 Routing Protocol에서 Enable 되면 Session이 맺어짐 - Session이 맺어질
[Routing Basic] Autonomous System [내부링크]
AS(Autonomous System) AS(Autonomous System) Overview RFC 1771 - 명확하게 정의된 단일 라우팅 정책을 준수하는 범위 Cisco - 단일 Network 관리조직이 관리할 수 있는 Network Area 하나의 AS 안에서 자율적으로 운영 가능 AS와 AS의 사이는 표준 프로토콜 사용 (Ex - EGP) 각 AS를 식별하기 위한 인터넷 상의 고유한 숫자를 AS Number라 함 현재 일반적으로 2byte를 사용중이며 4byte AS도 존재함 다른 AS로 나가는 방향은 관리자가 정할 수 있음 다른 AS에서 들어오는 방향은 관리자가 정할 수 없음 다른 AS는 내가 관리하는 못하는 영역 AS는 16비트 또는 32비트 번호 구분됨 Autonomous System Overview (16-Bit ) AS 0 ~ AS 65535 - 16Bit(1Byte) 전용 AS 1. Public Autonomous System - Global
[BGP] BGP Overview [내부링크]
BGP(Border Gateway Protocol) Overview BGP(Border Gateway Protocol) Overview Distancce Vector Protocol - Split Horizon을 사용함 BGPv4는 RFC 4271에 정의됨 BGP는 Unicast로 라우팅 정보 전송 IGP는 Multicast로 라우팅 정보 전송 TCP 179를 이용해 Session을 맺고 Message를 송수신함 서로 다른 AS 사이에서 사용되는 라우팅 프로토콜 IGP의 Best-Path : Metric BGP의 Best-Path : Attribute 및 Policy 최초 BGP 연결 때 모든 정보를 주고받은 이후에는 정보에 변경이 발생하면 Update를 하여 정보를 재전송함 - BGP는 IGP처럼 자신의 정보를 주기적으로 전송하지 않음 BGP는 Best-Path만 광고함 BGP Neighbor는 TCP 및 BGP의 두 단계로 구성됨 매우 복잡한 라우팅 정책을
[BGP] iBGP vs eBGP [내부링크]
Internal BGP iBGP(internal BGP) BGP Neighber가 동일한 AS에 속함 iBGP 라우터는 직접 연결되지 않아도 됨 eBGP(다른 AS)로 학습한 경로를 또 다른 AS의 eBGP 라우터에게 광고할 용도로 사용되기도 함 TTL : 255 (Cisco) TTL : 64 (Nokia 7750 SR) Physical IP로 iBGP 연결 Loopback IP로 iBGP 연결 BGP Neighbor IP는 Physical Interface와 Loopback IP를 사용할 수 있음 iBGP Neighbor를 지정할 때는 보통 Loopback IP를 사용 Physical Interface로 지정해도 되지만 Link Down 시 Backup Path가 있어도 Neighbor가 끊어짐 External BGP eBGP(external BGP) 서로 다른 AS 간에 라우팅을 업데이트를 하는데 사용됨 보통 TTL의 Default가 1이어서 Neighbor끼리
[BGP] BGP Table 생성 과정 [내부링크]
BGP Neighbor 유지 BGP Neighbor 유지 1) TCP 및 BGP Session이 설정된 후 BGP 업데이트가 전송됨 2) Session을 유지하기 위해 주기적인 keepAlive가 전송됨 3) Hold Timer Interval 내에 Message가 없으면 BGP 및 TCP Session이 모두 종료됨 4) Session이 종료되면 Neighbor로부터 학습된 모든 정보가 폐기되고 전체 네트워크가 Convergence 되어야 함 5) TCP 및 BGP Session에 변화가 생기면 정보 교환이 발생하고 Policy가 적용된 후 Best-Path가 RTM에 제공되어 각 경로에 대해 Preference에 따라 최종 결정이 이루어져 FIB로 전송됨 Routing Table 및 BGP Database 생성 과정 BGP Default Setting (Nokia 7750 SR) Import Route-Policy 설정이 없을 시 - 모든 BGP Route가 Neighbor에서
[BGP] BGP Table Code 확인 [내부링크]
BGP Table Code 확인 BGP Table Code 확인 각 Neighbor에게 학습한 모든 네트워크 정보 번호 설명 ① - " * " · Next-Hop의 문제가 없는 경로를 의미 - " > " · Best-Path를 의미 · 항상 " 〉 "가 있는 Best-Path만 다른 라우터에게 광고됨 · Load Balancing이 설정되어 있지 않은 경우 항상 Best-Path만 라우팅 테이블에 Install됨 - " r "(RIB-failure) · AD가 높아서 라우팅 테이블에 Install되지 못한 것을 의미 - " i " · iBGP Neighbor한테 광고받은 네트워크를 의미 ② - " i " · 해당 네트워크가 IGP, EGP, Incomplete 중 어떤 것으로 광고받았는지 알려줌
[BGP] BGP Table 및 Routing Table Selection Priority / Algorithm [내부링크]
BGP Policy Process (Nokia 7750 SR) BGP Policy Process (Nokia 7750 SR) BGP Route Selection Algorithm (Nokia 7750 SR) BGP Route Selection Algorithm (Nokia 7750 SR) BGP Route Selection Priority BGP Best-Path Selection 아래 사항이 모두 해당되는 경우 BGP Best-Path로 선택함 1) Next-Hop에 대한 Route가 유효함 2) AS Loop가 없음 BGP Route Selection - Tie Breaker (Nokia 7750 SR) Route에 AS Loop이 없고 유효한 Next Hop을 가진 Route에 대해서 다음의 우선순위로 Route를 Selection함 1. Higher Local-Preference - AS 내에서만 유효함 2. Shorter AS-Path 3. Lower Origin Cod
[BGP] BGP Policy - Import/Export [내부링크]
BGP Import / Export Route Policy BGP Import Route Policy BGP 프로토콜에 Import Policy를 적용하면 Neighbor에서 광고 받는 Prefix를 필터링하거나 수정함 - 처리할 업데이트가 적기 때문에 BGP Overhead를 줄임 - Control Plane 처리가 덜 필요하며 테이블 크기가 줄어듦 BGP Export Route Policy BGP 프로토콜에 Export Route Policy가 적용되는 경우 - IGP에서 BGP로의 Route 교환을 제어함 - BGP Neighbor에 광고되는 Route를 관리함 BGP Policy Process (Nokia 7750 SR) BGP Triggered Policy (Nokia 7750 SR) BGP Triggered Policy 일반적인 Policy는 "commit" 명령을 사용하면 Policy 변경 내용이 즉시 적용됨 "triggered-policy"는 프로토콜이 재실행되
[BGP] BGP Policy - Policy Funcion [내부링크]
Policy Function (Nokia 7750 SR) 일반적인 Policy-Statement는 첫 번째 Match 후 Policy Logic을 종료함 "next-entry"를 사용하면 Math 후 동일한 Policy-Statement에 있는 다른 Entry로 넘어감 "next-policy"를 사용하면 Match 후 다른 Policy-Statement로 넘어감 "Next-Entry" Option - Logic Example 1. Policy Entry의 조건과 완전히 Match 되지 않으면 정의된 작업이 적용되지 않으며 다음으로 넘어감 - Policy Statement의 Next Enetry 또는 Next Policy Statement로 진행됨 2. Policy Entry의 조건과 완전히 Match될 경우 - "Reject"이 설정되면 수정되지 않고 Policy가 적용됨 - "accept"가 설정되면 수정되고 Policy가 적용됨 "next-entry"가 설정된 경우 지정된
[BGP] BGP Session Clear [내부링크]
BGP Session Clear(Nokia 7750 SR) BGP Clear Session Neighbor을 재설정함 R1 clear router bgp neighbor 1.1.23.3 BGP Clear Protocol 전체 BGP 프로토콜을 재설정함 R1 clear router bgp protocol Clearing Session - Soft Options "clear router bgp" 명령어로 인한 서비스 영향을 줄이는 Option을 제공함 Soft - 지정된 BGP Neighbor는 구성된 Export Policy에 대해 Local-RIB의 모든 경로를 재계산함 Soft-inbound - 지정된 BGP Neighbor는 구성된 Import Policy를 기준으로 RIB-In의 모든 경로를 재계산함
[BGP] BGP Message Header [내부링크]
BGP Message Type Summary BGP Message Type Summary Message Size - 19Byte ~ 4096Byte 5가지의 Message Type이 있음 - Type 1 ~ Type 4는 RFC 4271에 정의됨 - Type 5는 RFC 2918에 정의됨 Type Name 설명 1 Open - Peer와 BGP Session을 맺는데 사용됨 - Peer에서 구성된 Parameter가 호환되는지를 확인할 수 있음 - BGP의 AS, Router-ID, holdtime 정보를 가지고 있음 2 Update - Peer 간의 라우팅 정보를 교환하는데 사용됨 3 Notification - BGP에서 오류가 발생했을 때 전송 - Peer Session을 종료하는데 사용 - Notification Message를 전송하고 BGP 연결을 종료함 (Error의 원인) 4 Keepalive - BGP Session 유지 - BGP Header로만 구성 - 현재 양
[BGP] BGP Neighbor State [내부링크]
BGP Neighbor State BGP Neighbor State Type BGP Peer는 6가지 상태 중 하나에 존재함 Phase 상태 설명 TCP IDLE - BGP가 시작되었으나 세션이 맺어지지 않고 대기 중인 상태 - TCP가 시작되고 연결이 시도됨 TCP CONNECT - TCP 연결(Session)이 완료되기를 기다리는 상태 1. 연결이 맺어질 경우 OPEN Message를 보냄 2. 연결이 실패하면 ACTIVE State로 변경됨 TCP ACTIVE - TCP 연결 실패로 BGP 세션이 맺어지지 않아 다시 시도하는 상태 - 계속 실패하는 경우 IDLE → CONNECT → ACTIVE를 순환함 BGP OPEN Sent - KeepAlive 및 Hold Timer가 모두 시작됨 - OPEN Message를 보내고 수신을 기다리는 상태 1. 오류 검출 시 Notification Message를 보냄 2. 오류가 발견되지 않으면 Keepalive Message를 보냄 B
[BGP] BGP IGP Synchronization Issue [내부링크]
BGP IGP Synchronization Issue 해결 방법 BGP IGP Synchronization Issue 해결 방법 1. "no sync" 명령어 사용 2. BGP를 IGP로 Redistribution 3. Confederation 사용 4. Non-BGP Router에 iBGP 구동 BGP IGP Synchronization Issue 해결 BGP Synchronization 기능 iBGP로 광고받은 네트워크는 IGP Routing Table이 확인해야만 광고할 수 있음 보통 eBGP Neighbor 관계에서는 동기 문제가 생기지 Synchronization 기능 1. R3은 AS 10에서 광고받은 경로(1.1.1.1/32)를 iBGP로 광고하기 전에 IGP Table을 검사함 2. IGP Table에 1.1.1.1/32 정보가 없다면 해당 경로를 전파하지 않음 ① - Black Hole은 예방할 수 있지만 해당 목적지로 하는 Packet을 전달할 수 없음 1.
[BGP] BGP Next-Hop Issue [내부링크]
BGP Next-Hop Issue BGP Next-Hop D-IP에 대한 Next-Hop으로 사용해야 하는 Border 라우터의 IP임 BGP Update를 수신하면 수행하는 첫 번째 점검은 Next-Hop에 대한 IGP 경로의 가용성임 - Next-Hop 연결할 수 없는 경우 경로 선택 기준에서 경로가 평가되지 않음 iBGP에게 경로를 광고할 땐 Next-Hop을 수정하지 않음 eBGP에게 경로를 광고할 땐 Next-Hop을 수정함 동작은 항상 동일하지 않으며 아래와 같은 영향을 받음 - Point-to-Point Network - Multi-Access Network iBGP와 eBGP의 처리가 다르게 됨 Attribute eBGP iBGP Next-Hop - 업데이트가 AS를 넘을 때 설정 - 일반적으로 수정되지 않음 - Next-Hop-Self를 변경할 수 있음 BGP Next-Hop Issue 해결 방법 1. DMZ Network를 IGP에 포함 2. "Next-
[BGP] BGP Split-Horizon Issue [내부링크]
BGP Split-Horizon Issue BGP Split-Horizon Issue 해결 방법 1. Full Mesh 설정 2. Route Reflector 설정 3. Confederation 설정 BGP Split-Horizon Issue 해결 BGP도 Distance Vector이므로 라우팅 루프를 방지하기 위한 Split-Horizon이 적용됨 Split-Horizon - iBGP로 광고 받은 네트워크는 iBGP로 광고하지 못함 1. Full Mesh 설정 Full-Mesh는 확장성이 제한된 설계 "n*(n - 1)/2" Session이 필요함 TCP로 인해 Overhead가 증가함 R2에서 R4로 송신한 라우팅 정보가 물리적으로 R3을 지나지만 R3은 일반 데이터처럼 목적지 라우터(R4)로 전송 2. Route-Reflector 설정 iBGP Neighbor라도 Route-Reflector와 해당 Client에 대해서는 iBGP Split-Horizon 적용하지
[BGP] BGP Confederation [내부링크]
BGP Confederation Overview RFC 5065에 정의됨 - 기존에 사용되던 RFC 3065가 폐지됨 하나의 AS를 작은 AS로 나눌 수 있음 Confederations 장점 BGP 라우터가 많은 AS를 보다 작은 Domain으로 세분화할 수 있음 BGP에 포함된 정보를 사용해 경로 정책을 제어할 수 있음 Full-Mesh 요구사항을 완화할 수 있음 Confederations 원리 외부 AS에서는 Confederation 전체가 하나의 AS로 간주함 내부의 각 AS는 독립 실행형 AS로 간주됨 하나의 AS를 최대 15개의 AS로 나눌 수 있음 - Nokia 7750 SR 기준 모든 라우터는 Confederation을 지원해야 함 BGP Confederation Attribute Confederations Attribute - AS-PATH AS를 넘으면 AS-PATH가 수정됨 - BGP Confederation AS를 넘어가도 AS-PATH를 수정함
[BGP] BGP Route-Reflector [내부링크]
BGP Route-Reflector Overview BGP Route-Reflector Overview iBGP Peer에 대해 iBGP Split Horizon을 사용하지 않도록 함 - iBGP로 학습한 경로를 iBGP에게 광고할 수 있음 RFC 4456에 정의됨 Route-Reflector을 사용하여 iBGP 학습 경로를 iBGP Peer에 광고하는 것을 Reflection이라고 함 Nokia 7750 SR은 BGP "always-compare-med" 명령어를 사용하면 Routing Loop 또는 MED(BGP 경로 선택 프로세스 중)를 전혀 고려하지 않을 수 있음 BGP Route-Reflector 용어 용어 설명 Route -Reflector - Split-Horizon 규칙을 면제받은 라우터 - Route-Reflector는 다시 다른 Route Reflector의 Client가 될 수 있음 Route -Reflector Client - Route-Reflector
[BGP] BGP Attribute Type [내부링크]
BGP Attribute Type Attribute Type의 분류는 BGP에서의 동작과 처리를 정의함 Well-known Mandatory 모든 BGP 장비에서 인식되어야 함 모든 Update Message에 포함되어야 함 수신 라우터에 해당 Attribute가 업데이트에 없을 경우 Notification을 송신함 - 일반적으로 BGP Neighbor가 중단됨 Well-known Discretionary 모든 BGP 장비에서 인식되어야 함 Update Message에 선택적으로 포함함 모든 장비가 어떤 것인지 인식은 하지만 BGP Update 메시지에는 없을 수도 있는 속성 Optional Transitive 모든 BGP 장비에서 인식할 필요는 없음 Update Message에는 Transitive Flag가 포함됨 특정 Optional Transitive 속성을 지원하지 않으면 속성 Flag 중 Partial Bit를 1로 설정해 Neighbor에게 전송 라우
[BGP] BGP Attribute - Weight [내부링크]
BGP Attribute - Weight (Cisco) BGP Attribute - Weight Cisco 전용 속성과 달리 Weight는 해당 라우터에서만 의미를 가지며 Neighbor에게 전송되지 않음 높은 값이 선호됨 외부로 가는 경로를 결정할 때 사용 - BGP를 통해 받으면 Weight 값은 0이며 본인이 BGP에 포함시키면 32768 Weight 설정 - 0~65535의 값을 가질 수 있음 - Default로 Neighbor에게 배운 경로는 Weight=0이며 자신이 생성한 경로는 Weight=32768 - 장비 내부에서 특정 경로로 가는 OIF를 결정할 때만 의미가 있으며 Neighbor에게 전달되지 않음
[BGP] BGP Attribute - Origin [내부링크]
BGP Attribute - Origin BGP Attribute - Origin 라우팅 정보를 생성하는 원래 AS에 의해 생성됨 낮은 값이 선호됨 Well-Known Mandatory이므로 모든 BGP Update Message에 포함됨 다른 AS로 BGP Update를 해도 절대 변경되어서는 안 됨 최초로 Update한 라우터에서 해당 NLRI가 IGP로 학습되었으면 Origin Code는 "i"로 설정됨 Name Code Value Meaning IGP i 0 - 해당 NLRI는 IGP를 통해 학습됨 - 원래 AS에 대한 내부에서 학습됨 EGP e 1 - 해당 NLRI는 EGP를 통해 학습됨 Incomplete ? 2 - 해당 NLRI는 다른 방법으로 학습 (Redistribution 등) - 축약된 경로는 축약 전 상세 네트워크 중에서 가장 높은 순위의 것으로 선택 Origin - Redistribution이 되면 어떤 프로토콜로부터 배운 것인지 구분할 수 없어 "
[BGP] BGP Attribute - AS-PATH [내부링크]
BGP Attribute - AS-Path BGP Attribute - AS-Path Well-Known Mandatory 속성 라우팅 루프를 방지 - eBGP Neighbor에게 수신한 라우팅 정보에 자신의 AS가 있으면 루프가 발생했음을 의미하므로 버림 - Local AS가 포함된 Update를 수신하면 Loop Flag가 지정됨 Update Message가 해당 네트워크까지 가는 경로상에 있는 AS들을 기록해 놓은 속성 AS-PATH가 짧은 경로가 선택됨 AS Border 라우터가 Update를 전파할 때 수정됨 iBGP Peer로 Update 시 AS-PATH는 변경되지 않음 AS를 추가한다면 Local-AS를 사용하는 것이 가장 좋음 BGP Update가 발생한 최초 AS의 AS-PATH는 "Null"임 iBGP와 eBGP의 처리가 다르게 됨 Attribute eBGP iBGP AS-PATH - 업데이트가 AS를 넘을 때 추가됨 - 수정되지 않음 AS-Pat
[BGP] BGP Attribute - MED [내부링크]
BGP Attribute - MED(Multi-Exit Discriminator) BGP Attribute - MED(Multi-Exit Discriminator) Optional Non-Transitive 속성 작은 값이 우선시함 MED는 동일한 AS에서 수신한 것만 비교함 - Cisco에서 서로 다른 AS에서 수신한 MED를 강제로 비교하려면 "bgp always-compare-med"를 설정하면 됨 인접 AS에서 들어오는 경로를 조정할 때 사용 Local-AS에 대한 기본 진입점을 정의함 MED 값 결정 및 전송 방법 iBGP로 전송 시 - iBGP Peer 간에 MED 값이 변경 없이 전송됨 eBGP로 전송 시 - iBGP Peer에게 수신한 MED 값은 무시하고 전송하지 않음 · 수신 측에서는 라우팅 정보에 MED 값이 없으면 0으로 간주 - 자신이 eBGP에 포함시킨 네트워크의 MED 값은 전송함 · 이때의 MED 값은 해당 네트워크의 IGP Metric 값을 사
[BGP] BGP Attribute - Local-Preference [내부링크]
BGP Attribute Local-Preference BGP Attribute Local-Preference Well-Known Discretionary 속성임 값이 높은 것이 우선시함 인접 AS로 나가는 경로를 조정할 때 사용 iBGP Peer 간에만 전달되며 AS 외부로는 전송되지 않음 - eBGP Peer에게 Local-Preference를 수신하면 해당 Attribute는 무시됨 ① : R4에게 Local-Preference 값이 200이라고 알림 ② : Local-Preference가 높은 R1이 우선한다는 것을 알게 됨 ② : 이미 R3에게 자신의 Local-preference 값을 전송한 경우라면 취소 메시지를 보내고 전송하기 전이라면 자신의 Local-preference 값은 R3에게 전송하지 않음 Local Preference 설정 - 0~4294967295의 값을 가질 수 있음 Local-Preference Policy Example (Nokia 7
[BGP] BGP Attribute - Atomic-Aggregate [내부링크]
BGP Attribute - Atomic-Aggregate BGP Attribute - Atomic-Aggregate Well-Known Discretionary 속성임 축약으로 인하여 원래의 AS 경로 정보가 없어졌을 수도 있음을 표시함 - 일부 특정 정보가 손실되었음을 의미함 해당 속성을 가진 네트워크는 다시 상세 네트워크로 분할해서는 안 됨 - 상세 네트워크로 분할하면 축약되기 전의 동일한 상세 네트워크와 혼동되어 제대로 라우팅이 되지 않을 수 있음 - 다른 BGP Peer에게 광고할 때 해당 경로의 NLRI를 구체적으로 생성하지 않음 해당 속성이 있는 경로를 수신하면 해당 속성을 다른 라우터로 전파할 때 경로에서 제거하지 않음 축약 시 기본적으로 BGP Table에 AS 경로가 나타나지 않지만 추가 옵션 명령어를 사용하면 AS정보를 나타나게 할 수 있음 축약을 시행한 장비의 AS만 나타냄 Ex) AS-PATH의 AS-SET - AS-SET은 괄호 {} 안에 표시된
[BGP] BGP Attribute - Aggregator [내부링크]
BGP Attribute - Aggregator BGP Attribute - Aggregator Optional Transitive 속성임 축약된 네트워크에 표시하는 속성이며 해당 네트워크를 축약한 장비의 AS와 R-ID 표시함 Loop 방지 용도로만 사용하며 AS-PATH 길이에 의한 경로 선택에는 사용하지 않음 Aggregation 시 Atomic_Aggregate 필드에 표시하여 Aggregation이 되었다는 것을 알림 Aggregator - Aggregation을 한 R2의 R-ID를 Aggregator로 표시함 - 기본적으로 Aggregation 시 AS-Path List에서 원래 AS인 AS 10의 정보가 사라짐 · R1은 동일한 경로를 다시 수신해도 Loop를 감지할 수 없음 · 해당 문제를 해결하기 위해 Aggregation 시 "as-set"옵션을 추가적으로 사용해야 함 - "as-set"옵션 적용 후 R1은 수신한 Route 정보에 Local-AS(10)
[BGP] BGP Attribute - Community [내부링크]
BGP Attribute - Community BGP Attribute - Community RFC 1997에 정의됨 - 2Byte AS Number일 경우 Community를 정의함 - 보통 2Byte Base Community를 사용함 RFC 4360에 정의됨 - 4Byte AS Number일 경우 Extended Community를 정의함 Optional Transitive 속성임 Community를 인식하지 못하는 라우터는 Routing Update를 통과시킴 네트워크를 특정 그룹으로 묶어서 라우팅 정책 설정을 쉽게 해줌 공통 속성 또는 특성을 공유하는 경로 집합을 그룹화한 것 BGP Route에 Tagging 할 때 사용 Community 값은 Local에서 관리됨 한 경로에 대해 여러 Community 값이 존재할 수 있음 Community 장점 Community를 사용하여 특정 라우팅 정보를 수락하거나 다른 Neighbor에게 광고하는 것을 제어할 수
[BGP] BGP Dampening [내부링크]
BGP Dampening 링크가 업•다운을 반복할 때 해당 네트워크에 대한 광고를 일정 기간 동안 차단하는 것 BGP Route Dampening와 IP Event Dampening으로 구분됨 BGP Route Dampening BGP에서만 사용되는 Route Dampening 업•다운을 반복하는 외부 AS의 네트워크를 특정 시간 동안 BGP로 광고되는 것을 차단하는 것 iBGP를 통하여 수신한 외부 AS 경로는 Dampening 하지 않음 네트워크가 다운될 때마다 벌점이 쌓이고 벌점이 한도를 넘어서면 특정 기간 동안 광고를 차단함 - 네트워크가 안정되면 다시 광고함 Route Dampening 용어 설명 Flap - 경로의 상태가 Up에서 Down으로 바뀌는 것 History State - 한 번 이상의 Flap이 발생하여 벌점을 받은 상태 Penalty (벌점) - Flap이 일어날 때마다 부과되는 벌점을 뜻함 Damp State - 벌점이 기준을 초과하여 해당 네트워
[BGP] BGP Load Balancing [내부링크]
BGP Load Balancing BGP는 기본적으로 Load Balancing을 하지 않음 BGP 경로가 Load Balancing이 되려면 반드시 모든 속성의 값이 동일해야 함 BGP 경로를 Load Balancing 시키는 방법 1. IGP 또는 정적 경로 이용 2. Multipath 명령어 이용 - Cisco Config : maximum-path 3. DMZ 링크 대역폭 기능 이용 BGP Load Balancing 방법 BGP 경로 Load Balancing - IGP 또는 정적 경로 이용 두 eBGP 간에 Static 경로로, iBGP 간에는 IGP(OSPF)로 Load Balancing이 이뤄짐 다른 AS와 연결되는 경계 라우터가 여러 대 일 때 경계 라우터들간에 BGP Load Balancing이 안 됨 BGP 경로 Load Balancing - Multipath 명령어 이용 다른 AS와 연결되는 경계 라우터가 여러 대 있어도 경계 라우터들간에 BGP Load
[Mirror Service] Mirroring Service 개요 [내부링크]
Mirroring Service 개요 Mirroring Service 개요 Port Mirroring - 한 포트에서 송수신되는 트래픽을 다른 포트로 복제할 수 있음 Nokia 7750 SR의 Mirror Source는 Port, SAP, MPLS Label, IP Filter, MAC Filter일 수 있음 Mirror Source - Mirroring할 특정 지점의 트래픽 소스 Mirror Destination - Mirroring된 트래픽이 전송되는 위치 - 복제된 트래픽은 Local 장비뿐만 아니라 SDP를 통해 Remote 장비로도 보낼 수 있음 - 복제된 패킷이 전달됨 원래 Forwarding 되어야 할 포트로는 원본 패킷이 전달됨 Mirror Destination으로 전송되는 Mirror Frame의 Size는 Slicing 기능을 사용하여 구성할 수 있음 - 분석을 위해 Header만 복사하여 고객 데이터의 무결성과 보안을 보호할 수 있음 Local Mirr
[IES] IES(Internet Enhanced Services) Overview [내부링크]
IES(Internet Enhanced Services) Overview IES(Internet Enhanced Services) Overview IES는 고객이 IP 라우터 인터페이스와 통신하여 인터넷 트래픽을 송수신하는 라우팅 연결 서비스임 IES를 통해 고객에게 직접 인터넷 액세스 제공함 - 고객의 관점에서 보면 IES는 인터넷에 직접 제공되는 것 IES 특성 고객 소유 IP 인터페이스를 분리하기 위해 여러 IES 서비스가 생성됨 IES를 이용하여 설정된 인터페이스가 Global Routing Table과 동일한 라우팅에 참여할 수 있음 - Remote 라우터로 트래픽을 Tunneling 한다는 개념이 필요하지 않음 IES는 기본적으로 고객에게 L3 인터페이스를 제공하는 방법임 - 일반 L3 인터페이스와 유사하지만 SAP로 구성된 포트와 함께 서비스로 처리됨 - SAP : Ethernet Null, dot1Q, Q-in-Q와 같은 여러 Encap Type을 지원함 다
[IES] IES Case Study - Standard IES [내부링크]
IES Standard IES Case Study (Nokia 7750 SR) 작업 개요 목적 IES을 설정하여 동작을 확인한다. 일자 2022.11.05(토) 테스트 내용 1. IES Standard IES Case Study - 구성도 2. CE1↔PE1 Interface 설정 3. CE1↔PE1 Interface 설정 확인 4. CE1↔PE1 OSPF 설정 5. CE1↔PE2 Ping Test 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 1. IES Standard IES Case Study - 구성도 2. CE1↔PE1 Interface 설정 R1 (CE1) config router interface "p1/1/5:1" address 1.1.12.1/24 port 1/1/5:1 no shutdown exit interface "p1/1/5:2" address 1.1.21.1/24 port 1/1/5:2 no shutdo
[Mirror Service] Mirror Service Case Study - Local Mirroring [내부링크]
Local Mirror Service 설정 요구 사항 Local Mirror Service 설정 요구 사항 Mirror Destination Parameters - Mirror Destination-ID = Mirror Source-ID - Mirror Destination-SAP Mirror Source Parameters - Mirror Destination-ID = Mirror Source-ID - Source Type 지정 · Source Type : Port, SAP, IP filter, MAC filter, ingress label "configure mirror mirror-dest <service-id> [create] [type <encap-type>]" 명령어 - Mirroring된 트래픽을 보낼 위치를 지정하는 데 사용됨 "debug mirror-source <service-id>" 명령어 - Source에서 Mirroring될 트래픽을 식별하기 위한 트래
[Mirror Service] Mirror Service Case Study - Remote Mirroring [내부링크]
Remote Mirror Service 설정 요구 사항 Remote Mirror Service 설정 요구 사항 Mirror Destination Parameters - Mirror Source Service-ID와 동일한 Mirror Destination-ID - Mirror Destination 서비스에서 Remote Source를 지정함 - Mirror Destination SAP 또는 SDP 구성 필요 Mirror Source Parameters - Mirror Destination Service-ID와 동일한 Mirror Source-ID - Mirror Destination으로서의 SDP 구성 필요 - 하나 이상의 Source Type 지정 · Port, SAP, IP-Filter, MAC-Filter, Ingress Label Mirroring Service Case Study - Remote Mirroring (Nokia 7750 SR) 작업 개요 목적 Remote
[Mirror Service] Mirror Service Case Study - Mirror Slicing [내부링크]
Mirroring Service Case Study - Mirror Slicing (Nokia 7750 SR) 작업 개요 목적 Mirror Slicing을 설정하여 동작을 확인한다. 일자 2022.11.06(일) 테스트 내용 1. Mirroring Service Case Study - 구성도 2. Mirror Slicing 설정 2. Mirror Slicing 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 1. Mirroring Service Case Study - 구성도 2. Mirror Slicing 설정 R3 (PE2) configure mirror mirror-dest 1000 create // Mirror Destination 설정 spoke-sdp 2:1000 create egress vc-label 500 // Mirroring Service VC-Label 설정 back no shutdown back slic
[MPLS L3 VPN] VPRN Overview [내부링크]
VPRN(Virtual Private Routed Network) Overview VPRN(Virtual Private Routed Network)이란 RFC 4364(이전의 RFC 2547)에서 정의됨 IP/MPLS 코어에 걸쳐 L3 라우팅 서비스를 제공 각 PE는 VPRN 서비스당 분리된 테이블을 보유함 IP/MPLS 네트워크를 통해 서로 완전히 격리된 여러 개별 고객 라우팅 네트워크를 구축할 수 있음 VPRN 기능 P는 MPLS를 지원하지만 Customer VPRN을 인식하지 못함 PE는 각 VPRN에 대해 별도의 VRF를 유지함 CE는 RIP, OSPF, BGP와 같은 라우팅 프로토콜을 사용하여 PE 라우터와 Peering함 MP-BGP(Multiprotocol BGP)는 IP/MPLS 망을 통해 고객 경로 정보를 전달하는 데 사용됨 VPRN은 MPLS Label Stack을 활용함 - Transport Label(=LSP Label)은 PE간의 Forward
[MPLS L3 VPN] VPRN 구성요소 [내부링크]
VPRN 구성요소 - VRF(Virtual Routing Forwarding) VRF Overview 각 해당 VPRN에 대한 Customer의 경로가 들어 있음 각 PE에는 각 VPRN 서비스에 대한 VRF가 있음 VPN-IPv4 주소는 PE Control Plane에만 표시됨 Customer의 Prefix를 VRF에서 VPRN으로 내보낼 때 VPN-IPv4가 추가됨 CE는 VPN-IPv4 주소를 인식하지 못함 VPRN 구성요소 - RD(Route Distinguisher) RD(Route Distinguisher) Overview IP/MPLS 네트워크에서 Customer 간의 경로를 구별할 수 있도록 추가된 문자임 - IP/MPLS 네트워크를 통해 교환되는 서로 다른 VPRN 경로가 모두 고유하게 만듦 서로 다른 VPRN의 경로를 구별하는 데 사용됨 VPRN으로 가져올 경로에 영향을 미치지 않음 PE에서 특정 경로가 속한 VPRN(또는 VRF)을 식별하기 위해
[MPLS L3 VPN] VPRN Control Plane Flow [내부링크]
VPRN Control Plane Flow CE1→PE1 Control Plane Flow CE1은 구성된 PE-CE 라우팅 프로토콜을 통해 PE로 전파함 PE1은 경로가 수신된 인터페이스의 구성에 따라 VRF에 Route를 설치함 PE1은 CE1의 경로를 학습하고 PE1은 해당 경로를 VRF로 설치한 후 BGP Table로 자동 광고됨 - BGP Table로 전파할 때 RD를 추가하여 VPN-IPv4 경로가 됨 - Ingress PE에서 RD를 추가하여 VPN-IPv4가 생성됨 - Egress PE에서 RD가 제거되어 VPN-IPv4에서 기존의 IPv4로 복원됨 PE1→PE2 Control Plane Flow MP-BGP Update를 통해 VPN-IPv4가 MPLS 망을 통해 VPRN 라우팅 정보를 배포할 수 있음 PE1↔PE2는 BGP Peer이므로 MP-BGP Update가 교환되는 BGP Session을 가짐 - MP-BGP Update를 통해 서비스에 대한 Rou
[MPLS L3 VPN] VPRN Data Plane Flow [내부링크]
VPRN Data Plane Flow(CE2→CE1) CE2→PE2 Data Plane Flow 1) CE2→PE2로 D-IP가 192.168.1.1인 IP 패킷을 전송함 2) PE2는 Blue VRF와 연결된 인터페이스에서 패킷이 수신됨 3) PE2는 Blue VRF를 사용할 것임을 알고 있음 4) Blue VRF에서 FEC의 Next-Hop은 PE1임 VPRN에 도착하는 데이터는 L2 Encap이 제거되고 PE가 전달 결정(LSP 및 VPN Label 부착)을 내림 PE2→PE1(PE2) Data Plane Flow 1) PE2에서 VPN Label은 서비스를 정의하는 BGP Table에 의해 결정됨 1) LFIB의 Next-Hop에 대한 Label이 결정됨 - 10.10.10.1(PE1)과 관련된 Label은 131071임 - PE2에 의해 Transport Label이 131071로 지정됨 PE2에서 Transport Label은 LFIB에 의해 결정됨 IP/MPLS 망
[MPLS L3 VPN] VPRN Case Study - VPRN Interworking [내부링크]
VPRN Interworking Case Study (Nokia 7750 SR) 작업 개요 목적 VPRN Interwor을 설정하여 동작을 확인한다. 일자 2022.11.11(금) 테스트 내용 1. VPRN Interworking Case Study - 구성도 2. MPLS Core Network OSPF 설정 및 확인 3. MPLS LSP 설정 및 확인 4. MP-BGP 설정 및 확인 5. VPRN Service 생성 및 확인 6. MP-BGP→BGP VPN 경로 교환을 위한 Policy 설정 7. PE VPRN Routing Protocol 설정 8. CE BGP 설정 및 확인 9. CE-PE 간 BGP Neighbor 확인 10. PE VPRN Service 상태 확인 11. PE VPRN Routing Table 확인 12. CE Routing Table 확인 13. PE VPN-IPv4 BGP Table 확인 14. PE VPRN Service FIB 확인 15. CE1→C
[MPLS L3 VPN] VPRN BGP Loop 발생 동작 과정 [내부링크]
VPRN BGP Loop Protection Mechanism VPRN BGP Loop Protection Mechanism 기존의 eBGP Loop 감지 Mechanism은 VPRN에서 Loop를 감지했지만 실제 Loop는 아님 BGP AS는 연속적일 것으로 예상했었지만 MPLS 등장으로 달라짐 기존의 BGP Loop 감지 Mechanism은 VPRN 토폴로지를 고려하여 설계되지 않음 - 이러한 Mechanism은 VPRN 물리적 토폴로지의 상태를 정확하게 반영하지 못할 수 있음 VPRN 토폴로지는 기존 BGP Loop Mechanism으로 탐지할 수 없는 BGP Loop가 발생할 수 있음 - 추가적인 Loop 감지 메커니즘이 필요함 VPRN 추가 BGP Loop Protection Mechanism AS-Path Nullination을 사용한 Loop Protection AS-Path를 사용한 Loop Protection - Private-AS 제거 AS-Overri
[MPLS L3 VPN] VPRN BGP Loop Protection - AS-Path Nullification [내부링크]
VPRN BGP Loop Protection Mechanism - AS-Path Nullification VPRN BGP Loop Protection Mechanism - AS-Path Nullification Remote CE에게 AS-Path에 Provider AS Number만 포함여 광고됨 Local CE에게 경로를 수신하는 PE가 Customer의 AS-Path의 존재를 "Null"로 대체함 - CE에게 수신한 AS-Path Number가 AS-Path에게 유일한 항목이어야 함 - Remote CE가 Local-AS가 없는 Path를 수신하여 Loop를 방지할 수 있음 PE1은 수신된 경로의 AS-Path Number를 제거하기 위해 Nullfication Policy 적용됨 AS-Path Null을 이용한 BGP Loop 무효화 R2 (PE1) configure router policy-options begin // Policy-Option 시작 as-path "Bl
[MPLS L3 VPN] VPRN BGP Loop Protection - Private-AS Remove [내부링크]
VPRN BGP Loop Protection Mechanism - Private-AS Remove VPRN BGP Loop Protection Mechanism - Private-AS Remove "remove-private" Option으로 BGP Peer에 광고하기 전에 Private AS-Path Number를 제거할 수 있음 - 위 예에서 PE2에 "remove-private" Option이 적용됨 - PE2에 의해 CE2로 광고되는 모든 BGP 경로가 Private-AS를 제거함 Nokia 7750 SR은 이미 정의된 AS 번호를 인식하여 Public 및 Private AS를 구분함 - Private AS Number : 64512 ~ 65535 - 테스트를 위해 Blue Network의 AS Number를 65001로 변경함 - 테스트를 위해 Red Network의 AS Number를 65002로 변경함 "null-AS-path"와 "remove-private"의 차
[MPLS L3 VPN] VPRN BGP Loop Protection - AS-Override [내부링크]
VPRN BGP Loop Protection Mechanism - AS-Override VPRN BGP Loop Protection Mechanism - AS-Override Local CE AS-Path Number는 Provider AS-Path Number로 수정되어 Remote CE로 광고함 - Customer AS Number 대신 Provider AS Number가 두 개 사용됨 Provider AS-Path Number가 AS-Path에 두 번 연속 나타나면 해당 BGP Update가 VPRN의 다른 사이트에서 발생했음을 Remote Site에 알려줌 Peer의 AS-Path Number 모두를 BGP Route의 AS-Path에 있는 Local-AS Number로 변경함 "as-override" Option 적용 전 상태 확인 AS-Path Loop를 감지하여 BGP Route는 Best-Path로 인지하지 않음 "as-override" Option 적용 및 확
[MPLS L3 VPN] VPRN BGP Loop Protection - Site of Origin [내부링크]
VPRN BGP Loop Protection Mechanism - Site of Origin(SoO) VPRN BGP Loop Protection Mechanism - Site of Origin(SoO) SoO를 사용하여 AS-Override의 문제점인 Loop를 방지할 수 있음 - SoO는 경로의 원점을 식별하는 데 사용되는 BGP 경로에 부착된 BGP Extended Community Attribute임 특정 Customer Site에서 학습한 경로가 동일한 Site로 다시 광고되지 않도록 함 BGP Peer에 대해 구성된 SoO와 같으면 경로가 광고되지 않도록 차단되어 Route Loop가 방지됨 - SoO는 PE가 경로를 학습하는 Site를 고유하게 식별함 SoO 테스트를 위해 각 PE에 "AS-Override" Optiond을 적용시켜 놓음 CE1↔PE1 및 CE3↔PE3의 SoO 값이 154:10으로 구성됨 CE2↔PE2의 SoO 값이 154:20으로 구성됨 "
[MPLS L3 VPN] VPRN Logical Topology - Full-Mesh / Hub and Spoke [내부링크]
VPRN Logical Topology Type VPRN Logical Topology Type 일반적으로 VPRN의 Logical Topology의 Type은 아래와 같음 - Full Mesh · Provider Core의 모든 PE 간에 LSP Tunnel과 MP-BGP Session이 Full-Mesh를 유지함 - Hub and Spoke - Extranet · 서로 다른 Customer의 서로 다른 사이트 간에 리소스를 공유함 - Overlapping · 음성, 방화벽, 네트워크 관리와 같은 서비스에 액세스하는 데 사용되는 Extranet과 유사함 VPRN Full-Mesh Logical Topology VPRN Full-Mesh Logical Topology BGP Peer를 PE 간 RR로 구성하면 Full-Mesh로 구성할 필요가 없음 VPRN Full-Mesh Logical Topology VPRN Hub and Spoke Logical Topology Spoke
[MPLS L3 VPN] VPRN Logical Topology - Extranet / Overlapping [내부링크]
VPRN Logical Topology Type VPRN Logical Topology Type 일반적으로 VPRN의 Logical Topology의 Type은 아래와 같음 - Full Mesh · Provider Core의 모든 PE 간에 LSP Tunnel과 MP-BGP Session이 Full-Mesh를 유지함 - Hub and Spoke - Extranet · 서로 다른 Customer의 서로 다른 사이트 간에 리소스를 공유함 - Overlapping · 음성, 방화벽, 네트워크 관리와 같은 서비스에 액세스하는 데 사용되는 Extranet과 유사함 VPRN Extranet Logical Topology VPRN Extranet Logical Topology 서로 다른 두 회사는 선택한 리소스에 연결할 수 있도록 서로 경로를 공유함 - 데이터베이스 정보 및 파일을 공유하거나 그룹 프로젝트에 협력하는 기업을 나타낼 수 있음 Extranet VPRN 서비스는 서로 다른 여러
[MPLS L3 VPN] VPRN Case Study - Hub and Spoke_1 [내부링크]
VPRN Hub and Spoke Topology Case Study (Nokia 7750 SR) 작업 개요 목적 VPRN Hub and Spoke를 설정하여 동작을 확인한다. 일자 2022.11.15(화) 테스트 내용 1. VPRN Hub and Spoke Topology Case Study - 구성도(물리) 2. VPRN Hub and Spoke Topology Case Study - 구성도(논리) 3. 기본 MPLS L3 VPN Topology 구성 4. Hub PE의 VPRN Community List 생성 5. Hub PE의 Import Policy 정의 6. Hub PE에 VPRN VRF Policy 설정 7. Spoke PE의 VPRN Policy 설정 8. Hub PE VRF Routing Table 확인 9. Spoke PE VRF Routing Table 확인 10. Hub PE에 Spoke-to-Spoke 통신 허용 11. Spoke PE VRF Routing T
[MPLS L3 VPN] VPRN Case Study - Hub and Spoke_2 [내부링크]
VPRN Hub and Spoke Topology Case Study (Nokia 7750 SR) 작업 개요 목적 VPRN Hub and Spoke를 설정하여 동작을 확인한다. 일자 2022.11.15(화) 테스트 내용 1. VPRN Hub and Spoke Topology Case Study - 구성도(물리) 2. VPRN Hub and Spoke Topology Case Study - 구성도(논리) 3. 기본 MPLS L3 VPN Topology 구성 4. Hub PE의 VPRN Community List 생성 5. Hub PE의 Import Policy 정의 6. Hub PE의 VPRN VRF Policy 설정 7. Spoke PE의 VPRN Policy 설정 8. PE의 VPRN 1 eBGP Policy 설정 9. Hub PE의 VPRN 10 eBGP 설정 10. Hub CE Policy 정의 11. Hub CE BGP 설정 12. Hub PE BGP AS-Path Loop
[MPLS L3 VPN] VPRN Case Study - Extranet [내부링크]
VPRN Extranet Topology Case Study (Nokia 7750 SR) 작업 개요 목적 VPRN Extranet을 설정하여 동작을 확인한다. 일자 2022.11.17(목) 테스트 내용 1. VPRN Extranet Topology Case Study - 구성도 2. 기본 MPLS L3 VPN Topology 구성 3. PE1의 Extranet VPRN 구성 4. PE1의 Extranet Site에 대한 Export Policy 5. PE1의 Extranet Site에 대한 Import Policy 6. PE1에 Extranet VPRN 적용 7. PE2에 VRF-Target 설정 8. PE1의 VRF Route 확인 9. PE2의 VRF Route 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 1. VPRN Extranet Topology Case Study - 구성도 CE↔PE 간에 eBGP로 연동함
[MPLS L3 VPN] VPRN Case Study - Overlapping [내부링크]
VPRN Overlapping Topology Case Study (Nokia 7750 SR) 작업 개요 목적 VPRN Overlapping을 설정하여 동작을 확인한다. 일자 2022.11.18(금) 테스트 내용 1. VPRN Overlapping Topology Case Study - 구성도 2. 기본 MPLS L3 VPN Topology 구성 3. PE1의 Internet VRRN에 적용할 BGP Import Policy 정의 4. PE1의 Internet VPRN 설정 5. PE1의 Internet VPRN BGP 설정 6. PE1의 Internet VPRN Routing Table 확인 7. PE1에 Import Policy를 위해 Community-List 정의 8. PE1의 Green VPRN에 대한 Import Policy 정의 9. PE1의 Red VPRN에 대한 Import Policy 정의 10. PE1의 Internet VPRN에 대한 Import Policy 정
[MPLS L3 VPN] VPRN Spoke-SDP Termination [내부링크]
VPRN Service의 Spoke-SDP Termination VPRN Service의 Spoke-SDP Termination Overview L2 VPN 서비스의 Spoke-SDP와 L3 VPRN 서비스를 상호 연결하는 기능임 - SDP는 GRE 또는 MPLS로 생성될 수 있음 L3 VPN에서 Spoke-SDP는 VPRN IP Interface로 직접 Termination됨 논리적으로 Network Port에 들어가는 Spoke-SDP는 Service SAP으로 들어간 것처럼 L3 서비스에 연결됨 VPRN Service의 Spoke-SDP Termination Spoke-SDP에서 VPRN으로 들어오는 트래픽은 Access QoS Policy가 아닌 Network QoS Policy를 사용함 - Network QoS Policy는 SDP에 바인딩될 때 VPRN 서비스에 적용됨 지정된 VPRN 서비스로 Termination될 트래픽은 패킷에 있는 SDP-ID 및 VC-La
[IES] IES Spoke-SDP Termination [내부링크]
VPRN Service의 Spoke-SDP Termination L3 Service Spoke-SDP Termination Overview L2 VPN 서비스의 Spoke-SDP와 L3 IES를 상호 연결하는 기능임 - SDP는 GRE 또는 MPLS로 생성될 수 있음 L3 IES에서 Spoke-SDP는 IES IP Interface로 직접 Termination됨 논리적으로 Network Port에 들어가는 Spoke-SDP는 Service SAP으로 들어간 것처럼 L3 서비스에 연결됨 IES Spoke-SDP Termination Overview Spoke-SDP에서 IES으로 들어오는 트래픽은 Access QoS Policy가 아닌 Network QoS Policy를 사용함 - Network QoS Policy는 SDP에 바인딩될 때 IES에 적용됨 지정된 L3 서비스(IES)에서 Termination될 트래픽은 패킷에 있는 SDP-ID 및 VC-Label로 식별됨 - L
[MPLS L3 VPN] Inter-AS VPRN Model Overview [내부링크]
Inter-AS VPRN Overview Inter-AS VPRN 사용 이유 서로 다른 Provider에 연결된 고객의 VPRN을 연결하기 위해 사용함 VPRN의 두 Site가 서로 다른 AS에 연결되어 있는 경우 PE는 iBGP 연결을 할 수 없음 - eBGP를 사용하여 VPN-IPv4를 배포하려면 몇 가지 다른 방법을 사용해야 함 Inter-AS Model Type 두 개 이상의 VPRN AS를 상호 연결하는 Model Model A - AS Border 라우터에서 VRF-to-VRF 연결 Model B - Neighbor AS로 Labeling된 VPN-IPv4 경로의 eBGP Redistribution Model C - Source 및 Destination PE 간에 Label이 지정된 VPN-IPv4 경로의 Multi-hop eBGP Redistribution - Neighbor AS로 Labeling된 VPN-IPv4 경로의 eBGP Redistribution
[MPLS L3 VPN] Inter-AS VPRN Model A [내부링크]
Inter-AS VPRN Model A Overview Inter-AS VPRN Model A Overview PE/ASBR는 다른 AS의 PE/ASBR 라우터에 직접 연결됨 각 PE/ASBR은 다른 PE/ASBR을 CE처럼 처리함 - eBGP를 사용하여 Label이 지정되지 않은 IPv4 경로를 Peer에 광고함 VRF-to-VRF 접근 방식이라함 Inter-AS 구간은 MPLS가 필요 없음 Inter-AS Model A 단점 PE/ASBR에 VPRN별 구성이 필요하므로 확장성 제한 있음 VPRN의 수가 증가함에 따라 관리가 쉽지 않을 수 있음 Inter-AS VPRN Model A Control/Data Plane Inter-AS VPRN Model A - Control Plane 1) CE1은 192.168.1.0/24을 IPv4로 PE1에 광고함 2) PE1은 IPv4를 VPN-IPv4 경로로 변환하고 VPN Label V1을 할당하고 업데이트를 ASBR1로 보냄
[MPLS L3 VPN] VPRN Case Study - Inter-AS VPRN Model A [내부링크]
Inter-AS VPRN Model A Case Study (Nokia 7750 SR) 작업 개요 목적 Inter-AS VPRN Model A를 설정하여 동작을 확인한다. 일자 2022.11.23(수) 테스트 내용 1. Inter-AS VPRN Model A Case Study - 구성도 2. CE↔PE eBGP 설정 3. CE↔PE eBGP 확인 4. ASBR1↔ASBR2 eBGP 설정 5. ASBR1↔ASBR2 eBGP 확인 6. CE1 Routing Table 7. PE1 VRF Routing Table 8. PE1 VPN-IPv4 Advertised Routes 9. PE1 VPN-IPv4 Received Routes 10. PE1 VPN-IPv4 BGP Table 11. CE1→CE2 Ping Test 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 1. Inter-AS VPRN Model A Case Study - 구성
[MPLS L3 VPN] Inter-AS VPRN Model B [내부링크]
Inter-AS VPRN Model B Overview Inter-AS VPRN Model B Overview ASBR↔ASBR 간에 VPN-IPv4 교환을 위한 MP-eBGP를 생성함 - ASBR은 MP-eBGP를 사용하여 Peer에게 VPN-IPv4 경로를 전송함 ASBR에 VPRN을 생성할 필요가 없음 ASBR-to-ASBR 접근 방식이라함 VPN-IPv4 Prefix를 여러 Provider를 통해 전송할 수 있음 VPN-IPv4 Prefix를 전송할 때 MP-iBGP와 MP-eBGP의 차이점 - eBGP Session은 Next-Hop이 변경되어 LSP Path는 업데이트를 시작하는 ASBR에서 종료됨 - 그러므로 ASBR은 MP-eBGP를 통해 ASBR Peer에 경로를 광고하기 전에 경로에 대한 새 Label을 할당해야 함 ASBR은 MP-eBGP Update를 통해 ASBR Peer에 경로를 광고하기 전에 경로에 새 Label을 할당함 두 ASBR을 연결하는
[MPLS L3 VPN] VPRN Case Study - Inter-AS VPRN Model B [내부링크]
Inter-AS VPRN Model B Case Study (Nokia 7750 SR) 작업 개요 목적 Inter-AS VPRN Model B를 설정하여 동작을 확인한다. 일자 2022.11.23(수) 테스트 내용 1. Inter-AS VPRN Model B Case Study - 구성도 2. CE↔PE eBGP 설정 3. CE↔PE eBGP 확인 4. ASBR1↔ASBR2 eBGP 설정 5. ASBR1↔ASBR2 eBGP 확인 6. PE1↔ASBR1 eBGP 확인 7. CE1 Routing Table 8. PE1 VRF Routing Table 9. PE1 VPN-IPv4 Advertised Routes 10. ASBR1 VPN-IPv4 Advertised Routes 11. ASBR↔ASBR 간에 eBGP Inter-AS-Label 확인 12. CE1→CE2 Ping Test 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 1
[MPLS L3 VPN] Inter-AS VPRN Model C [내부링크]
Inter-AS VPRN Model C Overview Inter-AS VPRN Model C Overview 구분 내용 ① - Remote AS에 대한 모든 /32 System IP에 대한 Label이 지정된 IPv4 경로 교환 - BGP Family : vpn-ipv4, ipv4 · IPv4 용도 : 다른 AS의 /32 System IP에 대해 Label이 지정된 IPv4 경로 교환 · VPN-IPv4 용도 : 다른 AS의 RR과 MP-eBGP를 맺은 RR에게 Customer의 경로 전파 ② - PE와 RR 사이의 VPN-IPv4 고객 경로 교환 - Remote AS의 모든 /32 System IP에 대해 Label이 지정된 IPv4 경로 전파 - BGP Family : ipv4 · IPv4 용도 : 다른 AS의 /32 System IP에 대해 Label이 지정된 IPv4 경로 교환 ③ - 서로 다른 AS 간의 VPN-IPv4 Customer 경로 교환 - BGP Family :
[MPLS L3 VPN] VPRN Case Study - Inter-AS VPRN Model C [내부링크]
Inter-AS VPRN Model C Case Study (Nokia 7750 SR) 작업 개요 목적 Inter-AS VPRN Model C를 설정하여 동작을 확인한다. 일자 2022.11.25(금) 테스트 내용 1. Inter-AS VPRN Model C Case Study - 구성도 2. CE↔PE eBGP 설정 3. CE↔PE eBGP 확인 4. ASBR1↔ASBR2 eBGP 설정 5. AS 내부 IPv4에 대한 Label 광고 설정 6. ASBR1 eBGP Session 확인 7. ASBR에서 Labeling된 IPv4를 광고하기 위한 Policy 설정 8. ASBR1 eBGP Session 확인 9. ASBR1이 광고 받는 IPv4 Prefix의 실제 Label 확인 10. ASBR1 Routing Table 확인 11. PE1 Routing Table 확인 12. AS의 RR 간에 MP-eBGP Session 구성 13. RR1에서 다른 RR 간의 MP-eBGP Sess
[MPLS L2 VPN] VPWS Overview [내부링크]
VPWS(Virtual Private Wire Service) Overview VPWS(Virtual Private Wire Service) Overview VLL이라고도 함 전용선처럼 Point-to-Point Service를 제공함 고객 데이터를 캡슐화하여 GRE 또는 MPLS Tunnel을 통해 전송함 VPWS는 MAC 학습이 필요하지 않기 때문에 L1 VPN이라고도 함 VPWS Type Type Description Epipe - Point-to-Point Ethernet Service를 제공함 - VLAN Tag가 지정된 Ethernet Frame을 지원함 Apipe - Point-to-Point ATM Service를 제공함 Fpipe - Point-to-Point Frame-Relay Service를 제공함 Cpipe - Point-to-Point TDM Service를 제공함 Ipipe - 서로 다른 L2 기술 간의 IP-Interworking 기능 제공 VPW
[MPLS L2 VPN] VPLS Overview [내부링크]
VPLS(Virtual Private LAN Service) Overview VPLS(Virtual Private LAN Service) Overview VPLS 특성은 RFC 4665 및 RFC 4762에 정의됨 - RFC 4665 : Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks - RFC 4762 : Virtual Private LAN Service Using LDP Signaling IP/MPLS 네트워크를 통해 단일 이더넷 스위치에 여러 사이트를 연결함 - VPLS를 사용하는 고객은 지리적으로 분산되어 있더라도 동일한 LAN에 있는 것으로 보임 VPLS는 MAC 주소를 기반으로 트래픽을 처리함 VPLS는 VPWS를 멀티포인트 서비스로 향상시킨 것임 VPLS(Virtual Private Wire Service) 이점 VPLS 이점 - Customer 모든 Site가 단일 스
[MPLS L2 VPN] VPLS MAC Learning 동작 과정 [내부링크]
VPLS Virtual Switch(VS) VPLS Virtual Switch(VS) 기능 위 예시는 6개의 서로 다른 Site에서 사용되는 6개의 서로 다른 태그 값을 보여줌 모든 트래픽은 MAC 주소를 기반으로 LSP Tunnel을 사용하여 모든 PE 간에 전달됨 기본적으로 Unknown Destination 패킷은 모든 LSP에서 복제되고 해당 서비스에 참여하는 PE로 전달됨 - 이 작업은 Target이 응답하고 PE에 MAC 주소가 학습될 때까지 수행됨 Ethernet Switch와 VPLS의 동작 차이 - VPLS · VLAN 태그에 관계없이 모든 SAP를 동일한 브로드캐스트 도메인에 병합함 - Ethernet Switch · VLAN 태그를 사용하여 별도의 브로드캐스트 도메인을 생성함 보통 서비스 구분 태그는 Ingerss 시 제거됨 VLAN 태그를 유지해야 하는 경우 Null Encap을 사용하여 SAP을 정의하면 됨 VPLS는 L2SW처럼 SA(SAP/SD
[MPLS L2 VPN] VPLS Management IP [내부링크]
Management IP Interface Management IP Interface VPLS 관리용 인터페이스 구성 관리 인터페이스는 Out-of-Band 방식과 유사하게 작동함 해당 관리용 인터페이스는 Telnet, SSH, SNMP, ping 등과 같은 CPM 프로토콜에 사용될 수 있음 CPM 필터링을 사용하여 이 인터페이스에 대한 액세스를 제한할 수 있음 Management IP Interface 설정 Management IP Interface - 구성도 PE1↔PE2 간에 VPLS 서비스가 설정됨 Management IP Interface 설정 PE1 config service vpls 100 interface MGMT-IP create address 192.168.0.2/24 // VPLS의 MGMT-IP 설정 exit all CE1↔PE1 연결성 확인 PE1→CE1 연결성 확인 CE1→PE1 연결성 확인
[MPLS L2 VPN] VPLS FDB Maintenance - MAC-Aging [내부링크]
VPLS FDB MAC-Aging Disable MAC-Aging Disable MAC-Aging Timer가 Disable된 경우 학습된 MAC을 수동으로 삭제하거나 Flush할 수 있음 MAC-Aging Timer가 Disable되면 FDB 내의 MAC이 Aging Time을 더 이상 증가시키지 않음 - Timer가 증가하지 않아 자동으로 Flush되지 않음 FDB MAC-Aging - 구성도(물리) FDB MAC-Aging - 구성도(논리) CE1→CE5 연결성 확인 FDB MAC-Aging Default-Timer Default Remote-Age Timer : 900 Default Local-Age Timer : 300 MAC-Aging Timer 확인 MAC-Aging Disable 설정 R2 (PE1) configure service vpls 100 sap 1/1/5 disable-aging // SAP의 MAC-Aging 기능을 Disable함 exit all
[MPLS L2 VPN] VPLS FDB Maintenance - MAC-Learning [내부링크]
VPLS FDB MAC-Learning Disable MAC-Learning Disable Local/Remote에 대한 S-MAC이 FDB에 학습되지 않도록 MAC Learning Disable을 사용할 수 있음 각 SAP 또는 Spoke-SDP에 MAC Learning Disable을 설정할 수 있음 MAC Learning Disable 상태에서 VPLS FDB가 비어 있으면 모든 트래픽이 Flooding됨 FDB MAC-Learning - 구성도(물리) FDB MAC-Learning - 구성도(논리) CE1→CE5 연결성 확인 MAC-Learning 확인 각 PE의 FDB에 SAP, SDP에 해당하는 정보로 MAC-Learning함 MAC-Learning Disable 설정 R2 (PE1) configure service vpls 100 sap 1/1/5 disable-learning // SAP의 MAC-Learning 기능을 Disable함 exit all confi
[MPLS L2 VPN] VPLS FDB Maintenance - FDB Size [내부링크]
VPLS FDB Size VPLS의 FDB에 최대 MAC 개수 설정 PE configure service vpls 100 fdb-table-size 250 // 해당 VPLS의 FDB Table Size를 250으로 설정함 exit all 7750 SR은 각 VPLS 당 FDB에서 허용되는 최대 MAC 수를 설정할 수 있음 - VPLS의 Default "fdb-table-size" : 250 각 VPLS의 FDB Size가 Full일 시 FDB에서 공간을 사용할 수 있을 때까지 MAC 학습 기능이 비활성화됨 FDB Size Alarm PE configure service vpls 100 fdb-table-high-wmark 90 // 해당 VPLS의 FDB Size가 90% 이상일 때 경보 생성 fdb-table-high-wmark 70 // 해당 VPLS의 FDB Size가 70% 이하일 때 경보 삭제 exit all FDB Size를 정해놓은 백분율보다 커지면 경보가 생성되
[MPLS L2 VPN] VPLS FDB Maintenance - FDB Unknown MAC [내부링크]
VPLS FDB Unknown MAC Discard Unknown MAC Discard 프레임의 D-MAC이 FDB에 없으면 모든 Unicast를 삭제하는 기능임 "discard-unknown" 기능은 Ethernet에만 적용됨 "discard-unknown" 기능은 D-MAC이 Broadcast 또는 Multicast일 때 Discard 하지 않음 FDB Unknown MAC - 구성도(물리) FDB Unknown MAC - 구성도(논리) Unknown MAC Discard 설정 R2 (PE1) configure service vpls 100 disable-learning // D-MAC이 FDB에 없을 시 Drop함 exit all Unknown MAC Discard 설정 확인 CE1의 ARP에 CE5 정보가 있을 경우 Unicast로 전송하므로 PE에서 Unknown MAC이 Discard됨 Unknown MAC Discard 설정 확인 CE1의 ARP에 CE5 정보가
[MPLS L2 VPN] MPLS L2 VPN 구성요소 [내부링크]
MPLS L2 VPN 구성요소 MPLS L2 VPN 구성요소 구성 요소 내용 SAP - 서비스 네트워크에 대한 가입자의 인터페이스 지점 Customer-ID - 여러 서비스를 그룹화하는데 사용할 수 있는 서비스와 관련된 값 Service-ID - 서비스를 식별하는데 사용되는 값 VC-ID - Service Label에 Signal을 보낼 때 서비스를 식별함 - 이 값은 서비스의 양쪽 끝에서 일치해야 함 - 일반적으로 Service-ID와 동일함 SDP - Egress PE에 서비스 데이터를 전달하는 데 사용할 Transport Tunnel의 논리적 표현 Transport Tunnel - 서비스 데이터를 전송하는 데 사용되는 LSP - 일반적으로 RSVP-TE 또는 LDP로 Signal를 보냄 - SDP가 Transport Tunnel과 연결됨 Service Tunnel - 서비스 끝점인 두 PE가 종단 간 Signal을 보내는 Service Label로 표시됨 Demultiplexe
[MPLS L2 VPN] MPLS L2 VPN Local/Distribute Service [내부링크]
MPLS L2 VPN Local Service MPLS L2 VPN Local Service PE1 config service epipe 50 customer 1 create sap 1/1/4 create // Service에 SAP 적용 back sap 1/1/5 create // Service에 SAP 적용 back no shutdown exit all Local Service에서 서비스의 모든 구성 요소는 단일 라우터에 있음 서비스는 Local 또는 Distribute일 수 있음 MPLS L2 VPN Distribute Service MPLS L2 VPN Distribute Service IP/MPLS 네트워크를 사용하여 서비스를 연결하고 데이터를 전달함 SDP Binding은 Service Label Signal을 보내고 Remote 라우터에 대한 전송을 정의하기 위해 필요함 Service Level View - Logical Transport Tunnel - SDP
[MPLS L2 VPN] SAP Encapsulation [내부링크]
SAP Encapsulation Summary SAP SONET/SDH Encapulation Type SAP SONET/SDH Encapsulation Type BCP-Null - POS 포트에서 단일 IP를 지원하거나 채널화 POS 포트의 경우 채널당 단일 서비스를 지원함 - PPP over SONET 또는 SDH를 사용해 두 장치 간의 단일 서비스를 프리징 하는데 사용됨 BCP-Dot1q - POS 포트 또는 채널에서 여러 서비스가 지원됨 - PPP over SONET 또는 SDH를 사용해 두 장치 간의 단일 서비스를 프리징 하는데 사용됨 - Dot1q VLAN 태그는 다양한 서비스를 식별하는데 사용됨 ATM - ATM Frame-Relay - Frame-Relay SAP Ethernet Encapulation Type SAP Ethernet Encapsulation Type Null - 포트에서 단일 서비스 지원 - Encapulation ID가 0으로 설정됨 - Ex) "s
[MPLS L2 VPN] SAP Encapsulation 동작 과정 [내부링크]
SAP Null Encapsulation의 VLAN Tag 동작 과정 SAP Null Encapsulation의 VLAN Tag 동작 과정 VC-Type VLAN Mode에서는 항상 Default VLAN ID = 0인 태그를 추가함 Egress SAP에서 수신된 VLAN Tag를 포함하여 항상 프레임에 SAP에 구성된 Tag을 Encap함 SAP Dot1q Encapsulation의 VLAN Tag 동작 과정 SAP Dot1q Encapsulation의 VLAN Tag 동작 과정 VLAN-VC-Tag가 새 VLAN-ID로 정의된 경우 이 VLAN ID가 서비스 구분 VLAN으로 전송됨 - Default로 VLAN-VC-Tag가 정의되지 않으면 SAP Encap 태그와 일치하는 서비스 구분 태그가 사용됨 VLAN이 서비스 구분 태그일 경우 해당 VLAN이 VC-Type VLAN으로 전송될 수 있지만 Egress SAP에서 제거됨 VC-Type "Ether"를 사용하면 서비스
[MPLS L2 VPN] Service MTU Type 및 Calculation [내부링크]
MTU Type MTU Type L2 Frame에는 Fragment가 지원되지 않음 - L3 Packet은 Fragment를 지원함 FCS는 MTU를 계산할 때 고려되지 않음 T-LDP Signaling되면 서비스의 각 끝에서 MTU가 협상됨 MTU Type 내용 Network Port MTU - 물리적 포트를 통해 전송되는 패킷의 MTU를 제어함 Access Port MTU (SAP MTU) - 물리적 포트를 통해 전송되는 패킷의 MTU를 제어함 - SAP의 MTU를 제어함 SDP Path MTU - 서비스 End-Point간의 SDP MTU를 제어함 - SDP를 통해 전송되는 패킷의 MTU를 제어함 Service MTU - Service MTU를 제어함 - 서비스 전체에서 고객이 보낼 수 있는 MTU를 제어함 MTU Calculation 방법 SDP Path MTU 및 Network Port MTU Calculation "Network Port MTU ≥ Service M
[MPLS L2 VPN] VPWS VPN [내부링크]
Fpipe Service(Frame-Relay VLL) Fpipe Service Point-to-Point Frame-Relay 서비스를 제공함 고객의 관점에서 PE 라우터는 기본적으로 Frame-Relay로 인식되어야 함 Frame-Relay Header가 프레임과 함께 전송되지 않으므로 Fpipe에 대한 "Control Word"가 필요함 Nokia는 Frame-Relay의 DLCI를 Pseudowire에 매핑하기 위한 One-to-One Mode를 지원함 - 즉, 단일 Frame-Relay 회로가 Fpipe 서비스에 매핑됨 프레임이 Fpipe SAP에 도착하면 Frame-Relay Header와 Padding이 제거됨 프레임은 임의의 Pseudowire 서비스에 대해 Service Label 및 Transport Label로 Encap됨 Frame-Relay Header의 특정 값이 4byte인 "Control Word"에 복사됨 - Frame-Relay 프레임이
[MPLS L2 VPN] Spoke-SDP vs Mesh-SDP 동작 과정 [내부링크]
Spoke-SDP vs Mesh-SDP 동작 과정 Spoke-SDP 동작 과정 Spoke-SDP에서 수신된 트래픽은 동일한 서비스에 있는 다른 모든 SDP(Spoke & Mesh) 및 SAP으로 복제됨 수신한 포트에 복제되지 않음 Mesh-SDP 동작 과정 Mesh-SDP에서 수신된 트래픽은 동일한 서비스에 있는 다른 모든 Spoke-SDP 및 SAP로 복제됨 - 동일한 서비스 내의 다른 Mesh-SDP에는 복제되지 않음 수신한 포트에 복제되지 않음 SAP 동작 과정 SAP에서 수신된 트래픽은 동일한 서비스에 있는 다른 모든 SDP(Spoke & Mesh) 및 SAP으로 복제됨 수신한 포트에 복제되지 않음
[MPLS L2 VPN] Epipe Case Study - Epipe Basic Config [내부링크]
Epipe Basic Config Case Study (Nokia 7750 SR) 작업 개요 목적 Epipe를 설정하여 동작을 확인한다. 일자 2022.12.09(금) 테스트 내용 1. Epipe Basic Config Case Study - 구성도(물리) 2. Epipe Basic Config Case Study - 구성도(논리) 3. MPLS LSP 설정 4. MPLS LSP 확인 5. SDP 설정 6. SDP 확인 7. T-LDP 확인 8. Epipe 설정 9. Epipe Service 확인 10. SAP 확인 11. SDP Binding 확인 12. LDP Binding Service 확인 13. CE 간 연결성 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 1. Epipe Basic Config Case Study - 구성도(물리) 2. Epipe Basic Config Case Study - 구성도(논리) IP
[MPLS L2 VPN] VPLS Case Study - VPLS Basic Config [내부링크]
VPLS Basic Config Case Study (Nokia 7750 SR) 작업 개요 목적 VPLS를 설정하여 동작을 확인한다. 일자 2022.12.10(토) 테스트 내용 1. VPLS Basic Config Case Study - 구성도(물리) 2. VPLS Basic Config Case Study - 구성도(논리) 3. MPLS LSP 설정 4. MPLS LSP 확인 5. SDP 설정 6. SDP 확인 7. T-LDP 확인 8. VPLS 설정 9. VPLS Service 확인 10. SAP 확인 11. SDP Binding 확인 12. LDP Binding Service 확인 13. CE 간 연결성 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 1. VPLS Basic Config Case Study - 구성도(물리) 2. VPLS Basic Config Case Study - 구성도(논리) IP/MPLS 망은
[MPLS L2 VPN] VPLS Case Study - H-VPLS Topology [내부링크]
H-VPLS Topology Case Study (Nokia 7750 SR) 작업 개요 목적 H-VPLS을 설정하여 동작을 확인한다. 일자 2022.12.11(일) 테스트 내용 1. H-VPLS Topology Case Study - 구성도(물리) 2. H-VPLS Topology Case Study - 구성도(논리) 3. MPLS LSP 설정 4. MPLS LSP 확인 5. SDP 설정 6. SDP 확인 7. T-LDP 확인 8. VPLS 설정 9. VPLS Service 확인 10. SAP 확인 11. SDP Binding 확인 12. LDP Binding Service 확인 13. CE 간 연결성 확인 테스트 계측기 - 장비 / OS L2 Cisco i86bi-linux-l2-adventerprisek9-15.1c / IOL L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 1. H-VPLS Topology Case Study - 구성도(물리) 2. H-VP
[VRF] VRF Overview [내부링크]
VRF(Virtual Routing & Forwarding) Overview VRF(Virtual Routing & Forwarding) Overview DB(Routing Table 등)에 식별자를 정해 논리적으로 분리하는 기술임 - 식별자를 정하지 않은 DB(Routing Table)는 Global에 해당 라우터를 가상화시킨 것이 아님 VRF가 가상 라우터가 아닌 DB만 가상화시킨 것 - 해당 포트에 IPv4에 대한 VRF를 설정했을 때 IPv6가 들어오면 Global 정보로 인지함 VRF마다 RIB, FIB Table이 따로 있음 VRF 명령어는 Vender 및 OS마다 명령어가 다름 VRF Leaking VRF-to-Global VRF Leaking 경로 조정이나 PBR을 통해 VRF와 Global이 통신할 수 있음 Global-to-VRF VRF Leaking 경로 조정이나 PBR을 통해 VRF와 Global이 통신할 수 있음\ VRF-to-VRF Leaking
[VPN] Tunnel Overview [내부링크]
Tunnel Overview Tunnel 개념 Tunneling이란 데이터를 전달하기 위해 새로운 Header를 붙이는 기술임 보통 터널 사이에 많은 네트워크 장비들이 있음 두 장비 사이에 장비가 없고 터널만 있는 경우는 암호화를 위한 것 Original Header와 Tunnel Header 비교 Original Header 인터넷 망에 진입하기 전 사설망에서 사용되는 Header Tunnel Header 인터넷 망에서 Forwarding 하기 위한 용도 Tunnel 구간에서 Original Header를 볼 필요가 없음 Overlay와 Underlay 비교 Overlay와 Underlay의 공통으로 가장 큰 장점 - Overlay는 외부(사설)의 정보, Underlay는 내부(공인)의 정보만 알면 됨 - Overlay와 Underlay는 서로의 정보를 몰라도 됨 - Overlay 변화 시 Underlay에 영향이 없으며 Underlay 변화 시에도 Overlay에 영
[VPN] GRE Tunnel Overview [내부링크]
GRE Interface Link GRE Interface Link GRE Tunnel의 Link는 기본적으로 Point-to-Point 기반 GRE Tunnel은 물리적인 인터페이스를 사용하지 않고 가상의 인터페이스를 사용함 - 해당 인터페이스를 "Tunnel Interface"라고 함 - 해당 "Tunnel Interface"를 이용하여 직접 연결되어 있는 것처럼 구성 다른 기술을 같이 사용하면 Multi-Point 구성 가능 Point-to-Point 특징 상대방의 주소에 관심이 없음 - 데이터를 던지면 무조건 받을 것이라 생각하기 때문 같은 구간에서 아래와 같이 구성해도 문제없이 통신 가능 Static Routing으로만 설정하면 위 그림같이 Network가 달라도 되지만 Dynamic Routing Protocol을 사용하려면 Network가 같아야 함 - Hello Packet은 같은 네트워크에게 수신한 것만 Neighbor를 맺기 때문 GRE Tunnel 동작
[VPN] GRE Tunnel Header [내부링크]
GRE Tunnel Header GRE Tunnel Header RFC 2890 구조 최초 GRE Tunnel 개발 후 많은 변화가 있었음 (현재 기준 RFC 2890이 최신) 필드 내용 GRE - GRE가 제공하는 서비스를 구분 C - Bit=1일 때 Checksum 필드 사용 - Default로 Disable(명령어로 Enable 가능) - - 1Bit가 비어 있음 - 현재 사용 안 함 - 호환성을 위해 비워둠 K - Bit=1일 때 Key 필드 사용 - Default로 Disable(명령어로 Enable 가능) S - Bit=1일 때 Sequence Number 필드 사용 - Default로 Disable(명령어로 Enable 가능) - Sequence Number 데이터를 전송할 때 번호를 적은 후 전송함 Reserved 0 Reserved 1 - 나중을 위해 비움 Ver(Version) - Version : 0 - GRE는 많이 변경되었지만 계속 Version 0을 유지
[VPN] IP VPN와 MPLS VPN 비교 [내부링크]
IP VPN IP VPN IPSec, GRE 등의 VPN은 데이터에 대한 비밀성, 무결성, 인증을 위해 암호화 알고리즘 및 터널 기술을 제공함 데이터에 대한 암호화 및 복호화, 터널 생성을 위한 Overhead가 큼 VPN의 구성과 관리는 가입자가 담당하는 부분이라 사용자 입장에서 어려움이 있음 IP VPN Architecture 인터넷은 개방성을 추구하여 특별한 제한 사항이 있지 않는 한 전 세계 모든 컴퓨터와 연결될 수 있음 개방형 인터넷을 사설 네트워크처럼 사용하기 위해서는 일반적으로 인터넷 트래픽이 VPN 사용자의 내부로 들어가서는 안 되며 다른 VPN 가입자의 트래픽도 경우에 따라서 선택적으로 받아들일 수 있어야 함 VPN은 인터넷으로부터 독립성을 보장받아야 함 출발지와 목적지간에 전용 터널을 이용하여 가입자 네트워크를 인터넷과 분리시켜 독립성을 제공함 암호화 및 복호화 과정에서 Overhead가 증가된다는 단점을 가지고 있음 MPLS VPN MPLS VPN
[VRF] VRF Case Study - VRF Leaking [내부링크]
VRF Leaking Case Study (Cisco) 작업 개요 목적 VRF을 설정하여 동작을 확인한다. 일자 2022.12.13(화) 테스트 내용 1. VRF Leaking Case Study - 구성도 2. VRF 생성 3. VRF Interface 설정 4. VRF Interface 확인 5. VRF Routing Protocol 설정 6. VRF Routing Protocol Neighbor 확인 7. VRF Routing Table 확인 8. R2↔R5 간 Global EIGRP 설정 9. R2 VRF에 Default-Route 광고 설정 10. Global-to-VRF Static Routing 설정 11. Global-to-VRF Static Route 확인 12. R1 Lo0 → R5 Lo0 연결성 확인 13. Global-to-VRF PBR 설정 (다른 OS ) 14. VRF → VRF Static Routing 설정 15. VRF → VRF Static Route
[Multicast] MDT(Multicast Distribution Tree) [내부링크]
Multicast Distribution Tree Overview Multicast Distribution Tree Overview Distribution Tree는 SPT(Shortest Path Tree)와 ST(Shared Tree)로 구분함 Multicast Group 이란? - 해당 Multicast를 보내는 Server들과 Multicast를 받으려는 Receiver들의 집합 Multicast Routing Table(Multicast Route = Mroute)이 따로 존재 - Multicast Routing Table에 "(S,G)"라는 Table이 생성됨 Multicast를 수신한 Interface로 Multicast를 송신하지 않음 Multicast Distribution Tree의 필요성 Multicast Distribution Tree의 필요성 Receiver 장비에 같은 Multicast Packet이 중복되어 들어올 수 있음 Multicast Dis
[Multicast] mRPF(Multicast Reverse Path Forwarding) [내부링크]
Unicast Routing과 Multicast Routing 비교 Unicast Routing Unicast Routing은 D-IP를 기준으로 어떤 Interface로 전송할 것인지가 중요함 Unicast Routing Process 간략 순서 1. 패킷의 D-IP 확인 2. Routing Table을 Lookup 3. Best-Path로 Forwarding Multicast Routing D-IP가 Multicast Address이므로 Unicast Routing Table에서 Lookup할 수 없음 Multicast를 처리하기 위한 별도의 Routing Table(Mroute)이 필요함 IIF는 OIL에 포함될 수 없음 - Multicast를 받은 Interface로 Multicast를 전송하지 못함 Incoming Interface(IIF) - Multicast를 받아 처리하기 위한 Interface - IIF로 들어오는 Multicast를 받아 처리함 - SPT
[Multicast] uRPF(Unicast Reverse Path Forwarding) [내부링크]
uRPF(Unicast Reverse Path Forwarding)의 필요성 uRPF(Unicast Reverse Path Forwarding)의 필요성 - ① 하나의 IP로 최대 65535의 TCP Session을 맺을 수 있음 - TCP Port가 1~65535이기 때문 하나의 PC에서 IP를 변경하여 TCP Sessioin을 시도하면 방화벽은 다른 장비로 인식함 하나의 PC에서 IP를 변경하여 Syn Packet을 계속 보내면서 방화벽을 공격할 수 있음 IP Spoofing 발생 시 방화벽 과부하로 Down 발생 - S-IP를 변경하여 공격하는 것을 IP Spoofing이라고 함 uRPF(Unicast Reverse Path Forwarding)의 필요성 - ② 공격자가 내부의 다른 PC들에게 S-IP를 방화벽 IP로 변경하여 Syn 패킷을 발생시키면 내부 PC들은 방화벽에게 Syn/Ack를 전송함 IP Spoofing 발생 시 방화벽 과부하로 Down 발생 - S-
[Multicast] Dense-Mode vs Sparse-Mode [내부링크]
Dense-Mode vs Sparse-Mode Overview Dense-Mode vs Sparse-Mode Overview RPF Check 란? - 수신되는 Multicast를 처리할 것인지 정하는 것임 Dense-mode와 Spares-mode 란? - 수신되는 Multicast를 어느 Interface로 내보낼 것인지(OIF List)를 관리하는 것임 - OIF List를 관리하는 방법일 뿐임 Dense-Mode - 무조건 OIF List에 넣고 Prune Message를 받은 인터페이스로 Multicast를 전송하지 않음 Spares-Mode - Multicast 요청(Join 또는 Report)이 있어야 OIF List에 넣고 Multicast를 전송함 Dense-Mode 동작 과정 1. (*,G)에 대한 정보 생성 Multicast를 받으면 Multicast를 관리하기 위해 (*,G)를 생성함 SSM 기술을 사용하면 (*,G)를 생성하지 않음 어떤 인터페이스
[Multicast] Multicast Layer 2/3 Address [내부링크]
Multicast Layer 3 Address Multicast Layer 3 Address IPv4 Multicast Address는 D 클래스에 해당됨 32bit 중에 앞 4개의 Bit가 1110이면 Multicast Address로 지정됨 - 10진수 변경 시 "224.0.0.0 ~ 239.255.255.255"가 Multicast Address임 하나의 IP 당 하나의 Multicast Group을 지원하며 하나의 서비스를 지원함 Multicast IP 내용 224.0.0.0 ~ 224.0.0.255 - Reserved - TTL이 1이므로 다른 Network로 도달이 불가능함 - Local Multicast Address Area라고 함 224.0.1.0 ~ 238.255.255.255 - 공인 Multicast Group 239.0.0.0 ~ 239.255.255.255 239.253.0.0/16 - 사설 Multicast Group - 하나의 사이트에만 사용 시 사
[Multicast] IGMPv1 Overview [내부링크]
IGMP(Internet Group Management Protocol)v1 IGMP(Internet Group Management Protocol)v1 Multicast가 224.0.0.x인 IP주소는 각각의 특징이 있음 Multicast가 들어왔을 때 Routing 시키는 것은 Multicast Routing Protocol임 IGMP는 장비가 IGMP Message를 이용하여 어떤 Service를 받으려는 장비가 어떤 Interface쪽에 있는지만 관리하는 것일 뿐 Multicast Client가 중간에 Multicast 수신을 중단하려면 라우터의 Table에서 Default로 3분을 기다려야함 - Default로 3분 후에 Table에서 정보가 사라짐 - Multicast를 안 받는다는 IGMP Message가 없음 Cisco의 Mroute Table에서 (*,224.0.1.40)은 Cisco에서 Auto로 활성화 된 IGMP Group IGMP Enable 시 확인
[Multicast] IGMPv1 Message 동작 과정 [내부링크]
IGMPv1 Message 종류 IGMPv1 Message 종류 필드 내용 Report - Client가 해당 IP의 Multicast를 보내 달라는 Message임 Query - Multicast를 수신할 Client가 있는지 확인하는 Message임 IGMPv1 Membership Report Message 동작 과정 IGMPv1 Membership Report Message 동작 과정 Client가 해당 IP의 Multicast를 보내 달라는 Message임 Membership Report 발생조건 1. 최초로 Multicast를 요청하는 경우 2. Membership Query를 수신한 경우 위 사진은 PC가 "224.1.1.1"의 Multicast를 받고 싶을 때를 나타냄 중간에 3분 동안 Report Message가 없으면 해당 Multicast를 관리하지 않음 라우터가 1분에 한 번씩 Query를 던지면 Client가 Report Messge를 다시 전송함 M
[Multicast] IGMPv1 Querier Router [내부링크]
Querier Router Query Message를 전송하는 장비를 Querier라고 함 Querier Router 하나의 Subnet에 라우터가 여러 대면 Assert Mechanism으로 인해 Winner가 서비스를 제공하지만 이건 아님 여러 장비가 Query를 보내면 중복된 Query와 Report를 받는 이슈가 발생함 하나의 Subnet에서는 하나의 Querier만 존재함 Querier Router 선출 방법 Querier Router 선출 방법 IGMPv1 - Multicast Routing Protocol(PIM)에서 선출한 DR으로 Querier을 선출함 - DR은 IP가 가장 높은 장비로 선출함 - 위 그림의 IGMPv1의 Querier Router는 R2으로 선출함 IGMPv2 IGMPv3 - DR과 Querier를 분리하기 위해 IP가 가장 낮은 장비를 Qyerier로 선출함 - 위 그림의 IGMPv2/3의 Querier Router는 R1으로 선출함
[Multicast] IGMPv2 Message 동작 과정 [내부링크]
IGMPv2 Message 종류 IGMPv2 Message 종류 필드 내용 Report - Client가 해당 IP의 Multicast를 보내 달라는 Message임 General Query - Multicast를 수신할 Client가 있는지 확인하는 Message임 Specific Query - 라우터가 Leave Message를 받았을 때 Specific Query를 전송함 - Leave Message를 전송한 Client 말고 다른 Client가 Multicast를 받을 것인지 확인하기 위한 것임 Leave - Client에서 중간에 Multicast를 안 받고 싶을 때 사용함 IGMPv2 Membership Report Message 동작 과정 IGMPv2 Membership Report Message 동작 과정 IGMPv1에서 Type 제외하고 모두 동일함 - IGMPv1 참고 IGMPv2 Membership Query Message 동작 과정 IGMPv2 Members
[Multicast] IGMPv2 동작 과정 [내부링크]
IGMPv2 동작 과정 IGMPv2 동작 과정 1. PC1이 D-IP가 224.1.1.1인 Report를 전송함 - IGMP Join 2. 라우터에서 Last Reporter는 PC1로 인식 3. PC2는 D-IP가 224.1.1.1인 Report를 전송함 - IGMP Join - 라우터와 PC1은 Report를 수신함 4. Report를 수신한 라우터와 PC1은 Last Reporter를 PC2로 인식함 5. PC3이 D-IP가 224.1.1.1인 Report를 전송함 - IGMP Join 6. Report를 수신한 라우터와 PC1, PC2는 Last Report를 PC3으로 변경함 - Report를 전송한 103PC는 본인이 Last Reporter임을 알고 있음 7. PC4가 D-IP가 224.2.2.2인 Report를 전송함 - IGMP Join 8. 라우터는 PC4의 Report를 받고 IGMP Group을 추가함 9. 라우터는 주기적으로 224.1.1.1에 대한 Gener
[Multicast] IGMPv3 동작 과정 - Non-SSM / SSM [내부링크]
IGMPv3 Overview IGMPv3 Overview IGMPv2는 많은 Multicast를 모든 Client가 받아야 하는 문제가 생김 IGMPv3는 특정 조건을 붙일 수 있음 - 특정 조건 예시 · S-IP : 192.168.0.1인 Multicast · S-IP : 192.168.1.1을 제외한 나머지 Multicast IGMPv3 동작 과정 - Non-SSM IGMPv3 동작 과정 - Non-SSM Non-SSM은 (*,G)와 (S,G)를 사용해 Multicast 서비스를 제공함 1. Client1은 Group, Source 개수가 1개인 Multicast를 요청함 2. Report를 받은 라우터는 Membership Table을 생성함 - 모든 장비들이 응답하므로 Reporter는 중요하지 않음 - 라우터는 (S,G)로 수신했지만 Membership Table과 Mroute는 (*,G)로 생성함 3. Client2는 Group, Source 개수가 1개인 Multi
[Multicast] IGMPv3 동작 과정 - SSM 문제점 [내부링크]
IGMPv3 동작 과정 - SSM 문제점 IGMPv3 동작 과정 - SSM 문제점 ① 1. Client3은 Group이 1개이며 Source가 All(*,G)인 Multicast를 요청함 2. 라우터의 Membership Table에 Source가 빈 상태로 생성됨 - Mroute에는 (*,G)가 생성될 수 없으므로 (*,224.2.2.2)가 생성되지 않음 - Source를 Any로 요청하면 서비스를 수신하질 못함 · 이럴 땐 SSM용 Multicast 주소를 따로 생성해야 함 IGMPv3 동작 과정 - SSM 문제점 ② 1. Client3은 Group, Source 개수가 1개인 Multicast를 요청함 2. 라우터는 Membership Table, Mroute가 생성됨 3. 라우터 위에서 Source가 4.4.4.4인 Multicast를 수신되면 라우터의 Gi0/1로 Multicast가 전송되므로 224.1.1.1 Group을 요청하는 모든 Client가 응답함 - 때문에 보통
[Multicast] IGMPv3 동작 과정 - General Query / Report / Specific Query [내부링크]
IGMPv3 동작 과정 - General Query / Report IGMPv3 동작 과정 - General Query / Report 1. 이미 Client는 처음 Report를 발송하여 라우터에 위 그림과 같은 Membership Table이 생성된 상태임 2. 라우터가 General Query를 224.1.1.1로 전송하여 모든 Client가 수신함 3. 모든 Client가 받고자 하는 정보가 다르므로 각각 Report를 전송함 - 처음에는 Report의 Type을 "new"로 전송했지만 지금은 이미 전달한 정보이므로 1.1.1.1에 대한 정보만 "Include" 시켜 달라고 Type을 "Include"로 전송함 - General Query를 발생시키면 모든 Client가 Report 메시지를 전송함 4. 라우터가 모든 Report를 수신하면 Membership Table을 계속 유지할 수 있음 IGMPv3 동작 과정 - Specific Query IGMPv3 동작 과정 - S
[Multicast] IGMP Header [내부링크]
IGMPv1 Header IGMPv1 Header 필드 내용 Type - 해당 IGMPv1 Message의 용도를 알려줌 Unused - 사용하지 않은 필드 - All "0"으로 채워짐 - IGMPv2에는 "Max Response Time"으로 채워짐 - IGMPv1의 "Max Response Time"은 All 0으로 적용됨 Checksum - 오류를 확인하기 위한 필드 Group Address - Multicast IP를 알려줌 Type Value Message Type 0x11 IGMP Membership Query Message 0x12 IGMPv1 Membership Report Message IGMPv2 Header IGMPv2 Header 필드 내용 Type - 해당 IGMPv2 Message의 용도를 알려줌 Maximum Response Time - Client가 "Max Response Time"을 수신하면 18등분을 하여 18 등분 중에 언제 Report를 던질 것
[Multicast] Multicast RPF Database [내부링크]
Multicast RPF Database Multicast RPF Database 1. Multicast를 Enable하지 않고 R2에서 Static Routing을 설정하면 10.10.10.0/24에 대한 패킷들은 Gi0/0으로 전송함 2. 두 라우터의 모든 인터페이스에 Multicast가 Enable 되어 있으며 Dense-mode일 경우 R1은 Gi0/0, Gi0/1로 Multicast를 전송함 3. R2는 Multicast를 수신하면 RPF Check를 함 - R2는 Static Routing을 설정했으므로 10.10.10.0/24에 대한 Best-Path는 Gi0/0임 - R2의 Gi0/1은 RPF Check Fail이 됨 4. R2는 Gi0/1으로 수신된 Multicast를 Drop 시킴 - Unicast와 Multicast 모두 R2의 Gi0/0으로 몰림 5. 보통 R2의 Gi0/0으로 Unicast를 전송하고 Gi0/1으로 Multicast를 수신하고 싶어함 - 현재
[Multicast] PIM RPF Check 순서 [내부링크]
PIM(Protocol Independent Multicast) PIM(Protocol Independent Multicast) PIM은 어떤 프로토콜로 생성된 DB인지 관심 없이 가지고 있는 DB를 이용하여 RPF Check DB로 사용함 - 어떤 Unicast Routing Protocol이 사용되든 PIM은 Unicast Routing Table을 이용해 RPF Check를 하면 됨 - RPF Check용 DB가 있으면 해당 DB로 RPF 체크 후 Multicast Routing Table을 생성함 - RPF Check용 DB가 없으면 Unicast Routing Table로 RPF 체크 후 Multicast Routing Table을 생성함 PIM은 Dense-Mode or Sparse-Mode에서 동작할 수 있음 - DVMRP(Distance Vector Multicast Routing Protocol), mOSPF는 Dense-Mode에만 동작함 - CBT는 Spars
[Multicast] PIM Dense-Mode 동작 과정 - First Time [내부링크]
PIM Dense-Mode 동작 과정 - First Time Step ① - Multicast Tree Structure 생성 1. R1은 Multicast를 수신하면 (S,G)정보가 생성됨 2. Source 정보로 RPF Check 3. RPF Check가 성공되면 Multicast가 수신된 인터페이스를 제외한 인터페이스로 Flooding 함 4. R2, R3도 1~3번 과정을 진행 5. R2, R5는 IIF가 아닌 곳으로도 Multicast가 수신됨 - IIF로 수신된 Multicast는 처리하지만 IIF가 아닌 곳으로 수신된 Multicast는 Drop시킴 - R2↔R5는 서로 Multicast를 보내는 중 (Prune Message를 받아야 안 보냄) - IIF로 수신된 Multicast를 Flooding 하므로 가운데 구간은 Multicast가 중복됨 - Assert Mechanism으로 이긴 1대의 장비는 "A"로 표시됨 - Assert Mechanism에서 진 장비는 P
[Multicast] Assert Mechanism [내부링크]
Assert Mechanism Assert Mechanism에서 이긴 장비는 한 대임 하나의 네트워크 당 하나의 장비만 Multicast를 전송함 Assert Mechanism 동작 조건 1. R1, R2는 위에서 동일한 Multicast를 수신함 2. S-IP를 확인하고 RPF 체크함 3. OIL(Out-Going Interface List)로 Multicast를 Flooding 함 4. OIL로 Multicast가 수신됨 - R1, R2는 같은 네트워크에 Multicast를 전송하는 장비가 있다는 것으로 판단함 5. Assert Mechanism 동작 Assert Mechanism 우선순위 1. Multicast S-IP에 대해 Unicast Routing Table의 AD가 낮은 것 - 각 장비가 OSPF, EIGRP로 연동할 때 비교함 2. Multicast S-IP에 대해 Unicast Routing Table의 Metric이 낮은 것 - 각 장비가 같은 Routing
[Multicast] PIM Dense-Mode 동작과정 - Graft / Graft Ack [내부링크]
PIM Dense-Mode 동작 과정 - Graft / Graft Ack PIM Dense-Mode 동작 과정 - Graft / Graft Ack Message 1. 위와 같이 Multicast Tree 구조를 생성함 2. Prune Message를 전송하여 Tree 구조에서 Multicast를 전송할 User가 있는지 확인이 끝난 상태임 3. 처음에 Multicast가 흐르지 않는 곳에 User가 생김 - User는 Multicast를 수신하기 위해 IGMP Report를 전송함 4. IGMP Report를 받은 R10에서 (*,G)가 생성됨 5. (*,G)가 생성된 라우터는 Source에 대한 정보를 알아야 Source 쪽으로 Multicast 요청이 가능함 6. Multicast를 처음 설정하고 Multicast를 수신했을 때 (S,G)가 만들어졌던 것을 보고 (S,G) 정보를 체크함 - Source로 가는 Best-Path를 확인함 · 처음 Multicast를 구성했을 때 찾
[Link Aggregation] Link Aggregation Case Study - PAGP ①(Cisco) [내부링크]
Link Aggregation PAGP ① Case Study(Cisco) 작업 개요 목적 PAGP(Desirable ↔ Desirable)를 사용할 때 Link Aggregation의 동작을 확인한다. 일자 2022.12.27(월) 테스트 내용 01. Link Aggregation PAGP Case Study - 구성도 02. PAGP 설정 03. PAGP 설정 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 인터페이스를 따로 설정하면 Link Aggregation이 정상적으로 안 묶일 수 있음 양쪽 스위치에 Desirable Mode를 사용하면 Link Aggregation이 정상 동작함 01. Link Aggregation PAGP Case Study - 구성도 02. PAGP 설정 SW1 conf t interface range e0/1-2 channel-protoco
[Link Aggregation] Link Aggregation Case Study - PAGP ②(Cisco) [내부링크]
Link Aggregation PAGP ② Case Study(Cisco) 작업 개요 목적 PAGP(Desirable ↔ Auto)를 사용할 때 Link Aggregation의 동작을 확인한다. 일자 2022.12.27(월) 테스트 내용 01. Link Aggregation PAGP Case Study - 구성도 02. PAGP 설정 03. PAGP 설정 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 인터페이스를 따로 설정하면 Link Aggregation이 정상적으로 안 묶일 수 있음 각 스위치에 Desirable Mode와 Auto Mode를 사용하면 Link Aggregation이 정상 동작함 01. Link Aggregation PAGP Case Study - 구성도 02. PAGP 설정 SW1 conf t interface range e0/1-2 channel-pr
[Link Aggregation] Link Aggregation Case Study - PAGP ③(Cisco) [내부링크]
Link Aggregation PAGP ③ Case Study(Cisco) 작업 개요 목적 PAGP(Auto ↔ Auto)를 사용할 때 Link Aggregation의 동작을 확인한다. 일자 2022.12.27(월) 테스트 내용 01. Link Aggregation PAGP Case Study - 구성도 02. PAGP 설정 03. PAGP 설정 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 인터페이스를 따로 설정하면 Link Aggregation이 정상적으로 안 묶일 수 있음 양쪽 스위치에 Auto Mode를 사용하면 Link Aggregation이 동작하지 않음 01. Link Aggregation PAGP Case Study - 구성도 02. PAGP 설정 SW1 conf t interface range e0/1-2 channel-protocol pagp // PAGP
[Link Aggregation] Link Aggregation Case Study - LACP ①(Cisco) [내부링크]
Link Aggregation LACP ① Case Study(Cisco) 작업 개요 목적 LACP(Active ↔ Active)를 사용할 때 Link Aggregation의 동작을 확인한다. 일자 2022.12.27(월) 테스트 내용 01. Link Aggregation LACP Case Study - 구성도 02. LACP 설정 03. LACP 설정 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 인터페이스를 따로 설정하면 Link Aggregation이 정상적으로 안 묶일 수 있음 양쪽 스위치에 Active Mode를 사용하면 Link Aggregation이 정상 동작함 01. Link Aggregation LACP Case Study - 구성도 02. LACP 설정 SW1 conf t interface range e0/1-2 channel-protocol lacp //
[Link Aggregation] Link Aggregation Case Study - LACP ②(Cisco) [내부링크]
Link Aggregation LACP ② Case Study(Cisco) 작업 개요 목적 LACP(Active ↔ Passive)를 사용할 때 Link Aggregation의 동작을 확인한다. 일자 2022.12.28(화) 테스트 내용 01. Link Aggregation LACP Case Study - 구성도 02. LACP 설정 03. LACP 설정 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 인터페이스를 따로 설정하면 Link Aggregation이 정상적으로 안 묶일 수 있음 각 스위치에 Active Mode와 Passive Mode를 사용하면 Link Aggregation이 정상 동작함 01. Link Aggregation LACP Case Study - 구성도 02. LACP 설정 SW1 conf t interface range e0/1-2 channel-pr
[Link Aggregation] Link Aggregation Case Study - LACP ③(Cisco) [내부링크]
Link Aggregation LACP ③ Case Study(Cisco) 작업 개요 목적 LACP(Passive ↔ Passive)를 사용할 때 Link Aggregation의 동작을 확인한다. 일자 2022.12.28(화) 테스트 내용 01. Link Aggregation LACP Case Study - 구성도 02. LACP 설정 03. LACP 설정 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 인터페이스를 따로 설정하면 Link Aggregation이 정상적으로 안 묶일 수 있음 양쪽 스위치에 Passive Mode를 사용하면 Link Aggregation이 동작하지 않음 01. Link Aggregation LACP Case Study - 구성도 02. LACP 설정 SW1 conf t interface range e0/1-2 channel-protocol lac
[Link Aggregation] Link Aggregation Case Study - Static(Cisco) [내부링크]
Link Aggregation Static Case Study(Cisco) 작업 개요 목적 Static(On ↔ On)를 사용할 때 Link Aggregation의 동작을 확인한다. 일자 2022.12.28(화) 테스트 내용 01. Link Aggregation Static Case Study - 구성도 02. Link Aggregation Static 설정 03. Link Aggregation Static 설정 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 인터페이스를 따로 설정하면 Link Aggregation이 정상적으로 안 묶일 수 있음 양쪽 스위치에 On Mode를 사용하면 Link Aggregation이 정상 동작함 - Static(On)으로 설정할 시 장비 사이에 프로토콜을 송수신 하는 것이 아님 - Loop의 위험이 있음 01. Link Aggregation
[Link Aggregation] Link Aggregation Case Study - LACP ①(Nokia 7705 SAR) [내부링크]
Link Aggregation LACP ① Case Study(Nokia 7705 SAR) 작업 개요 목적 LACP(Active ↔ Active)를 사용할 때 Link Aggregation의 동작을 확인한다. 일자 2022.12.29(목) 테스트 내용 01. Link Aggregation LACP Case Study - 구성도 02. LACP 설정 03. LACP 설정 확인 테스트 계측기 - 장비 / OS L3 Nokia / 실장비 TiMOS-B-8.0.R10 결과 양쪽 라우터에 Active Mode를 사용하면 Link Aggregation이 정상 동작함 01. Link Aggregation LACP Case Study - 구성도 02. LACP 설정 R1 configure port 1/2/1 description LACP-Interface // 포트의 Description을 지정 ethernet mode network // 해당 포트의 Ethernet Mode를 지정 ethern
[Link Aggregation] Link Aggregation Case Study - LACP ②(Nokia 7705 SAR) [내부링크]
Link Aggregation LACP ② Case Study(Nokia 7705 SAR) 작업 개요 목적 LACP(Active ↔ Passive)를 사용할 때 Link Aggregation의 동작을 확인한다. 일자 2022.12.29(목) 테스트 내용 01. Link Aggregation LACP Case Study - 구성도 02. LACP 설정 03. LACP 설정 확인 테스트 계측기 - 장비 / OS L3 Nokia / 실장비 TiMOS-B-8.0.R10 결과 각 라우터에 Active Mode와 Passive Mode를 사용하면 Link Aggregation이 정상 동작함 01. Link Aggregation LACP Case Study - 구성도 02. LACP 설정 R1 configure port 1/2/1 description LACP-Interface // 포트의 Description을 지정 ethernet mode network // 해당 포트의 Ethernet M
[Link Aggregation] Link Aggregation Case Study - LACP ③(Nokia 7705 SAR) [내부링크]
Link Aggregation LACP ③ Case Study(Nokia 7705 SAR) 작업 개요 목적 LACP(Passive ↔ Passive)를 사용할 때 Link Aggregation의 동작을 확인한다. 일자 2022.12.29(목) 테스트 내용 01. Link Aggregation LACP Case Study - 구성도 02. LACP 설정 03. LACP 설정 확인 테스트 계측기 - 장비 / OS L3 Nokia / 실장비 TiMOS-B-8.0.R10 결과 양쪽 라우터에 Passive Mode를 사용하면 Link Aggregation이 정상 동작하지 않음 01. Link Aggregation LACP Case Study - 구성도 02. LACP 설정 R1 configure port 1/2/1 description LACP-Interface // 포트의 Description을 지정 ethernet mode network // 해당 포트의 Ethernet Mode를 지정
[Link Aggregation] Link Aggregation Case Study - Static(Nokia 7705 SAR) [내부링크]
Link Aggregation Static Case Study(Nokia 7705 SAR) 작업 개요 목적 Static(On ↔ ON)를 사용할 때 Link Aggregation의 동작을 확인한다. 일자 2022.12.29(목) 테스트 내용 01. Link Aggregation Static Case Study - 구성도 02. Link Aggregation Static 설정 03. Link Aggregation Static 설정 확인 테스트 계측기 - 장비 / OS L3 Nokia 7705 SAR-18 / 실장비 TiMOS-B-8.0.R10 결과 LACP Mode를 설정하지 않으면 Static(On)으로 설정됨 양쪽 라우터에 On Mode를 사용하면 Link Aggregation이 정상 동작함 - Static(On)으로 설정할 시 장비 사이에 프로토콜을 송수신 하는 것이 아님 - Loop의 위험이 있음 01. Link Aggregation Static Case Study - 구성
[VRRP] VRRP Case Study - Basic(Cisco) [내부링크]
VRRP Basic Case Study(Cisco) 작업 개요 목적 VRRP를 설정하고 기본적인 동작을 확인한다. 일자 2022.12.29(목) 테스트 내용 01. VRRP Basic Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. VRRP 설정 07. VRRP 설정 확인 08. VRRP Master 절체 09. VRRP Master 절체 후 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 VRRP를 사용하여 단말에게 게이트웨이 이중화를 제공할 수 있음 단말은 게이트웨이의 변화를 인지하지 못함 Priority 값이 높은 라우터가 Master로 선출되며 Priority
[VRRP] VRRP Case Study - Preempt(Cisco) [내부링크]
VRRP Preempt Case Study(Cisco) 작업 개요 목적 VRRP를 설정하고 Preempt 옵션 동작을 확인한다. 일자 2022.12.30(금) 테스트 내용 01. VRRP Preempt Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. VRRP 설정 07. VRRP 설정 확인 08. Preempt 옵션 미적용 후 VRRP Master 재부팅 09. Preempt 옵션 적용 후 VRRP Master 재부팅 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Priority 값이 동일할 경우 IP가 높은 장비를 Master로 선출함 기본적으로 Preempt 옵션이 적용
[VRRP] VRRP Case Study - Owner(Cisco) [내부링크]
VRRP Owner Case Study(Cisco) 작업 개요 목적 VRRP를 설정하고 Owner 옵션 동작을 확인한다. 일자 2022.12.30(금) 테스트 내용 01. VRRP Owner Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. VRRP 및 Owner 설정 07. VRRP 및 Owner 설정 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Priority 값이 동일할 경우 IP가 높은 장비를 Master로 선출함 Owner로 설정한 장비의 VRRP Priority 값이 255로 설정되어 항상 Master로 동작함 Owner로 설정한 장비는 Preempt 옵션
[VRRP] VRRP Case Study - Load Balancing(Cisco) [내부링크]
VRRP Load Balancing Case Study(Cisco) 작업 개요 목적 VRRP Load Balancing을 설정하고 동작을 확인한다. 일자 2022.12.30(금) 테스트 내용 01. VRRP Load Balancing Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. VRRP 설정 07. VRRP 설정 확인 08. VRRP Load Balancing Traffic Flow 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Priority 값이 동일할 경우 IP가 높은 장비를 Master로 선출함 VRRP Group Number를 다르게 하여 두 라우터에 각
[VRRP] VRRP Case Study - Uplink Down Track(Cisco) [내부링크]
VRRP Uplink Down Track Case Study(Cisco) 작업 개요 목적 VRRP를 설정하고 Uplink DownTrack 동작을 확인한다. 일자 2022.12.30(금) 테스트 내용 01. VRRP Uplink Down Track Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. VRRP 설정 07. VRRP 설정 확인 08. Uplink Down Track 미적용 후 Uplink Down 시 동작 확인 09. Uplink Down Track 설정 10. Uplink Down Track 적용 후 Uplink Down 시 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(1
[VRRP] VRRP Case Study - Delay(Cisco) [내부링크]
VRRP Delay Case Study(Cisco) 작업 개요 목적 VRRP를 설정하고 Delay 동작을 확인한다. 일자 2022.12.30(금) 테스트 내용 01. VRRP Delay Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. VRRP 설정 07. VRRP 설정 확인 08. VRRP Delay 설정 09. VRRP Delay 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Priority 값이 동일할 경우 IP가 높은 장비를 Master로 선출함 Preempt가 동작할 때 일정 시간 Delay를 설정할 수 있음 초기 Master 장비 정상가 되었어도 프로토
[VRRP] VRRP 명령어(Cisco) [내부링크]
VRRP 설정 명령어 VRRP 설정 conf t interface e0/0 ip address [1.1.12.2 255.255.255.0] // R-IP 설정 vrrp [10] ip [1.1.12.1] // V-IP 설정 vrrp [10] priority [110] // Master를 선출하는 Priority 설정 vrrp [10] preempt // preempt 기능 활성화 vrrp [10] timers advertise msec [500] // Hello 주기 설정 (msec) vrrp [10] authentication [md5] key-string [TEST] // VRRP 인증 설정 vrrp [10] track [5] decrement [40] // Track 설정 (Track 5번에 대해 활성화되면 Priority 값을 40만큼 감소) end VRRP 확인 명령어 VRRP 상태 확인(Brief) VRRP의 상태를 간략히 확인 VRRP 상태 확인(Detail) VRRP의
[VRRP] HSRP 명령어(Cisco) [내부링크]
HSRP 설정 명령어 HSRP 설정 명령어 conf t interface e0/0 ip address [1.1.12.2] [255.255.255.0] // R-IP 설정 standby [10] ip [VIP] // V-IP 설정 standby [10] priority [110] // HSRP Priority 값 설정 standby [10] preempt // HSRP Preempt 활성화 standby [10] track e0/1 [30] // e0/1 Down 시 Priority를 30만큼 감소 standby [10] version [2] // HSRP Vsersion 설정 (Default : 1) standby [10] timers [1] [3] // Hello Interval : 1s, Hold Interval : 3s로 설정 standby [10] timers msec [Hello Interval] msec [Hold Interval] // Timer를 msec단위로 변경 e
[VRRP] HSRP Case Study - Basic(Cisco) [내부링크]
HSRP Basic Case Study(Cisco) 작업 개요 목적 HSRP를 설정하고 기본적인 동작을 확인한다. 일자 2022.12.31(토) 테스트 내용 01. HSRP Basic Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. HSRP 설정 07. HSRP 설정 확인 08. HSRP Master 절체 09. HSRP Master 절체 후 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Priority 값이 동일해도 IP가 높은 장비를 Active로 선출하지 않음 - 먼저 Active로 선출된 장비가 Active 상태를 유지함 단말은 게이트웨이의 변화를 인지하지 못함
[VRRP] HSRP Case Study - Preempt(Cisco) [내부링크]
HSRP Preempt Case Study(Cisco) 작업 개요 목적 HSRP를 설정하고 Preempt 옵션 동작을 확인한다. 일자 2022.12.31(토) 테스트 내용 01. HSRP Preempt Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. HSRP 설정 07. HSRP 설정 확인 08. Preempt 옵션 미적용 후 HSRP Active 재부팅 09. Preempt 옵션 적용 후 HSRP Active 재부팅 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Priority 값이 동일해도 IP가 높은 장비를 Active로 선출하지 않음 - 먼저 Active로 선출된 장비
[VRRP] HSRP Case Study - Owner(Cisco) [내부링크]
HSRP Owner Case Study(Cisco) 작업 개요 목적 VRRP를 설정하고 Owner 옵션 동작을 확인한다. 일자 2022.12.31(토) 테스트 내용 01. HSRP Owner Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. HSRP 및 Owner 설정 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Priority 값이 동일할 경우 IP가 높은 장비를 Master로 선출함 - 먼저 Active로 선출된 장비가 Active 상태를 유지함 HSRP는 Owner를 지원하지 않음 01. HSRP Owner Case Study - 구성도 02. 기본 인터페이스 설정 R
[VRRP] HSRP Case Study - Load Balancing(Cisco) [내부링크]
HSRP Load Balancing Case Study(Cisco) 작업 개요 목적 HSRP Load Balancing을 설정하고 동작을 확인한다. 일자 2022.12.31(토) 테스트 내용 01. HSRP Load Balancing Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. HSRP 설정 07. HSRP 설정 확인 08. HSRP Load Balancing Traffic Flow 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Priority 값이 동일해도 IP가 높은 장비를 Active로 선출하지 않음 - 먼저 Active로 선출된 장비가 Active 상태를 유지
[VRRP] HSRP Case Study - Uplink Down Track(Cisco) [내부링크]
HSRP Uplink Down Track Case Study(Cisco) 작업 개요 목적 HSRP 설정하고 Uplink DownTrack 동작을 확인한다. 일자 2022.12.31(토) 테스트 내용 01. HSRP Uplink Down Track Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. HSRP 설정 07. HSRP 설정 확인 08. Uplink Down Track 미적용 후 Uplink Down 시 동작 확인 09. Uplink Down Track 설정 10. Uplink Down Track 적용 후 Uplink Down 시 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15
[VRRP] HSRP Case Study - Delay(Cisco) [내부링크]
HSRP Delay Case Study(Cisco) 작업 개요 목적 HSRP를 설정하고 Delay 동작을 확인한다. 일자 2022.12.31(토) 테스트 내용 01. VRRP Delay Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. VRRP 설정 07. VRRP 설정 확인 08. VRRP Delay 설정 09. VRRP Delay 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Priority 값이 동일해도 IP가 높은 장비를 Active로 선출하지 않음 - 먼저 Active로 선출된 장비가 Active 상태를 유지함 Preempt가 동작할 때 일정 시간 Dela
[VRRP] VRRP Case Study - Basic(Nokia 7750 SR) [내부링크]
VRRP Basic Case Study(Nokia 7750 SR) 작업 개요 목적 VRRP를 설정하고 기본적인 동작을 확인한다. 일자 2023.01.01(일) 테스트 내용 01. VRRP Basic Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. VRRP 설정 07. VRRP 설정 확인 08. VRRP Master 절체 09. VRRP Master 절체 후 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 Priority 값이 동일할 경우 IP가 높은 장비를 Master로 선출하지 않음 - 먼저 Master로 선출된 장비가 Master 상태를 유지함 VRRP를 사용하여 단말에게 게이트웨이 이중화를 제공할 수 있음
[VRRP] VRRP Case Study - Preempt(Nokia 7750 SR) [내부링크]
VRRP Preempt Case Study(Nokia 7750 SR) 작업 개요 목적 VRRP를 설정하고 Preempt 옵션 동작을 확인한다. 일자 2023.01.01(일) 테스트 내용 01. VRRP Preempt Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. VRRP 설정 07. VRRP 설정 확인 08. Preempt 옵션 미적용 후 VRRP Master 재부팅 09. Preempt 옵션 적용 후 VRRP Master 재부팅 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 Priority 값이 동일할 경우 IP가 높은 장비를 Master로 선출하지 않음 - 먼저 Master로 선출된 장비가 Master 상태를 유지
[VRRP] VRRP Case Study - Owner(Nokia 7750 SR) [내부링크]
VRRP Owner Case Study(Nokia 7750 SR) 작업 개요 목적 VRRP를 설정하고 Owner 옵션 동작을 확인한다. 일자 2023.01.01(일) 테스트 내용 01. VRRP Owner Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. VRRP 및 Owner 설정 07. VRRP 및 Owner 설정 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 Priority 값이 동일할 경우 IP가 높은 장비를 Master로 선출하지 않음 - 먼저 Master로 선출된 장비가 Master 상태를 유지함 Nokia VRRP는 Owner를 지원하지 않음 01. VRRP Owner Case Study - 구성도 0
[VRRP] VRRP Case Study - Load Balancing(Nokia 7750 SR) [내부링크]
VRRP Load Balancing Case Study(Nokia 7750 SR) 작업 개요 목적 VRRP Load Balancing을 설정하고 동작을 확인한다. 일자 2023.01.01(일) 테스트 내용 01. VRRP Load Balancing Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. VRRP 설정 07. VRRP 설정 확인 08. VRRP Load Balancing Traffic Flow 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 Priority 값이 동일할 경우 IP가 높은 장비를 Master로 선출하지 않음 - 먼저 Master로 선출된 장비가 Master 상태를 유지함 VRRP Group N
[VRRP] VRRP Case Study - Uplink Down Track(Nokia 7750 SR) [내부링크]
VRRP Uplink Down Track Case Study(Nokia 7750 SR) 작업 개요 목적 VRRP를 설정하고 Uplink DownTrack 동작을 확인한다. 일자 2023.01.01(일) 테스트 내용 01. VRRP Uplink Down Track Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. VRRP 설정 07. VRRP 설정 확인 08. Uplink Down Track 미적용 후 Uplink Down 시 동작 확인 09. Uplink Down Track 설정 10. Uplink Down Track 적용 후 Uplink Down 시 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 Priorit
[VRRP] VRRP Case Study - Delay(Nokia 7750 SR) [내부링크]
VRRP Delay Case Study(Nokia 7750 SR) 작업 개요 목적 VRRP를 설정하고 Delay 동작을 확인한다. 일자 2023.01.01(일) 테스트 내용 01. VRRP Delay Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. VRRP 설정 07. VRRP 설정 확인 08. VRRP Delay 설정 09. VRRP Delay 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 Priority 값이 동일할 경우 IP가 높은 장비를 Master로 선출하지 않음 - 먼저 Master로 선출된 장비가 Master 상태를 유지함 Preempt가 동작할 때 일정 시간 Delay를 설정할 수 있음 초기
[RIP] 명령어(Cisco) [내부링크]
RIP 설정 명령어 RIPv1 광고 설정 conf t router rip // RIP 설정 모드로 진입 network [10.10.10.0] // 광고할 Network를 설정 end RIPv2 광고 설정 conf t router rip // RIP 설정 모드로 진입 version 2 // RIPv2로 설정 no auto-summary // "no auto-summary"로 Classless를 지원하게 설정 network [10.10.10.0] // 광고할 Network를 설정 end RIP Default-Route 광고 설정 conf t router rip // RIP 설정 모드로 진입 default-information originate // Default-Route 광고 end Passive Interface 설정 conf t router rip passive-interface gi0/0 // 해당 인터페이스로 RIP 패킷을 전송하지 않음 (수신은 함) end Triggered
[RIP] RIP Case Study - Basic(Cisco) [내부링크]
RIP Basic Case Study(Cisco) 작업 개요 목적 RIP를 설정하고 기본적인 동작을 확인한다. 일자 2023.01.02(월) 테스트 내용 01. RIP Basic Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. RIPv2 설정 05. RIPv2 설정 확인 06. 단말 간 통신 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 RIP의 "no auto-summary" 명령어로 Classless로 설정할 수 있음 RIP의 "no auto-summary"는 RIPv2만 지원됨 - RIPv1은 지원되지 않음 01. RIP Basic Case Study - 구성도 02. 기본 인터페이스 설정 R1 conf t i
[RIP] RIP Case Study - Default-Route(Cisco) [내부링크]
RIP Default-Route Case Study(Cisco) 작업 개요 목적 RIP Default-Route를 설정하고 동작을 확인한다. 일자 2023.01.02(월) 테스트 내용 01. RIP Default-Route Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. RIPv2 설정 05. RIPv2 Default-Route 설정 06. RIPv2 Default-Route 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 "default-information originate" 명령어를 설정하여 Default-Route를 광고할 수 있음 01. RIP Default-Route Case Study - 구성도 02.
[RIP] RIP Case Study - Passive Interface(Cisco) [내부링크]
RIP Passive Interface Case Study(Cisco) 작업 개요 목적 RIP의 Passive Interface를 설정하고 동작을 확인한다. 일자 2023.01.03(화) 테스트 내용 01. RIP Passive Interface Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. RIPv2 설정 05. RIPv2 Passive Interface 설정 06. RIPv2 Passive Interface 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 RIP의 Passivee Interface를 설정하면 해당 인터페이스로 RIP 패킷을 수신하지만 송신하지 않음 01. RIP Passive Interface
[RIP] RIP Case Study - Triggered Update(Cisco) [내부링크]
RIP Triggered Update Case Study(Cisco) 작업 개요 목적 RIP의 Triggered Update를 설정하고 동작을 확인한다. 일자 2023.01.03(화) 테스트 내용 01. RIP Triggered Update Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. RIPv2 설정 05. RIPv2 Triggered Update 설정 06. RIPv2 Triggered Update 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Triggered Update를 설정하면 RIP 패킷을 주기적으로 업데이트하지 않고 네트워크의 변화가 있을 때만 업데이트함 01. RIP Triggered Updat
[RIP] RIP Case Study - Route Poisoning(Cisco) [내부링크]
RIP Route Poisoning Case Study(Cisco) 작업 개요 목적 RIP의 Route Poisoning을 설정하고 동작을 확인한다. 일자 2023.01.03(화) 테스트 내용 01. RIP Route Poisoning Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. RIPv2 설정 05. RIPv2 Route Poisoning 설정 06. RIPv2 Route Poisoning 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Poisoning을 설정하면 해당 네트워크 Down 시 Hop Count 16으로 업데이트함 DB에서 Hop Count가 16인 네트워크는 Routing Table로 올리지
[RIP] RIP Case Study - Split Horizon(Cisco) [내부링크]
RIP Split Horizon Case Study(Cisco) 작업 개요 목적 RIP의 Split Horizon을 설정하고 동작을 확인한다. 일자 2023.01.03(화) 테스트 내용 01. RIP Split Horizon Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. RIPv2 설정 05. RIPv2 Split Horizon 설정 06. RIPv2 Split Horizon 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Split Horizon을 설정하면 라우팅 정보를 수신한 인터페이스로 같은 라우팅 정보를 업데이트하지 않음 - DB에서 각 네트워크마다 Best-Path라고 인식하는 인터페이스로 업데이트하지
[RIP] RIP Case Study - Timer(Cisco) [내부링크]
RIP Timer Case Study(Cisco) 작업 개요 목적 RIP의 Timer를 설정하고 동작을 확인한다. 일자 2023.01.03(화) 테스트 내용 01. RIP Timer Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. RIPv2 설정 05. RIPv2 Timer 설정 06. RIPv2 Timer 설정 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 01. RIP Timer Case Study - 구성도 02. 기본 인터페이스 설정 R1 conf t interface Loopback0 // 인터페이스 진입 ip address 1.1.1.1 255.255.255.255 // IP 설정 no shutdown //
[RIP] RIP Case Study - Authentication(Cisco) [내부링크]
RIP Authentication Case Study(Cisco) 작업 개요 목적 RIP의 Authentication을 설정하고 동작을 확인한다. 일자 2023.01.03(화) 테스트 내용 01. RIP Authentication Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. RIPv2 설정 05. RIPv2 Authentication 설정 06. RIPv2 Authentication 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 RIP Authentication을 설정한 인터페이스로 송수신되는 RIP 패킷에는 Authentication이 MD5 Mode로 암호화되어 송신됨 RIP Neighbor 간 Auth
[EIGRP] 명령어(Cisco) [내부링크]
EIGRP 설정 명령어 EIGRP 광고 설정 conf t router eigrp 100 // 동일한 AS Number만 라우팅 no auto-summary // "no auto-summary"로 Classless를 지원하게 설정 network [10.10.10.0] // 광고할 Network를 설정 end EIGRP Neighbor 설정 conf t router eigrp 100 // 동일한 AS Number만 라우팅 neighbor 192.168.20.1 serial 1/0 // Neighbor와 1:1 통신을 하기위해 시도함 end Passive Interface 설정 conf t router eigrp 100 passive-interface fa0/0 // 해당 인터페이스로 EIGRP 패킷을 전송하지 않음 (수신은 함) end EIGRP Manual Summary 설정 conf t interface fa0/0 ip summary-address eigrp [110] [172.16
[EIGRP] EIGRP Case Study - Basic(Cisco) [내부링크]
EIGRP Basic Case Study(Cisco) 작업 개요 목적 EIGRP를 설정하고 기본적인 동작을 확인한다. 일자 2023.01.04(수) 테스트 내용 01. EIGRP Basic Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. EIGRP 설정 05. EIGRP 설정 확인 06. 단말 간 통신 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 EIGRP의 "no auto-summary" 명령어로 Classless로 설정할 수 있음 01. EIGRP Basic Case Study - 구성도 02. 기본 인터페이스 설정 R1 conf t interface Loopback0 // 인터페이스 진입 ip address 1
[EIGRP] EIGRP Case Study - Neighbor(Cisco) [내부링크]
EIGRP Neighbor Case Study(Cisco) 작업 개요 목적 EIGRP를 설정하고 Neighbor와 1:1 통신을 확인한다. 일자 2023.01.04(수) 테스트 내용 01. EIGRP Neighbor Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. EIGRP 설정 05. EIGRP Neighbor 설정 06. EIGRP Neighbor 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 하나의 장비에만 설정하면 EIGRP Neighbor가 Down 되므로 주의해야 함 "Neighbor" 명령어 설정 후에 Unicast로 EIGRP 패킷을 송신함 01. EIGRP Neighbor Case Study -
[EIGRP] EIGRP Case Study - Passive Interface(Cisco) [내부링크]
EIGRP Passive Interface Case Study(Cisco) 작업 개요 목적 EIGRP의 Passive Interface를 설정하고 동작을 확인한다. 일자 2023.01.04(수) 테스트 내용 01. EIGRP Passive Interface Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. EIGRP 설정 05. EIGRP Passive Interface 설정 06. EIGRP Passive Interface 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 EIGRP의 Passivee Interface를 설정하면 해당 인터페이스로 RIP 패킷을 수신하지만 송신하지 않음 01. EIGRP Basic C
[EIGRP] EIGRP Case Study - Manual Summary(Cisco) [내부링크]
EIGRP Manual Summary Case Study(Cisco) 작업 개요 목적 EIGRP의 Manual Summary를 설정하고 동작을 확인한다. 일자 2023.01.04(수) 테스트 내용 01. EIGRP Passive Interface Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. EIGRP 설정 05. EIGRP Manual Summary 설정 06. EIGRP Manual Summary 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 EIGRP의 Manual Summary를 설정하면 설정한 Summary IP 대역으로 EIGRP 광고함 Manual Summary를 설정할 때 Sumamry를 하려는
[EIGRP] EIGRP Case Study - Split Horizon(Cisco) [내부링크]
EIGRP Split Horizon Case Study(Cisco) 작업 개요 목적 EIGRP의 Split Horizon을 설정하고 동작을 확인한다. 일자 2023.01.04(수) 테스트 내용 01. EIGRP Split Horizon Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. EIGRP 설정 05. EIGRP Split Horizon 설정 06. EIGRP Split Horizon 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Split Horizon을 설정하면 라우팅 정보를 수신한 인터페이스로 같은 라우팅 정보를 업데이트하지 않음 - DB에서 각 네트워크마다 Best-Path라고 인식하는 인터페이스로 업
[EIGRP] EIGRP Case Study - Load Balancing(Cisco) [내부링크]
EIGRP Load Balancing Case Study(Cisco) 작업 개요 목적 EIGRP의 Load Balancing을 설정하고 동작을 확인한다. 일자 2023.01.05(목) 테스트 내용 01. EIGRP Load Balancing Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. EIGRP 설정 05. EIGRP Load Balancing 설정 06. EIGRP Load Balancing 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 EIGRP는 "maximum-paths [x]"명령어로 Load Balancing의 최대 경로 개수를 설정할 수 있음 01. EIGRP Load Balancing Case Study - 구성도 02. 기본 인터페이스 설정 R1 conf t interface Loopback0 // 인
[EIGRP] EIGRP Case Study - Unequal Load Balancing(Cisco) [내부링크]
EIGRP Unequal Load Balancing Case Study(Cisco) 작업 개요 목적 EIGRP의 Unequal Load Balancing을 설정하고 동작을 확인한다. 일자 2023.01.05(목) 테스트 내용 01. EIGRP Unequal Load Balancing Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. EIGRP 설정 05. EIGRP Unequal Load Balancing 설정 06. EIGRP Unequal Load Balancing 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 EIGRP는 "variance [x]"명령어로 Unequal Load Balancing을 설정함 "(각 경로의 FD) < (Successor의 FD) x (Variance 값)"인 경로들을 Load Balanc
[EIGRP] EIGRP Case Study - Default-Route(Cisco) [내부링크]
EIGRP Default-Route Case Study(Cisco) 작업 개요 목적 EIGRP의 Default-Route을 설정하고 동작을 확인한다. 일자 2023.01.06(금) 테스트 내용 01. EIGRP Default-Route Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. EIGRP 설정 05. EIGRP Default-Route 설정 ① 06. EIGRP Default-Route 동작 확인 ① 07. EIGRP Default-Route 설정 ② 08. EIGRP Default-Route 동작 확인 ② 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Static Routing을 Next-Hop Type으로 설정한 후 Default-Route를 광고하면 EIGRP Neighbor에게 광고되지 않음 - Next-Hop Type
[EIGRP] EIGRP Case Study - Metric(Cisco) [내부링크]
EIGRP Metric Case Study(Cisco) 작업 개요 목적 EIGRP의 Metric을 설정하고 동작을 확인한다. 일자 2023.01.06(금) 테스트 내용 01. EIGRP Metric Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. EIGRP 설정 05. EIGRP Metric 설정 06. EIGRP Metric 설정 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 EIGRP K 상수를 변경하여 EIGRP Metric을 수정할 수 있음 EIGRP Metric이 Neighbor와 Mismatch면 Neighbor가 끊어짐 01. EIGRP Metric Case Study - 구성도 02. 기본 인터페이스 설정 R1 conf t interface Loopback0 // 인터페이스 진입 ip address 1.1.1.
[EIGRP] EIGRP Case Study - Authentication(Cisco) [내부링크]
EIGRP Authentication Case Study(Cisco) 작업 개요 목적 EIGRP의 Authentication을 설정하고 동작을 확인한다. 일자 2023.01.06(금) 테스트 내용 01. EIGRP Authentication Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. EIGRP 설정 05. EIGRP Authentication 설정 06. EIGRP Authentication 설정 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 EIGRP Authentication을 설정한 인터페이스로 송수신되는 EIGRP 패킷 Authentication이 MD5 Mode로 암호화되어 송신됨 EIGRP Neighbor 간 Authentication으로 보안 설정을 할 수 있음 01. EIGRP Authentication
[OSPF] OSPF Case Study - Single Area(Nokia 7750 SR) [내부링크]
OSPF Single Area Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF Single Area를 설정하고 동작을 확인한다. 일자 2023.01.08(일) 테스트 내용 01. OSPF Single Area Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Database 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 OSPF 인터페이스 타입을 P-to-P로 하면 LSA Type 1만 발생함 OSPF 인터페이스 타입을 Broadcast로 하면 LSA Type 1, Type 2가 발생함 LSA Type 2는 DR에 대한 정보임 OSPF 인터페이스 타입을 Broadcast로 설정하면 DR/BDR을 선출하기 위해 To-Way 상태에서 대기함 - To-Way 상태에서 Wait Time(Dead
[OSPF] OSPF Case Study - Multiple Area(Nokia 7750 SR) [내부링크]
OSPF Multiple Area Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF Multiple Area를 설정하고 동작을 확인한다. 일자 2023.01.08(일) 테스트 내용 01. OSPF Multiple Area Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Database 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 OSPF 인터페이스 타입을 P-to-P로 하면 LSA Type 1, Type 3만 발생함 - 다른 Area에서는 LSA Type 3만 유입됨 OSPF 인터페이스 타입을 Broadcast로 하면 LSA Type 1, Type 2, Type3이 발생함 LSA Type 2는 DR에 대한 정보임 OSPF 인터페이스 타입을 Broadcast로 설정하면 DR/BDR을 선출
[OSPF] OSPF Case Study - Neighbor(Nokia 7750 SR) [내부링크]
OSPF Neighbor Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF Neighbor 조건을 확인한다. 일자 2023.01.09(월) 테스트 내용 01. OSPF Neighbor Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Neighbor - Area-ID 07. OSPF Neighbor - Subnet Mask 08. OSPF Neighbor - DR/BDR 선출 조건 09. OSPF Neighbor - Hello, Dead Interval 10. OSPF Neighbor - MTU 11. OSPF Neighbor - Authentication 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 Area가 상이하면 OSPF Neighbor를 맺을 수 없음 Subnet Mask가 상이해도 OS
[OSPF] OSPF Case Study - Metric(Nokia 7750 SR) [내부링크]
OSPF Metric Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF Metric를 설정하고 동작을 확인한다. 일자 2023.01.09(월) 테스트 내용 01. OSPF Metric Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Metric 변경 - Reference BW 07. OSPF Metric 변경 - Cost 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 Cost = Reference Bandwidth / Bandwidth - Reference Bandwidth = 100,000,000Kbps - 계산 결과 소수점이 나오면 버림 Bandwidth를 직접적으로 변경하면 다른 서비스에 직접적으로 영향을 미칠 가능성이 큼 OSPF Cost를 변경하면 Bandwidth에 영향을 주지 않아
[OSPF] OSPF Case Study - Passive Interface(Nokia 7750 SR) [내부링크]
OSPF Passive Interface Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 Passive Interface를 설정하고 동작을 확인한다. 일자 2023.01.10(화) 테스트 내용 01. OSPF Passive Interface Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Passive Interface 설정 07. OSPF Passive Interface 동작 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 OSPF의 Passivee Interface를 설정하면 해당 인터페이스로 OSPF 패킷을 송수신 하지 않음 01. OSPF Metric Case Study - 구성도 02. 기본 인터페이스 설정 R1 config port 1/1/2 ethernet mode network
[OSPF] OSPF Case Study - R-ID 선출(Nokia 7750 SR) [내부링크]
OSPF R-ID 선출 Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 R-ID 선출 순서를 조정하여 동작을 확인한다. 일자 2023.01.10(화) 테스트 내용 01. OSPF Passive Interface Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF R-ID 선출 - Chassis의 마지막 MAC 32bit 07. OSPF R-ID 선출 - System IP 08. OSPF R-ID 선출 - R-ID 설정(Global) 09. OSPF R-ID 선출 - R-ID 설정(OSPF) 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 Nokia 7750 SR의 OSPF R-ID 선출 순서는 아래와 같음 1. OSPF R-ID를 설정하면 해당 IP를 OSPF R-ID로 사용함 2. Global R-
[OSPF] OSPF Case Study - DR/BDR 선출(Nokia 7750 SR) [내부링크]
OSPF DR/BDR 선출 Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 DR/BDR 선출 조건을 확인함 일자 2023.01.11(수) 테스트 내용 01. OSPF Passive Interface Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF DR/BDR 선출 - R-ID 07. OSPF DR/BDR 선출 - Priority 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 Nokia 7750 SR의 OSPF R-ID 선출 순서는 아래와 같음 1. OSPF Priority가 큰 장비가 DR/BDR 선출 우선순위가 높음 - OSPF Priority가 0일 경우 DR/BDR 선출에 참여하지 않고 DROTHER 라우터로 선출됨 2. R-ID가 큰 장비가 DR/BDR 선출 우선순위가 높음 OSPF I
[OSPF] OSPF Case Study - LSA Type 3 Summary(Nokia 7750 SR) [내부링크]
OSPF LSA Type 3 Summary Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 LSA Type 3 Summary를 축약 설정하고 동작을 확인한다. 일자 2023.01.11(수) 테스트 내용 01. OSPF LSA Type 3 Summary Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. LSA 3 Type Summary 전 DB 확인 08. LSA 3 Type Summary 설정 09. LSA 3 Type Summary 후 DB 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 "area-range" 명령어는 LSA Type 3을 Summrization 함 R3은 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24를
[OSPF] OSPF Case Study - LSA Type 5 Summary(Nokia 7750 SR) [내부링크]
OSPF LSA Type 5 Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 LSA Type 5 Summary를 축약 설정하고 동작을 확인한다. 일자 2023.01.12(목) 테스트 내용 01. OSPF LSA Type 5 Summary Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. OSPF Redistribution Policy 설정 08. OSPF Redistribution Policy 적용 09. OSPF Redistribution Policy 적용 확인 10. OSPF LSA Type 5 Summary 설정 11. OSPF LSA Type 5 Summary 동작 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 OSPF로 재분배를 하기 위해 반드시 ASBR을
[OSPF] OSPF Case Study - Redistribution(Nokia 7750 SR) [내부링크]
OSPF Redistribution Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 Redistribution을 설정하고 동작을 확인한다. 일자 2023.01.12(목) 테스트 내용 01. OSPF Redistribution Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. OSPF Redistribution Policy 설정 08. OSPF Redistribution Policy 적용 09. OSPF Redistribution Policy 적용 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 OSPF로 재분배를 하기 위해 반드시 ASBR을 설정해야 함 OSPF 재분배 시 Type1로 설정하면 Metric이 누적됨 OSPF 재분배 시 Type2로 설정하면 Metri
[OSPF] OSPF Case Study - Stub Area(Nokia 7750 SR) [내부링크]
OSPF Stub Area Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 Stub Area를 설정하고 동작을 확인한다. 일자 2023.01.12(목) 테스트 내용 01. OSPF Stub Area Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. OSPF Redistribution Policy 설정 08. OSPF Redistribution Policy 적용 09. OSPF Redistribution Policy 적용 확인 10. OSPF Stub Area 설정 11. OSPF Stub Area 동작 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 OSPF로 재분배를 하기 위해 반드시 ASBR을 설정해야 함 재분배 시 ASBR과 같은 Area에 있는 라우터에는 Ty
[OSPF] OSPF Case Study - Totally Stub Area(Nokia 7750 SR) [내부링크]
OSPF Totally Stub Area Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 Totally Stub Area를 설정하고 동작을 확인한다. 일자 2023.01.12(목) 테스트 내용 01. OSPF Totally Stub Area Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. OSPF Redistribution Policy 설정 08. OSPF Redistribution Policy 적용 09. OSPF Redistribution Policy 적용 확인 10. OSPF Totally Stub Area 설정 11. OSPF Totally Stub Area 동작 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 OSPF로 재분배를 하기 위해 반드시 ASBR을
[OSPF] OSPF Case Study - NSSA(Nokia 7750 SR) [내부링크]
OSPF NSSA Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 NSSA를 설정하고 동작을 확인한다. 일자 2023.01.13(금) 테스트 내용 01. OSPF NSSA Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. OSPF Redistribution Policy 설정 08. OSPF Redistribution Policy 적용 09. OSPF Redistribution Policy 적용 확인 10. OSPF NSSA 설정 11. OSPF NSSA 동작 확인 12. OSPF NSSA Default-Route 설정 13. OSPF NSSA Default-Route 동작 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 OSPF로 재분배를 하기 위해 반드시 ASBR을
[OSPF] OSPF Case Study - Totally NSSA(Nokia 7750 SR) [내부링크]
OSPF Totally NSSA Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 Totally NSSA를 설정하고 동작을 확인한다. 일자 2023.01.13(금) 테스트 내용 01. OSPF Totally NSSA Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. OSPF Redistribution Policy 설정 08. OSPF Redistribution Policy 적용 09. OSPF Redistribution Policy 적용 확인 10. OSPF Totally NSSA 설정 11. OSPF Totally NSSA 동작 확인 12. OSPF Totally NSSA Default-Route 설정 13. OSPF Totally NSSA Default-Route 동작 확인 테스트 계측기 - 장비 / OS L3 Nokia 77
[OSPF] OSPF Case Study - Virtual Link(Nokia 7750 SR) [내부링크]
OSPF Virtual Link Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 Virtual Link를 설정하고 동작을 확인한다. 일자 2023.01.13(금) 테스트 내용 01. OSPF Virtual Link Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Virtual Link 설정 07. OSPF Virtual Link 동작 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 OSPF는 Multi-Area를 사용하기 위해 반드시 Backbone Area와 인접해 있어야 함 - Backbone Area와 인접하지 않은 Area는 라우팅 정보를 받지 못함 - 각 Area 간에 OSPF Neighbor는 정상적으로 맺음 OSPF Area가 Backbone Area와 물리적으로 인접하지 않았
[OSPF] OSPF Case Study - Authentication ①(Nokia 7750 SR) [내부링크]
OSPF Authentication ① Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 Authentication을 설정하고 동작을 확인한다. 일자 2023.01.13(금) 테스트 내용 01. OSPF Authentication Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Authentication - Simple Password 설정 07. OSPF Authentication - Simple Password 동작 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 Authentication Type이 Simple Password일 경우 OSPF 패킷에 Password가 노출됨 양측의 Authentication Key가 상이하면 Neighbor를 맺을 수 없음 01. OSPF Authent
[OSPF] OSPF Case Study - Authentication ②(Nokia 7750 SR) [내부링크]
OSPF Authentication ② Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 Authentication을 설정하고 동작을 확인한다. 일자 2023.01.13(금) 테스트 내용 01. OSPF Authentication Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Authentication - MD5 설정 07. OSPF Authentication - MD5 동작 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 Authentication Type이 MD5일 경우 OSPF 패킷에 Password가 암호화됨 하나의 MD5에 여러 개의 MD5 Key 설정이 가능함 양측의 MD5 Key가 상이하면 Neighbor를 맺을 수 없음 01. OSPF Authentication Case S
[OSPF] OSPF Case Study - ECMP(Nokia 7750 SR) [내부링크]
OSPF ECMP Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 ECMP를 설정하고 동작을 확인한다. 일자 2023.01.14(토) 테스트 내용 01. OSPF ECMP Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. ECMP 설정 전 경로 확인 07. ECMP 설정 08. ECMP 설정 후 경로 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 서로 다른 라우팅 프로토콜의 Preference를 동일한 값으로 설정했을 시 각 라우팅 프로토콜에 대한 Default Preference 값을 따름 Preference와 Metric이 동일한 경로에 대해서만 ECMP가 적용됨 - 동일한 라우팅 프로토콜에서 학습되어야 함 최대 16개의 ECMP를 구성할 수 있음 01. OSPF Redistribution C
[OSPF] OSPF Case Study - Single Area(Cisco) [내부링크]
OSPF Single Area Case Study(Cisco) 작업 개요 목적 OSPF Single Area를 설정하고 동작을 확인한다. 일자 2023.01.14(토) 테스트 내용 01. OSPF Single Area Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Database 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 OSPF 인터페이스 타입을 P-to-P로 하면 LSA Type 1만 발생함 OSPF 인터페이스 타입을 Broadcast로 하면 LSA Type 1, Type 2가 발생함 LSA Type 2는 DR에 대한 정보임 OSPF 인터페이스 타입을 Broadcast로 설정하면 DR/BDR을 선출하기 위해 To-Way 상태에서 대기함 - To-Way 상태
[OSPF] OSPF Case Study - Multiple Area(Cisco) [내부링크]
OSPF Multiple Area Case Study(Cisco) 작업 개요 목적 OSPF Multiple Area를 설정하고 동작을 확인한다. 일자 2023.01.14(토) 테스트 내용 01. OSPF Multiple Area Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Database 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 OSPF 인터페이스 타입을 P-to-P로 하면 LSA Type 1, Type 3만 발생함 - 다른 Area에서는 LSA Type 3만 유입 OSPF 인터페이스 타입을 Broadcast로 하면 LSA Type 1, Type 2, Type3이 발생함 LSA Type 2는 DR에 대한 정보임 OSPF 인터페이스 타입을 Broadcast로
[OSPF] OSPF Case Study - Neighbor(Cisco) [내부링크]
OSPF Neighbor Case Study(Cisco) 작업 개요 목적 OSPF Neighbor 조건을 확인한다. 일자 2023.01.15(일) 테스트 내용 01. OSPF Neighbor Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Neighbor - Area-ID 07. OSPF Neighbor - Subnet Mask 08. OSPF Neighbor - DR/BDR 선출 조건 09. OSPF Neighbor - Hello, Dead Interval 10. OSPF Neighbor - MTU 11. OSPF Neighbor - Authentication 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Area가 상이하면 OSPF Neighbor를 맺을 수 없음 Sub
[OSPF] OSPF Case Study - Metric(Cisco) [내부링크]
OSPF Metric Case Study(Cisco) 작업 개요 목적 OSPF Metric를 설정하고 동작을 확인한다. 일자 2023.01.16(월) 테스트 내용 01. OSPF Metric Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Metric 변경 - BW 07. OSPF Metric 변경 - Reference BW 08. OSPF Metric 변경 - Cost 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Cost = Reference Bandwidth / Bandwidth - Reference Bandwidth = 100,000,000Kbps - 계산 결과 소수점이 나오면 버림 Bandwidth를 직접적으로 변경하면 다른 서비스에 직접적으로 영향을 미칠 가능성이
[OSPF] OSPF Case Study - Passive Interface(Cisco) [내부링크]
OSPF Passive Interface Case Study(Cisco) 작업 개요 목적 OSPF의 Passive Interface를 설정하고 동작을 확인한다. 일자 2023.01.16(월) 테스트 내용 01. OSPF Passive Interface Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Passive Interface 설정 07. OSPF Passive Interface 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 OSPF의 Passivee Interface를 설정하면 해당 인터페이스로 OSPF 패킷을 송수신 하지 않음 01. OSPF Metric Case Study - 구성도 02. 기본 인터페이스 설정 R1 conf t interface Loopb
[OSPF] OSPF Case Study - R-ID 선출(Cisco) [내부링크]
OSPF R-ID 선출 Case Study(Cisco) 작업 개요 목적 OSPF의 R-ID 선출 순서를 조정하여 동작을 확인한다. 일자 2023.01.16(월) 테스트 내용 01. OSPF Passive Interface Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF R-ID 선출 - Interface IP가 높은 것 07. OSPF R-ID 선출 - Loopback IP가 높은 것 08. OSPF R-ID 선출 - R-ID 설정 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Cisco의 OSPF R-ID 선출 순서는 아래와 같음 1. R-ID를 설정하면 해당 IP를 OSPF R-ID로 사용함 2. R-ID 미설정 시 Loopback에서 가장 큰 IP를 R-ID로 사용함 3
[OSPF] OSPF Case Study - DR/BDR 선출(Cisco) [내부링크]
OSPF DR/BDR 선출 Case Study(Cisco) 작업 개요 목적 OSPF의 DR/BDR 선출 조건을 확인함 일자 2023.01.16(월) 테스트 내용 01. OSPF Passive Interface Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF DR/BDR 선출 - R-ID 07. OSPF DR/BDR 선출 - Priority 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Cisco의 OSPF R-ID 선출 순서는 아래와 같음 1. OSPF Priority가 큰 장비가 DR/BDR 선출 우선순위가 높음 - OSPF Priority가 0일 경우 DR/BDR 선출에 참여하지 않고 DROTHER 라우터로 선출됨 2. R-ID가 큰 장비가 DR/BDR 선출 우선순위가 높
[OSPF] OSPF Case Study - LSA Type 3 Summary(Cisco) [내부링크]
OSPF LSA Type 3 Summary Case Study(Cisco) 작업 개요 목적 OSPF의 LSA Type 3 Summary를 축약 설정하고 동작을 확인한다. 일자 2023.01.16(월) 테스트 내용 01. OSPF LSA Type 3 Summary Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. LSA 3 Type Summary 전 DB 확인 08. LSA 3 Type Summary 설정 09. LSA 3 Type Summary 후 DB 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 "range" 명령어는 LSA Type 3을 Summrization 함 R3은 192.168.10.0/24, 192.168.20.0/24, 192.1
[OSPF] OSPF Case Study - LSA Type 5 Summary(Cisco) [내부링크]
OSPF LSA Type 5 Case Study(Cisco) 작업 개요 목적 OSPF의 LSA Type 5 Summary를 축약 설정하고 동작을 확인한다. 일자 2023.01.16(월) 테스트 내용 01. OSPF LSA Type 5 Summary Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. OSPF Redistribution Route-Map 설정 08. OSPF Redistribution Route-Map 적용 09. OSPF Redistribution Route-Map 적용 확인 10. OSPF LSA Type 5 Summary 설정 11. OSPF LSA Type 5 Summary 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 "
[OSPF] OSPF Case Study - Redistribution(Cisco) [내부링크]
OSPF Redistribution Case Study(Cisco) 작업 개요 목적 OSPF의 Redistribution을 설정하고 동작을 확인한다. 일자 2023.01.16(월) 테스트 내용 01. OSPF Redistribution Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. OSPF Redistribution Route-Map 설정 08. OSPF Redistribution Route-Map 적용 - Metric Type 2 09. OSPF Redistribution Route-Map 적용 확인 - Metric Type 2 10. OSPF Redistribution Route-Map 적용 - Metric Type 1 11. OSPF Redistribution Route-Map 적용 확인 - Metric Type 1 테스트 계측기 - 장비 /
[OSPF] OSPF Case Study - Stub Area(Cisco) [내부링크]
OSPF Stub Area Case Study(Cisco) 작업 개요 목적 OSPF의 Stub Area를 설정하고 동작을 확인한다. 일자 2023.01.17(화) 테스트 내용 01. OSPF Stub Area Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. OSPF Redistribution Route-Map 설정 08. OSPF Redistribution Route-Map 적용 09. OSPF Redistribution Route-Map 적용 확인 10. OSPF Stub Area 설정 11. OSPF Stub Area 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 재분배 시 ASBR과 같은 Area에 있는 라우터에는 Type 4 LSA가
[OSPF] OSPF Case Study - Totally Stub Area(Cisco) [내부링크]
OSPF Totally Stub Area Case Study(Cisco) 작업 개요 목적 OSPF의 Totally Stub Area를 설정하고 동작을 확인한다. 일자 2023.01.17(화) 테스트 내용 01. OSPF Totally Stub Area Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. OSPF Redistribution Route-Map 설정 08. OSPF Redistribution Route-Map 적용 09. OSPF Redistribution Route-Map 적용 확인 10. OSPF Totally Stub Area 설정 11. OSPF Totally Stub Area 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 재
[OSPF] OSPF Case Study - NSSA(Cisco) [내부링크]
OSPF NSSA Case Study(Cisco) 작업 개요 목적 OSPF의 NSSA를 설정하고 동작을 확인한다. 일자 2023.01.17(화) 테스트 내용 01. OSPF NSSA Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. OSPF Redistribution Route-Map 설정 08. OSPF Redistribution Route-Map 적용 09. OSPF Redistribution Route-Map 적용 확인 10. OSPF NSSA 설정 11. OSPF NSSA 동작 확인 12. OSPF NSSA Default-Route 설정 13. OSPF NSSA Default-Route 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 재
[OSPF] OSPF Case Study - Totally NSSA(Cisco) [내부링크]
OSPF Totally NSSA Case Study(Cisco) 작업 개요 목적 OSPF의 Totally NSSA를 설정하고 동작을 확인한다. 일자 2023.01.17(화) 테스트 내용 01. OSPF Totally NSSA Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. OSPF Redistribution Route-Map 설정 08. OSPF Redistribution Route-Map 적용 09. OSPF Redistribution Route-Map 적용 확인 10. OSPF Totally NSSA 설정 11. OSPF Totally NSSA 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 재분배 시 ASBR과 같은 Area에 있는 라우
[OSPF] OSPF Case Study - Virtual Link(Cisco) [내부링크]
OSPF Virtual Link Case Study(Cisco) 작업 개요 목적 OSPF의 Virtual Link를 설정하고 동작을 확인한다. 일자 2023.01.17(화) 테스트 내용 01. OSPF Virtual Link Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Virtual Link 설정 07. OSPF Virtual Link 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 OSPF는 Multi-Area를 사용하기 위해 반드시 Backbone Area와 인접해 있어야 함 - Backbone Area와 인접하지 않은 Area는 라우팅 정보를 받지 못함 - 각 Area 간에 OSPF Neighbor는 정상적으로 맺음 OSPF Area가 Backbone Ar
[OSPF] OSPF Case Study - Interface Authentication ①(Cisco) [내부링크]
OSPF Interface Authentication ① Case Study(Cisco) 작업 개요 목적 OSPF의 Interface Authentication을 설정하고 동작을 확인한다. 일자 2023.01.17(화) 테스트 내용 01. OSPF Interface Authentication Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Interface Authentication - Simple Password 설정 07. OSPF Interface Authentication - Simple Password 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Authentication Type이 Simple Password일 경우 OSPF 패킷에 Password가 노
[OSPF] OSPF Case Study - Area Authentication ①(Cisco) [내부링크]
OSPF Area Authentication ① Case Study(Cisco) 작업 개요 목적 OSPF의 Area Authentication을 설정하고 동작을 확인한다. 일자 2023.01.17(화) 테스트 내용 01. OSPF Area Authentication Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Area Authentication - Simple Password 설정 07. OSPF Area Authentication - Simple Password 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Authentication Type이 Simple Password일 경우 OSPF 패킷에 Password가 노출됨 양측의 Authentication Ke
[OSPF] OSPF Case Study - Interface Authentication ②(Cisco) [내부링크]
OSPF Interface Authentication ② Case Study(Cisco) 작업 개요 목적 OSPF의 Interface Authentication을 설정하고 동작을 확인한다. 일자 2023.01.17(화) 테스트 내용 01. OSPF Interface Authentication Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Interface Authentication - MD5 설정 07. OSPF Interface Authentication - MD5 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Authentication Type이 MD5일 경우 OSPF 패킷에 Password가 암호화됨 하나의 MD5에 여러 개의 MD5 Key 설정이 가능함
[OSPF] OSPF Case Study - Area Authentication ②(Cisco) [내부링크]
OSPF Area Authentication ② Case Study(Cisco) 작업 개요 목적 OSPF의 Area Authentication을 설정하고 동작을 확인한다. 일자 2023.01.17(화) 테스트 내용 01. OSPF Area Authentication Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Area Authentication - MD5 설정 07. OSPF Area Authentication - MD5 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 Authentication Type이 MD5일 경우 OSPF 패킷에 Password가 암호화됨 하나의 MD5에 여러 개의 MD5 Key 설정이 가능함 양측의 MD5 Key가 상이하면 Neighb
[OSPF] OSPF Case Study - Default-Route(Cisco) [내부링크]
OSPF Default-Route Case Study(Cisco) 작업 개요 목적 OSPF의 Default-Route를 설정하고 동작을 확인한다. 일자 2023.01.17(화) 테스트 내용 01. OSPF Default-Route Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. OSPF Default-Route 설정 전 Routing Table 확인 07. OSPF Default-Route 설정(Always) 08. OSPF Default-Route 동작 확인(Always) 09. OSPF Default-Route 설정 10. OSPF Default-Route 동작 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS C3725-ADVENTERPRISEK9-M / Version 12.4(15)T14 결과 "default-information originate always"
[OSPF] OSPF Case Study - N1/N2 Block(Nokia 7750 SR) [내부링크]
OSPF N1/N2 Block Case Study(Nokia 7750 SR) 작업 개요 목적 OSPF의 N1/N2 Block을 설정하고 동작을 확인한다. 일자 2023.01.18(수) 테스트 내용 01. OSPF N1/N2 Block Case Study - 구성도 02. 기본 인터페이스 설정 03. 기본 인터페이스 설정 확인 04. OSPF 설정 05. OSPF 설정 확인 06. Loopback 추가 설정 07. OSPF Redistribution Policy 설정 08. OSPF Redistribution Policy 적용 09. OSPF Redistribution Policy 적용 확인 10. OSPF NSSA 생성 11. OSPF NSSA 동작 확인 12. OSPF N1/N2 Block 설정 13. OSPF N1/N2 Block 동작 확인 테스트 계측기 - 장비 / OS L3 Nokia 7750 SR-12 TiMOS-B-14.0.R3 결과 ASBR에서 "config route
[Emulator Guide] Red Hat 7.5 설치 ① [내부링크]
Red Hat 7.5 설치 ① 1. "File" 선택 → "New Virtual Machine" 선택 2. "Custome(advanced)" 선택 → "Next" 선택 3. "Workstation 17.x" 선택 → "Next" 선택 - 각자 PC에 설치된 Workstation의 Version에 맞는 것을 선택함 4. "I will install the operating system later." 선택 - 설치하려는 운영체제는 나중에 설치하기 위해 선택함 5. "Linux" 선택 → "Red Hat Linux" 선택 → "Next" 선택 - Red Hat이 Linux의 종류 중 하나이기 때문에 Linux를 선택함 6. Virtual Machine Name 및 설치 위치 선택 → "Next" 선택 - "Virtual Machine Name" : 설치하려는 Virtual Machine 이름 - "Location" : Virtual Machine을 설치하려는 위치 7. Virtual M
[Emulator Guide] Red Hat 7.5 설치 ② [내부링크]
Red Hat 7.5 설치 ② 1. "Power on this virtual machine" 선택 - "Power on this virtual machine"을 선택하여 가상 머신에 전원을 넣어줌 2. "Install Red Hat Enterprise Linux 7.5" 선택 - "Install Red Hat Enterprise Linux 7.5"를 선택하여 Red Hat 7.5를 설치함 - 방향키로 위, 아래를 이동할 수 있음 - 엔터키를 사용하여 선택할 수 있음 3. "English" 선택 → "Continue" 선택 - 설치할 때 사용할 언어를 선택함 4. "DATE & TIME" 선택 5. Asia/Seoul Timezone 선택 - Asia/Seoul Timezone을 선택 6. "SOFTWARE SELECTION" 선택 7. "Server with GUI" 선택 → "Done" 선택 - Red Hat에 설치할 소프트웨어를 선택함 8. "INSTALLATION DESTINA
[BGP] BGP Authentication / Prefix-Limit [내부링크]
BGP Authentication BGP Authentication of Neighbor Peer Authentication은 OPEN Message에서 Optional로 요청될 수 있음 각 TCP 세그먼트는 16Byte Hasg를 포함함 Authentication은 MD5를 사용함 Hash Option을 사용하지 않으면 Key가 암호화되지 않은 일반 텍스트 형식으로 간주됨 BGP Prefix-Limit BGP Prefix-Limit BGP가 Peer 또는 Group에서 허용할 최대 경로 수를 구성함 Peer에서 학습할 수 있는 최대 경로 수의 90%에 도달하면 SNMP Trap이 전송됨 Peer에서 학습할 수 있는 최대 경로 수를 초과하면 BGP Peering이 삭제되고 사용되지 않도록 설정됨 R1 configure router bgp group iBGP neighbor 2.2.2.2 prefix-limit 1000
[Emulator Guide] CentOS 7 설치 ① [내부링크]
CentOS 7 설치 ① 1. "File" 선택 → "New Virtual Machine" 선택 2. "Custome(advanced)" 선택 → "Next" 선택 3. "Workstation 17.x" 선택 → "Next" 선택 - 각자 PC에 설치된 Workstation의 Version에 맞는 것을 선택함 4. "I will install the operating system later." 선택 - 설치하려는 운영체제는 나중에 설치하기 위해 선택함 5. "Linux" 선택 → "CentOS 7 64-bit" 선택 → "Next" 선택 - CentOS는 Linux의 종류 중 하나이기 때문에 Linux를 선택함 6. Virtual Machine Name 및 설치 위치 선택 → "Next" 선택 - "Virtual Machine Name" : 설치하려는 Virtual Machine 이름 - "Location" : Virtual Machine을 설치하려는 위치 7. Virtual Mac
[STP] STP Overview 및 포트 상태 [내부링크]
STP 필요성(L2 이중화 문제점) 루프 발생 시 L2 이더넷 헤더에 TTL 필드가 없으므로 무한 루프 발생 → L2 프레임을 송수신하는 장비라면 루프를 고려해야 함 루프가 발생한 VLAN뿐만 아니라 다른 VLAN에 연결된 장비들에도 영향을 미침 → 루프 발생 시 리소스(CPU, RAM) 사용률이 높아짐 BUM(Broadcast, Unknown Unicast, Multicast) 트래픽 발생 시 Broadcast 트래픽 발생 → SW의 MAC Table에 BUM 트래픽에 대한 정보가 없음 Broadcast Strom Broadcast 프레임이 다시 Broadcast로 송신되는 상태 많은 트래픽으로 인하여 대역폭 고갈 및 리소스 소모율 상승 Multiple Frame Copy SW의 Flooding 기능으로 인한 프레임 중복 수신 MAC Flapping 여러 방향으로 들어온 트래픽의 S-MAC이 같기 때문에 SW의 MAC Table의 정보가 계속 변경됨 STP(Spanni
[STP] STP BPDU Header [내부링크]
BPDU(Bridge Protocol Data Unit) 종류 Configuration BPDU Root SW를 선출하고 SW 포트의 역할을 지정 Root SW에서 2s마다 발생(Default) BPDU가 연속적으로 3개 Loss까지 허용 → 4개 Loss부터 장애라 판단 35Byte TCN(Topology Change Notification) BPDU 네트워크 망 변화 발생 시 변화했다는 것을 Root SW에게 알리기 위해 사용 항상 루트 SW 쪽으로 송신 4Byte BPDU Format BPDU Format STP의 BPDU : 35Byte RSTP의 BPDU : 36Byte RSTP의 BPDU는 STP의 Configuration BPDU와 유사 802.1d BPDU Header Frame Control 0x01 고정 DA(Destination Address) 수신지 MAC 주소 SA(Source Address) 송신지 MAC 주소 Logical Link
[STP] STP 포트 선출 [내부링크]
STP 포트 선출 알고리즘 순서 1. Root SW 선택 2. 모든 Non-SW에서 RP를 하나씩 선택 3. 세그먼트당 DP를 하나씩 선택 - 종단 장비 쪽으로도 DP가 존재하며 BPDU가 전송됨 4. DP or RP가 아닌 포트는 대체 포트(Blocking Port) 1. Root Switch 선출 1-1. B-ID가 가장 낮은 SW SW1의 B-ID가 가장 낮으므로 SW1이 Root SW로 선출됨 - Priority는 다른 Switch와 같지만 MAC Address가 작아 B-ID가 가장 작다고 계산됨 2. Root Port 선출 Root Port 선출은 SW 기준 2-1. Root B-ID가 가장 낮은 BPDU를 수신한 포트 SW3은 B-ID가 가장 작은 BPDU를 수신한 포트가 e0/0이므로 해당 포트를 RP로 선출함 2-2. Path Cost 값이 가장 낮은 포트 (우선순위 ↑) 각 Switch는 포트중 Root Switch로 가는 경로 값이 가장 작은 포트를 Roo
[STP] STP 동작 과정 [내부링크]
포트 역할 변화 포트 역할 변화 포트 활성화 시 포트가 DP or RP이면 Listening 상태가 되며 Non-DP면 Blocking 상태가 됨 Max Age가 경과하면 Listening 상태로 변경 DP or RP가 Non-DP로 되면 바로 Blocking 상태가 됨 Listening, Learning에서 각각 Forwarding Delay 만큼 지나면 Learning, Forwarding이 됨 장애 발생 시 토폴로지 변화 장애 발생 시 토폴로지 변화 (Port Down) 1. SW1, SW2의 e0/1이 Disable로 상태 변경 2. SW2는 자신이 루트 SW라 판단하여 후순위 BPDU를 SW4에게 전달 3. SW4는 후순위 BPDU를 수신하여 SW2 ↔ 루트 SW 간의 링크 다운인 것을 알게 됨 → SW4는 Max Age동안 기다리며 SW2가 전송하는 후순위 BPDU를 계속 수신 4. SW4는 Non-DP인 F0/1을 RP로 변경하며 RP인 e0/0을 DP로 변경함
[STP] STP Convergence Time 단축 기술 [내부링크]
토폴로지 변화 시 네트워크가 재구성될 때까지 소요되는 시간 STP Convergence Time : 30~50s Port Fast Port Fast 해당 포트를 바로 포워드 상태로 적용(항상 Forwarding 상태) → STP로 인한 Link Up Time 지연을 막음 → 즉, 상대방이 송신하는 BPDU는 무시함 (Loop를 감지하기 위해 BPDU 송신은 함) 보통 단말이 연결된 Edge Port에 적용 Uplink Fast Uplink Fast 직접 연결된 링크 장애 시 Blocking 포트를 바로 Forwarding 포트로 변경 주로 N-DP를 가지고 있는 SW에 설정 Backbone Fast 간접 링크 장애 시 N-DP를 Blocking(20s)을 생략하고 바로 Listening 상태로 변경 모든 SW에 설정 필요 Backbone Fast 1. SW2는 장애 발생 시 자신의 BPDU를 SW3에게 송신 후순위 BPDU를 수신한 SW3은 SW2 ↔ 루트 SW의 링크
[STP] STP 네트워크 보호 기술 [내부링크]
BPDU Guard BPDU Guard 설정된 포트에 BPDU가 수신되면 포트를 shutdown 시킴 BPDU Filter BPDU Filter 설정된 포트로 BPDU를 송수신하지 않음 Root Guard Root Guard 설정된 포트로 Root B-ID보다 좋은 B-ID가 들어오면 포트를 shutdown 시키며 차후 기존 루트 B-ID 보다 안 좋은 BPDU를 수신하면 다시 no shutdown 됨 → 새로운 SW가 붙었을 때 토폴로지의 변화를 막기 위한 것 Loop Guard Loop Guard Blocking 포트가 BPDU를 받지 못할 때 Forwarding으로 변경되는 것을 방지 Loop Detection Guard Loop Detection Guard Loop Detection Frame을 송신하여 루프가 발생했는지 확인 → STP가 동작하지 않는 장비는 BPDU를 받아도 포워딩하지 않기 때문에 루프 발생 가능성이 있음 루프 확인 후 액션 설정 종류 1. Lo
[STP] RSTP 개념 및 포트 상태 [내부링크]
RSTP 정의 STP의 Convergence TIme을 줄이는 것은 한계가 있음 STP에서 링크에 장애가 생겼을 때 Delay가 생기는 이유 - 즉시 Forwarding 상태로 변경 시 루프가 발생할 수 있기 때문 RSTP는 Proposal BPDU를 전송하고 Agreement BPDU를 받아 바로 Forwarding 상태로 변경 RSTP 포트 종류 RSTP 포트 종류 포트 종류 설명 DP (Designated Port) - BPDU를 송신하는 포트 - 세그먼트당 1개 RP (Root Port) - DP에서 나오는 BPDU를 수신하는 포트 - Non-Root SW당 1개 Alternate Port - RP 다운 시 해당 역할을 이어받는 포트 Backup Port - DP 다운 시 해당 역할을 이어받는 포트 - 자신이 보낸 BPDU를 다른 포트로 수신할 때 두 포트 중 후순위의 포트가 Backup Port로 결정 Disabled Port - RSTP에서 역할이 없는 포트 RSTP
[STP] RSTP 동작 과정 [내부링크]
초기 활성 토폴로지 초기 활성 토폴로지 1. SW1은 SW2, SW3에게 DP로 설정한다는 Proposal BPDU를 전송 2. SW2, SW3은 Proposal BPDU를 수신한 포트를 제외한 나머지 포트를 모두 차단 상태로 만듦 → RP 후보를 제외한 모든 포트를 차단하는 것을 Synchronization이라 함 → RP를 Forwarding상태로 변경해도 루프가 발생하지 않도록 하기 위함 3. SW2, SW3은 Agreement BPDU를 SW1에게 전송 → Agreement BPDU를 전송하는 포트를 Forwarding상태로 변경 4. Agreement BPDU를 수신한 SW1은 SW2,3과 연결된 포트를 Forwarding상태로 변경 5. SW2는 Proposal BPDU를 SW3에게 전송 → DP선출 과정에서 SW2가 SW3보다 우세하기 때문 → SW3의 e0/2는 차단 상태이므로 Agreement BPDU를 전송하지 못함 6. 응답을 받지 못한 상대는 차단 상태(STP는
[STP] 명령어(Cisco) [내부링크]
STP 설정 명령어 STP 우선순위 관련 설정 conf t spanning-tree vlan [10] priority [4096] // VLAN 10의 STP priority를 4096으로 설정 spanning-tree vlan [10] root primary // VLAN 10의 Root Bridge로 설정 spanning-tree vlan [10] root secondary // Secondary Root Bridge로 설정 spanning-tree mode rapid-pvst // STP Mode를 RSTP로 설정 end STP Timer 설정 conf t spanning-tree vlan 10 forward-time [10] // Forward Time 10s로 변경 (Default : 15s) spanning-tree vlan 10 hello-time [1] // Hello Time 1s로 변경 (Default : 2s) spanning-tree vlan 10 max-age
[STP] STP Case Study - Root Bridge 선출(Cisco) [내부링크]
STP Root Bridge 선출 Case Study(Cisco) 작업 개요 목적 STP의 Root Bridge 선출 순서를 확인한다. 일자 2022.12.25(일) 테스트 내용 01. STP Root Bridge 선출 ① - Bridge-ID가 가장 작은 SW 02. STP Root Bridge 선출 ① - Bridge-ID가 가장 작은 SW 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 Priority 값이 가장 작은 SW가 Root Bridge로 선출됨 - PVST Mode에서 Root Bridge의 Priority는 "Priority + VLAN"로 나타남 01. STP Root Bridge 선출 ① - Bridge-ID가 가장 작은 SW 모든 SW들은 Default Priority 값이 32768로 동일하므로 Root Bridge는 MAC Address로 결정됨 - SW
[STP] STP Case Study - Root Port 선출(Cisco) [내부링크]
STP Root Port 선출 Case Study(Cisco) 작업 개요 목적 STP의 Root Port 선출 순서를 확인한다. 일자 2022.12.25(일) 테스트 내용 01. STP Root Port 선출 ① - Root Bridge-ID가 가장 작은 BPDU를 수신한 포트 02. STP Root Port 선출 ② - Path Cost 값이 가장 낮은 포트 03. STP Root Port 선출 ③ - 인접 SW의 Bridge-ID가 가장 낮은 포트 04. STP Root Port 선출 ④ - 인접 SW의 Port-ID가 가장 낮은 포트 05. STP Root Port 선출 ⑤ - 자신의 Port-ID가 가장 낮은 포트 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 Root Port 선출은 SW 장비 기준으로 됨 STP RP포트 선출 순서 ① Root B-ID가 가장 낮은 BP
[STP] STP Case Study - Designated Port 선출(Cisco) [내부링크]
STP Designated Port 선출 Case Study(Cisco) 작업 개요 목적 STP의 Designated Port 선출 순서를 확인한다. 일자 2022.12.26(월) 테스트 내용 01. STP Designated Port 선출 ① - Root SW의 각 포트 02. STP Designated Port 선출 ② - 후순위(Inferior) BPDU를 수신한 포트 03. STP Designated Port 선출 ③ - Path Cost 값이 작은 SW의 포트 04. STP Designated Port 선출 ④ - B-ID가 작은 SW의 포트 05. STP Designated Port 선출 ⑤ - 자신의 Port-ID가 작은 포트 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 Designated Port 선출은 Link 기준으로 됨 STP DP포트 선출 순서 ① Root
[STP] STP Case Study - Port Fast(Cisco) [내부링크]
STP Port Fast Case Study(Cisco) 작업 개요 목적 STP의 Port Fast 기능을 확인한다. 일자 2022.12.26(월) 테스트 내용 01. STP Port Fast Case Study - 구성도 02. Port Fast 설정 03. Port Fast가 적용된 장비 인터페이스 UP/Down 후 상태 확인 04. Port Fast가 미적용된 장비 인터페이스 UP/Down 후 상태 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 단말향 인터페이스에 "Port Fast" 기능을 Enable한 후 shutdown / no shutdown 했을 때 즉각적으로 Forwarding 상태로 변경됨 "Port Fast" 기능은 Loop의 위험성이 있기 때문에 단말과 연결된 인터페이스만 적용됨 01. STP Port Fast Case Study - 구성도 02. Po
[STP] STP Case Study - Uplink Fast(Cisco) [내부링크]
STP Uplink Fast Case Study(Cisco) 작업 개요 목적 STP의 Uplink Fast 기능을 확인한다. 일자 2022.12.26(월) 테스트 내용 01. STP Uplink Fast Case Study - 구성도 02. Uplink Fast 설정 03. Uplink Fast가 적용된 장비 인터페이스 Down 후 상태 확인 04. Uplink Fast가 미적용된 장비 인터페이스 Down 후 상태 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 Blocking을 가지고 있는 SW4에 "Uplink Fast" 기능을 Enable한 후 shutdown 했을 때 즉각적으로 Blocking → Forwarding 상태로 변경됨 "Uplink Fast"가 적용되면 Priority 값과 Cost값이 증가함 Root Bridge에 "Uplink Fast" 설정 시 Pr
[STP] STP Case Study - Backbone Fast(Cisco) [내부링크]
STP Backbone Fast Case Study(Cisco) 작업 개요 목적 STP의 Backbone Fast 기능을 확인한다. 일자 2022.12.26(월) 테스트 내용 01. STP Backbone Fast Case Study - 구성도 02. Backbone Fast 설정 03. Backbone Fast 적용 후 인터페이스 Down 후 상태 확인 04. Backbone Fast 미적용 후 인터페이스 Down 후 상태 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 모든 스위치에 "Backbone Fast" 기능을 적용하지 않으면 정상적으로 동작하지 않음 모든 SW에 "Backbone Fast"를 Enable한 후 간접 Link Down 시 즉각적으로 Blocking → Listening으로 변경됨 "Backbone Fast"는 간접적으로 연결된 링크 장애 시 Blo
[STP] STP Case Study - BPDU Guard(Cisco) [내부링크]
STP BPDU Guard Case Study(Cisco) 작업 개요 목적 STP의 BPDU Guard 기능을 확인한다. 일자 2022.12.26(월) 테스트 내용 01. STP BPDU Guard Case Study - 구성도 02. BPDU Guard 설정 03. BPDU Guard 적용 시 BPDU 수신 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 "BPDU Guard"를 Enable 한 후 해당 Port로 BPDU가 수신되면 Port를 Down시킴 01. STP BPDU Guard Case Study - 구성도 02. BPDU Guard 설정 SW4 conf t interface e0/1 spanning-tree bpduguard enable // 해당 장비에 "BPDU Guard"를 적용함 end SW4에 "BPDU Guard" 기능을 적용함 03. BPDU Guard
[STP] STP Case Study - BPDU Filter(Cisco) [내부링크]
STP BPDU Filter Case Study(Cisco) 작업 개요 목적 STP의 BPDU Filter 기능을 확인한다. 일자 2022.12.26(월) 테스트 내용 01. STP BPDU Filter Case Study - 구성도 02. BPDU Filter 설정 03. BPDU Filter 적용 시 BPDU 송수신 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 "BPDU Filter"를 적용한 해당 인터페이스로 BPDU를 송수신하지 않음 01. STP BPDU Filter Case Study - 구성도 02. BPDU Filter 설정 SW3 conf t interface e0/1 spanning-tree bpdufilter enable // 해당 장비에 "BPDU Guard"를 적용함 end SW4에 "BPDU Filter" 기능을 적용함 03. BPDU Filter
[STP] STP Case Study - Root Guard(Cisco) [내부링크]
STP Root Guard Case Study(Cisco) 작업 개요 목적 STP의 Root Guard 기능을 확인한다. 일자 2022.12.26(월) 테스트 내용 01. STP Root Guard Case Study - 구성도 02. Root Guard 설정 03. Root Guard 적용 후 동작 확인 - 선순위 BPDU 수신 04. Root Guard 적용 후 동작 확인 - 후순위 BPDU 수신 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 "Root Guard" 설정 후 선순위 BPDU가 수신되면 해당 인터페이스를 논리적으로 Down 시킴 - 실제 인터페이스는 UP 상태 - 다시 후순위 BPDU를 수신하게 되면 해당 인터페이스를 활성화 시킴 01. STP Root Guard Case Study - 구성도 02. Root Guard 설정 SW2 conf t interface
[STP] STP Case Study - Loop Guard(Cisco) [내부링크]
STP Loop Guard Case Study(Cisco) 작업 개요 목적 STP의 Loop Guard 기능을 확인한다. 일자 2022.12.27(화) 테스트 내용 01. STP Loop Guard Case Study - 구성도 02. Loop Guard 설정 03. Loop Guard 적용 후 동작 확인 04. Loop Guard 적용 전 동작 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 "Loop Guard" 설정 후 BPDU를 수신하지 못하면 Forwarding으로 변경되는 것을 방지함 - 실제 인터페이스는 UP 상태 - "Loop Guard" 설정 전에 BPDU를 수신하지 못하면 Forwarding 변경으로 변경됨 01. STP Loop Guard Case Study - 구성도 02. Loop Guard 설정 SW4 conf t interface e0/0 spanni
[VLAN] VLAN Overview [내부링크]
VLAN(Virtual Local Area Network) Overview VLAN 이란 가상의 LAN 구성 논리적으로 Broadcast 분리 VLAN 장점 네트워크 분할 (Broadcast 분리) 유연성 증가 (물리적으로 큰 변화 없이 구성 변경 가능) 보안성 증가 (서로 다른 VLAN 간 직접적으로 통신 불가능) VLAN(Virtual Local Area Network) 할당 방식 Static 포트 단위로 VLAN 구성 관리자가 수동으로 VLAN 설정 Dynamic 별도 서버(VMPS)를 이용해 MAC 주소 단위로 VLAN Member 구성 VMPS(VLAN Membership Policy Server) - VLAN Membership에 관련 MAC을 보유한 서버 단말이 SW에 연결되면 SW가 VMPS에 단말의 MAC에 맞는 VLAN을 물어보고 할당받음 IEEE 802.1Q Frame Header (doq1q Header) IEEE 802.1Q Frame For
[VLAN] Access Mode/Trunk Mode 개념 및 동작 과정 [내부링크]
Access Mode Access Mode 포트 당 하나의 VLAN 할당 Frame이 SW의 포트로 들어갈 때 Tag가 붙고 포트에서 나올 때 Tag가 떼어짐 Access Mode 동작 과정 - SW간 같은 VLAN 통신 1. 물리적 연결 구성 2. PC1→PC3 Ping 통신 시도 3. SW의 Access Mode로 설정된 포트로 Import 시 10번 Tag 생성 4. SW의 Access Mode로 설정된 포트로 export 시 Tag 제거 5. SW의 Access Mode로 설정된 포트로 Import 시 10번 Tag 생성 6. SW의 Access Mode로 설정된 포트로 export 시 Tag 제거 7. PC3→PC1 Ping Reply 시 위와 같이 진행 Access Mode 동작 과정 - SW간 다른 VLAN 통신 1. 물리적 연결 구성 2. PC1→PC4 Ping 통신 시도 3. SW의 Access Mode로 설정된 포트로 Import 시 10번 Tag 생성 4. S
[VLAN] Native VLAN 개념 및 동작 과정 [내부링크]
Native VLAN(Virtual Local Area Network) Native VLAN Tag를 식별하지 못하는 장치도 통신할 수 있도록 도와줌 802.1Q Trunk에서만 사용 → 802.1Q는 Native VLAN을 이용해 캡슐화되지 않은 Frame도 송수신 가능 → ISL은 캡슐화되지 않은 Frame을 수신하면 폐기 Native VLAN을 Trunk로 송신 시 Tag를 붙이지 않고 송신 Trunk 포트로 Tag가 없는 프레임을 수신하면 Native VLAN에 소속된 것이라 판단 양측 SW에 Native VLAN번호가 동일해야 함 Trunk 모드는 Tag에 관여하지 않음 같은 SW의 포트마다 Native VLAN을 다르게 설정할 수 있음 Native VLAN 3인 포트에 3번 Tag가 있는 프레임이 들어오면 드롭하지 않고 처리함 Native VLAN 동작 과정 및 필요성 Native VLAN 동작 과정 및 필요성 1. 물리적 연결 구성 2. PC1→PC3 Pi
[VLAN] Inter VLAN 개념 [내부링크]
Inter VLAN(Virtual Local Area Network) 서로 다른 VLAN이 통신할 수 있게 하는 기술 → VLAN 사이에서 라우팅 함 라우터는 기본적으로 Tag를 인식하지 않아 Tag가 있는 프레임을 버림 Sub-Interface - GW 분리 - 라우터가 VLAN을 인식할 수 있게 해 줌 Inter VLAN 필요성 Inter VLAN 필요성 - L3 장비 없을 시 1. PC1→PC2 Ping 통신 시도 2. SW의 Access Mode로 설정된 포트로 Import 시 10번 Tag 생성 3. 20번 Tag로 설정된 Access Port로 다른 VLAN Tag를 가지고 있는 데이터 송신 불가능 4. Tag가 있는 프레임이 SW로 들어오면 Tag가 붙음 Inter VLAN 필요성 - L3 장비 있을 시 1. PC1→PC2 Ping 통신 시도 2. SW의 Access Mode로 설정된 포트로 Import 시 10번 Tag 생성 3. SW의 Trunk로 설정된 포트로
[VLAN] SVI / Physical Interface [내부링크]
Multilayer Switch IP 설정 방법 SVI(Switched Virtual Interface) 가상 인터페이스 L2에서는 관리적인 목적으로 사용하지만 L3에선 Gateway역할 Routed Port 스위치 기능을 제거한 포트 들어오는 데이터는 Switch Process를 거치지 않음 SVI(Switched Virtual Interface) SVI 논리적 구조 VLAN 10로 설정된 물리적인 Port는 VLAN 10을 가진 가상 SW에 연결 VLAN 20로 설정된 물리적인 Port는 VLAN 20를 가진 가상 SW에 연결 Trunk로 설정된 물리적인 Port는 각각의 가상 SW에 연결됨 물리적 포트 중 VLAN 10을 가진 포트가 Down 되면 해당 Port와 연결되어있는 가상 SW의 포트가 사라짐 VLAN 10에 해당하는 논리적 포트가 모두 Down 되면 L3 Port(SVI)만 남음 - L3 기능을 할 필요가 없으므로 가상 SW에서 SVI와 연결되어있는
[VLAN] VTP 개념 [내부링크]
VTP 개념 VTP(VLAN Trunking Protocol) Trunk로 연결된 스위치끼리 VLAN DB를 동기화하는 프로토콜 → 포트 설정은 배포되지 않음 VTP 정보는 라우터를 넘어 전송되지 않음 → 라우터가 VTP 도메인을 분리 End-to-End VLAN일 때 주로 사용 Local VLAN은 SW마다 가지고 있는 VLAN 정보가 달라 VTP를 설정할 필요가 없음 → VTP를 사용하지 않으려면 VTP Mode를 Transparent로 설정 VTP를 끌 수 없음 Revision Number 만으로 VLAN을 동기화함. VTP 모드를 Transparent에서 Server로 변경하면 Revision Number가 초기화됨 VTP 사용 조건 1. VTP Domain 동일 2. SW간 Trunk Port로 연결 3. VTP Password 설정 시 Password 동일 VTP Mode 모드 설명 Server - VLAN 생성, 수정, 삭제 가능 - 기본 VTP Mode이며
[VLAN] 명령어(Cisco) [내부링크]
VLAN 설정 명령어 VLAN 생성 및 제거 conf t vlan 10 name VLAN_TEST // vlan10 이름 변경 exit no vlan 10 // vlan10 제거 end conf t vlan 10-15 // VLAN 10~15 생성 exit vlan 20,30 // VLAN 20, 30 생성 end Access Mode 설정 conf t interface e0/0 switchport mode access switchport access vlan 10 // e0/0 포트를 vlan 10으로 mapping no shutdown end Trunk Mode 설정 conf t interface e0/1 switchport trunk encapsulation dot1q // VLAN Tag 방식 설정(Dot1Q or ISL) → 해당 명령어가 없는 경우는 ISL 방식을 지원하지 않고 Default가 Dot1Q를 지원 switchport mode trunk // e0/1 포트를
[VLAN] VLAN Case Study - Access Mode ①(Cisco) [내부링크]
VLAN Access Mode ① Case Study(Cisco) 작업 개요 목적 하나의 SW에 동일한 VLAN 설정 시 통신 과정을 확인한다. 일자 2022.12.23(금) 테스트 내용 01. VLAN Access Mode Case Study - 구성도 02. VLAN 설정 03. VLAN 설정 확인 04. IP 설정 05. IP 설정 확인 06. Access Mode VLAN Tag 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 Access Mode일 때 패킷의 VLAN Tag는 장비에 수신될 때 붙고 송신될 때 떼짐 - Wireshark로 캡처 시 VLAN Tag가 안 보임 01. VLAN Access Mode Case Study - 구성도 02. VLAN 설정 SW1 conf t vlan 100 // VLAN 100 생성 name VLAN 100 // VLAN 100에
[VLAN] VLAN Case Study - Access Mode ②(Cisco) [내부링크]
VLAN Access Mode ② Case Study(Cisco) 작업 개요 목적 하나의 SW에 서로 다른 VLAN 설정 시 통신 과정을 확인한다. 일자 2022.12.23(금) 테스트 내용 01. VLAN Access Mode Case Study - 구성도 02. VLAN 설정 03. VLAN 설정 확인 04. IP 설정 05. IP 설정 확인 06. Access Mode VLAN Tag 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 Access Mode일 때 패킷의 VLAN Tag는 장비에 수신될 때 붙고 송신될 때 떼짐 - Wireshark로 캡처 시 VLAN Tag가 안 보임 SW에서 서로 다른 VLAN 설정 시 통신이 불가능 함 01. VLAN Access Mode Case Study - 구성도 02. VLAN 설정 SW1 conf t vlan 100 // VLAN
[VLAN] VLAN Case Study - Access Mode ③(Cisco) [내부링크]
VLAN Access Mode ③ Case Study(Cisco) 작업 개요 목적 SW 간 동일한 VLAN 설정 시 통신 과정을 확인한다. 일자 2022.12.23(금) 테스트 내용 01. VLAN Access Mode Case Study - 구성도 02. VLAN 설정 03. VLAN 설정 확인 04. IP 설정 05. IP 설정 확인 06. Access Mode VLAN Tag 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 Access Mode일 때 패킷의 VLAN Tag는 장비에 수신될 때 붙고 송신될 때 떼짐 - Wireshark로 캡처 시 VLAN Tag가 안 보임 01. VLAN Access Mode Case Study - 구성도 02. VLAN 설정 SW1 conf t vlan 100 // VLAN 100 생성 name VLAN 100 // VLAN 100에 대한
[VLAN] VLAN Case Study - Access Mode ④(Cisco) [내부링크]
VLAN Access Mode ④ Case Study(Cisco) 작업 개요 목적 SW 간 서로 다른 VLAN 설정 시 통신 과정을 확인한다. 일자 2022.12.23(금) 테스트 내용 01. VLAN Access Mode Case Study - 구성도 02. VLAN 설정 03. VLAN 설정 확인 04. IP 설정 05. IP 설정 확인 06. Access Mode VLAN Tag 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 Access Mode일 때 패킷의 VLAN Tag는 장비에 수신될 때 붙고 송신될 때 떼짐 - Wireshark로 캡처 시 VLAN Tag가 안 보임 SW 간 서로 다른 VLAN 설정 시 통신은 가능함 - 대신 VLAN Mismatch 로그가 발생함 01. VLAN Access Mode Case Study - 구성도 02. VLAN 설정 SW1 c
[VLAN] VLAN Case Study - Trunk Mode ①(Cisco) [내부링크]
VLAN Trunk Mode ① Case Study(Cisco) 작업 개요 목적 SW 간 같은 VLAN 설정 시 통신 과정을 확인한다. 일자 2022.12.23(금) 테스트 내용 01. VLAN Trunk Mode Case Study - 구성도 02. VLAN 설정 03. VLAN 설정 확인 04. IP 설정 05. IP 설정 확인 06. Trunk Mode VLAN Tag 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 Trunk Mode일 때는 패킷을 수신 시 VLAN Tag를 붙이고 송신할 때 VLAN Tag를 제거하지 않음 01. VLAN Trunk Mode Case Study - 구성도 02. VLAN 설정 SW1 conf t vlan 100 // VLAN 100 생성 name VLAN 100 // VLAN 100에 대한 Name 적용 end conf t interfa
[VLAN] VLAN Case Study - Trunk Mode ②(Cisco) [내부링크]
VLAN Trunk Mode ② Case Study(Cisco) 작업 개요 목적 SW 간 서로 다른 VLAN 설정 시 통신 과정을 확인한다. 일자 2022.12.23(금) 테스트 내용 01. VLAN Trunk Mode Case Study - 구성도 02. VLAN 설정 03. VLAN 설정 확인 04. IP 설정 05. IP 설정 확인 06. Trunk Mode VLAN Tag 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 Trunk Mode일 때는 패킷을 수신 시 VLAN Tag를 붙이고 송신할 때 VLAN Tag를 제거하지 않음 01. VLAN Trunk Mode Case Study - 구성도 02. VLAN 설정 SW1 conf t vlan 100 // VLAN 100 생성 name VLAN 100 // VLAN 100에 대한 Name 적용 end conf t inte
[VLAN] VLAN Case Study - Allowed VLAN(Cisco) [내부링크]
VLAN Allowed VLAN Case Study (Cisco) 작업 개요 목적 SW 간 Allowed VLAN 설정 시 통신 과정을 확인한다. 일자 2022.12.23(금) 테스트 내용 01. VLAN Trunk Mode Case Study - 구성도 02. VLAN 설정 03. VLAN 설정 확인 04. IP 설정 05. IP 설정 확인 06. Allowed VLAN Tag 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 Trunk Mode일 때는 패킷을 수신 시 VLAN Tag를 붙이고 송신할 때 VLAN Tag를 제거하지 않음 Trunk Allowed에서 설정한 VLAN만 Trunk Mode 인터페이스로 송수신이 가능함 01. VLAN Allowed VLAN Case Study - 구성도 02. VLAN 설정 SW1 conf t vlan 100 // VLAN 100
[VLAN] VLAN Case Study - Native VLAN(Cisco) [내부링크]
VLAN Native VLAN Case Study(Cisco) 작업 개요 목적 - SW 간 Native VLAN 설정 불일치 시 통신 과정을 확인한다. - Native VLAN으로 설정한 포트로 Untag VLAN을 수신 시 통신 과정을 확인한다. 일자 2022.12.23(금) 테스트 내용 01. VLAN Native VLAN Case Study - 구성도 02. VLAN 설정 03. VLAN 설정 확인 04. IP 설정 05. IP 설정 확인 06. Native VLAN Mismatch 시 통신 과정 확인 테스트 계측기 - 장비 / OS L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 일반적인 Trunk Mode는 패킷을 전송할 때 VLAN Tag를 제거하지 않지만 Native VLAN은 Tag를 제거함 Native VLAN에서 Untag 패킷을 수신하면 해당 패킷은 Native VLAN(Tag 1)으로 인식함
[VLAN] VLAN Case Study - Inter VLAN(Cisco) [내부링크]
VLAN Inter VLAN Case Study(Cisco) 작업 개요 목적 Inter-VLAN을 사용하여 서로 다른 VLAN 간 통신을 확인한다. 일자 2022.12.24(토) 테스트 내용 01. VLAN Inter VLAN Case Study - 구성도 02. VLAN 설정 03. VLAN 설정 확인 04. IP 설정 05. IP 설정 확인 06. Inter-VLAN을 사용하여 VLAN 간 통신 과정 확인 테스트 계측기 - 장비 / OS L3 Cisco / IOS I86BI_LINUX-ADVENTERPRISEK9-M / Version 15.5(2)T L2 Cisco / IOL I86BI_LINUXL2-ADVENTERPRISEK9-M / Version 15.1 결과 라우터를 Sub-Interface로 설정하는 이유 - 하나의 물리적 인터페이스를 여러 논리적 인터페이스로 구성할 수 있음 - VLAN Tag를 인식할 수 있게 해줌 Inter-VLAN을 이용하여 서로 다른 VLAN
[ARP] ARP Overview [내부링크]
ARP(Address Resolution Protocol) Overview ARP 란 Network에서 통신할 때 Address는 필수 2,3,4 각 계층에 해당하는 Address가 있음 - Layer 2 : Mac 주소 (Etherent Protocol일 시) - Layer 3 : IPv4 (보통 IPv4에 해당됨) - Layer 4 : Port Number ARP는 통신할 때 필요한 Address를 Resolution해주는 Protocol임 ARP 할당 방식 Static - 관리자가 직접 할당 Dynamic - 프로토콜을 이용 - ARP를 이용하는 것 Unicast ARP (ARP Polling) Broadcast 통신을 최소화하기 위해, 계속 통신하고 있는 상대이면 Unicast로 ARP를 주기적으로 보냄 - 보통 ARP는 Broadcast로 통신됨 옵션으로 설정 가능 ARP Header Format ARP Header Format 필드 내용 Destination
[ARP] ARP 동작 과정 [내부링크]
ARP 동작 과정 PC1→PC2 Ping 테스트 PC1→PC2 Ping 테스트를 위해 MAC 주소를 알아야 함 PC1→PC2 Ping 테스트 시 PC1은 본인의 IP와 상대방의 IP를 비교하여 같은 Network에 있는지 확인함 - 같은 Network 시 D-IP을 PC2로 세팅함 - 다른 Network 시 D-IP을 Gateway로 세팅함 PC1은 PC2가 다른 Network라는 것을 확인하여 PC1은 Gateway의 IP와 MAC을 알아내려 함 - PC1은 본인이 ARP Table에 Gateway에 대한 정보가 없으므로 ARP 발생 ARP Request할 때 Ethernet Header의 D-MAC은 FF:FF:FF:FF:FF:FF이지만 ARP Header의 D-MAC은 00:00:00:00:00:00으로 채워짐 - FF:FF:FF:FF:FF:FF는 Broadcast라는 의미 - 00:00:00:00:00:00은 해당 주소를 알아야 한다는 의미 PC1→SW1 ARP Req
[ARP] Proxy ARP 동작 과정 [내부링크]
Proxy ARP 동작 과정 PC1→PC2 Ping 테스트 PC1→PC2 Ping 테스트를 위해 MAC 주소를 알아야 함 PC1→PC2 Ping 테스트 시 PC1은 본인의 IP와 상대방의 IP를 비교하여 같은 Network에 있는지 확인함 - 같은 Network 시 D-IP을 PC2로 세팅함 - 다른 Network 시 D-IP을 Gateway로 세팅함 PC1은 PC2가 다른 Network라는 것을 확인하여 PC1은 Gateway의 IP와 MAC을 알아내려 함 - PC1은 본인이 ARP Table에 Gateway에 대한 정보가 없으므로 ARP 발생 ARP Request할 때 Ethernet Header의 D-MAC은 FF:FF:FF:FF:FF:FF이지만 ARP Header의 D-MAC은 00:00:00:00:00:00으로 채워짐 - FF:FF:FF:FF:FF:FF는 Broadcast라는 의미 - 00:00:00:00:00:00은 해당 주소를 알아야 한다는 의미 Proxy AR
[ARP] RARP 동작 과정 [내부링크]
RARP(Reverse ARP) 동작 과정 RARP(Reverse ARP) Request / Reply 1. Host가 부팅되면 IP 할당받기 위해 RARP Server에게 RARP Request를 Broadcast로 보냄 - 출발지 IP와 도착지 IP는 정의되지 않음 - Host는 본인의 MAC을 알려주며 IP를 요청하는 것 - Host는 "내 MAC은 X.X.X.X인데 IP를 알려줘" 2. RARP Server는 파일에 Host의 MAC 주소와 이에 해당하는 IP를 미리 적어놓은 상태임 - RARP Request의 S-MAC이 파일에 없으면 Drop시키고 있으면 해당하는 IP를 할당해 줌 3. RARP Reply는 S-IP와 D-IP는 각각 RARP Server, Host로 채워지며 유니캐스트로 송신함 - Server는 Host의 MAC을 확인 후 IP를 할당해 줌 - Server는 "너의 IP는 X.X.X.X"라고 알려줌
[ARP] Inverse ARP 동작 과정 [내부링크]
Inverse ARP 동작 과정 Inverse ARP 동작 확인 전 설정 확인 네트워크 장비에 Default로 Inverse-ARP는 Enable되어 있음 아래 토폴로지에서 R1, R2의 설정 예시 - Invserse ARP를 사용하면 특별한 설정이 필요하지 않음 - 단, Frame-Relay SW에는 DLCI Mapping을 해줘야 함 conf t interface serial 2/0 encapsulation frame-relay ip address 1.1.12.1 255.255.255.0 no shutdown end Inverse ARP 동작 과정 ① 라우터에 Inverse-ARP를 Enable 시키고 "encapsulation frame-relay"을 설정하면 Frame-Relay SW는 설정된 VC에 DLCI를 Mapping 하고 Frame-Relay SW는 해당 VC에 연결된 라우터의 IP와 DLCI를 Mapping함 ② 라우터는 Frame-Relay SW와 정상적으로
[ARP] GARP 동작 과정 [내부링크]
Gratuitous ARP 동작 과정 Gratuitous ARP - IP 충돌 감지 (IP 중복 없을 시) GARP의 목적 중 하나는 IP 충돌 감지를 확인하는 것 IP 충돌이 없을 시 GARP Request만 있고 GARP Reply는 없음 GARP는 S-IP와 D-IP가 본인인 것이 특징임 장비에 IP를 입력하면 입력한 IP가 중복되는 IP인지 확인하기 위해 GARP Request를 송신함 SW는 D-MAC이 Broadcast인 Data를 받으므로 Flooding함 IP 충돌이 없으므로 GARP Reply가 없음 GARP의 Request를 캡처한 내용임 Gratuitous ARP - IP 충돌 감지 (IP 중복 시) PC1(장비)에 IP를 입력하면 입력한 IP가 중복되는 IP인지 확인하기 위해 GARP Request를 송신함 SW는 D-MAC이 Broadcast인 Data를 받으므로 Flooding함 PC2(장비)에 IP를 입력하면 입력한 IP가 중복되는 IP인
[Basics] 네트워크 / 인터넷 [내부링크]
네트워크 네트워크 통신 가능한 두 대 이상의 장비가 연결되어 통신 가능한 환경 인터넷 인터넷 네트워크를 연결하여 서로 통신 가능한 환경
[Basics] Broadcast Domain / Collision Domain [내부링크]
Broadcast Domain Broadcast Doamin Broadcast Packet이 도달할 수 있는 영역 "같은 Broadcast Domain = 같은 IP 대역 = 같은 Gateway = 같은 LAN" Collision Domain Collision Domain Ethernet 환경에서 Collision이 발생할 수 있는 영역 2계층 장비(L2 스위치 등)는 Collision Domain을 분리할 수 있음 (단, Full Duplex 이어야 가능함) - 1계층 장비(Hub 등)는 Collision Domain을 분리할 수 없음 - Hub는 Half Duplex로 동작
[Basics] Simplex / Duplex [내부링크]
Simplex Simplex 송신 or 수신만 가능 단방향 통신 Ex) TV, 라디오 등 Duplex Duplex 송수신 가능(양방향 통신) Half Duplex - 송신과 수신이 가능한 양방향 통신이지만 송수신이 동시에 불가능 - Ex) 무전기 Full Duplex - 송신과 수신이 가능한 양방향 통신이며 송수신이 동시에 가능 - Ex) 전화기
[Basics] Gateway [내부링크]
Gateway Gateway 다른 네트워크로 가기 위해 지나야 하는 곳 다른 네트워크 = 다른 IP 대역 = 다른 Broadcast - 사용자가 Gateway를 입력하지 않으면 같은 IP 대역 안에서만 통신 가능
[Basics] Bit Rate / Bandwidth / Throughput [내부링크]
Bit Rate(전송 속도) Bit Rate(전송 속도) 1초 동안 한 지점에서 다른 지점으로 옮겨진 데이터의 양(속도)를 의미 - 측정시간 동안의 평균 전송속도를 나타냄 단위로는 bps를 가장 많이 사용하며 필요에 따라 cps, 초당 블록수, 초당 패킷수, baud 등을 쓰기도 함 Bandwidth Bandwidth 해당 포트가 1초 동안 전송하는 Bit의 양 bps, Kbps, Mbps, Gbps 등으로 표시되며 HZ로 표현하기도 함 Bit Rate / Bandwidth 차이 Bit Rate / Bandwidth 차이 컨베이어 벨트로 반도체를 제작한다고 가정하고 왼쪽과 오른쪽은 서로 다른 공정을 진행한다고 가정 전송속도 - A공정과 B공정의 처리 속도가 빨라 회전율이 높아지는 것을 의미 - A공정의 처리속도가 빠르지만 B공정의 처리속도가 느리면 전체적으로 전송속도가 느린 것 대역폭 - 컨베이어벨트의 너비를 의미 - 보통 대역폭이 크면 전송속도가 빠르지만 반드시 그런
[Basics] RTT / Latency / Delay / Jitter / Loss [내부링크]
RTT(Round Trip Time) RTT(Round Trip Time) 패킷 왕복 시간 데이터가 목적지에 도달하고 출발지로 돌아오는 시간 Latency Latency Latency는 여러 의미로 해석될 수 있음 패킷을 송신하여 수신하기까지 걸리는 시간을 의미(RTT) 패킷을 송신하는데 걸리는 시간을 의미 장비가 데이터를 수신하여 송신하기까지 걸리는 시간을 의미 → 라우팅 / 스위칭 / 복호화 등에 해당할 수 있음 → 보통 해당 Delay Delay Delay는 개별 요소의 Latency가 합해진 것 Delay와 Latency는 지연의 의미가 있음 Latency는 개별 요소 중심의 지연 시간을 의미 발신지를 떠나 목적지에 도착하는데 걸리는 시간 Jitter Jitter Latency or Delay의 일정한 정도 패킷이 도착하는 시간 변화 Loss Loss 패킷이 목적지에 도착하지 못한 것을 의미 보통 Bandwidth가 부족하거나 Delay가 길어 발생
[Basics] MTU / MSS / Pass MTU [내부링크]
IPv4 MTU(Maximum Transmission Unit) MTU(Maximum Transmission Unit) 프레임 or 패킷에서 한 번에 전송될 수 있는 최대 크기 단위 : Byte 보통 Ethernet Header 14Byte + FCS 4Byte가 추가되어 프레임 MTU가 1518이 됨 패킷을 분할하는 이유 - 패킷을 분할하지 않고 송신하면 패킷이 모두 도달할 때까지 해당 구간을 점유하기 때문 네트워크 MTU가 단말 데이터의 MTU보다 작으면 네트워크 장비에서 DF bit를 확인 - DF bit = 0 이면 나눠서 처리 - DF bit = 1 이면 Drop&ICMP 발생 1500Byte 패킷을 MTU=500Byte로 설정했을 때 아래와 같이 분할됨 MSS(Maximum Segment Size) MSS(Maximum Segment Size) 4계층의 데이터 부분의 최대 값으로 분할하지 않고 한 번에 보내는 것 MSS = MTU - IP Haeder - T
[Basics] Network 구성 방식 [내부링크]
Point-to-Point Point-to-Point 1:1 통신 방법 목적지 주소를 브로드캐스, 멀티캐스트, 유니캐스트 중 어떤 것을 사용하여도 상관없음 Broadcast Multi-access Broadcast Multi-access Broadcast : 패킷을 전송할 때 동일 네트워크에 있는 모든 장비에게 도달할 수 있는 네트워크 Multi-access : 하나의 인터페이스를 통해 다수의 장비와 연결되는 네트워크 Non-Broadcast Multi-access Non-Broadcast Multi-access Broadcast 기능이 지원되지 않는 Multi-access네트워크 대부분의 NBMA는 내부에서 Virtual Circuit 방식을 사용하여 멀티액세스를 구현함 가상회로 번호의 이름은 인캡슐레이션 방식마다 다름 - 프레임 릴레이의 VC번호 : DLCI(Data Link Connection Identifier) 브로드캐스트나 멀티캐스트를 각 DLCI로 패킷을
[Basics] OSI 7 Layer 및 TCP/IP [내부링크]
OSI 7 Layer(Open Systems Interconnection) OSI 7 Layer(Open Systems Interconnection) IOS(International Organization for Standardization) 국제 표준화 기구에서 정의 7단계로 구분 RFC 문서로 정의(표준) 보통 참조용 TCP/IP(Transmission Control Protocol / Internet Protocol) TCP/IP(Transmission Control Protocol / Internet Protocol) IETF(Internet Engineering Task Force) 국제 인터넷 표준화 기구에서 정의 4단계로 구분 보통 프로토콜에 사용 계층적 구조의 장단점 계층적 구조의 장단점 TS(TroubleShooting) 용이 - 낮은 계층부터 장애처리 - 한 계층의 변화가 다른 계층에 영향을 미치는 정도가 작다 데이터의 흐름 이해 - 통신에 대한 시
[Basics] CSMA/CD [내부링크]
CSMA/CD(Carrier Sense Multiple Access/Collision Detection) 전송 후 충돌을 감지하고 재전송하는 방식 CS(Carrier Sense) 네트워크 신호가 있는지 감지 데이터를 보내기 전 네트워크에서 다른 데이터가 전송되고 있는지 확인 Idle 상태 : 전송 시도 Busy 상태 : 대기 MA(Multiple Access) 동일 시간에 2개 이상의 장비가 데이터를 보낼 수 있음 CD(Collision Detection) 데이터 충돌 시 모든 단말에게 신호를 보내 충돌을 없앰 - 데이터 충돌 시 JAM 신호 발송 (JAM : 32~48bit) - 충돌 발생 시 "Backoff" 시간이 약 2배씩 증가 충돌 발생 시 최대 15회 재전송 시도 (실패 시 Frame 전송 포기) CSMA/CD 동작 과정 CSMA/CD 동작 과정 CSMA/CD 문제점(Ethernet Frame Minimum Size) CSMA/CD 문제점(Ethernet Fr
[Basics] CSMA/CA [내부링크]
CSMA/CA(Carrier Sense Multiple Access/Collision Avoidance) CSMA/CA(Carrier Sense Multiple Access/Collision Avoidance) 충돌을 회피하는 방식 11개의 채널 중 중첩되지 않는 3개의 채널로 통신하여 충돌 회피 DCF(Distributed Coordination Function) 방식 사용 → 개별적인 노드가 경쟁에 의해 무선 채널을 획득하도록 하는 방식 CS(Carrier Sense) 망에 다른 신호가 있는지 감지 망이 Idle 상태면 IFS 만큼 기다렸다가 데이터 전송 - IFS(Interface Space) - 대기 중일 때도 채널을 계속 감시 - 채널이 사용 중이라 감지되면 타이머를 멈추고 채널이 Idle 상태일 때 다시 동작 (오래 기다린 지국이 우선순위를 가짐) IFS 시간 후에 채널이 비어있으면 전송 시작 - 아닌 경우 Backoff Time 동안 대기 후 전송 가능(대기
[Basics] Switch 5대 기능 [내부링크]
Learning 기능 Learning 기능 S-MAC을 기반으로 Mac Table 학습 BUM 트래픽은 스위치의 Mac Table에 학습 불가능 → BUM 트래픽 : Broadcast, Unknown Unicast, Multicast 트래픽 Flooding 기능 Flooding 기능 MAC Table에 등록되지 않는 D-M을 가진 프레임을 수신하면 모든 포트로 전송함 Filtering 기능 Filtering 기능 프레임이 수신된 포트로 다시 전송하지 않음 프레임을 포워딩할 때 다른 포트로 프레임을 전송하지 않음 Forwarding 기능 Forwarding 기능 생성된 MAC Table을 기반으로 D-M이 연결되어 있는 포트로 프레임을 전달 VLAN 별로 발생 Aging 기능 Aging 기능 Aging Time 이내 MAC Table에 있는 MAC을 달고 들어온 프레임이 들어오지 않으면 MAC Table에서 삭제됨 (Default : 300초) Aging Time 이내
[Basics] Switch와 Router 차이 [내부링크]
Switch 최적의 경로를 찾는 알고리즘 없이 정보에 의해 데이터를 처리하는 것 L2 SW에 Frame이 들어오면 L2 Header를 De-Encap하지 않음 → D-MAC을 보기만 함 받은 데이터의 D-MAC가 본인 MAC인지 확인하고 맞으면 처리, 아니면 MAC Table을 참조 서로 다른 Broadcast Domain끼리 통신 불가능 Router 라우터는 IP를 사용하여 패킷을 전달하기 때문에 Broadcast Packet을 전달하지 않음 최적의 경로를 찾는 알고리즘이 있는 것 Routing 이란 - 목적지까지 패킷을 전달하는 방법을 결정하는 경로 선택 과정 Routing이라는 프로세스를 통해 모든 경로를 수집한 후, 최적의 경로를 선택하는 것 수신된 데이터의 D-IP가 본인 IP인지 확인하고 맞으면 처리, 본인의 IP가 아니면 Routing Table에서 비교 서로 다른 Broadcast Domain끼리 통신이 가능하게 도와줌 Mac Table이 있는 장비
[Basics] IPv4 Header [내부링크]
IPv4 Header IPv4 Header Format Version IP 버전을 나타냄 HL(Header Length) 옵션을 포함한 헤더 전체 길이 ToS(Type of Service) 트래픽 우선순위를 결정 DSCP - 7~5 · 어떤 패킷을 먼저 처리할지 정함 (우선 트래픽) - 4~3 · 패킷을 큐에 넣고 송수신함 · 큐에 있는 데이터에 대한 드랍률 결정 (중요한 데이터는 드롭되지 않음) - 2 · 사용 안 함 ECN - 1~0 · 큐가 모두 차면 드롭하지 않고 전송 · 해당 트래픽을 받은 장비는 드롭을 안 했지만 드롭된 것처럼 인식 · 트래픽을 받은 장비는 해당 데이터가 Loss난 것으로 인식해 속도를 줄임 · 우선순위가 높지 않은 데이터일수록 ECN필드 값이 높음 Total Length IP 패킷의 전체 길이 (L3H + Data) Identification 나눠진 데이터가 목적지에 도착했을 때 같은 데이터인지 구분 가능하게 해 줌 패킷을 송신하는 장비가
[Basics] IPv4 유형(Unicast/Multicast/Broadcast) [내부링크]
Unicast Unicast 하나의 목적지로 전송 (1:1 통신) Multicast Multicast 특정된 목적지로 전송 (1:N 통신) → 패킷을 복제하여 전송 D클래스 주소 사용 Multicast IP에 대응하는 MAC 주소가 이미 맵핑됨 Broadcast Broadcast 같은 대역의 모든 장비에게 전송 (1:N 통신) 55.255.255.255 VS 192.168.11.255 - 보통 아래와 같이 구분 · 255.255.255.255 : Global Broadcast Address · 192.168.11.255 : Network Layer Broadcast Address - RFC 919 문서에 따르면 아래와 같이 구분 · 255.255.255.255 : Local Broadcast Address · 192.168.11.255 : Directed Broadcast Address Direct Broadcast Direct Broadcast D-IP가 Direct가
[Basics] 공인 IP / 사설 IP [내부링크]
공인 IP 공인 IP 세계적으로 중복되지 않는 고유 식별번호 인터넷에서 외부로 공개되어 접근이 가능 IP 범위에서 예약된 IP 범위가 있음(사설 IP 등) IP 할당 과정 - ICANN → APNIC → KRNIC → ISP → 개인 사설 IP 사설 IP 공용 IP 수의 제한으로 사설 IP 할당 내부적으로 임의로 통신하기 위해 사설 IP 적용 → 인터넷이랑 통신하기 위해서 공인 IP를 사용해야 함 공용 IPv4 부족으로 NAT 기술 도입 NAT는 IP 주소 변환하는 기술 → NAT는 공용 IP와 사설 IP를 변경해주는 기술이 아님 → 보통 공용 IP와 사설 IP를 변경함 클래스 서브넷마스크 사설IP 식별용 상위 비트 주소범위 A /8 10.0.0.0 ~ 10.255.255.255 0xxx xxxx 0.0.0.0 ~ 127.255.255.255 B /16 172.16.0.0 ~ 172.31.255.255 10xx xxxx 128.0.0.0 ~ 191.255.255.255
[Basics] IPv4 Classful / Classless [내부링크]
Classful Classful Classful IP 체계를 사용 - 클래스 체계(A클래스, B클래스 등)를 사용 D Class는 하나의 IP가 하나의 서비스를 제공하므로 서브넷 마스크가 없음 E Class는 실험용 클래스 서브넷마스크 사설IP 식별용 상위 비트 주소범위 A /8 10.0.0.0 ~ 10.255.255.255 0xxx xxxx 0.0.0.0 ~ 127.255.255.255 B /16 172.16.0.0 ~ 172.31.255.255 10xx xxxx 128.0.0.0 ~ 191.255.255.255 C /24 192.168.0.0 ~ 192.168.255.255 110x xxxx 192.0.0.0 ~ 223.255.255.255 D 239.0.0.1 ~ 239.255.255.255 1110 xxxx 224.0.0.0 ~ 239.255.255.255 E 1111 xxxx 240.0.0.0 ~ 255.255.255.255 Classless Classless Cla
[Basics] Subnet Mask / CIDR [내부링크]
Subnet Mask Subnet Mask IP의 Network와 Host를 구분하는 역할 IP와 AND 연산을 통해 동일 네트워크인지 확인 2진수로 표기 시 0 오른쪽에 1이 올 수 없음 - ex) 1111 1111 1111 1111 1111 1101 0000 0000 (사용 불가능) - ex) 1111 1111 1111 1111 1111 1111 0000 0000 (사용 가능) 프리픽스 크기 서브넷마스크 마지막 바이트 네트워크 수 최대 호스트 수 /24 255.255.255.0 0000 0000 1 256(254) /25 255.255.255.128 1000 0000 2 128(126) /26 255.255.255.192 1100 0000 4 64(62) /27 255.255.255.224 1110 0000 8 32(30) /28 255.255.255.240 1111 0000 16 16(14) /29 255.255.255.248 1111 1000 32 8(6) /30 255
[Basics] Subnetting / Supernetting [내부링크]
Subnetting Subnetting IP 낭비를 방지하기 위하여 하나의 네트워크를 여러 네트워크로 분리하는 것 서브넷팅을 하여 분리된 네트워크 단위를 서브넷이라 함 아래 그림은 B클래스를 서브 넷팅 한 것 - Subnet 개수 : 2^8 - Subnet 당 Host 개수 : 2^8 - 2 (2 → NET-ID, Broadcast 제외) - Subnetting 방법은 FLSM, VLSM에서 자세히 설명됨 Supernetting Supernetting 작은 네트워크를 하나의 네트워크로 합치는 것 여러 경로를 하나의 경로로 요약(축약) 리소스 절약 가능 Supernetting EX - 192.168.10.0/24인 네트워크에서 부서 인원이 250→350으로 증가되었다. 슈퍼넷팅을 통해 350명이 사용할 수 있는 하나의 네트워크 구하기 C 클래스 2개를 슈퍼넷팅을 하여 하나의 네트워크로 구성
[Basics] FLSM / VLSM [내부링크]
FLSM(Fixed-Length Subnet Mask) FLSM(Fixed-Length Subnet Mask) 같은 서브넷 마스크로 서브넷팅 하는 것 FLSM EX - 192.168.32.0/24를 25개의 호스트가 있는 네트워크로 서브넷팅 → 네트워크수의 기준인 경우 왼쪽부터 세고 호스트수의 기준인 경우 오른쪽부터 셈 → 25개의 호스트가 필요하므로 2의 배수 중 25를 수용할 수 있는 가장 작은 수는 32임. (∵2의 배수이어야 함) 32는 2^5이므로 오른쪽부터 5개의 bit는 Host-ID로 사용하며 나머지 3개의 Bit는 Net-ID로 사용함 VLSM(Variable Length Subnet Mask) VLSM(Variable Length Subnet Mask) 서로 다른 서브넷 마스크로 서브넷팅 하는 것 서브넷팅 시 호스트가 가장 많은 것(서브넷이 작은) 부터 진행해야 함 VLSM EX - 회사가 201.102.1.0/24 (Class C) 네트워크를 사용함 -
[Basics] Control Plane / Data Plane / Management Plane [내부링크]
Router Plane 구조 모든 네트워크 장비는 세 가지 영역으로 구분 - Data Plane - Control Plane - Management Plane Router Plane 구조 Control Plane Control Plane Data Plane에 의해 수행되는 Packet Forwarding에 직접적으로 관여하지 않음 CPU를 이용해 처리하는 영역으로 L2 스위치에서는 메모리 영역에 MAC Table이 위치 Data Plane이 가지고있는 Forwarding Table에 정보를 기록하는 담당 → 라우터의 경우 Control Plane에서 라우팅 프로토콜이 동작하여 Data Plane의 Forwarding Table에 정보를 기록함 라우팅 프로토콜이 동작하는 단계 데이터 영역의 하드웨어를 통해 빨리 처리되지만 CPU 기반의 패킷 포워딩은 성능 저하의 원인이 될 수 있음 Label 교환도 Control Plane Data Plane Data Plane Cont
[Basics] Circuit Switching / Packet Switching [내부링크]
Circuit Switching 네트워크에서 End-to-End 통신 방식은 2가지가 있음 - Circuit Switching - Packet Switching Circuit Switching 데이터를 나눠 전송하지 않고 회선을 할당 받음 회선 전체를 독점함 회선을 점유하기 때문에 속도와 성능이 일정하며 Loss와 Delay가 거의 없음 회선을 분할하는 방식인 FDM(Frequency Division Multiplexing)과 TDM(Time Division Multiplexing)이 있음 FDM (Frequency Division Multiplexing) - 주파수를 나눠서 공유하는 방식 (시간은 고정) - 대역의 일부를 공유 - 여러 신호들이 하나의 링크 대역폭을 나눠서 사용 → 대역폭을 여러 개의 작은 채널로 분할하여 여러 회선들이 동시에 이용하는 방식 - 채널 간 간섭을 막기 위해 보호대역이 필요하며 보호대역으로 인하여 채널의 이용률을 낮춤 TDM (Time Di
[Basics] L2 스위칭 (Store and Forward / Cut-Through / Fragment-Free) [내부링크]
Store and Forward Store and Forward 수신된 프레임 전체를 저장해 처리하는 방식 (Ethernet Frame Size : 64~1518byte) 장점 : S-Mac학습, MAC Table 비교 가능, 에러 발생 구분 가능 단점 : 데이터 처리 속도가 너무 느림 Fragment-Free Fragment-Free Cache에 64byte만 저장 후 체크. (64byte 이하면 전송이 안 됨) 64byte면 Collition의 발생 여부를 확인할 수 있음 → 에러 발생 구분 가능 장점 : S-Mac학습, MAC Table 비교 가능, 에러 발생 구분 가능 Cut-Through Cut-Through 스위치가 D-MAC를 확인한 후 즉시 전달하는 방법 단점 : S-MAC 학습 X, MAC 테이블 생성 X 프레임에 따라 지연이 발생하지 않지만 에러가 있거나 쓸모없는 트래픽을 포워딩할 수 있음 Cut-Through & Fragment-Free Cut-T
[Basics] L3 스위칭(Process Switching / Fast Switching / CEF) [내부링크]
Process Switching Process Switching 모든 패킷은 CPU에 의해 확인되고 소프트웨어에 의해 전송경로가 결정됨 최초의 패킷이 들어오면 버퍼에 복사하고 D-IP를 라우팅 테이블에서 찾음 프레임의 목적지를 재작성하고 OIF(Outgoing Interface)로 보냄 그 후 같은 목적지의 패킷은 같은 방식으로 보내짐 패킷 별로 Load Balancing을 수행함 D-IP를 라우팅 테이블에서 찾고 D-IP를 재작성할 때 CPU에 의해 연산되어 속도가 느리고 CPU-intensive임 Fast Switching Fast Switching 첫 번째 패킷만 CPU에 의해 확인된 후(라우팅 테이블 참조) 하드웨어에 캐시 하여 나머지 패킷을 빠르게 처리 Process Switch의 단점을 보완하기 위해 cache를 추가시킴 패킷이 들어오면 캐쉬에서 매칭 되는 정보가 없으면 Process Switching처럼 처리하지만 해당 정보를 캐쉬에 저장 패킷이 들어오
[Basics] Frame-Relay 개념 및 동작 과정 [내부링크]
Frame-Relay 기초 Frame-Relay 학습 전 기본 개념 L2 Protocol - WAN · Point-to-Point : PPP, HDLC · Multipoint : X.25, Frame-Relay, ATM - LAN · Ethernet Network Type - Point-to-Point · 전용회선 · PPP, HDLC · 물리적 주소가 있지만 Link가 하나이고 장비도 하나이므로 큰 의미가 없음 - NBMA(Non Broadcast Multi Access) · X.25, Frame-Relay, ATM - BMA(Broadcast Multi Access) · Broadcast를 지원하는 Multi Access 환경 Frame-Relay 기본 개념 2계층 프로토콜 Frame-Relay는 VC(Virtual Circuit)라는 가상 회선을 통해 데이터가 이동함 - Frame-Relay는 PVC(Permanent Virtual Circuit)를 사용 서로 연결된(
[Basics] CEF Case Study - CEF 동작 과정(Cisco) [내부링크]
CEF 동작 과정 Case Study (Cisco) 작업 개요 목적 L3 스위칭(CEF)을 테스트 하여 CEF를 정확히 이해한다. 일자 2022.08.09(화) 테스트 내용 1. CEF 동작 과정 Case Study - 구성도 2. OSPF 설정 3. CEF Table 확인 4. Adjacency Table 확인 5. ARP Clear 이슈 테스트 계측기 - 장비 / OS L3 Cisco c3725-adventerprisek9-mz.124-15.t14 / IOS 결과 - CEF Table은 Routing Table의 복사본(캐쉬)임 - CEF Table에는 네트워크, Next-Hop IP와 OIF에 대한 정보가 있음 - Adjacency Table에 정보가 있으려면 CEF Table에 해당 대역의 Next-Hop에 대한 정보가 있어야 함 - Adjacency Table에는 Next-Hop IP와 L2 헤더(D-MAC, S-MAC)에 대한 정보가 있음 - ARP Table에 있는 정보
[Windows 11] Windows 텍스트 커서 표시기/두께 설정하는 방법 [내부링크]
문서작업 등 텍스트를 사용하는 경우 "텍스트 커서"가 작아 현재 현재 "텍스트 커서"가 어디 있는지 찾기 힘들 때가 있다. 컴퓨터로 문서작업 등 텍스트를 쓰는 사용자라면 위와 같은 불편함을 느낀 적이 있을 것이다. 이번 글에는 "텍스트 커서"의 위치를 찾기 쉽게 하기 위하여 "텍스트 커서 표시기"와 "텍스트 커서 두께"를 설정하는 방법을 공유하려고 한다. Windows 텍스트 커서 표시기 설정하는 방법 1. "텍스트 커서" 열기 - "Windows + I"를 누르면 설정 창이 열린다. - "접근성" 선택 → "텍스트 커서" 선택 2. "텍스트 커서 표시기" 활성화 - 위 사진과 같이 "텍스트 커서 표시기"를 활성화시켜준다. - "텍스트 커서 표시기"를 활성화시키지 않으면 "텍스트 커서 표시기 크기"와 "텍스트 커서 표시기 색"을 설정해도 보이지 않는다. 3. "텍스트 커서 표시기" 크기 설정 - "텍스트 커서 표시기 크기"의 값이 클수록 "텍스트 커서 표시기"가 커진다. - "텍스트
[Windows 11] Windows 파일 확장자 보는 방법 [내부링크]
일반적으로 파일마다 확장자가 정해져 있다. doc, docx, hwp, pdf, ppt, psd, txt, xls, xlsx, bmp, gif, jpeg, jpg, png, mp3, wma, wav, mov, mp4, mpg, mkv, avi, doc , txt, hwp, exe, ppt, pptx, zip 등의 확장자가 있다. 컴퓨터를 사용하다 보면 문서의 확장자를 확인해야 할 때가 있기 때문에 항상 문서의 확장자를 볼 수 있게 설정하는 것을 추천한다. 이 글에는 문서의 확장자를 항상 확인할 수 있도록 확장자를 보이게 설정하는 두 가지 방법을 공유하려고 한다. Windows 파일 확장자 보는 방법 ① 1. 확장자 표시가 없는 파일 - 위 사진은 확장자 표시가 없는 파일을 예시로 보여준다. 2. 파일 확장자 보는 방법 - "보기" 선택 → "표시" 선택 → "파일 확장명" 선택 - 다른 사이트 들은 여러 가지의 방법을 설명하고 있지만 위 방법이 가장 간단하고 빠르게 설정이 가능한 방
[Windows 11] Windows 숨겨진 폴더/파일 보는 방법 [내부링크]
시스템에서 사용하는 중요한 파일이나 폴더들을 수정하거나 삭제하면 심각한 문제가 발생할 수 있기 때문에 컴퓨터 사용자가 쉽게 수정 및 삭제를 하지 못하도록 기본적으로 숨김 처리가 되어 있다. 컴퓨터를 사용하다 보면 시스템에서 중요한 파일을 수정해야 할 때가 있는데 수정해야 할 파일이 숨김 처리가 되어 있어 수정이 어려울 때가 있다. 이 글에는 숨겨진 폴더나 파일을 볼 수 있게 설정하는 두 가지 방법을 공유하려고 한다. Windows 숨겨진 폴더/파일 보는 방법 ① 1. 숨겨진 폴더/파일 보는 방법 - "보기" 선택 → "표시" 선택 → "숨긴 항목" 선택 - 다른 사이트 들은 여러 가지의 방법을 설명하고 있지만 위 방법이 가장 간단하고 빠르게 설정이 가능한 방법이다. - 필자도 항상 위와 같은 방법으로 "숨긴 항목"을 보이게 설정한다. 2. 숨겨진 폴더/파일 확인 "숨긴 항목" 설정 전 "숨긴 항목" 설정 후 - "숨긴 항목"을 활성화하여 위 사진과 같이 숨긴 폴더를 확인할 수 있다.
[Windows 11] Windows 폴더/파일 숨기는 방법(100% 완벽하게 숨기기) [내부링크]
개인 컴퓨터가 아니거나 개인 컴퓨터를 여러 명이 사용할 때 중요한 폴더나 파일이 다른 사용자에게 보이는 것은 보안상 좋지 않다. 원하는 폴더나 파일을 숨김 처리를 하면 일반적으로 숨긴 폴더나 파일을 쉽게 확인할 수 없다. 이 글에는 폴더나 파일을 숨길 수 있는 두 가지 방법을 공유하려고 한다. Windows 폴더/파일 숨기는 방법 ① 1. "속성" 창에서 폴더/파일 숨기기 설정 - 폴더나 파일 중 숨기고 싶은 것들을 선택한다. - 폴더나 파일 중 숨기고 싶은 것들을 선택하고 우클릭한 후, "속성"을 눌러 "속성" 창을 연다 - "숨김"을 활성화한 뒤, "적용"을 클릭한다. - "적용"을 클릭하지 않을 경우 "숨김" 설정이 적용되지 않는다. - "선택한 항목에만 변경 사항 적용" · 위에서 선택한 폴더와 파일만 숨김 처리를 적용하는 것이다. - "선택한 항목, 하위 폴더 및 파일에 변경 사항 적용" · 위에서 선택한 폴더와 파일뿐만 아니라 폴더 안에 있는 '하위 폴더' 나 '파일'도
[Windows 11] Windows 가상 메모리 설정하는 방법 [내부링크]
위도우 운영 시스템에서 사용하는 가상 메모리란 HDD, SSD와 같은 보조 기억 장치의 일부를 RAM과 같은 주 기억 장치처럼 사용하는 기술을 말한다. HDD, SSD(보조 기억 장치)가 부족한 RAM(주 기억 장치)을 보조하기 위한 기술이라고 생각하면 이해하기 쉬울 거 같다. 가상 메모리는 실제 메모리의 용량이 충분한 상태이면 거의 사용되지 않는다. <가상 메모리의 장점> · 실제 RAM의 용량이 작은 컴퓨터에서 가상 메모리를 설정하여 HDD, SSD의 일부가 RAM의 역할을 하여 RAM이 부족하더라도 프로그램을 동작시킬 수 있다. <가상 메모리 단점> · HDD, SSD의 일부가 RAM의 역할을 해주는 것이므로 HDD, SSD가 동작하는 것이다. (즉, 실제 RAM을 사용하는 것보다 속도가 느려진다.) · HDD, SSD와 같은 보조 기억 장치의 수명이 짧아진다는 말이 있다. · 가상 메모리 용량을 너무 많이 설정할 경우 "페이징 현상"이 발생하여 오히려 컴퓨터가 느려질 수 있다
[Windows 11] Windows 마우스 스크롤(휠) 속도 조절하는 방법 [내부링크]
컴퓨터에서 웹이나 프로그램을 이용할 때 스크롤(휠) 속도를 조절하고 싶을 때가 있다. Windows에서 스크롤(휠) 속도를 조절할 수 있는 방법을 공유하려고 한다. Windows 마우스 스크롤(휠) 속도 조절하는 방법 1. "마우스" 열기 - "Windows + I"를 누르면 설정 창이 열린다. - "Bluetooth 및 장치" 선택 → "마우스" 선택 2. "한 번에 스크롤할 줄" 설정 변경 - "한 번에 스크롤할 줄" 부분의 값을 높이면 스크롤(휠) 속도가 빨라진다. - "한 번에 스크롤할 줄" 부분의 값을 줄이면 스크롤(휠) 속도가 느려진다. - 스크롤(휠)을 한 칸 움직일 때마다 변동되는 "줄"을 설정하는 것이다. 3. "마우스 휠을 돌려서 스크롤" 설정 변경 - 스크롤(휠)을 한 칸 움직일 때마다 "줄"단위로 변동되는 것이 너무 느리다고 느껴지면 스크롤(휠)을 한 칸 움직일 때마다 한 화면씩 변동되게 설정할 수 있다.
[Windows 11] Windows 비활성 창 위에 커서를 올릴 때 스크롤 비활성화하는 방법 [내부링크]
컴퓨터에서 메인으로 사용 중인 창 이외에 비활성 창 위에 커서를 올리고 스크롤을 움직일 때 "스크롤 활성화"가 되어 있으면 비활성 창이 움직인다. 이와 같은 현상이 불편한 사람이 많다. 비활성 창 위에 커서를 올리고 스크롤을 움직일 때 비활성 창이 고정되게 하는 방법을 공유하려고 한다. Windows 비활성 창 위에 커서를 올릴 때 스크롤 비활성화하는 방법 1. "마우스" 열기 - "Windows + I"를 누르면 설정 창이 열린다. - "Bluetooth 및 장치" 선택 → "마우스" 선택 2. "비활성 창 위에 커서를 올릴 때 스크롤" 설정 변경 - "비활성 창 위에 커서를 올릴 때 스크롤" 부분을 비활성화시킨다. - 만약 비활성 창 위에 커서를 올릴 때 스크롤을 움직이려면 해당 항목을 활성화 시킨다.
[Windows 11] Windows 노트북 웹캠 차단하는 방법 [내부링크]
보통 노트북에는 기본적으로 웹캠이 장착되어 있다. 바이러스 감염이나 실수로 카메라 권한을 부여하여 보안 문제가 발생할 수 있다. 이러한 보안 문제를 방지하기 위해 웹캠을 차단하는 방법을 공유하려고 한다. Windows 노트북 웹캠 차단하는 방법 1. "카메라 액세스" 차단 - "Windows + I"를 누르면 설정 창이 열린다. - "개인 정보 및 보안" 선택 → "카메라 액세스" 끔 - "카메라 액세스"를 끄면 모든 프로그램에 대하여 카메라 권한을 부여하지 않아 카메라가 정상 작동을 하지 않는다. 2. "카메라 액세스" 차단 시 카메라 어플 실행 - "카메라 액세스"를 끄고 카메라 어플을 실행해 보면 설정을 변경하라고 창이 뜬다. 3. 카메라 물리적 보안 - 위 방법은 소프트웨어 방법으로 카메라를 차단한 것이다. - 소프트웨어는 원격으로도 설정을 변경할 수 있기 때문에 최선의 보안은 물리적으로 차단하는 것이다. - 많은 방법으로 테스트를 진행한 결과 "여드름 패치"를 웹캠에 붙이는
[Windows 11] Windows 마지막 글자 사라짐 해결 방법 [내부링크]
최근 Windows 11을 사용하는 사람들이 많아지고 있다고 느껴진다. Windows 11을 사용하면서 불편한 점이 몇 가지가 있다. 불편한 것 중 하나가 텍스트를 치고 다른 곳을 누르거나 다른 프로그램을 잠깐 보고 오면 마지막 글자가 사라져 있다는 것이다. 마지막 텍스트 하나가 사라진다는 것이 큰 문제가 아니라고 느껴질 수도 있겠지만 문서 작업과 같은 업무를 진행할 때 텍스트 하나가 사라진다는 것이 큰 문제점으로 느껴졌다. 그래서 이번 글은 Windows 11에서 텍스트의 마지막 글자가 사라지는 현상을 방지하는 방법을 공유하려고 한다. Windows 마지막 글자 사라짐 해결 방법 1. "언어 및 지역" 열기 - "Windows + I"를 누르면 설정 창이 열린다. - "시간 및 언어" 선택 → "언어 및 지역" 선택 2. "더 많은 마우스 설정" 선택 - "한국어"부분에 있는 "..."을 누른다. 3. "<Ctrl> 키를 누르면 포인터 위치 표시" 선택 - "한국어"부분에 있는 "
[Windows 11] Windows 마우스 포인터 색상/크기/모양 변경하는 방법 [내부링크]
보통 컴퓨터를 사용하면서 마우스가 작아 현재 마우스 포인터가 어디에 있는지 찾는 게 힘들었던 분들이 많을 것으로 생각된다. 그래서 이번 글에는 마우스 커서를 보다 쉽게 찾기 위해 마우스의 포인터 색상, 크기, 모양을 변경하는 방법을 공유하려고 한다. Windows 마우스 포인터 색상 변경하는 방법 1. "마우스 포인터 및 터치" 열기 - "Windows + I"를 누르면 설정 창이 열린다. - "접근성" 선택 → "마우스 포인터 및 터치" 선택 2. 마우스 색상 변경(흰색/검은색) - 위 사진과 같이 기본적으로 마우스 포인터 생상을 흰색, 검은색, 흰검으로 변경할 수 있다. 3. 마우스 색상 변경(사용자 지정 색) - 마우스 포인터 색상이 흰색, 검은색이 아닌 다른 색으로 설정하고 싶으면 위 사진처럼 "마우스 포인터 스타일" 중 맨 오른쪽에 있는 포인터를 선택한다. - 마우스 포인터 색상을 사용자가 원하는 색상으로 변경할 수 있다. - 마우스 포인터 색상을 변경하여 마우스 포인터의
Packet Tracer 설치 가이드 [내부링크]
Packet Tracer 설치 가이드 https://www.netacad.com/courses/packet-tracer 1. 위 URL을 통해 Cisco 홈페이지 접속 2. "View course" 클릭 3. "Sign up today!" 클릭 4. 회원가입 5. "Create Account" 클릭 6. 이메일 확인 후 해당 링크로 접속 7. "Resources" - "Packet Tracer Download" 클릭 8. 본인 PC에 맞는 버전 다운로드 9. Packet Tracer 설치 10. 로그인 후 사용 가능 Packet Tracer 단점 Packet Tracer는 많은 기능을 지원하지 않음 많은 기능을 사용하려면 GNS3 or EVE-NG를 사용하는 것을 추천함
Packet Tracer 사용 가이드 [내부링크]
Packet Tracer 사용 가이드 1. Packet Tracer 실행 2. 라우터 장비 종류 확인 3. 스위치 장비 종류 확인 4. PC or Server 등 장비 종류 확인 5. 링크 종류 확인 6. Drag&Drop으로 장비 설치 7. 번개 모양(링크)를 이용하여 토폴로지 생성 - 번개 모양을 누르고 연결하고 싶은 장비를 클릭하면 링크(케이블)가 연결된다. - 번개 모양을 "Ctrl + 좌클릭"하면 링크를 끊김 없이 연결할 수 있다. - Delete 키를 이용하여 장비를 제거할 수 있다. 장비 하드웨어 설정 1. 전원 On/Off 확인 및 On 상태로 전환 - L2 Switch에는 전원 스위치가 없지만 L3 Router에는 전원 스위치가 있어 클릭하면 장비가 On/Off 된다. 2. 장비 인터페이스 증설 - 왼쪽에 나열된 것들이 인터페이스다. - 원하는 인터페이스를 장비 슬롯에 Drag&Drop 하면 인터페이스 증설이 된다. (단, 장비 전원이 Off 된 상태만 된다.) -
[GNS3] 설치 가이드 [내부링크]
GNS3 설치 가이드 https://www.gns3.com/software/download 1. 위 URL을 통해 GNS3 홈페이지 접속 & 다운로드 2. 로그인 (회원가입) 3. "Next" 클릭 4. "I Agree" 클릭 5. "Next" 클릭 6. "Next" 클릭 7. "Next" 클릭 8. "Next" 클릭 9. "I Agree" 클릭 10. "Install" 클릭 11. "Finish" 클릭 12. "I Agree" 클릭 13. "Install" 클릭 14. "Next" 클릭 15. "Finish" 클릭 16. "Next" 클릭 17. "No" 클릭 18. "Finish" 클릭 19. GNS3 실행
[GNS3] 기본 설정 & 사용 가이드 [내부링크]
GNS 기본 설정 & 사용 가이드 1. "Setup Wizard" 설정 Run appliances in a virtual machine - VM을 이용하여 IOS, IOU, ASA, 타 Vender의 Appliance를 동작시킨다. (단, GNS3 VM을 설치해야 한다.) Run appliances on my local computer - VM이 아닌 Local 컴퓨터 내부에서 Appliance를 동작시킨다. Run appliances on a remote server (advanced usage) - VM이 아닌 Remote 서버에서 Appliance 2. "Next" 클릭 (Default로 설정) 3. "Next" 클릭 (단, 내용에 "Successfu"가 있어야 된다.) 4. GNS3 VM을 인식하지 못한다. (추가적으로 GNS3 VM을 설치를 해야 한다. / 미리 설치되어 있으면 자동으로 인식한다.) 아래 "VMware"를 선택한 후 "downloaded here"를 누
[GNS3] IOS 설치 가이드 [내부링크]
GNS3 IOS 설치 가이드 1. Edit → Preferences → New 클릭 Run this IOS router on the GNS3 VM - IOS Router를 GNS3 VM에서 동작 Run this IOS router on my local computer - IOS Router를 Local PC에서 동작 2. IOS 이미지 등록 3. "Next" 클릭 4. "Next" 클릭 5. 인터페이스를 증설하는 부분이다. 원하는 Slot에 원하는 카드를 증설하면 된다. 6. 하나의 토폴로지(Project)에서 장비를 로딩할 때 리소스를 최소한으로 사용하게 도와주는 작업이다. "Idle-PC finder" 클릭하여 Idle-PC 값을 찾는다. 7. Idle-PC finder를 실패할 경우 토폴로지에서 진행할 수 있다. (이 단계에서 Idle-PC가 안 되는 몇몇 IOS 버전이 있다.) 8. Apply → OK 클릭 9. Project 생성 후, 토폴로지를 생성한다. (장비는 Dr
[GNS3] IOU 설치 가이드 [내부링크]
GNS3 IOU 설치 가이드 1. GNS3를 실행시키고 Project를 생성한다. 기존 Project를 사용해도 상관없다. 2. IOU를 추가하면 GNS3 VM에 IOU파일을 복사한다. 3. "Finish" 클릭 GNS3 VM에 IOU 파일 복사 완료 4. IOU 장비 등록 확인 "Apply" -> "OK" 클릭 5. L3 Router를 사용하기 위해 L3 이미지를 추가한다. 6. "Edit"를 누르면 RAM, Network Adapter 등 해당 장비에 대한 정보를 수정할 수 있다. 7. IOU를 사용하려면 License가 필요하다. (IOS는 별도 License가 필요 없다.) IOU 라이선스 파일("IOURC.txt")을 업로드해준다. "Apply" -> "OK" 클릭 8. 아래와 같은 Error가 발생하는 경우가 종종 있다. 9. GNS3 VM에서 "Upgrade"로 들어간다. (GNS3 Version과 같은 Version으로 Upgrade를 진행해야 한다.) (Upgrade
[GNS3] Console & Wireshark 연동 [내부링크]
GNS3 Console 연동 1. "Edit"로 들어가 원하는 Console 프로그램을 선택하면 연동이 된다. GNS3 Wireshark 연동 1. 아래와 같이 "Packet capture"항목을 수정한다. 2. Wireshark 실행 케이블을 우클릭한 후 "Start Capture"을 누르면 Wireshark가 실행된다. 3. Wireshark 동작 모습
[EVE-NG] 설치 가이드 [내부링크]
EVE-NG 설치 가이드 1. 아래 URL로 접속하여 EVE-NG Community를 Download 받는다. https://www.eve-ng.net/index.php/download/#DL-COMM 2. EVE-NG Community를 Download 받을 때 ISO가 아닌 OVF를 선택한다. 3. 압축 해제 4. OVF VMware에 업로드한다. 5. OVF Hardware를 설정 Memory와 Processors는 본인 PC 사양에 맞게 설정해 주면 된다. 6. NAT Adapter IP 수정 (EVE-NG 웹사이트에 접속할 IP이다.) 7. EVE-NG 실행 (Default 계정 : root / eve) 8. Root Password 지정 9. hostname 지정 10. DNS Domain 지정 11. IP 할당 방식 지정 (Static 추천) 12. EVE-NG IP, Subnet Mask, Gateway 지정 (Nat에서 지정한 IP와 같은 대역으로 지정한다.) 13.
[EVE-NG] Cisco IOL 등록 [내부링크]
EVE-NG Cisco IOL 등록 -참고한 사이트- https://www.eve-ng.net/index.php/documentation/howtos/howto-add-cisco-iol-ios-on-linux/ 1. 이미지 등록 전 Node 비활성화 상태를 확인한다. "Cisco IOL"이 비활성화 되어 있음 2. EVE-NG로 접속한다. (VMware에 설치된 EVE-NG로 접속해도 무방하다.) 3. IOL 이미지 업로드할 위치 확인한다. 4. 이미지를 업로드하기 위하여 FTP 프로그램을 이용하여 EVE-NG로 접속한다. (WinSCP, Filezilla 등으로 접속하면 된다.) 5. Cisco IOL 이미지를 업로드한다. ("/opt/unetlab/addons/iol/bin/"으로 업로드한다.) 이미지는 구글링 하면 바로 찾을 수 있다. 6. Cisco IOL 이미지가 정상적으로 업로드된 것을 확인한다. 7. 사용권한을 수정한다. /opt/unetlab/wrappers/unl_w
[EVE-NG] Cisco IOS [Dynamips] 등록 [내부링크]
EVE-NG Cisco IOS[Dynamips] 등록 -참고한 사이트- https://www.eve-ng.net/index.php/documentation/howtos/howto-add-cisco-dynamips-images-cisco-ios/ 1. 이미지 등록 전 Node 비활성화 상태를 확인한다. 2. EVE-NG로 접속한다. (VMware에 설치된 EVE-NG로 접속해도 무방하다.) 3. IOS 이미지 업로드할 위치 확인한다. 4. 이미지를 업로드하기 위하여 FTP 프로그램을 이용하여 EVE-NG로 접속한다. (WinSCP, Filezilla 등으로 접속하면 된다.) 5. Cisco IOS 이미지를 업로드한다. ("/opt/unetlab/addons/dynamips/"으로 업로드한다.) 이미지는 구글링 하면 바로 찾을 수 있다. 6. Cisco IOS 이미지가 정상적으로 업로드된 것을 확인한다. 7. 압축해제를 진행한다. ("unzip -p ---" 명령어로 진행한다.) 8.
[EVE-NG] vIOS L3 Router 등록 [내부링크]
EVE-NG vIOS L3 등록 -참고한 사이트- https://www.eve-ng.net/index.php/documentation/howtos/howto-add-cisco-vios-from-virl/ 1. 이미지 등록 전 Node 비활성화 상태를 확인한다. 2. EVE-NG로 접속한다. (VMware에 설치된 EVE-NG로 접속해도 무방하다.) 3. vIOS 이미지 업로드할 위치에 폴더를 생성한다. vios-adventerprisek9-m.SPA.156-1.T vios-adventerprisek9-m.SPA.156-2.T 4. 이미지를 업로드하기 위하여 FTP 프로그램을 이용하여 EVE-NG로 접속한다. (WinSCP, Filezilla 등으로 접속하면 된다.) 5. Cisco vIOS 이미지를 업로드한다. ("/opt/unetlab/addons/qemu/[폴더]"으로 업로드한다.) 이미지는 구글링 하면 바로 찾을 수 있다. vios-adventerprisek9-m.SPA.156
[EVE-NG] vIOS L2 Switch 등록 [내부링크]
EVE-NG vIOS L2 Switch 등록 -참고한 사이트- https://www.eve-ng.net/index.php/documentation/howtos/howto-add-cisco-vios-from-virl/ 1. 이미지 등록 전 Node 비활성화 상태를 확인한다. 2. EVE-NG로 접속한다. (VMware에 설치된 EVE-NG로 접속해도 무방하다.) 3. vIOS 이미지 업로드할 위치에 폴더를 생성한다. 4. 이미지를 업로드하기 위하여 FTP 프로그램을 이용하여 EVE-NG로 접속한다. (WinSCP, Filezilla 등으로 접속하면 된다.) 5. Cisco vIOS 이미지를 업로드한다. ("/opt/unetlab/addons/qemu/[폴더]"으로 업로드한다.) 이미지는 구글링 하면 바로 찾을 수 있다. 6. Cisco vIOS 이미지가 정상적으로 업로드된 것을 확인한다. 7. Image 파일 이름 및 확장자 변경 8. 권한 수정 9. vIOS Switch Node 추
[EVE-NG] ExtremeXOS 등록 [내부링크]
EVE-NG ExtremeXOS 등록 -참고한 사이트- https://www.eve-ng.net/index.php/documentation/howtos/howto-add-extreme-exos/ 1. 이미지 등록 전 Node 비활성화 상태를 확인한다. 2. EVE-NG로 접속한다. (VMware에 설치된 EVE-NG로 접속해도 무방하다.) 3. vIOS 이미지 업로드할 위치에 폴더를 생성한다. mkdir /opt/unetlab/addons/qemu/extremexos-22.4.1.4 mkdir /opt/unetlab/addons/qemu/extremexos-30.2.1.8 4. 이미지를 업로드하기 위하여 FTP 프로그램을 이용하여 EVE-NG로 접속한다. (WinSCP, Filezilla 등으로 접속하면 된다.) 5. ExtremeXOS Image를 업로드한다. ("/opt/unetlab/addons/qemu/[폴더]"으로 업로드한다.) 이미지는 구글링 하면 찾을 수 있다. 6. E
[EVE-NG] Nokia 7750 SR 12.0.R6 등록 [내부링크]
EVE-NG Nokia 7750 SR 12.0.R6 등록 -참고한 사이트- https://www.eve-ng.net/index.php/documentation/howtos/howto-add-alcatel-7750-sr/ 1. 이미지 등록 전 Node 비활성화 상태를 확인한다. 2. EVE-NG로 접속한다. (VMware에 설치된 EVE-NG로 접속해도 무방하다.) 3. 패키지 Update & Upgrade apt-get update 운영체제에서 사용 가능한 패키지들과 그 버전에 대한 정보를 업데이트하는 명령어다. 설치되어 있는 패키지를 최신으로 업데이트하는 것이 아닌 설치 가능한 리스트를 업데이트하는 것이다. apt-get upgrade 운영체제에 apt-get install 명령으로 설치한 패키지들을 최신 버전으로 업그레이드하는 명령어다. apt-get upgrade 명령을 이용하면 apt-get update로 가져온 각 패키지들의 최신 버전에 맞게 업그레이드를 한다. 위와 같이
[EVE-NG] Nokia 7750 SR 13.0.R3 등록 [내부링크]
EVE-NG Nokia 7750 SR 13.0.R3 등록 -참고한 사이트- https://www.eve-ng.net/index.php/documentation/howtos/howto-add-alcatel-7750-sr/ 1. 패키지 Update & Upgrade apt-get update 운영체제에서 사용 가능한 패키지들과 그 버전에 대한 정보를 업데이트하는 명령어다. 설치되어 있는 패키지를 최신으로 업데이트하는 것이 아닌 설치 가능한 리스트를 업데이트하는 것이다. apt-get upgrade 운영체제에 apt-get install 명령으로 설치한 패키지들을 최신 버전으로 업그레이드하는 명령어다. apt-get upgrade 명령을 이용하면 apt-get update로 가져온 각 패키지들의 최신 버전에 맞게 업그레이드를 한다. 위와 같이 Error 발생한다면 DNS 설정과 통신 확인 필요 DNS IP와 통신이 된다면 Error 없이 진행된다. 2. 디렉토리 생성 및 Image 업로드
[EVE-NG] Nokia 7750 SR 20.10.R1 등록 [내부링크]
EVE-NG Nokia 7750 SR 20.10.R1 등록 -참고한 사이트- https://www.eve-ng.net/index.php/documentation/howtos/howto-add-nokia-vsr/ 1. 패키지 Update & Upgrade apt-get update 운영체제에서 사용 가능한 패키지들과 그 버전에 대한 정보를 업데이트하는 명령어다. 설치되어 있는 패키지를 최신으로 업데이트하는 것이 아닌 설치 가능한 리스트를 업데이트하는 것이다. apt-get upgrade 운영체제에 apt-get install 명령으로 설치한 패키지들을 최신 버전으로 업그레이드하는 명령어다. apt-get upgrade 명령을 이용하면 apt-get update로 가져온 각 패키지들의 최신 버전에 맞게 업그레이드를 한다. 위와 같이 Error 발생한다면 DNS 설정과 통신 확인 필요 2. 임시 디렉토리 생성 cd mkdir tmp 3. 이미지 업로드 및 압축 해제 cd tmp unzip
[EVE-NG] SecureCRT Tabs 설정 [내부링크]
SecureCRT Tabs 설정 "Windows Client Side" Download https://www.eve-ng.net/index.php/download/#DL-WIN 1. 위 링크로 접속하여 "Windows Client Side"파일을 다운받는다. 2. EVE-NG파일을 "Program Files"파일 안으로 이동시킨다. Register 수정 1. "win10_64bit_sCRT"파일 수정 2. 아래 캡처 자료의 경로와 SecureCRT의 실제 경로가 같아야 함 3. 레지스트리 편집기에서 "컴퓨터\HKEY_CLASSES_ROOT\telnet\shell\open\command"경로에 있는 파일을 아래와 같이 수정(같을 경우 수정할 필요 없음) "Global.ini" 파일 편집 1. "Options" → "Global Options" 2. 해당 경로에 있는 "Global.ini" 파일을 수정해야 함 3. 경로 사이에 숨겨진 폴더가 있음 4. D:"Single Instance"
[EVE-NG] Wireshark 연동 [내부링크]
Wireshark 연동 "Windows Client Side" Download https://www.eve-ng.net/index.php/download/#DL-WIN <아래 설정들은 모두 EVE-NG Client에서 설정하는 내용> 1. 위 링크로 접속하여 "Windows Client Side"파일을 다운받는다. 2. EVE-NG파일을 "Program Files"파일 안으로 이동시킨다. Wireshark 파일 수정 1. "wireshark_wrapper" 파일 수정 2. EVE-NG 계정으로 변경 <EVE-NG 서버 계정으로 설정해야 됨> 3. "plink"경로 확인 4. Wireshark 경로 확인 Wireshark 파일 보안 설정 1. "wireshark_wrapper" 파일 속성 2. "wireshark_wrapper" 파일 보안 설정 Plink 파일 보안 설정 1. "plink" 파일 속성 2. "plink" 파일 보안 설정 Putty 파일 실행 0. Putty 실행 전 E
[GNS3] SecureCRT 연동 [내부링크]
GNS3 SecureCRT 연동 1. "Edit" 선택 → "Preferences" 선택 2. "General" 선택 → "Console application" 선택 → "Edit" 선택 3. "SecureCRT" 선택 4. "SecureCRT.exe" 파일이 있는 경로를 수정 - 경로 수정 후 반드시 적용해야 함 5. SecureCRT 실행 확인 - 장비 우클릭 → "console" 클릭 → SecureCRT 프로그램 실행 확인
[GNS3] Setup Wizard [내부링크]
GNS3 Setup Wizard 1. "Help" 선택 → "Setup Wizard" 선택 2. 장비를 작동시킬 방법 선택 1. "Run appliances in a virtual machine" - GNS3 VM을 이용하여 IOSv, IOU, ASA 등 다른 Vender의 장비를 작동시킴 2. "Run appliances on my local computer" - GNS3VM이나 다른 서버를 이용하지 않고 로컬 컴퓨터 내부에서 장비를 작동시킴 3. "Run appliances on a remote server(advanced usage)" - 로컬 GNS3VM, 로컬 컴퓨터가 아닌 외부 서버의 GNS3VM이나 컴퓨터로 장비를 작동시킴
[GNS3] Nokia 7750 SR 12.0.R6 등록 [내부링크]
GNS3 Nokia 7750 SR 12.0.R6 등록 1. "Help" 선택 → "Setup Wizard" 선택 2. 로컬 컴퓨터로 장비 부팅 - GNS3에서 GNS3VM인 가상 서버를 이용하여 7750 SR 12.0.R6 OS를 올리는 방법이 있음 - GNS3에서 GNS3VM인 가상 서버를 이용하여 7750 SR 12.0.R6 OS를 올리면 부팅이 잘 안 되는 이슈가 있음 - GNS3에서 7750 SR 12.0.R6는 로컬 컴퓨터를 이용하여 장비를 부팅시킬 수 있음 - 반드시 "successful"이 나와야 함 3. 7750 SR 12.0.R6 OS 등록 - "Edit" 선택 → "Preferences" 선택 - "Qemu VMs" 선택 → "New" 선택 - 등록할 장비 NAME 기재 - "Browse" 선택 → 등록할 7750 SR 12.0.R6 OS 선택 → "Finish" 선택 4. 7750 SR 12.0.R6 OS 정보 수정 - "Qemu VMs" 선택 → "Edit" 선
[Windows 11] Windows 해상도 변경하는 방법 [내부링크]
보통 노트북의 기본 해상도는 "1920x1080"(FHD)로 설정되어 있다. 사용자들이 사용하는 프로그램이나 특성에 따라 사용하려는 해상도가 다를 수 있다. Windows 해상도를 변경하는 방법을 공유하려고 한다. Windows 해상도 변경하는 방법 1. "디스플레이" 열기 - "Windows + I"를 누르면 설정 창이 열린다. - "시스템" 선택 → "디스플레이" 선택 2. "디스플레이 해상도" 변경 - "디스플레이 해상도" 부분에서 원하는 해상도로 변경하면 된다.
[Windows 11] Windows 배율 변경하는 방법 [내부링크]
보통 노트북의 기본 배율은 "125%"로 설정되어 있다. "125%"로 설정되어 있으면 텍스트, 앱 등 기타 항목들이 상대적으로 커서 PC를 사용하기 불편하다. 필자는 보통 배율을 "100%"로 사용한다. Windows 배율을 변경하는 방법을 공유하려고 한다. Windows 배율 변경하는 방법 1. "디스플레이" 열기 - "Windows + I"를 누르면 설정 창이 열린다. - "시스템" 선택 → "디스플레이" 선택 2. "배율" 변경 - 보통 노트북의 배율은 "125%"로 설정되어 있다. - 원하는 배율을 선택한다. · 배율은 "100%"로 선택하는 것을 추천한다. - "배율"을 "100%"로 선택하면 아이콘, 텍스트, 창 크기 등이 변경된다.
[Windows 11] Windows 디스플레이 방향 변경하는 방법 [내부링크]
보통 PC의 디스플레이 방향은 가로 방향이다. 피벗이 지원되는 모니터 받침대나 모니터 암을 사용할 때 디스플레이 방향을 세로로 사용하는 게 좋을 때가 있다. Windows 디스플레이 방향 변경하는 방법 1. "디스플레이" 열기 - "Windows + I"를 누르면 설정 창이 열린다. - "시스템" 선택 → "디스플레이" 선택 2. "디스플레이 방향" 변경 - 보통 PC의 디스플레이 방향은 "가로"이다. - "가로" → "세로"로 변경하면 디스플레이 방향이 변경된다.
[Windows 11] Windows 절전 모드 시간 설정하는 방법 [내부링크]
기본적으로 Windows가 절전 모드로 넘어가는 시간이 짧아 사용하기에 불편할 때가 있다. Windows가 절전 모드로 넘어가는 시간을 변경하는 방법을 공유하려고 한다. Windows 절전 모드 시간 설정하는 방법 1. "전원 관리 옵션 설정 편집" 열기 - "Windows + S"를 눌러 Windows 검색창을 연다. - "전원 관리 옵션 설정 편집"을 검색한다. 2. 절전 모드 시간 설정 - 노트북을 전원에 연결하고 사용할 때 절전 모드로 넘어가지 않게 하기 위해 위와 같이 설정한다. - 노트북을 전원에 연결하지 않고 배터리로 사용할 때 10분 후에 화면이 꺼지고 20분 후에 절전 모드로 들어간다.
[Windows 11] Windows 마우스 좌우 버튼 변경하는 방법 [내부링크]
보통 마우스는 오른손잡이 사람에게 맞추어 설계가 되어있다. 왼손잡이가 기본 세팅 값으로 사용하기에 불편함이 있어 마우스 좌우 변경하는 것을 추천한다. Windows 마우스 좌우 버튼 변경하는 방법 1. "마우스" 열기 - "Windows + I"를 누르면 설정 창이 열린다. - "Bluetooth 및 장치" 선택 → "마우스" 선택 2. 마우스 좌우 버튼 변경 - "기본 마우스 단추" 부분에서 "왼쪽" → "오른쪽"으로 변경하여 마우스의 좌우 버튼을 변경한다. · "오른쪽"으로 설정되어 있는데 마우스 좌우 버튼을 변경하려면 "왼쪽"으로 변경한다.
[Windows 11] Windows 잠금 화면 변경하는 방법 [내부링크]
윈도우는 기본적으로 제공되는 잠금 화면이 있다. 잠금 화면을 "다른 이미지"나 "슬라이드 쇼"로 변경하는 방법을 공유하려고 한다. Windows 잠금 화면 변경하는 방법 1. "잠금 화면" 열기 - "Windows + I"를 누르면 설정 창이 열린다. - "개인 설정" 선택 → "잠금 화면" 선택 2. Windows에서 제공되는 이미지로 변경 - Windows에서 기본적으로 제공되는 이미지를 잠금 화면으로 설정하기 위한 것이다. - "잠금 화면 개인 설정" 부분에서 "Windows 추천"으로 변경하고 Windows에서 추천하는 사진을 잠금 화면으로 변경한다. 3. Windows에서 제공되는 것이 아닌 다른 이미지로 변경 - Windows에서 기본적으로 제공되는 이미지가 아닌 다른 이미지로 잠금 화면을 설정하기 위한 것이다. - "잠금 화면 개인 설정" 부분에서 "사진"으로 변경하고 "사진 선택" 부분에서 "사진 찾아보기"를 선택한 후 원하는 사진을 넣으면 된다. 4. "슬라이드 쇼"
[Windows 11] Windows 바탕화면 변경하는 방법 [내부링크]
윈도우는 기본적으로 제공되는 바탕화면이 있다. 바탕화면을 "다른 이미지"나 "슬라이드 쇼"로 변경하는 방법을 공유하려고 한다. Windows 바탕화면 변경하는 방법 1. "배경" 열기 - "Windows + I"를 누르면 설정 창이 열린다. - "개인 설정" 선택 → "배경" 선택 2. Windows에서 제공되는 이미지로 변경 - Windows에서 기본적으로 제공되는 이미지를 바탕화면으로 설정하기 위한 것이다. - "배경 개인 설정" 부분에서 "사진"으로 변경하고 Windows에서 제공되는 이미지를 선택하여 변경한다. 3. Windows에서 제공되는 것이 아닌 다른 이미지로 변경 - Windows에서 기본적으로 제공되는 이미지가 아닌 다른 이미지로 바탕화면을 설정하기 위한 것이다. - "배경 개인 설정" 부분에서 "사진"으로 변경하고 "사진 선택" 부분에서 "사진 찾아보기"를 선택한 후 원하는 사진을 넣으면 된다. 4. "단색"으로 변경 - 바탕화면을 이미지가 아닌 단색으로 설정하기
[Windows 11] Windows 네트워크 연결 없이 설치하는 방법 [내부링크]
Windows 11 초기 설정 시 네트워크 연결 없이 설정하는 것이 편할 때가 있다. 네트워크 연결 후 초기 설정 시 마이크로소프트 로그인 및 여러 추가 설정을 해야 하기 때문이다. Windows 네트워크 연결 없이 설치하는 방법 1. "Shift + F10"을 눌러 명령 프롬프트 열기 - "Shift + F10"을 눌러 명령 프롬프트 창을 연다. 2. 명령 프롬프트에서 "OOBE\BYPASSNRO"를 입력한다. - 명령 프롬프트 창에 "OOBE\BYPASSNRO"를 입력한다. - 명령 프롬프트 창에 명령어를 입력하면 자동으로 재부팅이 된다. - 윈도우가 재부팅 되고 윈도우 초기 세팅을 다시 한다. - "인터넷에 연결되어 있지 않음"이 나타났다. - "인터넷에 연결되어 있지 않음"을 눌러 인터넷 연결을 하지 않고 윈도우 초기 세팅을 진행한다. - "제한된 설치로 계속"을 눌러 인터넷 연결을 하지 않고 윈도우 초기 세팅을 진행한다.
[Windows 11] Windows 자동(DHCP) IP 재할당(갱신)하는 방법 [내부링크]
보통 PC를 자동(DHCP) IP로 사용한다. 인터넷 접속 문제나 DHCP 임대 시간 문제 등 IP를 재할당/갱신을 해야 할 상황이 있을 수 있다. Windows 자동(DHCP) IP 재할당(갱신)하는 방법 1. "명령 프롬프트" 창 열기 - "Windows + R"을 눌러 실행 창을 연다. - "cmd"를 입력 후 "확인"을 눌러 "명령 프롬프트"를 연다. 2. "ipconfig /all" 명령어를 이용하여 IP 및 DHCP 임대시간 확인 - "ipconfig /all"을 입력하면 현재 사용 중인 어댑터에 대한 모든 IP 정보들이 자세히 나열된다. - 현재 "Wi-Fi"를 이용하여 인터넷을 사용중이므로 "무선 LAN 어댑터 Wi-Fi"의 IP 정보를 확인하면 된다. - 유선을 사용하는 PC는 "이더넷"이라는 부분을 확인하면 된다. 3. 자동(DHCP) IP 재할당/갱신 - "ipconfig /release" 명령어를 사용하여 현재 사용하는 어댑터의 DHCP 구성 해제 및 IP를 제
[Windows 11] Windows 초기화하는 방법 [내부링크]
Windows 11이 설치된 PC에서는 Windows를 이용하여 운영체제를 처음 설치한 것과 동일한 상태로 초기화 시킬 수 있다. 설정, 프로그램 등 모든 것이 초기 상태로 돌아간다. Windows 초기화하는 방법 1. "Windows + I" → "시스템" → "복구" - "Windows + I"을 눌러 설정 창을 연다. - "시스템" 선택 → "복구" 선택 2. Windows PC 초기화 - "PC 초기화"를 눌러 PC를 초기화 시킨다. - "모든 항목 제거"를 눌러 모든 프로그램과 파일을 초기 상태로 초기화 시킨다. - 자동으로 재부팅이 되면서 PC를 초기화 시킨다. - 윈도우 초기 세팅을 진행한다. - 인터넷 연결을 할 경우 인터넷 연결 후 넘어가면 된다. - 인터넷에 연결하면 마이크로소프트 로그인 등 여러 설정을 더 해야 하므로 필자는 처음에 인터넷 연결을 하지 않는다. - "Shift + F10"을 누르면 명령 프롬프트 창이 켜진다. - 명령 프롬프트 창에 "OOBE\BY
[Windows 11] Windows 프로그램 제거(삭제)하는 방법 [내부링크]
PC에서 다운로드 받은 프로그램을 더 이상 사용하지 않을 때 용량, 속도 문제 등으로 인하여 제거/삭제하는 것이 좋다. Windows 프로그램 제거(삭제)하는 방법 ① - 첫 번째 방법은 "설치된 앱"에서 프로그램을 제거/삭제하는 것이다. 1. "Windows + I" → "앱" → "설치된 앱" - "Windows + I"을 눌러 설정 창을 연다. - "앱" 선택 → "설치된 앱" 선택 2. 삭제할 앱 오른쪽에 있는 "..." 클릭 → "제거" 선택 - 삭제할 앱 오른쪽에 있는 "..." 을 클릭한 후 "제거"를 선택한다. 3. "제거" 선택 - "제거"를 선택한 후 각 프로그램의 제거 프로세스를 따르면 된다. Windows 프로그램 제거(삭제)하는 방법 ② 1. 제어판 실행 - "Windows + R"을 눌러 실행 창을 연다. - "control"을 입력 후 "확인"을 누르면 제어판이 열린다. 2. "프로그램 및 기능" 열기 - "보기 기준"을 "작은 아이콘"으로 설정하면 "프로
[Windows 11] Windows 수동(Static) IP 설정하는 방법 [내부링크]
일반적으로 자동(DHCP)으로 IP를 할당받아 사용하지만 특정 상황일 때 수동(Static)으로 IP를 할당하여 사용할 때도 있다. Windows 수동(Static) IP 설정하는 방법 1. "Windows + I" → "네트워크 및 인터넷" → "고급 네트워크 설정" - "Windows + I"을 눌러 설정 창을 연다. - "네트워크 및 인터넷" 선택 → "고급 네트워크 설정" 선택 2. 사용 중인 네트워크 어댑터 선택 - 사용 중인 네트워크 어댑터를 선택한다. - 보통 "이더넷"이나 "Wi-Fi"를 많이 사용한다. 3. 네트워크 수동(Static) IP 설정 - "추가 속성 보기" 선택 - "IP 할당" 부분의 "편집" 선택 - "수동"으로 변경한 후 사용할 IP로 설정한다. - DNS는 SK, KT, LG 등 여러 개가 있다. - 설정한 IP로 적용되었는지 확인한다.
[Windows 11] Windows 자동(DHCP) IP 설정하는 방법 [내부링크]
일반적으로 PC의 IP는 공유기와 같은 장비에서 IP를 할당 받아 사용한다. Windows 수동(DHCP) IP 설정하는 방법 1. "Windows + I" → "네트워크 및 인터넷" → "고급 네트워크 설정" - "Windows + I"을 눌러 설정 창을 연다. - "네트워크 및 인터넷" 선택 → "고급 네트워크 설정" 선택 2. 사용 중인 네트워크 어댑터 선택 - 사용 중인 네트워크 어댑터를 선택한다. - 보통 "이더넷"이나 "Wi-Fi"를 많이 사용한다. 3. 네트워크 자동(DHCP) IP 설정 - "추가 속성 보기" 선택 - "IP 할당" 부분의 "편집" 선택 - "자동(DHCP)"으로 변경한 후 "저장"을 눌러 변경한다. - 자동(DHCP) IP로 적용되었는지 확인한다.
[Windows 11] Windows IP 확인하는 방법 [내부링크]
본인 PC의 IP를 확인하는 방법이다. Windows IP 확인하는 방법 1. "명령 프롬프트" 창 열기 - "Windows + R"을 눌러 실행 창을 연다. - "cmd"를 입력 후 "확인"을 눌러 "명령 프롬프트"를 연다. 2. "ipconfig" 명령어를 이용하여 IP 확인 - "ipconfig"를 입력하면 현재 사용 중인 어댑터에 대한 모든 IP 정보들이 나열된다. - 현재 "Wi-Fi"를 이용하여 인터넷을 사용 중이므로 "무선 LAN 어댑터 Wi-Fi"의 IP를 확인하면 된다. - 유선을 사용하는 PC는 "이더넷"이라는 부분을 확인하면 된다.
[Windows 11] Windows 실시간 보호 기능 켜기/끄기 [내부링크]
보통 실시간 보호 기능을 활성화시켜 놓지만 특정 상황일 때는 실시간 보호 기능을 비활성화 시켜야 할 때가 있다. Windows 실시간 보호 기능 켜기/끄기 1. "Windows + I" → "개인 정보 및 보안" → "Windows 보안" - "Windows + I"을 눌러 설정 창을 연다. - "개인 정보 및 보안" 선택 → "Windows 보안" 선택 2. "바이러스 및 위협 방지" 클릭 - "바이러스 및 위협 방지" 선택 3. "바이러스 및 위협 방지 설정"의 "설정 관리" 클릭 - "바이러스 및 위협 방지 설정"의 "설정 관리" 선택 - "실시간 보호 기능"을 비활성화한다.
[Windows 11] Windows Bit 확인하는 방법(32bit/64bit) [내부링크]
프로그램을 다운로드 받을 때 32bit와 64bit를 나누어 다운로드 받아야 하는 경우가 많기 때문에 운영체제의 Bit 수를 알아야 할 때가 있다. 본인 PC와 다른 Bit에 해당되는 프로그램을 다운로드 받았을 때 정상 동작하지 않을 수 있다. Windows Bit 확인하는 방법(32bit/64bit) 1. "Windows + I" → "시스템" → "정보" - "Windows + I"를 눌러 설정 창을 연다. - "시스템" 선택 → "정보" 선택 2. Windows Bit 확인 - "시스템 종류" 부분에 본인 PC의 Bit가 무엇인지 확인할 수 있다. - 64Bit의 PC는 "x64"의 프로그램을 다운로드 받으면 된다. - 32Bit의 PC는 "x32"이나 "x86"의 프로그램을 다운로드 받으면 된다.
[Windows 11] Windows Defender 켜기/끄기 [내부링크]
보통 Windows Defender를 활성화시켜 놓지만 특정 상황일 때는 Windows Defender를 비활성화 시켜야 할 때가 있다. Windows Defender 켜기/끄기 1. 제어판 실행 - "Windows + R"을 눌러 실행 창을 연다. - "control"을 입력 후 "확인"을 누르면 제어판이 열린다. 2. "Windows Defender 방화벽" 클릭 - "보기 기준"을 "작은 아이콘"으로 변경하면 "Windows Defender 방화벽"이 보인다. - "Windows Defender 방화벽" 클릭 3. "Windows Defender 방화벽" 해제 - "Windows Defender 방화벽 설정 또는 해제" 클릭 - "Windows Defender 방화벽 사용 안 함" 선택 → "확인" 선택 4. "Windows Defender 방화벽" 해제 확인 - Windows Defender가 해제되었는지 확인한다.
[Windows 11] Windows 시스템 언어 변경하는 방법 [내부링크]
Windows 시스템 언어를 보통 한국어로 사용하지만 특정 상황에서는 영어 등 다른 언어를 사용해야 할 때가 있다. Windows 시스템 언어 변경하는 방법 1. "Windows + I"로 설정 창 열기 - "Windows + I"를 눌러 설정 창을 연다. 2. "시간 및 언어" → "언어 및 지역" - "시간 및 언어" 클릭 → "언어 및 지역" 클릭 3. "언어 추가"를 눌러 "English" 언어 팩을 다운 - "언어 추가" 선택 - "English" 언어 검색 및 선택 → "다음" 선택 - 설치하려는 기능을 선택 → "설치" 선택 - 언어 팩을 다운로드 받다. 4. Windows 시스템 언어 변경 - "Windows 표시 언어"의 부분을 "English"로 변경한다. - Windows 시스템 언어를 적용하기 위해 로그아웃 후 다시 로그인한다. - Windows 시스템 언어가 변경된 것을 확인한다.
[Windows 11] Windows 시스템 폰트 변경하는 방법 [내부링크]
윈도우 시스템 전체에 시스템 폰트를 변경하고 싶을 때가 있지만 윈도우 글꼴 창에서는 바로 글꼴을 변경할 수 없다. 윈도우 시스템 폰트를 변경하기 위해 먼저 "Microangelo On Display"라는 프로그램을 다운 받아야 한다. Windows 시스템 폰트 변경하는 방법 1. "Microangelo On Display" 설치 - "Microangelo On Display"를 설치한다. · URL : https://www.microangelo.us/free-download/change-vista-icons.asp Free Download: Microangelo On Display Microangelo On Display Download Change Vista icons with On Display. Microangelo On Display On Display can customize your desktop's icon and cursor display like no other ic
[Windows 11] Windows 작업 표시줄 아이콘 왼쪽으로 정렬하는 방법 [내부링크]
Windows 10에서 Windows 11로 업그레이드 후 작업 표시줄에 있는 아이콘이 중앙에 정렬되어 있는 것이 불편했다. 그래서 Windows 11에서 작업 표시줄에 있는 아이콘이 왼쪽에 정렬되도록 설정하는 방법을 공유하려고 한다. 작업 표시줄 아이콘 왼쪽으로 정렬하는 방법 1. Windows 11 작업 표시줄 아이콘 중앙 정렬 확인 - Windows 11을 설치하면 기본적으로 작업 표시줄 중앙에 아이콘이 정렬되어 있다. 2. "설정 창" → "개인 설정" → "작업 표시줄" - "Windows + I"를 눌러 설정 창을 연다. - "개인 설정" 클릭 → "작업 표시줄" 클릭 3. "작업 표시줄 동작" - "작업 표시줄 동작" 클릭 4. "작업 표시줄 맞춤"에서 "가운데" → "왼쪽"으로 변경 - "작업 표시줄 맞춤" 부분을 "오른쪽" → "왼쪽"으로 변경함 5. Windows 11 작업 표시줄 아이콘 왼 정렬 확인 - 설정 변경 후 작업 표시줄의 아이콘이 왼쪽 정렬이 되었음을
[Windows 11] Windows 작업 표시줄 가상 데스크톱 아이콘 생성 및 이용 방법 [내부링크]
컴퓨터 사용 중에 많은 프로그램을 이용할 때 용도 별로 가상 데스크톱을 생성하여 사용하면 보다 쾌적한 환경에서 작업을 할 수 있다. 작업 표시줄에 가상 데스크톱 아이콘 생성 방법 1. "설정 창" 열기 ① "Windows + I"를 눌러 설정 창을 연다. ② "Windows + S"를 눌러 윈도우 검색창을 열고 "설정"을 검색한다. 2. "개인 설정" → "작업 표시줄" 열기 - "개인 설정" 선택 → "작업 표시줄" 선택 3. "작업 보기" 활성화화 - "작업 보기" 활성화를 한다. 4. 작업 표시줄에 "작업 보기" 아이콘 생성 확인 - "작업 보기" 아이콘이 생성되었다. 가상 데스크톱 이용 방법 (생성 / 이름 변경 / 삭제) 1. 가상 데스크톱 생성 ① "새 데스크톱" 부분의 "+" 부분을 눌러 가상 데스크톱을 생성한다. - 단축키인 "Windows + Tab"을 눌러 가상 데스크톱을 생성한다. ② 단축키인 "Ctrl + Windows + D"를 눌러 가상 데스크톱을 생성한다.
[Windows 11] Windows 작업 표시줄 검색 창 생성 방법 [내부링크]
윈도우 검색 창을 이용하여 특정 프로그램을 찾으면 효율적으로 사용할 수 있다. 작업 표시줄에 검색 창 생성 방법 1. "설정 창" 열기 ① "Windows + I"를 눌러 설정 창을 연다. ② "Windows + S"를 눌러 윈도우 검색창을 열고 "설정"을 검색한다. 2. "개인 설정" → "작업 표시줄" 열기 - "개인 설정" 선택 → "작업 표시줄" 선택 3. "검색" 활성화화 - "검색" 활성화를 한다. 4. 작업 표시줄에 "검색" 아이콘 생성 확인 - "검색" 아이콘이 생성되었다. 5. 작업 표시줄에 생성된 "검색"창 클릭 - 검책 창을 클릭하여 검색하면 설치되어 있는 프로그램이나 웹을 이용하여 검색할 수 있다.
[Windows 11] Windows 노트북 클램쉘 모드 설정 방법 [내부링크]
요즘 데스크톱보다 노트북을 사용하는 사람이 많아졌다. 집에서 노트북을 데스크톱 PC처럼 사용하여 공간 활용을 높이기 위하여 "클램쉘"이라는 것을 이용한다. "클램쉘"이란 노트북 덮개를 닫았을 때 절전모드로 변경되지 않고 사용이 가능하다. 이때 노트북은 데스크톱 본체라고 생각하면 편하다. Windows 노트북 클램쉘 모드 설정 방법 1. "전원 관리 옵션 설정" 열기 - "Windows + S"를 눌러 윈도우 검색창을 열고 "전원 관리 옵션 설정"을 검색한다. 2. "덮개를 닫으면 수행되는 작업 선택" 클릭 3. 클램쉘 모드 설정 - 덮개를 닫았을 때 "아무 것도 안 함"으로 설정한 후에 "변경 내용 저장"을 누른다. - 위와 같이 설정했을 때는 전원을 연결하지 않고 배터리를 사용중일 때 덮개를 닫으면 절전모드로 변경된다. · 배터리를 사용중일 때에도 덮개를 닫았을 때 클램쉘 모드를 사용하려면 왼쪽 부분도 "아무 것도 안 함"으로 변경하면 된다.
[Emulator Guide] CentOS 7 설치 ② [내부링크]
[Emulator Guide] CentOS 7 설치 ② 1. "Power on this virtual machine" 선택 - "Power on this virtual machine"을 선택하여 가상 머신에 전원을 넣어줌 2. "Install CentOS Linux 7" 선택 - "Install CentOS Linux 7"를 선택하여 CentOS 7을 설치함 - 방향키로 위, 아래를 이동할 수 있음 - 엔터키를 사용하여 선택할 수 있음 3. "English" 선택 → "Continue" 선택 - 설치할 때 사용할 언어를 선택함 4. "DATE & TIME" 선택 5. Asia/Seoul Timezone 선택 - Asia/Seoul Timezone을 선택 6. "SOFTWARE SELECTION" 선택 7. "Server with GUI" 선택 → "Done" 선택 - Red Hat에 설치할 소프트웨어를 선택함 8. "INSTALLATION DESTINATION" 선택 9. "I wi
네이버 블로그
티스토리
커뮤니티