För en lager-3-omkopplare är lager-3-modulen i omkopplaren en router, och den fungerar precis som en router, som fungerar som alla andra värdar för ARP. En lager-3-omkopplare är fortfarande i första hand en lager-2-omkopplare, och lager-2-omkopplaren fungerar fortfarande precis som en lager-2-omkopplare. Skikt-3 och lager-2 delar av en lager-3-omkopplare är verkligen separata. Lager-3-gränssnitten (både virtuella gränssnitt och alla fysiska gränssnitt som är konfigurerade som lager-3-gränssnitt) använder en ARP-tabell, men lager-2-gränssnitten använder en MAC-adresstabell.

När en värd, inklusive en router eller routing-modulen i en lager-3-switch, skickar en ARP-begäran och får inget svar, den markerar ARP-tabellposten som incomplete.

Men tänk om servern skickar en ARP-begäran till växeln men inte får svar? Kommer servern att visa ofullständig ARP i sin ARP-tabell och växeln visar ingen post?

Det beror på det. Om en värd skickar en ARP-begäran till en annan värd, inklusive en router, men den ännu inte har fått svar kommer värdens ARP-tabellpost att markeras incomplete för routerns IPv4-adress.

Vad routern har i sin ARP-tabell beror på om routern fick ARP-begäran eller inte, och huruvida routern redan har en ARP-tabellpost för värden.

• En router med en befintlig ARP-tabellpost för värden kommer att fortsätta att ha den posten tills routern rensar den på grund av en timeout. Tidsgränsen är inte obligatorisk av RFC, men RFC har ett avsnitt som behandlar möjligheten att använda en timeout för ARP-tabellposter, och de flesta värdar gör detta:

  Det kan vara önskvärt att ha tabellåldring och / eller timeouts. Implementeringen av dessa ligger utanför detta protokolls räckvidd.

• Om routern aldrig fick ARP-begäran och den inte hade någon post för värden, kommer det inte att finnas någon post i routerns ARP-tabell.
• Om routern fick ARP-begäran från värden, men svaret tillbaka till värden tappades bort, kommer routern att ha en komplett ARP tabellpost för värden.

För att förstå hur ARP fungerar bör du läsa RFC 826, An Ethernet Address Resolution Protocol – eller – Konvertering av nätverksprotokolladresser till 48.bit Ethernet-adress för överföring på Ethernet-maskinvara . Kom ihåg att ARP fungerar för IPv4, men inte för IPv6, som har ND (Neighbor Discovery) istället för ARP.

En framgångsrik ARP-upplösning krävs för att två IPv4-noder ska kunna kommunicera på ett gemensamt lager-2-segment (vanligtvis Ethernet).

Ofullständiga ARP-förfrågningar har två grundläggande skäl.

1. ARP-begäran har inte besvarats. Antingen har destinationsnoden inte mottagit ARP-begäran eller dess svar har inte mottagits. Målnoden kan vara nere.

2. Källnodens nätverksmask är inte korrekt konfigurerad.Källnoden tar hänsyn till alla destinationer inom sitt eget subnät lokalt eller on-link: det förväntar sig att kunna prata med dem direkt via sitt Ethernet-gränssnitt utan hjälp av en gateway-router.

   När t.ex. en nod inom undernätet 192.168.0.0/24 är felaktigt inställd med 192.168.0.10/16 den betraktar en destination som 192.168.16.1 lokal. Det kommer inte att försöka använda en gateway utan försöka en direkt ARP som förblir ofullständig.

Oavsett om källan eller destinationen / nästa hoppnod är en router, flerlagersomkopplare eller slutnod spelar ingen roll.

Switchens ARP-tabell används endast av switchhanteringsgränssnittet för IP-trafik genereras av själva omkopplaren.

I annat fall ser omkopplare bara information om lager 2. De förstår inte ARP.

Kommentarer

• ja, jag menade en flerlagersomkopplare

En annan möjlig anledning – dhcpcd felaktiga inställningar

Jag lägger till det här svaret, även om det (troligen) inte är direkt relaterat till den specifika frågan ovan, är det i vissa fall relevant

Om systemstatiska ip / dhcp-inställningar är felaktiga är detta kan visas som en indirekt bieffekt.

I mitt specifika fall hade jag en Linux-maskin som jag flyttade platser och ändrade nätverksinställningar ngs för.

Jag glömde att uppdatera dem i /etc/dhcpcd.conf när jag flyttade tillbaka maskinen igen.

