DE102022133145A1 - Software-Update Reihenfolge mittels Link Layer Discovery Protocol (LLDP) - Google Patents

Software-Update Reihenfolge mittels Link Layer Discovery Protocol (LLDP) Download PDF

Info

Publication number
DE102022133145A1
DE102022133145A1 DE102022133145.8A DE102022133145A DE102022133145A1 DE 102022133145 A1 DE102022133145 A1 DE 102022133145A1 DE 102022133145 A DE102022133145 A DE 102022133145A DE 102022133145 A1 DE102022133145 A1 DE 102022133145A1
Authority
DE
Germany
Prior art keywords
switches
network
until
boot
procedure according
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102022133145.8A
Other languages
English (en)
Inventor
Zbigniew Pelzer
Stephan Kehrer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hirschmann Automation and Control GmbH
Original Assignee
Hirschmann Automation and Control GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hirschmann Automation and Control GmbH filed Critical Hirschmann Automation and Control GmbH
Publication of DE102022133145A1 publication Critical patent/DE102022133145A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/024—Standardisation; Integration using relational databases for representation of network management data, e.g. managing via structured query language [SQL]

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Small-Scale Networks (AREA)

Abstract

Es wird ein Verfahren vorgeschlagen, um die beste Reihenfolge von Software-Updates und/oder von Bootbefehlen an Switchen, zu bestimmten, mit Hilfe dessen die Kollisionen bei der Verteilung der Software-Updates und/oder der Bootbefehle vermieden werden können, sowie der Prozess der Software-Updates und/oder der Bootbefehle zeitliche optimiert werden kann Dazu wird ein Netzwerk verwendet, in welchem eine Updatestation, mehrere Netzwerkteilnehmer und mehrere Switche miteinander kommunizieren können. Es wird nun vorgeschlagen, mittels LLDP Informationen über die Switches in dem Netzwerk zu sammeln und die Entfernung der Switche von der Updatestation durch die gesammelten Informationen zu bestimmen. Die Reihenfolge von Updates und/oder Bootbefehlen an die Switche kann nun durch die Entfernung festgelegt werden.

Description

  • Die vorliegende Erfindung bezieht sich auf ein Verfahren, um die Reihenfolge der Updates von Software-, Firmware-, Programmierbarer Logik- und/oder von Bootbefehlen an Netzwerkgeräten, insbesondere Switchen, zu bestimmten.
  • Switches sind Netzwerkgeräte, die andere Netzwerkgeräte, auch als Netzwerkteilnehmer bezeichnet, miteinander verbinden. Eine feste oder programmierbare Logik innerhalb der Switche sorgt dabei für die Adressierung der Datenpakete, welche zwischen den Netzwerkteilnehmern ausgetauscht werden.
  • Diese programmierbare Logik und/oder Software sollte aus Sicherheitsgründen und/oder für Funktionserweiterungen mit Updates versorgt werden. Hierzu kann es vorkommen, dass ein Software-Update eines Switches in einem Netzwerk deswegen scheitert, weil die Reihenfolge des Updates (oder des anschließenden Boot-Vorgangs) nicht korrekt ist. Dies kommt insbesondere dann vor, wenn viele Geräte im Netzwerk gleichzeitig mit einem Update versorgt werden. Das kann dazu führen, dass ein Switch gebootet wird, der die Boot-Befehlskette unterbricht, bevor die hinter ihm liegenden Switches den gleichen Befehl bekommen.
  • Typischerweise wird hier mit Bootverzögerungen gearbeitet, um das Problem zu beheben. Das ist allerdings nicht immer ausreichend, um Probleme während des Updatevorgangs zu verhindern.
  • Aufgabe der vorliegenden Erfindung es ist daher, die vorgenannten Probleme zu beheben und ein sicheres Verfahren für Updates von Netzwerkgeräten, insbesondere von Switchen, bereitzustellen.
  • Diese Aufgabe wird mit den Merkmalen des Anspruchs gelöst.
  • Dazu wird die Reihenfolge der Netzwerkgeräte, insbesondere der Switches, mit LLDP ermittelt. Die Boot-Befehle werden dann in der korrekten Reihenfolge geschickt. Das führt dazu, dass die Netzwerkgeräte, insbesondere die Switches, zum Beispiel in der Linie in der Reihenfolge ihrer Entfernung von der Station (zum Beispiel ein dafür bestimmtes Netzwerkgerät oder auch eine Metzmangementstation), die die Updates verteilt, neu gebootet werden. Hierbei wird zum Beispiel der am weitesten entfernte zuerst neu gebootet, dann der am zweit weitesten entfernte als nächstes, usw.
  • LLDP ist ein Layer-2-Protokoll, welches gemäß IEEE-802-1AB genormt ist. Durch dieses Protokoll können Informationen zwischen benachbarten Netzwerkteilnehmern und Netzwerkkomponenten ausgetauscht werden. Das Protokoll arbeitet unabhängig von anderen Protokollen. Es versendet Informationen über sich selbst und empfängt von anderen Teilnehmern gesendete Informationen. LLDP benötigt somit keine Kommunikation mit anderen Geräten.
  • Im Folgenden wird der Einfachheit halber das Verfahren anhand von Switches beschrieben, ist aber nicht auf diese Gattung von Netzwerkgeräten beschränkt.
  • Bevorzugt wird vorgeschlagen, den am weitesten entfernten Switch zuerst mit der neuen Software und/oder dem Befehl zum Rebooten zu versorgen, dann den am zweitweitesten entfernte, und so weiter. Bei der Einhaltung dieser hier vorgeschlagenen Reihenfolge wird garantiert, dass das jeweilige nächste Software-Update (oder Boot-Befehl) überhaupt sein Ziel erreicht (das bedeutet, dass der mit einem Software-Update zu versorgende oder zu bootende Switch nicht hinter einem gerade bootenden und damit nicht erreichbaren Switch liegt).
  • Das Verfahren nach der Erfindung ist beispielhaft in der Figur dargestellt.

