LAG Bonding mit VLAN Routing Centos7
Hallo zusammen,
da ich vom Microsoft mich verabschieden möchte, habe ich mir zum üben und kennenlernen einen Centos7 Server aufgebaut. Der Server soll künftig vier über KVM VM mit BitDefender Cloud, IRC, Print-Server und Backupserver betreiben. Außerdem möchten diese VM´s von fünf verschiedenen VLAN über LAG (zwei verschiedene Netzwerkkarten) erreichbar sein. Verwendet werden vier TP-Link Switch TL-SG3424, TL-SG3216 und TL-SG3210. Die Konfiguration von Switches ist kein Problem, diese laufen. Aber ….
Habe vorgestern Informationen gesammelt zur der Bonding-Konfiguration und habe dann gestern einiges davon ausprobiert.
Leider nicht mit dem gewünschtem Ergebnis.
Eins ist Fakt. Die Anleitung für die Konfiguration von Centos6 kann mir leider nicht helfen. Den dies habe ich sehr oft gefunden.
Zum Feierabend habe ich dann noch eine Seite gefunden und mit danach vorgegangen.
https://www.unixmen.com/linux-basics-create-network-bonding-on-centos-76 ...
Edit file /etc/sysconfig/network-scripts/ifcfg-enp0s8,
vi /etc/sysconfig/network-scripts/ifcfg-enp0s8
Modify the file as shown below.
Then, Edit file /etc/sysconfig/network-scripts/ifcfg-enp0s9,
vi /etc/sysconfig/network-scripts/ifcfg-enp0s9
Modify the file as shown below.
Save and close the files.
Now, activate the Network interfaces.
Now, enter the following command to make Network Manager aware the changes.
(Ich habe jede Variable in Gänsefüßchen gesetzt)
nmcli con reload
Restart network service to take effect the changes.
(Doch es wollte nicht starten, bis ich den befehl „systemctl stop NetworkManager.service && systemctl disable NetworkManager.service“ ausgeführt habe)
dann hat auch der Befehl „cat /proc/net/bonding/bond0“ eine ähnliche Ausgabe wie auf der Seite gebracht. Und der Server war von VLAN1 erreichbar. Nach dem Neustart jedoch nicht mehr. Als ich dann über den NetworkManager angefangen einige zuviel erstellte Scripts zu löchen, habe ich die falsche entfernt. Dann musste ich leider Feierabend machen.
Nun bin ich zuhause und es gibt mir einfach nicht die Ruhe, was habe ich übersehen? Hat jemand das Malen nach Zahlen für mich zur dem Thema?
Tut mir leid, wenn mein Text schwer zu lesen ist, bin noch am üben. Ach ja, versteht mich bitte nicht falsch. Die Beträge welche ich hier gefunden habe waren fast alle mit nur halb angeschnittenen Antworten.
Viele Grüße
Ich
da ich vom Microsoft mich verabschieden möchte, habe ich mir zum üben und kennenlernen einen Centos7 Server aufgebaut. Der Server soll künftig vier über KVM VM mit BitDefender Cloud, IRC, Print-Server und Backupserver betreiben. Außerdem möchten diese VM´s von fünf verschiedenen VLAN über LAG (zwei verschiedene Netzwerkkarten) erreichbar sein. Verwendet werden vier TP-Link Switch TL-SG3424, TL-SG3216 und TL-SG3210. Die Konfiguration von Switches ist kein Problem, diese laufen. Aber ….
Habe vorgestern Informationen gesammelt zur der Bonding-Konfiguration und habe dann gestern einiges davon ausprobiert.
Leider nicht mit dem gewünschtem Ergebnis.
Eins ist Fakt. Die Anleitung für die Konfiguration von Centos6 kann mir leider nicht helfen. Den dies habe ich sehr oft gefunden.
Zum Feierabend habe ich dann noch eine Seite gefunden und mit danach vorgegangen.
https://www.unixmen.com/linux-basics-create-network-bonding-on-centos-76 ...
Edit file /etc/sysconfig/network-scripts/ifcfg-enp0s8,
vi /etc/sysconfig/network-scripts/ifcfg-enp0s8
Modify the file as shown below.
HWADDR="08:00:27:04:03:86"
TYPE="Ethernet"
BOOTPROTO="none"
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_PEERDNS="yes"
IPV6_PEERROUTES="yes"
IPV6_FAILURE_FATAL="no"
NAME="enp0s8"
UUID="a97b23f2-fa87-49de-ac9b-39661ba9c20f"
ONBOOT="yes"
MASTER=bond0
SLAVE=yes
vi /etc/sysconfig/network-scripts/ifcfg-enp0s9
Modify the file as shown below.
HWADDR=08:00:27:E7:ED:8E
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=enp0s9
UUID=e2352c46-e1f9-41d2-98f5-af24b127b3e7
ONBOOT=yes
MASTER=bond0
SLAVE=yes
Now, activate the Network interfaces.
ifup ifcfg-enp0s8
ifup ifcfg-enp0s9
(Ich habe jede Variable in Gänsefüßchen gesetzt)
nmcli con reload
Restart network service to take effect the changes.
systemctl restart network
dann hat auch der Befehl „cat /proc/net/bonding/bond0“ eine ähnliche Ausgabe wie auf der Seite gebracht. Und der Server war von VLAN1 erreichbar. Nach dem Neustart jedoch nicht mehr. Als ich dann über den NetworkManager angefangen einige zuviel erstellte Scripts zu löchen, habe ich die falsche entfernt. Dann musste ich leider Feierabend machen.
Nun bin ich zuhause und es gibt mir einfach nicht die Ruhe, was habe ich übersehen? Hat jemand das Malen nach Zahlen für mich zur dem Thema?
Tut mir leid, wenn mein Text schwer zu lesen ist, bin noch am üben. Ach ja, versteht mich bitte nicht falsch. Die Beträge welche ich hier gefunden habe waren fast alle mit nur halb angeschnittenen Antworten.
Viele Grüße
Ich
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 311312
Url: https://administrator.de/contentid/311312
Ausgedruckt am: 25.11.2024 um 13:11 Uhr
20 Kommentare
Neuester Kommentar
Hier werden sie geholfen:
Netzwerk Management Server mit Raspberry Pi
Die Syntax und ToDos sollten bei CentOS mehr oder minder identisch sein !
Anmerkungen zur VLAN Konfiguration findest du über dem Link Aggregation Kapitel.
Grundlagen dazu auch hier:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Dr. Google hat diverse Infos dazu:
http://www.45drives.com/wiki/index.php/Implementing_Network_Bonding_on_ ...
http://aarvik.dk/how-to-setup-lacp-network-bonding-interface-on-rhel-ce ...
usw.
Entscheidend ist das du den Mode auf 4 setzt mit mode=4 im Konfig File wenn du auf einen LAN Switch gehst der Link Aggregation supportet mit LACP.
Auch hier auf der Switchseite MUSS zwingend ein LAG mit LACP konfiguriert sein. LAGs sind immer eine 2seitige Angelegenheit.
Das o.a. Tutorial hat entsprechende Switch Beispielkonfigs.
Netzwerk Management Server mit Raspberry Pi
Die Syntax und ToDos sollten bei CentOS mehr oder minder identisch sein !
Anmerkungen zur VLAN Konfiguration findest du über dem Link Aggregation Kapitel.
Grundlagen dazu auch hier:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Dr. Google hat diverse Infos dazu:
http://www.45drives.com/wiki/index.php/Implementing_Network_Bonding_on_ ...
http://aarvik.dk/how-to-setup-lacp-network-bonding-interface-on-rhel-ce ...
usw.
Entscheidend ist das du den Mode auf 4 setzt mit mode=4 im Konfig File wenn du auf einen LAN Switch gehst der Link Aggregation supportet mit LACP.
Auch hier auf der Switchseite MUSS zwingend ein LAG mit LACP konfiguriert sein. LAGs sind immer eine 2seitige Angelegenheit.
Das o.a. Tutorial hat entsprechende Switch Beispielkonfigs.
General ist falsch, denn das ist dann kein Link Aggregation Port. Trunk wäre hier richtig, denn du hast ja ganz klar einen Trunk sprich eine LACP Link Aggregation auf diesen beiden Ports terminiert.
Wenn der Switch kein Cisco ist (denn da heissen LAGs immer "Port Channel") nennt der Rest der Netzwerk Welt LACP aggregierte Links immer TRUNKS.
Von daher ist das richtig.
Wichtig wäre nochmal:
Die Fehlermeldung Failed to start LSB: Bring up/down networking. kann was damit zu tun haben das du doppelte definitionen hast sprich das der Network Manager noch rennt und was überschreiben will in statischer Zuordnung.
VMs migrierst du nicht zufällig oder ?:
http://missingsmth.com/failed-to-start-lsb/
Da muss man dann auf die Macs achten.
Alles in allem muss man schon sagen das das recht kryptisch in CentOS ist. Bei Debian / Ubuntu ist das mit 3 Konfigzeilen erledigt.
Poste mal den Switch Status Output und ggf. das Log des Switches wenn der LACP LAG hochkommt.
Wenn der Switch kein Cisco ist (denn da heissen LAGs immer "Port Channel") nennt der Rest der Netzwerk Welt LACP aggregierte Links immer TRUNKS.
Von daher ist das richtig.
Wichtig wäre nochmal:
- was zeigt ein simples ifconfig an ?
- und ganz wichtig: WAS sagt der Port bzw. Interface Status des Switches zu diesem Trunk ?? Ist der UP ?
- ein show LACP status usw. wäre auch hilfreich wenn der Switch sowas supportet (Hersteller ?)
Die Fehlermeldung Failed to start LSB: Bring up/down networking. kann was damit zu tun haben das du doppelte definitionen hast sprich das der Network Manager noch rennt und was überschreiben will in statischer Zuordnung.
VMs migrierst du nicht zufällig oder ?:
http://missingsmth.com/failed-to-start-lsb/
Da muss man dann auf die Macs achten.
Alles in allem muss man schon sagen das das recht kryptisch in CentOS ist. Bei Debian / Ubuntu ist das mit 3 Konfigzeilen erledigt.
Poste mal den Switch Status Output und ggf. das Log des Switches wenn der LACP LAG hochkommt.
Perfekt ! CentOS sieht gut aus und der Switch auch. Beide Ports auf UP und die Group (LAG1) aktiv sagen klar das LACP und das Bonding bzw. die Link Aggregation sauber funktioniert. !
Egress Rule "UNTAG" an den Switchports ist aber total falsch !
Damit bekommen ausgehende Pakete keinen VLAN Tag ! Damit kann dann der CentOS Host niemals erkennen für welches VLAN die bei ihm eingehenden (vom Switch ausgehenden) Pakete bestimmt sind.
Du machst ja ein Tagging auf dem CentOS.
Setzt du die Ports auf untagged wird einzig nur das Native VLAN, spricht das VLAN 1 übertragen.
21 und 22 müssten aber logischerweise ein Tagged Trunk sein. Trunk = Link Aggregation Tagged = VLAN Tagging.
Alles andere wäre nach Netzwerk Verständnis falsch !
Es sieht aber so aus als ob TP-Link etwas Cisco Sprech nutzt !! Siehe hier:
http://www.tp-link.com/en/faq-328.html
Dort steht ganz klar das TRUNK als "Tagged Uplink" zu verstehen ist. Also ein Port der ein Mitglied mehrerer VLANs ist und das kann er logischerweise dann nur im TAGGED Trunk Mode denn du willst ja VLAN Tags zum CentOS übertragen, richtig ?
Untagged kann ein Port niemals Mitglied mehrerer VLANs sein. Logisch, denn wie soll der Switch dann die Pakete unterscheiden aus welchem VLAN sie kommen. Das kann er immer nur wenn das Paket ein 802.1q VLAN Tag hat !
Die weitere Vorgehnsweise am Switch defiieren die Screenshots eindeutig:
Egress Rule "UNTAG" an den Switchports ist aber total falsch !
Damit bekommen ausgehende Pakete keinen VLAN Tag ! Damit kann dann der CentOS Host niemals erkennen für welches VLAN die bei ihm eingehenden (vom Switch ausgehenden) Pakete bestimmt sind.
Du machst ja ein Tagging auf dem CentOS.
Setzt du die Ports auf untagged wird einzig nur das Native VLAN, spricht das VLAN 1 übertragen.
21 und 22 müssten aber logischerweise ein Tagged Trunk sein. Trunk = Link Aggregation Tagged = VLAN Tagging.
Alles andere wäre nach Netzwerk Verständnis falsch !
Es sieht aber so aus als ob TP-Link etwas Cisco Sprech nutzt !! Siehe hier:
http://www.tp-link.com/en/faq-328.html
Dort steht ganz klar das TRUNK als "Tagged Uplink" zu verstehen ist. Also ein Port der ein Mitglied mehrerer VLANs ist und das kann er logischerweise dann nur im TAGGED Trunk Mode denn du willst ja VLAN Tags zum CentOS übertragen, richtig ?
Untagged kann ein Port niemals Mitglied mehrerer VLANs sein. Logisch, denn wie soll der Switch dann die Pakete unterscheiden aus welchem VLAN sie kommen. Das kann er immer nur wenn das Paket ein 802.1q VLAN Tag hat !
Die weitere Vorgehnsweise am Switch defiieren die Screenshots eindeutig:
- Port Nummer selektieren und auf TRUNK setzen
- VLAN Create oder selektieren, VLAN ID angeben und dort den vorher selktierten Trunk Port bei der Egress Rule auf TAGGED setzen. Apply klicken !
- Das für alle VLAN IDs wiederholen die Tagged an diesem Port rausgehen sollen !
Also Ist die Einstellung GENERAL doch richtig? Bei Trunk kann man auf UNTAG nicht setzen.
Nein, sie ist falsch !Es muss ja Trunk sein. Die TP-Link Knowledge Base Screenshots sagen das doch eindeutig.
Für einen Tagged Uplink wird der Mode auf Trunk gesetzt und die Egress Rule auf Tagged.
Wär ja komisch wenn TP-Link dort selber was beschreibt was dann auf ihren Produkten nicht geht. Wär ja hochgradig unlogisch, oder ?
Mittlerweile glaube ich, dass ich das VLAN am Server nicht konfiguriert habe.
Das kann sein....und wäre auch einen Erklärung für das Tohuwabohu.Du musst am Bond Interface Subinterfaces haben für jedes VLAN z.B. hier für VLAN 2:
bond0.2 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Ansonsten kann man das nachladen mit modprobe 8021q.
Das geht dann bei CentOS mit diesen Scripts (z.B. vlan 2 und 3):
/etc/sysconfig/network-scripts/ifcfg-bond0.2:
VLAN=yes
DEVICE=bond0.2
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.2.1
NETMASK=255.255.255.0
/etc/sysconfig/network-scripts/ifcfg-bond0.3:
VLAN=yes
DEVICE=bond0.3
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.3.1
NETMASK=255.255.255.0
Ein Debian Beispiel hier:
http://www.microhowto.info/howto/configure_an_ethernet_interface_as_a_v ...
Netzwerk Management Server mit Raspberry Pi
Bei mir haben ja alle VLANS die gleiche IP Adresse.
Uuuuhhh, nicht dein Ernst, oder ??Das ist natürlich ein fataler Fehler und zeigt erhebliche Defizite im Netzwerk Wissen !! Sorry, aber bitte erstmal die Grundlagen zu VLANs lesen bevor wir hier weitermachen:
http://www.schulnetz.info/vlan-einstieg-was-ist-ein-vlan/ (alle Teile)
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Bei mir zuhause mit der Digitalisierungsbox habe ich auch alle VLAN in einem IP Bereich gelegt und es funktioniert.
Uuuhhhrgh...Na ja...wenn man die L2 Collision Doamins komplett getrennt lässt in den VLANs und sie NIEMALS irgendwo koppelt, dann geht das.
Das ist aber russisch Roulette und konterkariert den tieferen Sinn von VLANs natürlich.
Zeigt eher das du das Konzept VLANs nicht wirklich verstanden hast, sorry.
Theoretisch hast du Recht und mit den o.a. harten Einschränkungen geht das. Aber so ein Design hat nichts mit der Praxis zu tun, denn koppelt du die mal aus Versehen bist du nicht mehr standardkonform...
Der Server google nicht anpingen.
Wie lautet die Default Route auf dem Server ?? netstat -r -nWas du machst mit 2 Default Routen ist routingtechnischer Blödsinn !
Wie bitte soll der Server denn nun wissen welche der Default Routen er nehmen soll ?? OSe können mit sowas nicht umgehen. Es gilt immer nur eine Route... vermutlich hat die dann keinen Internet Zugriff und daher der Fehler...?!
Was sagt also netstat oder ip route show ??
Ich habe es nun wie folgt gebildet:
image 4c39968a9265159ac32e22892cee2fe1
Da fehlte jetzt das Bild dazu ?! Hast du das ggf. gelöscht und vergessen den Tag im Text ebenfalls zu löschen ??image 4c39968a9265159ac32e22892cee2fe1
Warum auch immer kann man es nicht sehen, daher jetzt nun ein Link dazu:
Nicht auf "+" geklickt beim Bild ??Warum auch immer kann man es nicht sehen, daher jetzt nun ein Link dazu:
OK, umständlich aber damit kommt das Bild dann zum Vorschein...Kein sehr gutes Netzwerk Design Solche Switchketten sollte man generell vermeiden im Ethernet. Sternförmig ist die Devise. Aber mit 3 Hops bist du grad noch so am Limit.
Ein Bekannter hat mir gesagt, dass das was ich eigentlich vor habe, gar nicht funktionieren kann.
So so und warum ? Hat er das mal begründet ??OK, ganz Unrecht hat er nicht, denn dein Design ist nicht gerade gut aber auch nicht falsch das es nicht klappen würde.
Die Kardinalsfrage die man stellen muss und die leider nicht in der Grafik klar dokumentiert ist, ist die der IP Adressierung ??
Sind die .126.0 /24, .127.0 /24 und .128.0 /24 er Netze jetzt eingene VLANs z.B. VLAN 1 bis 3 ?
Vermutlich ja aber dann gleich die 2te Frage: WO sind die Tagged Uplinks die diese VLANs im zw. den Switches übertragen ?
Normal müssten das die Uplinks zwischen den Switches sein. Ist dem so ?
Dritte Frage: WO werden diese VLANs geroutet ? L3 Switch ? Gateway ? CentOS Server ?
OK die 3te Frage ist natürlich nur relevant wenn du auch einen Kommunikation zw. den VLANs anstrebst.
Und schickte mir folgenden Aufbau.
Ja, kann man so machen muss man aber nicht. Du kannst ja auch mit dem CentOS Server routen statt der pfSense Firewall. Es gibt eben viele Wege nach Rom...Leider musste ich dann die Kinder ins Bett bringen...
Kein Thema... Familie geht vor !! Kannst du es mir vielleicht sagen, eventuell verstehe ich dann die Logik.
Versuchen wir es mal....Erste Anlaufstelle ist immer das Handbuch und siehe da...dort steht eine 1A Erklärung auf Seite 67 und 68 inkl. Diagram: !!
http://www.tp-link.com/res/down/doc/TL-SG3216(UN)_V2_UG.pdf
Dort ist genau der Unterschied zw. TRUNK und GENERAL erklärt !
Die Funktion unterscheidet sich lediglich in dem Punkt das General dich mit einer Egress Rule (Regel für ausgehende Pakete) bestimmen lässt ob die ausgehenden Packete Tagged oder Untagged sind.
Diese Funktion ist banal gesagt eigentlich Schwachsinn, denn sie macht eigentlich genau dasselbe wie der Trunk.
Einzige Ausnahme ist das ein "TRUNK" Port immer den VLAN Tag mit aussendet ausgehend.
Eine "GENERAL" Port sendet ihn aus wenn die EGRESS RULE Tagged ist aber wenn die EG RULE Untagged ist dann wird das Paket ohne VLAN ID untagged ausgesendet.
Hier stellt sich jetzt die Gretchenfrage wie sich dieser Port verhält wenn die EG RULE Untagged ist. Was passiert wenn es irgendwo ein General Port gibt der die VLANs 1-5 annimmt, intern auch in diese VLANs forwardet aber einen GENERAL Port hat der dann die EG RULE Untagged hat.
Forwardet der jetzt an dem Port ALLE Pakets ohne VLAN Tag aus allen VLANs ??
Technisch gesehen wäre das ein SuperGAU denn das würde ein Netzwerk logischerweise zum kollabieren bringen wenn so eigentlich getrennte Layer 2 Collision Domains zusammengeführt werden. Eine Katastrofe würde das so sein...
Annahme ist aber das es vermutlich nur Pakete sind die Untagged geforwardet werden dessen PVID am Port konfiguriert ist und das NUR diese dann dort untagged rauskommen. Seite 72 erklärt es wenigstens so.
Sichere Gewissheit wird dir aber nur ein Wireshark Trace bringen an dem Port indem man dort mal mit den EG Rules etwas spielt.
Solltest du mal machen um sicherzugehen.
Etwas schwachsinnige Konfig Logik aber das ist wohl so bei billigen China Böllern...
Als Fazit kann man sagen das man dann sowohl GENERAL als auch TRUNK verwenden kann. Bei den Switchlinks untereinander und auf den Servern macht dann TRUNK eigentlich am meisten Sinn, denn man will ja explizit immer Tagged Frames ausgehend haben um die VLAN ID ans angeschlossenen Endgerät zu senden damit das VLAN zu erkennen ist und zuordbar ist.
GENERAL geht aber auch, nur das man dort eben dann höllisch aufpassen muss wie man die die Egress Role UND im Falle von Untaged, die PVID setzt !
Wenn man das beachtet ist das OK.
Genau so ein Blödsinn wie bei NetGear. Die machen auch aus einer simplen Sache eine megakomplizierte Konfig Logik.
Grund von NetGear und TP-Link bei VLANs die Finger zu lassen.
Laut TP-Link ist es auch richtig. :/
Sieht auch soweit richtig aus !Auf den Trunk Uplinks der Switches untereinader hast du hoffentlich alle VLANs tagged konfiguriert ?? (Außer VLAN 1, das ist immer untagged)
Der Server kommt ins internet, die Clients erreichen den Server, der Server erreicht die Clients.
Sehr gut !!Bedeutet das die Infrastruktur mit den VLANs sauber rennt !
Nun habe ich das Problem, dass die Clients im VLAN2 nicht ins Internet kommen. Jetzt fehlt der route zum Gateway „172.19.126.1“
OK, ich rate mal das du über den CentOS Server, routest, richtig ?? Ja, muss ja, denn die Switches sind allesamt Layer 2 only Switches und können nicht routen...OK...hier die ToDos um das zum Fliegen zu bringen:
- Auf dem CentOS Server muss IPv4 Forwarding aktiviert sein (Routing). Be Debian basierten Maschinen geht das über das Entkommentieren der Zeile #net.ipv4.ip_forward=1 in der Datei /etc/sysctl.conf.
- Im VLAN 1 bekommen alle Endgeräte die IP Adresse des CentOS Servers als Default Gateway
- Im VLAN 2 bekommen alle Endgeräte die IP Adresse des CentOS Servers als Default Gateway
- Dein Internet Router ist sicher im VLAN 1, richtig ?? Der muss jetzt zwingend eine statische Route konfiguriert bekommen: Zielnetz: 172.19.127.0, Maske: 255.255.255.0, Gateway: 172.19.126.3 (Letzte IP ist die IP Adresse des CentOS Servers im VLAN 1 !!
- Der CentOS Server bekommt eine Default Route auf den Internet Router .126.1
- Fertisch.
Die Grundlagen und Funktionsweise zu genau diesem Setup zeigt dir dieses Routing Tutorial:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
und speziell im VLAN Umfeld hier:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Damit sollte das sofort zum Fliegen kommen !!
Nein die Switches sind alle mit TRUNK miteinander verbunden, dann kann man VLAN getrennt nicht konfigurieren.
Sorry, aber das ist technischer Unsinn !Du musst und willst doch auch die VLANs transparent über die gesamten 3 Switches bringen !!!
Folglich müssen die einzelnen Trunk Links ja tagged konfigriert sein (General oben) um so die VLAN Information zwischen den Switches zu übertragen.
Alles andere wäre schlicht falsch.
Das du mehrere Tagged Uplinks dann als Trunks (Link Aggregation) bündelst ist davon ja erstmal nicht abhängig.
Wichtig ist das sie getagged sind, so das die VLANs an alles 3 Switches verfügbar sind.
Ich weiß, du wirst mich jetzt hassen, ich habe jedoch die IP Adressen etwas den VLAN angepasst also der Server ist nicht mehr unter 172.19.126.3 sondern unter 172.19.255.104 erreichbar.
Nööö, tu ich nicht. Es ist ja nur kosmetisch welche IP du in welchem Segment verwendest. In so fern...Latte !Allerdings mit .255 in den Adressen solltest du immer sehr vorsichtig sein !!! Manche Billigheimer können damit nicht richtig umgehen (Broadcast).
Was aber unverständlich ist ist die Frage in WELCHEM VLAN du jetzt das .255.0er Netz verwendest ???
Oben hast du ja sehr richtig und vorbildlich immer die VLAN ID im dritten Byte der Netzwerkadresse kodiert.
Fragt sich jetzt in welchem VLAN denn nun .255.0 /24 ist ?? Im VLAN 4 oder wo ???
Verstehe ich es jetzt richtig? Da der Server mit der IP Adresse 172.19.2.1 zu erreichen ist bekommen die Clients aus dem VLAN2 unter Gateway 172.19.2.1 eingetragen?
Ja, richtig verstanden !!Stell dir deinen Server als Router vor der in jedem VLAN ein Bein hat....
Logisch das die Endgeräte in den jeweiligen VLANs, dann sein "Bein" bzw. die IP Adresse darauf als Default Gateway eingetragen haben müssen, denn der Server fungiert ja als Router zw. den VLANs !
Sprich alle im Netz 192.168.2.x /24 haben dann die 192.168.2.1 (Server IP) als Gateway Adresse.
Alle im Netz 192.168.1.x /24 haben dann die 192.168.1.1 und last but not least...
Alle im Netz 192.168.3.x /24 dann die 192.168.3.1
Der Server selber dann die Default Route auf den Internet Router...
Der Internet Router dann die statischen Routen auf die VLAN Netze..
Fertisch !
So einfach ist das...
Wir haben keinen Router, wir haben kein Zugriff darauf. DNS ist 10.1.2.1
Oha...dann hast du keine Chance das umzusetzen ! Dann kannst du rein nur zw. den VLANs routen und mehr nicht.Wenn du keine Route auf dem Internet Router konfigurieren kannst, dann ist dein einziger Ausweg nur Masquerading auf deinem Server zu verwenden !
Siehe o.a. 2er NIC Tutorial ICS / NAT Thema !!! Bitte nochmal genau lesen !
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Läuft nicht
Ja das ist dann klar. !Wenigstens aber das lokale Routing zwischen den VLANs, das sollte dann aber fehlerfrei funktionieren !!!
Wenn du dann nochmal das Mysterium mit dem .255.0er /24 Subnetz aufklären könntest ???
Muss auf dem Server nicht die Umleitung der einzelnen IP-Bäumen noch eingerichtet werden so ähnlich wie das hier?
Nein, das wäre Schwachsinn !Sorry, aber der Server "kennt"" ja seine IP Netze ganz genau, da diese ja direkt an ihm angeschlossen sind. Routen in diese Netze sind damit vollkommen überflüssig.
Kommen Pakete an für diese Netze kann der Server sie direkt forwarden, da wie gesagt direkt an ihm angeschlossen.
Er bräuchte also lediglich eine Default Route im Pakete forwarden zu können die Zieladressen haben die NICHT in diesen 3 Netzen liegen die er selber kennt.
Siehe auch Tutorial. dort ist ein Packet Walk genau beschrieben...bitte lesen !
Solche unsinnigen Routen also immer entfernen, denn die machen alles schlimmer da grundfalsch.
Ja, das war die leidige Diskussion und der TP-Link Nomenklatur Unsinn mit General und Trunk oben.
Wie auch immer...es muss tagged sein. General dann eben.
Die IP direkt auf dem Interface ist der untagged Traffic und der wird immer ins Default VLAN, sprich also VLAN 1 geforwardet !!!
In so fern hättest du dann einen IP Adress Mismatch in deinem VLAN 1 !!!
Laut deiner Liste ist da das .1.0 /24 Netzwerk und eben nicht das .255.0 /24.
Die bond x IP Adressen müssen also .1.x /24 lauten. Kannst du auch ganz einfach mal testen wenn du einen Laptop mit statischer IP im VLAN 1 hast , der muss pingbar sein vom CentOS Server und auch andersrum !!
Übrigens kann man so auch die IP Erreichbarkeit aller VLAN Segmente testen !!
Korrigier das bitte !
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Schlau wäre es auch einen DHCP Server auf dem CentOS Server für jedes VLAN zu konfigurieren:
Netzwerk Management Server mit Raspberry Pi
Dann würdest du am Client immer sofort anhand der IP sehen in welchem VLAN dieser arbeitet und ob alles korrekt konfiguriert ist mit den Tagged Ulinks und Trunks (LAGs) !!
Wie auch immer...es muss tagged sein. General dann eben.
Ähm das ist bond0 das ist in keinem VLAN.
Das ist Unsinn...sorry.Die IP direkt auf dem Interface ist der untagged Traffic und der wird immer ins Default VLAN, sprich also VLAN 1 geforwardet !!!
In so fern hättest du dann einen IP Adress Mismatch in deinem VLAN 1 !!!
Laut deiner Liste ist da das .1.0 /24 Netzwerk und eben nicht das .255.0 /24.
Die bond x IP Adressen müssen also .1.x /24 lauten. Kannst du auch ganz einfach mal testen wenn du einen Laptop mit statischer IP im VLAN 1 hast , der muss pingbar sein vom CentOS Server und auch andersrum !!
Übrigens kann man so auch die IP Erreichbarkeit aller VLAN Segmente testen !!
Korrigier das bitte !
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Schlau wäre es auch einen DHCP Server auf dem CentOS Server für jedes VLAN zu konfigurieren:
Netzwerk Management Server mit Raspberry Pi
Dann würdest du am Client immer sofort anhand der IP sehen in welchem VLAN dieser arbeitet und ob alles korrekt konfiguriert ist mit den Tagged Ulinks und Trunks (LAGs) !!