juli 2, 2020
Articles
Ingen kommentarer

Hvad er grundene til at se en ufuldstændig ARP?

Som nævnt i dette indlæg :

Årsagen for at se en ufuldstændig ARP er, at “Der blev sendt en ARP-anmodning for den adresse, men værten med den adresse kører ikke på LAN, så der er ikke noget svar”

Så hvis en flerlags-switch sender en ARP-anmodning til en server og ikke får noget svar, markeres ARP som ufuldstændig i switch-ARP-tabellen.

Men hvad nu hvis serveren sender en ARP-anmodning til skifte, men modtager ikke svar? Viser serveren ufuldstændig ARP i sin ARP-tabel, og kontakten viser ingen post?

Hvis vi antager, at ovenstående er korrekt, kan vi sige, at hvis du ser den ufuldstændige ARP-post på en lokal enhed, er problemet er med enheden i den anden ende af forbindelsen (eller kabler)? Eller er der nogle undtagelser?

Kommentarer

  • Som @RonTrunk påpeger, er en switch en gennemsigtig lag-2-enhed, der ikke kender eller plejer om lag-3 (IP) -adressering, så det ‘ t bruger eller reagerer på ARP. Omskifteren styres muligvis, så styringen af switchen er som en vært på netværket, og den har en lag-3-grænseflade, der bruger og reagerer på ARP, men det har intet at gøre med skiftefunktionen, som stadig ikke ved noget omkring lag-3. Forveks ikke ‘ t ARP på lag-3-enheder med MAC-adressetabellen for switche. Mange mennesker forveksler dem.
  • Virker kontakten som L3-gatewayen eller bare som en L2-switch?
  • @cpt_fink, ja ved ” switch ” Jeg mente en multilayer switch (L3 gateway)

Svar

For en lag-3-switch er lag-3-modulet i kontakten en router, og den fungerer ligesom en router, der fungerer som enhver anden vært for ARP. En lag-3-switch er stadig primært en layer-2-switch, og laget-2-switch fungerer stadig ligesom en layer-2-switch. Lag-3 og lag-2 dele af en lag-3 switch er virkelig adskilte. Lag-3-grænsefladerne (både virtuelle grænseflader og fysiske grænseflader konfigureret som lag-3-grænseflader) bruger en ARP-tabel, men lag-2-grænsefladerne bruger en MAC-adressetabel.

Når en vært, inklusive en router eller routingsmodulet i en lag-3-switch, sender en ARP-anmodning og modtager intet svar, markerer den ARP-tabelindgangen som incomplete.

Men hvad hvis serveren sender en ARP-anmodning til switchen, men ikke modtager svar? Viser serveren ufuldstændig ARP i sin ARP-tabel, og kontakten viser ingen post?

Det afhænger. Hvis en vært sender en ARP-anmodning til en anden vært, inklusive en router, men den endnu ikke har modtaget et svar, markeres værts-ARP-tabelindgangen incomplete for routerens IPv4-adresse.

Hvad routeren har i sin ARP-tabel, afhænger af, om routeren fik ARP-anmodningen eller ej, og om routeren allerede har en ARP-tabelindgang for værten eller ej.

  • En router med en eksisterende ARP-tabelindgang for værten vil fortsat have denne post, indtil routeren renser den på grund af en timeout. Timeout er ikke påkrævet af RFC, men RFC har et afsnit, der beskæftiger sig med muligheden for at bruge en timeout til ARP-tabelindgange, og de fleste værter gør dette:

    Det kan være ønskeligt at have tabel aldring og / eller timeouts. Implementeringen af disse er uden for denne protokols rækkevidde.

  • Hvis routeren aldrig modtog ARP-anmodningen, og den ikke havde nogen post til værten, vil der ikke være nogen post i routerens ARP-tabel.
  • Hvis routeren modtog ARP-anmodningen fra værten, men svaret tilbage til værten mistede, vil routeren have en komplet ARP tabelindgang for værten.

For at forstå, hvordan ARP fungerer, skal du læse RFC 826, An Ethernet-adresseopløsningsprotokol – eller – konvertering af netværksprotokoladresser til 48. bit Ethernet-adresse til transmission på Ethernet-hardware . Husk, at ARP fungerer for IPv4, men ikke for IPv6, som har ND (Neighbor Discovery) i stedet for ARP.

Svar

En vellykket ARP-opløsning er påkrævet for at to IPv4-noder skal kommunikere på et fælles lag-2-segment (normalt Ethernet).

Ufuldstændige ARP-anmodninger har to grundlæggende årsager.

  1. ARP-anmodningen er ikke blevet besvaret. Enten har destinationsnoden ikke modtaget ARP-anmodningen, eller dens svar er ikke modtaget. Destinationsknudepunktet er muligvis nede.

  2. Kildeknudens netværksmaske er ikke konfigureret korrekt.Kildeknudepunktet betragter alle destinationer inden for sit eget subnet lokale eller on-link: det forventer at være i stand til at tale med dem direkte via sin Ethernet-grænseflade uden hjælp fra en gateway-router.

    Når f.eks. en knude inden for 192.168.0.0/24 undernettet er forkert opsat med 192.168.0.10/16 den betragter en destination som 192.168.16.1 lokal. Det forsøger ikke at bruge en gateway, men forsøger en direkte ARP, der forbliver ufuldstændig.

Uanset om kilden eller destinationen / næste hopknudepunkt er en router, multi-lags switch eller slutknudepunkt betyder ikke noget.

Svar

Switchens ARP-tabel bruges kun af switch management interface til IP-trafik genereret af selve kontakten.

