📬 ISN 224: eBGP-Multihop vs TTL-Security, Podstawy GIT i Rust w Parze z Pythonem!

224 numer newslettera porusza różnice między ebgp-multihop a ttl-security, dziedziczenie cudzej sieci, podstawy GIT-a, integrację Catalyst Center z NetBox oraz łączenie Rust z Pythonem — wydajność spotyka elastyczność. Czytaj dalej!
📬 ISN 224: eBGP-Multihop vs TTL-Security, Podstawy GIT i Rust w Parze z Pythonem!

Różnica między ebgp-multihop a ttl-security

#networking #bgp #security | Chingiz Khalafov
Have you ever ask yourself, what is the difference between ebgp-multihop and ttl-security? I mean, what actually changes in background? Well, below is a simple explanation: eBGP multihop sets TTL value for outgoing packets only: ---------------------------------------------------------------- R1(config-router)# do sh ip bgp neighbors 1.1.1.1 | i TTL Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 2 ---------------------------------------------------------------- While ttl-security set minimum incoming TTL value, alongside with outgoing TTL value: ---------------------------------------------------------------- R1(config-router)# neighbor 1.1.1.1 ttl-security hops 1 R1(config-router)# do sh ip bgp neighbors 1.1.1.1 | i TTL Connection is ECN Disabled, Mininum incoming TTL 254, Outgoing TTL 255 ---------------------------------------------------------------- Why it matters? Well, the packet, before reaching CPU should cross hardware component known as ASIC. With ttl-security hops router instructs ASIC to drop TCP packets with TTL value less than expected minimum incoming TTL, hence prevents “fake” packet from exhausting our poor CPU. As the name implies, ttl-security is a security mechanism, while ebgp-multihop is a reachability feature. Btw, those features are mutually exclusive, we can’t configure TTL Security and ebgp-multihop at the same time. ---------------------------------------------------------------- R1(config-router)# neighbor 1.1.1.1 ttl-security hops 1 Remove ebgp-multihop before configuring ttl-security ---------------------------------------------------------------- #networking #bgp #security

Oba pozwalają nawiązać sesję eBGP przez więcej niż jeden hop, ale działają fundamentalnie inaczej – a zrozumienie tej różnicy może uchronić Twoje routery przed atakami DoS.

ebgp-multihop – tylko reachability

Komenda ebgp-multihop modyfikuje wyłącznie wychodzące pakiety TCP – ustawia ich TTL na wartość większą niż domyślny 1. Router wysyła pakiety z odpowiednim TTL, ale nie weryfikuje TTL pakietów przychodzących:

R1(config-router)# neighbor 1.1.1.1 ebgp-multihop 2
R1# show ip bgp neighbors 1.1.1.1 | i TTL
Minimum incoming TTL 0, Outgoing TTL 2

To czysta funkcja reachability – umożliwia nawiązanie sesji, ale nie chroni przed niczym.

ttl-security – ochrona na poziomie ASIC

Mechanizm ttl-security hops działa dwukierunkowo. Ustawia maksymalny TTL (255) dla pakietów wychodzących, ale co ważniejsze – definiuje minimalny TTL dla pakietów przychodzących:

R1(config-router)# neighbor 1.1.1.1 ttl-security hops 1
R1# show ip bgp neighbors 1.1.1.1 | i TTL
Minimum incoming TTL 254, Outgoing TTL 255

Kluczowa różnica: router instruuje ASIC, aby dropował pakiety TCP z TTL poniżej oczekiwanej wartości zanim dotrą do CPU. Atakujący wysyłający sfałszowane pakiety BGP z losowych lokalizacji (z niskim TTL) nie będą w stanie przeciążyć procesora routera – ASIC odrzuci je sprzętowo.

ttl-security to mechanizm bezpieczeństwa implementujący GTSM (Generalized TTL Security Mechanism, RFC 5082). Chroni przed atakami typu TCP RST czy BGP route injection z odległych źródeł. ebgp-multihop to funkcja konfiguracyjna – umożliwia połączenie, ale nie weryfikuje autentyczności źródła pakietów.

⚠️
Ważne: Te opcje wzajemnie się wykluczają. Próba konfiguracji obu jednocześnie kończy się błędem.

Dziedziczenie cudzej sieci

