9
Problem mit Netzwerkinterface beim ping über Vlans hinweg - ARP?
Danke fürs lesen .....
Hallo allerseits. Ich hab hier ein sehr merkwürdiges Problem mit dem ich nicht mehr weiterkomme und da wollte ich Euch mal um Hilfe bitten.
Folgende Szenario:
Wir haben ein schon recht grosses Netzwerk mit einem HP ProCurve 5400z als Core Switch/Router und einem weiteren als Standby Core im VRRP Verbund.
Es sind diverse Vlans eingerichtet in denen jeweils verschiedenste Clients (PC, Drucker etc) problemlos arbeiten.
Die meisten Anwendungsserver stehen in eigenen Vlans einige noch im Default Lan. Da steht auch der DHCP Server (Win2003) und 2 DCs.
Soweit geht alles problemlos. ABER nun hab ich ein Netzwerkgerät bekommen das mich verrückt macht. Es ist ein Kartenleser (unter einer Linux Distri) mit einer LAN Schnittstelle und soll mit einem Server kommunizieren der im Server Vlan 200 steht.
Bring ich ihn ins Netz (Vlan 16) wo auch diverse andere Clients sind, per DHCP oder statisch, verhält er sich augenscheinlich noch normal.
Er hält bzw. bezieht seine IP Adresse und ist „bereit“.
Dachte ich!
Nur, er liess sich dann aus einem anderen VLAN (200 oder beliebig anderes) nicht anpingen!
Bringe ich ihn in das selbe Netz wie den Server, läuft alles!!!!
Mein erster Verdacht war das Standardgatewayeintrag beim Leser. War es aber nicht, das stimmte.
Kein Ping und auch sonst keine Verbindung zum Gerät.
Der Support des Herstellers war erstmal überfragt und verdutzt, meinte dann der Fehler liegt in unserem Netz. Er schaltete sich auf den Kartenleser , kontrollierte das Netzwerk das war alles ok. Dann sagte ich er solle mal das Standardgateway (Router , Core)
anpingen. Das klappte und nun kommt es, ab dem Zeitpunkt ging auch der Ping über die VLAN’s hinweg zu dem Leser!
Damit war der Support durch, meinte es geht doch und wir sollten den Fehler suchen.
Ich muss dazu sagen, dass der Ping auch noch nach einem Neustart des Lesers ging.
Nun hatte ich denVerdacht, dass am Switch kein arp Eintrag angelegt wurde, bzw. erst nach einem Ping vom Leser zum Coreswitch.
Wireshark!
Ich hab einen Mitschnitt gemacht und dabei einen Ping zum Leser laufen lassen und ihn neu gestartet.
Ich konnte sehen wir die DHCP Verhandlung ablief. Sah gut aus, er bezog eine Adresse, ihm wurden 2 Offers übertragen mit der identischen IP und jeweils anderem Relay Agent (kommt wohl irgendwie vom VRRP dass als 2 Gateway die Adresse des Standby Routers ürtragen wird? Keine Ahnung ). Das sah alles gut aus.
Zur selben Zeit startete ich noch einen normalen PC der genau das gleiche Verhalten zeigte.
Der einzige Unterschied war, dass der PC noch ein DHCP Inform nach der DHCP Verhandlung absetzte, der Leser machte das nicht.
Ping klappte natürlich nicht auf den Leser auf den PC problemlos.
Und was mich da noch stutzig machte ist, dass ich nicht gesehen habe dass der Ping in Richtung Leser ging. Kein Ping und auch kein arp req in Richtung Leser! Es ist fast so, als ob der Router weiss, dass der Leser eh nicht da ist und deshalb nicht mal ein arp req absetzt.
FAZIT: Das Ding arbeitet nur im gleichen Subnetz wir seine Mitspieler. *grrrr*
Nun meine Fragen
1. Wann würde der Router erkennen an welchem Port der Leser angeschlossen ist und einen dementsprechenden arp Eintrag anlegen? Ist das eine Akion nach dem DHCP verhandeln als separate Aktion (fehlt dieses DHCP Inform Paket?!!)?
2. Hat jemand eine Idee warum dieser Leser so zickt und was ich tun kann?
3. Hat jemand so was schon mal gehabt?
Ok, ich hoffe mir kann jemand einen Tip geben ….. und vielen Dank fürs lesen.
Hallo allerseits. Ich hab hier ein sehr merkwürdiges Problem mit dem ich nicht mehr weiterkomme und da wollte ich Euch mal um Hilfe bitten.
Folgende Szenario:
Wir haben ein schon recht grosses Netzwerk mit einem HP ProCurve 5400z als Core Switch/Router und einem weiteren als Standby Core im VRRP Verbund.
Es sind diverse Vlans eingerichtet in denen jeweils verschiedenste Clients (PC, Drucker etc) problemlos arbeiten.
Die meisten Anwendungsserver stehen in eigenen Vlans einige noch im Default Lan. Da steht auch der DHCP Server (Win2003) und 2 DCs.
Soweit geht alles problemlos. ABER nun hab ich ein Netzwerkgerät bekommen das mich verrückt macht. Es ist ein Kartenleser (unter einer Linux Distri) mit einer LAN Schnittstelle und soll mit einem Server kommunizieren der im Server Vlan 200 steht.
Bring ich ihn ins Netz (Vlan 16) wo auch diverse andere Clients sind, per DHCP oder statisch, verhält er sich augenscheinlich noch normal.
Er hält bzw. bezieht seine IP Adresse und ist „bereit“.
Dachte ich!
Nur, er liess sich dann aus einem anderen VLAN (200 oder beliebig anderes) nicht anpingen!
Bringe ich ihn in das selbe Netz wie den Server, läuft alles!!!!
Mein erster Verdacht war das Standardgatewayeintrag beim Leser. War es aber nicht, das stimmte.
Kein Ping und auch sonst keine Verbindung zum Gerät.
Der Support des Herstellers war erstmal überfragt und verdutzt, meinte dann der Fehler liegt in unserem Netz. Er schaltete sich auf den Kartenleser , kontrollierte das Netzwerk das war alles ok. Dann sagte ich er solle mal das Standardgateway (Router , Core)
anpingen. Das klappte und nun kommt es, ab dem Zeitpunkt ging auch der Ping über die VLAN’s hinweg zu dem Leser!
Damit war der Support durch, meinte es geht doch und wir sollten den Fehler suchen.
Ich muss dazu sagen, dass der Ping auch noch nach einem Neustart des Lesers ging.
Nun hatte ich denVerdacht, dass am Switch kein arp Eintrag angelegt wurde, bzw. erst nach einem Ping vom Leser zum Coreswitch.
Wireshark!
Ich hab einen Mitschnitt gemacht und dabei einen Ping zum Leser laufen lassen und ihn neu gestartet.
Ich konnte sehen wir die DHCP Verhandlung ablief. Sah gut aus, er bezog eine Adresse, ihm wurden 2 Offers übertragen mit der identischen IP und jeweils anderem Relay Agent (kommt wohl irgendwie vom VRRP dass als 2 Gateway die Adresse des Standby Routers ürtragen wird? Keine Ahnung ). Das sah alles gut aus.
Zur selben Zeit startete ich noch einen normalen PC der genau das gleiche Verhalten zeigte.
Der einzige Unterschied war, dass der PC noch ein DHCP Inform nach der DHCP Verhandlung absetzte, der Leser machte das nicht.
Ping klappte natürlich nicht auf den Leser auf den PC problemlos.
Und was mich da noch stutzig machte ist, dass ich nicht gesehen habe dass der Ping in Richtung Leser ging. Kein Ping und auch kein arp req in Richtung Leser! Es ist fast so, als ob der Router weiss, dass der Leser eh nicht da ist und deshalb nicht mal ein arp req absetzt.
FAZIT: Das Ding arbeitet nur im gleichen Subnetz wir seine Mitspieler. *grrrr*
Nun meine Fragen
1. Wann würde der Router erkennen an welchem Port der Leser angeschlossen ist und einen dementsprechenden arp Eintrag anlegen? Ist das eine Akion nach dem DHCP verhandeln als separate Aktion (fehlt dieses DHCP Inform Paket?!!)?
2. Hat jemand eine Idee warum dieser Leser so zickt und was ich tun kann?
3. Hat jemand so was schon mal gehabt?
Ok, ich hoffe mir kann jemand einen Tip geben ….. und vielen Dank fürs lesen.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 197192
Url: https://administrator.de/forum/problem-mit-netzwerkinterface-beim-ping-ueber-vlans-hinweg-arp-197192.html
Ausgedruckt am: 22.12.2024 um 23:12 Uhr
9 Kommentare
Neuester Kommentar
Hi
auch wenn des statistisch gegen 0 geht und es nicht vorkommen darf und sollte: check mal die MAC Adresse ob es diese bei einem anderen Gerät bereits gibt und es aus dem Grund zu solchen Problemen kommt.
Ich hatte das einmal bei uns, nachdem die Azubis aus der E-Technik "fröhlich lötend, schraubend und klebend" sich Ihre Images für die Micro-Controller (oder was auch immer) kopiert haben und dadurch alle Geräte 100% Klone waren.
Die Wahrscheinlichkeit ist zwar verschwindend gering das es eine doppelte MAC Adresse gibt - kann aber passieren
(Wobei so etwas auch bei den "Großen" vorkommt: http://www.heise.de/ct/hotline/Doppelte-MAC-Adressen-315538.html)
auch wenn des statistisch gegen 0 geht und es nicht vorkommen darf und sollte: check mal die MAC Adresse ob es diese bei einem anderen Gerät bereits gibt und es aus dem Grund zu solchen Problemen kommt.
Ich hatte das einmal bei uns, nachdem die Azubis aus der E-Technik "fröhlich lötend, schraubend und klebend" sich Ihre Images für die Micro-Controller (oder was auch immer) kopiert haben und dadurch alle Geräte 100% Klone waren.
Die Wahrscheinlichkeit ist zwar verschwindend gering das es eine doppelte MAC Adresse gibt - kann aber passieren
(Wobei so etwas auch bei den "Großen" vorkommt: http://www.heise.de/ct/hotline/Doppelte-MAC-Adressen-315538.html)
Hast du auf den Switchen DHCP Snooping aktiviert?
Hi dog,
hab grad nachgesehen, wusste garnicht dass es sowas gibt!
Es ist aber deaktiviert.
Und generell scheint ja die DHCP Reservierung zu funktionieren.
Ausserdem macht ja das Terminal auch bei statischer IP Vergabe Probleme.
Aber dennoch danke für den Hinweis.
hab grad nachgesehen, wusste garnicht dass es sowas gibt!
Es ist aber deaktiviert.
Und generell scheint ja die DHCP Reservierung zu funktionieren.
Ausserdem macht ja das Terminal auch bei statischer IP Vergabe Probleme.
Aber dennoch danke für den Hinweis.
Hi,
danke erstmal. Ich hab das noch mit weiteren 2 Lesern probiert .... der gleiche Effekt.
Dank Dir.
danke erstmal. Ich hab das noch mit weiteren 2 Lesern probiert .... der gleiche Effekt.
Dank Dir.
Hi,
interessant
Also zusammengefasst, im gleichen Subnetz geht der Ping, in einem anderem kommt nichts, richtig?
Hat denn der Router in seinem ARP-Cache die richtige MAC des Lesers?
Kann der Router den anpingen?
VG
Deepsys
interessant
Also zusammengefasst, im gleichen Subnetz geht der Ping, in einem anderem kommt nichts, richtig?
Hat denn der Router in seinem ARP-Cache die richtige MAC des Lesers?
Kann der Router den anpingen?
VG
Deepsys
Hi Deepsys,
so kann man es fast sagensofern er auch im gleichen Netz wie der DHCP ist, gehts auch über die VLANS.
Habe jetzt folgendes versucht.
Anschluss Leser im default Lan (zieht Adresse)- MAC im Switch unbekannt - Ping auf das Gerät aus nem VLAN - danach MAC bekannt
Anschluss Leser im im VLANx (zieht Adresse)- MAC im Switch unbekannt - Ping auf Gerät geht nicht - MAC logischerweise weiterhin unbekannt
Router kann ihn auch nicht pingen.
Danke für deine Hilfe
so kann man es fast sagensofern er auch im gleichen Netz wie der DHCP ist, gehts auch über die VLANS.
Habe jetzt folgendes versucht.
Anschluss Leser im default Lan (zieht Adresse)- MAC im Switch unbekannt - Ping auf das Gerät aus nem VLAN - danach MAC bekannt
Anschluss Leser im im VLANx (zieht Adresse)- MAC im Switch unbekannt - Ping auf Gerät geht nicht - MAC logischerweise weiterhin unbekannt
Router kann ihn auch nicht pingen.
Danke für deine Hilfe
Sieht so aus als ob der Switch oder der Leser ein Problem mit dem ARP hat wie Deepsys richtig vermutet ?!
Beim ARP kommt es darauf an WER Datentraffic initiiert. Ist es der Kartenleser selber will der ja mit irgendwelchem Server usw. kommunizieren der nicht in seinem IP Netz (VLAN) liegt.
Dann beginnt der Standardprozess den jeder Netzwerker in der ersten Klasse lernt:
Der Kartenleser "sieht" sieht in seine Routingtabelle und wenn er keine Route findet nimmt er das default Gateway, was bei dir die virtuelle VRRP Adresse des VRRP Prozesses der Core Systeme sind die im HA laufen und dann initiiert der Kartenleser ein ARP Request Broadcast an diese IP.
Der VRRP Masterswitch antwortet dann mit der VRRP Mac Adresse der VIP (virtuelle IP). Diese IP kannst du ganz einfach erkennen, denn es beinhaltet die VRRP ID (VRID) in dem VLAN, also sowas wie 00-00-2E-CD-21-XX wobei "XX" die VRID ID ist.
Dann gibst du mal ein arp -a am Kartenleser ein um dir dessen ARP Cache anzusehen, dort sollte die VIP Mac dann auftauchen.
Kommt von außen Traffic auf den Kartenleser landet der ja im Core Switch der L3 macht. Wenn der die Mac des Kartenleseres nicht kennt ARPed der Core Switch nach der Karteleser IP auf den der Kartenleser dann mit einem ARP Reply seiner Mac antworten muss.
Folglich zeigt ein show arp auf der HP Gurke ob der Kartenleser dort im ARP Cache vetreten ist was der Fall sein muss !
Wichtig ist dort auch mal mit show mac die Mac Forwarding Tabelle zu checken ob der Switch die Mac Adresse des Kartenlesers am Port gelernt hat.
Wenn also der Switch den Kartenleser pingen kann wäre es sehr unverständlich wenn externer Traffic am Switch ankommt das der Kartenleser dann nicht pingbar ist.
Das würde dann eher wieder auf ein Routing Problem im Switch schliessen lassen...?!
Fazit: Du musst also rausbekommen WER der böse Buhmann ist der mit den ARPs nicht richtig umgeht.
Kollege Wireshark ist hier mal wieder dein bester Freund !
Beim ARP kommt es darauf an WER Datentraffic initiiert. Ist es der Kartenleser selber will der ja mit irgendwelchem Server usw. kommunizieren der nicht in seinem IP Netz (VLAN) liegt.
Dann beginnt der Standardprozess den jeder Netzwerker in der ersten Klasse lernt:
Der Kartenleser "sieht" sieht in seine Routingtabelle und wenn er keine Route findet nimmt er das default Gateway, was bei dir die virtuelle VRRP Adresse des VRRP Prozesses der Core Systeme sind die im HA laufen und dann initiiert der Kartenleser ein ARP Request Broadcast an diese IP.
Der VRRP Masterswitch antwortet dann mit der VRRP Mac Adresse der VIP (virtuelle IP). Diese IP kannst du ganz einfach erkennen, denn es beinhaltet die VRRP ID (VRID) in dem VLAN, also sowas wie 00-00-2E-CD-21-XX wobei "XX" die VRID ID ist.
Dann gibst du mal ein arp -a am Kartenleser ein um dir dessen ARP Cache anzusehen, dort sollte die VIP Mac dann auftauchen.
Kommt von außen Traffic auf den Kartenleser landet der ja im Core Switch der L3 macht. Wenn der die Mac des Kartenleseres nicht kennt ARPed der Core Switch nach der Karteleser IP auf den der Kartenleser dann mit einem ARP Reply seiner Mac antworten muss.
Folglich zeigt ein show arp auf der HP Gurke ob der Kartenleser dort im ARP Cache vetreten ist was der Fall sein muss !
Wichtig ist dort auch mal mit show mac die Mac Forwarding Tabelle zu checken ob der Switch die Mac Adresse des Kartenlesers am Port gelernt hat.
Wenn also der Switch den Kartenleser pingen kann wäre es sehr unverständlich wenn externer Traffic am Switch ankommt das der Kartenleser dann nicht pingbar ist.
Das würde dann eher wieder auf ein Routing Problem im Switch schliessen lassen...?!
Fazit: Du musst also rausbekommen WER der böse Buhmann ist der mit den ARPs nicht richtig umgeht.
Kollege Wireshark ist hier mal wieder dein bester Freund !
vielen Dank aqui
im Prinzip seh ich das ja genauso. Und mit Wireshark war ich da auch schon dran. Das verrückte ist nur, dass beide Geräte extrem maulfaul sind.
So, sendet der Leser z.B. nach seiner DHCP Verhandlung absolut nix mehr ins Netz. Somit auch kein arp Eintrag.
An der Stelle ist nun ultrakomisch, dass wenn ich den Leser anpinge der Switch kein arp req bringt.
Somit hab ich 2 Teilnehmer die sich anschweigen.
Mich macht das mit dem Switch und dem fehlenden arp req echt stuzig.
Was ich noch sagen muss. Ich habe eine Chance an den Leser (Betriebssystem) zu kommen! Die Kite ist dicht.
im Prinzip seh ich das ja genauso. Und mit Wireshark war ich da auch schon dran. Das verrückte ist nur, dass beide Geräte extrem maulfaul sind.
So, sendet der Leser z.B. nach seiner DHCP Verhandlung absolut nix mehr ins Netz. Somit auch kein arp Eintrag.
An der Stelle ist nun ultrakomisch, dass wenn ich den Leser anpinge der Switch kein arp req bringt.
Somit hab ich 2 Teilnehmer die sich anschweigen.
Mich macht das mit dem Switch und dem fehlenden arp req echt stuzig.
Was ich noch sagen muss. Ich habe eine Chance an den Leser (Betriebssystem) zu kommen! Die Kite ist dicht.
Oha, das ist aber ganz klar ein Bug in der Switchfirmware, wenn dem wirklich so ist ! Sollte dich also in der Tat SEHR stutzig machen.
Das darf niemals sein das der Switch kein ARP schickt, denn er MUSS vor Sessionaufbau oder ICMP Ping die Mac Adresse kennen und das geht nun mal mit einem ARP Request.
Kein Layer 3 Paket ohne Layer 2 Unterbau, denn das würde jeglichem Netzwerk Standard zuwiderlaufen.
Da solltest du dir dann aber mal den Switch genauestens unter die Lupe nehmen ! Das darf de facto NICHT sein und ist ein Fehler !
Sowohl der VRRP Master Switch MUSS zwangsweise einen Arp senden als auch der VRRP Slave wenn du direkt von deren Console den Leser pingst.
Wenn das stimmt und du nicht einen Fehler mit der Konfiguration des Monitor Ports am Switch gemacht hast wo du das VLAN snifferst (Ausnahme du hast den Sniffer mit Hub o.ä. zwischengeschleift ?!) dann ist das de facto ein Fehler des Switches, da besteht kein Zweifel.
Bist du da auf der aktuellsten Firmware ?
Es spielt übrigens keinerlei Rolle ob die Endgeräte am Switch nun stumm oder geschwätzig sind. Das sind Standards des TCP/IP Protokolls bzw. ICMP die per se eingehalten werden müssen !
Das ein Kartenleser ja eher still ist ist ja gewollt. Was sollte er auch ins Netz blasen wenn keiner einen Zahlvorgang auslöst an ihm ?! Ist schon richtig so das er seriös schweigt wenn es um Geld geht
Beim ARP darf aber weder er noch der Switch schweigen.
P.S.: Den Satz " Ich habe eine Chance an den Leser (Betriebssystem) zu kommen! Die Kite ist dicht." kann man nicht verstehen, das ist wohl ein Dreckfuhler, oder ?
Das du an das Betriebssystem Nicht kommst ist sicher gewollt aber was hat der englische Drachen da zu suchen ?
Das darf niemals sein das der Switch kein ARP schickt, denn er MUSS vor Sessionaufbau oder ICMP Ping die Mac Adresse kennen und das geht nun mal mit einem ARP Request.
Kein Layer 3 Paket ohne Layer 2 Unterbau, denn das würde jeglichem Netzwerk Standard zuwiderlaufen.
Da solltest du dir dann aber mal den Switch genauestens unter die Lupe nehmen ! Das darf de facto NICHT sein und ist ein Fehler !
Sowohl der VRRP Master Switch MUSS zwangsweise einen Arp senden als auch der VRRP Slave wenn du direkt von deren Console den Leser pingst.
Wenn das stimmt und du nicht einen Fehler mit der Konfiguration des Monitor Ports am Switch gemacht hast wo du das VLAN snifferst (Ausnahme du hast den Sniffer mit Hub o.ä. zwischengeschleift ?!) dann ist das de facto ein Fehler des Switches, da besteht kein Zweifel.
Bist du da auf der aktuellsten Firmware ?
Es spielt übrigens keinerlei Rolle ob die Endgeräte am Switch nun stumm oder geschwätzig sind. Das sind Standards des TCP/IP Protokolls bzw. ICMP die per se eingehalten werden müssen !
Das ein Kartenleser ja eher still ist ist ja gewollt. Was sollte er auch ins Netz blasen wenn keiner einen Zahlvorgang auslöst an ihm ?! Ist schon richtig so das er seriös schweigt wenn es um Geld geht
Beim ARP darf aber weder er noch der Switch schweigen.
P.S.: Den Satz " Ich habe eine Chance an den Leser (Betriebssystem) zu kommen! Die Kite ist dicht." kann man nicht verstehen, das ist wohl ein Dreckfuhler, oder ?
Das du an das Betriebssystem Nicht kommst ist sicher gewollt aber was hat der englische Drachen da zu suchen ?
