Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

Linux Distros versuchen Gateway zu umgehen - stattdessen Paketzustellung direkt bzw. lokal?!

Frage Netzwerke Router & Routing

Mitglied: paj2000

paj2000 (Level 1) - Jetzt verbinden

26.08.2014, aktualisiert 17:18 Uhr, 1626 Aufrufe, 49 Kommentare, 1 Danke

Ich bin bei 2 Linux Distros (Ubuntu 14.04 & Raspian) auf eine Eigenheit wie folgt gestoßen, die mir unter Windows nicht untergekommen ist.

Ich habe einen Rechner mit folgenden Einstellung:
IP: 10.100.1.1/16
Gateway: 10.100.0.1

Die ARP-Tabelle ist geflusht (also ganz leer).

Wenn ich nun auf 10.200.1.1 pingen will, sendet er nicht das Paket an das Gateway sondern will es direkt zustellen?

Wieso?
Ist hier unter Linux noch etwas einzustellen?




60963ac01506501b813916f56ea33f56 - Klicke auf das Bild, um es zu vergrößern

Wobei DstMAC: 50:e5:49:..... bereits die MAC des Clients 10.200.1.1 und nicht die von 10.100.0.1 ist?!
49 Antworten
Mitglied: Lochkartenstanzer
26.08.2014 um 13:51 Uhr
Zitat von paj2000:

Ich habe einen Rechner mit folgenden Einstellung:
IP: 10.100.1.1/16
Gateway: 10.100.0.1
...
Wenn ich nun auf 10.200.1.1 pingen will, sendet er nicht das Paket an das Gateway sondern will es direkt zustellen?
...
Ist hier unter Linux noch etwas einzustellen?

moin,

  • Sicher? Wie stellst Du fest, daß er direkt zustellen will?
  • Bist Du sicher, daß Du /16 als maske hast und nicht aus versehen /8?

Poste mal die Ausgaben von ifconfig -a und netstat -r

lks
Bitte warten ..
Mitglied: Looser27
26.08.2014 um 13:55 Uhr
Du hast aber schon gesehen, dass alle angegebenen Adressen in unterschiedlichen Netzen hängen?

Gruß

Looser
Bitte warten ..
Mitglied: Lochkartenstanzer
26.08.2014, aktualisiert um 14:19 Uhr
Zitat von Looser27:

Du hast aber schon gesehen, dass alle angegebenen Adressen in unterschiedlichen Netzen hängen?

Gateway und IP-Adresse sind im selben Netz (=10.100.0.0/16), das Ziel nicht.

Deswegen die frage, wie er es feststellt und ob er einen Tippfehler drin hat, z.B. /16 statt /26.

Klarheit darüber verschaffen die Ausgaben der obigen Befehle.

lks
Bitte warten ..
Mitglied: Looser27
26.08.2014 um 14:12 Uhr
Client IP 10.100.1.1
Gatew. 10.100.0.1

Schlag mich, aber wenn das kein Tippfehler ist, sind das 2 unterschiedliche Netze.....
Bitte warten ..
Mitglied: brammer
26.08.2014 um 14:14 Uhr
Hallo,

Client IP 10.100.1.1
Gatew. 10.100.0.1

bei einer /16 Maske (= 255.255.0.0) ist das ein Netz....

Wohin magst du die Schläge?

brammer
Bitte warten ..
Mitglied: Lochkartenstanzer
26.08.2014, aktualisiert um 14:18 Uhr
Zitat von Looser27:

Client IP 10.100.1.1
Gatew. 10.100.0.1

Schlag mich, aber wenn das kein Tippfehler ist, sind das 2 unterschiedliche Netze.....

Warum?

lks.

PS: Ohne Netzmaske kann man überhaupt nicht beurteilen, ob zwei IP-Adressen im selben Netz sind. Aber der TO hatte /16 angegeben.

PPS: Darf ich Cat9 verwenden.
Bitte warten ..
Mitglied: aqui
26.08.2014 um 14:22 Uhr
Da ist der Nickname wohl Programm...?! Erst lesen, denken, dann antworten !

