Verfahren zur Bereitstellung redundanter Relay-, insbesondere Routing Funktion, System, Computerprogramm und computerlesba res Medium

Die Erfindung betrifft ein Verfahren zur Bereitstellung re dundanter Relay-, insbesondere Routing-Funktion in einem ins besondere industriellen Netzwerk, in dem ein überlagertes Teilnetzwerk über zwei oder mehr redundante Relays, insbeson dere Router mit einem unterlagerten Teilnetzwerk verbunden ist, bei dem von den redundanten Relays immer maximal eines in einem aktiven Modus betrieben wird, während sich das oder die verbleibenden Relays im Standby-Modus befinden, wobei je des redundante Relay ein Relay-Redundanz-Modul zur Steuerung des Relay-Modus aufweist, und für den Fall, dass das momentan aktive Relay ausfällt, das oder genau eines der verbleibenden redundanten Relays von dessen Relay-Redundanz-Modul aktiviert wird .

Darüber hinaus betrifft die Erfindung ein System zur Bereit stellung redundanter Relay-, insbesondere Routing-Funktion umfassend zwei oder mehr redundante Relays, insbesondere Rou ter, die ein überlagertes Teilnetzwerk mit einem unterlager ten Teilnetzwerk verbinden oder verbinden können, wobei jedes redundante Relay ein Relay-Redundanz-Modul aufweist, und wo bei das System derart ausgebildet und/oder eingerichtet ist, dass von den redundanten Relays immer maximal eines in einem aktiven Modus betrieben wird, während sich das oder die ver bleibenden Relays im Standby-Modus befinden, und für den Fall, dass das momentan aktive Relay ausfällt, das oder genau eines der verbleibenden redundanten Relays von dessen Relay- Redundanz-Modul aktiviert wird. Weiterhin betrifft die Erfin dung ein Computerprogramm und ein computerlesbares Medium.

Im industriellen Bereich, insbesondere in hierarchischen Au tomatisierungsnetzen, kommen IRnb-Router sowie NAT64-Router zum Einsatz. Durch Router können relativ einfach so genannte „Netztrennungen" erreicht werden, durch welche beispielsweise eine Kommunikationslast in Folge von Broadcast-Nachrichten eingedämmt bleibt. Das IP-Routing ist essentiell, um trotz der Netztrennung eine Ende-zu-Ende-Konnektivität auf IP-Ebene zu ermöglichen.

Um zu verhindern, dass das mit Netztrennungen einhergehende IP-Routing umfangreiches IT-Knowhow beim Anwender erfordert, können autokonfigurierende Router zum Einsatz kommen.

Insbesondere für einen industriellen Einsatz ist neben einer möglichst weitreichenden automatischen Konfiguration auch ei ne möglichst hohe Verfügbarkeit, gerade von Infrastrukturkom ponenten, wie etwa Relays, insbesondere IPv6- und NAT64-Rou- tern, wichtig. Eine hohe Verfügbarkeit kann prinzipiell durch Bereitstellung von Ersatzrelays bzw. Ersatzroutern, welche für ein ausgefallenes Gerät/eine ausgefalle Funktion überneh men bzw. "einspringen" , erzielt werden.

Sowohl bei IPv4 als auch bei IPv6 ist der eigentliche Rou ting-Prozess zustandslos. Für einen zustandslosen Fall kann vergleichsweise einfach von einem ausgefallenen Router auf einen Ersatzrouter umgeschaltet werden. Dies insbesondere oh ne dass der Ersatzrouter zunächst auf den Zustand des ausge fallenen Routers aufsynchronisiert sein muss.

Die Anmelderin hat insbesondere für den Kontext industrieller Automatisierungsanwendungen eine Reihe von Autokonfigurati onsmechanismen entwickelt. Beispielhaft sei hier auf die EP 2 940 972 Al, die EP 2 955 904 Bl, EP 3 076 636 Bl,

EP 3 062 490 Bl und EP 3 091 714 Bl verwiesen.

Durch die Autokonfiguration kann ein wesentliches zustandsbe haftetes Element hinzukommen: die automatische Präfix-Konfi guration, also die automatische Konfiguration des Subnetzban des . Den standardisierten, funktionalen „Unterbau" von autokonfi gurierenden IPv6- und NAT64-Routern kann dabei die so genann te „Präfix-Delegation" bilden (siehe insbesondere RFC 3633, wobei RFC für „Request For Comments" steht, und der RFC 3633 unter https://tools.ietf.org/html/rfc3633 abrufbar ist).

Die Präfix-Delegation basiert technisch auf DHCPv6, insbeson dere entsprechend RFC 3315, und bevorzugt auf der so genann ten „zustandsbehafteten" („stateful") Variante von DHCPv6. Findet eine Präfix-Delegation statt, wird in die eigentlich zustandslosen Relays, insbesondere IPv6- bzw. NAT64-Router Zustand eingebracht, der insbesondere für eine Autokonfigura tion erforderlich ist.

Im industriellen Bereich besteht Bedarf an einer hohen Ver fügbarkeit auch für den Fall, dass automatisch konfigurieren de Relays, insbesondere Router zum Einsatz kommen.

Aus dem Stand der Technik sind verschiedene Redundanzmecha nismen vorbekannt.

Für IP-Router existiert das so genannte Common Address Redun- dancy Protocol (CARP) sowie das Virtual Router Redundancy Protocol (VRRP) (siehe unter anderem RFC 5798) . Demgemäß er hält eine Gruppe von Routern eine gemeinsame virtuelle IP-Ad resse und oftmals auch eine gemeinsame virtuelle MAC-Adresse. Dabei sind IP- und MAC-Adresse nur auf dem jeweils aktiven Router geschaltet. Fällt der aktive Router aus, wird ein an derer Router aktiviert und reklamiert die virtuellen IP- und MAC-Adresse für sich. In Hinblick auf IPv6 hat dieses Vorge hen den Vorteil, dass nicht erst die „Neighbour Unreachabili- ty Detection" (siehe Abschnitt 7.3 in RFC 4861) ansprechen muss, damit ein einzelner IPv6-Knoten vom ausgefallenen IPv6- Router auf einen Ersatz-Router umschaltet. Vielmehr erfolgt die Umschaltung für die IPv6-Knoten unsichtbar, da sowohl die IPv6-Adresse des Routers als auch dessen MAC-Adresse unverän dert bleibt. Auch DHCPv6 kennt einen Redundanzmechanismus (siehe insbeson dere die RFCs 6853 "DHCPv6 Redundancy Deployment Considerati- ons" und 7031 "DHCPv6 Failover Requirements " ) , jedoch nur ei nen für die DHCPv6-Server, da das Augenmerk auf der Serverre dundanz liegt. Dies dürfte nach Auffassung der Anmelderin insbesondere dem ursprünglichen Einsatzfeld des Büro- bzw. Heimbereiches geschuldet sein, da in diesen automatisch IP- Adressen zugewiesen werden sollen, wobei irrelevant ist, wel che es sind. Fällt ein Endgerät aus, muss kein im Standby wartendes Ersatzgerät möglichst rasch die Aufgaben des ausge fallenen Gerätes übernehmen. Dies insbesondere, da in der Re gel keine weiteren Geräte von beispielsweise einem Heim-PC abhängig sind.

