📬 ISN 200: Konsolowy Planer IPv6, Nowe Algorytmy i BFD: Twój Pakiet Bezpieczeństwa Sieci!

Proste zapobieganie wyciekom tras

BGP “Roleplay” - Prevent Route Leaks Simply - the Junos Way (RFC9234)

Accidental route leaks and hijacks have been business-as-usual, since the day when Yakov Rekhter and Kirk Lougheed conceived BGP on two napkins, exactly 35 years ago. And it took is all that time, just to realize that a very simple tweak, even though very limited in its nature, could have saved us f

LinkedInBerislav Todorovic

W swej istocie RFC9234 jest proste. Wywodzi się bezpośrednio z modelu relacji między dwoma sąsiadującymi systemami autonomicznymi (AS) w BGP, które z natury mogą być:

• provider-customer - często oferowane klientowi przez dostawcę w ramach umowy komercyjnej
• peering - często bez opłat

Każdy inżynier sieci, który kiedykolwiek dotknął BGP, wie, że w odniesieniu do każdego sąsiada BGP twoja sieć może odgrywać jedną z następujących ról:

• Provider - sąsiedni AS, dla którego twój AS zapewnia pełny tranzyt do Internetu i z powrotem
• Customer - sąsiedni AS, którego twoja sieć używa do pełnego tranzytu do sieci globalnej
• Peer - sąsiedni AS, który oferuje ci ograniczony tranzyt do swojej sieci i sieci swoich klientów oraz vice versa

Klasyczny sposób implementacji powyższego podziału zasad, wykonuje się następująco:

1. Przypisz standardową społeczność dla każdej roli sąsiada (Customer, Peer, Provider)
2. W politykach importu BGP - oznacz wszystkie trasy odpowiednią społecznością roli
3. W politykach eksportu BGP - rozgłaszaj tylko trasy oznaczone społecznością Customer do Peers i Providers, jednocześnie rozgłaszając wszystko do wszystkich sąsiadów z rolą Customer

Przykład implementacji w Junos:

policy-options {
    policy-statement PS-EBGP-CUSTOMER-OUT {
        term BGP {
            from {
                protocol bgp;
                prefix-list PL-CUSTOMER;
            }
            then accept;
        }
        then reject;
    }
    policy-statement PS-EBGP-PEER-OUT {
        term REJECT {
            from community [ PEER PROVIDER ];
            then reject;
        }
        term BGP {
            from {
                protocol bgp;
                community CUSTOMER;
            }
            then accept;
        }
        then reject;
    }
    community CUSTOMER members 65000:0;
    community PEER members 65000:1;
    community PROVIDER members 65000:2;
}

RFC9234 przychodzi z eleganckim rozwiązaniem - tak zwaną funkcjonalnością i atrybutem Only-To-Customer (OTC) BGP. HPE Juniper Networking niedawno to zaimplementowało, dając prosty mechanizm łagodzenia takich problemów.

RFC9234 definiuje LOCAL ROLE twojego AS w odniesieniu do każdego z twoich sąsiadów. Podstawowe użycie jest proste - po prostu idź do konfiguracji BGP i dodaj przełącznik otc-local-role:

set protocols bgp group TRANSIT otc-local-role customer
set protocols bgp group CUSTOMER otc-local-role provider  
set protocols bgp group PEER otc-local-role peer

Podobnie jak każde inne rozszerzenie BGP, to również opiera się na dwóch mechanizmach:

• BGP Capability

Negocjowane przy użyciu wiadomości BGP OPEN, gdy ustanawiana jest sesja BGP. Jeśli BGP Role Capability (Code: 9) jest obecna w wektorze BGP Capabilities wiadomości OPEN, ta opcja jest komunikowana do peera i atrybut BGP Role jest wymieniany przy użyciu wiadomości UPDATE.

• BGP Attribute

Jeśli negocjacja capability jest udana, BGP OTC Attribute (Code: 35) jest wymieniany z peerem. Celem tego atrybutu jest wymuszenie, że gdy trasa zostanie wysłana do Customer, Peer lub Route Server Client, następnie pójdzie tylko do Customers.

RFC9234 przewiduje nieco inne handling tego atrybutu:

