📬 ISN 180: Architektura gwiazdy z najlepszymi praktykami AWS

Incydent z certyfikatem ROA w Korei Północnej

North Korea Downed by Faulty ROA

On March 18, 2025, North Korea’s BGP routes became RPKI-invalid due to the publication of a faulty ROA. In this post, we’ll visualize the impact on the propagation of affected routes and what North Korea (and you too!) can do to avoid problems with the optional maxLength attribute.

KentikDoug Madory

18 marca 2025 roku, z powodu błędu w certyfikacie ROA opublikowanym przez APNIC, trasy BGP z Korei Północnej zostały oznaczone jako nieprawidłowe. W rezultacie wiele sieci na całym świecie przestało rozsyłać te trasy, co spowodowało gwałtowny spadek liczby punktów dostępowych widzących północnokoreańskie prefiksy IP.

Niektóre sieci, jak Arelion, GTT i Verizon, szybko zareagowały, ale inne, np. AS6762 i AS6939, nie przerwały propagacji. Nawet Cogent musiał zrezygnować z dystrybucji tras z Korei Północnej.

Przyczyna problemu nie jest jasna - mógł to być zarówno przypadek, jak i celowa akcja. W przeszłości zdarzały się ataki wykorzystujące nieprawidłowe certyfikaty ROA, ale najczęściej przyczyną są błędy konfiguracyjne.

Korea Północna szybko zareagowała, opublikowując poprawne certyfikaty ROA i przywracając pełną propagację swoich tras. To pokazuje, jak ważne jest prawidłowe zarządzanie certyfikatami i RPKI dla stabilności sieci.

Ten incydent przypomina, że podstawowe zasady sieciowe wciąż mają kluczowe znaczenie, nawet w erze chmur i AI. Nawet najmniejszy błąd może mieć poważne konsekwencje dla całych krajów.

Mechanika kierowania ruchem w MPLS i Segment Routing

Loopback as a Service

Methods of steering traffic into MPLS and Segment Routing LSP is one of the least standardized and most confusing parts of traffic engineering.

routingcraft.netroutingcraft

W świecie sieci komputerowych kierowanie ruchem to nie lada wyzwanie. Szczególnie gdy mamy do czynienia z technologiami MPLS i Segment Routing (SR), gdzie każdy dostawca ma własne, często niepokrywające się podejście.

Na pierwszy rzut oka płaszczyzna kontrolna MPLS i SR wydaje się całkiem dobrze ustandaryzowana. Ale diabeł tkwi w szczegółach – dokładniej mówiąc, w metodach kierowania ruchu. Brak jednolitych standardów sprawia, że każdy vendor stosuje własną logikę wyboru następnego przeskoku.

Weźmy przykład RSVP-TE LSP. Na Cisco IOS-XE/XR domyślnie nie routujemy przez RSVP, choć istnieje opcja "autoroute announce". Tymczasem Juniper i Arista podchodzą do tematu inaczej – ich tunele MPLS obsługują przeskoki BGP zgodnie z preferencjami protokołów (RSVP-TE > SR-TE > LDP).

Segment Routing miał uprościć i zwiększyć skalowalność MPLS. Kluczowym mechanizmem jest tu koncepcja "koloru" – unikalnej wartości liczbowej przypisanej do polityki SR-TE. Trasy BGP pasujące do danego koloru są mapowane do odpowiedniej polityki.

To jak GPS dla ruchu sieciowego – pozwala precyzyjnie kierować różnymi usługami z tego samego routera do osobnych ścieżek.

Nie zawsze można od razu wdrożyć najnowsze standardy. Dlatego często sięgamy po sprytne rozwiązania tymczasowe. Jednym z nich są service loopbacki.

Mechanizm jest prosty: każdy interfejs pętli zwrotnej odpowiada innej usłudze. Następny przeskok dla danej trasy (BGP, MPLS VPN, EVPN) jest zmieniany na odpowiedni service loopback. Te nie są ogłaszane do IGP, ale trafiają do BGP-LU z niskim priorytetem.

Sygnalizowanie RSVP-TE LSP do różnych loopbacków to temat rzeka. Niektóre implementacje to wspierają, inne nie. Często trzeba kombinować – albo konfigurować bezpośrednio na routerze, albo użyć zewnętrznego kontrolera SDN do obliczenia trasy.

HA dla Cisco SD-WAN z NGFW

Cisco Learning Network

Artykuł omawia strategie zapewnienia wysokiej dostępności w implementacjach Catalyst SD-WAN, koncentrując się na automatyzacji i synchronizacji stanu w rozwiązaniach z zaporą ogniową nowej generacji (NGFW). Wskazuje na znaczenie redundancji urządzeń, połączeń WAN oraz rozkładu ruchu w celu eliminacji pojedynczych punktów awarii.

Szablony konfiguracji z Ansible

Network Configuration Templating with Ansible - Part 1

When discussing network automation with our customers, one of the main concerns that come up is the ability to audit their device configurations. This becomes especially important during the last quarter of the year, as many corporations are going through their yearly audit to obtain their required approvals for PCI or other compliance standards. Our solution for that is to use the Golden Configuration application for Nautobot, but it’s also entirely possible to use simple Ansible playbooks to perform the audit. This blog series will go over the essential pieces to understanding network configuration templating using Ansible, but the same process can easily be translated for use with Nautobot.

Network to CodeChiara Geronzi

W artykule omawiane są kluczowe elementy automatyzacji konfiguracji sieci z użyciem Ansible, zwłaszcza w kontekście audytu konfiguracji urządzeń. Proponowane rozwiązanie to wykorzystanie aplikacji Golden Configuration dla Nautobot, jednak równie skuteczne mogą być proste skrypty Ansible. Artykuł koncentruje się na procesie tworzenia szablonów konfiguracji, zaczynając od wyboru funkcji do audytu, takiej jak konfiguracja NTP, oraz na identyfikacji i organizacji odpowiednich zmiennych w strukturze YAML.

Architektura gwiazdy z najlepszymi praktykami AWS