choiyoonjun111의 등록된 링크

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

Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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 멤버십

원문보기 내부링크
Naver Blog

[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 알고리즘을 사용하여

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

[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에 도달하기 위해 중간

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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로 잡힘

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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를 수신하면 모든 라우터는

원문보기 내부링크
Naver Blog

[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의 경우 공유

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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를 사용할 수 없음

원문보기 내부링크
Naver Blog

[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을 적용시키고

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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을 구분

원문보기 내부링크
Naver Blog

[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를 완전히 볼

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

[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할 수 있음 -

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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 같은 공격에 보호

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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으로 지정

원문보기 내부링크
Naver Blog

[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는 아무 설정하

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

[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가 높은

원문보기 내부링크
Naver Blog

[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의 물리적 인

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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가 높은

원문보기 내부링크
Naver Blog

[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로 된 라우팅 테이블 변화가 즉각적

원문보기 내부링크
Naver Blog

[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 네트워크로 가기 위해 오른쪽 라우터로 보내면 됨

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

[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)이 동작함

원문보기 내부링크
Naver Blog

[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 네트워크가

원문보기 내부링크
Naver Blog

[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를 자신의 경로로 기억을 해

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

[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의 대상이

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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을 송신

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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로 재분배된 네트

원문보기 내부링크
Naver Blog

[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"로 보임

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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로 간주되어 구성할 수 없음

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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 경로 개수

원문보기 내부링크
Naver Blog

[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이 맺어질

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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의 두 단계로 구성됨 매우 복잡한 라우팅 정책을

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

[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 중 어떤 것으로 광고받았는지 알려줌

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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"는 프로토콜이 재실행되

원문보기 내부링크
Naver Blog

[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"가 설정된 경우 지정된

원문보기 내부링크
Naver Blog

[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의 모든 경로를 재계산함

원문보기 내부링크
Naver Blog

[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로만 구성 - 현재 양

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

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

원문보기 내부링크
Naver Blog

[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 적용하지

원문보기 내부링크
Naver Blog

[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를 수정함

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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에게 전송 라우

원문보기 내부링크
Naver Blog

[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에게 전달되지 않음

원문보기 내부링크
Naver Blog

[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이 되면 어떤 프로토콜로부터 배운 것인지 구분할 수 없어 "

원문보기 내부링크
Naver Blog

[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

원문보기 내부링크
Naver Blog

[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 값을 사

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