Zurück zum Thema...
Das Verhalten kann eigentlich nicht sein und würde dem TCP/IP Standard widersprechen. Das .200er netz ist ein anderes Netz und der Stack müsste dann sofort nach der Router IP 10.100.0.1 ARPen !
Er muss ersten den Router ARPen um das Paket an den Router zustellen zu können.
Gib also mal ein apt-get install tcpdump ein und dann ein tcpdump -v und sieh dir mal genau an was da passiert.
Es kann eigentlich nur sein das du einen Fehler in der IP Konfig hast oder der Router sowas wie Proxy ARP macht wenn das dort aktiviert ist.
Bitte warten ..
Mitglied: Lochkartenstanzer
26.08.2014 um 14:33 Uhr
Zitat von aqui:

Es kann eigentlich nur sein das du einen Fehler in der IP Konfig hast oder der Router sowas wie Proxy ARP macht wenn das dort
aktiviert ist.

Eben. Wenn er durch irgendeinen Automatismus /8 statt /16 als Netzmaske für das klassische Class-A-Netz hat, würde das schon passen. deswegen die frage nach ifconfig -a und netstat -r

lks
Bitte warten ..
Mitglied: aqui
26.08.2014, aktualisiert um 15:47 Uhr
Das wäre eine denkbare Alternative. Dann hat aber an der Routerkonfig ein Dummie gesessen. Nicht nur das er dann ne falsche Subnetzmaske eingegeben hat er hat dann zusätzlich auch noch Proxy ARP aktiviert. Eigentlich ein NoGo in der Routerkonfig.
Das ist aber jetzt nur wild geraten...?!
Da das Verhalten aber bei 2 unabhängigen Distros passiert (und dann wohl auch bei Winblows und Mac OS-X ebenso...) erhärtet aber diese Vermutung.
Da wär dann mal in der Tat ein Feedback von paj2000 interessant diesbezüglich ?!
Bitte warten ..
Mitglied: paj2000
26.08.2014 um 16:51 Uhr
kann ich hier .pcab Files von meiner Aufzeichnung posten?
Bitte warten ..
Mitglied: paj2000
26.08.2014 um 16:55 Uhr
Vorab schon mal die gewünschten Daten:

root@LAPL:~# ifconfig -a
eth0 Link encap:Ethernet Hardware Adresse e4:11:5b:23:95:22
inet Adresse:10.100.1.1 Bcast:10.100.255.255 Maske:255.255.0.0
inet6-Adresse: fec0::e611:5bff:fe23:9522/64 Gültigkeitsbereich:Standort
inet6-Adresse: fec0::5c04:1843:8179:2f48/64 Gültigkeitsbereich:Standort
inet6-Adresse: fe80::e611:5bff:fe23:9522/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX-Pakete:3105 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:731 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:304455 (304.4 KB) TX-Bytes:93216 (93.2 KB)

lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:65536 Metrik:1
RX-Pakete:368 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:368 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX-Bytes:25327 (25.3 KB) TX-Bytes:25327 (25.3 KB)

wlan0 Link encap:Ethernet Hardware Adresse 68:a3:c4:61:6d:c4
BROADCAST MULTICAST MTU:1500 Metrik:1
RX-Pakete:764 Fehler:0 Verloren:68 Überläufe:0 Fenster:0
TX-Pakete:154 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:137988 (137.9 KB) TX-Bytes:24329 (24.3 KB)

wwan0 Link encap:Ethernet Hardware Adresse 02:80:37:ec:02:00
BROADCAST MULTICAST MTU:1500 Metrik:1
RX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:0 (0.0 B) TX-Bytes:0 (0.0 B)

root@LAPL:~# route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.100.0.1 0.0.0.0 UG 0 0 0 eth0
10.100.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
Bitte warten ..
Mitglied: Lochkartenstanzer
26.08.2014 um 16:58 Uhr
Zitat von paj2000:

Vorab schon mal die gewünschten Daten:

root@LAPL:~# ifconfig -a
eth0 Link encap:Ethernet Hardware Adresse e4:11:5b:23:95:22
inet Adresse:10.100.1.1 Bcast:10.100.255.255 Maske:255.255.0.0

o.k.


root@LAPL:~# route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.100.0.1 0.0.0.0 UG 0 0 0 eth0
10.100.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0

o.k.
Bitte warten ..
Mitglied: paj2000
26.08.2014 um 16:59 Uhr
Des Gatway ist ein frisch aufgesetzter Linux-Server (Ubuntu 14.04).
Ich habe nur eine NEtzwerkkarte mit 2 virutellen Interfaces

