Messages

76

German - Deutsch / Wer hat Erfahrung mit EVPN und opnsense?

« on: July 20, 2022, 08:18:42 pm »

Wir ziehen gerade ein mandantenfähiges Datacenter-Netzwerk hoch. Räumlich steht das DC auf einem Campus, auf dem auch die Accessswitches ausgerollt werden. Es gibt keine WAN-strecken in dem Sinne, alle Accessswitches auf dem Gelände hängen mit direktem Uplink am Datacenter.

Die Umgebung wird vollständig mit SDDC und SDDN betrieben.

Das SDDC wird mit VMware vSphere 7, vSAN Enterprise und VMwarae NSX-T 3.2 Enterprise Plus realisiert.

Die Switche im DC sind Dell S5248F-ON mit Dell OS 10. Die Switche im Accessbereich sind Dell N3248PXE-ON. Aktuell noch mit Dell OS 6 (OS6 kann kein VXLAN, die Hardware der Switche aber schon) aber wir sind aktuell dabei PICOS zu prüfen, damit wir EVPN bis zu den Accessswitches ausrollen können.

Für das EVPN kommt OSPF oder BGP im underlay fürs Overlay VXLAN  mit MP-BGP zum Einsatz.

Das Routing/Firewalling zwischen den Tenants werden wir wenn möglich zentral in NSX-T machen. Wir wollen also keine VRFs auf den Switches betreiben. Wir sind uns aber noch nicht ganz sicher, ob die Routing/Firewalling-Leistung und die Handhabbarkeit von NSX-T-Edges für diesen Anwendungsfall ausreichen.

Wenn ich das richtig sehe, scheint FRR EVPN mit MP-BGP ja grundsätzlich zu können:
https://docs.frrouting.org/en/latest/bgp.html

Wir würden in der Umgebung gerne auch OPNsense-Router betreiben, die dann direkt ans EVPN angeschlossen werden.

Hat schon mal jemand OPNsense in Verbindung mit EVPN-Netzen eingesetzt? Falls ja, wie sind die Erfahrungen?

Hat die Business Edition spezielle Erweiterungen / Features im repo für diesen Anwendungsfall?

77

German - Deutsch / Re: Regeln auf Loopbackinterfaces greifen nicht - was ist zu beachten?

« on: July 08, 2022, 03:17:49 pm »

Ja, das hatten wir auch schon im Sinn. Regeln greifen ja entweder nur wenn Traffic in ein Interface rein fließt oder aus einem Interface raus fließt. Dementsprecht muss man ja In oder Out bei den Regeln wählen.

WAN wäre in dem Fall ja das Interface 10.1.0.2 im Transfernetz. Da greifen die Regeln dann auch, wenn wir eine IN-Regel erstellen. Das heißt, ist der Traffic an der Stelle durch, kommt er bis zu den lo1 Adressen. Ohne eine In-Regel (z.B. erlaube jeglichen Traffic aus dem Internet, der zu 192.192.192.0/24 will) auf diesem Interface, hätte der Traffic auch keine Chance überhaupt zum lo1 zu kommen.

Wir wollten dann versuchen, z.B. Pings aus dem Internet oder Zugriffe auf das Webinterface der sense zu unterbinden. Geht das in dem Fall überhaupt?

Edit: Aktuell haben wir den HA-Proxy oder Portforwardings noch gar nicht konfiguriert. Wir wollten erstmal hinbekommen, dass die öffentlichen Adressen gezielt gepingt bzw. nicht gepingt werden können. Das heißt wir haben noch gar keine Out-Regel vom lo1 zu HA-Proxy oder einem DMZ-Host unterbinden können.

78

German - Deutsch / Regeln auf Loopbackinterfaces greifen nicht - was ist zu beachten?

« on: July 08, 2022, 02:15:20 pm »

Hallo zusammen,

wir haben ein öffentliches /24er IPv4-Netz. Als Adresse nehmen wir 192.192.192.0/24 an. Dieser Adressblock wird von Router 1 an unsere OPNsense mit der IP 10.1.0.2 geroutet.

Auf der OPNsense wollen wir nun die public IPs verwalten und je nach Bedarf über HA-Proxy oder Portforwardings an entsprechende Dienste in diversen DMZs/lokalen Netzen weiterleiten.

