Voor een layer-3 switch is de layer-3 module in de switch een router, en deze werkt net als een router, die werkt als elke andere host voor ARP. Een laag-3-schakelaar is nog steeds primair een laag-2-schakelaar en de laag-2-schakelaar werkt nog steeds net als een laag-2-schakelaar. De laag-3- en laag-2-delen van een laag-3-schakelaar zijn echt gescheiden. De laag-3-interfaces (zowel virtuele interfaces als eventuele fysieke interfaces die zijn geconfigureerd als laag-3-interfaces) zullen een ARP-tabel gebruiken, maar de laag-2-interfaces zullen een MAC-adrestabel gebruiken.

Als een host, inclusief een router of de routeringsmodule in een Layer-3-switch, een ARP-verzoek verzendt en geen antwoord ontvangt, markeert het de ARP-tabelvermelding als incomplete.

Maar wat als de server een ARP-verzoek naar de switch stuurt maar geen antwoord ontvangt? Zal de server onvolledige ARP weergeven in zijn ARP-tabel en zal de schakelaar geen invoer weergeven?

Dat hangt ervan af. Als een host een ARP-verzoek verzendt naar een andere host, inclusief een router, maar nog geen antwoord heeft ontvangen, wordt het item in de ARP-tabel van de host gemarkeerd met incomplete voor het IPv4-adres van de router.

Wat de router in zijn ARP-tabel heeft, hangt af van het feit of de router het ARP-verzoek heeft ontvangen en of de router al een ARP-tabelvermelding voor de host heeft.

• Een router met een bestaande ARP-tabelvermelding voor de host behoudt die invoer totdat de router deze opruimt vanwege een time-out. De time-out wordt niet opgelegd door de RFC, maar de RFC heeft wel een sectie die de mogelijkheid behandelt om een time-out te gebruiken voor ARP-tabelvermeldingen, en de meeste hosts doen dit:

  Het kan wenselijk zijn om tabelveroudering en / of time-outs te hebben. De implementatie hiervan valt buiten het bereik van dit protocol.

• Als de router het ARP-verzoek nooit heeft ontvangen en er geen invoer voor de host, dan is er geen invoer in de ARP-tabel van de router.
• Als de router het ARP-verzoek van de host heeft ontvangen, maar het antwoord aan de host verloren is gegaan, heeft de router een volledige ARP tabelvermelding voor de host.

Voor een begrip van hoe ARP werkt, moet u RFC 826, An Ethernet Address Resolution Protocol – of – Netwerkprotocoladressen converteren naar 48-bits Ethernet-adres voor verzending op Ethernet-hardware . Onthoud dat ARP werkt voor IPv4, maar niet voor IPv6, dat ND (Neighbor Discovery) heeft in plaats van ARP.

Een succesvolle ARP-resolutie is vereist om twee IPv4-knooppunten te laten communiceren op een gemeenschappelijk laag 2-segment (meestal Ethernet).

Onvolledige ARP-verzoeken hebben twee fundamentele redenen.

1. De ARP-aanvraag werd niet beantwoord. Het bestemmingsknooppunt heeft het ARP-verzoek niet ontvangen of het antwoord is niet ontvangen. Het bestemmingsknooppunt is mogelijk niet beschikbaar.

2. Het netwerkmasker van het bronknooppunt is niet correct geconfigureerd.Het bronknooppunt beschouwt alle bestemmingen binnen zijn eigen subnet lokaal of on-link: het verwacht rechtstreeks met hen te kunnen praten via zijn Ethernet-interface, zonder de hulp van een gateway-router.

   Wanneer bijv. een knooppunt binnen het 192.168.0.0/24 subnet is onjuist ingesteld met 192.168.0.10/16 het beschouwt een bestemming als 192.168.16.1 lokaal. Het zal geen gateway proberen te gebruiken, maar een directe ARP proberen die onvolledig blijft.

Of de bron of de bestemming / volgende hop-node een router is, meerlaagse switch of eindknooppunt doet er niet toe.

De ARP-tabel van de switch wordt alleen gebruikt door de switchbeheerinterface voor IP-verkeer gegenereerd door de switch zelf.

Anders kijken switches alleen naar informatie van laag 2. Ze begrijpen ARP niet.

Reacties

• ja, ik bedoelde een meerlaagse schakelaar

Een andere mogelijke reden – dhcpcd onjuiste instellingen

Ik voeg dit antwoord toe, hoewel het (waarschijnlijk) niet direct gerelateerd is aan de specifieke vraag hierboven, het is in sommige gevallen wel relevant

Als de statische ip / dhcp-instellingen van een systeem onjuist zijn, is dit kan verschijnen als een indirect neveneffect.

In mijn specifieke geval had ik een Linux-machine waarvan ik locaties verplaatste en de netwerkinstellingen veranderde ngs for.