Interface p2p1
10.1.1.1/16

Interface p2p1:0
10.100.0.1/16

Interface p2p1:1
10.200.0.1/16

Habe dann das IP-Forwarding mit
echo 1 > /proc/sys/net/ipv4/ip_forward
aktiviert
und das wars
Bitte warten ..
Mitglied: paj2000
26.08.2014 um 17:00 Uhr
oder zumindest Bilder/Screenshots posten von den Ausgaben in Wireshark?
Bitte warten ..
Mitglied: Lochkartenstanzer
26.08.2014 um 17:02 Uhr
Zitat von paj2000:

oder zumindest Bilder/Screenshots posten von den Ausgaben in Wireshark?

http://www.administrator.de/faq/20#toc-5
Bitte warten ..
Mitglied: Lochkartenstanzer
26.08.2014, aktualisiert um 17:10 Uhr
Zitat von paj2000:

Des Gatway ist ein frisch aufgesetzter Linux-Server (Ubuntu 14.04).
Ich habe nur eine NEtzwerkkarte mit 2 virutellen Interfaces

Interface p2p1
10.1.1.1/16

Interface p2p1:0
10.100.0.1/16

Interface p2p1:1
10.200.0.1/16

Habe dann das IP-Forwarding mit
echo 1 > /proc/sys/net/ipv4/ip_forward
aktiviert
und das wars

Dann ist das klar. Sofern Du keine (offensichtlich) VLANs verwendest, laufen alle Netze auf demselben Segment. Wie sagt kollege aqui imerm so schön:

Der Betrieb mehrerer IP-netze auf demselben LAN-Segment ist nicht ein nogo (Ich sag lieber "not recommended").

Da kommt es dann zu solchen (und vielen anderen) Effekten. Warum sollte Deine Kiste das Paket ans default gateway schicken, wenn doch das Ziel doch direkt erreichbar ist. Hast Du darauf geachtet, ob entsprechende ICMP-Pakete über die Leitung gegangen sind?

lks
Bitte warten ..
Mitglied: paj2000
26.08.2014 um 17:11 Uhr
wenn ich es in VLANs betreiben würde, kommt der Ping gar nicht an, da er aus dem VLAN des Netzes 10.100.0.0/16 nicht auf das VLAN mit NetzID 10.200.0.0/16 kommt.

Warum ist es Dir klar das er wegen der Server-Konfiguration am Client mit IP 10.100.1.1 den ICMP-Ping nicht über 10.100.0.1 sonder direkt auf 10.200.1.1 zustellt?
Bitte warten ..
Mitglied: Lochkartenstanzer
26.08.2014, aktualisiert um 17:16 Uhr
Zitat von paj2000:

wenn ich es in VLANs betreiben würde, kommt der Ping gar nicht an, da er aus dem VLAN des Netzes 10.100.0.0/16 nicht auf das
VLAN mit NetzID 10.200.0.0/16 kommt.

Dann machst Du was falsch. Er müßte dann das paket ans Gateway schicken.


Warum ist es Dir klar das er wegen der Server-Konfiguration am Client mit IP 10.100.1.1 den ICMP-Ping nicht über 10.100.0.1
sonder direkt auf 10.200.1.1 zustellt?

Weil vermutlch die Kiste über ICMP gesagt bekommen hat, daß 10.200.1.1 im selben Segment hängt.

So oder so: Zwei IP-Netze im selben Segment zu betreiben ist jedenfalls keine gute Idee, wenn man nicht weiß, wie man mit solchen unerwarteten Effekten umgeht.

lks
Bitte warten ..
Mitglied: paj2000
26.08.2014 um 17:17 Uhr
Bild eingefügt in Beitrag
Bitte warten ..
Mitglied: paj2000
26.08.2014 um 17:20 Uhr
Und wie gesagt: Wenn ich sie in getrennte VLANs packe dann funktioniert der Ping nicht mehr da er direkt zustellen will, was ja nicht geht.
So bin ich ja erst auf das ganze aufmerksam geworden!
Bitte warten ..
Mitglied: Lochkartenstanzer
26.08.2014, aktualisiert um 17:23 Uhr
Zitat von paj2000:

Bild eingefügt in Beitrag

Das sieht doch in Ordnung aus:

