메트로 이더넷을 통해 OSPF를 배포하는 것이 합리적입니까?

고객을 위해 여러 지점 사이트를 서로 연결해야하는 경우 일반적으로 신뢰할 수있는 통신 업체를 통해 MPLS VPN을 권장합니다. 각 사이트의 CE는 업스트림 PE로 BGP와 통신하며 각 사이트에는 자체 개인 ASN이 있습니다. BGP는 무수한 교통 공학 도구를 제공하고 인접 사이트는 n 개 사이트에 대해 n + 1 (콜로 환경 +1)로 제한되므로 이는 매우 편리합니다.

그러나 최근 메트로 이더넷 솔루션에 대한 고객의 관심이 높아지고 있습니다. 많은 고객이 공통 대도시 지역 내에 지점을 가지고 있으며 MetroE 견적은 동일한 속도의 회로에 대해 MPLS 서비스보다 수백 달러 (USD) 미만으로 제공됩니다. 이것이 매력적이지만 메쉬 토폴로지를 허브 앤 스포크로 바꾸지 않으면 서 레이어 2 백본을 통해 라우팅을 설정하는 방법을 잘 모르겠습니다.

BGP는 메시 연결성을 유지하기 위해 브랜치 사이트간에 전체 인접 네트워크 메시가 필요합니다. 이는 확장 성 관점에서 바람직하지 않습니다. 다른 옵션은 IGP, 즉 OSPF를 배포하고 모든 사이트가 WAN에서 인접성을 형성하도록하는 것입니다. 과도하게 보이는 것처럼 각 사이트를 자체 영역으로 지정하고 싶지만 각 사이트에서 광고 된 경로를 요약하는 기능을 유지하고 싶습니다. 이것은 영역 경계에서만 수행 할 수 있습니다.

이게 말이 되요? 이러한 방식으로 OSPF를 배포 할 때주의해야 할 사항이 있습니까 (예 : LSA 플러딩 사용 중지를 고려해야 하는가)? 아니면 내가 간과 한 다른 솔루션이 있습니까?

서로 다른 두 제품이 매우 다르기 때문에 이것은 복잡한 질문입니다. MPLS L3VPN 회로는 본질적으로 참여하는 모든 위치 간의 풀 메시이며, MetroE 연결은 일반적으로 두 특정 사이트 사이의 지점 간 링크입니다.

필자의 경험에 따르면 MetroE 회로는 보호 경로와 계약하지 않는 한 보호 서비스가없는 직접 프로비저닝 된 경로입니다. 즉, 특정 경로를 따라 인터페이스 나 라우터에 장애가 발생하면 MetroE 서비스로 직접 연결된 두 사이트간에 트래픽이 중단 될 수 있습니다. MPLS L3VPN은 인터페이스 / 라우팅 실패를 해결하여 사이트간에 완전한 메시를 유지합니다. 이것은 일반적으로 둘 사이의 가격 차이를 설명합니다.

MetroE 플랫폼을 기반으로 고유 한 서비스를 구축하는 데 아무런 문제가 없습니다. 고객 요구 사항에 따라 적절한 라우팅 유형을 결정하면됩니다. 소규모 사무실 네트워크를 사용하는 경우 OSPF / IS-IS / EIGRP를 사용하면 직접 연결된 사이트간에 라우팅 정보를 교환 할 수 있습니다. NSP / ISP / * SP를 더 많이 사용하는 경우 IGP와 EGP간에 인프라와 고객 경로를 분리하면 확장 할 때 훨씬 더 중요해집니다.

ISP 엔지니어로서 MetroE 및 EWAN 링크를 광범위하게 사용하여 백본을 구축하고 물리적 링크에 대한 지식을 활용하여 iBGP / eBGP 환경을 설계합니다. 대부분의 경우 iBGP 피어 수를 줄이기 위해 경로 리플렉터와 이중 경로 리플렉터 (피어링 양쪽의 경로 리플렉터 클라이언트)를 사용합니다. 그러나 POP에서 6 개 이상의 라우터를 다루지 않는 한 iBGP는 확장 성이 뛰어납니다.

