BGP 경로 리플렉터
BGP 경로 리플렉터 이해하기
이 주제에서는 구성을 단순화하고 확장을 지원하는 데 경로 리플렉터를 사용하는 것에 대해 설명합니다. traffic-forwarding 경로에 없는 경로 리플렉터의 워크로드를 줄이는 또 다른 방법은 [edit protocols bgp family family-name] 계층 수준에서 no-install 문을 사용하는 것입니다. Junos OS 릴리스 15.1부터 no-install 문은 routing protocols daemon(rpd)과 kernel 또는 distributed firewall daemon(dfwd)과 같은 Junos 시스템의 기타 요소 간에 상호 작용을 제거합니다. 이 상호 작용은 라우팅 테이블이라고도 하는 연관된 rpd RIB(Routing Information Base)의 모든 경로가 해당 구성 요소에 게시되는 것을 금지함으로써 제거됩니다.
Junos OS 릴리스 15.1 이전 릴리스에서는 BGP에서 학습된 경로를 거부하는 forwarding-table 내보내기 정책을 사용하여 traffic-forwarding 경로에 없는 경로 리플렉터의 워크로드를 줄일 수 있습니다.
내부 BGP(IBGP) 풀 메시 요구 사항으로 인해 대부분의 네트워크는 경로 리플렉터를 사용하여 구성을 단순화합니다. 풀 메시에 필요한 세션 수를 계산하는 공식은 v * (v - 1)/2입니다. 여기서 v는 BGP 지원 디바이스 개수입니다. 풀 메시 모델은 잘 확장되지 않습니다. 경로 리플렉터를 사용하여 라우터를 클러스터로 그룹화하고, 클러스터는 AS(Autonomous System)에 고유한 숫자 식별자로 확인됩니다. 클러스터 내에서 단일 라우터(경로 리플렉터)의 BGP 세션을 각 내부 피어로 구성해야 합니다. 이러한 구성을 통해 IBGP 풀 메시 요구 사항이 충족됩니다.
AS에서 경로 리플렉터를 사용하려면 하나 이상의 라우터를 경로 리플렉터로 지정합니다(일반적으로 POP당 1개). 경로 리플렉터는 내부 피어에서 학습한 경로를 다른 내부 피어로 재보급하는 특별한 BGP 기능이 있습니다. 따라서 모든 내부 피어가 서로 완전하게 연결되도록 요구하는 대신, 경로 리플렉션은 경로 리플렉터가 모든 내부 피어와 완전히 연결되면 됩니다. 경로 리플렉터와 해당하는 모든 내부 피어가 클러스터를 형성합니다(그림 1).
일부 주니퍼 네트웍스 디바이스의 경우, 경로 리플렉터를 사용하는 각 디바이스에 고급 BGP 기능 라이선스가 설치되어야 합니다. 라이선스 상세 정보는 소프트웨어 설치 및 업그레이드 가이드를 참조하십시오.
그림 1은 Cluster 127의 경로 리플렉터로 구성된 라우터 RR을 보여줍니다. 다른 라우터는 클러스터 내에서 지정된 내부 피어입니다. BGP 경로는 내부 피어에 의해 라우터 RR에 보급됩니다. 그런 다음, RR은 해당 경로를 클러스터 내의 다른 모든 피어로 재보급합니다.
경로 리플렉터의 풀 메시를 구성하여 여러 클러스터를 구성하고 연결할 수 있습니다(그림 2 참조).
그림 2는 경로 리플렉터 RR 1, RR 2, RR 3, RR 4를 풀 메시 내부 피어로 보여줍니다. 라우터가 경로를 RR 1에 보급하면, RR 1은 다른 경로 리플렉터로 경로를 재보급하고, 이를 통해 AS 내의 나머지 라우터에 경로를 재보급합니다. 경로 리플렉션을 사용하면 풀 메시 요건으로 인해 발생하는 확장 문제 없이 경로를 AS 전체에 전파할 수 있습니다.
여러 클러스터를 지원하는 경로 리플렉터는 비클라이언트 라우터에서 동일한 cluster ID를 가진 경로를 허용하지 않습니다. 따라서 중복 RR에 다른 cluster ID를 구성하여 다른 클러스터에 경로를 반영해야 합니다.
그러나 클러스터가 확대되면 경로 리플렉터가 있는 풀 메시와 경로 리플렉터 사이의 풀 메시를 확대하기가 어려워집니다. 이 문제를 보완하려면 계층적 경로 리플렉션을 위해 라우터 클러스터를 클러스터의 클러스터로 그룹화할 수 있습니다(그림 3 참조).
그림 3은 Cluster 127, 19, 45에 대한 경로 리플렉터로 각각 RR 2, RR 3, RR 4를 보여줍니다. 네트워크 관리자는 이러한 경로 리플렉터를 풀 메시하는 대신 RR 1이 경로 리플렉터인 다른 클러스터(Cluster 6)의 일부로 구성했습니다. 라우터가 경로를 RR 2에 보급하면 RR 2는 자체 클러스터 내의 모든 라우터에 경로를 재보급한 다음, 경로를 RR 1에 재보급합니다. RR 1은 해당 클러스터의 라우터에 경로를 재보급하고 해당 라우터는 해당 클러스터를 통해 경로를 전파합니다.
참조
예: 경로 리플렉터 구성
이 예는 경로 리플렉터를 구성하는 방법을 보여줍니다.
요구 사항
이 예제를 구성하기 전에 디바이스 초기화 이외의 특별한 구성은 필요하지 않습니다.
개요
일반적으로, IBGP는 다른 IBGP 지원 디바이스에 대해 업데이트를 다시 보급하지 않기 때문에 내부 BGP(IBGP) 지원 디바이스는 완전히 연결되어야 합니다. 풀 메시는 각 IBGP 지원 디바이스에서 여러 개의 neighbor 문을 구성하여 획득한 논리적 메시입니다. 풀 메시가 반드시 물리적 풀 메시인 것은 아닙니다. 풀 메시(논리적 또는 물리적)를 유지해도 대규모 배포에서 제대로 확장되지 않습니다.
그림 4는 경로 리플렉터 역할을 하는 디바이스 A가 있는 IBGP 네트워크를 표시합니다. 디바이스 B와 디바이스 C는 경로 리플렉터의 클라이언트입니다. 디바이스 D 및 디바이스 E는 클러스터 외부에 있으므로, 경로 리플렉터의 비클라이언트입니다.
디바이스 A(경로 리플렉터)에서 클라이언트(디바이스 B와 디바이스 C)와 비클라이언트(디바이스 D와 디바이스 E)에 대한 neighbor 문을 포함한 모든 IBGP 지원 디바이스에서 피어 관계를 형성해야 합니다. 또한 cluster 문과 클러스터 식별자를 포함해야 합니다. 클러스터 식별자는 모든 32비트 값이 될 수 있습니다. 이 예는 경로 리플렉터의 루프백 인터페이스 IP 주소를 사용합니다.
경로 리플렉터 클라이언트인 디바이스 B와 디바이스 C에서는 경로 리플렉터인 디바이스 A와 피어 관계를 구축하는 하나의 neighbor 문만 필요합니다.
비클라이언트인 디바이스 D와 디바이스 E에서는 각 비클라이언트 디바이스(D-to-E 및 E-to-D)에 neighbor 문이 필요합니다. 또한 경로 리플렉터(D-to-A 및 E-to-A)에 neighbor 문도 필요합니다. 디바이스 D와 디바이스 E는 클라이언트 디바이스(디바이스 B와 디바이스 C)에 neighbor 문이 필요하지 않습니다.
디바이스 D와 디바이스 E는 서로 명시적으로 피어 관계를 구성했으므로 비클라이언트로 간주됩니다. 이것을 RRroute 리플렉터 클라이언트로 만들려면 디바이스 D의 구성에서 neighbor 192.168.5.5 문을 삭제하고, 디바이스 E의 구성에서 neighbor 192.168.0.1 문을 삭제합니다.
구성
절차
CLI 빠른 구성
이 예를 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일로 붙여 넣은 다음 모든 라인브레이크를 제거하고, 네트워크 구성을 일치하는 데 필요한 세부 사항을 바꾸고 [edit] 계층 수준에서 명령을 CLI로 복사해 붙여 넣습니다.
디바이스 A
set interfaces fe-0/0/0 unit 1 description to-B set interfaces fe-0/0/0 unit 1 family inet address 10.10.10.1/30 set interfaces fe-0/0/1 unit 3 description to-D set interfaces fe-0/0/1 unit 3 family inet address 10.10.10.9/30 set interfaces lo0 unit 1 family inet address 192.168.6.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.6.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers cluster 192.168.6.5 set protocols bgp group internal-peers neighbor 192.163.6.4 set protocols bgp group internal-peers neighbor 192.168.40.4 set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.1 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.1 set protocols ospf area 0.0.0.0 interface fe-0/0/1.3 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.6.5 set routing-options autonomous-system 17
디바이스 B
set interfaces fe-0/0/0 unit 2 description to-A set interfaces fe-0/0/0 unit 2 family inet address 10.10.10.2/30 set interfaces fe-0/0/1 unit 5 description to-C set interfaces fe-0/0/1 unit 5 family inet address 10.10.10.5/30 set interfaces lo0 unit 2 family inet address 192.163.6.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.163.6.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.2 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.2 set protocols ospf area 0.0.0.0 interface fe-0/0/1.5 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.163.6.4 set routing-options autonomous-system 17
디바이스 C
set interfaces fe-0/0/0 unit 6 description to-B set interfaces fe-0/0/0 unit 6 family inet address 10.10.10.6/30 set interfaces lo0 unit 3 family inet address 192.168.40.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.40.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.3 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.6 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.40.4 set routing-options autonomous-system 17
디바이스 D
set interfaces fe-0/0/0 unit 4 description to-A set interfaces fe-0/0/0 unit 4 family inet address 10.10.10.10/30 set interfaces fe-0/0/1 unit 7 description to-E set interfaces fe-0/0/1 unit 7 family inet address 10.10.10.13/30 set interfaces lo0 unit 4 family inet address 192.168.0.1/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.0.1 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols bgp group internal-peers neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.4 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.4 set protocols ospf area 0.0.0.0 interface fe-0/0/1.7 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.0.1 set routing-options autonomous-system 17
디바이스 E
set interfaces fe-0/0/0 unit 8 description to-D set interfaces fe-0/0/0 unit 8 family inet address 10.10.10.14/30 set interfaces lo0 unit 5 family inet address 192.168.5.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.5.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.5 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.8 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.5.5 set routing-options autonomous-system 17
단계별 절차
경로 리플렉터 구성
단계별 절차
다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. CLI 탐색 관련 정보는 Junos OS CLI 사용자 가이드의 구성 모드에서의 CLI 편집기 사용을 참조하십시오.
주니퍼 네트웍스 디바이스 A를 경로 리플렉터로 사용하여 네트워크에서 IBGP를 구성하는 방법:
인터페이스를 구성합니다.
[edit interfaces] user@A# set fe-0/0/0 unit 1 description to-B user@A# set fe-0/0/0 unit 1 family inet address 10.10.10.1/30 user@A# set fe-0/0/1 unit 3 description to-D user@A# set fe-0/0/1 unit 3 family inet address 10.10.10.9/30 user@A# set lo0 unit 1 family inet address 192.168.6.5/32
클러스터 식별자 및 AS(Autonomous System)의 모든 IBGP 지원 장치와의 인접 관계를 포함하여 BGP를 구성합니다.
또한 OSPF 경로를 BGP에 재배포하는 정책을 적용합니다.
[edit protocols bgp group internal-peers] user@A# set type internal user@A# set local-address 192.168.6.5 user@A# set export send-ospf user@A# set cluster 192.168.6.5 user@A# set neighbor192.163.6.4 user@A# set neighbor 192.168.40.4 user@A# set neighbor 192.168.0.1 user@A# set neighbor 192.168.5.5
정적 라우팅 또는 IGP(Interior Gateway Protocol)를 구성합니다.
이 예는 OSPF를 사용합니다.
[edit protocols ospf area 0.0.0.0] user@A# set interface lo0.1 passive user@A# set interface fe-0/0/0.1 user@A# set interface fe-0/0/1.3
OSPF 경로를 BGP로 재배포하는 정책을 구성합니다.
[edit policy-options policy-statement send-ospf term 2] user@A# set from protocol ospf user@A# set then accept
라우터 ID 및 AS(Autonomous System) 번호를 구성합니다.
[edit routing-options] user@A# set router-id 192.168.6.5 user@A# set autonomous-system 17
결과
구성 모드에서 show interfaces, show protocols, show policy-options 및 show routing-options 명령을 입력하여 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.
user@A# show interfaces
fe-0/0/0 {
unit 1 {
description to-B;
family inet {
address 10.10.10.1/30;
}
}
}
fe-0/0/1 {
unit 3 {
description to-D;
family inet {
address 10.10.10.9/30;
}
}
}
lo0 {
unit 1 {
family inet {
address 192.168.6.5/32;
}
}
}
user@A# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.168.6.5;
export send-ospf;
cluster 192.168.6.5;
neighbor 192.163.6.4;
neighbor 192.168.40.4;
neighbor 192.168.0.1;
neighbor 192.168.5.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.1 {
passive;
}
interface fe-0/0/0.1;
interface fe-0/0/1.3;
}
}
user@A# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@A# show routing-options router-id 192.168.6.5; autonomous-system 17;
디바이스 구성을 마쳤으면 구성 모드에서 commit을 입력합니다.
다른 비클라이언트 디바이스가 주니퍼 네트웍스에서 제공되는 경우 구성 중인 클러스터 내의 각 비클라이언트 BGP 피어에 대해 이 단계를 반복합니다. 그렇지 않으면 디바이스 문서에서 지침을 참조하십시오.
클라이언트 피어 구성
단계별 절차
다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. CLI 탐색 관련 정보는 Junos OS CLI 사용자 가이드의 구성 모드에서의 CLI 편집기 사용을 참조하십시오.
클라이언트 피어 구성 방법:
인터페이스를 구성합니다.
[edit interfaces] user@B# set fe-0/0/0 unit 2 description to-A user@B# set fe-0/0/0 unit 2 family inet address 10.10.10.2/30 user@B# set fe-0/0/1 unit 5 description to-C user@B# set fe-0/0/1 unit 5 family inet address 10.10.10.5/30 user@B# set lo0 unit 2 family inet address 192.163.6.4/32
경로 리플렉터와의 BGP 인접 관계를 구성합니다.
또한 OSPF 경로를 BGP에 재배포하는 정책을 적용합니다.
[edit protocols bgp group internal-peers] user@B# set type internal user@B# set local-address 192.163.6.4 user@B# set export send-ospf user@B# set neighbor 192.168.6.5
OSPF를 구성합니다.
[edit protocols ospf area 0.0.0.0] user@B# set interface lo0.2 passive user@B# set interface fe-0/0/0.2 user@B# set interface fe-0/0/1.5
OSPF 경로를 BGP로 재배포하는 정책을 구성합니다.
[edit policy-options policy-statement send-ospf term 2] user@B# set from protocol ospf user@B# set then accept
라우터 ID 및 AS 번호를 구성합니다.
[edit routing-options] user@B# set router-id 192.163.6.4 user@B# set autonomous-system 17
결과
구성 모드에서 show interfaces, show protocols, show policy-options 및 show routing-options 명령을 입력하여 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.
user@B# show interfaces
fe-0/0/0 {
unit 2 {
description to-A;
family inet {
address 10.10.10.2/30;
}
}
}
fe-0/0/1 {
unit 5 {
description to-C;
family inet {
address 10.10.10.5/30;
}
}
}
lo0 {
unit 2 {
family inet {
address 192.163.6.4/32;
}
}
}
user@B# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.163.6.4;
export send-ospf;
neighbor 192.168.6.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.2 {
passive;
}
interface fe-0/0/0.2;
interface fe-0/0/1.5;
}
}
user@B# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@B# show routing-options router-id 192.163.6.4; autonomous-system 17;
디바이스 구성을 마쳤으면 구성 모드에서 commit을 입력합니다.
다른 클라이언트 디바이스가 주니퍼 네트웍스에서 제공되는 경우 구성 중인 클러스터 내의 각 클라이언트 BGP 피어에 대해 이 단계를 반복합니다. 그렇지 않으면 디바이스 문서에서 지침을 참조하십시오.
비클라이언트 피어 구성
단계별 절차
다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. CLI 탐색 관련 정보는 Junos OS CLI 사용자 가이드의 구성 모드에서의 CLI 편집기 사용을 참조하십시오.
비클라이언트 피어 구성 방법:
인터페이스를 구성합니다.
[edit interfaces] user@D# set fe-0/0/0 unit 4 description to-A user@D# set fe-0/0/0 unit 4 family inet address 10.10.10.10/30 user@D# set fe-0/0/1 unit 7 description to-E user@D# set fe-0/0/1 unit 7 family inet address 10.10.10.13/30 user@D# set lo0 unit 4 family inet address 192.168.0.1/32
RRroute 리플렉터 및 다른 비클라이언트 피어와의 BGP 인접 관계를 구성합니다.
또한 OSPF 경로를 BGP에 재배포하는 정책을 적용합니다.
[edit protocols bgp group internal-peers] user@D# set type internal user@D# set local-address 192.168.0.1 user@D# set export send-ospf user@D# set neighbor 192.168.6.5 user@D# set neighbor 192.168.5.5
OSPF를 구성합니다.
[edit protocols ospf area 0.0.0.0] user@D# set interface lo0.4 passive user@D# set interface fe-0/0/0.4 user@D# set interface fe-0/0/1.7
OSPF 경로를 BGP로 재배포하는 정책을 구성합니다.
[edit policy-options policy-statement send-ospf term 2] user@D# set from protocol ospf user@D# set then accept
라우터 ID 및 AS 번호를 구성합니다.
[edit routing-options] user@D# set router-id 192.168.0.1 user@D# set autonomous-system 17
결과
구성 모드에서 show interfaces, show protocols, show policy-options 및 show routing-options 명령을 입력하여 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.
user@D# show interfaces
fe-0/0/0 {
unit 4 {
description to-A;
family inet {
address 10.10.10.10/30;
}
}
}
fe-0/0/1 {
unit 7 {
description to-E;
family inet {
address 10.10.10.13/30;
}
}
}
lo0 {
unit 4 {
family inet {
address 192.168.0.1/32;
}
}
}
user@D# show protocols
bgp {
group internal-peers {
type internal;
local-address 192.168.0.1;
export send-ospf;
neighbor 192.168.6.5;
neighbor 192.168.5.5;
}
}
ospf {
area 0.0.0.0 {
interface lo0.4 {
passive;
}
interface fe-0/0/0.4;
interface fe-0/0/1.7;
}
}
user@D# show policy-options
policy-statement send-ospf {
term 2 {
from protocol ospf;
then accept;
}
}
user@D# show routing-options router-id 192.168.0.1; autonomous-system 17;
디바이스 구성을 마쳤으면 구성 모드에서 commit을 입력합니다.
다른 비클라이언트 디바이스가 주니퍼 네트웍스에서 제공되는 경우 구성 중인 클러스터 내의 각 비클라이언트 BGP 피어에 대해 이 단계를 반복합니다. 그렇지 않으면 디바이스 문서에서 지침을 참조하십시오.
검증
구성이 올바르게 작동하고 있는지 확인합니다.
BGP 인접 라우터 확인
목적
BGP가 구성된 인터페이스에서 실행되고 BGP 세션이 각 neighbor 주소에 대해 구성되어 있는지 확인됩니다.
작업
운영 모드에서 show bgp neighbor 명령을 입력합니다.
user@A> show bgp neighbor
Peer: 192.163.6.4+179 AS 17 Local: 192.168.6.5+62857 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.163.6.4 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 6
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 5 Sent 3 Checked 19
Input messages: Total 2961 Updates 7 Refreshes 0 Octets 56480
Output messages: Total 2945 Updates 6 Refreshes 0 Octets 56235
Output Queue[0]: 0
Peer: 192.168.0.1+179 AS 17 Local: 192.168.6.5+60068 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.0.1 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 3
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 6
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 18 Sent 20 Checked 12
Input messages: Total 15 Updates 5 Refreshes 0 Octets 447
Output messages: Total 554 Updates 4 Refreshes 0 Octets 32307
Output Queue[0]: 0
Peer: 192.168.5.5+57458 AS 17 Local: 192.168.6.5+179 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.5.5 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 2
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 17 Sent 3 Checked 9
Input messages: Total 2967 Updates 7 Refreshes 0 Octets 56629
Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197
Output Queue[0]: 0
Peer: 192.168.40.4+53990 AS 17 Local: 192.168.6.5+179 AS 17
Type: Internal State: Established (route reflector client)Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-ospf ]
Options: <Preference LocalAddress Cluster Refresh>
Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.40.4 Local ID: 192.168.6.5 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 1
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 17)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Advertised prefixes: 6
Last traffic (seconds): Received 5 Sent 23 Checked 52
Input messages: Total 2960 Updates 7 Refreshes 0 Octets 56496
Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197
Output Queue[0]: 0BGP 그룹 확인
목적
BGP 그룹이 올바르게 구성되는지 확인합니다.
작업
운영 모드에서 show bgp group 명령을 입력합니다.
user@A> show bgp group Group Type: Internal AS: 17 Local AS: 17 Name: internal-peers Index: 0 Flags: <> Export: [ send-ospf ] Options: <Cluster> Holdtime: 0 Total peers: 4 Established: 4 192.163.6.4+179 192.168.40.4+53990 192.168.0.1+179 192.168.5.5+57458 inet.0: 0/26/16/0 Groups: 1 Peers: 4 External: 0 Internal: 4 Down peers: 0 Flaps: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0
BGP 요약 정보 확인
목적
BGP 구성이 올바른지 확인합니다.
작업
운영 모드에서 show bgp summary 명령을 입력합니다.
user@A> show bgp summary Groups: 1 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.163.6.4 17 2981 2965 0 0 22:19:15 0/6/1/0 0/0/0/0 192.168.0.1 17 36 575 0 0 13:43 0/6/1/0 0/0/0/0 192.168.5.5 17 2988 2964 0 0 22:19:10 0/7/7/0 0/0/0/0 192.168.40.4 17 2980 2964 0 0 22:19:14 0/7/7/0 0/0/0/0
라우팅 테이블 정보 확인
목적
라우팅 테이블에 IBGP 경로가 포함되어 있는지 확인합니다.
작업
운영 모드에서 show route 명령을 입력합니다.
user@A> show route
inet.0: 12 destinations, 38 routes (12 active, 0 holddown, 10 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/30 *[Direct/0] 22:22:03
> via fe-0/0/0.1
[BGP/170] 22:20:55, MED 2, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 3, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
10.10.10.1/32 *[Local/0] 22:22:03
Local via fe-0/0/0.1
10.10.10.4/30 *[OSPF/10] 22:21:13, metric 2
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 4, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
10.10.10.8/30 *[Direct/0] 22:22:03
> via fe-0/0/1.3
[BGP/170] 22:20:51, MED 2, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 3, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
10.10.10.9/32 *[Local/0] 22:22:03
Local via fe-0/0/1.3
10.10.10.12/30 *[OSPF/10] 22:21:08, metric 2
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 4, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.163.6.4/32 *[OSPF/10] 22:21:13, metric 1
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:55, MED 1, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 3, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
192.168.0.1/32 *[OSPF/10] 22:21:08, metric 1
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:51, MED 1, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 3, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.5.5/32 *[OSPF/10] 22:21:08, metric 2
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 00:15:24, MED 1, localpref 100, from 192.168.0.1
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 4, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.6.5/32 *[Direct/0] 22:22:04
> via lo0.1
[BGP/170] 22:20:51, MED 2, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
[BGP/170] 22:20:55, MED 2, localpref 100, from 192.168.40.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
192.168.40.4/32 *[OSPF/10] 22:21:13, metric 2
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:55, MED 1, localpref 100, from 192.163.6.4
AS path: I
> to 10.10.10.2 via fe-0/0/0.1
[BGP/170] 22:20:51, MED 4, localpref 100, from 192.168.5.5
AS path: I
> to 10.10.10.10 via fe-0/0/1.3
224.0.0.5/32 *[OSPF/10] 22:22:07, metric 1
MultiRecv두 개의 서로 다른 클러스터에 속하는 경로 리플렉터 이해하기
경로 리플렉션의 목적은 내부 BGP(IBGP) 라우팅 디바이스가 완전히 맞물리지 않은 경우의 루프 방지입니다. 이를 위해 RR은 일반 BGP 작동 규칙 중 하나를 위반합니다. 이들은 내부 BGP 피어에서 학습한 경로를 다른 내부 BGP 피어로 다시 보급합니다.
일반적으로 단일 RR은 단일 클러스터의 구성원입니다. 예를 들어, 계층적 RR 설계에서 계층 2 RR은 계층 1 RR의 클라이언트가 될 수 있지만 서로의 클라이언트가 될 수 없다고 간주해봅시다.
그러나 두 RR이 서로의 클라이언트이고 경로가 한 클러스터에서 다른 클러스터로 반영되는 경우 cluster ID 중 하나만 클러스터 목록에 포함됩니다. 이 경우 클러스터 목록에 하나의 cluster ID가 있으면 루프 방지에 적합하기 때문입니다.
표 1에서는 반영된 경로의 클러스터 목록을 cluster ID로 채울 때 경로 리플렉터가 사용하는 규칙을 요약합니다.
경로 리플렉션 시나리오 |
구성 |
|---|---|
클라이언트 중 하나에서 비클라이언트 라우터로 경로를 반영하는 경우 클라이언트 -> RR -> 비클라이언트 |
RR은 반사된 경로의 클러스터 목록에서 해당 클라이언트와 연관된 cluster ID를 채웁니다. |
비클라이언트 라우터에서 클라이언트 라우터로 경로를 반영하는 경우 비클라이언트 -> RR -> 클라이언트 |
RR은 반사된 경로의 클러스터 목록에서 해당 클라이언트와 연관된 cluster ID를 채웁니다. |
클라이언트 라우터에서 다른 클러스터에 있는 다른 클라이언트 라우터로 경로를 반영하는 경우 클라이언트1 -> RR -> 클라이언트2 (다른 클러스터) |
RR은 cluster ID를 클라이언트2에 반영하기 전에 클러스터 목록에서 클라이언트1과 연결된 cluster ID를 채웁니다. 클라이언트 2와 연결된 cluster ID가 추가되지 않았습니다. |
클라이언트 라우터에서 다른 AS(Autonomous System)에 있는 비클라이언트 라우터로 경로를 반영하는 경우. 예를 들어, 계층 2 RR 및 2 BGP 그룹을 구성한 경우, 하나는 RR 클라이언트용이고 다른 하나는 계층 1 RR용이며, 하나의 AS(Autonomous System)에서 다른 AS(Autonomous System)으로의 경로를 반영하고 있습니다. 클라이언트 -> RR -> 비클라이언트 (다른 AS) |
cluster-ID는 하나의 AS(Autonomous System)에 고유하기 때문에 RR은 비클라이언트 장치에 대한 경로를 반영하기 전에 cluster-ID로 클러스터 목록을 채우지 않습니다. |
참조
예: 두 개의 서로 다른 클러스터에 속하는 경로 리플렉터 구성하기
이 예는 각기 다른 두 개의 클러스터에 속하는 경로 리플렉터(RR)를 구성하는 방법을 보여줍니다. 이는 일반적인 시나리오가 아니지만 일부 상황에서는 유용할 수 있습니다.
요구 사항
장치 인터페이스 및 내부 게이트웨이 프로토콜(IGP)을 구성합니다. 인터페이스와 IGP 구성을 포함하는 RR 설정의 예는 예: 루트 리플렉터 구성을 참조하십시오.
개요
이 예에서 디바이스 RR1은 디바이스 R3 및 디바이스 RR2를 위한 경로 리플렉터입니다. 경로 리플렉터 RR1에는 두 개의 각기 다른 클러스터 ID가 할당되어 있습니다. RR1-R3에 5.5.5.5, RR1-RR2에 6.6.6.6입니다.
디바이스 RR2는 디바이스 R4에 대한 경로 리플렉터입니다.
그림을 고려하십시오(그림 5).
이 예는 디바이스 RR1 및 디바이스 RR2의 BGP 구성을 보여줍니다.
구성
절차
CLI 빠른 구성
이 예를 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일로 붙여 넣은 다음 모든 라인브레이크를 제거하고, 네트워크 구성을 일치하는 데 필요한 세부 사항을 바꾸고 [edit] 계층 수준에서 명령을 CLI로 복사해 붙여 넣습니다.
디바이스 RR1
set protocols bgp group RR1_client type internal set protocols bgp group RR1_client local-address 192.168.20.1 set protocols bgp group RR1_client cluster 10.13.1.3 set protocols bgp group RR1_client neighbor 192.168.48.1 set protocols bgp group Non_client type internal set protocols bgp group Non_client local-address 192.168.20.1 set protocols bgp group Non_client neighbor 192.168.16.1 set protocols bgp group RR1_to_RR2 type internal set protocols bgp group RR1_to_RR2 local-address 192.168.20.1 set protocols bgp group RR1_to_RR2 cluster 10.12.1.2 set protocols bgp group RR1_to_RR2 neighbor 192.168.40.1
디바이스 RR2
set protocols bgp group RR2_client type internal set protocols bgp group RR2_client local-address 192.168.40.1 set protocols bgp group RR2_client cluster 10.24.2.4 set protocols bgp group RR2_client neighbor 192.168.32.1 set protocols bgp group RR2_to_RR1 type internal set protocols bgp group RR2_to_RR1 local-address 192.168.40.1 set protocols bgp group RR2_to_RR1 neighbor 192.168.20.1
디바이스 RR1 구성하기
단계별 절차
다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. CLI 탐색 관련 정보는 Junos OS CLI 사용자 가이드의 구성 모드에서의 CLI 편집기 사용을 참조하십시오.
디바이스 RR1 구성:
-
디바이스 R3과의 피어링 관계를 구성합니다.
[edit protocols bgp group RR1_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 10.13.1.3 user@RR1# set neighbor 192.168.48.1
-
디바이스 R0과의 피어링 관계를 구성합니다.
[edit protocols bgp group Non_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set neighbor 192.168.16.1
-
디바이스 RR2와의 피어링 관계를 구성합니다.
[edit protocols bgp group RR1_to_RR2] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 10.12.1.2 user@RR1# set neighbor 192.168.40.1
결과
구성 모드에서 show protocols 명령을 입력하여 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.
user@RR1# show protocols
bgp {
group RR1_client {
type internal;
local-address 192.168.20.1;
cluster 10.13.1.3;
neighbor 192.168.48.1;
}
group Non_client {
type internal;
local-address 192.168.20.1;
neighbor 192.168.16.1;
}
group RR1_to_RR2 {
type internal;
local-address 192.168.20.1;
cluster 10.12.1.2;
neighbor 192.168.40.1;
}
}
디바이스 구성을 마쳤으면 구성 모드에서 commit을 입력합니다.
디바이스 RR2 구성하기
단계별 절차
다음 예는 구성 계층에서 다양한 수준의 탐색이 필요합니다. CLI 탐색 관련 정보는 Junos OS CLI 사용자 가이드의 구성 모드에서의 CLI 편집기 사용을 참조하십시오.
디바이스 RR2 구성:
-
디바이스 R4와의 피어링 관계를 구성합니다.
[edit protocols bgp group RR2_client] user@RR2# set type internal user@RR2# set local-address 192.168.40.1 user@RR2# set cluster 10.24.2.4 user@RR2# set neighbor 192.168.32.1
-
디바이스 RR1과의 피어링 관계를 구성합니다.
[edit protocols bgp group RR2_to_RR1] user@RR2# set type internal user@RR2# set local-address 192.168.40.1 user@RR2# set neighbor 192.168.20.1
결과
구성 모드에서 show protocols 명령을 입력하여 구성을 확인합니다. 출력 결과가 의도한 구성대로 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.
user@RR2# show protocols
bgp {
group RR2_client {
type internal;
local-address 192.168.40.1;
cluster 10.24.2.4;
neighbor 192.168.32.1;
}
group RR2_to_RR1 {
type internal;
local-address 192.168.40.1;
neighbor 192.168.20.1;
}
}
디바이스 구성을 마쳤으면 구성 모드에서 commit을 입력합니다.
검증
구성이 올바르게 작동하고 있는지 확인합니다.
경로 10.3.3.3에 대해 보급된 cluster ID 확인
목적
BGP가 구성된 인터페이스에서 실행되고 BGP 세션이 각 neighbor 주소에 대해 구성되어 있는지 확인됩니다.
작업
운영 모드에서 show route advertising-protocol bgp neighbor-address 명령을 입력합니다.
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 10.3.3.3 extensive
inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden)
* 10.3.3.3/32 (1 entry, 1 announced)
BGP group RR1_to_RR2 type Internal
Nexthop: 192.168.48.1
Localpref: 100
AS path: [100] I
Cluster ID: 10.13.1.3
Originator ID: 192.168.48.1
의미
10.3.3.3/32 경로가 디바이스 RR1 클라이언트 피어, 디바이스 R3에서 유래합니다. 이 경로가 RR1 클라이언트인 디바이스 RR2로 전송되면 경로가 10.13.1.3 cluster ID를 포함합니다. 이것은 RR1-R3에 해당하는 cluster ID입니다.
경로 10.1.0.1에 보급된 cluster ID 확인하기
목적
디바이스 RR1에서 디바이스 RR2로의 경로 보급을 확인합니다.
작업
운영 모드에서 show route advertising-protocol bgp neighbor-address 명령을 입력합니다.
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 10.1.0.1/32 extensive
inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden)
* 10.1.0.1/32 (1 entry, 1 announced)
BGP group RR1_to_RR2 type Internal
Nexthop: 192.168.16.1
Localpref: 100
AS path: [100] I
Cluster ID: 10.12.1.2
Originator ID: 192.168.16.1의미
10.1.0.1/32 경로가 디바이스 RR1의 비-클라이언트 피어인 디바이스 R0에서 유래합니다. 이 경로가 RR1 클라이언트인 디바이스 RR2에 전송되면 경로는 10.12.1.2 cluster ID를 포함합니다. 이것은 RR1-RR2에 대한 cluster ID입니다.
디바이스 RR1은 각기 다른 클러스터(디바이스 R4)에 있는 또 다른 클라이언트에 보급될 때 디바이스 RR2로부터 인바운드 cluster ID를 보존합니다.
BGP-ORR(BGP Optimal Route Reflection) 이해하기
IS-IS(Intermediate System to Intermediate System)와 최단 경로 우선(OSPF)을 사용하여 루트 리플렉터에서 BGP-ORR(BGP Optimal Route Reflection)을 IGP(Interior Gateway Protocol)로 구성하면 BGP-ORR 클라이언트 그룹에 최적의 경로를 광고하실 수 있습니다. 이 작업은 루트 리플렉터의 관점 대신 클라이언트의 관점에서 가장 짧은 IGP 메트릭을 사용하여 수행됩니다.
동일하거나 유사한 IGP 토폴로지를 공유하는 클라이언트 그룹은 하나의 BGP 피어 그룹으로 묶을 수 있습니다. optimal-route-reflection을 구성하면 해당 BGP 피어 그룹에서 BGP-ORR을 활성화하실 수 있습니다. 리플렉터 노드 중 하나를 BGP 피어 그룹의 기본 노드(igp-primary)로 구성하여 해당 기본 노드의 IGP 메트릭을 사용하여 최상의 경로를 선택하고 이를 동일한 BGP 피어 그룹의 클라이언트에 알릴 수도 있습니다. 선택적으로 기본 리플렉터 노드(igp-primary)가 다운되거나 연결할 수 없을 때 사용되는 백업 노드( igp-backup)로 다른 리플렉터노드를 선택할 수도 있습니다.
BGP-ORR을 활성화하려면 [edit protocols bgp group group-name] 계층 수준에서 optimal-route-reflection명령문을 포함하십시오.
BGP-ORR은 IGP가 BGP 경로 해결에 사용될 때만 작동합니다. 경로 해결에 MPLSLDP/RSVP가 사용되는 경우에는 BGP-ORR이 작동하지 않습니다.
BGP-ORR이 작동하려면 BGP 접두사가 IGP를 통해 해결되어야 합니다. 일반적인 레이어 3 VPN, 레이어 2 VPN, VPLS, MVPN 또는 EVPN 시나리오에서는 접두사가 inet.3을 통해 해결됩니다. inet.3에서 접두사의 protocol-다음 홉에 대한 기본 경로는 RSVP 또는 LDP입니다(IS-IS 또는 OSPF와 같은 IGP 프로토콜이 아님). BGP-ORR이 작동하려면 라우터가 레이어 3 VPN, 레이어 2 VPN, VPLS, MVPN 또는 EVPN 접두사의 route-resolution에 inet.0을 사용하도록 구성하셔야 합니다. 이 작업은 다음과 같은 명령을 통해 수행하실 수 있습니다.
-
레이어 3 VPN 접두사의 경우:
user@host# set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0
-
레이어 2 VPN 또는 VPLS 접두사의 경우:
user@host# set routing-options resolution rib bgp.l2vpn.0 resolution-ribs inet.0
-
EVPN 접두사의 경우:
user@host# set routing-options resolution rib bgp.evpn.0 resolution-ribs inet.0
-
MVPN 접두사의 경우:
user@host# set routing-options resolution rib bgp.mvpn.0 resolution-ribs inet.0
또 다른 방법은 IGP 경로를 inet.3으로 유출하여 inet.3에서 기본 경로로 만드는 것입니다.
BGP-ORR을 구성하려면 다음의 CLI 계층을 사용하십시오.
[edit protocols bgp]
group group-name{
optimal-route-reflection {
igp-primary ipv4-address;
igp-backup ipv4-address;
}
}
참조
최적 경로를 보급하기 위한 경로 리플렉터에서의 BGP 최적 경로 반영 구성
IS-IS(Intermediate System to Intermediate System)와 최단 경로 우선(OSPF)을 사용하여 루트 리플렉터에서 BGP-ORR(BGP Optimal Route Reflection)을 IGP(Interior Gateway Protocol)로 구성하면 BGP-ORR 클라이언트 그룹에 최적의 경로를 광고하실 수 있습니다. 이 작업은 루트 리플렉터의 관점 대신 클라이언트의 관점에서 가장 짧은 IGP 메트릭을 사용하여 수행됩니다.
BGP-ORR을 활성화하려면 [edit protocols bgp group group-name] 계층 수준에서 optimal-route-reflection명령문을 포함하십시오.
동일하거나 유사한 IGP 토폴로지를 공유하는 클라이언트 그룹은 하나의 BGP 피어 그룹으로 묶을 수 있습니다. optimal-route-reflection을 구성하면 해당 BGP 피어 그룹에서 BGP-ORR을 활성화하실 수 있습니다.
BGP-ORR을 구성하려면,
다음 CLI 명령을 사용하여 BGP-ORR 구성을 모니터링하고 문제를 해결합니다.
show bgp group—BGP-ORR의 기본 및 백업 구성을 봅니다.show isis bgp-orr—IS-IS BGP-ORR 메트릭(RIB)을 봅니다.show ospf bgp-orr—OSPF BGP-ORR 메트릭(RIB)을 봅니다.show ospf route—OSPF 라우팅 테이블의 항목을 봅니다.show route—라우팅 테이블의 활성 항목을 봅니다.show route advertising protocol bgp peer—BGP-ORR 규칙에 따라 경로가 보급되고 있는지 확인합니다.
참조
BGP Route Server 개요
BGP route server는 네트워크에서 필요한 직접 point-to-point EBGP 세션 수를 단순화하는 내부 IBGP(IBGP) 경로 리플렉터에 해당하는 외부 BGP(EBGP)입니다. EBGP route server는 BGP 속성 전파 측면에서 투명하므로 route server에서 수신한 경로는 해당 경로가 직접 연결된 EBGP 피어에서 오는 경우 BGP 속성 집합(NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP, Communities)을 전달합니다.
IBGP 경로 리플렉터와 마찬가지로 EBGP route server는 route server 기능을 사용하여 EBGP 피어 사이에서 직접 전달된 경로 외부에 있는 네트워크에 연결됩니다. 이 연결은 직접적인 물리적 링크, VPLS LAN이나 EVPN과 같은 레이어 2 네트워크, 피어의 루프백 주소 연결성을 제공하는 point-to-point EBGP IP 패브릭을 통해 제공될 수 있습니다(일반적으로 데이터 센터 네트워크).
BGP 프로토콜은 RFC 7947에 설명된 다음 기능을 통해 route-server 기능을 제공하도록 향상되었습니다.
NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP, Communities에 대한 속성 투명성
경로 숨김 완화를 위한 클라이언트별 정책 제어와 다중 route-server RIB
BGP 프로그래밍 기능은 route-server 기능을 활용합니다. BGP JET bgp_route_service.proto API는 다음과 같이 route server 기능을 지원하도록 향상되었습니다.
EBGP route server를 프로그래밍합니다.
클라이언트별 RIB에서 클라이언트 그룹에 선택적으로 보급하기 위해 특정 route server RIB에 경로를 삽입합니다.
BGP JET bgp_route_service.proto API에는 개별 경로를 EBGP 또는 IBGP(기본값)로 식별하는 peer-type 개체가 포함되어 있습니다.
Route server 기능은 일반적으로 address-family에 독립적이지만 특정 BGP 속성 지원은 address-family에 따라 다를 수 있습니다(예: AIGP는 labeled-unicast address-families에만 지원됨). Route server 기능은 모든 EBGP address family에 대해 지원됩니다.
BGP 속성 투명성
Route server에 대한 EBGP 속성 투명성 [RFC7947]은 경로를 전파하는 동안 전환 또는 비전환 속성이 제거되거나 수정되지 않도록 일반 BGP 경로 전파를 수정하여 지원됩니다.
일반 EBGP 동작에 대한 변경 사항은 route-server-client CLI 구성에 의해 제어됩니다. [edit protocols bgp group group-name] 계층 수준의 route-server-client CLI 구성은 route server BGP 속성의 투명성 동작을 구현합니다.
Route server는 단일 홉 EBGP 및 다중 홉 구성 모두에 대해 속성 투명성을 제공합니다. 따라서
route-server-client구성에는 단일 홉 및 다중 홉 세션에 대한no-nexthop-change기능이 암시적으로 포함됩니다. 다중 홉 BGP 세션의 경우,multihop키워드를 구성해야 합니다.route-server-client은(는) [edit protocol bgp] 계층의 프로토콜, 그룹 또는 neighbor 수준에서 구성할 수 있습니다.route-server-client구성은 그룹 유형이 external인 경우에만 적용할 수 있습니다.route-server-client이(가) internal 그룹에 대해 구성된 경우 commit을 시도하면 구성 오류가 발생합니다.route-server-client구성은 매개 변수가 없습니다.일반 BGP 권한은
route-server-client구성에 적용됩니다.
속성은 속성 투명성과 관련하여 독립적으로 처리됩니다. 다음 홉을 route-server로 수정하지 않은 상태로 보낼 수 없더라도 다른 속성은 해당 속성에 적용 가능한 대로 투명하게 전송됩니다.
다음은 샘플 route-server-client 구성입니다.
[edit]
protocols {
bgp {
group R0 {
type external;
route-server-client;
family inet {
unicast;
}
peer-as 100;
neighbor 10.0.0.1;
}
}
}
다음 홉
정책을 명시적으로 구성하지 않는 한 다음 홉 자체를 부과하거나 해당 다음 홉을 수정하여 다음 홉 속성은 수정해서는 안 됩니다. Route server는 RFC 4271의 타사 다음 홉 규칙에 따라 BGP 다음 홉을 전파해야 합니다.
다음 홉 동작은 다음 route-server 시나리오에 대해 지정됩니다.
LAN과 WAN 상호 연결의 경우, route server가 공유 LAN 및 WAN 서브넷을 통해 클라이언트 피어에 연결되면 수신된 타사 다음 홉이 RFC 4271에 정의된 대로 수정 없이 route server에 의해 보급됩니다.
데이터 센터 다중 홉 상호 연결의 경우, route server가 다중 홉 상호 연결을 통해 클라이언트 피어에 연결되면 EBGP 다중 홉을 구성해야 하며
no-nexthop-changeCLI 구성의 동작은route-server-client구성에 의해 암시적으로 부과됩니다. 수신된 타사 다음 홉은 RFC 4271에 정의된 선택적 타사 동작에 따라 수정 없이 route server에 의해 보급됩니다.Route server와 클라이언트 피어 간의 point-to-point single-hop 연결과 같은 다른 경우에는, BGP 피어에서 거부할 수 있는 다음 홉 보급 방지를 위해 일반적인 다음 홉 보급 절차가 사용됩니다(예를 들어, 대부분 BGP 구현은 기본적으로 non-multipoint 세션의 서브넷 주소로 적용되지 않는 다음 홉 주소를 거부함).
AS-Path
AS-Path는 route server의 로컬 AS 번호 앞에 붙여 수정해서는 안 됩니다. 피어에 route-server-client CLI를 구성하면 보급 시 로컬 AS 번호가 추가되지 않습니다. 또한 show route advertising-protocol bgp peer CLI 명령은 route server 클라이언트인 피어에 대해 변경되어 보급된 메트릭에 로컬 AS가 표시되지 않습니다.
기타 속성
MULTI_EXIT_DISC 속성(선택적, 비전환)은 수신된 대로 전파되어야 합니다.
no-advertise, no-내보내기, non-transitive extended communities를 포함한 모든 community 속성은 수신된 대로 전파되어야 합니다.
AIGP(Accumulated IGP) 속성(선택적, 비전환)은 수신된 대로 전파되어야 합니다.
주:Junos OS는 BGP-LU address family(IPv4 및 IPv6)에 대해서만 AIGP를 지원합니다.
BGP route server 클라이언트 RIB
Route server 클라이언트별 RIB는 다른 보기와 동일한 목적지에 대해 다른 경로를 포함할 수 있는 BGP Loc-RIB의 전용 보기입니다. Route server 클라이언트는 해당 피어 그룹을 통해 하나의 개별 클라이언트별 보기 또는 공유된 공통 RIB와 연결할 수 있습니다.
동일한 목적지에 대해 다른 클라이언트에 다른 경로를 보급하는 기능을 제공하려면, 개념적으로 BGP 경로 선택의 여러 인스턴스가 동일한 목적지에 대해 발생하지만 다른 클라이언트/그룹 컨텍스트에서 허용되어야 합니다.
클라이언트/그룹별 경로 선택으로 유연한 정책 제어라는 높은 수준의 요건을 구현하기 위해 BGP route server는 NFIs(non-forwarding routing instances)를 사용하여 BGP 경로 선택, Loc-RIB, 정책을 포함한 BGP 파이프라인을 다중 인스턴스화하는 접근 방식을 취합니다. Route server는 별도의 NFIs 내에 구성된 BGP 그룹에서 route server 클라이언트를 그룹화하도록 구성됩니다. 이 접근 방식은 라우팅 인스턴스 내에서 실행되는 BGP가 경로 선택을 수행하고 다른 라우팅 인스턴스에서 실행되는 BGP와 별도의 RIB를 갖는다는 사실을 활용합니다.
정책 요구 사항 및 고려 사항
Route server 클라이언트 간에 경로를 전파하기 위해 구성된 정책을 기반으로 라우팅 인스턴스의 RIB 간에 경로가 누출됩니다.
정책 제어를 위한 route server 구성에는 다음 고려 사항이 포함됩니다.
동일한 Loc-RIB 보기를 수신하려면 동일한 기본 인스턴스 또는 routing-instance 내에서 route server 클라이언트를 구성해야 합니다.
Route server 클라이언트는 완전히 고유한 Loc-RIB 보기를 수신하도록 자체 routing-instance 내에서 구성되어야 합니다.
동일한 Loc-RIB 보기에서 다른 내보내기 정책을 가지려면 동일한 routing-instance의 다른 BGP 피어 그룹에서 route server 클라이언트를 구성해야 합니다.
Route server 클라이언트별 RIB 보기가 기본적으로 다른 테이블의 모든 경로를 수신하도록 하려면
instance-import정책의 full-mesh가instance-any으로 구성됩니다.instance-any을(를) 포함하는 정책으로instance-import을(를) 구성할 때:instance-any은 다음에서 사용될 수 있습니다.policy-statement ... term ... frompolicy-statement ... frompolicy-statement ... term ... topolicy-statement ... to
instance-any에는 매개 변수가 없습니다.instance-import이외의 정책에서instance-any을 사용하면 효과가 없습니다.
많은 고유한 routing-instance와 peer-group을 구성하면 규모와 성능에 영향을 줍니다.
[
edit protocols bgp group neighbor] 계층 수준의 BGPforwarding-contextCLI 구성은 BGP neighbor에 대한 라우팅 인스턴스를 구성 인스턴스와 포워딩 인스턴스로 분할합니다. BGPforwarding-contextCLI 구성은 BGP 피어가route-server-client로 구성된 non-forwarding 인스턴스를 지원합니다. 여기서 지정한 인스턴스는 no-forwarding 유형이 아닌 기본 또는 routing-instance를 포워딩할 수 있는 모든 인스턴스입니다.
참조
변경 내역 표
기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. Feature Explorer 를 사용하여 플랫폼에서 기능이 지원되는지 확인하세요.
no-install 문은 routing protocols daemon(rpd)과 kernel 또는 distributed firewall daemon(dfwd)과 같은 Junos 시스템의 기타 요소 간에 상호 작용을 제거합니다.