U přepínače vrstvy 3 je modul vrstvy 3 v přepínači směrovač a funguje stejně jako směrovač, který funguje jako každý jiný hostitel pro ARP. Přepínač vrstvy 3 je stále primárně přepínačem vrstvy 2 a přepínač vrstvy 2 stále funguje stejně jako přepínač vrstvy 2. Části přepínače vrstvy 3 a vrstvy 2 jsou opravdu oddělené. Rozhraní vrstvy 3 (jak virtuální rozhraní, tak všechna fyzická rozhraní nakonfigurovaná jako rozhraní vrstvy 3) budou používat tabulku ARP, ale rozhraní vrstvy 2 budou používat tabulku MAC adres.

Když hostitel, včetně směrovače nebo směrovacího modulu v přepínači vrstvy 3, odešle požadavek ARP a neobdrží žádnou odpověď, označí záznam tabulky ARP jako incomplete.

Ale co když server pošle přepínači požadavek ARP, ale nedostane odpověď? Bude server zobrazovat neúplné ARP ve své tabulce ARP a přepínač nebude zobrazovat žádnou položku?

To záleží. Pokud hostitel odešle požadavek ARP jinému hostiteli, včetně routeru, ale dosud neobdržel odpověď, bude položka tabulky ARP hostitele označena incomplete pro adresu IPv4 routeru.

To, co má router ve své tabulce ARP, závisí na tom, zda směrovač dostal požadavek ARP, a zda již router má pro hostitele položku tabulky ARP.

• Směrovač s existujícím záznamem tabulky ARP pro hostitele bude mít tuto položku i nadále, dokud ji router nevyprší z důvodu časového limitu. Časový limit není nařízen RFC, ale RFC má sekci, která se zabývá možností použití časového limitu pro položky tabulky ARP, a většina hostitelů to dělá:

  Může být žádoucí mít stárnutí tabulky nebo vypršení časového limitu. Jejich implementace je mimo rámec tohoto protokolu.

• Pokud router nikdy neobdržel požadavek ARP a neměl žádný záznam pro hostitele, nebude v tabulce routeru ARP žádná položka.
• Pokud router obdržel požadavek ARP od hostitele, ale odpověď zpět na hostitele se ztratila, router bude mít kompletní ARP položka tabulky pro hostitele.

Abyste pochopili, jak ARP funguje, měli byste si přečíst RFC 826, An Ethernet Address Resolution Protocol – nebo – Převod adres síťového protokolu na 48bitovou ethernetovou adresu pro přenos na ethernetovém hardwaru . Nezapomeňte, že ARP funguje pro IPv4, ale ne pro IPv6, který má místo ARP ND (Neighbor Discovery).

Úspěšné rozlišení ARP je vyžadováno pro dva uzly IPv4 ke komunikaci na společném segmentu vrstvy 2 (obvykle Ethernet).

Neúplné požadavky ARP mají dva základní důvody.

1. Žádost ARP nebyla zodpovězena. Buď cílový uzel neobdržel požadavek ARP, nebo jeho odpověď nebyla přijata. Cílový uzel může být nefunkční.

2. Maska sítě zdrojového uzlu není správně nakonfigurována.Zdrojový uzel považuje všechny cíle v rámci své vlastní podsítě za místní nebo on-link: očekává, že s nimi bude moci hovořit přímo přes své ethernetové rozhraní bez pomoci routeru brány.

   Když např. uzel v podsíti 192.168.0.0/24 je nesprávně nastaven na 192.168.0.10/16 považuje za cíl jako 192.168.16.1 místní. Nezkouší použít bránu, ale pokusí se o přímý ARP, který zůstane neúplný.

Ať už je zdrojovým nebo cílovým / dalším uzlem směrování směrovač, vícevrstvý přepínač nebo koncový uzel na tom nezáleží.

Tabulka ARP přepínače je používána pouze rozhraním správy přepínače pro provoz IP generováno samotným přepínačem.

Jinak se přepínače dívají pouze na informace vrstvy 2. Nerozumí ARP.

Komentáře

• ano, myslel jsem vícevrstvý přepínač

další možný důvod – dhcpcd nesprávné nastavení

Přidávám tuto odpověď, i když (pravděpodobně) přímo nesouvisí s konkrétní výše uvedenou otázkou, je v některých případech relevantní

Pokud je statické nastavení systému ip / dhcp nesprávné, toto se může projevit jako nepřímý vedlejší účinek.

V mém konkrétním případě jsem měl stroj s Linuxem, který jsem přesunul na jiné místo a změnil nastavení sítě ngs for.

Zapomněl jsem je aktualizovat v /etc/dhcpcd.conf, když jsem stroj přesunul zpět.

Toto je moje dhcpcd.conf