Quelle und Ziel sind korrekt und das Paket wird an das default gateway geschickt, daß durch Deine Kostruiktion dieselbe Mac hat wie das Ziel und daher es nicht von einem Paket zu untescheiden ist, daß direkt ans ziel geschickt wird.

Wo ist das problem? Sieht doch alles in Ordnung aus.

lks
Bitte warten ..
Mitglied: Lochkartenstanzer
26.08.2014, aktualisiert um 17:29 Uhr
Zitat von paj2000:

Und wie gesagt: Wenn ich sie in getrennte VLANs packe dann funktioniert der Ping nicht mehr da er direkt zustellen will, was ja
nicht geht.

Wie machst Du Deine VLANS? Und wie definierst Du dann die Interfaces in Deinem "Router".

lks
Bitte warten ..
Mitglied: paj2000
26.08.2014 um 17:31 Uhr
???
Paket1
SenderIP 10.100.1.1 (OK)
EmpfängerIP 10.200.1.1 (OK)
SenderMAC: e4:11:5b:23:95:22 (OK - ist MAC von meinem Laptop)
EmpfängerMAC: 50:e5:49:5b:5b:fd (NICHT OK - dies ist MAC-Adresse von 10.200.1.1 - hier müsste die MAC-Adresse des Gateways 10.100.0.1 stehen!!)

oder nicht?
Bitte warten ..
Mitglied: paj2000
26.08.2014 um 17:34 Uhr
auto p2p1
iface p2p1 inet static
address 10.1.1.1
netmask 255.255.0.0
gateway 10.1.9.1
dns-nameservers 10.1.9.1

auto p2p1:0
iface p2p1:0 inet static
address 10.100.0.1
netmask 255.255.0.0

auto p2p1:1
iface p2p1:1 inet static
address 10.200.0.1
netmask 255.255.0.0
Bitte warten ..
Mitglied: Lochkartenstanzer
26.08.2014 um 17:36 Uhr
Zitat von paj2000:

???
Paket1
SenderIP 10.100.1.1 (OK)
EmpfängerIP 10.200.1.1 (OK)
SenderMAC: e4:11:5b:23:95:22 (OK - ist MAC von meinem Laptop)
EmpfängerMAC: 50:e5:49:5b:5b:fd (NICHT OK - dies ist MAC-Adresse von 10.200.1.1 - hier müsste die MAC-Adresse des
Gateways 10.100.0.1 stehen!!)


Das ist doch dieselbe, wenn Du gateway und ziel beide auf das interface p2p1 draufknallst.

lks

PS: Mach mal einen ifconfig -a auf deinem gateway und poste das.
Bitte warten ..
Mitglied: Lochkartenstanzer
26.08.2014, aktualisiert um 17:39 Uhr
Das sind keine VLANS.

Da werden einafch nur einem Interface nur mehrere IP-Adressen zugeteilt.

Lies dir mal http://manpages.ubuntu.com/manpages/trusty/man5/vlan-interfaces.5.html durch.

lks
Bitte warten ..
Mitglied: paj2000
26.08.2014 um 17:39 Uhr
ich habe keine vlan-specific tags bzw. konfigurationen vorgenommen, da ich ja hinter einem Untagged Port mit dem Router sitze.

Rechner 10.100.1.1/16 gehört zu VLAN2 (Sitzt hinter Port 2)
Rechner 10.200.1.1/16 gehört zu VLAN3 (Sitzt hinter Port 3)

Router/Server 10.1.1.1/16 gehört zu VLAN1 (Sitzt hinter Port 1)

Port 1 ist für VLAN1-3 berechtigt und vergibt den Tag für VLAN1 für eintreffende Pakete vom Server
Port 2 ist für VLAN1-2 berechtigt und vergibt den Tag für VLAN2 für eintreffende Pakete vom Client 10.100.1.1/16
Port 3 ist für VLAN1&3 berechtigt und vergibt den Tag für VLAN3 für eintreffende Pakete vom Client 10.200.1.1/16
Bitte warten ..
Mitglied: aqui
26.08.2014, aktualisiert um 17:41 Uhr
Ich habe nur eine NEtzwerkkarte mit 2 virutellen Interfaces
Uuuhhh böses Faul...da geht das Drama schon los. Das ist kein supportetes Design im TCP/IP ! Sowas macht man ausschliesslich temporär für IP Migrationen aber niemals im Wirkbetrieb. Du fährst so mit mehreren IP Adressen auf einem gemeinsamen Draht ! Ein NoGo.
Kein Wunder das es da zu Problemen kommt, denn allein schon die ganze ICMP Geschichte funktioniert so nicht mehr, denn von welcher IP sollte der Host dann ICMP wohl machen ?
Vergiss den Unsinn...
Wenn überhaupt dann solltest du dort sauber mit VLANs arbeiten auf einem singulären Interface. Das garantiert ein sauberes Routing !
Wie das geht kannst du hier nachlesen:
http://www.administrator.de/wissen/netzwerk-management-server-mit-raspb ...