Um die öffentlichen IPs auf der sense zu verwalten, haben wir ein Loopback-Interface angelegt (lo1), dieses aktiviert und ihm die IP 192.192.192.1/32 als Virtual IP gegeben. Diese IP ist auch aus dem Netz erreichbar, wenn man auf dem Transfernetz eine entsprechende Allow-Regel anlegt.

Weil wir mehrere Tenants haben werden, würden wir jedem Tenant gerne zukünftig ein eigenes Loopback-Interface mit jeweils eigener öffentlicher IP zuweisen, also lo2 = 192.192.192.2/32, lo3 = 192.192.192.3/32 usw.. Die Überlegung dahinter ist, dass es übersichtlicher ist, wenn jedes Tenant sein eigenes Interface hat, weil dann die Regeln nicht alle auf einem Interface erstellt werden.


Hier der Plan dazu:

      WAN / Internet
            :
            :
      .-----+-----.
      |  Router1 |
      '-----+-----'
            |.1
            |
        Transfernetz 10.1.0.0/24
            |
            |.2
      .-----+----------------------------------------------------------------.
      |  OPNsense                                                  |         lo1          | -Virtuelle IP 192.192.192.1
      '-----+----------------------------------------------------------------'
            | .1                                |.1                    |         lo2          | -Virtuelle IP 192.192.192.2
            |                                    |                       -------------------'
            |                                    |
   DMZ1 | 10.2.0.1/24        DMZ1 | 10.3.0.0/24   




Wenn wir wie oben angedeutet auf dem Interface 10.1.0.2 Regeln anlegen, die den Zugriff aus dem Internet zu den Public IPs regeln dann klappt es ohne Probleme, den Zugriff auf die Public IPs zu reglementieren.

Unser Problem ist, dass die Regelwerke, die wir auf den Loobackinterfaces definieren nicht greifen.

Wenn man die Regelwerke auf den Loopback-Interface anlegen will, wie müsste dann die Regeln aussehen, wenn z.B. HTTP/HTTPS-Traffic aus dem Internet erlaubt werden soll?


Vielen Dank für die Hilfestellung.

79

22.1 Legacy Series / Re: os-ddclient

« on: June 02, 2022, 11:50:29 am »

Has anyone had a chance to test the latest version of ddclient

from at least 3.10.0rc1
https://github.com/ddclient/ddclient/releases

I'm wondering if it works with an API key with Cloudflare now
Changelog says yes - https://github.com/ddclient/ddclient/blob/develop/ChangeLog.md

ddclient v 3.10.0 final is out since 2022-05-15 and supports Cloudflare API tokens.

Will CF API tokens be supported in the WebUI till opnsense 20.7 is out?

Yes i know, legacy plugins will further work on existing setups, but old dyndns plugin will not be installable on new setups once 20.7 is released?!

80

German - Deutsch / Re: Eingeschränkter Upload im lokalen Netzwerk

« on: June 02, 2022, 10:53:19 am »

Ist da nur Routing und Firewalling im Spiel oder betreibst du die Nextcloud in Verbindung mit HAproxy oder ähnlichem auf der Sense?

Welchen Client nutzt du von extern, welchen Client von intern? Ist das der selbe Client (z.B. Laptop)?

Arbeitest du von außen mit Portforwarding direkt auf die Nextcloud? Wenn ja welche Ports sind freigeben/weitergeleit?

Welche Firewallregeln sind auf dem internen Interface vom internen Netz (Standard-LAN Interface)?

Findet der Upload jeweils über HTTPs, also das Webinterface der Nextcloud statt oder lädst du noch über andere Protokolle hoch/runter (FTP, Webdav, ....)?


Klingt zwar nach nem einfachen Netzaufbau, aber ein Netzplan wäre trotzdem ganz schön. ;-)

81

German - Deutsch / Re: WiFi im Jahr 2022 mit der OPNsense / FreeBSD 13 ?

« on: June 02, 2022, 10:07:14 am »

Diese WiFi-Einschränkungen unter FreeBSD sind halt schon ziemlich lästig. Das verhindert halt so ziemlich jedes  All-In-One-Projekt. Vor allem kleine, kompakte AIO-Geräte sind dann raus, wenn man immer nen extra AP anstecken muss.

