📬 ISN 234: Dlaczego Szwajcaria ma 25 Gbit/s? VXLAN z AP i Multi-Vendor ZTP!

VXLAN bezpośrednio z AP

VXLAN to the Access Point

If you did not know, Arista Networks has wireless offerings, while this won’t be an exhaustive look at the product line, they do provide what you expect from a modern provider, cloud controlled, assisted troubleshooting, client monitoring, and VXLAN encapsulation from the AP. That last feature, this

LinkedInBrett K.

Architektura cloud-managed wireless rozwiązała problem skalowalności wdrożeń, ale stworzyła nowy: ruch użytkowników wylewa się bezpośrednio do warstwy dystrybucji i core, generując nieprzewidywalne przepływy. Arista odpowiada na to enkapsulacją VXLAN bezpośrednio z AP.

W klasycznym modelu kontrolerowym next-hop był zawsze znany — tunel kończył się na kontrolerze, polityki były egzekwowane centralnie. Po przejściu na model cloud-managed ten punkt agregacji zniknął. Underlay musi teraz obsłużyć dynamiczne, rozroszone przepływy klientów bezprzewodowych, a każda zmiana w zagęszczeniu użytkowników odbija się bezpośrednio na warstwach rdzenia.

VXLAN z AP rozwiązuje to bez wracania do dedykowanego sprzętu.

Każdy SSID może mieć skonfigurowany tunnel VXLAN do wskazanego punktu terminacji — w tym przypadku przełącznika Arista EOS pełniącego rolę VTEP. Warunki wstępne są minimalne:

• Łączność L3 między IP access pointa a adresem VTEP (realizowana przez eBGP między core i border leaf)
• Mapowanie VLAN-to-VNI na przełączniku terminującym
• Komenda vxlan flood vtep learned data-plane eliminuje potrzebę statycznego mapowania AP

Klient łączy się z SSID, jego ruch jest enkapsulowany w VXLAN już na AP i transportowany po underlaju jako zwykły pakiet UDP. Przełącznik EOS de-enkapsuluje ruch, klient dostaje gateway na tym urządzeniu, a domyślna trasa kieruje pakiety dalej — np. do Palo Alto do inspekcji.

Underlay nie widzi nic poza zewnętrznymi nagłówkami L3. Brak potrzeby trunk VLAN po stronie AP, brak zależności od trunking policy w sieci dostępowej.

Dlaczego Szwajcaria ma internet 25 Gbit/s, a USA nie

The Free Market Lie: Why Switzerland Has 25 Gbit Internet and America Doesn’t

The Free Market Lie: Why Switzerland Has 25 Gbit Internet and America Doesn’t

Stefan SchüllerStefan Schüller

Szwajcaria oferuje dziś dedykowany, symetryczny internet 25 Gbit/s do domu. Nie współdzielony z sąsiadami, z wyborem spośród kilkunastu dostawców. To nie przypadek technologiczny — to efekt świadomej decyzji architektonicznej na poziomie regulacyjnym.

Kluczowa różnica tkwi w architekturze fizycznej. Każdy budynek dostaje 4 dedykowane włókna światłowodowe w topologii Point-to-Point. Włókna kończą się w neutralnym, otwartym węźle (PoP), do którego podłączyć się może dowolny ISP. Identyfikator gniazda OTO (Optical Termination Outlet) wystarczy, żeby operator aktywował usługę — bez wizyty technika, bez kopania rowów.

Efekt: konkurencja odbywa się na warstwie usług (cena, jakość, support), nie na warstwie infrastruktury. To klasyczny unbundling — tyle że egzekwowany na poziomie L1, nie L2/L3.

USA oddało budowę sieci operatorom bez obowiązku współdzielenia infrastruktury. Rezultat: terytorialne monopole. Comcast ma swoją dzielnicę, AT&T swoją. Brak konkurencji = brak presji na upgrade. Dodatkowo dominuje architektura P2MP (GPON/XGS-PON) ze splitterami 1:32 — nominalny gigabit dzielony między 32 abonenów wieczorami spada do 100–200 Mbit/s.

Niemcy postawiły na infrastructure competition — każdy operator kopie własny rów. Efekt: równoległe inwestycje w tę samą ulicę, miliardy euro zmarnowane na redundantny beton, a pokrycie wciąż słabe.

W 2020 roku Swisscom próbował zastąpić P2P architekturą P2MP — co de facto zamknęłoby dostęp fizyczny dla konkurentów. Init7 złożył skargę do COMCO (szwajcarski UOKiK). Sąd federalny przyznał rację regulatorowi. Swisscom zapłacił 18 mln CHF kary i wrócił do czterowłóknowego standardu P2P.

Multi-Vendor ZTP

GitHub - NetOpsChic/multivendor-ZTP-server

Contribute to NetOpsChic/multivendor-ZTP-server development by creating an account on GitHub.

GitHubNetOpsChic

Multi-Vendor Pure ZTP Lab to minimalistyczne, oparte na infrastrukturze jako kod rozwiązanie do automatycznego, Day 1 Provisioning sieci wielodostawców (Cisco, Juniper, Arista) w środowisku GNS3. Projekt wykorzystuje prosty serwer ZTP w kontenerze Docker, który wykrywa urządzenia po Vendor Class Identifier (DHCP Option 60), przypisuje im unikalne adresy IP oraz dostarcza właściwe pliki konfiguracyjne przez TFTP.

Iperf3 na sterydach

GitHub - waqasdaar/iperf3-traffic-streams

Contribute to waqasdaar/iperf3-traffic-streams development by creating an account on GitHub.

GitHubwaqasdaar

iperf3-traffic-flows to zaawansowany, terminalowy menedżer ruchu sieciowego oparty na iperf3, oferujący wielostrumieniowe testy przepustowości w środowiskach produkcyjnych. Narzędzie rozwiązuje typowe problemy surowych poleceń iperf3, takie jak zarządzanie wieloma strumieniami, testowanie w VRF, znakowanie DSCP czy monitorowanie wyników w czasie rzeczywistym, dzięki interaktywnemu menu i automatycznej konfiguracji. 

Fundament automatyzacji, który musisz rozumieć