Alles andere ist zum Scheitern verurteilt.
Bitte warten ..
Mitglied: paj2000
26.08.2014 um 17:44 Uhr
lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:65536 Metrik:1
RX-Pakete:437 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:437 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX-Bytes:39272 (39.2 KB) TX-Bytes:39272 (39.2 KB)

p2p1 Link encap:Ethernet Hardware Adresse 74:d0:2b:90:42:72
inet Adresse:10.1.1.1 Bcast:10.1.255.255 Maske:255.255.0.0
inet6-Adresse: fe80::76d0:2bff:fe90:4272/64 Gültigkeitsbereich:Verbindung
inet6-Adresse: fec0::6d31:1285:65d9:16bd/64 Gültigkeitsbereich:Standort
inet6-Adresse: fec0::76d0:2bff:fe90:4272/64 Gültigkeitsbereich:Standort
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX-Pakete:93372 Fehler:0 Verloren:64 Überläufe:0 Fenster:0
TX-Pakete:67477 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:21417914 (21.4 MB) TX-Bytes:19296747 (19.2 MB)

p2p1:0 Link encap:Ethernet Hardware Adresse 74:d0:2b:90:42:72
inet Adresse:10.100.0.1 Bcast:10.100.255.255 Maske:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1

p2p1:1 Link encap:Ethernet Hardware Adresse 74:d0:2b:90:42:72
inet Adresse:10.200.0.1 Bcast:10.200.0.255 Maske:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1

p3p1 Link encap:Ethernet Hardware Adresse 00:c0:ca:13:13:d7
BROADCAST MULTICAST MTU:1500 Metrik:1
RX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:0 (0.0 B) TX-Bytes:0 (0.0 B)
Bitte warten ..
Mitglied: paj2000
26.08.2014 um 17:50 Uhr
Ich habe mich an diese anleitung gehalten:
http://www.heise.de/netze/artikel/Linux-224004.html

ein Server mit einer Netzwerkkarte der zwischen den einzelnen /16-Netze (welche alle in eigene VLANS gekapselt sind) als Router vermittelt ... nichts anderes mache ich da.

Und das kann nicht funktionieren?
Bitte warten ..
Mitglied: aqui
26.08.2014 um 18:00 Uhr
Die ist generell richtig nur kann das sein das du sie falsch umgesetzt hast ??
WIE bindest du dann den Switch an bzw. wie ist dessen Konfig ??
Irgendwo liegt da was im Argen...

Dieses Tutorial hat weitere Details dazu:
http://www.administrator.de/wissen/vlan-installation-und-routing-mit-m0 ...

Das RasPi VLAN Tutorial oben hat aber eine aktuelle Konfig. Die von Heise ist schon älzer und stimmt ggf. nicht mehr. Beachte das !
In einem RasPi VLAN laut der Tutorial Konfig passiert das nämlich nicht was du schilderst !
Bitte warten ..
Mitglied: paj2000
26.08.2014 um 18:06 Uhr
ich werde die tutorials nachher beim Abendessen durchackern...
AdHoc sehe ich aber hier keinen Fehler bei mir ... in dem RaspiVLAN Tutorial sitz er halt hinter einem Tagged Port des Switches, wodurch die "vlan-fähigkeit" des Raspis von nöten ist ... ich habe ihn auch untagged hinter einem switch sitzen, sodass er die VLAN-Tags schon am Port rausfiltert, sodass sie untagged auf den Server kommen ... dass ist ja im Prinzip das selbe oder nicht?!
Bitte warten ..
Mitglied: Lochkartenstanzer
27.08.2014, aktualisiert um 07:57 Uhr
Zitat von paj2000:

ich habe keine vlan-specific tags bzw. konfigurationen vorgenommen, da ich ja hinter einem Untagged Port mit dem Router sitze.

