Czy warto wdrożyć OSPF w sieci Metro Ethernet?

Kiedy muszę połączyć kilka oddziałów ze sobą dla klienta, zazwyczaj polecam VPN MPLS za pośrednictwem zaufanego operatora. CE w każdym miejscu mówi BGP ze swoim wcześniejszym PE, a każde miejsce jest ponumerowane własnym prywatnym ASN. Jest to dla nas bardzo wygodne, ponieważ BGP zapewnia niezliczone narzędzia inżynierii ruchu, a nasze sąsiedztwa są ograniczone do n + 1 dla n witryn (+1 to nasze środowisko colo).

Ostatnio zauważyłem jednak rosnące zainteresowanie klientów rozwiązaniami Metro Ethernet. Wielu naszych klientów ma oddziały we wspólnym obszarze metra, a oferty MetroE są o kilkaset dolarów (USD) niższe niż usługi MPLS dla obwodów o tej samej prędkości. Chociaż jest to atrakcyjne, nie jestem pewien, jak najlepiej ustanowić routing przez szkielet drugiej warstwy, unikając przy tym zamiany topologii siatki w hub-and-mówił.

BGP wymagałby pełnej siatki przyległości między oddziałami w celu utrzymania łączności z siecią, co oczywiście jest niepożądane z punktu widzenia skalowalności. Inną opcją jest wdrożenie IGP, a mianowicie OSPF, i wszystkie witryny tworzą sąsiedztwa w sieci WAN. Chciałbym zająć się każdą witryną jako własnym obszarem, co wydaje się przesadą, ale chcę zachować możliwość podsumowywania tras reklamowanych z każdej witryny, a można to zrobić tylko na granicach obszaru.

Czy to ma sens? Czy są jakieś zastrzeżenia, na które należy zwrócić uwagę podczas wdrażania OSPF w ten sposób (na przykład, czy powinienem rozważyć wyłączenie zalewania LSA)? A może istnieje inne rozwiązanie, które przeoczyłem?

Jest to dość złożone pytanie, ponieważ dwa różne produkty są bardzo różne. Obwód MPLS L3VPN z natury jest pełną siatką między wszystkimi lokacjami, które uczestniczą, podczas gdy połączenie MetroE jest zasadniczo połączeniem punkt-punkt między dwoma konkretnymi lokalizacjami.

Z mojego doświadczenia wynika, że ​​obwód MetroE jest ścieżką zapewnianą bezpośrednio, bez usług ochrony, chyba że jest kontraktowana ze ścieżką ochrony. Oznacza to, że awaria interfejsu lub routera wzdłuż określonej ścieżki spowodowałaby zakłócenia ruchu między dwiema stronami, które są bezpośrednio połączone przez usługę MetroE. MPLS L3VPN leczy awarie interfejsu / routingu, aby zapewnić Ci pełną siatkę między twoimi witrynami. Zasadniczo stanowi to różnicę cen między nimi.

Nie ma nic złego w budowaniu własnych usług na platformie MetroE - wystarczy pracować z wymaganiami klientów, aby ustalić, jaki rodzaj routingu jest odpowiedni. Jeśli pracujesz w małej sieci biurowej, OSPF / IS-IS / EIGRP może być wspaniałym sposobem wymiany informacji o routingu między bezpośrednio połączonymi witrynami, które utworzyłeś. Jeśli jesteś bardziej NSP / ISP / * SP, oddzielenie infrastruktury i tras klientów między IGP i EGP staje się znacznie ważniejsze w miarę skalowania.

Jako inżynier ISP intensywnie wykorzystujemy łącza MetroE i EWAN do budowy naszego szkieletu oraz wykorzystujemy naszą wiedzę na temat fizycznych łączy do projektowania naszego środowiska iBGP / eBGP. W wielu przypadkach używamy reflektorów trasy i podwójnych reflektorów trasy (klient-odbłyśnik-klient po obu stronach peeringu), aby zmniejszyć liczbę naszych równorzędnych iBGP. Jednak, chyba że masz do czynienia z routerami 6+ w POP, iBGP skaluje się całkiem dobrze.