요컨대 단일 클라이언트 인 경우 자체 클라이언트에게 네트워크 서비스를 제공하지 않는 경우 IGP를 사용합니다. 장애 조치 / 이중화 등을 통해 사이트간에 외부 연결을 공유해야하는 경우 실제 경로를 면밀히 검토하고이를 반영하도록 eBGP / iBGP를 설계하십시오. AS 외부의 다른 모든 라우터와 iBGP 피어에 대한 사이트 외부 링크가 하나 밖에없는 원격 위치에 라우터를 두지 않아도됩니다. 이중 경로 리플렉터를 사용하십시오.

관리 형 L3VPN (내가 "MPLS VPN"의 의미로 간주)에서 L2VPN으로 전환하는 것은 IP가 아닌 프로토콜을 실행하고 라우팅을 정의하는 라우팅 프로토콜 및 라우팅 플랫폼을 완전히 제어 할 수 있다는 점에서 좋은 단계입니다. 토폴로지.

각 사이트의 CPE 측에 이더넷 MAC 주소를 하나만 배치한다고 가정하면 공급자의 장비가 사이트 당 다수의 서브넷을 배우고 라우팅하는 것보다 사이트 당 1 개의 MAC 주소를 배우고 전달하는 것이 훨씬 간단합니다.

최선의 선택은 트래픽 및 성장 계획에 따라 다르므로 프로토콜 측면에서 보면 더 많은 정보없이 대답하기가 까다로운 질문입니다.

내부 및 인터넷 연결이 필요한 대기업입니까? 아니면 연결도 판매합니까? 그것이 모두 내부적이라고 가정하면 IGP를 배포하고 경로를 알리기 위해 eBGP를 실행할 수 있습니다.

사이트 또는 내부 접두사가 너무 많지 않은 경우 OSPF 또는 IS-IS와 같은 링크 상태 프로토콜이 가장 합리적입니다. 접두사가 몇 개인 경우 신속하게 수렴되고 RIB에서 FIB를 빠르게 작성할 수 있습니다. .

사이트가 많거나 접두사가 많은 경우 각 사이트를 처리해야하므로 라우팅 플랫폼에 세금을 부과하기 시작합니다. 이것은 n ² 시간 이 걸리기 시작하는 것 입니다. 사이트가 자주 올라가거나 내려 오는 경우 링크 상태에서이 변동이 발생하면 라우터 풀에 세금이 부과 될 수 있습니다.

많은 사이트, 많은 허름한 사이트 (하나의 경로 "업스트림", 다른 다운 스트림 라우터가 없음) 또는 많은 루트 이탈이 발생하는 경우 다른 프로토콜이나 토폴로지를 조사해야합니다.

그런 경우에는 일부 경로 리플렉터와 함께 BGP를 사용하는 것이 좋습니다. 이 방법으로 스포크가 발표하고 다른 스포크가 라우팅 테이블을 가져올 수있는 2 개 이상의 중장비 경로 리플렉터를 제공 할 수 있습니다. 이런 방식으로 연결하는 많은 스포크 사이트에 경량 CPE를 배포하고, 공간을 알리고, 라우터에 대한 내부 테이블 또는 기본 경로를 얻을 수 있습니다.

대략, 나는 몇 가지 스케일과 기어를 제안하고 (기가비트 이하의 처리량을 가정 할 때) :

• 1-20 개의 스포크-모든 사이트 간 OSPFv3 모든 사이트에 대해 Juniper SRX240 또는 유사.
• 20-100 개 스포크-경로 반사기가있는 iBGP 스포크의 Juniper SRX240, 경로 반영 (또는 데비안 Linux / BIRD)을위한 Juniper MX5 / 10 / 40 / 80
• 100-500 개의 스포크-다른 L2 네트워크, AS 또는 영역으로 나누기 시작

BGP 토론에 일반적으로 간과되는 두 가지 비트를 추가하기 만하면됩니다.

• iBGP를 실행하는 경우 일반적으로 BGP 다음 홉간에 연결을 설정하려면 다른 라우팅 프로토콜이 필요합니다. 설계 관점에서 iBGP는 라우팅 프로토콜보다 확장 성 도구입니다.
• eBGP를 실행하는 경우 최적의 엔드 투 엔드 트래픽 흐름을 위해 전체 BGP 세션 메시가 필요하지 않습니다. BGP 다음 홉 처리는 이러한 문제를 훌륭하게 해결합니다.

자세한 내용은 http://blog.ioshints.info/2011/08/bgp-next-hop-processing.html 을 참조하십시오