Demgegenüber sind von einem Router/NAT-Gerät in aller Regel eine Reihe von weiteren Geräten abhängig, sodass ein Ausfall hier eine größere Wirkung zeigt.

Schließlich ist der Anmelderin bekannt, dass im Unternehmens bereich IP- und NAT-Router oftmals von IT-Fachleuten statisch konfiguriert werden. Dabei ist der Anwender insbesondere in Form eines IT-Experten dafür zuständig, dass bei Ausfall ei nes aktiven Routers ein Ersatzgerät wieder für den Redundanz betrieb konfiguriert wird. Dies ist mit nicht unerheblichem Personal- und Zeitaufwand verbunden.

Aus der WO 2018/006684 Al gehen ein Nachrichtenverarbeitungs verfahren und -gerät sowie ein Router hervor. Im Rahmen des Verfahrens kommen ein Haupt- und ein Backup-Router zum Ein satz, die sich in einer Haupt- und Backupbeziehung befinden. Es wird das Problem gelöst, dass in einem Doppel-Maschinen- Standbynetzwerk Unsicherheit bezüglich einer von einem Nutzer erhaltenen Adresse besteht.

Aus der CN 104158694 gehen ferner ein Hot-Standby-Verfahren und eine zugehörige Vorrichtung für einen DHCPv6-Server her vor. Dabei empfängt ein Host-DHCPv6-Server eine Dienstanfor derung, die eine von einem DHCPv6-Client gesendete VDUID um- fasst, ermittelt, ob die VDUID in einer gespeicherten DUID- verlinkten-Liste gespeichert ist oder nicht, und stellt, wenn dem so ist, einen Business-Service für den DHCPv6-Client be reit. Der Host-DHCPv6-Server informiert einen Standby-DHCPv6- Server im Fehlerfall. Der Standby-DHCPv6-Server schaltet den Zustand der VDUID von einem nicht verfügbaren in einen ver fügbaren Zustand um und stellt einen Business-Service für den DHCPv6-Client bereit.

Im industriellen Bereich besteht Bedarf an einer hohen Ver fügbarkeit auch automatisch konfigurierender Relays, insbe sondere Router.

Es ist daher eine Aufgabe der vorliegenden Erfindung, ein Verfahren der eingangs genannten Art anzugeben, welches eine erhöhte Ausfallsicherheit auch für Relays bzw. IPv6- bzw. NAT64-Router mit zustandsbehafteter Autokonfiguration ermög licht. Darüber hinaus ist es eine Aufgabe der vorliegenden Erfindung, ein System zur Durchführung eines solchen Verfah rens anzugeben.

Bei einem Verfahren der eingangsgenannten Art wird diese Auf gabe dadurch gelöst, dass die redundanten Relays, insbesonde re Router jeweils einen DHCPv6-Client zur Abwicklung einer Präfix-Delegation, insbesondere gemäß RFC 3633, umfassen, wo bei immer nur der DHCPv6-Client des gerade aktiven Relays die Präfix-Delegation, insbesondere gemäß RFC 3633, abwickelt, und die redundanten Relays jeweils ein Relay-Kontroll-Modul aufweisen, dem das Relay-Redundanz-Modul des jeweiligen Re lays den momentanen Relay-Modus signalisiert, und das Relay- Kontroll-Modul des jeweils aktiven Relays eine virtuelle DUID seines DHCPv6-Clients und/oder ein dem aktiven Relay dele giertes Präfix auf das oder jedes im Standby-Modus befindli che Relay, insbesondere dessen oder deren Relay-Kontroll-Mo- dule, synchronisiert, und für den Fall, dass das momentan ak tive Relay ausfällt, dasRelay-Kontroll-Modul des in Reaktion auf den Ausfall aktivierten Relays dessen DHCPv6-Client star tet und der DHCPv6-Client auf die über die Synchronisation erhaltene DUID und/oder auf das über die Synchronisation er haltene Präfix zurückgreift.

Bei einem System der eingangs genannten Art wird die Aufgabe ferner dadurch gelöst, dass die redundanten Relays, insbeson dere Router jeweils einen DHCPv6-Client zur Abwicklung einer Präfix-Delegation, insbesondere gemäß RFC 3633, und ein Re- lay-Kontroll-Modul umfassen, und das System derart ausgebil det und/oder eingerichtet ist, dass immer nur der DHCPv6- Client des gerade aktiven Relays die Präfix-Delegation, ins besondere gemäß RFC 3633, abwickelt, und dass das Relay-Re- dundanz-Modul des jeweiligen Relays dem Relay-Kontroll-Modul des jeweiligen Relays den momentanen Relay-Modus signali siert, und das Relay-Kontroll-Modul des jeweils aktiven Re lays eine virtuelle DUID seines DHCPv6-Clients und/oder ein dem aktiven Relay delegiertes Präfix auf das oder jedes im Standby-Modus befindliche Relay, insbesondere dessen oder de ren Relay-Kontroll-Module, synchronisiert, und für den Fall, dass das momentan aktive Relay ausfällt, das Relay-Kontroll- Modul des in Reaktion auf den Ausfall aktivierten Relays des sen DHCPv6-Client startet und der DHCPv6-Client auf die über die Synchronisation erhaltene DUID und/oder auf das über die Synchronisation erhaltene Präfix zurückgreift. Das erfin dungsgemäße System ist zur Durchführung des erfindungsgemäßen Verfahrens ausgebildet und/oder eingerichtet. Das erfindungs gemäße System ist zur Durchführung des erfindungsgemäßen Ver fahrens ausgebildet und/oder eingerichtet.