interface eth0 static ip_address=192.168.1.8/24 static routers=192.168.1.254 #static routers=192.168.1.1 static domain_name_servers=127.0.0.1 

Když to bylo “ rozbité „, nechal jsem řádek static routers=192.168.1.254 okomentovat a řádek pod #static routers=192.168.1.1 byl nekomentovaný.

To pak způsobilo, že arp zobrazí neplatný záznam (“ neúplný „) pro adresa 192.168.1.1.

I když jsem tento systém přesunul teprve před týdnem, poté jsem ho před několika dny přesunul zpět, neměl jsem absolutně žádnou představu o tom, co se děje s tím. Pokud jsem mohl říct, mohl jsem to připojit k mé místní síti, ssh do ní dobře, a nebyly žádné problémy s ip addr. traceroute také neukazoval žádné užitečné informace, jen naznačil, že všechny dotazy šly jedním skokem na “ název hostitele stroje „. Je zřejmé, že to nemělo smysl a bylo to špatné, ale nedalo mi to žádnou informaci o tom, o jaký problém jde – to znamenalo, že všechny dotazy byly (nějak) vyřešeny na stejný stroj. Mimochodem tento stroj dělá DNS.

Nesouvisí přímo s otázkou OP, ale může být velmi užitečný pro ostatní, kteří mají tento problém v budoucnu, a toto je jediný způsob, jak jste dosud našli diagnostikovat to, protože nic jiného se zdá být špatně!

Jen pár poznámek o tom, jak jsem to diagnostikoval

• Při použití tohoto stroje jako serveru DNS pro jiné stroje na v síti, tyto stroje nebyly schopny vyřešit externí požadavky DNS
• Mohl jsem ssh na server DNS (to by se dalo očekávat, protože jeho IP je nastavena statická a přepínač / router také očekává, že uvidí stroj s tímto statická adresa IP připojená k místnímu ethernetu přes přepínač).
• První věc, která naznačila určitý problém, byla chyba sudo apt update. (Jelikož se jedná o server DNS, nemá žádné grafické rozhraní, a proto ačkoliv spuštění něčeho podobného jako webový prohlížeč by tento problém označilo mnohem dříve, nebo z ikony na hlavním panelu Síť na ploše nic z toho nemá.)
• ping 8.8.8.8 také selhával, nicméně ssh a ping na místních strojích byly v pořádku
• Zkontroloval jsem /etc/network/interfaces[.d] všechny soubory v těchto adresářích však byly prázdné / nastaveny na výchozí hodnoty, protože je spravuje software DNS
• Při připojování k serveru DNS prostřednictvím dodaného webového rozhraní nebyly v softwaru DNS žádné chyby / varování
• Začal jsem kontrolovat věci jako ip addr (žádné problémy) a arp. Už jsem řekl nenaznačoval, v čem by mohl být problém, ale naznačil něco, co se děje divné.
• Hledání důvodů, proč by arp mohl mít neúplný záznam, mě vedl správnými řádky
• Našel jsem tuto otázku ( https://serverfault.com/questions/765380/when-do-stale-arp-entries-become-failed-when-never-used ) a začal hledat způsob, jak odstranit položky arp
• Položku odstraním pomocí arp -d 192.168.1.1
• Stále se to však vracelo
• Snažil jsem se připojit k 192.168.1.1 v místní síti z jiné stroj, ale nepřekvapilo mě, že jsem to nemohl udělat ani pingnout, protože v mé síti nejsou žádné stroje s touto adresou.
• Obvykle by touto adresou byla adresa vaší brány / routeru ISP v domácí aplikace
• To mi připomnělo, že jsem nastavil síťový adaptér v jiném umístění tak, aby měl adresu 192.168.1.1 a že počítač, který byl k této adrese připojen byl používán jako router pro připojení k sítím 192.168.0.X a 192.168.1.X
• Původní umístění je v síti 192.168.1.X, místo, kam jsem se přestěhoval, bylo 192.168.0.X
• protože většina 192.168.1.X/24 sítě používají 192.168.1.1 jako výchozí bránu, protože tato IP adresa zpočátku nevzbudila žádné podezření a nezdá se “ divný “ z jakéhokoli důvodu
• Výchozí bránu jsem však změnil v dhcpcd.conf jak je popsáno výše a problém byl vyřešen
• Poučení, při dočasném vytváření podivné sítě typu počítač z počítače mimo web poskytněte adaptéru / NIC routeru podivnou statickou IP adresu jako 192.168.1.50 – to by mohlo pomoci někomu připomenout nebo naznačit něco neobvyklého, je někde nastaveno v souboru nastavení

Komentáře

• Bohužel zde nejsou konfigurace hostitele / serveru mimo téma, ale lze je zpracovat při chybě serveru pro busines s.