Detta är mitt 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 ” trasigt ”, jag fick kommentera raden static routers=192.168.1.254 och raden nedanför #static routers=192.168.1.1 var okommenterad.

Detta orsakade sedan att arp visade en ogiltig post (” ofullständig ”) adressen 192.168.1.1.

Även om jag bara flyttade det här systemet för en vecka sedan och sedan flyttade tillbaka det för några dagar sedan hade jag absolut ingen aning om vad som var fel med det. Såvitt jag kunde säga kunde jag ansluta det till mitt lokala nätverk, ssh in i det bra, och det fanns inga problem med ip addr. traceroute visade inte heller användbar information, det föreslog bara att alla frågor gick via ett enda hopp till ” maskinvärdnamn ”. Det var uppenbarligen inte meningsfullt och det var fel, men det gav mig ingen indikation på vad problemet var – det antydde att alla frågor löstes (på något sätt) på samma maskin. Denna maskin gör DNS förresten.

Inte direkt relaterad till frågan om OP, men kan vara mycket användbar för andra som har det här problemet i framtiden, och detta är det enda sättet du hittills hittat för diagnostisera det, eftersom inte mycket annat verkar vara fel!

Bara några anteckningar om hur jag diagnostiserade detta

• När jag använder den här maskinen som DNS-server för andra maskiner på nätverk kunde de maskinerna inte lösa externa DNS-förfrågningar
• Jag kunde ssh in i DNS-servern (det kan förväntas eftersom dess IP är inställd statisk, och switch / routern förväntar sig också att se en maskin med detta statisk IP ansluten på det lokala Ethernet-nätet via omkopplaren).
• Det första som indikerade något problem var sudo apt update misslyckades. (Eftersom detta är en DNS-server har den inget grafiskt gränssnitt och även om det att köra något som en webbläsare skulle ha visat detta problem mycket tidigare, eller från ikonen för nätverksskrivbordsfältet, har det inte något av dessa saker.)
• ping 8.8.8.8 misslyckades också, men ssh och pingning av lokala maskiner var bra
• Jag kollade /etc/network/interfaces[.d] men alla filer i dessa dirs var tomma / inställda som standard, eftersom DNS-programvaran hanterar dessa
• Det fanns inga fel / varningar i DNS-programvaran när du anslöt till DNS-servern via det medföljande webbgränssnittet
• Jag började kontrollera saker som ip addr (inga problem) och arp. Jag har redan sagt traceroute visade inte vad problemet skulle kunna vara, men visade att något konstigt pågick.
• Söker efter skäl till varför arp kan ha en ofullständig post som guidade mig längs rätt linjer
• Jag hittade den här frågan ( https://serverfault.com/questions/765380/when-do-stale-arp-entries-become-failed-when-never-used ) och började undersöka hur man tar bort arp-poster
• Jag tar bort posten med arp -d 192.168.1.1
• Men det fortsatte att komma tillbaka
• Jag försökte ansluta till 192.168.1.1 på mitt lokala nätverk från ett annat maskin, men jag blev inte förvånad över att jag inte kunde göra det eller pinga det eftersom det inte finns några maskiner i mitt nätverk med den här adressen
• Vanligtvis skulle den här adressen vara din gateway / en ISP-router i hemapplikationer
• Detta påminde mig om att jag hade ställt in en nätverksadapter på den andra platsen för att ha adressen 192.168.1.1, och att datorn som var ansluten till den här adressen användes som en router för att ansluta nätverken 192.168.0.X och 192.168.1.X
• Den ursprungliga platsen finns i nätverket 192.168.1.X, platsen jag flyttade till var på 192.168.0.X
• Eftersom de flesta 192.168.1.X/24 nätverk använder 192.168.1.1 som standardgateway, eftersom den här IP-adressen inte väckte initialt misstankar och det verkade inte ” konstigt ” av någon anledning
• Men jag ändrade standardgateway i dhcpcd.conf som beskrivits ovan och problemet löstes
• Lärdom, när du skapar ett konstigt dator-till-dator-nätverk tillfälligt, ge router-adaptern / NIC en konstig statisk IP som 192.168.1.50 – som kan hjälpa till att påminna sig själv eller ange att något utöver det vanliga ställs i en inställningsfil någonstans

Kommentarer

• Tyvärr är värd- / serverkonfigurationer utanför ämnet här, men kan hanteras på Serverfel för en verksamhet nätverk.