Der Grundgedanke der vorliegenden Erfindung besteht mit ande ren Worten darin, einen neuartigen Synchronisationsmechanis mus für die Präfix-Delegation von DHCPv6-Clients bereitzu stellen. Dies macht es möglich, Autokonfigurationsmechanis men, welche auf der Präfix-Delegation aufbauen bzw. diese nutzen, auch auf redundanten Relays, insbesondere Routern einzusetzen, wodurch die Notwendigkeit für eine starre bzw. statische Konfiguration durch einen IT-Experten, der beim Einrichten der Relays bzw. Router die auszusendenden IPv6- Präfixe statisch einstellt und demgemäß bei einem Ausfall ein Ersatzgerät erneut manuell entsprechend einstellen muss, ent fällt. Mit der bisherigen, statischen Konfiguration konnte die automatische Präfix-Delegation per DHCPv6 nicht im Kon text eines redundanten Relays, insbesondere Routers, genutzt werden, was durch die vorliegende Erfindung möglich wird.

Die Erfindung schlägt dabei konkret einen unterlagerten Re dundanzmechanismus vor, der insbesondere auf bekannten Mecha nismen für IP-Router, insbesondere CARP bzw. VRRP aufbaut, jedoch davon unabhängig ist und insbesondere keine Erweite rung dieser bekannten Mechanismen darstellt. Erfindungsgemäß wird vielmehr eine unabhängige funktionale Redundanzschicht oberhalb der IP-/MAC-Redundanzschicht vorgeschlagen. Es wird insbesondere die Autokonfigurations-Steuerungsebene („control plane") um einen Redundanzmechanismus erweitert.

Bei einer MAC-Redundanz wird das gleiche Paket auf mehreren Pfaden gleichzeitig im Netz übertragen (sogenannte „Doppe lung") und dann beim Empfänger die Doubletten innerhalb der MAC-Schicht erkannt und unterdrückt, so dass höheren Schich ten, wie die IP-Schicht, keine Doubletten mehr sehen. Eine solche MAC-Redundanz wird bei der erfindungsgemäßen Vorge hensweise nicht benötigt. Ebenso wird keinerlei IP-Redundanz benötigt, in dem Sinne, dass IP-Pakete gedoppelt und über verschiedene Wege versendet werden, wobei die empfangenden IP-Stacks dann Doubletten wieder entfernen müssten, bevor die IP-Daten zu den Anwendungen gereicht werden. Die Erfindung benutzt hingegen eine IP-Redundanz in dem Sinne, dass keine Doppelung stattfinden, sondern ein defekter Netzbereich (z.B. ein defektes Relay, insbesondere ein defekter Router oder dessen Verkabelung) umgangen wird, also ganz im ursprüngli chen Sinne der IP-Architektur . Das Umgehen erfolgt insbeson dere durch Umkonfiguration von Routen, wobei bekannte Mecha nismen genutzt werden können, bevorzugt Router Advertise ments, Routing-Protokolle wie OSPF, RIP, usw..

Die Erfindung schlägt einen Mechanismus vor, mit dem - ausge hend von vorhandenen Standard- ( Software- ) Komponenten die ei- gentliche Redundanz-Funktion in Bezug auf die Präfix-Delega tion technisch gelöst werden kann bzw. wird.

Durch die erfindungsgemäße Vorgehensweise wird es möglich, dass sich redundante Relays, insbesondere Router, neben einer virtuellen MAC- und IP-Adresse auch eine DHCPv6 Client DUID teilen, also einen sogenannten DHCP Unique Identifier. Diese Client DUID identifiziert das logische, aktive Relay, insbe sondere den logischen, aktiven Router, gegenüber der überla gerten Ebene, die das Präfix delegiert. Der Status einer DHCPv6 Präfix Delegation wird von einem aktiven Relay, insbe sondere Router auf einen oder mehrere Ersatzrelays , insbeson dere -router synchronisiert. Bei einer Redundanz-Umschaltung gemäß der vorliegenden Erfindung wird der Zustand mit auf das neue Relay, insbesondere den neuen Router, also das Ersatzre- lay bzw. den den Ersatzrouter übernommen und somit auch die Client DUID "umgezogen".

Fällt ein aktives Relay, insbesondere ein aktiver Router aus, kann ein Ersatzrelay, insbesondere Ersatzrouter übernehmen, wobei der Wechsel - mit Ausnahme eines etwaigen vorrüberge- henden Paketverlustes - für am unterlagerten, Downstream-Netz angeschlossene IPv6-Knoten unsichtbar ist. Insbesondere blei ben die IPv6-Adresse und MAC des autokonfigurierenden Relays bzw. Routers konstant. Gleichzeitig bleibt auch aus Sicht des überlagerten, delegierenden Routers die Identität des Relays bzw. Routers, insbesondere IRnb-Routers, gleich. Bei IPv6 ist die Identität von Clients allein an deren DUID gekoppelt und nicht an deren MAC-Adresse.

So wird es möglich, dass auch Automatisierungsanwender den Mehrwert der Redundanz ihrer Netzknoten erhalten, ohne dass sie hierfür spezielles IT-Know-How erwerben oder IT-Personal einbinden müssen.

Hierfür weisen die zwei - oder auch mehr - redundanten Re lays, insbesondere Router erfindungsgemäß jeweils ein Relay- Kontroll-Modul auf, welches einerseits dafür sorgt, dass das momentan aktive Relay den Status der DHCPv6 Präfix Delegation auf den oder die weiteren, im Standby-Modus befindlichen Re- lays, insbesondere deren Relay-Kontroll-Module, synchroni siert wird, damit er bei einem Ausfall des aktiven Relays, insbesondere Routers dort zur Verfügung steht. Der Zustand des DHCPV6 Clients des (jeweils) aktiven Relays, insbesondere Routers kann beispielsweise in einer Datei im Dateisystem des aktiven Relays, insbesondere Routers gespeichert sein bzw. werden .

Die Synchronisation der virtuellen DUID und/oder des dele gierten Präfixes kann beispielsweise erfolgen, indem das Re- lay-Kontroll-Modul des jeweils aktiven Relays die virtuelle DUID und/oder das delegierte Präfix dem Relay-Kontroll-Modul des oder jeden Relays im Standby-Modus bekannt gibt. Das er findungsgemäße System kann entsprechend in vorteilhafter Wei terbildung derart ausgebildet/oder eingerichtet sein, dass die Synchronisation der virtuellen DUID und/oder des dele gierten Präfixes erfolgt, indem das Relay-Kontroll-Modul des jeweils aktiven Relays die virtuelle DUID und/oder das dele gierte Präfix dem Relay-Kontroll-Modul des oder jedem Relays im Standby-Modus bekannt gibt. Die Synchronisation der virtu ellen DUID und/oder des digitalen Präfixes erfolgt bevorzugt per Protokoll. Das erfindungsgemäße System kann entsprechend in Weiterbildung derart ausgebildet und/oder eingerichtet sein, dass die Synchronisation der DUID und/oder des dele gierten Präfixes per Protokoll erfolgt. Beispielsweise kann eine "Secure Remote Copy" der Zustandsdaten in Form einer Da tei im Dateisystem des aktiven Relays bzw. Routers in das Da teisystem des bzw. der Relays bzw. Router (s) im Standby-Modus erfolgen .

Dass sich ein Relay, insbesondere Router, im aktiven Zustand befindet, bedeutet insbesondere, dass dieses bzw. dieser die Funktion übernimmt, in an sich bekannter Weise Pakete aus dem überlagerten in das unterlagerte (Teil-) Netzwerk weiterzulei ten, während der oder die Relays, insbesondere Router im pas siven bzw. Standby-Modus dies nicht tun, sondern nur bereit- stehen und „warten", um im Falle eines Ausfalls des aktiven Relays bzw. Routers für diesen übernehmen zu können.

Ein Relay- bzw. Router-Ausfall kann beispielsweise auf einen Ausfall der Geräte-Hardware und/oder einen Absturz der Relay- bzw. Router-Software und/oder einen Ausfall der Stromversor gung und/oder einen Defekt in der Netzverkabelung zurückzu führen bzw. dadurch bedingt sein.

Unter einem Relay im Sinne der vorliegenden Anmeldung ist insbesondere eine Funktion der Schicht n, die Daten, die sie von einer Entität empfangen hat, an eine andere Entität wei terleitet, zu verstehen, bevorzugt im Sinne von ISO/IEC7498- 1:1994, Klausel 5.3.1.6.

Ein Relay, insbesondere ein Relay der Schicht 3, kann in Form eines Routers gegeben sein.

Unter einem Router kann insbesondere jede Funktion bzw. jeder Knoten (bzw. jedes Gerät) zu verstehen sein, welcher Pakete weiterleitet, die nicht explizit an ihn adressiert sind, be vorzugt im Sinne von RFC 4861.

Bei einem Relay, insbesondere Router, kann es sich beispiels weise um ein (separates) Gerät bzw. eine (separate) Hardware- Komponente handeln, welche ausgebildet und/oder eingerichtet ist, diese Funktion zu erfüllen. Selbstverständlich ist es auch möglich, dass ein Relay als "Software-Relay" bzw. "Soft- Relay" bzw. ein Router als "Software-Router" bzw. "Soft-Rou- ter" vorliegt, etwa in Form eines Computerprogrammes bzw. ei ner Computerprogramm-Sammlung, die auf einer zu dessen/deren Ausführung ausgebildeten Einrichtung, etwa einem PC oder ei ner anderen Recheneinrichtung oder einem beliebigen anderen Gerät, abgelegt ist. Ein Relay bzw. Router bzw. die Relay- oder Router-Funktion kann beispielsweise auch in eine Steue rung, etwa eine speicherprogrammierbare Steuerung (SPS) eines Automatisierungssystems oder in ein anderes Gerät integriert sein, dies sowohl in Form von Hardware- als auch Software. Unter den Begriff Relay bzw. Router im Sinne der vorliegenden Anmeldung fallen sämtliche der vorgenannten Möglichkeiten, insbesondere auch "Soft-Relays"/"Soft-Router" sowie Geräte, die eigentlich andere Funktionen ausführen bzw. einem anderen Zweck dienen, aber auch eine Relay- bzw. Router-Funktion übernehmen, also insbesondere auch Daten weiterleiten, die nicht explizit an sie adressiert sind. Zum Beispiel kann auch ein Automatisierungsgerät, etwa eine insbesondere speicher programmierbare Steuerung, mit Relay- bzw. Router-Funktion als Relay bzw. Router gemäß der vorliegenden Erfindung zu er achten sein, bzw., wenn in diese eine separate Einrichtung, die entsprechend ausgebildet und/oder eingerichtet ist, inte griert ist, umfasst eine solche Steuerung ein Relay bzw. ei nen Router im Sinne der vorliegenden Erfindung.

Üblicherweise hat ein Relay bzw. Router wenigstens ein Up- stream-Interface und wenigstens ein Downstream-Interface . Es kann aber auch sein, dass ein Relay bzw. Router nur ein ein ziges (physisches) Interface aufweist, und die Unterscheidung zwischen Up- und Downstream allein Software-basiert erfolgt. Als Interface kann ein Port eines Relays bzw. Routers dienen.

Bei einem Upstream-Interface, also einer Upstream-Schnitt- stelle eines Relays bzw. Routers handelt es sich insbesondere um ein Interface, welches in Richtung wenigstens eines über lagerten (Teil-) Netzes bzw. Subnetzes und/oder Relays bzw. Routers zeigt. Ein Downstream-Interface, also eine Down- stream-Schnittstelle, ist insbesondere ein solches, welches in Richtung wenigstens eines unterlagerten (Teil-) Netzes bzw. Subnetzes zeigt.

Insbesondere für den Fall, dass die redundanten Relays in Form von Routern gegeben sind, umfassen diese neben dem Re- lay-Redundanz- und dem Relay-Kontroll-Modul , die im Falle ei nes Routers auch als Router-Redundanz- und Router-Kontroll- Module bezeichnet werden können, weiterhin zweckmäßiger Weise jeweils ein Router-Advertisement-Modul , mittels dem Router Advertisement Nachrichten in dem unterlagerten Netzwerk be- kanntgegeben werden können. Die Router-Advertisement-Module sind bevorzugt für das korrekte Abwickeln des Router-Adver- tisement-Protokolls ausgebildet und/oder eingerichtet.

Die Router-Advertisement-Module können jeweils eine Kombina tion von Hard- und Software umfassen oder durch eine solche gebildet werden oder auch rein Software- oder rein Hardware implementiert sein. Die Router-Advertisement-Module können beispielsweise jeweils einen Router-Advertisement Daemon (RAD oder radvd) umfassen oder durch einen solchen gegeben sein, ggf. in Kombination mit geeigneter Hardware.

Auch die Relay- bzw. Router-Kontroll-Module können jeweils rein Software- oder auch rein Hardware-implementiert sein, bzw. eine Kombination von Software und insbesondere speziell für diese vorgesehener Hardware umfassen.

Die Relay- bzw. Router-Kontroll-Module übernehmen - neben der Zustands-Synchronisation im Falle des aktiven Routers - das korrekte Orchestrieren der beteiligten DHCPv6-Clients und insbesondere Router-Advertisement-Module .

Wird dem Relay-Kontroll-Modul eines redundanten Relays insbe sondere von dem Relay--Redundanz-Modul dieses Relays gemel det, dass das Relay in den aktiven Zustand überführt wurde, aktiviert das Relay-Kontroll-Modul den DHCPv6-Client und - vor allem in dem Falle, dass redundanten Relays in Form von redundanten Routern vorliegen - insbesondere das Router Ad vertisement Modul.

Das Router-Advertisement-Modul eines Routers, der (jeweils) in Reaktion auf den Ausfall eines zuvor aktiven Routers in den aktiven Zustand überführten wird bzw. wurde, hält bevor zugt das über die Synchronisation erhaltene Präfix im unter lagerten Netzwerk aktiv, gibt dieses Präfix insbesondere an dem unterlagerten Netzwerk angeschlossenen IPv6-Teilnehmern, bevorzugt gemäß RFC 4861, bekannt. Das Relay- bzw. Router-Kontroll-Modul des oder der verblei benden, momentan nicht aktiven sondern im Standby-Modus be findlichen redundanten Relays bzw. Router hingegen deakti viert deren DHCPv6-Clients und insbesondere deren Router Ad vertisement Module und/oder hält diese, solange der oder die Relays bzw. Router nicht aktiv sind, deaktiviert.

Bevorzugt wickelt nur das jeweils aktive redundante Relay, insbesondere nur der jeweils aktive redundante Router die Präfix-Delegation ab, während die DHCPv6-Clients der verblei benden redundanten Relays bzw. Router bevorzugt in einem Standby-Modus bzw. deaktiviert sind und keine Präfix- Delegation abwickeln.

Die Rolle der Relays, insbesondere Routers wird erfindungsge mäß über ein Relay-, insbesondere Router-Redundanz-Modul ge steuert, das ebenfalls jedes der redundanten Relays, insbe sondere jeder der redundanten Router aufweist. Die Relay-Re- dundanz-Module können - genau wie die Relay-Kontroll-Module und Router-Advertisement-Module - jeweils rein Software- oder auch rein Hardware-implementiert sein, bzw. eine Kombination von Software und insbesondere speziell für diese vorgesehener Hardware umfassen.

Die Relay-, insbesondere Router-Redundanz-Module sind in be vorzugter Ausgestaltung ausgebildet und/oder eingerichtet, um das Common Address Redundancy Protocol und/oder das Virtual Router Redundancy Protokol, insbesondere gemäß RFC 5798, aus zuführen, was sich bewährt hat.

In weiterer Ausführungsform kann vorgesehen sein, dass zu sätzlich dazu, dass das (jeweils) in Reaktion auf den Ausfall eines zuvor aktiven Relays (neu) aktivierte Relay auf den synchronisierten Zustand zurückgreift, dieses das über die Synchronisation erhaltene delegierte Präfix bei einem überla gerten, insbesondere dem Prüfix-delegierenden Router, vali diert. Das erfindungsgemäße System ist in bevorzugter Ausge staltung entsprechend ausgebildet und/oder eingerichtet. Zweckmäßiger Weise ist oder wird auf jedem redundanten Relay, insbesondere Router die gleiche virtuelle IP-Adresse und/oder gleiche virtuelle MAC-Adresse hinterlegt, und ist oder wird die virtuelle IP-Adresse und/oder virtuelle MAC-Adresse immer nur auf dem im aktiven Modus befindlichen redundanten Relay, insbesondere Router aktiv geschaltet. Das erfindungsgemäße System ist bevorzugt entsprechend ausgestaltet und/oder ein gerichtet .

Wird in Reaktion auf den Ausfall eines der redundanten Re- lays, insbesondere Routers, ein anderes Relay, insbesondere ein anderer Router in den aktiven Zustand überführt, rekla miert dieses bzw. dieser weiterhin bevorzugt die gleiche vir tuelle IP-Adresse und/oder gleiche virtuelle MAC-Adresse für sich, die vorher vom ausgefallenen Relay, insbesondere Router verwendet wurde und die bevorzugt auch auf dem neu aktivier ten Relay, insbesondere Router hinterlegt ist.

Eine weitere besonders bevorzugte Ausgestaltung sieht vor, dass dasjenige der redundanten Relays, insbesondere derjenige der redundanten Router, das bzw. der sich als allererstes bzw. allererster im aktiven Modus befindet, sich eine eindeu tige, eigene DHCPv6-Client DUID erzeugt. Dies kann insbeson dere geschehen, indem es bzw. er die DUID um ein eindeutiges Bitmuster erweitert oder ersetzt, wobei das eindeutige Bit muster beispielsweise durch die Geräte-MAC-Adresse dieses Re lays bzw. Routers und/oder eine aktuelle Systemzeit gegeben sein kann.

Praktischerweise wird die Client DUID entsprechend RFC 3315 nicht alleine aus der (virtuellen) MAC-Adresse gebildet. Da diese MAC-Adresse in der Regel nur innerhalb des einzelnen Upstream- oder Downstream-Netzes eindeutig ist, kann es zu DUID-Kollisionen bei einem überlagerten, delegierenden Router kommen. Dies umso mehr, wenn Relays bzw. Router analog wie Serienmaschinen mehrfach identisch verbaut werden. Aus diesem Grund vereinzeln die aktiven Relays bzw. Router bevorzugt in ihrem allerersten Anlauf ihre Client DUIDs, was durch Erwei- tern/Ersetzen der DUID durch ein eindeutiges Bitmuster mög lich ist. Das erfindungsgemäße System ist in bevorzugter Aus führung entsprechend ausgestaltet und/oder eingerichtet.

Es kann vorgesehen sein, dass es sich bei wenigstens einem, bevorzugt allen redundanten Relays um ein Gateway, insbeson dere ein Application Layer Gateway (ALG) handelt. Diese be sitzen in der Regel eine oder auch mehrere IRnb-Adresse (n) und können ein Applikationsprotokoll via IPv6 auf ein bzw. das gleiche Applikationsprotokoll beziehungsweise einem

Nicht-IP-Protokoll absetzen.

Es können auch Relays in Form von Routern zum Einsatz kommen. Dann kann vorgesehen sein, dass es sich bei wenigstens einem der redundanten Relays um einen IPv6-Router handelt. Alterna tiv oder zusätzlich handelt es sich bei wenigstens einem der redundanten Relays um einen NAT64-Router . Selbstverständlich können auch sämtliche redundanten Relays in Form von IPv6- Routern oder sämtliche redundanten Relays in Form von NAT64- Routern vorliegen.

Ein weiterer Gegenstand der Erfindung ist ein Computerpro gramm, das Programmcodemittel umfasst, die bei der Ausführung des Programms und mindestens einem Computer diesen veranlas sen, das erfindungsgemäße Verfahren zur Bereitstellung redun danter Routing-Funktionen durchführen.

Darüber hinaus betrifft die Erfindung ein computerlesbares Medium, das Instruktionen umfasst, die, wenn sie auf wenigs tens einem Computer ausgeführt werden, den wenigstens einen Computer veranlassen, die Schritte des erfindungsgemäßen Ver fahrens zur Bereitstellung redundanter Routing-Funktionen durchzuführen .

Bei dem computerlesbaren Medium kann es sich beispielsweise um eine CD-ROM oder DVD oder einen USB oder Flash Speicher handeln. Es sei angemerkt, dass unter einem computerlesbaren Medium nicht ausschließlich ein körperliches Medium zu ver- stehen sein soll, sondern ein solches beispielswiese auch in Form eines Datenstromes und/oder eines Signals, welches einen Datenstrom repräsentiert, vorliegen kann.

Weitere Merkmale und Vorteile der vorliegenden Erfindung wer den anhand der nachfolgenden Beschreibung erfindungsgemäßer Ausführungsformen unter Bezugnahme auf die beiliegende Zeich nung deutlich.

Die einzige Figur zeigt eine rein schematische Darstellung eines Ausführungsbeispiels eines erfindungsgemäßen Systems.

Dargestellt ist ein Ausführungsbeispiel eines erfindungsgemä ßen Systems 1 zur Bereitstellung redundanter Relay-, vorlie gend Routingfunktion.

Das System 1 umfasst zwei redundante Relays, die bei dem dar gestellten Ausführungsbeispiel durch zwei redundante Router 2, 3 gegeben sind, die ein überlagertes Upstream-Teilnetzwerk 4 mit einem unterlagerten Downstream-Teilnetzwerk 5 eines in der Figur nicht weiter dargestellten industriellen Netzwerkes einer Automatisierungslösung verbinden. Das Upstream- und das Downstream-Teilnetzwerk 4, 5 sind in der Figur nur rein sche matisch, u.a. durch einen nach oben bzw. nach unten weisenden Pfeil 6 dargestellt. Jeder der beiden redundanten Router 2, 3 weist ein in der Figur nicht gezeigtes Upstream Interface auf, welches mit dem Upstream-Teilnetzwerk 4 verbunden ist, sowie ein in der Figur ebenfalls nicht gezeigtes Downstream- Interface, welches mit dem Downstream-Teilnetzwerk 5 verbun den ist.

Jeder der beiden redundanten Router 2, 3 umfasst weiterhin ein DHCPv6-Client 7, einen IP-Stack 8 und ein Router-Adver- tisement-Modul 9, das in an sich bekannter Weise für das kor rekte Abwickeln des Advertisement-Protokolls ausgebildet und eingerichtet ist. Die Router-Advertisement-Module 9 sind vor liegend als Router-Advertisement-Dämonen (RADVD) gegeben bzw. umfassen jeweils einen solchen. Der DHCPv6-client 7 und der IPv6-Stack 8 stellen ebenfalls Elemente dar, die von Routern gemäß dem Stand der Technik hinlänglich bekannt sind, so dass auf diese nicht weiter eingegangen wird.

In Betrieb ist immer nur maximal einer der beiden redundanten Router 2, 3 im aktiven Modus, während der andere im Standby- Modus ist und „wartet", um für den Fall, dass der bisher ak tive Router ausfällt, insbesondere keine Pakete mehr weiter leitet bzw. weiterleiten kann, für diesen übernehmen zu kön nen. Ein Router-Ausfall kann beispielsweise auf einen Ausfall der Geräte-Hardware und/oder einen Absturz der Router-Soft ware und/oder einen Ausfall der Stromversorgung und/oder ei nen Defekt in der Netzverkabelung zurückzuführen bzw. dadurch bedingt sein. Im Folgenden wird angenommen, dass sich in ei ner Ausgangssituation der in der Figur linke Router 2 im ak tiven Modus befindet und der in der Figur rechte Router 3 im Standby-Modus , wobei klar ist, dass die Rollen ebenso ver tauscht sein könnten.

Nur der im aktiven Modus befindliche Router 2, 3 übernimmt die Routing-Funktion und leitete in an sich bekannter Weise Pakete aus dem überlagerten Teilnetzwerk 4 in das unterlager te Teilnetzwerk 5 weiter.

Jeder der beiden redundanten Router 3 des Systems 1 weist zu sätzlich zu den bereits genannten Modulen bzw. Komponenten ein Router-Redundanz-Modul 10 auf, welches den Modus des je weiligen Routers 2, 3, also dessen Rolle steuert.

Vorliegend sind die Router-Redundanz-Module 10 der beiden re dundanten Router 2, 3 ausgebildet und/oder eingerichtet, um das sogenannte Common Address Redundancy Protocol (CARP) aus zuführen. Alternativ oder zusätzlich können sie ausgebildet und/oder eingerichtet sein, um das sogenannte Common Adress Redundancy Protocol (VRRP) , insbesondere gemäß RFC 5798 aus zuführen .

Beide redundanten Router 2, 3 erhalten eine gemeinsame virtu elle IP-Adresse und vorliegend auch eine gemeinsame virtuelle Mac-Adresse (zu virtuellen IP- und MAC-Adressen siehe insbe sondere RFC 5798) .Dabei sind die virtuelle IP- und Mac-Adres- se nur auf dem jeweils aktiven Router 2, 3, vorliegend also dem linken Router 2, aktiv geschaltet. Fällt der aktive Rou ter 2 aus, so wird der andere Router 3 vom Standby- in den aktiven Modus geschaltet und reklamiert die virtuellen IP- und Mac-Adressen für sich.

Die Router-Redundanzmodule 10 der beiden Router 2, 3 können miteinander kommunizieren, was in der Figur durch einen die beiden Module verbindenden Pfeil 11 angedeutet ist. So ist es möglich, dass der im Standby-Modus befindliche Router 3 in formiert werden kann, wenn der aktive Router 3 ausfällt und er für diesen übernehmen muss.

Konkret sendet das Router-Redundanz-Modul 10 des momentan ak tiven Routers 3 zyklisch, mit geeignetem zeitlichen Abstand von beispielsweise 1 Sekunde eine Nachricht an das Router- Redundanz-Modul 10, des im Standby-Modus befindlichen Routers 2 (zu dem zyklischen Senden siehe insbesondere "Adver_Timer" gemäß RFC 5798) . Fällt der aktive Router 3 aus, bleibt diese Nachricht aus und der bis dahin im Standby-Modus befindliche Router 3 wird in Reaktion auf das Ausbleiben der Nachricht von seinem Router-Redundanz-Modul 10 in den aktiven Zustand überführt .

Es sei angemerkt, dass im Rahmen des vorliegend beschriebenen Ausführungsbeispiels das erfindungsgemäße System 1 zwei re dundante Router 2, 3 umfasst. Selbstverständlich können auch drei oder mehrere redundante Router 2, 3 vorgesehen sein und in diesem Falle können ebenfalls alle Router-Redundanz-Module 10 miteinander kommunizieren. Sind drei oder mehr redundante Router 2, 3 vorhanden, wird im Falle des Ausfalls eines akti ven Routers 2 eine Entscheidung getroffen, welcher der zwei oder mehr verbleibenden Router 2, 3 in den aktiven Modus überführt wird. Hierzu kann beispielsweise eine Prioritäts reihenfolge vorgesehen sein. Weiterhin sein angemerkt, dass alternativ dazu, dass eine Nachricht von dem jeweils aktiven Router 2 ausbleibt, wenn dieser ausfällt, es auch möglich ist, dass erst dann eine Nachricht von dessen Router-Redun- danz-Modul 10 gesendet wird, um den oder die verbleibenden redundanten Router 3 über den Ausfall zu informieren.

Bei den beiden redundanten Routern 2, 3 handelt es sich vor liegend um autokonfigurierende IRnb-Router, deren standari- sierter funktionaler „Unterbau" die sogenannte Präfix-Delega tion gemäß RFC 3633 ist. Alternativ dazu, dass es sich bei den beiden Routern 2, 3 - oder auch nur einem von diesen - um IPv6-Router handelt, können diese beispielsweise auch durch autokonfigurierende NAT64-Router gegeben sein.

Die Präfix-Delegation, die von dem DHCPv6-client 7 der redun danten Router 2, 3 abgewickelt werden kann, basiert technisch auf DHCPv6 entsprechend RFC 3315 und insbesondere auf der so genannten „zustandsbehafteten" („stateful") Variante von DHCPv6. Dadurch wird in die Router 2, 3, die ohne eine auf die Präfix-Delegation zurückgreifende Autokonfiguration zu standslos wären, Zustand eingebracht.

Der Zustand ist in der Figur rein schematisch durch ein mit dem Bezugszeichen 12 versehenes Element in dem DHCPv6-client 7 des jeweiligen redundanten Routers 2, 3 dargestellt. Der Zustand 12 umfasst vorliegend ein in den Figuren nicht näher dargestelltes Präfix, welches dem DHCPv6-client 7 des aktiven redundanten Routers 2 unter Abwicklung der Präfix-Delegation gemäß RFC3633 delegiert wird bzw. wurde, sowie eine virtuelle DHCPv6-client DUID (DUID steht dabei für DHCP Unique Identi- fier) . Diese dient DUID identifiziert den logischen, aktiven Router 2 gegenüber der überlagerten Ebene, die das Präfix de legiert, insbesondere gegenüber einem in der Figur nicht dar gestellten, Prüfix-delegierenden überlagerten Router.

Um auch im „zustandsbehafteten" („stateful") Falle einen durchgehenden Service bereitstellen zu können, umfasst jeder der beiden redundanten Router 2, 3 ein Router-Kontroll-Modul 13. Diesem teilt das Router-Redundanzmodul 10 des jeweiligen Routers 2, 3 den momentanen Router-Modus mit, also, ob sich der jeweilige Router 2, 3 im aktiven oder im Standby-Modus befindet. Entsprechende Mitteilungen bzw. Nachrichten werden im Betrieb zyklisch, mit geeignetem zeitlichem Abstand (bei spielsweise jede Sekunde) von dem Router-Redundanz-Modul 10 des jeweiligen Routers 2, 3 an das jeweilige Router-Kontroll- Modul 13 übermittelt. In der Figur ist dies rein schematisch durch Pfeile 14 angedeutet, welche von dem jeweiligen Router- Redundanz-Modul 10 auf das jeweilige Router-Kontroll-Modul 13 zeigen. Die Router-Redundanz-Module 10 bzw. Router 2, 3 sind entsprechend ausgebildet und eingerichtet.