Ik vergat ze bij te werken in /etc/dhcpcd.conf, toen ik de machine weer terugverplaatste.

Dit is mijn 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 

Toen het ” kapot was “, ik heb de regel static routers=192.168.1.254 gereageerd, en de regel eronder #static routers=192.168.1.1 was geen commentaar.

Dit zorgde er vervolgens voor dat arp een ongeldige invoer (” onvolledig “) liet zien voor het adres 192.168.1.1.

Hoewel ik dit systeem pas een week geleden heb verplaatst en een paar dagen geleden weer terug heb gezet, had ik absoluut geen idee wat er aan de hand was ermee. Voor zover ik kon zien, kon ik het verbinden met mijn lokale netwerk, er prima in sshen, en er waren geen problemen met ip addr. traceroute toonde ook geen bruikbare informatie, het suggereerde alleen dat alle zoekopdrachten via een enkele hop naar ” computerhostnaam gingen “. Dat sloeg duidelijk nergens op en was verkeerd, maar het gaf me geen enkele indicatie van wat het probleem was – het impliceerde dat alle vragen (op de een of andere manier) werden opgelost dezelfde machine. Deze machine doet trouwens DNS.

Niet direct gerelateerd aan de kwestie van OP, maar kan erg nuttig zijn voor anderen die dit probleem in de toekomst hebben, en dit is de enige manier die u tot nu toe heeft gevonden om stel het vast, want er lijkt niet veel anders verkeerd te zijn!

Slechts enkele opmerkingen over hoe ik dit diagnosticeerde

• Bij het gebruik van deze machine als de DNS-server voor andere machines op de netwerk, die machines waren niet in staat om externe DNS-verzoeken op te lossen
• Ik zou naar de DNS-server kunnen sshen (dat zou worden verwacht aangezien het IP-adres statisch is ingesteld en de switch / router verwacht ook een machine te zien met deze statische IP verbonden met het lokale ethernet via de switch).
• Het eerste dat een probleem aangaf was sudo apt update mislukt. (Aangezien dit een DNS-server is, heeft het geen grafische interface en daarom, hoewel het draaien van zoiets als een webbrowser dit probleem veel eerder zou hebben aangegeven, of via het netwerkpictogram op het bureaublad, heeft het geen van deze dingen.)
• ping 8.8.8.8 faalde ook, maar ssh en pingen van lokale machines was prima
• Ik controleerde /etc/network/interfaces[.d] alle bestanden in deze mappen waren echter blanco / ingesteld op standaardwaarden, aangezien de DNS-software deze beheert
• Er waren geen fouten / waarschuwingen in de DNS-software bij het verbinden met de DNS-server via de meegeleverde webinterface
• Ik begon dingen te controleren als ip addr (geen problemen) en arp. Ik zei al traceroute gaf niet aan wat het probleem zou kunnen zijn, maar gaf wel aan dat er iets vreemds aan de hand was.
• Zoeken naar redenen waarom arp een onvolledige invoer zou kunnen hebben, leidde me in de goede richting
• Ik vond deze vraag ( https://serverfault.com/questions/765380/when-do-stale-arp-entries-become-failed-when-never-used ) en begon te onderzoeken hoe ik arp-items kon verwijderen
• Ik verwijder het item met arp -d 192.168.1.1
• Het bleef echter terugkomen
• Ik probeerde verbinding te maken met 192.168.1.1 op mijn lokale netwerk vanaf een ander machine, maar het verbaasde me niet dat ik dit niet kon doen of pingen omdat er geen machines op mijn netwerk zijn met dit adres
• Meestal is dit adres het adres van je gateway / een ISP-router in thuistoepassingen
• Dit herinnerde me eraan dat ik een netwerkadapter op de andere locatie had ingesteld met het adres 192.168.1.1, en dat de computer die was verbonden met dit adres werd gebruikt als een router om de netwerken 192.168.0.X en 192.168.1.X
• De oorspronkelijke locatie is op netwerk 192.168.1.X, de locatie waar ik naartoe verhuisde was op 192.168.0.X
• Aangezien de meeste 192.168.1.X/24 netwerken gebruiken 192.168.1.1 als de standaard gateway, aangezien dit IP aanvankelijk geen argwaan wekte, en het leek ook niet ” raar ” om welke reden dan ook
• Ik heb echter de standaardgateway gewijzigd in dhcpcd.conf zoals hierboven beschreven en het probleem is opgelost
• Geleerde les: geef de routeradapter / NIC een vreemd statisch IP-adres als – dat zou kunnen helpen om zichzelf eraan te herinneren of om aan te geven dat iets buitengewoons ergens in een instellingenbestand staat

Opmerkingen

• Helaas zijn host / server-configuraties hier niet relevant, maar kunnen ze worden afgehandeld op Serverfout voor een bedrijf s netwerk.