EVE-NG na Proxmox
Uruchamianie EVE-NG bezpośrednio na Proxmox to elegancki sposób na centralizację infrastruktury labatoryjnej. Zamiast dedykowanego hosta, otrzymujesz pełnowartościowe środowisko do testów w ramach istniejącej wirtualizacji. Jest jednak jeden warunek: nested virtualization musi działać perfekcyjnie.
Nested KVM: fundament konstrukcji
EVE-NG wymaga możliwości uruchamiania własnych VM-ów, więc Proxmox musi przekazać mu pełne możliwości procesora. Sprawdź najpierw, czy nested virtualization jest już aktywny:
Intel: cat /sys/module/kvm_intel/parameters/nested
AMD: cat /sys/module/kvm_amd/parameters/nested
Jeśli widzisz Y lub 1 – jesteś gotowy. Jeśli nie, włącz go jedną komendą:
# Intel
echo "options kvm-intel nested=Y" > /etc/modprobe.d/kvm-intel.conf
modprobe -r kvm_intel && modprobe kvm_intel
# AMD
echo "options kvm-amd nested=1" > /etc/modprobe.d/kvm-amd.conf
modprobe -r kvm_amd && modprobe kvm_amd
W ustawieniach VM ustaw CPU type na host – to kluczowe. Bez tego EVE-NG nie zobaczy instrukcji wirtualizacyjnych procesora i nested KVM nie zadziała.
Konfiguracja VM
Podczas tworzenia VM w Proxmox:
- Storage: VirtIO Block zamiast domyślnego – zauważalna różnica w wydajności dysków
- CPU: Type = host (na samym dole listy), minimum 4 rdzenie dla komfortu
- RAM: 8GB to start, ale pod obciążeniem rozważ 16GB+
- QEMU Agent: włącz dla lepszej integracji z Proxmox
Instalacja EVE-NG trwa dłużej niż Ubuntu minimal – spokojnie 15-20 minut. Po pierwszym uruchomieniu natychmiast zmień domyślne hasło (admin/eve) przez interfejs webowy.
Uruchomienie EVE-NG na Proxmox daje kilka przewag nad bare-metal:
- Snapshoty: powrót do czystego stanu
- Backup: pełna VM z konfiguracją i obrazami węzłów w jednym miejscu
- Zasoby on-demand: skaluj CPU/RAM w zależności od aktualnego projektu
Wersja Professional EVE-NG dodaje obsługę Vyatta, FortiGate i zaawansowane funkcje multi-user. Licencja roczna, ale dla środowisk produkcyjnych lub rozbudowanych lab-ów zwraca się w czasie zarządzania.
Security Service Insertion w SD-Access
https://www.entek-it.com/knowledge/sda-ssi-deepdive
Cisco udostępnia w early access program nową funkcjonalność SD-Access: Security Service Insertion (SSI). To nie jest kolejny feature sheet – to techniczny deep dive oparty na rzeczywistej implementacji laboratoryjnej z Catalyst Center 3.1.x i IOS-XE 17.18.x.
Catalyst Center vs ISE – kto faktycznie steruje polityką?
Catalyst Center nie jest płaszczyzną sterowania. Center orkiestruje intent – włącza SSI na węzłach, wiąże firewall z virtual network, pushuje politykę do ISE. Ale to ISE staje się policy authority dla sterowania ruchem.
Efekt widoczny natychmiast na switchu: nowe polecenia group-policy traffic-steering pokazują ISE jako aktywny policy server, podczas gdy Catalyst Center pojawia się tylko jako nieaktywna referencja. Switchę pobierają i utrzymują stan lokalnie – brak potrzeby konsultacji w runtime. Decyzja przekierowania zapada na ingress edge, nie w środku ścieżki.
Firewall jako LISP service EID
SSI rejestruje IP firewalla w LISP jako Service-ETR powiązany z konkretnym VN, VRF i border RLOC. Firewall nie jest "po prostu IP na transit network" – to first-class object w control plane SD-Access.
Rezultat: fabric wie natywnie, gdzie jest serwis i jak do niego dotrzeć. Zero static routing, zero policy-based routing tricks na edge'ach.
Co się dzieje z ruchem pasującym do polityki SSI?
Ingress edge podejmuje decyzję natychmiast. Gdy ruch matchuje politykę steering (source SGT → destination SGT), edge enkapsuluje pakiety w LISP/VXLAN bezpośrednio w kierunku firewall service. Nie przekazuje ruchu normalnie, nie czeka na reklasyfikację na kolejnym hopie.
Dlaczego to działa? SGT są teraz częścią LISP control plane. Pierwszy edge zna lokalizację policy-relevant service od razu. SXP? Niepotrzebny. Drugi hop do reklasyfikacji? Zbędny.
Border node decapsuluje i forwarduje do firewalla używając VRF i next-hop z LISP – czysto, przewidywalnie, bez rekursji.
Firepower z TrustSec – kontekst zachowany
TrustSec na interfejsie border-firewall pozwala Firepower egzekwować politykę z pełnym SGT context. Logi FMC pokazują ruch hairpinujący na tym samym transit interface z widocznością source IP, destination IP i source SGT.
Fabric abstraction nienaruszony. Dla fabric – firewall to kolejny serwis. Dla firewalla – pełny identity context.
SSI eliminuje całe kategorie złożoności:
- Zero SXP – nie projektujemy, nie skalujemy, nie troubleshootujemy
- Zero PBR na edge'ach – decyzja raz, na ingress
- Zero ryzyka późnego redirectu – traffic idzie wprost do właściwego serwisu
- Identity-driven od początku do końca – zgodnie z pierwotnym intencją SD-Access
To nie jest inkrementalna poprawa. To architektoniczny skok – security enforcement wyrównany z fabric design: identity-driven, control-plane-aware, deterministyczny.
Nowy, lepszy traceroute
hervehildenbrand
gtrace to zaawansowane narzędzie do analizy ścieżek sieciowych, które łączy lokalny traceroute z rozproszoną siecią sond GlobalPing. Umożliwia wykrywanie m.in. etykiet MPLS, load balancingu ECMP, NAT oraz odkrywanie MTU ścieżki. Obsługuje protokoły ICMP, UDP i TCP oraz IPv4/IPv6. Dzięki integracji z GlobalPing pozwala na porównanie tras z różnych lokalizacji na świecie. Wyniki można eksportować w formatach JSON, CSV i tekstowym. Narzędzie dostępne jest na Linux, macOS i Windows, wymaga uprawnień root/sudo do działania.
Alternatywa dla IPERF3
lance0
xfr to nowoczesna alternatywa dla iperf3, oferująca testy sieciowe z interaktywnym interfejsem (TUI) w czasie rzeczywistym, obsługą wielu klientów na serwerze oraz wsparciem dla protokołu QUIC. Narzędzie zostało napisane w Rust i umożliwia pomiary przepustowości TCP, UDP i QUIC z różnymi opcjami konfiguracji, jak liczba równoległych strumieni, bitrate czy kierunek testu.
Konfiguracja 200 kontenerów FRR w 10 sekund
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