Krótko mówiąc - jeśli dotyczy to jednego klienta, który nie oferuje usług sieciowych własnym klientom - trzymaj się IGP. Jeśli łączność zewnętrzna musi być współdzielona między lokacjami, z przełączaniem awaryjnym / redundancją itp., Dokładnie zbadaj posiadane ścieżki fizyczne i zaprojektuj eBGP / iBGP, aby to odzwierciedlić. Nie ma sensu mieć routera w zdalnej lokalizacji z tylko 1 linkiem poza witryną do peera iBGP ze wszystkimi innymi routerami w AS - użyj reflektora z dwiema trasami.

Przejście z zarządzanego L3VPN (co zakładam, że masz na myśli przez „MPLS VPN”) na L2VPN to dobry krok w górę, ponieważ możesz uruchamiać protokoły inne niż IP i uzyskać całkowitą kontrolę nad protokołami routingu i platformami routingu, które definiują twój routing topologia.

Zakładając, że umieścisz tylko jeden adres MAC Ethernet po stronie CPE każdej z twoich witryn, sprzętowi dostawcy jest znacznie łatwiej nauczyć się i przesłać 1 adres MAC na stronę, niż nauczyć się i przekierować potencjalnie wiele podsieci na stronę.

Jeśli chodzi o protokół, odpowiedź na to pytanie jest trudna bez większej ilości informacji, ponieważ najlepszy wybór zależy od ruchu i planów rozwoju.

Czy to tylko jeden duży klient, który potrzebuje łączności wewnętrznej i internetowej, czy też sprzedaje łączność? Zakładając, że wszystko jest wewnętrzne, po prostu wdrożysz IGP i być może uruchomisz eBGP do ogłaszania ścieżek.

Jeśli nie masz zbyt wielu witryn lub wewnętrznych prefiksów, najbardziej sensowny jest protokół stanu łącza, taki jak OSPF lub IS-IS, ponieważ szybko się zbiegnie i może szybko zbudować FIB z RIB, jeśli jest tylko kilka prefiksów .

Jeśli będziesz mieć wiele witryn lub wiele prefiksów, zacznie to opodatkowywać twoje platformy routingu, ponieważ każda z nich musi je przetworzyć. Jest to coś, co zaczyna zabierać n ² razy. Jeśli masz witryny, które często pojawiają się i spadają, ta zmiana stanu łącza może również zacząć obciążać pulę routerów.

Jeśli zamierzasz mieć wiele witryn, wiele krótkich witryn (jedna ścieżka „w górę”, żadnych innych routerów w dół) lub dużo rezygnacji z trasy, musisz przyjrzeć się innym protokołom lub topologiom.

W takim przypadku polecam użycie BGP z niektórymi reflektorami trasy. W ten sposób możesz zapewnić 2+ wytrzymałe odbijacze trasy, w których ogłaszają się szprychy, i za które inne szprychy mogą pobrać tablicę routingu. W ten sposób możesz wdrożyć lekkie CPE w wielu witrynach, które po prostu się łączą, ogłaszają swoje miejsce i uzyskują wewnętrzny stół lub domyślną trasę do routera, który to robi.

W przybliżeniu zasugerowałbym kilka skal i sprzętu (i przy założeniu przepustowości poniżej Gigabit):

• 1 - 20 ramion - OSPFv3 między wszystkimi stronami. Juniper SRX240 lub podobny dla wszystkich stron.
• 20 - 100 szprych - iBGP z reflektorami trasy. Juniper SRX240 w szprychach, Juniper MX5 / 10/40/80 do odbijania tras (lub Debian Linux / BIRD).
• 100 - 500 szprych - Zacznij rozkładać je na różne sieci L2, AS lub obszary

Aby dodać dwa często pomijane bity do dyskusji BGP:

• Jeśli korzystasz z iBGP, zwykle potrzebujesz innego protokołu routingu, aby ustanowić łączność między kolejnymi przeskokami BGP. Z punktu widzenia projektowania iBGP jest bardziej narzędziem skalowalnym niż protokołem routingu;
• Jeśli korzystasz z eBGP, nie potrzebujesz pełnej siatki sesji BGP, aby uzyskać optymalny przepływ ruchu od końca do końca; Przetwarzanie następnego przeskoku BGP ładnie rozwiązuje te problemy.

Aby uzyskać więcej informacji, zobacz http://blog.ioshints.info/2011/08/bgp-next-hop-processing.html

Mógłbyś bardzo dobrze uruchomić OSPF (lub inny IGP) na wielopunktowej usłudze metra Ethernet i powinien on działać bardzo dobrze.