Ich hatte vor, eine kleine kompakte Sense für den Urlaub zu bauen, in die man sich seine Touri-SIM rein macht und dann jeder drauf zugreifen kann. Ähnlich wie ein Netgear Nighthawk M1 oder so, nur halt mit mehr Möglichkeiten wie Site2Site VPN nach Hause etc., idealerweise mit nem Akku drin.

WiFi wäre spätestens dann interessant, wenn (falls) die OPNsense mal stabil auf ARM-Plattformen läuft. Irgendwelche Pis würden dafür ja ausreichen.

Oder wenn so Kracher wie der Mochabin mal unterstützt werden, dann könnte man sogar vollwertige und stromsparende und dazu noch performante Heimrouter mit Glasfaserinterface, WiFi6 und bei Bedarf auch Mobilfunk bauen.

82

German - Deutsch / Re: Umzug auf virtuell Überlegungen

« on: June 02, 2022, 09:49:15 am »

Es braucht übrigens nicht mal eine VM, in der die Sense läuft, um Snapshots zu nutzen. Wer ZFS als Dateisystem nutzt, kann auch einfach auf Dateisystemebene Snapshots erstellen - das geht bei Baremetalinstallation und in der VM. Leider scheint das aber noch nicht in die GUI eingebaut zu sein. Hier gibts ein paar mehr Infos dazu:

https://forum.opnsense.org/index.php?topic=25540.msg122750

https://docs.freebsd.org/en/books/handbook/zfs/


Ich handhabe es übrigens auch so, dass ich zu Hause keine HA-Konfig in der OPNsense aktiviert habe. Ich update in der Regel nur, wenn ich zu Hause bin. Das geht auf schneller Hardware so schnell, dass 30-60s Downtime für nen Reboot kein Problem sind.

Im Notfall, wenn ich doch mal von unterwegs aus updates machen will oder den Hypervisor auf dem die Sense läuft von unterwegs aus neu starten möchte oder der Hypervisor geplante längere Downtimes hat, gehe ich wie folgt vor:

Ich habe eine zweite Sense. Diese zweite Sense ist in der Regel ausgeschaltet. Sie ist im Idealfall ein aktueller Clone der ersten Sense in einer VM, kann aber auch ein Baremetalsystem sein. Die zweite Sense schalte ich ein, bevor ich von unterwegs irgendwelche kritischen Sachen machen will wo die Gefahr besteht, dass die erste Sense nicht mehr hoch kommt.

Das hochfahren der zweiten Sense mit exakt gleicher Konfig macht deshalb kein Problem, weil jede Sense beim booten oder beim Anlegen eines neuen Interfaces erkennt, ob die IP im Netzwerk schon online sind - es kommt also nicht zu IP-konflikten/kollisionen. Die zweite Sense schaltet ihrer IPs nicht online, solang ein anderes Device im Netz die gleiche IP zuvor nutzt.

Wenn ich dann die erste Sense neu starte und deren IPs offline sind, übernimmt die zweite Sense einfach den Betrieb, indem sie ihre IPs online nimmt.

Die erste Sense kann man dann im Notfall über den Hypervisor oder ein IPME-Interface erreichen. Oder wenn man es vorher eingerichtet hat, könnte man auch ein Notfallnetz nutzen, in der die erste Sense ne .1 und die zweite Sense ne .2 IP hat. Dann sollte man - sofern die erste Sense nicht ganz kaputt ist - auch wieder aufs Webinterface/SSH kommen.

Edit: Sollte man natürlich mal testen, bevor man es Live ausprobiert. Und: Kann mit PPPOE Probleme geben (?)

83

German - Deutsch / WiFi im Jahr 2022 mit der OPNsense / FreeBSD 13 ?

« on: May 29, 2022, 03:26:58 pm »

Hallo zusammen,

wie siehts denn mit WiFi im Jahr 2022 aus, seitdem FreeBSD 13 unter OPNsense läuft?

Ich kann mich noch dran erinnern, dass 802.11G eine Zeit lang das höchste der Gefühle war und auch nicht unbedingt sauber lief. Dann gabs irgendwann mal 802.11N support, aber mehr als 802.11G-Geschwindigkeit war in der Regel nicht drin (oder so ähnlich).

So gut wie alle Empfehlungen, die man so findet, stammen noch aus Zeiten, als noch kein FreeBSD13 unter der OPNsense lief.