Ellers ser switches kun på info om lag 2. De forstår ikke ARP.

Kommentarer

  • ja, jeg mente en flerlags-switch

Svar

En anden mulig årsag – dhcpcd forkerte indstillinger

Jeg tilføjer dette svar, selvom det (sandsynligvis) ikke er direkte relateret til det specifikke spørgsmål ovenfor, er det relevant i nogle tilfælde

Hvis en systemstatisk ip / dhcp-indstilling er forkert, er dette kan dukke op som en indirekte bivirkning.

I mit specifikke tilfælde havde jeg en Linux-maskine, som jeg flyttede placeringer og ændrede netværksindstillinger ngs for.

Jeg glemte at opdatere dem i /etc/dhcpcd.conf, da jeg flyttede maskinen tilbage igen.

Dette er mit 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 ” brudt “, jeg fik linjen static routers=192.168.1.254 kommenteret, og linjen under #static routers=192.168.1.1 var ikke kommenteret.

Dette fik derefter arp til at vise en ugyldig post (” ufuldstændig “) for adressen 192.168.1.1.

Selvom jeg kun flyttede dette system for en uge siden og derefter flyttede det tilbage for et par dage siden, havde jeg absolut ingen anelse om, hvad der var galt med det. Så vidt jeg vidste, kunne jeg forbinde det til mit lokale netværk, ssh ind i det fint, og der var ingen problemer, der dukkede op med ip addr. traceroute viste heller ikke nogen nyttig info, det foreslog bare, at alle forespørgsler skulle via et enkelt hop til ” maskinstatens navn “. Det gav åbenbart ingen mening og var forkert, men det gav mig ikke nogen indikation af, hvad problemet var – det antydede, at alle forespørgsler blev løst (på en eller anden måde) på samme maskine. Denne maskine gør DNS forresten.

Ikke direkte relateret til spørgsmålet om OP, men kan være meget nyttigt for andre, der har dette problem i fremtiden, og det er den eneste måde, du hidtil har fundet til diagnosticere det, da ikke meget andet ser ud til at være forkert!

Bare nogle bemærkninger til, hvordan jeg diagnosticerede dette

  • Når jeg bruger denne maskine som DNS-server til andre maskiner på netværk, kunne disse maskiner ikke løse eksterne DNS-anmodninger
  • Jeg kunne ssh ind på DNS-serveren (det kunne forventes, da dens IP er indstillet statisk, og switch / routeren forventer også at se en maskine med dette statisk IP tilsluttet på det lokale Ethernet via kontakten).
  • Den første ting, der angav et eller andet problem, var sudo apt update mislykkedes. (Da dette er en DNS-server, har den ingen grafisk grænseflade, og selvom det at køre noget som en webbrowser ville have indikeret dette problem meget hurtigere, eller fra ikonet Netværks-skrivebordsbakken, har det ikke nogen af disse ting.)
  • ping 8.8.8.8 mislykkedes også, men ssh og pinging af lokale maskiner var fint
  • Jeg kontrollerede /etc/network/interfaces[.d] dog var alle filer i disse dirs tomme / indstillet til standardindstillinger, da DNS-softwaren administrerer disse
  • Der var ingen fejl / advarsler i DNS-softwaren, når du opretter forbindelse til DNS-serveren via den medfølgende webgrænseflade
  • Jeg begyndte at kontrollere ting som ip addr (ingen problemer) og arp. Jeg har allerede sagt traceroute angav ikke, hvad problemet kunne være, men antydede, at der var noget underligt.
  • Søgning efter grunde til, at arp muligvis har en ufuldstændig post, der førte mig langs de rigtige linjer
  • Jeg fandt dette spørgsmål ( https://serverfault.com/questions/765380/when-do-stale-arp-entries-become-failed-when-never-used ) og begyndte at undersøge, hvordan man fjerner arp-poster
  • Jeg fjerner posten med arp -d 192.168.1.1
  • Men det blev ved med at komme tilbage
  • Jeg forsøgte at oprette forbindelse til 192.168.1.1 på mit lokale netværk fra et andet maskine, men jeg blev ikke overrasket over, at jeg ikke kunne gøre det eller ping det, fordi der ikke er nogen maskiner på mit netværk med denne adresse
  • Normalt ville denne adresse være adressen på din gateway / en ISP-router i hjemmeapplikationer
  • Dette mindede mig om, at jeg havde indstillet en netværksadapter den anden placering til at have adressen 192.168.1.1, og at computeren, der var forbundet til denne adresse blev brugt som en router til at forbinde netværket 192.168.0.X og 192.168.1.X
  • Den oprindelige placering er på netværket 192.168.1.X, placeringen jeg flyttede til var på 192.168.0.X
  • Da de fleste 192.168.1.X/24 netværk bruger 192.168.1.1 som standard gateway, da denne IP ikke oprindeligt vækkede mistanke, og det virkede ikke ” underlig ” af en eller anden grund
  • Men jeg ændrede standardgatewayen i dhcpcd.conf som beskrevet ovenfor, og problemet blev løst
  • Lærdommen, når du opretter et underligt computer-til-computer-netværk uden for webstedet, skal du give routeradapteren / NIC en underlig statisk IP som 192.168.1.50 – der kan hjælpe med at minde sig selv eller angive, at noget ud over det sædvanlige er angivet i en indstillingsfil et sted

Kommentarer

  • Desværre er host- / serverkonfigurationer ikke-emne her, men kan håndteres på Serverfejl for en forretning s netværk.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *