Jak zbudować wirtualną sieć warstwy 3 w środowisku SPB?

Routing, a mówiąc dokładniej, możliwość podzielenia sieci na osobne podsieci IP i trasowanie ruchu pomiędzy nimi (oraz do sieci zewnętrznych) to element, bez którego praktycznie nie da się obejść. W tradycyjnych sieciach odbywa się to poprzez zewnętrzne routery i/lub firewalle. Ale czy nie byłoby znacznie prościej, gdybyśmy mogli budować wirtualne sieci warstwy 3 (najlepiej wiele) w sieci SPB w dokładnie taki sam sposób, jak tworzy się wirtualne sieci warstwy 2?

Extreme Networks oferuje niezwykle potężne rozszerzenie technologii Shortest Path Bridging. Chciałbym tutaj podkreślić słowo „rozszerzenie”, ponieważ nie tworzy ono z niego rozwiązania w pełni autorskiego. Pamiętam, że za dawnych czasów krążyło wiele dyskusji na temat tego, gdzie trasować (routować). W zależności od przewag (i słabości) różnych rozwiązań, jedni producenci mówili „należy trasować wszędzie”, podczas gdy inni sugerowali raczej, by „switchuj ruch tam, gdzie możesz, trasuj tam gdzie musisz”. Dzięki możliwościom w wirtualnej warstwie 3, jakie dają wspomniane rozszerzenia technologii SPB, taka dyskusja nie ma dłużej sensu: możemy trasować ruch gdziekolwiek nam to odpowiada!

W sieci SPB, wirtualne sieci warstwy 3 buduje się w bardzo zbliżony sposób, co sieci warstwy 2, co szczegółowo omówiliśmy w poprzednim artykule. Ustaliliśmy już, że sieć warstwy 2 powstaje poprzez przyporządkowanie dwóch lub więcej VLANów (pozostających „na zewnątrz” sieci SPB i kończących się na węzłach brzegowych, czyli BEBach) do identyfikatora sieci wirtualnej I-SID. Aby zbudować sieć wirtualną warstwy 3, w miejsce VLANów, do identyfikatora I-SID przyporządkowuje się tzw. VRFy (Virtual Routing and Forwarding). Spójrzmy na poniższy schemat:

Wszystkie VRFy, które przyporządkowane są do identyfikatora I-SID 1001, tworzą wirtualną sieć warstwy 3, a hosty podłączone do jej poszczególnych podsieci mogą się ze sobą komunikować. Oznacza to, że wirtualne routery R1, R2, R3 oraz R4 stanowią część naszej wirtualnej sieci warstwy 3 i możemy im kazać wymieniać informacje na temat bezpośrednio dołączonych podsieci. I, jak już być może się domyślacie, za ową wymianę informacji odpowiada protokół IS-IS. Ponownie, nie jest konieczny OSFP, RIP, ani żaden inny protokół routingu!

A zatem, aby stworzyć naszą wirtualną sieć warstwy 3 (lub inaczej IPVPN), wystarczy zaledwie kilka komend. I ponownie: konfigurujemy przełączniki tylko tam, gdzie chcemy udostępnić usługę. Posiłkując się przykładem z wcześniejszego schematu, konfigurujemy przełączniki tylko tam, gdzie potrzebujemy umieścić niebieskie wirtualne routery. Pomiędzy R1 (BEB1) a R2 (BEB4) mogą znajdować się setki węzłów, lecz nie musimy z nimi nic robić. Dość mocno ułatwia życie, nieprawdaż? Efekt końcowy: hosty i urządzenia podłączone do podsieci 1, 2, 3, 4, 5 i 6 mogą się ze sobą komunikować tak, jakby miało to normalnie miejsce w przypadku tradycyjnego routingu.

Załóżmy, że komputer PC11 w podsieci 1 potrzebuje wysłać coś do serwera S1 znajdującego się w podsieci 6. Jak już wiemy z normalnego routingu IP, PC11 dokona enkapsulacji pakietu IP w ramkę Ethernetową i wyśle go do swojej domyślnej bramy sieciowej (R1). Router R1 następnie usuwa ramkę Ethernetową i sprawdza docelowy adres IP; wiedząc, że podsieć 6 podłączona jest do routera R4, R1 dokona ponownej enkapsulacji pakietu IP w ramkę Ethernetową adresowaną do R4 i przekaże ją do „swojego” węzła BEB (czyli BEB1). Wiedząc, że R4 podłączony jest do BEB4, węzeł BEB1 przystępuje do enkapsulacji MAC-in-MAC w oparciu o adres MAC węzła BEB4 będący adresem docelowym, ustanawia identyfikator I-SID jako 1001 oraz wysyła ramkę do portu znajdującego się na najkrótszej ścieżce do BEB4.

Tak jak w przypadku wirtualnych sieci warstwy 2, o których mówiliśmy poprzednio, wszystkie przełączniki znajdujące się na najkrótszej ścieżce spojrzą tylko na docelowy adres MAC i przekierowują dalej ramkę. Oznacza to, że prędzej czy później (raczej prędzej, tj. w ciągu zaledwie kilkudziesięciu mikrosekund) pakiet trafi do węzła BEB4. Po sprawdzeniu identyfikatora I-SID, węzeł BEB4 będzie wiedział, że otrzymana ramka adresowana jest do wirtualnego routera R4 (oczywiście, na węźle BEB4 skonfigurowanych może być więcej sieci wirtualnych). Następnie usunie on ramkę SPB MAC i przekaże dalej oryginalną ramkę Ethernetową do R4, a ten trasuje pakiet do serwera S1, korzystając z identycznego mechanizmu, jak w normalnym routingu.
 A co, jeśli chcemy komunikować się z inną siecią niebędącą SPB?

Cóż, to dość proste. Rzecz, którą akurat potrzebujemy zintegrować, podłączamy do podsieci „podwieszonej” do jednego (lub więcej) z naszych wirtualnych routerów. Za pomocą kilku prostych komend możemy nakazać wirtualnemu (SPB) routerowi rozsyłać informacje o routingu pochodzące z owego urządzenia zewnętrznego. Aby łatwiej nam to było zrozumieć, spójrzmy na poniższy schemat.

Podłączyliśmy właśnie jakiś router WAN (lub firewall) do naszego wirtualnego routera R4. Moglibyśmy teraz ustawić statyczny routing pomiędzy R4 a routerem WAN lub wykorzystać protokoły trasowania OSFP, RIP lub BGP. Niezależnie od tego, na co się zdecydujemy, routerowi R4 każemy rozsyłać do naszej wirtualnej sieci warstwy 3 wszelkie informacje uzyskiwane z routera WAN. Protokół IS-IS zajmie się następnie ich dystrybucją do routerów R1, R2 oraz R3, które będą teraz wiedziały, że dostęp do tych sieci możliwy jest za pośrednictwem routera R4. I vice versa, R4 poinformuje router WAN o sieciach, które są dostępne za jego pośrednictwem (aczkolwiek mogą obowiązywać polityki routingu).

W kolejnej części „Shortest Path Bridging dla Początkujących”: