Rozdíl mezi výpadkem ip odkazu a absencí fyzického odkazu

Existuje rozdíl mezi rozhraním, které je administrativně nahoru ale odpojeno nebo administrativně nefunkční .

Odpojeno

Rozhraní dostane nosnou dolů postavení. Jeho správná manipulace může záviset na ovladači rozhraní a verzi jádra. Normálně je k dispozici s ip link show . Například pomocí virtuálního ethernetu veth rozhraní:

# ip link add name vetha up type veth peer name vethb
# ip link show type veth
2: [email protected]: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 02:a0:3b:9a:ad:4d brd ff:ff:ff:ff:ff:ff
3: [email protected]: <NO-CARRIER,BROADCAST,MULTICAST,UP,M-DOWN> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 36:e3:62:1b:a8:1f brd ff:ff:ff:ff:ff:ff

vetha který je sám o sobě administrativně UP, zobrazuje NO-CARRIER a ekvivalentní operstate LOWERLAYERDOWN příznaky:je odpojeno.

Ekvivalent /sys/ existují také záznamy:

# cat /sys/class/net/vetha/carrier /sys/class/net/vetha/operstate
0
lowerlayerdown

V obvyklém nastavení pro rozhraní, které je administrativně nahoru přepravce a operstate shodu (NO-CARRIER <=> LOWERLAYERDOWN nebo LOWER_UP <=> UP). Jedna výjimka by byla například při použití ověřování IEEE 802.1X (pokročilé podrobnosti o operstate jsou popsány v této dokumentaci jádra:Provozní stavy, ale pro toto vysvětlení to není potřeba).

ethtool dotazuje rozhraní API nižší úrovně, aby získal stejný stav operátora.

To, že nemáte žádný nosič, nebrání tomu, aby nastavení vrstvy 3 zůstalo v platnosti. Když k tomu dojde, jádro nemění adresy ani trasy. Prostě paket, který by měl být vyslán, nakonec rozhraní nevyšle a samozřejmě nepřijde ani žádná odpověď. Takže například pokus o připojení k jiné IPv4 adrese dříve nebo později znovu spustí požadavek ARP, který se nezdaří a aplikace obdrží "No route to host". Navázaná připojení TCP si jen vyžádají čas a zůstanou navázaná.

Administrativně dolů

Nad vethb má provozní stav DOWN a nezobrazuje žádný stav přenašeče (protože musí být nahoře, aby to detekoval. Fyzické rozhraní Ethernet se samozřejmě chová stejně).

Když je rozhraní vypnuto (ip link set ... down ), přenašeč již nemůže být detekován, protože základní hardwarové zařízení bylo velmi pravděpodobně vypnuto a provozní stav je „dole“. ethtool jen řekne, že tam taky není žádný odkaz, takže to pro to nelze spolehlivě použít (určitě zobrazí několik neznámých záznamy také, ale existuje pro to spolehlivé schéma?).

Tentokrát to bude mít vliv na nastavení sítě 3. vrstvy. Jádro odmítne přidávat cesty pomocí tohoto rozhraní a odstraní všechny předchozí cesty s ním související:

• automatické (proto kernel ) LAN trasy přidané při přidávání adresy
• jakákoli další přidaná trasa (např.:výchozí trasa) v jakékoli směrovací tabulce (nejen hlavní směrovací tabulka) v závislosti přímo na rozhraní (scope link ) nebo na jiných předchozích smazaných trasách (pravděpodobně pak scope global ). Tyto se po obnovení rozhraní znovu neobjeví (ip link set ... up ) jsou ztraceny, dokud je nástroj uživatelského prostoru nepřidá zpět.

Interakce v uživatelském prostoru

Při použití nedávných nástrojů, jako je NetworkManager, se člověk může zmást a může si myslet, že odpojení je podobné vypnutí rozhraní. Je to proto, že NM monitoruje odkazy a provede akce, když k takovým událostem dojde. Pro představu ip monitor nástroj lze použít k monitorování ze skriptů, ale aktuálně nemá stabilní/parsovatelný výstup (není k dispozici výstup JSON), takže jeho použití je omezené.

Takže když je vodič odpojen, NM velmi pravděpodobně uváží, že již nepoužívá současnou konfiguraci, pokud tomu nebrání specifické nastavení:pak smaže adresy a trasy sám. Když je drát připojen zpět, NM znovu použije svou konfiguraci:přidá zpětné adresy a trasy (pomocí DHCP, pokud je to relevantní). Tohle vypadá stejně, ale není. Po celou tu dobu zůstalo rozhraní aktivní nebo by ani nebylo možné, aby byl NM varován, když bylo spojení obnoveno.

Shrnutí

• Je snadné rozlišit tyto dva případy:ip link show zobrazí NO-CARRIER +LOWERLAYERDOWN pro odpojené rozhraní a DOWN pro rozhraní administrativně zrušené.

• nastavením rozhraní administrativně dolů (a nahoru) může dojít ke ztrátě tras

• ztráta operátora a jeho obnovení nenaruší nastavení sítě. Pokud je zpoždění dostatečně krátké, nemělo by to narušit ani probíhající síťová připojení

• ale aplikace spravující síť mohou zareagovat a změnit nastavení sítě, někdy s výsledkem podobným případu administrativy

• můžete použít příkazy jako ip monitor link pro příjem událostí o rozhraních nastavených administrativně dolů/nahoru nebo o změnách operátora nebo ip monitor přijímat všechny související události (včetně změn adresy nebo trasy), ke kterým by došlo v tuto chvíli nebo krátce poté.

• Nejvíce ip příkazy (ale ne ip monitor ) mít k dispozici výstup JSON s ip -json ... pro pomocné skripty (spolu s jq ).

  Příklad (pokračování od prvního veth příklad):

  vethb je stále dole:

  # ip -j link show dev vethb | jq '.[].operstate'
  "DOWN"
  
  # ip -j link show dev vetha | jq '.[].operstate'
  "LOWERLAYERDOWN"
  

  Nastavte vethb up, který nyní získá dopravce na obou:

  # ip link set vethb up
  # ip -j link show dev vetha | jq '.[].operstate'
  "UP"
  

  To vypovídá o 3 obvyklých stavech:administrativně dolů , dolní vrstva (tj.:nahoru, ale odpojeno) nebo nahoru (tj.:funkční).