Ist WiFi mittlerweile ausgereift? Und geht auch 802.11AC oder AX mit ordentlichen Geschwindigkeiten?

Wie sind da eure Erfahrungen?

84

German - Deutsch / Re: VXLAN in der OPNsense verstehen

« on: May 17, 2022, 03:46:14 pm »

Ich hab ein Testsetup zwischen zwei sensen aufgebaut um VXLAN testen zu können, bekomme aber die Bridge nicht ans laufen. Kann mir bitte jemand auf die Sprünge helfen?

Der VXLAN-Tunnel (Eigenes Transfernetz über VLAN 911 mit MTU 9000) scheint zu stehen. Wenn ich jedem VXLAN-Interface auf den beiden sensen ne eigene IP gebe können sie sich gegenseitig pingen. Sogar DHCP funktioniert über VXLAN.

Auf Sense 1 hab ich dann eine Bridge angelegt. Member sind das VXLAN Interface und ein VLAN-Interface in VLAN 2020.
Auf Sense 2 hab ich auch eine Bridge angelegt. Member sind wieder das VLAN Interface und ein VLAN-Interface in VLAN 2021.

Ich hab auf den VXLAN-Interfaces dann IPv4 deaktiviert. VLAN 2020 und 2021 sowie die Bridge haben auch keine IP.

In den Tunerables hab ich Filterung auf der Bridge und auf den Members deaktiviert. Trotzdem haben alle  beteiligten Interfaces allow all rules bekommen.

Anmerkung: In den meisten Tutorials steht, dass man Filterung für die Bridge aktivieren soll und auf Bridgemembers deaktivieren. Ich brauch in dem Fall aber weder auf der Bridge noch auf dem Bridgemember Filterung, weil keines davon ne IP bekommen soll.

Nun hab ich einen Win10 Testclient an VLAN 2020 (11.11.20.20/24) und einen anderen an VLAN 2021 (11.11.20.21/24) mit festen IPs angehängt. Die Clients können sich jedoch nicht pingen.

Jemand ne Idee?

Was ich bereits probiert habe:
- Wenn ich die Clients beide in VLAN 2020 oder 2021 hänge, können sie sich pingen (kein Client-FW Problem oder so)
- Wenn ich dem Interface 2020 oder 2021 auf den Sensen eine IP im 11.11.20.0/24er Netz gebe, kann ich diese IPs vom Client aus pingen (somit kein Problem vom VLAN-Interface)
- Wenn ich dann die IP auf die Bridge umziehe, kann ich die IP nicht mehr von den Clients aus pingen (somit ein Bridgingproblem?)
- Wenn ich dann die IP nochmals auf das VXLAN-Interface umziehe, kann ich die IP vom client aus pingen, weil ist ja auch direct attached
- Wenn ich von Sense 1 die IP vom VXLAN-Interface pinge, geht das (siehe auch oben)
- Wenn ich von Sense 1 die IP von der Bridge in Sense 2 pinge, geht das wiederum nicht (somit ein Bridgingproblem?)

Überlegung:

Müsste es nicht möglich sein, dasss wenn jeder Client, jedes VLAN-Interface, jedes VXLAN-Interface und jede Bridge ne statische IP bekommt, dass sich dann alle IPs gegenseitig pingen können müssten?


Edit: Grafisch sieht das dann etwa so aus:

Client 1 mit fixer IP 11.11.20.20 <->VLAN 2020

<-> if_vlan2020 <-> Bridge0 <-> if_vxlan <-> if_vlan911 <->  #Sense1

VLAN 911                                                                                #Transfernetz für VXLAN TEPs

<-> if_vlan911 <-> if_vxlan <-> Birdge0 <-> if_vlan2021 <->  #Sense 2

VLAN 2021 <-> Client 2 mit fixer IP 11.11.20.21

85

German - Deutsch / Re: QinQ / 802.1ad Support ?

« on: May 16, 2022, 01:29:33 pm »

Habs mal reported.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264014

86

German - Deutsch / Re: QinQ / 802.1ad Support ?

« on: May 16, 2022, 10:19:42 am »

Ja, danke. Das wurde mir jetzt auch schon im FreeBSD-Forum bestätigt.

Wo kann man bei den FreeBSD-Entwicklern Feature-Requests einkippen?

