Verkabelung und Konfiguration eines Testnetzwerks mit VLAN und Bridged Router

linuxnutzer

Commander
Registriert
Dez. 2011
Beiträge
2.458
Fortsetzung von:
https://www.computerbase.de/forum/threads/billiger-guenstiger-802-1q-switch-mit-8-10-ports.2024867/

Wenn es nicht schon tw. funktioniert hätte ...

Grundsätzlich geht es mir darum, dass ich die Fritzbox anfangs nur pingen kann, zuerst ohne von mir erstelle VLANs. Die Besonderheit ist ja der Wireless Bridged Router, aber anders kann ich mein Testszenario nicht aufbauen, ohne das "produktive" Netzwerk zu stören.

1. Versuch
Notebook mit Mikrotik RB4011 verbunden, anderer Port als 1.
RB4011 von Port1 zu TP-Link (Brdiged Router) irgendein LAN-Port
Notebook bekommt via DHCP vom RB4011 IP-Adresse

RB4011 hatte IP-Adresse 192.168.88.2

Danach habe ich die IP-Adresse beim RB4011 auf 192.168.88.1 geändert, sollte eigentlich total egal sein. Der Mikrotik-Switch hatte 88.1 und den habe ich auf 88.2 geändert, wobei dazu der RB4011 abgeklemmt wurde.

Danach hat der Ping auf die FB nicht mehr funktioniert, wobei Notebook und Router auch neu gestartet wurden.

Code:
~# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.88.2    0.0.0.0         UG    100    0        0 eno1
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eno1
192.168.88.0    0.0.0.0         255.255.255.0   U     100    0        0 eno1

Ich frage mich woher die 192.168.88.2 als Vorgaberoute kommen. Ist ja alles auf DHCP-Automatik gestellt. die .2 wären der Switch, aber soweit bin ich noch nicht, der ist nicht (mehr) angeklemmt.

Wenn ich am RB4011 nicht Port 1 verwende, dann kann ich die FB pingen, aber das ist wohl wie wenn ich das Notebook gleich an die Bridge anschließe.

Kann es sein, dass mich ein ARP-Cache verrückt macht?

Beim Switch möchte ich dann beide probieren, ob sie grundsätzlich funktionieren, aber 1 Schritt nach dem anderen.
 
Zuletzt bearbeitet:
Moin,

beim DHCP wird deiner Netzwerkkarte eine IP und auch die route mitgegeben, wenn du jetzt "nach" dem "DHCP-Paket" die IP des routers änderst....DHCP wird nicht "dauerhaft" gesendet.
Wikipedia DHCP (insbesondere der Absatz DHCP-Refresh)
Die DHCP-Config hat eine gültigkeitsdauer, und erst wenn diese abläuft, bzw schon etwas früher, fragt dein Notebook nach einer "neuen" IP bzw ob die alte erhalten bleiben kann, "dann" gibts wieder neue bzw alte DHCP-Daten (aka routen).
Ergo Netzwerkkarte zurücksetzen und dann schauen wir weiter:

Linux: dhclient -r eth0 oder die NT-Karte an & aus schalten oder den netzwerkdienst neu starten :)
 
  • Gefällt mir
Reaktionen: linuxnutzer und madmax2010
oder den netzwerkdienst neu starten

Mache ich sowieso.

Ich habe die Netzwerke ziemlich viel gewechselt. Die Defaultnetze sind je nach Marke sehr unterschiedlich, aber ab jetzt möchte ich bei DHCP bleiben. Zum Switch komme ich aber nur mit fester IP.

Auch ein Neustart des Notebooks bzw. ein Trennen vom Strom sollte die "Boxen" dazu bringen, gecachte Einstellungen zu verlieren.

Code:
ifconfig -a
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.88.254  netmask 255.255.255.0  broadcast 192.168.88.255

Code:
~# dhclient -r eno1
(leer)

Ich bin noch immer bei 192.168.88.2 als Vorgaberoute bei meinem Ubuntu-Notebook. Keine Ahnung woher das kommt.

Ich finde es ja auch interessant, dass meine NIC im Notebook .254 hat.


Ergänzung ()

Ich kapiere da noch was nicht beim Routing. Vorgegeben ist die Route 192.168.88.2, aber ich kann den RB4011 mit 192.168.88.1 via Browser problemlos aufrufen und ein Ping vom RB4011 zur Frritzbox mit 192.168.178.1 funktioniert auch. Der RB4011 hat Defaulteinstellungen. Sollte da eine FW-Regel den Ping vom Notebook über den RB4001 zur FB verhindern?

Code:
[admin@RB4011] > /ping 192.168.178.1
  SEQ HOST                                     SIZE TTL TIME  STATUS           
    0 192.168.178.1                              56  64 2ms 
    1 192.168.178.1                              56  64 2ms 
    2 192.168.178.1                              56  64 11ms
    3 192.168.178.1                              56  64 3ms 
    sent=4 received=4 packet-loss=0% min-rtt=2ms avg-rtt=4ms max-rtt=11ms
 