Rechner 10.100.1.1/16 gehört zu VLAN2 (Sitzt hinter Port 2)
Rechner 10.200.1.1/16 gehört zu VLAN3 (Sitzt hinter Port 3)

Router/Server 10.1.1.1/16 gehört zu VLAN1 (Sitzt hinter Port 1)

Port 1 ist für VLAN1-3 berechtigt und vergibt den Tag für VLAN1 für eintreffende Pakete vom Server
Port 2 ist für VLAN1-2 berechtigt und vergibt den Tag für VLAN2 für eintreffende Pakete vom Client 10.100.1.1/16
Port 3 ist für VLAN1&3 berechtigt und vergibt den Tag für VLAN3 für eintreffende Pakete vom Client
10.200.1.1/16

Ich glaube es wäre ganz geschickt, wenn Du uns mal ein Bild von Deinem Netz malst mit passenden IP-Adressen udn VLAN-Bezeichnungen.

Ich habe den Verdacht, daß irgendetwas an Deiner VLAN-Konfiguration faul ist udn du auch mit den IP-Adressen irgendwie durcheinander bist.

Außerdem stellt sich mir die Frage warum Du die Ports nicht einfach als tagged definierst? Mit deinem Linux kannst du das ohen weiteres einrichten und konfigurieren.

lks
Bitte warten ..
Mitglied: aqui
27.08.2014 um 10:49 Uhr
Da ist de facto was mit dem VLAN Setting der Server NIC im Argen !
Ein tcpdump sollte das aber schnell zeigen.
Bitte warten ..
Mitglied: Lochkartenstanzer
27.08.2014 um 13:04 Uhr
Zitat von aqui:

Da ist de facto was mit dem VLAN Setting der Server NIC im Argen !

Er nutzt dort überhaupt kein VLAN Um VLANs zu nutzen, müßte er Puntke statt doppelpunkte in /etc/network/interfaces nutzen. Alelrdings muß er den Potzr dazu als tagged-Port betreiben.

lks
Bitte warten ..
Mitglied: aqui
27.08.2014 um 18:03 Uhr
Falsch ! Die oben zitierte ct' Anleitung bezieht sich ja auf eine tagged VLAN Konfig an einem Linux Host, denn es behandelt ja VLAN Tagging und eben keine Subinterface Konfig !
Die zitierte Debian Konfig (RasPi) ist aber aktueller und benutzt auch aktuelle Pakete und funktioniert (getestet !) auch fehlerfrei.
Letztere ist IP technisch ja auch nicht zu empfehlen wegen der gravierenden Nachteile.
Bitte warten ..
Mitglied: Lochkartenstanzer
27.08.2014, aktualisiert um 18:25 Uhr
Zitat von aqui:

Falsch ! Die oben zitierte ct' Anleitung bezieht sich ja auf eine tagged VLAN Konfig an einem Linux Host, denn es behandelt
ja VLAN Tagging und eben keine Subinterface Konfig !

schon.

Aber laut dem Auszug aus seinen /etc/network/interfaces hat er immer nur subinterfaces benuzt und nie vlans

p2p1 Link encap:Ethernet Hardware Adresse 74:d0:2b:90:42:72
...
p2p1:0 Link encap:Ethernet Hardware Adresse 74:d0:2b:90:42:72
...
p2p1:1 Link encap:Ethernet Hardware Adresse 74:d0:2b:90:42:72

Das sieht für mich nicht nach getaggeden VLANs aus.

Oder er hat schlicht und einfach statt p2p1 . 1 p2p : 1 genommen.

lks
Bitte warten ..
Mitglied: paj2000
27.08.2014 um 19:03 Uhr
Vielen Dank vorab für Eure Geduld ... habe heute mir mal das ganze nochmals zu gemüte geführt ... vergesst mal das VLAN ... ich mache das morgen so wie in der RaspiDoku ... doch eines geht mir noch immer nicht ein.
Wenn ich einen Rechner habe mit
IP: 10.120.1.1/16
Gateway 10.120.0.1
und danach einen Host pingen will mit 10.100.1.1 dann muss doch das Paket an das Gateway gesandt werden?!? oder nicht?!
Und er versucht bei mir immer per ARP zuerst die MAC von 10.100.1.1 zu erfragen und dann das Paket direkt zustellen an 10.100.1.1 anstatt es an 10.120.0.1 zu senden?!