Es wäre cool, wenn FreeBSD den EtherType 0x88A8, 0x9100, 0x9200, 0x9300 für QinQ nutzen würde. Oder wenn man den EtherType je Interface einstellbar machen könnte.

87

German - Deutsch / Re: QinQ / 802.1ad Support ?

« on: May 13, 2022, 08:47:56 am »

Ich muss den vorherigen Post nochmal etwas ergänzen / klarstellen, was Switche mit "unsauberer QinQ-Implementierung" angeht:

Bevor es 802.1AD gab, welches den Ethertype auf 0x88A8 festgelegt hat, gab es einen inoffiziellen Vorläufer, der auch 801.1QinQ genannt wurde. Dieser Vorläufer nutzte meist 0x9100 als EtherType.

Wenn also in Switchdokus von 802.1QinQ die Rede ist, dann ist möglicherweise gemeint, dass der Switch QinQ mit Ethertype 0x9100 beherrscht.

Es gibt nach wie vor aktuelle Switche, die diese Altlast mit sich rumtragen und nicht jedes Switch-OS lässt zu, den Ethertype von 0x9100 auf z.B. 0x88A8 zu ändern.

Welchen Ethertype nutzt OPNsense standardmäßig für QinQ (würde mal 0x8848 vermuten)?

Wenn ich das richtig sehe, sollte FreeBSD nicht nur 0x88A8 sondern auch 0x9100, 0x9200 und 0x9300 unterstützen.

https://reviews.freebsd.org/D21846

88

German - Deutsch / Re: Unterschied zwischen WAN, WAN_VLAN und PPPoE Interface

« on: May 12, 2022, 03:30:50 pm »

Die Sophos-Box wird nichts weiter sein als ein Mini-Computer auf der OPNsense installiert wurde. Gut so. :-)

Die Sophos-Box hat mehrere Netzwerkanschlüsse. Einen davon, nämlich igb1 (Intel Gigabit, daher igb1) hast du an dein Glasfasermodem angeschlossen. Du wirst noch weitere haben, z.b. igb0, an dem du dein internes Netzwerk angeschlossen hast. Die sind aber für deine Fragestellung erstmal nicht relevant.

Dein WAN-Interface wird direkt auf igb1 verknüpft sein. Für deinen Internetzugang brauchst du das aber nicht. Es könnte theoretisch sogar deaktiviert oder gar gelöscht werden. Aber das muss nicht sein, lass es einfach so wie es ist.

Dein WAN_VLAN Interface wird, wenn es ein Telekom-Anschluss ist, ziemlich sicher igb1_vlan7 oder so ähnlich heißen. Dieses WAN_VLAN-interface ist wahrscheinlich ebenfalls auf igb1 verknüpft, vielleicht aber auch auf igb0 oder 2. Oder? Jedenfalls ist WAN_VLAN auf den Anschluss verknüpft, an dem dein Glasfasermodem dran hängt.

Durch die Konfiguration von VLANs ist es möglich, über ein Netzwerkkabel mehrere separate Netzwerk zu übertragen. In der aktuellen Konfiguration hast du also wahrscheinlich über igb1 ein Netzwerk ohne VLAN-Tag laufen (das ist das, was hinter WAN-Interface steckt), als auch das Netzwerk WAN_VLAN, welches über die VLAN-ID 7 von dem Netzwerk WAN (welches keine ID hat) abgegrenzt werden kann.

Im WAN-Interface hast du scheinbar als IPv4-Adresse 0.0.0.0/8 konfiguriert (was keinen Sinn ergibt) und eine IPv6-Adresse.
Im WAN_VLAN-Interface hast du keine IP-Adressen konfiguriert, was aber auch nicht zwingend notwendig ist. Denn dieses Interface wird nicht dazu verwendet, direkt IPv4 oder IPv6 zu sprechen. Es ist einzig und allein dafür da, die pppoe-Kommunikation mit der Telekom zu ermöglichen. Da die Telekom ihren DSL-Traffic über VLAN 7 schickt und empfängt, muss dieses VLAN-Interface mit der ID 7 angelegt werden.

Wenn du das soweit verstanden hast wirst du evtl.  erahnen, dass das PPPOE-Interface nun schlicht und einfach das WAN_VLAN-Interface nutzt, um die Anmeldung bei der Telekom zu ermöglichen. Es ist also so, dass dein PPPOE auf das WAN_VLAN aufsetzt.

