Siemens SIMATIC NET RUGGEDCOM RX5000 Konfigurationshandbuch Seite 873

Unicast- und Multicast-Routing
12.8.11 Route-Reflector-Optionen verwalten
Erfordernis der Vollvermaschung
Auf Grund der Regeln zur BGP-Routenankündigung erfordert BGP eine logische
voll vermaschte ("full-mesh") Topologie, in der jeder Router seine Routen jedem
seiner Nachbarn ankündigt und an diesen weiterleitet. Diese Anforderung lässt
sich in externen oder eBGP-Netzwerken leicht erfüllen, in denen Verbindungen
zwischen autonomen Systemen (AS) hergestellt werden. Router können Schleifen
einfach vermeiden, indem Routen, die die gleiche numerische AS-Kennung besitzen,
verworfen werden. In internen oder iBGP-Netzwerken hat jedoch jeder Router die
gleiche numerische AS-Kennung, so dass alle von einem Router empfangenen
Routen verworfen werden würden.
Eine Möglichkeit, dieses Problem zu lösen, besteht darin, dass jeder iBGP-Router
eine Nachbarschaft mit seinen Peers aufbaut. Das würde jedoch zu sehr vielen BGP-
Sitzungen und unnötig hohem Verkehr in großen Netzwerken führen. Die Anzahl der
BGP-Sitzungen für X Router wird mit folgender Formel bestimmt: X*(X-1)/2. 20 iBGP-
Router würden somit 190 BGP-Sitzungen erzeugen (20*[20-1]/2 = 190).
Abbildung 12.151 Einfache BGP-Topologie ohne Route Reflector
Die Route-Reflector-Lösung
Der Einsatz einer Route-Reflector-Lösung vereinfacht die Topologie, indem Router
in einen Cluster gruppiert werden. Der Route Reflector stellt im Cluster eine BGP-
Sitzung mit jedem Client (BGP-Nachbar) her. Die Clients müssen keine BGP-Sitzungen
untereinander herstellen und müssen auch nicht voll vermascht sein. Alle Routen
werden dem Route Reflector ankündigt, der die Routen wiederum an seine Clients
weitergibt und somit die Anforderung der Vollvermaschung erfüllt. RUGGEDCOM
ROX II verwendet keine BGP-Routen für die Auflösung von BGP Next-Hop-Werten.
Abbildung 12.152 Einfache BGP-Topologie mit Route Reflector
828
RR
RUGGEDCOM ROX II v2.15 Weboberfläche
Konfigurationshandbuch, 05/2022, C79000-G8900-1534-02