Zuletzt bearbeitet:
linuxnutzer schrieb:
Code:
~# dhclient -r eno1
(leer)
Richtig wäre:
Code:
sudo dhclient -v eno1
Dann bekommst du auch eine Ausgabe und siehst, was los ist. Beispiel:
Code:
Internet Systems Consortium DHCP Client 4.4.2-P1
Copyright 2004-2021 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eno1/b3:10:c1:91:86:f4
Sending on   LPF/eno1/b3:10:c1:91:86:f4
Sending on   Socket/fallback
DHCPREQUEST for 192.168.20.13 on eno1 to 255.255.255.255 port 67
DHCPNAK from 192.168.20.1
DHCPDISCOVER on eno1 to 255.255.255.255 port 67 interval 4
DHCPOFFER of 192.168.20.10 from 192.168.20.1
DHCPREQUEST for 192.168.20.10 on eno1 to 255.255.255.255 port 67
DHCPACK of 192.168.20.10 from 192.168.20.1
bound to 192.168.20.10 -- renewal in 3311 seconds.
linuxnutzer schrieb:
ein Ping vom RB4011 zur Frritzbox mit 192.168.178.1 funktioniert auch
Warum sollte das auch nicht funktionieren?
linuxnutzer schrieb:
aber ich kann den RB4011 mit 192.168.88.1 via Browser problemlos aufrufen
Ja, da muss ja auch nichts geroutet werden. Du bleibst doch mit deiner Anfrage im gleichen Subnetz.
linuxnutzer schrieb:
Sollte da eine FW-Regel den Ping vom Notebook über den RB4001 zur FB verhindern?
Nein.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: linuxnutzer und Raijin
Mit manueller IP-Adresse und Route nach 192.168.88.1 scheint es zu funktionieren:

Code:
e5550:~# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.88.1    0.0.0.0         UG    100    0        0 eno1
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eno1
192.168.88.0    0.0.0.0         255.255.255.0   U     100    0        0 eno1


Code:
e5550:~# ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1) 56(84) Bytes Daten.
64 Bytes von 192.168.178.1: icmp_seq=1 ttl=63 Zeit=3.32 ms
64 Bytes von 192.168.178.1: icmp_seq=2 ttl=63 Zeit=2.34 ms
Ergänzung ()

Wieder zurück bei DHCP:

Code:
e5550:~# dhclient -v eno1
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eno1/20:..:..:..:..:17
Sending on   LPF/eno1/20:..:..:..:..:17
Sending on   Socket/fallback
DHCPREQUEST for 192.168.88.254 on eno1 to 255.255.255.255 port 67 (xid=0xa7b1aeb)
DHCPACK of 192.168.88.254 from 192.168.88.1 (xid=0xeb1a7b0a)
RTNETLINK answers: File exists
bound to 192.168.88.254 -- renewal in 253 seconds.

Warum sollte das auch nicht funktionieren?

Vergiss nicht eventuell unerkannte Probleme bei der Wireless Bridge.
 
Zuletzt bearbeitet:
linuxnutzer schrieb:
Vergiss nicht eventuell unerkannte Probleme bei der Wireless Bridge.
Du schreibst, dass es der Ping vom Notebook über den RB4011 über die Bridge zur Fritte funktioniert hat, bis du die DHCP-Konfiguration auf dem RB4011 verhunzt hast. Also liegt das Problem nicht zwischen RB4011 und Fritte.
linuxnutzer schrieb:
Mit manueller IP-Adresse und Route nach 192.168.88.1 scheint es zu funktionieren
Also spricht viel dafür, dass der DHCP-Server auf dem RB4011 falsch konfiguriert ist. Was liefert:
Code:
/ip dhcp-server network print
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: linuxnutzer und Raijin
Code:
[admin@RB4011] > /ip dhcp-server network print
Flags: D - dynamic
 #   ADDRESS            GATEWAY         DNS-SERVER          WINS-SERVER     DOM
 0   ;;; defconf
     192.168.88.0/24    192.168.88.2

Ok, Übeltäter gefunden, frage ich mich nur, wie es dazu kam. Eventuell weil ich den CRS-Switch kurz an den RB angeschlossen hatte.

Muss jetzt mal weitertesten und überlegen welche Geräte ich wie beim Testaufbau will.

Muss ich beim u.a. Beispiel nun das Routing auf die FB ändern?

Also die TP-Link Bridge ist sozusagen Platzhalter für die FB.

Die RB dient als Firewall

Also müsste ich wie schon jetzt die RB (Port 1) an den TP-Link (beliebiger LAN-Port) anschließen

Den CRS verbinde ich an irgendeinem Port (außer Port 1) mit dem RP an irgendeinem Port (außer 1)?

Das Notebook verbinde ich mit dem CRS an irgendeinem Port (außer 1)?

Und ich sollte weiter die FB pingen können?
 
