Som nevnt i dette innlegget :
Årsaken for å se en ufullstendig ARP er at «En ARP-forespørsel ble sendt for den adressen, men verten med den adressen er ikke oppe og kjører på LAN, så det er ikke noe svar»
Så hvis en flerlagsbryter sender en ARP-forespørsel til en server og ikke får noe svar, blir ARP markert som ufullstendig i bryter-ARP-tabellen.
Men hva om serveren sender en ARP-forespørsel til bytte, men mottar ikke svar? Vil serveren vise ufullstendig ARP i ARP-tabellen, og bryteren ikke viser noen oppføring?
Hvis vi antar at det ovennevnte er riktig, kan vi si at hvis du ser den ufullstendige ARP-oppføringen på en lokal enhet, er problemet er med enheten i den andre enden av tilkoblingen (eller kabling)? Eller er det noen unntak?
Kommentarer
- Som @RonTrunk påpeker, er en bryter en gjennomsiktig lag-2-enhet som ikke vet eller bryr seg om lag-3 (IP) adressering, så den ‘ t bruker eller svarer på ARP. Bryteren kan administreres, så styringen av bryteren er som en vert i nettverket, og den har et lag-3-grensesnitt som bruker og reagerer på ARP, men det har ingenting å gjøre med byttefunksjonen, som fremdeles ikke vet noe om lag-3. Ikke forveksle ‘ t ARP på lag-3-enheter med MAC-adressetabellen for brytere. Mange forvirrer dem.
- Fungerer bryteren som L3-gateway, eller bare som en L2-bryter?
- @cpt_fink, ja av » switch » Jeg mente en flerlagsbryter (L3 gateway)
Svar
For en lag-3-bryter er lag-3-modulen i bryteren en ruter, og den fungerer akkurat som en ruter, som fungerer som alle andre verter for ARP. En lag-3-bryter er fremdeles primært en lag-2-bryter, og lag-2-bryteren fungerer fortsatt akkurat som en lag-2-bryter. Lag-3 og lag-2 delene av en lag-3-bryter er virkelig separate. Lag-3-grensesnittene (både virtuelle grensesnitt og fysiske grensesnitt konfigurert som lag-3-grensesnitt) vil bruke en ARP-tabell, men lag-2-grensesnittene vil bruke en MAC-adressetabell.
Når en vert, inkludert en ruter eller rutemodulen i en lag-3-bryter, sender en ARP-forespørsel og mottar ikke noe svar, markerer den ARP-tabelloppføringen som incomplete.
Men hva om serveren sender en ARP-forespørsel til bryteren, men ikke får svar? Vil serveren vise ufullstendig ARP i ARP-tabellen, og bryteren ikke viser noen oppføring?
Det avhenger. Hvis en vert sender en ARP-forespørsel til en annen vert, inkludert en ruter, men den ennå ikke har mottatt svar, blir verts-ARP-tabelloppføringen merket incomplete for ruteren IPv4-adresse.
Hva ruteren har i ARP-tabellen, avhenger av om ruteren fikk ARP-forespørselen eller ikke, og om ruteren allerede har en ARP-tabelloppføring for verten.
-
En ruter med en eksisterende ARP-tabelloppføring for verten vil fortsette å ha den oppføringen til ruteren renser den på grunn av et tidsavbrudd. Tidsavbruddet er ikke pålagt av RFC, men RFC har en seksjon som omhandler muligheten for å bruke en timeout for ARP-tabelloppføringer, og de fleste verter gjør dette:
Det kan være ønskelig å ha aldring i tabellen og / eller tidsavbrudd. Implementeringen av disse er utenfor rammen av denne protokollen.
- Hvis ruteren aldri mottok ARP-forespørselen, og den ikke hadde noen oppføring for verten, vil det ikke være noen oppføring i ruteren ARP-tabellen.
- Hvis ruteren mottok ARP-forespørselen fra verten, men svaret tilbake til verten mistet, vil ruteren ha en fullstendig ARP tabelloppføring for verten.
For å forstå hvordan ARP fungerer, bør du lese RFC 826, An Ethernet Address Resolution Protocol – eller – Konvertering av nettverksprotokolladresser til 48. bit Ethernet-adresse for overføring på Ethernet-maskinvare . Husk at ARP fungerer for IPv4, men ikke for IPv6, som har ND (Neighbor Discovery) i stedet for ARP.
Svar
En vellykket ARP-oppløsning er nødvendig for at to IPv4-noder skal kommunisere på et felles lag-2-segment (vanligvis Ethernet).
Ufullstendige ARP-forespørsler har to grunnleggende årsaker.
-
ARP-forespørselen er ikke besvart. Enten har destinasjonsknutepunktet ikke mottatt ARP-forespørselen, eller svaret har ikke blitt mottatt. Målnoden kan være nede.
-
Kildenodens nettverksmaske er ikke riktig konfigurert.Kildekoden tar hensyn til alle destinasjoner innenfor sitt eget subnett lokale eller on-link: den forventer å kunne snakke med dem direkte via Ethernet-grensesnittet, uten hjelp fra en gateway-ruter.
Når f.eks. en node i 192.168.0.0/24 undernettet er feil satt opp med 192.168.0.10/16 den anser en destinasjon som 192.168.16.1 lokal. Den vil ikke prøve å bruke en gateway, men prøve en direkte ARP som forblir ufullstendig.
Enten kilden eller destinasjonen / neste hoppnode er en ruter, flerlagsbryter eller sluttnode spiller ingen rolle.
Svar
Bryterens ARP-tabell brukes bare av bryteradministrasjonsgrensesnittet for IP-trafikk generert av selve bryteren.
Ellers ser brytere bare på info om lag 2. De forstår ikke ARP.
Kommentarer
- ja, jeg mente en flerlagsbryter
Svar
En annen mulig årsak – dhcpcd feil innstillinger
Jeg legger til dette svaret, selv om det (sannsynligvis) ikke er direkte relatert til det spesifikke spørsmålet ovenfor, er det aktuelt i noen tilfeller
Hvis en systemstatisk ip / dhcp-innstilling er feil, er dette kan vises som en indirekte bivirkning.
I mitt spesifikke tilfelle hadde jeg en Linux-maskin som jeg flyttet steder og endret nettverksoppsettet ngs for.
Jeg glemte å oppdatere dem i /etc/dhcpcd.conf, da jeg flyttet maskinen tilbake igjen.
Dette er min 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 Når det var » ødelagt «, jeg fikk kommentert linjen static routers=192.168.1.254, og linjen under #static routers=192.168.1.1 var ikke kommentert.
Dette førte til at arp viste en ugyldig oppføring (» ufullstendig «) for adressen 192.168.1.1.
Selv om jeg bare flyttet dette systemet for en uke siden, og deretter flyttet det tilbake for noen dager siden, hadde jeg absolutt ingen anelse om hva som var galt med det. Så vidt jeg kunne vite, kunne jeg koble den til mitt lokale nettverk, ssh inn i det fint, og det var ingen problemer som dukket opp med ip addr. traceroute viste ikke nyttig informasjon, det antydet bare at alle spørsmål gikk via et enkelt hop til » maskinens vertsnavn «. Det var tydeligvis ingen mening og var galt, men det ga meg ingen indikasjoner på hva problemet var – det antydet at alle spørsmål ble løst (på en eller annen måte) på samme maskin. Denne maskinen gjør forresten DNS.
Ikke direkte relatert til spørsmålet om OP, men kan være veldig nyttig for andre som har dette problemet i fremtiden, og dette er den eneste måten du hittil har funnet til diagnostiser det, da ikke mye annet ser ut til å være galt!
Bare noen notater om hvordan jeg diagnostiserte dette
- Når jeg bruker denne maskinen som DNS-server for andre maskiner på nettverk, klarte ikke disse maskinene å løse eksterne DNS-forespørsler
- Jeg kunne ssh inn i DNS-serveren (det kan forventes da IP-en er satt statisk, og bryteren / ruteren forventer også å se en maskin med dette statisk IP koblet til det lokale Ethernet via bryteren).
- Det første som indikerte noe problem var
sudo apt updatemislyktes. (Siden dette er en DNS-server, har den ikke noe grafisk grensesnitt, og selv om det å kjøre noe som en nettleser ville ha indikert dette problemet mye tidligere, eller fra ikonet for nettverksskrivebordet, har det ikke noe av det.) -
ping 8.8.8.8mislyktes også, men ssh og pinging av lokale maskiner var greit - Jeg sjekket
/etc/network/interfaces[.d]men alle filene i disse dirs var tomme / satt til standardinnstillinger, ettersom DNS-programvaren administrerer disse - Det var ingen feil / advarsler i DNS-programvaren når du koblet til DNS-serveren via det medfølgende nettgrensesnittet
- Jeg begynte å sjekke ting som
ip addr(ingen problemer) ogarp. Jeg har allerede sagttracerouteangav ikke hva problemet kunne være, men antydet at noe rart foregikk. - Søker etter årsaker til at
arpkan ha en ufullstendig oppføring som førte meg langs de rette linjene - Jeg fant dette spørsmålet ( https://serverfault.com/questions/765380/when-do-stale-arp-entries-become-failed-when-never-used ) og begynte å undersøke hvordan du fjerner arp-oppføringer
- Jeg fjerner oppføringen med
arp -d 192.168.1.1 - Imidlertid fortsatte det å komme tilbake
- Jeg prøvde å koble til
192.168.1.1på mitt lokale nettverk fra et annet maskin, men jeg ble ikke overrasket over at jeg ikke kunne gjøre dette eller pinge det fordi det ikke er maskiner i nettverket mitt med denne adressen - Vanligvis vil denne adressen være adressen til gatewayen / en ISP-router i hjemmeapplikasjoner
- Dette minnet meg om at jeg hadde satt et nettverkskort på det andre stedet for å ha adressen
192.168.1.1, og at datamaskinen som var koblet til denne adressen ble brukt som en ruter for å koble til nettverkene192.168.0.Xog192.168.1.X - Den opprinnelige plasseringen er på nettverket
192.168.1.X, stedet jeg flyttet til var på192.168.0.X - Siden de fleste
192.168.1.X/24nettverk bruker192.168.1.1som standard gateway, da denne IP-en ikke opprinnelig vekket mistanker, og det virket ikke » rare » av en eller annen grunn - Imidlertid endret jeg standard gateway i
dhcpcd.confsom beskrevet ovenfor, og problemet ble løst - Leksjon, når du oppretter et merkelig datamaskin-til-datamaskinnettverk utenfor nettstedet midlertidig, gir ruteadapteren / NIC en merkelig statisk IP som
192.168.1.50– som kan hjelpe til med å minne seg selv eller indikere at noe utenom det vanlige er satt i en innstillingsfil et sted
Kommentarer
- Dessverre er verts- / serverkonfigurasjoner utenfor emnet her, men kan håndteres på Serverfeil for en virksomhet s nettverk.