Was ist Plug-and-Play (PnP)?
Plug and Play war ursprünglich ein Begriff für Computerhardware. Wenn ein neues externes Gerät zum Computer hinzugefügt wird, können die Hardwareressourcen automatisch erkannt werden, ohne dass eine Neukonfiguration oder manuelle Treiberinstallation erforderlich ist. Später entstand die Bedeutung des Hot-Plugging, die sich auf das direkte Hinzufügen oder Entfernen von Hardwaregeräten bezieht, wie etwa das Abziehen und Einstecken von USB-Geräten, während der Computer eingeschaltet ist.
In der Datenkommunikation und bei Netzwerklösungen bedeutet Plug-and-Play, dass Netzwerkgeräte und Zugangsendgeräte nach dem Anschluss an das Netzwerk automatisch auf das Netzwerk zugreifen können, um Konfiguration und Bereitstellung ohne manuelle Konfiguration abzuschließen.
Warum benötigt das Campusnetzwerk Plug-and-Play?
Mit der rasanten Entwicklung der Netzwerktechnologie nimmt auch der Umfang von Unternehmensnetzwerken zu. Unternehmenskunden müssen Hunderte bis Tausende von Geräten verwalten und warten, was in den frühen Planungs- und Bereitstellungsphasen, etwa bei der Erstinstallation von Geräten, viel Arbeit verursacht. Die für Konfiguration und Geräte-Upgrades aufgewendete Zeit macht ein Drittel oder mehr des gesamten Netzwerkmanagement- und Betriebszyklus aus, und die meisten dieser Aufgaben sind einfach und repetitiv. Daher müssen Kunden die Installation von Netzwerkgeräten, das Management während der Bereitstellung und spätere Software-Upgrades der Geräte dringend vereinfachen und so die Effizienz steigern.
Darüber hinaus nehmen mit der kontinuierlichen Verbreitung und Anwendung des Internet of Things die Arten und die Anzahl der Endgeräte zu, die auf Campus-Netzwerke zugreifen. Insbesondere in großen und mittelgroßen Campus-Netzwerken gehören zu den Zugangsgeräten neben PCs und Mobiltelefonen auch IP-Telefone, Drucker und Kameras. Viele verschiedene Arten von Endgeräten müssen mit dem Campus-Netzwerk verbunden werden, was die Endgeräteverwaltung im Campus-Intranet sehr schwierig macht. Da das herkömmliche Netzwerkmanagementsystem nur IP und MAC des Zugangsgeräts anzeigen kann, ist keine detailliertere Verwaltung des Endgeräts möglich. Wenn für verschiedene Endgeräte unterschiedliche Netzwerkdienste und Richtlinien geplant und bereitgestellt werden müssen, muss der Administrator für jeden Endgerätetyp unterschiedliche Netzwerkdienste und Richtlinien planen und bereitstellen. Die manuelle Konfiguration von Endgerätetypen macht die Dienstkonfiguration komplex und den Betrieb mühsam. Die automatische Identifizierung und Plug-and-Play von Endgeräten werden ebenfalls dringend benötigt.
Die Plug-and-Play-Lösung wurde entwickelt, um Benutzern zu helfen, den Netzwerkinstallationsprozess zu vereinfachen, die Effizienz der Netzwerkverwaltung sowie des Betriebs und der Wartung erheblich zu verbessern und Arbeits- und Zeitkosten effektiv zu senken. Sie bietet die folgenden Vorteile:
Visualisierung: Der Bedienprozess von Netzwerkadministratoren und Installationsingenieuren erfolgt über eine vollständig grafische Bedienoberfläche, einschließlich der Visualisierung der Konfigurationsoberfläche und der Visualisierung der Netzwerkplanung.
Hohe Effizienz: Durch die Vorab-Bereitstellung von Diensten auf dem SDN-Controller wird der tatsächliche Bereitstellungsprozess durchgängig verkürzt. Die manuelle Bereitstellung kann in wenigen Stunden statt in mehreren Tagen abgeschlossen werden.
Weniger Fehler: Alle Konfigurationen werden grafisch über den SDN-Controller durchgeführt, wodurch die Wahrscheinlichkeit von Fehlern bei der Befehlszeilenkonfiguration verringert wird; Verbindungsfehler können über den SDN-Controller in Echtzeit grafisch erkannt werden, um eine schnelle Fehlerbehebung zu ermöglichen.
Was ist der Plug-and-Play-Prozess für Netzwerkgeräte?
Nimmt man Switches als Beispiel, ist das Netzwerk im Cloud-Park-Netzwerk als geschichteter Baum konzipiert, und unterhalb der Core-Schicht gibt es eine große Anzahl von Switches. Plug-and-Play über die Switches der Aggregationsschicht und der Zugriffsschicht kann die Bereitstellungseffizienz verbessern und den Bereitstellungsaufwand vereinfachen.
Die Core-Layer-Switches schließen die Southbound-Anbindung an den SDN-Controller über die Befehlszeile ab. Anschließend werden die Core-Layer-Switches als Root-Geräte des Management-Subnetzes verwendet, und die Switches unterhalb der Core-Layer-Ebene werden über die DHCP-Methode im SDN-Controller online geschaltet, um Plug-and-Play für die Switches unterhalb der Core-Layer-Ebene zu realisieren.