Claims (15)

  1. Verfahren, um die Reihenfolge von Software-Updates und/oder von Bootbefehlen an Netzwerkteilnehmern, vorzugsweise Switchen, zu bestimmten, wobei in einem Netzwerk eine Updatestation, mehrere Netzwerkteilnehmer und zumindest ein Switch, vorzugsweise mehrere Switche, miteinander kommunizieren können, dadurch gekennzeichnet, dass mittels LLDP Informationen über die Netzgeräte, vorzugsweise die Switches, in dem Netzwerk gesammelt werden, dass die Entfernung zumindest einen Switches, vorzugsweise der mehreren Switche, von der Updatestation durch die Informationen bestimmt wird und dass die Reihenfolge von Updates und/oder Bootbefehlen an die Netzwerkteilnehmer, vorzugsweise die mehreren Switche, durch die Entfernung festgelegt wird.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zunächst diejenigen Switche zuerst mit Updates und/oder Bootbefehlen versorgt werden, welche die größte Entfernung zur Updatestation aufweisen.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Reihenfolge von Updates und/oder Bootbefehlen von dem Switch mit der größten Entfernung zu dem Switch mit der geringsten Entfernung zur Updatestation festgelegt wird.
  4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass auf Management Information Bases (MIBs) der Switche zugegriffen wird und über diese Zugriffe die Entfernung zu den einzelnen Switchen festgelegt wird.
  5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass der Zugriff auf die MIBs über die Updatestation durchgeführt wird.
  6. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass der Zugriff auf die MIBs über einen der Netzwerkteilnehmer durchgeführt wird.
  7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Switche LLDP-fähig sind.
  8. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass zu den Switchen benachbarte Netzwerkteilnehmer LLDP-fähig sind.
  9. Verfahren nach einem der Ansprüche 4 bis 8, dadurch gekennzeichnet, dass der Zugriff auf die MIBs über SNMP Befehle durchgeführt wird.
  10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass zunächst Updates auf allen Switchen gleichzeitig verteilt werden und lediglich die Updatereihenfolge durch die Entfernung festgelegt wird.
  11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass ähnlich wie die Switche auch Router von dem vorgeschlagenen Verfahren zur Verteilung der Software-Updates und/oder Boot-Befehle profitieren können.
  12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass die Updatestation als eigenständiger Netzwerkteilnehmer ausgeführt ist.
  13. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass die Updatestation in einem der Switche integriert ist.
  14. Verfahren nach einem der Ansprüche 1 bis 13, bei dem eine Bootstation, die die Software-Updates der anderen Switches veranlasst (bzw. die Boot-Befehle verschickt) ein beliebiges Gerät im Netzwerk, wie z.B. ein PC, ein Switch oder ein Router sein kann.
  15. Verfahren nach einem der Ansprüche 1 bis 14 bei dem die Bootstation dasjenige Gerät ist, das die Software-Updates verteilt oder Boot-Befehle verschickt, wobei diese Funktion der Bootstation auch ein anderes Gerät (Switch, Router oder dergleichen) im Netz bei Bedarf übernehmen kann.
