oiooiooioiioooiioiioiooo
Jul 30, 2016, updated at Aug 02, 2016 (UTC)
view5632
view20
0
Goto Top

LAG Bonding mit VLAN Routing Centos7

GermanQuestionRedHat, CentOS, FedoraLinux
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.
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
Then, Edit file /etc/sysconfig/network-scripts/ifcfg-enp0s9,
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
Save and close the files.
Now, activate the Network interfaces.
ifup ifcfg-enp0s8
ifup ifcfg-enp0s9
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.
systemctl restart network
(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. face-sad

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
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 311312

Url: https://administrator.de/contentid/311312

Printed on: April 26, 2024 at 10:04 o'clock

20 Comments
Latest comment
Goto Top
Member: aqui
aqui Jul 30, 2016 updated at 09:50:07 (UTC)
Goto Top
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.
Member: OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO Aug 01, 2016 at 13:51:59 (UTC)
Goto Top
Ja, ich mach nichts anderes als zu googlen, und alle Seiten welche du gelinkt hast, selbstverständlich danke ich dir dafür, habe ich auch bereits mir durchgelesen. Nur scheinbar nicht ganz verstanden oder etwas übersehen.

Nun mein heutiger Tag: Bonding scheinbar eingerichtet zu sein. Doch spuckt mir das System ein paar Fehler aus:

[root@server ~]# systemctl status network.service
● network.service - LSB: Bring up/down networking
   Loaded: loaded (/etc/rc.d/init.d/network)
   Active: failed (Result: exit-code) since Mo 2016-08-01 16:38:52 CEST; 4min 22s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 4890 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE)

Aug 01 16:38:52 server.server.net network[4890]: RTNETLINK answers: File exists
Aug 01 16:38:52 server.server.net network[4890]: RTNETLINK answers: File exists
Aug 01 16:38:52 server.server.net network[4890]: RTNETLINK answers: File exists
Aug 01 16:38:52 server.server.net network[4890]: RTNETLINK answers: File exists
Aug 01 16:38:52 server.server.net network[4890]: RTNETLINK answers: File exists
Aug 01 16:38:52 server.server.net network[4890]: RTNETLINK answers: File exists
Aug 01 16:38:52 server.server.net systemd[1]: network.service: control process exited, code=exited status=1
Aug 01 16:38:52 server.server.net systemd[1]: Failed to start LSB: Bring up/down networking.
Aug 01 16:38:52 server.server.net systemd[1]: Unit network.service entered failed state.
Aug 01 16:38:52 server.server.net systemd[1]: network.service failed.

