înregistrare Logare
Puncte:0
avatar Server

Nu se poate ping mașina PetaLinux dacă ambele NIC-uri de pe aceeași subrețea și deconectați eth0

drapel es
Timothy Miller

Am o mașină PetaLinux (Linux încorporat pe un dispozitiv Xilinx Zynq, debian furk, ​​kernel 4.19). Dacă cele două NIC-uri sunt pornite diferit subrețele, apoi pot deconecta o NIC, iar cealaltă va continua să funcționeze. Dar dacă sunt pe la fel subrețea, apoi deconectarea eth0 le va face pe ambele inaccesibile. (Deconectarea eth1 este în regulă.) De asemenea, dacă adresele sunt achiziționate de DHCP, atunci deconectarea mufei pentru eth0 este, de asemenea, în regulă.

Acum, înțeleg că în mod implicit, Linux are o politică slabă pentru alegerea unei NIC prin care să răspundă la orice mesaj, iar asta este ceva cu care m-am ocupat acum câțiva ani, în alt articol.

Din păcate, această soluție nu pare să funcționeze la versiunea de Linux pe care o avem aici. Avem ceva nou de-a face cu nucleele mai recente?

Mulțumesc anticipat.

Actualizați

„ip route” în timp ce ambele cabluri sunt conectate:

implicit prin 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.195
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.196

„ip route” când eth0 este deconectat (caz de eșec):

implicit prin 192.168.1.1 dev eth0 linkdown
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.195 linkdown
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.196

„ruta ip” când eth1 este deconectat (funcționează bine):

implicit prin 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.195
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.196 linkdown

Pentru a reitera, nu putem da ping la 192.168.1.196 când NIC-ul pentru 192.168.1.195 este deconectat.

113
0 + 0
drapel cn
hardillb
Cum arată ieșirea `ip route` înainte și după ce deconectați cablul eth0? (presupunând că ne pasă doar de IPv4 pentru moment)
0
Răspunde
drapel es
Timothy Miller
@hardillb Mulțumesc. Am continuat și am adăugat acele informații la întrebare.
0
Răspunde
A.B avatar
drapel cl
A.B
Sunt sigur că există mai multe metode pentru a „remedia” acest lucru (rutare politică, legare...), dar știind de ce puneți de bunăvoie două legături folosind aceeași rețea IP LAN în același LAN Ethernet (alias domeniul de difuzare) în ciuda faptului că știți vor fi probleme ar ajuta. Este pentru redundanță, pentru lățime de bandă, pentru altceva? Există servicii diferite pe cele două adrese IP. Pe măsură ce legați referințele, aplicațiile dvs. UDP sunt capabile să utilizeze IP_PKTINFO în mod corespunzător sau să se lege la mai multe adrese diferite în loc de 0.0.0.0 (care este o altă metodă de a gestiona problema IP-ului sursei de răspuns pentru UDP)? etc.
0
Răspunde
drapel es
Timothy Miller
@A.B Mulțumesc pentru răspuns. Noi înșine am pus doar ambele NIC-uri pe aceeași subrețea pentru testare. De ce doresc clienții noștri să o facă, nu știm cu adevărat, dar ei insistă.Lucrăm la adăugarea unei caracteristici care să permită trecerea la modul de legătură, dar cunoscând tiparele de comportament, vor insista că atât legarea, cât și nelegarea funcționează. Nu știam că vor fi probleme, iar asta nu pare acea margine a carcasei pe care ar trebui să o rupă atât de ușor. Toate serviciile sunt disponibile de la ambele NIC-uri și nu servesc la creșterea lățimii de bandă.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.