📬 ISN 238: Szybszy NetBox w Ansible, ARP vs MAC i 5 Trików FortiGate CLI!

Przyspiesz NetBox Inventory w Ansible

Speed Up Ansible`s NetBox Inventory

NetBox/Ansible Tip: The netbox.netbox.nb_inventory plugin pulls data from multiple NetBox API endpoints. Enable caching and disable unused extra lookups to reduce API calls and improve inventory load times. Here’s what you need to add to your NetBox inventory plugin file: # Cache inventory data cache: True

Packet Coders - Learn Network AutomationRick Donato

Plugin netbox.netbox.nb_inventory odpytuje kilkanaście endpointów NetBox API przy każdym uruchomieniu. Przy dużej infrastrukturze czas ładowania inwentory potrafi zabić produktywność – zanim Ansible zacznie faktycznie działać, czekasz minuty.

Większość inżynierów wie o cachowaniu, ale nie wdraża go bez wyraźnego powodu. Tu masz powód: każde uruchomienie playbooka bez cache to pełny round-trip do NetBox API. Dodaj do pliku inwentory:

cache: True
cache_plugin: jsonfile
cache_timeout: 3600
cache_connection: /tmp/ansible_netbox_cache

Czas życia 3600 sekund to dobry punkt startowy dla środowisk, gdzie dane zmieniają się rzadziej niż raz na godzinę.

Domyślna konfiguracja pluginu pobiera znacznie więcej danych niż większość playbooków rzeczywiście potrzebuje. Interfejsy, serwisy, rekordy DNS – każdy z nich to osobne żądanie do API.

interfaces: False
services: False
dns_name: False
virtual_chassis_flatten: False

Jeśli Twoje playbooki nie operują na tych danych, pobieranie ich to czysty narzut. Wyłącz i sprawdź różnicę w czasie ładowania.

Dwa parametry, które często są pomijane:

fetch_all: True
max_uri_length: 4000

fetch_all: True pobiera wszystkie strony wyników w jednym żądaniu zamiast iterować po stronach. max_uri_length: 4000 pozwala budować dłuższe zapytania i agregować filtry – mniej osobnych requestów do API.

Dlaczego ARP timeout wynosi 4 godziny, a MAC aging 5 minut?

On ARP and MAC Aging Timers « ipSpace.net blog

Naveen Kumar Devaraj mentioned an interesting fact in his EVPN-related comment: The EOS default ARP timeout is 4 hours, and MAC aging is 5 minutes. Arista is not the only platform using these default values; did you ever wonder where they came from?

ipSpace Logo

Jeśli pracujesz z Aristą EOS, te wartości widziałeś setki razy. Ale czy zastanawiałeś się, skąd pochodzą i czy nadal mają sens?

ARP powstał w czasach, gdy każdy broadcast palił cenne cykle CPU na każdej maszynie podłączonej do wspólnego kabla. Projektant protokołu świadomie odrzucił model HELLO (jak w CLNP) jako zbyt kosztowny — stąd mechanizm request/reply.

Długi timeout (4 godziny) był logiczny: ARP to mapowanie między warstwami, nie infrastruktura forwardingu. Adresy IP i MAC są stosunkowo stabilne, Gratuitous ARP obsługuje zmiany, a sam timeout służy głównie jako garbage collection. W 1989 r. RFC 1122 definiował cztery mechanizmy walidacji cache ARP — od timeoutu po unicast poll. Ten drugi pojawił się w praktyce dopiero dekady później.

MAC aging rozwiązuje zupełnie inny problem — utrzymuje tablicę forwardingu w czystości. Transparent bridging nigdy nie miał control plane, który mógłby autorytatywnie potwierdzić lokalizację MAC adresu. Mając tylko dynamiczne uczenie, lepiej było floodować ramkę niż wysłać ją w złym kierunku.

Timer 5 minut to historyczny kompromis. Pierwszy transparent bridge (DEC LANBridge 100) pojawił się w 1986 roku, a pomysł narodził się "pewnego wieczoru w 1983 roku". Wartość 5 minut prawdopodobnie dobrano tak, żeby była niższa niż czas potrzebny na odłączenie stacji roboczej, przeniesienie jej do innego pokoju i ponowne podłączenie.

W erze EVPN i nowoczesnych data center te domyślne timery mogą być problematyczne. Cisco NX-OS pokazuje, że można wybrać lepsze wartości:

• MAC aging: 1800 s (vs 300 s w EOS)
• ARP timeout: 1500 s (vs 14400 s w EOS)
• ND stale timer: 1380 s

Kluczowa obserwacja z komentarzy do oryginalnego artykułu: ARP timeout powinien być niższy niż MAC aging. Wtedy odpowiedź ARP odświeża wpis MAC, co redukuje unknown unicast flooding dla cichych hostów. Przy odwrotnej relacji (jak w EOS) ryzykujesz, że ważny wpis MAC wygaśnie, zanim host zdąży odświeżyć ARP.

Dzień z życia sieciowca

neteng.life — It’s always DNS.

What it’s like to be a network engineer. It’s always DNS. Until it’s BGP.

Symulator dyżuru 3 nad ranem, generowanie wymówek i ściana bólu – każdy problem to prawdziwa historia. Jeśli chcesz poczuć, jak to jest być sieciowcem, zanurz się w ten świat pełen RTFM i niekończących się wyzwań.

Asystent AI dla operacji sieciowych

GitHub - nkxy007/workerxy: network AI agents using Langchain deepagent SDK

network AI agents using Langchain deepagent SDK. Contribute to nkxy007/workerxy development by creating an account on GitHub.

GitHubnkxy007

WorkerXY to zaawansowany asystent AI dla operacji sieciowych i automatyzacji. Ułatwia diagnostykę sieci, zarządzanie chmurą i operacje w centrach danych – od wykrywania problemów po zarządzanie globalnymi klastrami AWS. Wyposażony w agentów specjalistycznych, pamięć długoterminową oraz autonomiczne zadania, pozwala na pełną kontrolę i automatyzację procesów.

FortiGate CLI: 5 poleceń, które zmienią sposób w jaki pracujesz