linuxnutzer schrieb:
Muss ich beim u.a. Beispiel nun das Routing auf die FB ändern?
Nein.
linuxnutzer schrieb:
Also müsste ich wie schon jetzt die RB (Port 1) an den TP-Link (beliebiger LAN-Port) anschließen
Ja.
linuxnutzer schrieb:
Den CRS verbinde ich an irgendeinem Port (außer Port 1) mit dem RP an irgendeinem Port (außer 1)?
Ja.
linuxnutzer schrieb:
Das Notebook verbinde ich mit dem CRS an irgendeinem Port (außer 1)?
Ja.
linuxnutzer schrieb:
Und ich sollte weiter die FB pingen können?
Ja.
 
  • Gefällt mir
Reaktionen: linuxnutzer
Leider kann ich die FB nicht pingen.

Code:
[admin@RB4011] > /ip dhcp network print       
Flags: D - dynamic
 #   ADDRESS            GATEWAY         DNS-SERVER          WINS-SERVER     DOM
 0   ;;; defconf
     192.168.88.0/24    192.168.88.2

Interessanterweise meint http://192.168.88.1/webfig/#IP:DHCP_Client.DHCP_Client.1

Gateway192.168.178.1
DHCP Server192.168.178.1

Da sind also 2 DHCP-Server im Spiel, IMHO ist das ok, weil ja 2 Netze, oder?
 
Kein Wunder, wenn der DHCP-Server auf dem RB4011 immer noch das falsche Gateway verteilt.

Zitat von linuxnutzer:


Muss ich beim u.a. Beispiel nun das Routing auf die FB ändern?
Nein.

Hier ist also ein Miissverständnis.

Ich verstehe nicht ganz woher der DNS2 aus dem FB-Netz kommt.

ip-adressen.png


Ich muss jetzt posten bevor ich neustarte, Gateway ist geändert, sieht aber bei mir deutlich unterschiedlich zu https://help.mikrotik.com/docs/display/ROS/First+Time+Configuration aus. Noch reichte die Änderung für den Ping nicht. Ich starte vorsichtshalber alles neu.
Ergänzung ()

Klappt auch nach dem Neustart des Notebooks und der Stromtrennung aller Boxen nicht.

Am Notebook habe ich jetzt:

Code:
e5550:~# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.178.1   0.0.0.0         UG    100    0        0 eno1
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eno1
192.168.88.0    0.0.0.0         255.255.255.0   U     100    0        0 eno1
192.168.178.1   0.0.0.0         255.255.255.255 UH    100    0        0 eno1

Ein arpscan am NB findet die FB nicht.

Achtung, ich habe nur das Gateway geändert und sonst nichts.

Code:
$ ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1) 56(84) Bytes Daten.
Von 192.168.88.254 icmp_seq=1 Zielhost nicht erreichbar
^C
--- 192.168.178.1 ping statistics ---
4 Pakete übertragen, 0 empfangen, +1 Fehler, 100% Paketverlust, Zeit 3075ms

Code:
[admin@RB4011] > /ip dhcp-server network print                  
Flags: D - dynamic 
 #   ADDRESS            GATEWAY         DNS-SERVER          WINS-SERVER     DOM
 0   ;;; defconf
     192.168.88.0/24    192.168.178.1
 
Zuletzt bearbeitet:
Code:
[admin@RB4011] > /ip dhcp-server network print
Flags: D - dynamic
 #   ADDRESS            GATEWAY         DNS-SERVER          WINS-SERVER     DOM
 0   ;;; defconf
     192.168.88.0/24    192.168.88.1

Code:
e5550:~# arp
Adresse Hardware-Typ Hardware-Adresse Optionen Maske Schnittstelle
_gateway                 ether   08:..:..:..:..:04   C                     eno1
router.lan               ether   08:..:..:..:..:83   C                     eno1

Code:
e5550:~# arp -n
Adresse Hardware-Typ Hardware-Adresse Optionen Maske Schnittstelle
192.168.88.1             ether   08:..:..:..:..:04   C                     eno1
192.168.88.2             ether   08:..:..:..:..:83   C                     eno1

Code:
e5550:~# ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1) 56(84) Bytes Daten.
64 Bytes von 192.168.178.1: icmp_seq=1 ttl=63 Zeit=2.88 ms

192.168.88.2 ist der Switch, kann man router.lan einfach ignorieren und im Kopf behalten, dass das der Switch ist?
 
Na ja, was heißt ignorieren? Der Switch wird aufgelistet, weil das Managment Interface des Switches im gleichen Subnetz hängt wie dein Notebook. Für den Anfang sollte das erst mal keine Rolle spielen.
 
  • Gefällt mir
Reaktionen: linuxnutzer
Für den Anfang sollte das erst mal keine Rolle spielen.

wird sicher kein Problem sein, das in switch.lan umzubennen.Das dürfte Mikrotik-spezifisch sein. Der GS1900 bringt keinen Namen, sondern die IP.

Code:
e5550:~# arp
Adresse Hardware-Typ Hardware-Adresse Optionen Maske Schnittstelle
_gateway                 ether   08:..:..:..:..:04   C                     eno1
192.168.88.253           ether   98:..:..:..:..:ee   C                     eno1

Ich stecke statt dem Zyxel wieder den CRS Switch an und probiere mich mal mit VLANs.
 
Zurück
Oben