멀티 포인트 메트로 이더넷 서비스에서 OSPF (또는 다른 IGP)를 제대로 실행할 수 있으며 매우 훌륭하게 작동합니다.

BGP를 계속 실행해야하는 이유가있을 수 있지만, 자신의 네트워크 내에서 BGP를 실행하려는 이유와 거의 같은 주장이 될 수 있습니다.

BGP 스피커를 모두 같은 AS에 "브로드 캐스트"네트워크에 배치 할 필요는 없습니다. 개인 AS가 레이어 2 메시를 통해 서로 연결할 수있는 통신에서 실행되는 일종의 내부 IXP로 생각하십시오. BGP 업데이트가 피어 세션이 시작되는 위치와 동일하지 않은 업데이트 메시지에 다음 홉을 전달할 수 있으므로 BGP 피어링의 전체 메시를 반드시 유지할 필요는 없습니다.

예를 들어 라우터 A, B 및 C가있는 레이어 2 메시가 있고 A와 B 사이, B와 C 사이에 BGP 피어가있는 경우 C가 A에서 시작된 경로에 대한 업데이트를받을 때 B와의 피어링 세션을 통해 학습 되었음에도 불구하고 A를 다음 홉으로 사용하십시오. 분명히 단일 허브 앤 스포크보다 더 많은 경로 피어링을 원할 것이므로 단일 허브에 의존하지 않지만 어떤 방법으로도 전체 메쉬가 필요하지 않습니다.

이 방법으로 BGP를 실행하면 라우팅 정책의 이점을 얻을 수 있습니다. 또한 다른 응답자가 언급 한 것처럼 동일한 개인 AS 번호 공간을 사용할 수 있으며 기존 L3VPN과 상호 연결하여 모델 및 지원 메커니즘은 변경할 필요가 없습니다.

즉, OSPF와 iBGP를 실행하는 두 개의 메트로 E 링크 (필자의 경우 지점 간)가 있으며 제대로 작동합니다.

허브 / 메인 라우터의 rs- 클라이언트 인 '스포크'를 사용하는 경로 서버 구성은 어떻습니까?

bgp 피어링은 허브 및 스포크 토폴로지와 비슷하지만 모든 스포크는 다른 모든 트래픽을 직접 전송할 수 있어야합니다.

서비스에서 다른 서비스로 쉽게 마이그레이션하기 위해 MPLS 제공자와 함께 사용 된 것과 동일한 개인 AS 번호를 재사용 할 수도 있습니다.

표준 대신 NBMA로 시작하는 것과 같은 대체 OSPF 토폴로지에 대해 읽고 결정하는 것이 좋습니다. 아웃 바운드 인터페이스를 통해 비용이 계산되는 방식 때문에 OSPF가 동일한 메트로 이더넷 내에서 동일한 라우터 / 사이트로가는 두 경로 중에서 올바르게 선택할 수있는 방법이 없다는 것을 곧 알게 될 것입니다. 메인 및 백업 WAN 링크는 동일하게 나타납니다. 표준 OSPF의 비용. 그러나 예를 들어 NBMA를 사용하기로 선택한 경우 인접 비용을 수동으로 정의 할 수 있지만 이제 메쉬 / 인접성을 수동으로 정의해야합니다.

당신이 무엇을 하든지간에, 반복하지 마십시오. 레이어 2에 참여하지 마십시오. 나중에 레이어 2 상호 연결이 필요한 경우 레이어 3 기능보다 OTV 또는 다른 레이어 2를 사용하면 문제가 발생합니다.

WAN 코어가 숨겨져있는 단순한 공급자 MPLS-VPN과 비교할 때 OSPF에 대해 더 많이 배우고 더 많이 알아야한다는 사실을 빠르게 알게 될 것입니다.

metroE를 통한 OSPF는 잘 작동하지만 필요에 맞게 설계하고 그에 따라 설계해야합니다. 내가 언급하지 않은 한 가지주의 할 점은 공급자가 지원하는 MTU를 알고 있는지 확인하는 것입니다. 제공자 유지 보수 중 metroE 링크에서 MTU가 하락하여 OSPF 이웃이 나타나지 않는 것을 보았습니다. 그들은 실제로 점보 프레임을 지원하지 않기 때문에 문제 일 것입니다. 그러나 그들은 우리를 위해했습니다.