choiyoonjun111의 등록된 링크

키자드에 등록된 총 496개의 포스트를 확인하실 수 있습니다.

Naver Blog

[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

원문보기 내부링크
Naver Blog

[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은 괄호 {} 안에 표시된

원문보기 내부링크
Naver Blog

[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)

원문보기 내부링크
Naver Blog

[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에게 광고하는 것을 제어할 수

원문보기 내부링크
Naver Blog

[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 - 벌점이 기준을 초과하여 해당 네트워

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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을 지원함 다

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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될 트래픽을 식별하기 위한 트래

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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)을 식별하기 위해

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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 망

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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"의 차

원문보기 내부링크
Naver Blog

[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 적용 및 확

원문보기 내부링크
Naver Blog

[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으로 구성됨 "

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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 서비스는 서로 다른 여러

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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로 연동함

원문보기 내부링크
Naver Blog

[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 정

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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로 보냄

원문보기 내부링크
Naver Blog

[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 - 구성

원문보기 내부링크
Naver Blog

[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을 연결하는

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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 :

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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가 단일 스

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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 연결성 확인

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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를 정해놓은 백분율보다 커지면 경보가 생성되

원문보기 내부링크
Naver Blog

[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 정보가

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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"를 사용하면 서비스

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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 프레임이

원문보기 내부링크
Naver Blog

[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으로 복제됨 수신한 포트에 복제되지 않음

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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 망은

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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에 영

원문보기 내부링크
Naver Blog

[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 동작

원문보기 내부링크
Naver Blog

[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을 유지

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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-

원문보기 내부링크
Naver Blog

[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)를 생성하지 않음 어떤 인터페이스

원문보기 내부링크
Naver Blog

[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 - 하나의 사이트에만 사용 시 사

원문보기 내부링크
Naver Blog

[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 시 확인

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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으로 선출함

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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가 응답함 - 때문에 보통

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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를 던질 것

원문보기 내부링크
Naver Blog

[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를 수신하고 싶어함 - 현재

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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를 구성했을 때 찾

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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 //

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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를 지정

원문보기 내부링크
Naver Blog

[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 - 구성

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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 옵션이 적용

원문보기 내부링크
Naver Blog

[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 옵션

원문보기 내부링크
Naver Blog

[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를 다르게 하여 두 라우터에 각

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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 장비 정상가 되었어도 프로토

원문보기 내부링크
Naver Blog

[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의

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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 상태를 유지함 단말은 게이트웨이의 변화를 인지하지 못함

원문보기 내부링크
1 2 3 4 5