DE102022133145.8A 2021-12-22 2022-12-13 Software-Update Reihenfolge mittels Link Layer Discovery Protocol (LLDP) Pending DE102022133145A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021134250.3 2021-12-22
DE102021134250 2021-12-22

Publications (1)

Publication Number Publication Date
DE102022133145A1 true DE102022133145A1 (de) 2023-06-22

Family

ID=84785335

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022133145.8A Pending DE102022133145A1 (de) 2021-12-22 2022-12-13 Software-Update Reihenfolge mittels Link Layer Discovery Protocol (LLDP)

Country Status (2)

Country Link
DE (1) DE102022133145A1 (de)
WO (1) WO2023117593A1 (de)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10545753B2 (en) * 2015-04-21 2020-01-28 Arista Networks, Inc. System and method of updating a network element
CN113572636A (zh) * 2021-07-13 2021-10-29 武汉迈威通信股份有限公司 环网拓扑结构中交换机的批量升级方法及环网拓扑结构

Also Published As

Publication number Publication date
WO2023117593A1 (de) 2023-06-29

Similar Documents

Publication Publication Date Title
DE102005032692B4 (de) Anordnung und Verfahren zur Konfiguration von Schnittstellen einer drahtlosen Verbindung zur Datenübertragung
EP1309920B1 (de) Adressvergabeverfahren für mindestens einen neu an ein bussystem angeschlossenen busteilnehmer
DE69818232T2 (de) Verfahren und system zur verhinderung des herunterladens und ausführens von ausführbaren objekten
DE102020113347A1 (de) Ausführung von containerisierten prozessen innerhalb der beschränkungen der verfügbaren host-knoten
DE60305998T2 (de) Einrichtung, Gateway und Verfahren zum Laden von Information zwischen on-board Ausrüstungen eines Flugzeugs und off-board Ladeeinrichtung
DE10215720A1 (de) Datenbus-Netzwerk
DE102021206755A1 (de) Verwalten von Schlüsseln für eine sichere Kommunikation zwischen Kommunikationsteilnehmern über einen getrennten Kommunikationskanal
DE102022133145A1 (de) Software-Update Reihenfolge mittels Link Layer Discovery Protocol (LLDP)
DE19510247A1 (de) Verfahren zur Datenübertragung
DE112013006756T5 (de) Kommunikations-, Steuervorrichtung und Programm
EP3705993B1 (de) System und verfahren zum auffinden und identifizieren von rechenknoten in einem netzwerk
EP3659322B1 (de) Softwareverteilungsverfahren, und softwareverteilungssystem für ein spurgebundenes fahrzeug
EP1642207A1 (de) Zuordnung von stationsadressen zu kommunikationsteilnehmern in einem bussystem
DE102004017698A1 (de) SCADA-System
LU101163B1 (de) Verfahren und Vorrichtungen für eine Lastzuweisung und Überwachung für eine zuzuweisende versorgungssicherheitskritische Ressource in einem Netzwerk
EP3725061B1 (de) Verfahren zum betreiben eines kommunikationssystems sowie kommunikationssystem
WO2024068460A1 (de) Backupverfahren von für an ein netzwerk angeschaltete netzwerkgeräte und hierzu eingerichtetes netzwerkgerät
DE202023101868U1 (de) Konfigurationssystem für ein Datennetzwerk sowie Datennetzwerk
WO2023117636A1 (de) Automatisches software update
DE102014207800B4 (de) Verfahren und Vorrichtung zum Reduzieren einer Netzwerklast bei Multicast- und Broadcast-Kommunikation
EP4091297A1 (de) Redundante speicherung der konfiguration von netzwerkgeräten unter einbeziehung von nachbarschaftsbeziehungen
DE102020134176A1 (de) Kommunikationssystem für eine landwirtschaftliche maschine und verfahren zur herstellung einer landwirtschaftlichen maschine
DE102021133657A1 (de) Verfahren und System zum Absichern des Austausches von Daten in einem Netzwerksystem für industrielle Steuerungen
DE102017220065A1 (de) Vorrichtung und Verfahren zur drahtlosen Kommunikation zwischen Endgeräten
CH681410A5 (de)

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0041000000

Ipc: H04L0041081300