Die Router-Kontroll-Module 13 sind ferner ausgebildet

und/oder eingerichtet, um anhand der vom Router-Redundanz-Mo dul 10 signalisierten Rolle eine Zustandssynchronisation durchzuführen. Konkret sind sie ausgebildet und/oder einge richtet, um in demjenigen Falle, dass ihnen von dem Router- Redundanz-Modul 10 des jeweiligen Routers 2, 3 signalisiert wird, dass der jeweilige Router 2, 3 sich im aktiven Modus befindet, die virtuelle DUID des DHCPv6-Clients 7 des be troffenen Routers 2, 3 sowie ein dem DHCPv6-Client 7 des be troffenen Routers 2, 3 dynamisch delegiertes Präfix auf den (ggf. die) anderen, sich im Standby-Modus befindlichen Router 2, 3 zu synchronisieren. Für den Fall, dass es drei oder mehr redundante Router 2, 3 gibt, erfolgt eine Synchronisation auf sämtliche im Standby-Modus befindliche Router. Der Zustand 12, der das delegierte Präfix und die virtuelle DUID des DHCPv6-Clients 7 umfasst, kann in dem aktiven Router 2 bei spielsweise in einer Datei im Dateisystem des Routers 2 hin terlegt sein.

Die Synchronisation des Zustandes 12 erfolgt ebenfalls zyk lisch (beispielsweise jede Sekunde oder mit anderem zeitli chem Abstand) und per Protokoll. In der Figur ist die Syn chronisation rein schematisch durch einen die beiden Router- Kontroll-Module 13 der beiden redundanten Router 2, 3 verbin denden Doppelpfeil 15 sowie das jeweilige Router-Kontroll- Modul 13 mit dem Zustand 12 verbindende Doppelpfeile 15 ange deutet .

