Amint ezt a bejegyzés említette:
Az ok ha egy hiányos ARP-t lát, az az, hogy “ARP-kérést küldtek erre a címre, de az adott címmel rendelkező gazdagép nem működik és működik a LAN-on, ezért nincs válasz”
Tehát, ha egy többrétegű kapcsoló ARP kérést küld egy szervernek, és nem kap választ, az ARP hiányosként lesz megjelölve a switch ARP táblában.
De mi van akkor, ha a szerver ARP kérést küld a váltani, de nem kap választ? Megjeleníti-e a szerver a hiányos ARP-t az ARP-táblázatában, és a kapcsoló nem jelenít meg bejegyzést?
Ha feltételezzük, hogy a fentiek helyesek, akkor mondhatjuk, hogy ha a hiányos ARP-bejegyzést látja egy helyi eszközön, akkor a probléma a készülék (vagy a kábelezés) másik végén van? Vagy vannak kivételek?
Megjegyzések
- Ahogy a @RonTrunk rámutat, a kapcsoló egy átlátszó 2. rétegű eszköz, amely nem ismeri vagy nem érdekli a 3. réteg (IP) címzéséről, tehát nem használja ‘ az ARP-t, és nem reagál rá. Lehet, hogy a kapcsoló kezelhető, így a kapcsoló kezelése olyan, mint egy gazdagép a hálózaton, és van egy 3-as szintű felülete, amely az ARP-t használja és válaszol rá, de ennek semmi köze a kapcsolási funkcióhoz, amely még mindig nem tud semmit a 3. rétegről. Ne keverje össze ‘ a 3. rétegű eszközök ARP-jét a kapcsolók MAC-címtáblájával. Sokan összezavarják őket.
- A kapcsoló L3 átjáróként, vagy csak L2 kapcsolóként működik?
- @cpt_fink, igen: ” switch ” Többrétegű kapcsolóra (L3 átjáró) gondoltam
Válasz
A layer-3 kapcsoló esetében a switch-ben található layer-3 modul egy útválasztó, és ugyanúgy működik, mint egy router, amely úgy működik, mint az ARP bármely más gazdagépe. A 3. rétegű kapcsoló továbbra is elsősorban a 2. rétegű kapcsoló, és a 2. réteg kapcsoló továbbra is ugyanúgy működik, mint egy 2. rétegű kapcsoló. A 3-as réteg kapcsoló 3-as és 2-es része valóban elkülönül egymástól. A 3. réteg interfészei (mind a virtuális interfészek, mind a fizikai rétegek, amelyek a 3. réteg interfészeiként vannak konfigurálva) ARP táblát fognak használni, de a 2. réteg interfészei MAC címtáblát fognak használni.
Amikor gazdagép, ha egy útválasztót vagy útválasztó modult tartalmaz a 3. réteg kapcsolójába, ARP kérést küld és nem kap választ, akkor az ARP tábla bejegyzést incomplete néven jelöli.
De mi van akkor, ha a szerver ARP kérést küld a kapcsolónak, de nem kap választ? A szerver hiányos ARP-t jelenít meg ARP-táblájában, és a kapcsoló nem jelenít meg bejegyzést?
Ez attól függ. Ha egy hoszt ARP kérést küld egy másik hosztnak, beleértve az útválasztót is, de még nem kapott választ, akkor a hoszt ARP tábla bejegyzését incomplete jelöli az útválasztó IPv4 címéhez.
Amit az útválasztó tartalmaz az ARP táblában, attól függ, hogy az útválasztó megkapta-e az ARP kérést, és hogy az útválasztón már van-e ARP táblázat bejegyzés a gazdagép számára.
-
Egy routernek, amelynek már van ARP-tábla bejegyzése a gazdagép számára, ez a bejegyzés továbbra is megmarad, amíg az útválasztó időtúllépés miatt megtisztítja. Az időtúllépést nem az RFC írja elő, de az RFC-nek van egy szakasza, amely az ARP tábla bejegyzésekhez használható időtúllépés lehetőségével foglalkozik, és a legtöbb gazdagép ezt teszi:
Kívánatos lehet az asztal öregedése és / vagy az időtúllépés. Ezek megvalósítása kívül esik a protokoll hatókörén.
- Ha az útválasztó soha nem kapta meg az ARP kérést, és nem volt bejegyzése a következőre: a gazdagép, akkor nem lesz bejegyzés az útválasztó ARP táblájába.
- Ha az útválasztó megkapta az ARP kérést a gazdagéptől, de a gazdagépre adott válasz elveszett, akkor az útválasztónak teljes ARP-je lesz táblázat bejegyzése a gazdagép számára.
Az ARP működésének megértéséhez olvassa el a következőt: RFC 826, An Ethernet Address Resolution Protocol – vagy – Hálózati protokoll-címek konvertálása 48 bites Ethernet-címre az Ethernet hardveren történő továbbításhoz . Ne feledje, hogy az ARP működik az IPv4 esetében, de nem az IPv6 esetében, amelynek ND (Neighbor Discovery) van az ARP helyett.
Answer
Sikeres ARP-felbontás szükséges ahhoz, hogy két IPv4-csomópont kommunikáljon egy közös 2. rétegű szegmensen (általában Etherneten).
A hiányos ARP-kérelmeknek két alapvető oka van.
-
Az ARP kérésre nem érkezett válasz. Vagy a célcsomópont nem fogadta az ARP kérést, vagy a válasza nem érkezett meg. Lehet, hogy a cél csomópont nem működik.
-
A forrás csomópont hálózati maszkja nincs megfelelően konfigurálva.A forráscsomópont a helyi vagy on-link alhálózaton belüli összes célt figyelembe veszi: arra számít, hogy képes lesz közvetlenül az Ethernet interfészén keresztül beszélni velük, átjáró útválasztó segítsége nélkül.
Amikor pl. egy csomópont a 192.168.0.0/24 alhálózaton belül helytelenül van beállítva a 192.168.0.10/16 címmel, olyan célállomást tekint, mint a 192.168.16.1. Nem egy átjárót próbál meg használni, hanem egy közvetlen ARP-t próbál meg, amely hiányos marad.
Akár a forrás, akár a cél / következő ugrócsomópont router, többrétegű kapcsoló vagy a végcsomópontnak nincs jelentősége.
Válasz
A kapcsoló ARP tábláját csak a kapcsolókezelő felület használja IP forgalomhoz maga a kapcsoló generálta.
Ellenkező esetben a kapcsolók csak a 2. réteg információit nézik meg. Nem értik az ARP-t.
Megjegyzések
- igen, többrétegű kapcsolóra gondoltam
Válasz
Egy másik lehetséges ok – a dhcpcd helytelen beállításai
Ezt a választ hozzáadom, bár (valószínűleg) nem közvetlenül kapcsolódik a fenti kérdéshez, bizonyos esetekben releváns
Ha a rendszer statikus ip / dhcp beállításai helytelenek, akkor ez közvetett mellékhatásként jelenhet meg. ngs for.
Elfelejtettem frissíteni őket a /etc/dhcpcd.conf fájlban, amikor újra visszahelyeztem a gépet.
Ez az én 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 Amikor ” törött “, a static routers=192.168.1.254 sort kommenteltem, és a #static routers=192.168.1.1 alatti sort nem kommentáltuk.
Ez azt eredményezte, hogy a arp érvénytelen bejegyzést jelenített meg (” hiányos “) a cím 192.168.1.1.
Annak ellenére, hogy csak egy hete költöztettem ezt a rendszert, majd néhány nappal ezelőtt visszahelyeztem, egyáltalán nem sejtettem, mi a baj ezzel. Amennyire meg tudtam mondani, csatlakoztathattam a helyi hálózathoz, ssh-t bele, és a ip addr esetén nem jelentek meg problémák. A traceroute sem mutatott hasznos információt, csak azt javasolta, hogy minden lekérdezés egyetlen ugráson keresztül ” gép hosztnevére “. Nyilvánvaló, hogy ennek semmi értelme és tévedése, de nem adott semmilyen utalást arra, hogy mi a probléma – ez arra utalt, hogy minden kérdést (valahogy) megoldottak a ugyanaz a gép. Ez a gép egyébként DNS-t csinál.
Nem közvetlenül kapcsolódik az OP kérdéséhez, de nagyon hasznos lehet másoknak, akiknek a jövőben ez a problémájuk van, és eddig csak így találtatok rá diagnosztizálja, mivel sok más nem tűnik hibásnak!
Csak néhány megjegyzés arról, hogyan diagnosztizáltam ezt
- Ha ezt a gépet DNS-kiszolgálóként használom a hálózat, ezek a gépek nem tudták megoldani a külső DNS-kéréseket
- Ssh-t tudtam beírni a DNS-kiszolgálóra (ez elvárható, mivel az IP-je statikus, és a kapcsoló / útválasztó arra is számít, hogy ezzel a géppel találkozni fog statikus IP-kapcsoló kapcsolódott a helyi ethernet-hez a kapcsolón keresztül).
- Az első dolog, amely valamilyen problémát jelzett, a
sudo apt updatehiba volt. (Mivel ez egy DNS-kiszolgáló, ezért nincs grafikus felülete, és bár valami webböngészőhöz hasonló futtatás sokkal hamarabb jelezte volna ezt a problémát, vagy a Hálózati asztali tálca ikonról nem tartalmaz ilyen dolgokat.) div> ezekben a fájlokban azonban minden fájl üres volt / alapértelmezettre állítva, mivel a DNS szoftver kezeli ezeket - A DNS-kiszolgálón a mellékelt webes felületen keresztül történő csatlakozáskor nem voltak hibák / figyelmeztetések a DNS-szoftverben
- Olyan dolgokat kezdtem el ellenőrizni, mint a
ip addr(nincs probléma) és aarp. Már mondtam, hogy nem jelezte, hogy mi lehet a probléma, de azt jelezte, hogy valami furcsa történt. - Olyan okok keresése, amelyek miatt a
arphiányos bejegyzése lehet, a helyes vonal mentén vezetett - Megtaláltam ezt a kérdést ( https://serverfault.com/questions/765380/when-do-stale-arp-entries-become-failed-when-never-used ), és elkezdtem vizsgálni az arp bejegyzések eltávolításának módját
- A bejegyzést a
arp -d 192.168.1.1 - Azonban folyamatosan visszatért
- Megpróbáltam csatlakozni a helyi hálózaton lévő
192.168.1.1hálózathoz egy másikból gép, de nem lepődtem meg, hogy ezt nem tudom megtenni vagy pingelni, mert a hálózatomon nincsenek ilyen címmel rendelkező gépek - Általában ez a cím lenne az Ön átjárójának / egy ISP útválasztójának címe. otthoni alkalmazások
- Ez arra emlékeztetett, hogy a másik helyre beállítottam egy hálózati adaptert, hogy
192.168.1.1legyen a címe, és hogy az ehhez a címhez csatlakoztatott számítógép útválasztóként használták a hálózatok összekapcsolására192.168.0.Xés192.168.1.X - Az eredeti hely a hálózaton van
192.168.1.X, az a hely, ahová költöztem, a192.168.0.X - Mivel a legtöbb
192.168.1.X/24hálózatok a192.168.1.1-et használják alapértelmezett átjáróként, látva, hogy ez az IP kezdetben nem okozott gyanút, és nem tűnt úgy, hogy ” bármilyen okból furcsa ” - Azonban módosítottam az alapértelmezett átjárót a
dhcpcd.confa fent leírtak szerint, és a probléma megoldódott. - Tanulság, amikor egy furcsa számítógép-számítógép hálózatot ideiglenesen nem webhelyen hozunk létre, adjunk az útválasztó adapternek / NIC-nek egy furcsa statikus IP-t, például
192.168.1.50– ez segíthet emlékeztetni magukat, vagy jelezhet valami szokatlant, be van állítva egy beállításfájlba valahol. > - Sajnos a gazdagép / kiszolgáló konfigurációi itt nem témakörök, de a buszok kiszolgálóhibáján kezelhetők. s hálózatát.