라벨 대 경로 매핑, 라벨 생성 확장 성

MPLS 사용 라우터에서 라우팅 테이블의 대상 접두사 당 고유 레이블이 생성되거나 라우팅 테이블의 다음 홉당 레이블이 고유하지 않은 경우 고유 레이블과 라우팅 테이블 항목 간의 매핑은 어떻습니까? 또한 대상 접두사 당인 경우 얼마나 잘 맞습니까? 내 이해에 따라 최대 레이블 값은 2 ^ 20 = 1048576입니다. 라우팅 테이블 항목의 수가 1048576보다 크면 어떻게됩니까?

— 헤만 스
소스

누군가가 1 백만 LFIB 항목에 접근하는 시나리오를보고 있다고 진지하게 제안하고 있습니까, 아니면 이것이 이론적 인 질문입니까?

— Mike Pennington

현재 L3과 함께 일하고 있으며 Edge 라우터에서 백만 개의 경로 (전체 인터넷 경로)에 접근하는 고객 시나리오를 보았습니다. 그러나 50 만에 가까운 총 출품작 수를 보았습니다.

— Hemanth

얼마나 많은 IGP 경로 + RSVP-TE 레이블? 모든 인터넷 경로에 레이블을 바인딩하는 것은 나쁜 디자인입니다. IGP 테이블의 모든 BGP 다음 홉에만 레이블을 바인딩해야합니다.

— Mike Pennington

BGP 다음 홉마다 레이블을 바인딩하는 것이 좋습니다. 그러나 MPLS에는 레이블 생성에 대한 일반적인 지침이 없습니다. 대상 접두사 또는 다음 홉마다 고유 레이블을 생성해야한다는 일반적인 규칙이 없습니까? 아니면 구현에 따라 다릅니다.

— Hemanth

어떤 대답이 도움이 되었습니까? 그렇다면 질문에 대한 답변이 계속 나오지 않도록 답변을 수락해야합니다. 또는 자신의 답변을 제공하고 수락 할 수 있습니다.

— Ron Maupin

답변:

라우팅 테이블에서 대상 접두사 당 고유 레이블이 생성됩니까? 또는 라우팅 테이블에서 다음 홉당 고유 레이블입니까? ... 고객 시나리오가 백만 개의 경로에 접근하는 것을 보았습니다 ... 그러나 MPLS에는 레이블 생성에 대한 일반적인 지침이 없습니다. 대상 접두사 또는 다음 홉마다 고유 레이블을 생성해야한다는 일반적인 규칙이 없습니까? 아니면 구현에만 한정됩니까?

약간 혼란스러운 것 같습니다. 인터넷 경로마다 고유 한 레이블을 할당하려는 사람은 거의 없습니다. 잘 설계된 MPLS 네트워크는 BGP 다음 홉에 바인딩 된 IGP 접두사를 기반으로 레이블을 할당해야합니다 ( RFC 3031, 섹션 4.6 참조 ).

따라서 LFIB의 1 백만 레이블이 오늘날 심각한 MPLS 설계 제약 조건인지 확실하지 않습니다.

— 마이크 페닝 턴
소스

rfc3031 section4.6에 따라 모든 코어 라우터는 igp 접두사에 lable을 할당합니다. 그러나 BGP는 BGP 피어에게 보내는 각 경로 (BGp 경로)에 고유 한 레이블을 할당합니다. 그러나 여기서 BGP는 수천 개의 경로를 올바르게 알릴 수 있습니까? BGP 경로 수가 2 ^ 20을 초과하면 어떻게됩니까?

— Hemanth

@Saran은 옳습니다 .RFC4364, 옵션 b와 같은 시나리오에서 레이블이 부족한 것으로 생각됩니다. 새로운 라벨이 필요한 NLRI를 광고 할 수 없습니다. 파 엔드 PE가 다음 홉에 동일한 홉을 갖는 한, 접두사에 대해 레이블을 공유 할 수있는 한 오히려 기술적으로는 불가능하다고 생각합니다. opt-B는 모든 IGP, VPN 레이블을 단일 레이블로 축소해야하기 때문에 이러한 상황이 발생할 수있는 시나리오를 상상하기는 쉽지만 나에게는 가능성이 거의 없습니다.