Vorliegend wickelt nur der aktive Router 2 die Präfix-Delega tion ab, und nur der aktive Router 2 synchronisiert ein ihm delegiertes Präfix und die virtuelle DUID seines DHCPv6- Clients 7 auf den weiteren, im Standby-Modus befindlichen Router 3. Wird dem Router-Kontroll-Modul 13 eines Routers 2,

3 hingegen signalisiert, dass sich der betroffene Router 2, 3 im Standby-Modus befindet (vorliegend der Router 3) , synchro nisiert das keinen Zustand 12 auf den oder die verbleibenden Router 2, 3, sondern empfängt nur den Zustand 12 von dem ge nau einen aktiven Router 2.

Das Router-Advertisement-Modul 9 ist vorliegend dafür zustän dig, dass dem DHCPv6-Client 7 des aktiven Routers 2 dynamisch zugewiesene Präfix am unterlagerten Netzwerk 5 angeschlosse nen, in der Figur nicht dargestellten IPv6-Teilnehmern gemäß RFC 4861 („Neighbour Discovery") bekanntzugeben. Dieser Zusam menhang ist in der Figur durch einen von dem DHCPV6-client 7 zu dem Router-Advertisement-Modul 9 weisenden Pfeil 16 darge stellt .

Infolge der Zustands-Synchronisation steht auf allen redun danten Routern 2, 3 zusätzlich zu der gleichen virtuellen Mac- und IP-Adresse (insbesondere gemäß CARP und/oder VRRP gemäß RFC 5798) auch der jeweilige Zustand 12 des aktiven re dundanten Routers 2 zur Verfügung.

Neben der Zustands-Synchronisation übernehmen die Router- Kontroll-Module 13 auch das korrekte orchestrieren der betei ligten DHCPv6-Clients 7 sowie Router-Advertisement-Module 9. Konkret aktiviert das Router-Kontroll-Modul 13 eines Routers 2, 3, wenn es von dessen Router-Redundanz-Modul 10 signali siert bekommt, dass sich der Router 2, 3 im aktiven Zustand befindet, den DHCPv6-client 7 und das Router-Advertisement- Modul 9 und hält diese aktiv, so lange der aktive Modus an hält . Wird dem Router-Kontroll-Modul 13 eines Routers 2, 3 hingegen vom Router- Redundanz-Modul 10 gemeldet, dass sich der Router 2, 3 im Standby-Modus befindet, deaktiviert das Router-Kon troll-Modul 13 den DHCPv6-client 7 und das Router-Advertise- ment-Modul 9 des betroffenen Routers 2, 3 und hält diese de aktiviert, solange der Standby-Modus anhält. Dass das Router- Kontroll-Modul 13 den DHCPv6-client 7 und das Router-Adver- tisement-Modul 9 entsprechend beeinflusst, ist in der Figur rein schematisch durch Pfeile 17 und 18 angedeutet, welche von dem Router-Kontroll-Modul 13 auf den DHCPv6-Client 7 bzw. das Router-Advertisement-Modul 9 zeigen.

Für den Fall, dass ein Modus-Wechsel stattfindet, weil einer der Router 2, 3 ausfällt (vorliegend der aktive Router 2), wird das Router-Kontroll-Modul 13 desjenigen Routers 2, 3, der in Reaktion auf den Ausfall aktiviert wird (vorliegend der zweite redundante Router 3) , den DHCPv6-client 7 dieses Routers 3 starten und dieser wird - aufgrund der Zustands- Synchronisation - im Anlauf „ganz normal" auf den synchroni sierten Zustand 12 zurückgreifen. Das Starten ist systemab hängig, kann im Falle eines Linus-System mit "systemd" bei spielsweise durch Ausführen des Kommandos "systemctl Start dhcpd. Service" erfolgen. Über den Modus-Wechsel wird das Rou- ter-Kontrollmodul 13 von dem betroffenen Router 3 von dessen Router-Redundanz-Modul 10 informiert. Auf Wunsch kann der in Reaktion auf den Ausfall des Routers 2 aktivierte Router 3 zusätzlich das delegierte Präfix beim überlagerten delegie renden Router, welcher in der Figur nicht gezeigt ist, vali dieren .

Parallel dazu wird das Router-Advertisement-Modul 9 des dann aktivierten Routers 2, welches - genau wie der DHCPv6-Client 7 - von dem Router-Kontroll-Modul 13 in Reaktion auf den Aus fall des anderen redundanten Routers 2 aktiviert wurde, das bisherige, über die Synchronisation erhaltene Präfix am un terlagerten Teil- bzw. Subnetz 5 weiterhin aktiv halten. Für am unterlagerten Teilnetz 5 angeschlossene IPv6-Knoten (in der Figur nicht gezeigt) ist dieser Wechsel bis auf einem eventuell vorübergehend auftretenden Paketverlust aus diesem Netz 5 oder in dieses Netz 5 hinein unsichtbar. Insbesondere bleiben die IPV6-Adresse und Mac des Routers 2, 3 konstant. Gelichzeitig bleibt auch aus Sich des überlagerten, delegie renden Routers (in der Figur nicht gezeigt) , die Identität des IPv6-Routers 2, 3 gleich. Bei IPv6 ist die Identität von Clients allein an deren DUID gekoppelt und nicht an deren MAC-Adresse .

Es kann eine Redundanzfunktion bereitgestellt und so durchge hend ein Router-Service aufrecht erhalten werden, selbst wenn einer der Router 2, 3 ausfällt und zwar im Falle autokonfigu rierender, infolge dessen „zustandsbehafteter („stateful") Router 2, 3. Automatisierungsanwender erhalten den Mehrwert der Redundanz wichtiger Infrastrukturkomponenten, insbesonde re ihrer Netzknoten, ohne dass sie hierzu IT-Know-How erwer ben oder IT-Personal einbinden müssen. Die Zustandssynchroni sation und der Rollenwechsel laufen vollständig automatisch ab .

Obwohl die Erfindung im Detail durch das bevorzugte Ausfüh rungsbeispiel näher illustriert und beschrieben wurde, so ist die Erfindung nicht durch die offenbarten Beispiele einge schränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen .