Așa cum am menționat în acest post :
Motivul pentru că ați văzut un ARP incomplet este că „A fost trimisă o cerere ARP pentru acea adresă, dar gazda cu acea adresă nu este activată și rulează pe LAN, deci nu există niciun răspuns”
Deci, dacă un comutator multistrat trimite o cerere ARP către un server și nu primește niciun răspuns, ARP va fi marcat ca incomplet în tabelul comutatorului ARP.
Dar dacă serverul trimite o cerere ARP către comută, dar nu primește răspuns? Serverul va afișa ARP incomplet în tabelul său ARP și comutatorul nu va afișa nicio intrare?
Dacă presupunem că cele de mai sus sunt corecte, putem spune că, dacă vedeți intrarea ARP incompletă pe un dispozitiv local, problema este cu dispozitivul la celălalt capăt al conexiunii (sau cablării)? Sau există câteva excepții?
Comentarii
- După cum subliniază @RonTrunk, un comutator este un dispozitiv transparent layer-2 care nu știe sau îi pasă despre adresarea layer-3 (IP), deci nu ‘ nu folosește sau nu răspunde la ARP. Comutatorul poate fi gestionat, astfel încât gestionarea comutatorului este ca o gazdă din rețea și are o interfață layer-3 care utilizează și răspunde la ARP, dar care nu are nimic de-a face cu funcția de comutare, care încă nu știe nimic despre stratul-3. Nu ‘ nu confundați ARP pe dispozitivele layer-3 cu tabelul de adrese MAC al comutatoarelor. Mulți oameni îi confundă.
- Comutatorul acționează ca un gateway L3 sau doar ca un switch L2?
- @cpt_fink, da de ” switch ” Am vrut să spun un switch multistrat (gateway L3)
Răspuns
Pentru un switch layer-3, modulul layer-3 din switch este un router și funcționează exact ca un router, care funcționează ca orice altă gazdă pentru ARP. Un comutator strat-3 este încă în primul rând un comutator strat-2, iar comutatorul strat-2 acționează în continuare la fel ca un comutator strat-2. Părțile layer-3 și layer-2 ale unui comutator layer-3 sunt într-adevăr separate. Interfețele layer-3 (atât interfețele virtuale, cât și orice interfețe fizice configurate ca interfețe layer-3) vor utiliza un tabel ARP, dar interfețele layer-2 vor utiliza un tabel de adrese MAC.
Când o gazdă, incluzând un router sau modulul de rutare într-un switch layer-3, trimite o cerere ARP și nu primește niciun răspuns, marchează intrarea tabelului ARP ca incomplete
.
Dar dacă serverul trimite o cerere ARP către comutator, dar nu primește răspuns? Serverul va afișa ARP incomplet în tabelul său ARP și comutatorul nu va afișa nicio intrare?
Asta depinde. Dacă o gazdă trimite o cerere ARP către o altă gazdă, inclusiv un router, dar nu a primit încă un răspuns, atunci intrarea tabelului ARP gazdă va fi marcată incomplete
pentru adresa IPv4 a routerului.
Ce are routerul în tabelul său ARP depinde dacă routerul a primit sau nu cererea ARP și dacă routerul are sau nu o intrare de tabel ARP pentru gazdă.
-
Un router cu o intrare de tabel ARP existentă pentru gazdă va continua să aibă acea intrare până când routerul o curăță din cauza unui timeout. Expirarea nu este obligatorie de către RFC, dar RFC are o secțiune care tratează posibilitatea de a utiliza un timeout pentru intrările de tabel ARP, iar majoritatea gazdelor fac acest lucru:
Poate fi de dorit să aveți o îmbătrânire a mesei și / sau expirări. Implementarea acestora nu intră în sfera acestui protocol.
- Dacă routerul nu a primit niciodată cererea ARP și nu a avut nicio intrare pentru gazdă, atunci nu va exista nicio intrare în tabelul ARP al routerului.
- Dacă routerul a primit cererea ARP de la gazdă, dar răspunsul înapoi la gazdă s-a pierdut, routerul va avea un ARP complet intrare în tabel pentru gazdă.
Pentru a înțelege cum funcționează ARP, ar trebui să citiți RFC 826, An Protocol de rezoluție a adresei Ethernet – sau – Conversia adreselor protocolului de rețea la adresa Ethernet de 48 de biți pentru transmisie pe hardware Ethernet . Amintiți-vă că ARP funcționează pentru IPv4, dar nu pentru IPv6, care are ND (Neighbor Discovery) în loc de ARP.
Răspuns
Este necesară o rezoluție ARP reușită pentru ca două noduri IPv4 să comunice pe un segment comun layer-2 (de obicei Ethernet).
Cererile ARP incomplete au două motive de bază.
-
Cererea ARP nu a primit răspuns. Fie nodul de destinație nu a primit cererea ARP, fie răspunsul său nu a fost primit. Nodul de destinație poate fi oprit.
-
Masca de rețea a nodului sursă nu este configurată corect.Nodul sursă ia în considerare toate destinațiile din propria subrețea locală sau on-link: se așteaptă să poată vorbi cu ele direct prin interfața Ethernet, fără ajutorul unui router gateway.
Când de ex. un nod din subrețeaua 192.168.0.0/24 este configurat incorect cu 192.168.0.10/16 consideră o destinație precum 192.168.16.1 locală. Nu va încerca să utilizeze un gateway, ci va încerca un ARP direct care rămâne incomplet.
Indiferent dacă sursa sau destinația / următorul nod hop este un router, switch multi-strat sau nodul final nu contează.
Răspuns
Tabelul ARP al comutatorului este utilizat doar de interfața de gestionare a comutatorului pentru traficul IP generat de comutatorul în sine.
În caz contrar, comutatoarele se uită doar la informațiile despre stratul 2. Nu înțeleg ARP.
Comentarii
- da, mă refeream la un comutator multistrat
Răspuns
Un alt motiv posibil – setări incorecte dhcpcd
Am adăugat acest răspuns, deși (probabil) nu este direct legat de întrebarea specifică de mai sus, este relevant în unele cazuri
Dacă setările statice ale unui sistem ip / dhcp sunt incorecte, acest lucru poate apărea ca un efect secundar indirect.
În cazul meu specific am avut o mașină Linux pe care am mutat locațiile și am schimbat setul de rețea ngs for.
Am uitat să le actualizez în /etc/dhcpcd.conf
, când am mutat din nou aparatul înapoi.
Acesta este 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
Când a fost ” rupt „, linia static routers=192.168.1.254
a fost comentată, iar linia de sub #static routers=192.168.1.1
a fost necomentată.
Acest lucru a determinat apoi arp
să afișeze o intrare nevalidă (” incompletă „) pentru adresa 192.168.1.1
.
Chiar dacă am mutat acest sistem doar acum o săptămână, apoi l-am mutat în urmă cu câteva zile în urmă, nu aveam absolut nici o idee despre ce nu era în regulă Cu acesta. Din câte mi-am dat seama, aș putea să-l conectez la rețeaua mea locală, ssh în ea bine și nu au apărut probleme cu ip addr
. traceroute
nu afișa nici o informație utilă, ci doar sugerează că toate interogările mergeau printr-un singur salt către ” numele gazdei mașinii „. Evident, acest lucru nu avea niciun sens și era greșit, dar nu mi-a dat nicio indicație cu privire la care era problema – a sugerat că toate întrebările erau rezolvate (cumva) pe aceeași mașină. Apropo, această mașină face DNS.
Nu are legătură directă cu problema OP, dar poate fi foarte utilă celorlalți care au această problemă în viitor și acesta este singurul mod pe care l-ați găsit până acum diagnosticați-l, deoarece nu se pare că altceva este greșit!
Doar câteva note despre modul în care am diagnosticat acest lucru
- Când utilizați această mașină ca server DNS pentru alte mașini de pe rețea, acele mașini nu au putut rezolva cererile DNS externe
- Aș putea introduce ssh în serverul DNS (asta ar fi de așteptat deoarece IP-ul său este setat static, iar comutatorul / routerul se așteaptă să vadă și o mașină cu acest IP static conectat pe ethernet-ul local prin comutator).
- Primul lucru care a indicat o problemă a fost
sudo apt update
eșuat. (Deoarece acesta este un server DNS, nu are o interfață grafică și, prin urmare, deși rularea unui browser web ar fi indicat această problemă mult mai devreme sau de pe pictograma tăvii desktop pentru rețea, nu are niciunul dintre aceste lucruri.) -
ping 8.8.8.8
a eșuat, de asemenea, totuși ssh și ping-ul mașinilor locale a fost în regulă - Am verificat
/etc/network/interfaces[.d]
cu toate acestea, toate fișierele din aceste direcții au fost necompletate / setate la valorile implicite, deoarece software-ul DNS le gestionează. - Nu au existat erori / avertismente în software-ul DNS la conectarea la serverul DNS prin interfața web furnizată
- Am început să verific lucruri precum
ip addr
(fără probleme) șiarp
. Am spus deja nu a indicat care ar putea fi problema, dar a indicat că se întâmplă ceva ciudat. - Căutarea motivelor pentru care
arp
ar putea avea o intrare incompletă m-a ghidat de-a lungul liniilor corecte - Am găsit această întrebare ( https://serverfault.com/questions/765380/when-do-stale-arp-entries-become-failed-when-never-used ) și am început să caut cum să șterg intrările arp
- Am eliminat intrarea cu
arp -d 192.168.1.1
- Cu toate acestea a continuat să revină
- Am încercat să mă conectez la
192.168.1.1
din rețeaua mea locală de la altul mașina, totuși nu am fost surprins că nu am putut face acest lucru sau nu am făcut ping pentru că nu există mașini în rețeaua mea cu această adresă - De obicei, această adresă ar fi adresa gateway-ului dvs. / un router ISP din aplicații de acasă
- Acest lucru mi-a amintit că am setat un adaptor de rețea în cealaltă locație pentru a avea adresa
192.168.1.1
și că computerul care a fost conectat la această adresă a fost folosit ca router pentru conectarea rețelelor192.168.0.X
și192.168.1.X
- Locația inițială este în rețea
192.168.1.X
, locația în care m-am mutat a fost pe192.168.0.X
- Deoarece majoritatea
192.168.1.X/24
folosesc192.168.1.1
ca gateway implicit, văzând că acest IP nu a trezit inițial nici o suspiciune și nu pare ” ciudat ” din orice motiv - Cu toate acestea, am modificat gateway-ul implicit în
dhcpcd.conf
după cum s-a descris mai sus și problema a fost rezolvată - Lecția învățată, atunci când creați temporar o rețea ciudată de la computer la computer, oferiți adaptorului routerului / NIC un IP static ciudat precum
192.168.1.50
– care ar putea ajuta să-și amintească sau să indice ceva ieșit din comun este setat undeva într-un fișier de setări
Comentarii
- Din păcate, configurațiile gazdă / server sunt off-topic aici, dar pot fi tratate pe Eroare server pentru un busines rețeaua s.