Influencing BGP Route Selection with Weights
BGP 경로 선택 기준
- 더 높은 가중치(local to router)
- 더 높은 local preference(global within AS)
- 보통 여기까지 비교
- 하위 조건까지는 잘 가지 않음
- 라우터에서 시작되는 경로
- 더 짧은 AS 경로(길이만 비교)
- 더 낮은 origin code(IGP < EGP < Incomplete)
- 더 낮은 MED 값
- 내부(IBGP)보다 외부(EBGP) 경로
- IBGP 경로의 경우, 더 가까운 IGP neighbor를 통하는 경로
- EBGP 경로의 경우, 더 오래된 경로
- 더 낮은 BGP Router-ID를 지닌 라우터의 경로
Influencing BGP Route Selection
- BGP 라우팅 정책은 용도에 따라 분류될 수 있음
- Wegiht: local 라우팅 정책을 제공(라우터 내에서)
- Local Preference: AS 범위의 라우팅 정책 제공
- BGP Weight는 neighbor 단위로 정의
- Default weight: 아무것도 설정하지 않으면 0
- AS-path-based weight
- Complex criteria with route-maps
Configuring Per-neighbor Weights
- 위의 명령어는 default weight를 설정하는 명령어
- 모든 BGP neighbor로부터 온 경로들은 특정한 Weight를 얻음
- 더 높은 weight의 BGP 경로를 우선
- Weight는 새로운 수신 업데이트 정보로만 반영됨
- 따라서 새로운 weight를 올리기 위해서는 BGP 세션을 다시 맺어야 함
- clear ip bgp 명령어 사용
- weight도 우선 순위를 결정하는 데에 중요하지만, 실질적으로 prefix가 가장 우선시
- Primary와 Backup을 설정하려면 BGP를 쓰지 말고, Default Route를 추천
- 경로의 weight 확인
- 경로 선택 과정에서 local preference가 참조 1순위이고, weight는 있어도 잘 사용하지 않음
Setting BGP Local Preference
Consistent Route Selection Within the AS
- AS 213 내부에서 사용해야 하는 프로토콜
- IBGP
- AS 213의 라우터에서 각 라우터들이 더 빠른 경로를 선택하도록 수정할 사항
- IBGP와 EBGP 세션에서 weight 값을 조정
- weight 값 조정
- 트래픽이 가장 빠른 회선으로 이동
- 하지만 이때 주로 사용하던 회선이 Down 되었을 경우, 차선책은 다음으로 큰 weight의 경로로 설정되지 않음
BGP Local Prefernce
- Local Preference를 통해 AS 범위의 경로 선택 정책을 설정할 수 있음
- Cisco 장비에서 경로 선택 과정은 Local Preference를 1순위로 참조한다고 보면 됨
- 이때 Weight 값은 전부 동일
- AS 범위의 경로 선택을 보장하기 위해
- AS 내의 local preference를 변경하지 말 것
- BGP Weight를 사용하지 말 것
- 라우터마다 default local preference가 설정됨
- Local preference는 route-map에 의해 변경될 수 있음
Configuring Default Local Preference
- Default Local Preference 값을 변경하는 명령어
Configuring Local Preference with Route-Maps
- Route-map과 match되는 경로에 대해서만 BGP local preference 변경
- 특정 neighbor로부터 들어오는 업데이트 정보나 특정 neighbor를 향해 나가는 업데이트 정보에 route-map 적용
LAB
토폴로지
- R3 to R2로 Local Preference를 200으로 선언
- R2는 Weight값을 사용하지 않도록 설정
- weight 0으로 설정
해설
- R2, R3에서 고객 네트워크(R1)로 Static
- R3 Static에서 AD 값을 250으로 설정
- 이렇게 하면 BGP의 AD가 200이기 때문에 라우팅 테이블에는 BGP가 내려가게 됨
- R1-R2 경로가 죽으면 R2-R3 BGP 경로 역시 사라지게 되고, Static이 BGP 경로 정보로 홍보됨
- 이후 다시 R1-R2 경로가 살아났을 때, R2-R3 경로는 여전히 Static BGP 경로가 홍보됨
- 이유는 Static으로 홍보하게 되면 weight 값이 32768이 되기 때문에 가중치 문제로 경로 홍보 순서가 꼬이게 됨
- 위의 문제를 해결하기 위해서 route-map을 사용
- R3: network 홍보를 할 때, weight를 0으로 설정
Using AS-Path Prepending
AS-Path Prepending
- AS-Path length의 수동 조작은 AS-Path Prepending이라고 함
- AS-Path는 송신자의 AS 번호를 여러번 복사하여 확장되어야 함
- AS-Path Prepending은 다음과 같은 경우에 사용
- 올바른 return 경로 선택
- multihomed 고객들을 위한 return traffic 재분배
AS-Path Prepending Design Consideration
- Required prepended AS-path length를 계산하는 데에 구체적인 메커니즘은 없음
- Primary와 Backup 시나리오
- Primary AS path는 늘 더 짧은 AS Path를 보장해야 함
- 긴 Backup AS path는 모든 인터넷 라우터의 메모리를 소비
- Backup link가 idle 상태인 동안, 다양한 AS-Path 길이를 탐색
- Traffic load 재분배
- 짧은 Prepended AS Path로 시작
Configuring AS-Path Prepending
- route-map에 match되는 정의된 AS 번호 Sequence Prepend
- AS 번호는 BGP 테이블의 AS path 경로에 prepend됨
- 설정이 되었는가 확인하기 위해서는 상대방 라우터에서의 BGP 설정 값을 봐야 함
BGP Hide Local-Autonomous System Feature
- 전체 BGP 네트워크의 AS 번호를 변경하도록 허용
- 경로가 AS 전체에 전파될 수 있도록 보장
- no prepend
- 수신하는 데이터에 local AS 번호를 추가하지 않겠다는 설정
Understanding BGP Multi-Exit Discriminators
Multi-Exit Discriminator
- MED 자체로 Path Selection을 할 수는 있음
- AS Path가 Null 상태가 아니면 전달 과정에서 MED 값이 사라짐
- MED 속성의 Default 값은 0
- 실제로 Default 값이라는 개념이 확실하게 잡힌 건 아님
Default MED Config
Addressing BGP Communities
BGP Communities
- BGP Communities는 경로 선택 정책 또는 필터링 유지를 보장하도록 경로에 Tagging 하는 것을 의미
- 어떠한 BGP 라우터라도 재분배를 실시할 때나 업데이트 정보를 받고 내보내는 과정에서 경로에 태그할 수 있음
- 기본적으로, communities는 전송되는 BGP 업데이트에 묶여있음
- Community 속성은 전송 가능한 선택적 속성
- 32-bit 숫자로 구성되어 있음
- 0-4,294,967,200의 값 중 하나
- BGP 라우팅 테이블에 있는 각 네트워크는 커뮤니티 설정 값으로 tag 될 수 있음
- 필터 중점의 communities
- no-advertise: 어떠한 peer로든 경로를 홍보하지 말라는 의미
- no-export: 실제 EBGP peer로 경로를 홍보하지 말라는 의미
- local-as: 어떠한 EBGP peer로든 경로를 홍보하지 말라는 의미
- internet: Internet Community로 해당 경로를 홍보하라는 의미
- Communities를 지원하지 않는 라우터는 Community 값을 변경하지 않고 그대로 통과시킴
- 32-bit의 커뮤니티 값은 두 파트로 나누어짐
- 커뮤니티의 의미를 정의하는 AS의 AS 번호를 포함한 높은 차수의 16 bits
- local의 핵심 정보를 담고 있는 낮은 차수의 16 bits
- 높은 16 차수의 0과 1의 값들은 미리 정해져 있음
- Cisco IOS는 32-bit 커뮤니티 값을 다음과 같이 설정할 수 있도록 허용함
Using Communities
- 관리 정책 목표 정의
- 관리 목적을 달성하기 위한 필터와 경로 선택 정책 설계
- 개별 목적을 알리는 커뮤니티 정의
- 진입 지점에 경로 태깅을 구성하거나 BGP neighbor들이 겨올에 태그하도록 구성
- 커뮤니티 재분배 구성
- 커뮤니티에 기초한 경로 필터와 경로 선택 파라미터 구성
- 관리 정책
Configuring Route Tagging with BGP Communities
- 라우트 맵과 함께 커뮤니티에 대한 경로 태깅을 완수해야 함
- 커뮤니티 번호는 어떤 번호는 어떤 것으로든 설정 가능
- set 키워드로 커뮤니티를 설정하고 덮어쓰기 함
- 단, option에 additive가 붙으면 덮어쓰기가 아니라 추가됨
Configuring Community Propagation
- 기본적으로, 커뮤니티는 전송되는 BGP 업데이트 정보에 담겨있음
- BGP neighbor에게 수동으로 커뮤니티를 홍보해야 함
- BGP peer Group은 많은 숫자의 neighbor로 BGP 커뮤니티 홍보를 구성할 때 가장 이상적임
BGP Community-List 설정
- extended community list 설정 명령어
- simple community-list와 유사하지만, extended 버전은 regular expression 기반으로 match 작업 실시
- .* 값은 모든 커뮤니티 값을 match 하는 데에 사용
Route Reflectors
IBGP Scalability Issues in a Transit AS
- Route Reflectors는 IBGP split-horizon 규칙을 정의
Route Reflectors Split-Horizon Rules
- IBGP로 받은 정보를 IBGP로 넘길 수 있는 객체
- Route Reflector는 임의의 라우터를 Client로 지정
- Client Router로부터 IBGP로 받은 정보를 자신이 직접 EBGP로 받은 것으로 가정하여 다른 모든 Client/Non-Client Router로 전달
- Non-Client Router로부터 IBGP로 받은 정보는 Client에게는 전달하지만 Non-Client에게는 전달하지는 않음
- Client를 잘못 맺으면 Loop 발생
- Root Reflector끼리만 full mesh 형성
- 나머지 Client/Non-Client끼리는 full mesh 형성하지 않음
Route Reflector Clusters
- Cluster-ID
- 그룹 내에서 Reflector를 이중화하여 생성
- 각 Cluster는 고유한 Cluster-ID를 지녀야 함
- 경로가 Reflect 될 때마다 Cluster-list BGP 속성에 Cluster-ID가 추가됨(AS Path와 유사)
- 자신과 같은 Cluster-ID로부터 정보를 받으면, 라우터 자체적으로 Packet Drop(Reflect하지 않음)
Additional Route Reflector Loop-Prevention Mechanisms
- 경로가 reflect 되는 모든 순간마다, originating IBGP 라우터의 Router-ID는 originator-ID BGP 속성에 저장됨
- 특정 라우터가 자신의 Router-ID값이 originator-ID로 설정된 IBGP 경로를 받았을 경우, 해당 경로를 무시
- BGP 경로 선택 절차는 cluster-list와 originator-ID를 고려하도록 정의
Designing Networks with Route Reflectors
Network Design with Route Reflectors
-
Route reflector 규칙
- Route reflector 규칙은 transit AS를 더 작은 영역으로 나눔
- 위의 영역들을 cluster라고 함
- 각 cluster는 route reflector와 client를 포함하고 있음
- Route reflector 규칙은 transit AS를 더 작은 영역으로 나눔
-
IBGP 세션 규칙
- 클러스터 내의 모든 client는 route reflector 또는 route reflector들과 IBGP 세션을 반드시 형성해야 함
- AS 내의 모든 route reflector 사이의 IBGP full mesh는 필수적
- route reflector가 아닌 라우터는 IBGP full mesh에 포함되거나 route reflector client가 될 수 있음
Configuring Route Reflectors
- 클러스터 설정 값은 위의 두 줄이 끝
- Client는 자신이 Client인지 모름
- Client 역할이 될 라우터에는 입력할 설정 명령어가 없다는 의미
Introducing Confederations
AS-Path Propagation Within the BGP Confederation
- IBGP Session
- AS 경로는 변하지 않음
- Intra-confederation EBGP session
- intra-confederation AS 번호가 AS 경로에 prepend됨
- 외부 peer와 EBGP session
- AS 경로에서 Intra-confederation AS 번호가 사라짐
- 외부 AS 번호가 AS 경로에 prepend됨
AS-Path Processing in BGP Confederation
- Intra-confederation AS 경로는 AS 경로의 분리된 세그먼트로 인코딩됨
- BGP confederation 내의 모든 라우터는 BGP Confederation을 지원해야 함
- BGP Confederation을 지원하지 않는 라우터는 알 수 없는 AS 경로를 거절할 것
Intra-confederation EBGP Session Properties
- 세션이 구성되어 있는 동안 EBGP 세션처럼 동작
- EBGP neighbor는 직접 연결되어야 함
- 아니면 neighbor에서 ebgp-multihop을 구성해야 함
- 라우팅 업데이트를 홍보할 때는 IBGP 세션처럼 동작
- local preference, MED, next-hop 속성이 유지됨
- 모든 confederation은 하나의 IGP를 실행할 수 있고, BGP 라우팅 테이블의 next-hop 속성을 기반으로 최적의 라우팅을 제공
Configuring and Monitoring Confederations
BGP Confederation Design Rules
- 각 member-AS 내에서 IBGP full mash가 필요
- Route Reflector들은 각 AS에서 IBGP full mesh 요건을 완화하는 데에 사용될 수 있음
- Confederation 내에서 AS 간 EBGP 세션에 토폴로지 한계치가 없음
- Intra-confederation EBGP 세션은 네트워크의 물리적 토폴로지를 따를 것
Planning BGP Confederation
- AS를 더 작은 영역으로 나눔
- 네트워크의 물리적 토폴로지에 따라
- 각 영역마다 AS 번호 정의
- 사설 용도의 AS 번호 사용(64512-65535)
- Cisco IOS release level을 인증
- 모든 라우터는 BGP confederation을 지원해야 함
- 각 영역을 AS로 변환
- 모든 BGP Configuration의 수정이 필요함
Configuring BGP Confederations
- member-AS 번호로 BGP 과정 시작
- 외부 AS 번호를 정의
- confederation 내의 모든 라우터에서 정의되어야 함
- Confederation 내의 모든 member-AS 번호를 기록
- EBGP 세션의 모든 라우터에서 정의되어야 함
- 기존의 BGP 프로세스를 제거하고 member-AS 번호로 새로운 BGP 프로세스 configure
- 외부 confederation 범위의 AS 번호를 configure
- Confederation에서 모든 AS 정의
- BGP Confederation sample Configuration