Inheriting Someone Else’s Network: What to Fix, What to Leave Alone, and How Not to Destroy Your Credibility — Layer8Packet
You just got promoted or changed jobs. Now you’re managing a network you didn’t design, with decisions you don’t agree with, and configurations that make you cringe. Do you change everything? Leave it alone? How do you prove yourself without breaking things or alienating the people who built it? Her

Dwa tygodnie w nowej roli. Przeglądasz diagramy sieci, konfigi, architekturę. I nagle to widzisz – decyzję projektową, która wywołuje pytanie: „kto to w ogóle tak zaprojektował?". Twój pierwszy instynkt? „Muszę to naprawić". Głos doświadczenia? „Poczekaj, może brakuje ci kontekstu". Rzeczywistość polityczna? „Zmień to źle i zniszczysz swoją wiarygodność, zanim ją zbudujesz".

Pierwsze 30 dni: obserwuj, nie zmieniaj

Twoja praca w pierwszym miesiącu to NIE zmienianie rzeczy. Ani nawet nie planowanie zmian. Tylko rozumienie.

Co robić: Dokumentuj obecny stan. Rozmawiaj z ludźmi, którzy to zbudowali – pytaj „dlaczego tak zaprojektowaliście?" z prawdziwą ciekawością, nie oceną. Sprawdź incydenty z ostatnich 6-12 miesięcy. Co faktycznie się psuje? Dane > założenia.

Co naprawić, co zostawić: framework

Napraw natychmiast (Tier 1): Aktywne zagrożenia bezpieczeństwa. Problemy z niezawodnością powodujące regularne awarie. Blokery operacyjne. Marnotrawstwo finansowe. Kryterium: powodują realną szkodę, biznesowy wpływ jest mierzalny.

Napraw wkrótce (Tier 2): Starzejąca się infrastruktura. Ograniczenia skalowalności. Ulepszenia efektywności. Dług techniczny. Kryterium: staną się problemami Tier 1, jeśli zostaną zignorowane, ale masz czas, żeby to zrobić dobrze.

Napraw przy okazji (Tier 3): Preferencje architektoniczne. Kwestie kosmetyczne. Optymalizacje o małym wpływie. Kryterium: irytują cię estetycznie, ale nie powodują problemów.

Zostaw (Tier 4): „Zrobiłbym to inaczej". Niskopriorytetowe legacy, które działa. Preferencje zespołu. Kryterium: brak wpływu biznesowego i technicznego. Po prostu inne niż twoje podejście.

Kluczowa zasada: Ludzie opierają się zmianom wprowadzanym NA nich. Wspierają zmiany, które pomogli stworzyć.


Podstawy GIT-a

Git Cheat Sheet - General Commands
We’ve created a handy list and PDF cheat sheet of the most useful Git CLI commands covering the basics, branching, merging, rebasing, and more. Yours to keep as a quick reference for everyday tasks.

Praktyczny przewodnik obejmujący konfigurację, podstawy repozytoriów, codzienny workflow, zarządzanie gałęziami, rebase, stashing, przegląd historii oraz cofanie zmian.


Catalyst Center i Netbox

GitHub - sieteunoseis/netbox-catalyst-center
Contribute to sieteunoseis/netbox-catalyst-center development by creating an account on GitHub.

NetBox Catalyst Center Plugin integruje Cisco Catalyst Center (dawniej DNA Center) z NetBox, umożliwiając podgląd szczegółów urządzeń sieciowych, informacji o klientach bezprzewodowych, statusu zgodności oraz alertów bezpieczeństwa. Dzięki temu narzędziu możesz synchronizować dane o urządzeniach, monitorować stan połączeń Wi-Fi i importować urządzenia bezpośrednio do NetBox.


Rust + Python: jak łączyć wydajność z elastycznością

Świetnie! Udało ci się pomyślnie zarejestrować.
Witaj z powrotem! Zalogowałeś się pomyślnie.
Pomyślnie subskrybowałeś Inna Sieć.
Twój link wygasł.
Sukces! Sprawdź swoją skrzynkę e-mailową, aby uzyskać magiczny link do logowania.
Sukces! Twoje informacje rozliczeniowe zostały zaktualizowane.
Twoje informacje rozliczeniowe nie zostały zaktualizowane.