— ytti

@Saran은 언급 한 시나리오에서 inter-AS MPLS VPN 입니다. 원래 질문에서 묻는 간단한 BGP 라우팅은 기본적으로 BGP 경로에 레이블을 할당하지 않습니다. 모든 MPLS VPN 시나리오에는 VPNv4에서 배포 한 레이블이 부족할 수 있습니다. 그 시점에서 인터 AS를 실행하지 않는 경우 고객 기반을 별도의 라우터로 분할해야합니다.

— Mike Pennington

옵션 C는 일반 [IGP, VPN] 스택이므로 일반 MPLS처럼 확장됩니다. 그러나 옵션 B는 단지 [label]이며, 결국 ASBR에서 [IGP, VPN]에 매핑해야합니다. 따라서 OptionC에서 VPN 부분은 두 PE에 대해 고유 할 필요는 없지만 OptionB에서는 [IGP, VPN]의 각 조합이 ASBR <-> ASBR 링크를 통해 고유해야합니다.

— ytti

@ytti- "먼저 PE가 다음 홉에 동일한 홉을 가지고있는 한 접두사에 대해 레이블을 공유 할 수있는 한 기술적으로는 불가능할 것 같습니다."레이블을 생성해야하는 엄격한 규칙이 없습니까? 각 PRefix (BGp 접두사)? 전환을 위해 동일한 경로를 따르는 경우 여러 접두사에 대해 하나의 레이블을 공유하는 것이 좋습니다. 그러나 문제는 이것이 어떻게 결정됩니까? 다운 스트림 라우터는 어떤 레이블을 공유 할 경로를 어떻게 알거나 결정합니까? 그냥 다음 홉인가요? 많은 루트가 동일한 nexthop을 공유하는 경우 하나의 레이블 만 부여됩니까?

— Hemanth

라벨이 소진 될 수있는 정확한 실제 시나리오는 논쟁의 여지가 있습니다. 라벨이 다 떨어지지 않고 그 효과에 영향을주는 일부 하우스 키핑 문제도 있습니다.

오늘날 주요 공급 업체 (최소한 CSCO, JNPR)의 라벨 관리자는 라벨 별 연속 애플리케이션이 필요하도록 프로그래밍되어 있습니다. 물론 이것은 약간의 성능 및 복잡성으로 인해 수정 될 수 있지만 고려해야 할 또 다른 문제입니다.

일부 MPLS 서비스는 코어의 레이블 공간에 대해 매우 굶주리고 있습니다. 에지에서 우리는 'IGP 레이블'로 마스크를 숨길 수 있기 때문에 대부분 관련이 없습니다.
우리는 MPLS가 IP에 관한 것이 아니라 FEC에 관한 것임을 기억해야합니다. 코어에 다른 치료 / 경로를 제공해야하는 경우 새로운 FEC가 필요합니다.

구현이 특수 목적 레이블 을 통해 이루어질 가능성이 크지 만 메가 레이블 및 큰 레이블 의 사용 사례 에 대한 논의가 있습니다 . 개인적으로 2 ^ 20이 문제가되기 전에 MPLS 와이어 형식이 변경되기를 바랍니다. MPLS는 주로 하나의 운영자 네트워크 내에서만 사용되므로 IPv4> IPV6 마이그레이션에 비해 유선 형식을 변경하는 것이 매우 쉬우므로 문제가 발생하면이를 해결하는 것은 매우 간단합니다. 해결하고 싶은 몇 가지 문제 :

운송 중에 라벨 이력을 유지하는 기능
낮은 바이트 오버 헤드 (TTL, TC는 스택 레이블에서 중복 됨)
대중 교통 P '덕 타이핑'MPLS 페이로드 불필요 (현재 ECMP 중단)
설계에 따라 확장 가능 (특수 라벨은 바이트 비용이 많이 듭니다)
라벨 공간 증가
MPLSv1과 공존

— 이티
소스