VRF Sandwich
Service insertion w EVPN to temat, który wraca przy każdym projekcie data center wymagającym inspekcji ruchu east-west. VRF Sandwich to eleganckie rozwiązanie — ale ma kilka pułapek, które potrafią zaskoczyć nawet doświadczonych inżynierów.
Idea jest prosta: umieszczasz źródłowy i docelowy endpoint w osobnych VRF-ach (np. VRF A i VRF B), a firewall staje się jedynym punktem łączącym te VRF-y. Każdy interfejs firewalla trafia do odpowiedniego VRF-a, a routing między VRF-ami odbywa się przez eBGP. Ruch między endpointami musi fizycznie przejść przez firewall — nie ma innej drogi.
W praktyce konfiguracja na border leafie sprowadza się do przypisania interfejsów do VRF-ów i uruchomienia sesji eBGP z firewallем w każdym VRF-ie osobno.
Tu zaczyna się najciekawsza część. EVPN fabric działa w jednym AS (np. 65000). Border leaf wysyła prefix do firewalla z tym AS w ścieżce. Firewall odsyła prefix do border leafa w drugim VRF-ie — ale AS 65000 nadal siedzi w AS path. Border leaf widzi własny AS, odrzuca prefix. Ruch nie działa.
Masz dwa wyjścia:
- AS Override na firewallu — zastępuje AS fabric swoim własnym AS przed readvertisementem. Konfigurujesz tylko na urządzeniu zewnętrznym, zakres zmian minimalny.
- allowas-in na fabric — pozwala VTEPom akceptować prefiksy z własnym AS w ścieżce. Musisz to skonfigurować wszędzie: na route reflectorach i wszystkich uczestniczących VTEPach. Słabo skalowalne.
Rekomendacja: AS Override na firewallu. Mniejszy blast radius, łatwiejszy audyt.
Uwaga na FRR: domyślnie wymaga jawnej polityki dla eBGP (RFC 8212) i nie implementuje split-horizon dla eBGP. Bez no bgp ebgp-requires-policy i neighbor X solo możesz spędzić godzinę debugując, dlaczego sesja jest up, ale prefiksy nie przechodzą.
Active-active cluster firewalli wygląda świetnie na papierze — dopóki nie zauważysz, że request poszedł przez node 1, a response wraca przez node 2. Jeśli klaster nie synchronizuje stanu sesji, node 2 nie zna tego flow i blokuje ruch.
Rozwiązanie: symmetric hashing na fabric wymusza, że oba kierunki tego samego flow trafiają do tego samego node. Alternatywnie — klaster z pełną synchronizacją stanu, ale to już odpowiedzialność po stronie security team.
VRF Sandwich działa dobrze przy małej liczbie VRF-ów. Przy skali pojawiają się problemy: każdy VRF wymaga dedykowanych interfejsów i osobnych sesji BGP z firewallем. Przy 10+ VRF-ach zarządzanie tym staje się uciążliwe. Selektywna inspekcja przez filtrowanie BGP jest możliwa, ale krucha.
Największy problem z automatyzacją sieci
Tim Schreyack
Twój zespół spędził 18 miesięcy na budowanie wewnętrznej platformy automatyzacji. Teraz połowa inżynierów sieciowych zarządza backlogiem dla developerów zamiast zajmować się siecią. Brzmi znajomo?
Branża popełnia systematyczny błąd: gdy pojawia się potrzeba automatyzacji provisioning'u czy auto-remediacji, domyślną odpowiedzią staje się "zatrudnijmy deweloperów i zbudujmy to sami." Logika jest pozornie sensowna — unikamy vendor lock-in, mamy pełną kontrolę.
W praktyce zamieniasz zależność od dostawcy na zależność od dwóch-trzech inżynierów, którzy rozumieją wewnętrzny codebase. Gdy odejdą, odchodzi razem z nimi wiedza o architekturze systemu obsługującego produkcję.
Nikt nie buduje własnej Grafany ani Prometheusa od zera. Ale przy automatyzacji sieci nagle przyjmujemy, że musimy tworzyć wszystko samodzielnie. To niespójność, która kosztuje miliony.
Network Automation Forum w swoim badaniu z 2025 roku potwierdza: 92% organizacji buduje automatyzację przy użyciu inżynierów sieciowych z umiejętnościami programistycznymi — nie dedykowanych team'ów deweloperskich. To nie obejście problemu. To właściwy model.
Inżynierowie sieciowi robią znacznie więcej niż "skrypty w Pythonie": definiują modele danych, kodują wiedzę operacyjną w zadaniach automatyzacji, budują integracje między systemami. Robią to jednak na platformach, które rozwiązują trudne problemy informatyczne — żeby oni mogli skupić się na trudnych problemach sieciowych.
Budowanie własnej warstwy platformowej to dublowanie pracy, którą ktoś już wykonał i przetestował w dziesiątkach środowisk produkcyjnych.
Żaden vendor nie dostarczy w pudełku tego, co ty wnosisz: znajomości swojej topologii, polityk operacyjnych, historii decyzji konfiguracyjnych sprzed lat. To wiedza, która sprawia, że automatyzacja jest bezpieczna.
Automatyczne generowanie testów
pdudotdev
aiQA to narzędzie do automatycznego generowania testów sieciowych dla środowisk wielowendorowych. Wystarczy opisać oczekiwane działanie sieci, a system przygotuje zgodne z RFC scenariusze testowe, komendy CLI dla konkretnych producentów, asercje oraz pliki YAML, testy pytest i playbooki Ansible. Narzędzie obsługuje m.in. OSPF, BGP i EIGRP, korzysta z dokumentacji RFC oraz instrukcji producentów, a każdy test zawiera obowiązkowe wycofanie zmian. Projekt można dostosować do własnej topologii, urządzeń i założeń projektowych.
Komunikacja poprzez pakiety DHCP
pdudotdev
DHushCP to edukacyjne narzędzie dla Linuksa, które umożliwia przesyłanie ukrytych wiadomości za pomocą pakietów DHCP. Treści są umieszczane w mniej typowych polach protokołu, a dodatkowa funkcja steganografii pozwala ukrywać tekst przy użyciu niewidocznych znaków Unicode. Projekt może zainteresować osoby uczące się o steganografii sieciowej i testach bezpieczeństwa, ale należy korzystać z niego wyłącznie w autoryzowanych środowiskach.
Szyfrowanie overlay bez przepisywania architektury
Przeczytaj całą historię
Zarejestruj się teraz, aby przeczytać całą historię i uzyskać dostęp do wszystkich postów za tylko dla płacących subskrybentów.
Subskrybuj