Das PPPOE-Interface ist der Teil, der sich die öffentliche IPv4 bzw. IPv6-Adresse von der Telekom zieht.
Das WAN_VLAN wiederum braucht nicht zwingend eine IPv4/6-Adresse, weil es nur als Unterbau für die PPPOE genutzt wird.

Dein WAN-Interface wiederum könnte man mit einer sinnvollen IPv64/-Adresse wiederum dazu nutzen, um vom internen Netz auch auf dein Glasfasermodem drauf zu kommen um z.B. die Qualität und Geschwindigkeit der Glasfaserverbindung auslesen zu können. Mit der 0.0.0.0/8 wird das aber nichts. Wenn dein Glasfasermodem z.B. die 192.168.1.1/24 hat, dann müsstest du das WAN-Interface mit z.b. 192.168.1.2/24 konfigurieren. Es fehlt dann noch die Outbound-NAT-Konfig für das WAN-Interface, aber du solltest das was ich geschrieben habe erstmal verstehen und bestätigen, ob dein WAN-Interface wirklich die 0.0.0.0/8 hat und welche IP dein Glasfasermodem hat.

Hoffe, das war soweit verständlich.

89

German - Deutsch / Re: QinQ / 802.1ad Support ?

« on: May 12, 2022, 02:27:38 pm »

Ich hab zum Thema QinQ noch eine Frage.

Der übliche VLAN-Tag (802.1Q) bzw. der innere Tag vom QinQ wird ja mit EtherType/Tag Protocol Identifier(TPID) 0x8100 markiert . Der äußere Tag von 802.1AD wird gemäß Standard mit EtherType 0x88A8 markiert.

Ist es möglich, den äußeren Ethertype von einem QinQ-Device zu modifizieren? Sagen wir, auch auf EtherType 0x8100?

Grund:

Es gibt Switche, die können zwar QinQ, aber machen das nicht unbedingt sauber. Die nutzen sowohl für den äußeren als auch den inneren Ethertype immer die 0x8100.

Und es gibt Switche, die können mit Ethertype 0x88A8 nix anfangen, weil sie nur 0x8100 (802.1Q) können. Solche Switche könnte man trotzdem unter bestimmten Umständen für QinQ missbrauchen. Würde die Sense ebenfalls "unsauberes" QinQ beherrschen und outer und inner Tag mit Ethertype 0x8100 versehen, dann würde so ein Switch den äußeren Tag als VLAN-Tag und den inneren Tag als Payload betrachten. Der Payload würde dann aus am letzten Switch vor dem Accessswitch aus einem ungetaggten Port ausgeleitet werden. Der Accesswitch würde dann einfach auf Tagging eingestellt sein den Payload dem entsprechenden VLAN zuweisen. Ist zwar dirty, aber müsste gehen.

Und dann gibts Switche da kann man den TPID sogar ändern oder zusätzliche TPIDs hinzufügen/definieren.

90

German - Deutsch / Re: VXLAN in der OPNsense verstehen

« on: May 12, 2022, 01:55:33 pm »

Wir haben aktuell Dell Switche die mit Dell OS10 (wären auch Open-Network-fähig). Dafür gibt es auch brauchbare Konfigbeispiele in der Doku. EVPN / BGP nutzen wir aktuell aber auch nicht, da das Netz zu klein ist und der Aufwand sich auf absehbare Zeit nicht lohnt. Das Underlay-Network ist erstmal ohne dynamisches Routing und Layer 2.

Der ursprüngliche Gedanke war, dass wir zwischen unserem Edge-Router vom Datacenter und den Access-Switches einfach nur ein Transfernetz bauen, in das wir die VXLAN-Tunnel zu den Switches anlegen und dann nur auf den Access-Switches dort wo benötigt die einzelnen VNIs auf die VLANs auskapseln. Das hätte dieses lästige VLAN-Management durchs Netzwerk weitgehend eingedampft.


Was ich nicht ganz nachvollziehen kann ist, dass die meisten Implementierungen von VXLAN es nicht zulassen, Frames mit EtherTyper 802.1Q oder 802.1AD zu übertragen, obwohl VXLAN das ja hergeben würde. Das würde den Aufwand der Konfiguration deutlich verringern. Man könnte dann viele VLANs in ein VNI packen. So muss man für jedes VLAN ein eigenes VNI erstellen.