[root@server ~]# journalctl -xe
Aug 01 16:58:18 server.server.net network[7214]: [FEHLGESCHLAGEN]
Aug 01 16:58:18 server.server.net network[7214]: Schnittstelle bond0 hochfahren:  FEHLER   : [/etc/sysconfig/network-scripts/ifup-eth] Gerät  hat andere MAC-Adresse als erwartet,
Aug 01 16:58:18 server.server.net /etc/sysconfig/network-scripts/ifup-eth[7569]: Gerät  hat andere MAC-Adresse als erwartet, ignorieren.
Aug 01 16:58:18 server.server.net network[7214]: WARN     : [/etc/sysconfig/network-scripts/ifup-eth] Unable to start slave device ifcfg-enp7s0 for master bond0.
Aug 01 16:58:18 server.server.net /etc/sysconfig/network-scripts/ifup-eth[7570]: Unable to start slave device ifcfg-enp7s0 for master bond0.
Aug 01 16:58:18 server.server.net network[7214]: RTNETLINK answers: File exists
Aug 01 16:58:18 server.server.net network[7214]: [  OK  ]
Aug 01 16:58:18 server.server.net network[7214]: RTNETLINK answers: File exists
Aug 01 16:58:18 server.server.net network[7214]: RTNETLINK answers: File exists
Aug 01 16:58:18 server.server.net network[7214]: RTNETLINK answers: File exists
Aug 01 16:58:18 server.server.net network[7214]: RTNETLINK answers: File exists
Aug 01 16:58:18 server.server.net network[7214]: RTNETLINK answers: File exists
Aug 01 16:58:18 server.server.net network[7214]: RTNETLINK answers: File exists
Aug 01 16:58:18 server.server.net network[7214]: RTNETLINK answers: File exists
Aug 01 16:58:18 server.server.net network[7214]: RTNETLINK answers: File exists
Aug 01 16:58:18 server.server.net network[7214]: RTNETLINK answers: File exists
Aug 01 16:58:18 server.server.net systemd[1]: network.service: control process exited, code=exited status=1
Aug 01 16:58:18 server.server.net systemd[1]: Failed to start LSB: Bring up/down networking.
-- Subject: Unit network.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit network.service has failed.
--
-- The result is failed.
Aug 01 16:58:18 server.server.net systemd[1]: Unit network.service entered failed state.
Aug 01 16:58:18 server.server.net systemd[1]: network.service failed.
Aug 01 16:58:18 server.server.net polkitd[2429]: Unregistered Authentication Agent for unix-process:7209:762131 (system bus name :1.322, object path /org/freedesktop/PolicyKit1/Au
Aug 01 17:01:01 server.server.net systemd[1]: Started Session 6 of user root.
-- Subject: Unit session-6.scope has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit session-6.scope has finished starting up.
--
-- The start-up result is done.
Aug 01 17:01:01 server.server.net systemd[1]: Starting Session 6 of user root.
-- Subject: Unit session-6.scope has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit session-6.scope has begun starting up.
Aug 01 17:01:01 server.server.net CROND[7676]: (root) CMD (run-parts /etc/cron.hourly)
Aug 01 17:01:01 server.server.net run-parts(/etc/cron.hourly)[7679]: starting 0anacron
Aug 01 17:01:01 server.server.net run-parts(/etc/cron.hourly)[7685]: finished 0anacron
Aug 01 17:01:01 server.server.net run-parts(/etc/cron.hourly)[7687]: starting 0yum-hourly.cron
Aug 01 17:01:01 server.server.net run-parts(/etc/cron.hourly)[7691]: finished 0yum-hourly.cron

Unter ifcfg-VLAN-1 steht

VLAN="yes"  
TYPE="Vlan"  
PHYSDEV="bond0"  
VLAN_ID="1"  
REORDER_HDR="0"  
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="VLAN-1"  
UUID="6beab5d0-5d6e-4698-b9f3-e3fa1b98650b"  
ONBOOT="yes"

so ähnlich auch in ifcfg-VLAN-5

VLAN=yes
TYPE=Vlan
PHYSDEV=bond0
VLAN_ID=5
REORDER_HDR=0
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=VLAN-5
UUID=f3da11c6-72f5-4dd2-a046-d25c219b9ba1
ONBOOT=yes

incfg-bond0
DEVICE=bond0
NAME=bond0
TYPE=Bond
BONDING_MASTER=yes
IPADDR=172.19.126.3
PREFIX=24
GATEWAY="172.19.126.1"  
DNS1="10.1.1.1"  
ONBOOT=yes
BOOTPROTO=none
BONDING_OPTS="mode=4 miimon=100"

ifcfg-enp5s0

HWADDR="10:8d:5a:1b:20:16"  
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="enp5s0"  
UUID="26fa4429-cec1-40fd-9c1a-81b4aafff847"  
ONBOOT="yes"  
MASTER="bond0"  
SLAVE="yes"

ifcfg-enp7s0

HWADDR="60:05:c1:3e:6b:15"  
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="enp7s0"  
UUID="81de165b-1bc3-4159-a337-26f4a42b3bd0"  
ONBOOT="yes"  
MASTER="bond0"  
SLAVE="yes"

Was ich auch sehr komisch finde ist, dass wenn ich im Switch bei den beiden Ports an welche der Server angeschlossen ist „GENERAL“ einstelle, so kann es von verschiedenen VLAN´s angesprochen werden, von anderem Switch aus auch. Wenn ich jedoch auf „TRUNK“ setze, so kann man es nur von dem Switch aus erreichen an dem der Server angeschlossen ist sonnst nicht.

LAG habe ich wie folgt eingerichtet:
Member: aqui
aqui Aug 01, 2016 updated at 15:40:45 (UTC)
Goto Top
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:
  • 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.
Member: OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO Aug 02, 2016 updated at 08:10:55 (UTC)
Goto Top
Guten Morgen,

ja Debian ist in fast allem deutlich einfacher. Leider nur nicht so stabil wie Centos finde ich.

Fehler „Failed to start LSB: Bring up/down networking.“ behoben. Denn Sind VLAN keine Physische Geräte und dürfen nicht „ifcfg-VLAN“ heißen sondern „route-VLAN“

Nun haben wir:

[root@server ~]# systemctl status network.service
● network.service - LSB: Bring up/down networking
   Loaded: loaded (/etc/rc.d/init.d/network)
   Active: active (exited) since Di 2016-08-02 08:43:52 CEST; 17min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 669 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=0/SUCCESS)