• Tryb luźny (Loose Mode) - domyślny w większości implementacji, spowoduje, że sąsiad nierozumiejący BGP OTC Capability zignoruje go. Sesja BGP zostanie utworzona, ale rola OTC będzie używana tylko lokalnie.
• Tryb ścisły (Strict Mode) - jeśli BGP OTC Capability nie jest wynegocjowane - NIE twórz sesji BGP i traktuj to jako błąd.

Czasami ustawienie stałej roli per grupa BGP lub sąsiad może być niewystarczające. Junos ma na to eleganckie rozwiązanie! Możesz nadpisać rolę dla jednego lub więcej prefiksów w ramach działań polityki routingu:

set policy-options policy-statement MYPOLICY term OTC-ROLE-OVERRIDE then otc-local-role provider

Jeśli chcesz wyciekać konkretny prefiks otrzymany od peera do swoich providerów, musisz nadpisać rolę OTC dla tego prefiksu:

policy-options {
    policy-statement PS-EBGP-TRANSIT-OUT {
        term EXCEPTION {
            from {
                protocol bgp;
                route-filter 200.200.5.0/24 exact;
            }
            then {
                accept;
                otc-local-role provider;
            }
        }
    }
}

Przełom w algorytmach najkrótszej ścieżki

https://arxiv.org/pdf/2504.17033

W świecie algorytmów grafowych rzadko kiedy jesteśmy świadkami tak znaczących przełomów. Algorytm Dijkstry, opracowany w 1959 roku przez holenderskiego informatyka Edsgera Dijkstrę, przez dziesięciolecia stanowił złoty standard dla znajdowania najkrótszych ścieżek w grafach. Ostatnia znacząca poprawa miała miejsce w 1984 roku, ustanawiając "barierę sortowania", którą wydawało się niemożliwe do pokonania.

Bariera sortowania w kontekście algorytmów najkrótszej ścieżki odnosi się do teoretycznego ograniczenia wydajności. Tradycyjnie uważano, że algorytmy te nie mogą działać szybciej niż O(m log n), gdzie m to liczba krawędzi, a n to liczba wierzchołków w grafie.

Teraz, po 41 latach stagnacji, chińscy naukowcy z Uniwersytetu Tsinghua przełamali tę barierę. Ich nowy algorytm osiąga złożoność czasową O(m log^(2/3) n), co stanowi pierwszy istotny postęp od dekad.

Kluczową innowacją jest zastosowanie strategii "dziel i zwyciężaj" z nowatorskim krokiem scalania. W przeciwieństwie do tradycyjnych algorytmów sortowania, ten krok scalania jest specjalnie dostosowany do etykiet odległości w grafach.

"Bootcamp" z Automatyzacji sieci

GitHub - NetAuto-RheinMain/NetAuto-Bootcamp: An introduction into the world of Network Automation

An introduction into the world of Network Automation - NetAuto-RheinMain/NetAuto-Bootcamp

GitHubNetAuto-RheinMain

NetAuto-Bootcamp to intensywny, praktyczny program uczący automatyzacji sieci i podstaw sieciowych. Możesz go użyć, jeśli chcesz przejść z tradycyjnego IT do NetOps albo zbudować solidne umiejętności w automatyzacji dla Cisco IOS i Arista EOS. Kurs łączy teorię niezależną od dostawcy z praktyką specyficzną dla vendorów — projektujesz, konfigurujesz, automatyzujesz i rozwiązujesz problemy w środowiskach symulowanych (Cisco Packet Tracer, GNS3, EVE‑NG). Pracujesz z Ansible, Terraform/OpenTofu i Pythonem, porównując składnię vendorów i realizując scenariusze z życia.

Planer adresacji IPv6 w konsoli

GitHub - buraglio/ipv6planner: A high level IPv6 subnet planner written in go

A high level IPv6 subnet planner written in go. Contribute to buraglio/ipv6planner development by creating an account on GitHub.

GitHubburaglio

IPv6 Address Planner to narzędzie wiersza poleceń do tworzenia hierarchicznych planów adresacji IPv6. Generuje plan z podanego subnetu, rozdziela przestrzeń na wiele POP‑ów, tworzy poziomy podsieci w każdym POPie i oblicza liczbę dostępnych podsieci na każdym poziomie. Eksportuje wynik w formatach tekstowych, JSON lub HTML oraz oferuje tryb interaktywny i rozbudowaną pomoc.

Jak BFD Może Pomóc Twojej Sieci