Wie in der obigen Abbildung gezeigt, läuft der Plug-and-Play-Prozess des Aggregation SwitchA wie folgt ab:
Der Administrator stellt die DHCP-Serverfunktion auf dem Gerät der Core-Schicht bereit (oder es kann sich um ein separates DHCP-Servergerät im Netzwerk handeln), aktiviert die DHCP-Funktion in VLANIF1 und konfiguriert die Option DHCP Option 148, die den NETCONF-Aktivierungsstatus des Geräts, die URL/IP des SDN-Controllers und Informationen zur Portnummer enthält.
Nachdem der unterhalb des Kerns befindliche SwitchA mit einer leeren Konfiguration gestartet wurde, verwendet er standardmäßig VLANIF1, um eine Anfrage an den DHCP-Server zu initiieren.
Da alle Ports des Switches werkseitig standardmäßig zu VLAN 1 hinzugefügt sind, sind der Core-Switch und der Switch, der die Anfrage initiiert, innerhalb von VLAN 1 interoperabel.
Sobald der Core-Switch, der der DHCP-Server ist, die Anfrage erhält, antwortet er SwitchA mit einer DHCP-Nachricht, die die Option 148 enthält.
SwitchA aktiviert die NETCONF-Funktion basierend auf den Inhalten der Option 148 und ruft außerdem die URL/IP- und Portnummerninformationen des SDN-Controllers ab.
SwitchA ruft die URL/IP- und Portnummerninformationen des SDN-Controllers ab und verwendet die URL/IP- und Portnummerninformationen des SDN-Controllers, um die Authentifizierung beim SDN-Controller zu registrieren.
Nachdem SwitchA sich beim SDN-Controller registriert und authentifiziert hat, um online zu gehen, sendet der SDN-Controller die Konfiguration automatisch gemäß der vom Administrator festgelegten Vorkonfiguration (einschließlich der PnP-VLANs) an SwitchA und schließt damit die Inbetriebnahme von SwitchA ab, um Plug-and-Play zu ermöglichen.
PnP VLAN
Im Plug-and-Play-Prozess von Netzwerkgeräten gibt es ein wichtiges Konzept, PnP VLAN, auch selbstverhandelndes Management-VLAN genannt, das sich auf das VLAN bezieht, das vom SDN-Controller verwendet wird, wenn er Switches oder APs nano-verwaltet.
Zunächst verwenden Aggregations-Switches und Access-Switches Funktions-VLAN 1, um die Registrierung beim SDN-Controller online durchzuführen. Um die Zuverlässigkeit des Netzwerks zu verbessern, verwenden Administratoren VLAN 1 im Allgemeinen nicht als Management-VLAN, da VLAN 1 das Standard-VLAN des Switches ist und alle Ports des Switches standardmäßig VLAN 1 hinzugefügt werden. Daher können in VLAN 1 leichter Broadcast-Stürme entstehen und die Dienstkommunikation beeinträchtigen. die Dienstkommunikation beeinträchtigen. Daher müssen der Aggregations-Switch und der Access-Switch, nachdem sie mit VLAN 1 online gegangen sind, gemäß der SDN-Konfiguration automatisch auf das festgelegte Management-VLAN umschalten, und dieses automatisch umgeschaltete Management-VLAN wird als PnP-VLAN bezeichnet.
Im Campusnetzwerk werden zur Vereinfachung der Netzwerkwartung die in kabelgebundenen und drahtlosen Netzwerken verwendeten PnP VLANs in der Regel als unterschiedliche VLANs festgelegt, die jeweils als kabelgebundene PnP VLANs und drahtlose PnP VLANs bezeichnet werden.Die von den Switches verwendeten PnP VLANs werden als kabelgebundene PnP VLANs bezeichnet, und die von den APs verwendeten VLANs werden als drahtlose PnP VLANs bezeichnet.

Der PnP-VLAN-Switching-Prozess ist wie folgt:
Das Aggregationsgerät und das Zugangsgerät registrieren sich online beim SDN-Controller über VLAN 1.
Der SDN-Controller gibt die vorkonfigurierten PnP-VLANs an das Aggregationsgerät und das Zugangsgerät aus.
Das Aggregationsgerät und das Zugangsgerät registrieren sich erneut auf der Leitung unter Verwendung des ausgehandelten PnP-VLAN, um Plug-and-Play zu ermöglichen.