Aug 02 08:43:49 server.server.net systemd[1]: Starting LSB: Bring up/down networking...
Aug 02 08:43:49 server.server.net network[669]: Loopback-Schnittstelle hochfahren:  [  OK  ]
Aug 02 08:43:52 server.server.net network[669]: Schnittstelle bond0 hochfahren:  [  OK  ]
Aug 02 08:43:52 server.server.net systemd[1]: Started LSB: Bring up/down networking.

[root@server ~]# ifconfig
bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST>  mtu 1500
        inet 172.19.126.3  netmask 255.255.255.0  broadcast 172.19.126.255
        inet6 fe80::428d:5cff:fe1a:2016  prefixlen 64  scopeid 0x20<link>
        ether 30:8d:5a:bd:30:15  txqueuelen 0  (Ethernet)
        RX packets 2228  bytes 180438 (176.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 962  bytes 83958 (81.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp5s0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
        ether 30:8d:5a:bd:30:15  txqueuelen 1000  (Ethernet)
        RX packets 1059  bytes 73796 (72.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 879  bytes 74802 (73.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp7s0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
        ether 30:8d:5a:bd:30:15  txqueuelen 1000  (Ethernet)
        RX packets 1171  bytes 106770 (104.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 85  bytes 9712 (9.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 19  memory 0xdf0c0000-df0e0000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Lokale Schleife)
        RX packets 1  bytes 82 (82.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 82 (82.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@main ~]# ifstat
ifstat: history is aged out, resetting
#kernel
Interface        RX Pkts/Rate    TX Pkts/Rate    RX Data/Rate    TX Data/Rate
                 RX Errs/Drop    TX Errs/Drop    RX Over/Rate    TX Coll/Rate
lo                     1 0             1 0            82 0            82 0
                       0 0             0 0             0 0             0 0
enp5s0              1186 0          1157 0         83198 0         98748 0
                       0 0             0 0             0 0             0 0
enp7s0              1517 0            95 0        136522 0         10878 0
                       0 0             0 0             0 0             0 0
bond0               2704 0          1253 0        219784 0        109776 0
                       0 0             0 0             0 0             0 0

Switch LOG nach dem Starten des Servers:

1 2016-08-02 07:44:01 LAG level_6 Added new Link Aggregation Group 1, members: Port 21-22.
2 2016-08-02 07:43:59 Link level_3 port 21, changed state to up.
3 2016-08-02 07:43:58 Link level_3 port 22, changed state to up.

Aber das mit dem TRUNK renne ich gegen die Wand. Es wird grundsätzlich nur dann der Server im Netzwerk angesprochen, wenn die Ports auf „GENERAL“ stehen. Ich habe ja oben meine Konstellation der Hardware aufgelistet. Die Switches sind von TP-Link TL-SG3216, 2x TL-SG3424 und TL-SG3210 das Interface schaut so aus:

1unbenannt
2unbenannt
3unbenannt
4unbenannt
5unbenannt
6unbenannt
Member: aqui
aqui Aug 02, 2016 updated at 12:11:36 (UTC)
Goto Top
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:
  • 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 !
Das du die Egress Rule nicht auf Tagged gesetzt hast im Trunk Mode ist vermutlich dein Kardinlasfehler ?!
Member: OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO Aug 02, 2016 at 14:30:59 (UTC)
Goto Top
hi und sorry. Die letzten zwei Screenshots habe ich für TP-LINK Support hochgeladen, da habe ich bereits den Server auf Port 19 und 20 verschoben,

Also Ist die Einstellung GENERAL doch richtig? Bei Trunk kann man auf UNTAG nicht setzen. Mittlerweile glaube ich, dass ich das VLAN am Server nicht konfiguriert habe. Kann man das irgend wie am Server direkt testen oder sehen?
Member: aqui
aqui Aug 02, 2016 updated at 15:49:34 (UTC)
Goto Top
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)
Mit lsmod | grep 8021q solltest du checken ob der Kernel vlan Support hat.
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
Member: OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO Aug 03, 2016 at 14:15:58 (UTC)
Goto Top
Vielen Dank. Bei mir haben ja alle VLANS die gleiche IP Adresse. Ich hoffe, dass das nicht den Konflikt veruhrsacht. VLAN sind am Server eingerichtet. Muss man da nicht noch einen ROUTE einbinden?

In jedem Fall habe ich nun herrausgefunden, dass der Server nicht mehr ansprechbar ist sobald ich die Ports auf TAG settze. Auch kann es dann nicht mehr an das internet und keinen Clienten mehr erreichen.

Habe diesen Link hier gefunden.

https://www.centos.org/forums/viewtopic.php?t=7782

Hier wird es beschriben, mach möchte die Datein in meinem Fall wie folgt erstellen.

/etc/sysconfig/network-scripts/route-vlan1
ip route add default via 172.19.126.3 dev vlan1 table 1

/etc/sysconfig/network-scripts/route-vlan2
ip route add default via 172.19.126.3 dev vlan2 table 2

/etc/sysconfig/network-scripts/route-vlan3
ip route add default via 172.19.126.3 dev vlan3 table 3

/etc/sysconfig/network-scripts/route-vlan4
ip route add default via 172.19.126.3 dev vlan4 table 4

/etc/sysconfig/network-scripts/route-vlan5
ip route add default via 172.19.126.3 dev vlan5 table 5

Leider keine Besserung.

Also ich glaube auch nciht mehr, dass es an der Konfiguration der Switches liegt. Denn hier wird es deutlich.

UNTAG:

[root@server network-scripts]# ifstat
#kernel
Interface        RX Pkts/Rate    TX Pkts/Rate    RX Data/Rate    TX Data/Rate
                 RX Errs/Drop    TX Errs/Drop    RX Over/Rate    TX Coll/Rate
lo                     0 0             0 0             0 0             0 0
                       0 0             0 0             0 0             0 0
enp5s0               143 0           309 0          9882 0         37087 0
                       0 0             0 0             0 0             0 0
enp7s0               475 0           102 0         50199 0         10294 0
                       0 0             0 0             0 0             0 0
bond0                618 0           411 0         60081 0         47381 0
                       0 0             0 0             0 0             0 0
bond0.1                0 0             0 0             0 0             0 0
                       0 0             0 0             0 0             0 0
bond0.2                0 0             0 0             0 0             0 0
                       0 0             0 0             0 0             0 0
bond0.3                0 0             0 0             0 0             0 0
                       0 0             0 0             0 0             0 0
bond0.4                0 0             0 0             0 0             0 0
                       0 0             0 0             0 0             0 0
bond0.5                0 0             0 0             0 0             0 0
                       0 0             0 0             0 0             0 0

TAG:

[root@server ~]# ifstat
#kernel
Interface        RX Pkts/Rate    TX Pkts/Rate    RX Data/Rate    TX Data/Rate
                 RX Errs/Drop    TX Errs/Drop    RX Over/Rate    TX Coll/Rate
lo                     0 0             0 0             0 0             0 0
                       0 0             0 0             0 0             0 0
enp5s0                85 0            54 0          7039 0          8042 0
                       0 0             0 0             0 0             0 0
enp7s0                95 0            20 0         11120 0          1952 0
                       0 0             0 0             0 0             0 0
bond0                180 0            74 0         18159 0          9994 0
                       0 0             0 0             0 0             0 0
bond0.1               37 0             0 0          2225 0             0 0
                       0 0             0 0             0 0             0 0
bond0.2               15 0             0 0           690 0             0 0
                       0 0             0 0             0 0             0 0
bond0.3                0 0             0 0             0 0             0 0
                       0 0             0 0             0 0             0 0
bond0.4                0 0             0 0             0 0             0 0
                       0 0             0 0             0 0             0 0
bond0.5                0 0             0 0             0 0             0 0
                       0 0             0 0             0 0             0 0

Grundsätzlich gehen scheinbar die vlan1 und vlan2 pakete am Server an, nur kann er diese nicht ververten.

Links sind jedoch alle gesetzt:

[root@server ~]# ip -d link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 addrgenmode eui64
2: enp5s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP mode DEFAULT qlen 1000
    link/ether 30:8d:5a:bd:30:15 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64
3: enp7s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP mode DEFAULT qlen 1000
    link/ether 30:8d:5a:bd:30:15 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
    link/ether 30:8d:5a:bd:30:15 brd ff:ff:ff:ff:ff:ff promiscuity 0
    bond addrgenmode eui64
5: bond0.1@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
    link/ether 30:8d:5a:bd:30:15 brd ff:ff:ff:ff:ff:ff promiscuity 0
    vlan protocol 802.1Q id 1 <REORDER_HDR> addrgenmode eui64
6: bond0.2@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
    link/ether 30:8d:5a:bd:30:15 brd ff:ff:ff:ff:ff:ff promiscuity 0
    vlan protocol 802.1Q id 2 <REORDER_HDR> addrgenmode eui64
7: bond0.3@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
    link/ether 30:8d:5a:bd:30:15 brd ff:ff:ff:ff:ff:ff promiscuity 0
    vlan protocol 802.1Q id 3 <REORDER_HDR> addrgenmode eui64
8: bond0.4@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
    link/ether 30:8d:5a:bd:30:15 brd ff:ff:ff:ff:ff:ff promiscuity 0
    vlan protocol 802.1Q id 4 <REORDER_HDR> addrgenmode eui64
9: bond0.5@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
    link/ether 30:8d:5a:bd:30:15 brd ff:ff:ff:ff:ff:ff promiscuity 0
    vlan protocol 802.1Q id 5 <REORDER_HDR> addrgenmode eui64

Und was mich noch stört sind zwei folgende Zeilen beim restarten vom Netzwerk oder Runter Fahren vom Centos
bond0: no command found in slaves file - use +ifname ifstat
bond0: no command found in slaves file - use +ifname ifstat
Member: aqui
aqui Aug 03, 2016 at 16:46:27 (UTC)
Goto Top
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
Member: OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO Aug 04, 2016 updated at 09:10:35 (UTC)
Goto Top
All das habe ich doch bereits gelesen. Scheinbar nicht ganz verstanden. Und das mit den verschiedenen IP Adressen habe ich zwar gesehen, jedoch ignoriert, da es nirgendwo steht, dass man das so machen muss. Bei mir zuhause mit der Digitalisierungsbox habe ich auch alle VLAN in einem IP Bereich gelegt und es funktioniert.

Naja wie dem auch sei. Danke dir aqui, dass du mit mir soviel Geduld gehabt hast.

Ich habe es nun wie folgt gebildet:


Port 1-5 = Vlan 1-5


/etc/sysconfig/network-scripts/ifcfg-enp5s0
HWADDR="10:8d:5a:1b:20:16"  
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="enp5s0"  
UUID="26fa4429-cec1-40fd-9c1a-81b4aafff847"  
ONBOOT="yes"  
MASTER="bond0"  
SLAVE="yes"

/etc/sysconfig/network-scripts/ifcfg-enp7s0
HWADDR="60:05:c1:3e:6b:15"  
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="enp7s0"  
UUID="81de165b-1bc3-4159-a337-26f4a42b3bd0"  
ONBOOT="yes"  
MASTER="bond0"  
SLAVE="yes"

/etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
NAME=bond0
TYPE=Bond
BONDING_MASTER=yes
IPADDR=172.19.126.3
PREFIX=24
GATEWAY="172.19.126.1"  
DNS1="10.1.1.1"  
ONBOOT=yes
BOOTPROTO=static
BONDING_OPTS="mode=4 miimon=100"

Soviel zur Bonding. Das funktioniert.

Jetzt VLAN:

Ich habe jetzt folgende Datein erstellt mit dem folgendem Inhalt:

/etc/sysconfig/network-scripts/ifcfg-bond0.1
DEVICE=bond0.1
BOOTPROTO=static
ONBOOT=yes
IPADDR=172.19.131.3
PREFIX=24
NETWORK=172.19.131.0
VLAN=yes

/etc/sysconfig/network-scripts/ifcfg-bond0.2
DEVICE=bond0.2
BOOTPROTO=static
ONBOOT=yes
IPADDR=172.19.127.3
PREFIX=24
NETWORK=172.19.127.0
VLAN=yes

/etc/sysconfig/network-scripts/ifcfg-bond0.3
DEVICE=bond0.3
BOOTPROTO=static
ONBOOT=yes
IPADDR=172.19.128.3
PREFIX=24
NETWORK=172.19.128.0
VLAN=yes

/etc/sysconfig/network-scripts/ifcfg-bond0.4
DEVICE=bond0.4
BOOTPROTO=static
ONBOOT=yes
IPADDR=172.19.129.3
PREFIX=24
NETWORK=172.19.129.0
VLAN=yes

/etc/sysconfig/network-scripts/ifcfg-bond0.5
DEVICE=bond0.5
BOOTPROTO=static
ONBOOT=yes
IPADDR=172.19.130.3
PREFIX=24
NETWORK=172.19.130.0
VLAN=yes

Außerdem habe ich habe ich noch folgende Dateien angelegt:

/etc/sysconfig/network-scripts/route-vlan1
ip route add default via 172.19.126.3 dev vlan1 table 1

/etc/sysconfig/network-scripts/route-vlan2
ip route add default via 172.19.127.3 dev vlan2 table 2

Spielt aber keine Rolle ob diese da sind oder nicht.

So jetzt habe ich folgende Situation.
Der Server wird nun von VLAN 1-5 erreicht.
Der Server erreicht alle Clienten im VLAN 1-5.
Der Server google nicht anpingen. (keine Internet Verbindung)
Member: aqui
aqui Aug 05, 2016 updated at 16:37:47 (UTC)
Goto Top
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 -n
Was 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 ??
Member: OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO Aug 07, 2016 at 06:30:47 (UTC)
Goto Top
Ich komme jetzt leider die Woche nicht mehr an die Struktur.

Ok, natürlich muss ich dir jetzt Recht geben. Habe gestern noch mal nach dem selben Prinzip auch zu Hause versucht für die Media Reciver VLAN einzurichten. Und habe auch bemerkt, dass ich von Switch aus keine Verbindung zum Drucker habe, welches an der Digibox hängt. *schähm* „Ganz viel lernen muss ich da noch.“

Eigentlich ist zwischen den folgenden Zeilen in meinem letztem Beitrag noch eine Grafik mit eine Netzwerktopographie gewesen.

Ich habe es nun wie folgt gebildet:

image 4c39968a9265159ac32e22892cee2fe1

Port 1-5 = Vlan 1-5

Warum auch immer kann man es nicht sehen, daher jetzt nun ein Link dazu:


Ein Bekannter hat mir gesagt, dass das was ich eigentlich vor habe, gar nicht funktionieren kann.

Und schickte mir folgenden Aufbau.

aajeieijpcblnbgc

Leider musste ich dann die Kinder ins Bett bringen und kam ihn nicht mehr dazu ihn zu fragen was genau ich an den Switches einstellen muss.

Kannst du es mir vielleicht sagen, eventuell verstehe ich dann die Logik. Denn bis jetzt hat mit TP-Link auch nicht sagen können was die einzelnen Punkte GENERAL TRUNK ACCESS zu bedeuten haben.
Member: aqui
aqui Aug 07, 2016 updated at 12:48:11 (UTC)
Goto Top
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 ??
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 face-sad 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 !! face-smile
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... face-sad
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.
Member: OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO Aug 16, 2016 at 14:06:01 (UTC)
Goto Top
Vielen Dank für die Erklärung. Billig willich. :/

Ja den Super-SAU habe ich des öfteren gehabt, und dabei das gesamte Netzwerk lahm gelegt. face-smile

Ich habe jetzt mal zum üben mich erstmal auf drei Switches beschränkt.

Und die Switches wie folgt konfiguriert.

Switch-A:

Port 1 ACCESS VLAN1
Port 2 ACCESS VLAN2
Port 17 GENERAL Active-LACP VLAN1 UNTAG; VLAN2 TAG SERVER
Port 18 GENERAL Active-LACP VLAN1 UNTAG; VLAN2 TAG SERVER
Port 21 TRUNK LAG3 SWITCH-C
Port 22 TRUNK LAG3 SWITCH-C
Port 21 TRUNK LAG2 SWITCH-B
Port 22 TRUNK LAG2 SWITCH-B
Port 23 TRUNK LAG2 SWITCH-B
Port 24 GENERAL VLAN1 UNTAG; VLAN2 TAG GATEWAY

Switch-B:

Port 1 ACCESS VLAN1
Port 2 ACCESS VLAN2
Port 22 TRUNK Static-LAG2 SWITCH-A
Port 23 TRUNK Static-LAG2 SWITCH-A
Port 24 TRUNK Static-LAG2 SWITCH-A

Switch-C:

Port 1 ACCESS VLAN1
Port 2 ACCESS VLAN2
Port 15 TRUNK Static-LAG3 SWITCH-A
Port 16 TRUNK Static-LAG3 SWITCH-A

Laut TP-Link ist es auch richtig. :/

Der Server kommt ins internet, die Clients erreichen den Server, der Server erreicht die Clients. Nun habe ich das Problem, dass die Clients im VLAN2 nicht ins Internet kommen. Jetzt fehlt der route zum Gateway „172.19.126.1“

VLAN1 hat 172.19.126.0/24
VLAN2 hat 172.19.127.0/24

[root@server ~]# route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.19.126.1    0.0.0.0         UG    0      0        0 bond0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 enp6s0
169.254.0.0     0.0.0.0         255.255.0.0     U     1005   0        0 bond0
169.254.0.0     0.0.0.0         255.255.0.0     U     1006   0        0 virbr0
169.254.0.0     0.0.0.0         255.255.0.0     U     1193   0        0 bond0.1
169.254.0.0     0.0.0.0         255.255.0.0     U     1195   0        0 bond0.2
169.254.0.0     0.0.0.0         255.255.0.0     U     1196   0        0 bond0.3
169.254.0.0     0.0.0.0         255.255.0.0     U     1197   0        0 bond0.4
169.254.0.0     0.0.0.0         255.255.0.0     U     1198   0        0 bond0.5
172.19.126.0    0.0.0.0         255.255.255.0   U     0      0        0 bond0
172.19.126.0    0.0.0.0         255.255.255.0   U     0      0        0 enp6s0
172.19.127.0    0.0.0.0         255.255.255.0   U     0      0        0 bond0.2
172.19.128.0    0.0.0.0         255.255.255.0   U     0      0        0 bond0.3
172.19.129.0    0.0.0.0         255.255.255.0   U     0      0        0 bond0.4
172.19.130.0    0.0.0.0         255.255.255.0   U     0      0        0 bond0.5
172.19.131.0    0.0.0.0         255.255.255.0   U     0      0        0 bond0.1
172.19.132.0    0.0.0.0         255.255.255.0   U     0      0        0 virbr0
[root@server ~]# ip route show
default via 172.19.126.1 dev bond0
169.254.0.0/16 dev enp6s0  scope link  metric 1002
169.254.0.0/16 dev bond0  scope link  metric 1005
169.254.0.0/16 dev virbr0  scope link  metric 1006
169.254.0.0/16 dev bond0.1  scope link  metric 1193
169.254.0.0/16 dev bond0.2  scope link  metric 1195
169.254.0.0/16 dev bond0.3  scope link  metric 1196
169.254.0.0/16 dev bond0.4  scope link  metric 1197
169.254.0.0/16 dev bond0.5  scope link  metric 1198
172.19.126.0/24 dev bond0  proto kernel  scope link  src 172.19.126.104
172.19.126.0/24 dev enp6s0  proto kernel  scope link  src 172.19.126.3
172.19.127.0/24 dev bond0.2  proto kernel  scope link  src 172.19.127.1
172.19.128.0/24 dev bond0.3  proto kernel  scope link  src 172.19.128.1
172.19.129.0/24 dev bond0.4  proto kernel  scope link  src 172.19.129.1
172.19.130.0/24 dev bond0.5  proto kernel  scope link  src 172.19.130.1
172.19.131.0/24 dev bond0.1  proto kernel  scope link  src 172.19.131.1
172.19.132.0/24 dev virbr0  proto kernel  scope link  src 172.19.132.3
Member: aqui
aqui Aug 17, 2016 updated at 08:59:44 (UTC)
Goto Top
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.
Dürfte bei CentOS ähnlich sein ?!
  • 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 !!
Member: OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO Aug 17, 2016 at 12:33:19 (UTC)
Goto Top
Auf den Trunk Uplinks der Switches untereinader hast du hoffentlich alle VLANs tagged konfiguriert ?? (Außer VLAN 1, das ist immer untagged)

Nein die Switches sind alle mit TRUNK miteinander verbunden, dann kann man VLAN getrennt nicht konfigurieren. Diese sind dann alle TAG bei TP-Link. Das würde nur mit GENERAL gehen, dann kann man auch verschiedene VLAN unterschiedlich einstellen TAG oder UNTAG.

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. Gateway habe ich auch neu bekommen 172.19.255.1

VLAN1 172.19.1.1
VLAN2 172.19.2.1
VLAN3 172.19.3.1

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...

JA und JA

Zeile #net.ipv4.ip_forward=1 in der Datei /etc/sysctl.conf .

Wurde so auf einigen Seiten beschrieben. Wurde in die bestehende, leerere Datei eingefügt.

Im VLAN 2 bekommen alle Endgeräte die IP Adresse des CentOS Servers als Default Gateway

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?

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 !!

Wir haben keinen Router, wir haben kein Zugriff darauf. DNS ist 10.1.2.1

Fertisch.

Läuft nicht face-sad

Muss auf dem Server nicht die Umleitung der einzelnen IP-Bäumen noch eingerichtet werden so ähnlich wie das hier?

[root@server ~]# ip route add 172.19.0.0/16 via 172.19.255.1 dev bond0
RTNETLINK answers: File exists
Member: aqui
aqui Aug 18, 2016 updated at 08:04:59 (UTC)
Goto Top
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. face-smile 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... face-wink
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.
Member: OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO Aug 18, 2016 at 08:19:23 (UTC)
Goto Top
Wichtig ist das sie getagged sind, so das die VLANs an alles 3 Switches verfügbar sind.

Dann muss ich es auf GENERAL stellen. Ist ja in prezip das gleiche, wenn ich die anderen Vlans auf TAG stelle.

Fragt sich jetzt in welchem VLAN denn nun .255.0 /24 ist ?? Im VLAN 4 oder wo ???

Ähm das ist bond0 das ist in keinem VLAN. :/ sollte ich VLAN 1 damit bestücken?

Ich lese noch mal was du mir gelinkt hast durch. Danke dir!
Member: aqui
aqui Aug 18, 2016 updated at 09:08:26 (UTC)
Goto Top
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.
Ä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) !!
Member: OIOOIOOIOIIOOOIIOIIOIOOO
OIOOIOOIOIIOOOIIOIIOIOOO Aug 18, 2016 updated at 10:24:37 (UTC)
Goto Top
Ok, als habe ich jetzt aus dem Server VLAN1 die Datei ifcnf-bond0.1 entfernt.

Und ich lese weiter face-smile

Ok ICS habe ich überlesen. Der Begriff "Masquerading" sate mir so erstmal nichts. Hast du eine andere Lösung (bezahlbar so zwischen 100 - 999 unter 1000 Euro)? Derzeit haben wir nur 30 Clients die da durch müssen. Was brauche ich dann noch damit die einzelnen VLANs ins Internet können und das DNS 10.1.2.1 erreichen können?
GermanQuestionRedHat, CentOS, FedoraLinux