Der Vollständigkeit halber die Ausgabe von "route -n":
root@LAPL:~# route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.120.0.1 0.0.0.0 UG 0 0 0 eth0
10.120.0.0 0.0.0.0 255.255.0.0 U 1 0 0 eth0
Bitte warten ..
Mitglied: paj2000
27.08.2014 um 19:05 Uhr
Kann ich hier einen Mitschnitt von tcpdump bzw. Wireshark hier als Datei posten?
Bitte warten ..
Mitglied: paj2000
27.08.2014 um 19:44 Uhr
Es war so dass ich vom Gateway eine ICMP-Redirect (Code 5) Anforderung bekommen habe Pakete an 10.100.1.1 direkt zuzustellen ...
die Frage ist nun aber noch: Warum sendet mein Router/Server dies?
Redirect Messages werden doch nur gesandt, wenn es im gleichem Netzsegment eine direktere Verbindung gibt wie hier erklärt:
http://kb.pocnet.net/wiki/ICMP-Redirects
Dies ist jedoch bei meinem Setup nicht der Fall ... da werde ich wohl noch etwas suchen müssen ... oder mir helfen lassen müssen ;)
Bitte warten ..
Mitglied: Lochkartenstanzer
27.08.2014 um 22:35 Uhr
Zitat von paj2000:


Dies ist jedoch bei meinem Setup nicht der Fall ... da werde ich wohl noch etwas suchen müssen ... oder mir helfen lassen
müssen ;)

Doch. Dein "Router" hat beide "Beine" im selben Segment, weil Du beide Netze auf dasselbe Interface gelegt hast.

lks
Bitte warten ..
Mitglied: paj2000
28.08.2014 um 06:37 Uhr
Dann verstehe ich es ... vielen Dank für das Licht der Erkenntnis - es ist schön aus dem Dunklen hervorzukriechen ;)

Dann ist dies wie in diesem Artikel (http://www.heise.de/netze/artikel/Linux-224004.html) beschrieben eigentlich wie folgt zu ergänzen:
Da die Vermittlung(Routing) zwischen den VLANs(und den dazugehörigen IP-Netzen) ein Server mit nur einer physischen Karte und mehreren logischen Interfaces durchführt, müssen ICMP-Redirect-Messages am Server ausgeschalten werden (da der Routers durch die logischen Interfaces den Zugang in jedes Netz mit nur einer physikalischen Netzwerkkarte hat und so immer Redirect Messages ausgibt):
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

Bitte nochmals um kurze Bestätigung ob ich das so richtig verstanden und beschrieben habe ;)

Was ich für mich noch checken muss ist, warum der Ping vom Windowsclient auf eine Netzwerkkomponente in einem anderem Netz sauber geroutet wurde und funktioniert hat, hingegen zum Linuxlaptop (der wiederum in einem anderem Netz war) nicht?!
Bitte warten ..
Mitglied: paj2000
28.08.2014 um 06:47 Uhr
noch ein kurzer Nachtrag:
statt
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
habe ich nun die NIC direkt angegeben ... dann funktionierts:
echo 0 > /proc/sys/net/ipv4/conf/p2p1/send_redirects
Bitte warten ..
Mitglied: aqui
28.08.2014, aktualisiert um 10:22 Uhr
Ist ja eine interessante Lösung ! An einen Kernel Bug denkt man ja immer zuletzt. Gut wenns nun klappt obwohl es doch dann wieder Fragen aufwirft, denn in einer sauberen VLAN Konfiguration der NIC sollte das (getestet) NICHT passieren !
Bitte nochmals um kurze Bestätigung ob ich das so richtig verstanden und beschrieben habe ;)
Nein, deine Schlussfolgerung ist falsch von oben...!
Man muss das schon sehr genau betrachten. Es gilt folgendes:

1.) Wenn du mit Secondary IP Adressen fährst also EIN physisches Interface hast auf dem du mehrere unterschiedliche IP Adapter Adressen hast dann bekommst du logischerweise ein Problem mit ICMP Redirects. Der Router weiss ja nicht von welcher IP er die ICMP Pakete senden soll. Meist macht er es von der Promäradresse, was dann aber bewirkt das alle anderen Secondary IPs an diesem Interface ausgespart werden. Dadurch kommt es eben zu dem ICMP Chaos.
Genau DAS ist einer der vielen Gründe warum Secondary IPs auf einer physischen NIC kein besonders gutes Design ist.
Es lässt sich manchmal nicht vermeiden wenn man IP Adressen migriert in einem Segment. Allein dafür ist es auch gedacht, denn für eine temporäre Migration kann man das machen.
Niemals aber für den Produktivbetrieb !!