Mogą jednak istnieć powody, aby nadal uruchamiać BGP, chociaż ... byłyby to te same argumenty, dlaczego warto chcieć uruchamiać BGP również we własnej sieci.

Nie musisz umieszczać wszystkich głośników BGP w tym samym AS w sieci typu „broadcast”. Pomyśl o tym jako o wewnętrznym IXP prowadzonym przez telekomunikację, w którym twoje prywatne AS mogą się ze sobą łączyć za pośrednictwem siatki warstwy 2. Nie musisz nawet utrzymywać pełnej siatki połączeń równorzędnych BGP, ponieważ aktualizacje BGP mogą przenosić przeskok w komunikacie aktualizacji, który nie jest taki sam, jak skąd pochodzi sesja równorzędna.

Na przykład, jeśli masz siatkę warstwy 2 z routerami A, B i C, a masz peery BGP między A i B oraz między B i C, gdy C otrzyma aktualizacje tras pochodzących z A, będzie mieć A jako następny przeskok, mimo że nauczyli się tego podczas sesji peeringu z B. Oczywiście chciałbyś więcej peeringu trasy niż tylko jednego hub-and-speak, więc nie jesteś zależny od jednego hubu, ale w żadnym wypadku nie potrzebuję pełnej siatki.

Nadal zyskujesz wszystkie zalety polityki routingu wynikające z uruchomienia BGP, jeśli zrobisz to w ten sposób ... a także, jak wspomniano inny respondent, może korzystać z tej samej prywatnej przestrzeni numerów AS, a nawet może łączyć się z istniejącym L3VPN, aby Twój model i mechanizmy wsparcia nie muszą się zmieniać.

Biorąc to pod uwagę, mam kilka łączy metro-E (w moim przypadku punkt-punkt), które obsługuję OSPF i iBGP i działa to dobrze.

Co z konfiguracją serwera trasy z „szprychami” będącymi klientami rs koncentratora / głównych routerów?

Mimo że peingi bgp byłyby jak topologia hub & speak, wszystkie szprychy powinny mieć możliwość wysyłania ruchu bezpośrednio do wszystkich innych.

Możesz nawet ponownie użyć tych samych prywatnych numerów AS, które są używane z dostawcą MPLS, aby ułatwić migrację z usługi do innej.

Gorąco polecam przeczytanie i podjęcie decyzji w sprawie alternatywnych topologii OSPF, takich jak rozpoczęcie od NBMA zamiast standardowych. Wkrótce zdasz sobie sprawę, że OSPF nie ma możliwości prawidłowego wyboru między dwiema ścieżkami prowadzącymi do tego samego routera / strony w tej samej sieci Ethernet, ze względu na sposób obliczania kosztu przez interfejs wychodzący, zarówno główne, jak i zapasowe łącza WAN będą wyglądały tak samo koszt w standardowym OSPF. Jeśli jednak zdecydujesz się na użycie NBMA, możesz ręcznie zdefiniować koszty sąsiada - ale teraz musisz ręcznie zdefiniować siatkę / przylegania.

Cokolwiek robisz, ROUTE OVER IT IT POWTARZAJ NIE DOŁĄCZAJ DO WARSTWY 2, po prostu pytasz o kłopoty później, jeśli potrzebujesz wzajemnej łączności warstwy 2, użyj OTV lub innej funkcji warstwy 2 nad warstwą 3.

Szybko przekonasz się, że dowiesz się znacznie więcej o OSPF (i musisz wiedzieć znacznie więcej) niż w porównaniu do prostego dostawcy MPLS-VPN, w którym rdzeń WAN jest przed tobą ukryty.

OSPF przez metroE działa dobrze, ale musisz się upewnić, że pasuje do twoich potrzeb i odpowiednio zaprojektujesz. Jedynym zastrzeżeniem, o którym nie wspomniałem, jest upewnienie się, że wiesz, jaką jednostkę MTU obsługuje Twój dostawca. Widziałem spadek MTU na łączu metroE podczas konserwacji dostawcy, który powoduje, że sąsiad OSPF nie pojawia się. Prawdopodobnie tylko problem, ponieważ tak naprawdę nie obsługują dużych ramek, ale zrobili to tylko dla nas :) Bycie miłym czasami się nie opłaca.