2.) Ganz anders sieht die Sache aus wenn du auf dem Router oder in deinem Falle Host VLAN Interfaces anlegst. Immer unter der Voraussetzung das das richtig gemacht wird wie z.B. im o.a. Raspberry_Tutorial unterm Kabitel VLAN Installation beschrieben.
Die ct' Anleitung beschreibt das ebenso aber mit etwas älteren Kommandos und Paketet die dann nicht immer richtig funktionieren.
Generell ist es aber so das diese Konfiguration auf der NIC 2 virtuelle und völlig getrennte Interfaces kreiert, die der Rechner auch so behandelt.
Zwar gehen sie physisch über eine NIC sind intern im Kernel aber 2 vollkommen getrennte NICs wenn man so will. Damit schickt der Rechner auch getrennt ICMP und alle anderen Kontrol Pakete über diesen Link sauber pro Interface getrennt.
Sie tauchen zwar wieder physisch an der gleichen NIC auf aber die Pakete haben ja immer eine eindeutige VLAN ID im 802.1q VLAN Header des Pakets.
An diesen NICs kann man dann auch nur Switches anschliessen oder Endgeräte die Pakete mit 802.1q VLAN Tagging verstehen, also tagged Uplinks.
Diese Komponenten trennen diesen Traffic ja auch immer wieder in völlig getrennte Segmente, eben VLANs.
Rein funktionell betrachtet verhält sich diese Konfiguration der NIC exakt so wie 2 separat getrennte NICs im Rechner. Nichts anderes emulieren ja die virtuellen internen NICs mit dem Tagging.

In so fern hast du hier also 2 völlig unterschiedliche Designs und Szenarien die du auch so betrachten musst.
Vereinfacht gesagt:
Secondary IPs = Mehrere IP Netze auf einem Draht ==> technisch kein TCP/IP Support = Probleme = NoGo
VLAN Separation der NIC = saubere Trennung ==> problemlos da TCP/IP technsich sauber = richtige Konfig = erfordert aber VLAN Switch
Bitte warten ..
Mitglied: paj2000
28.08.2014 um 10:31 Uhr
vielen Dank für die ausführliche Erläuterung!
Werde es heute einmal "sauber" wie von Dir und dem RaspiTutorial beschrieben konfigurieren!
Bitte warten ..
Mitglied: aqui
28.08.2014 um 10:51 Uhr
Und dann wird es auch sauber funktionieren....du wirst sehen !
Bitte warten ..
Mitglied: paj2000
28.08.2014 um 17:14 Uhr
So ist es ;)
Alles fein nun ;)
Bitte warten ..
Mitglied: aqui
28.08.2014 um 17:16 Uhr
Klasse, hört sich gut an wenn nun alles klappt wie es soll !

Danke fürs Feedback und bitte
http://www.administrator.de/faq/32
nicht vergessen.
Bitte warten ..
Neuester Wissensbeitrag
Internet

Unbemerkt - Telekom Netzumschaltung! - BNG - Broadband Network Gateway

(3)

Erfahrungsbericht von ashnod zum Thema Internet ...

Ähnliche Inhalte
Server
gelöst Weiterleitung mit Apache über Linux-Gateway ohne Portangaben (13)

Frage von markuswo zum Thema Server ...

Monitoring
System Monitoring für Windows, Linux (4)

Frage von manuelw zum Thema Monitoring ...

Router & Routing
Radius für 15 User direkt über Mikrotik- oder Ubiquiti-Router (4)

Frage von Muesliriegel zum Thema Router & Routing ...

Heiß diskutierte Inhalte
Switche und Hubs
Trunk für 2xCisco Switch. Wo liegt der Fehler? (17)

Frage von JayyyH zum Thema Switche und Hubs ...

Windows Server
Outlook Verbindungsversuch mit Exchange (15)

Frage von xbast1x zum Thema Windows Server ...

DSL, VDSL
DSL-Signal bewerten (14)

Frage von SarekHL zum Thema DSL, VDSL ...