Microsofts BGP Router im Internet
Microsoft stellt einen eigenen BGP Router für Windows bereit. Wir benötigen an einer Stelle, wo bisher nur ein paar Hyper-V fähige Kisten stehen einen unabhängigen Internetzugang. Was liegt also näher als alles aus einer Hand zu bauen?
Installation
Auf eine Windows VM kommt aus der RAS Rolle das Feature LAN Routing zum Einsatz. Damit kann die VM zwischen Interfaces routen.
Als nächstes wird die BGP Rolle installiert. Auch das ist problemlos, die benötigten Abhängigkeiten sind gleich dabei.
Alle folgenden Schritte benötigen die Powershell, was dem geneigten Admin sehr entgegen kommt. Zuerst also einen neuen BGP Router definieren.
PS> Add-BgpRouter -BgpIdentifier <IPAddress> -LocalASN <UInt32>
Man gibt also seine lokales AS Nummer an (zum experimentieren gibt private Nummern) und eine eindeutige IP Adresse, unter der der Router arbeiten wird. Am besten die IP eines Interfaces. Erfreulich ist die Verwendung eines UInt32, der auf die Unterstützung von 4-Byte ASNs hinweist.
Als nächstes kommt dann die Einrichtung eines BGP Peers, also eines Nachbar mit dem diese Maschine reden soll.
PS> Add-BgpPeer [-Name] <String> -LocalIPAddress <IPAddress> -PeerASN <UInt32> -PeerIPAddress <IPAddress>
Der Peer bekommt einen sprechenden Namen unter dem er später erscheinen soll. Des weiteren wird die AS-Nummer des Peers benötigt. Wenn diese die gleiche ist, wie die eigene, handelt es ich um ein i(nternal)BGP, sonst um ein e(xternal)BGP Peer.
Die Kommunikation erfolgt zwischen zwei IP Adressen, die auf beiden Seiten übereinstimmen müssen. I.d.R. werden da IP Adressen genommen, die sich im gleichen Netz befinden und direkt miteinander reden können. Die meisten eBGP Peers erwarten das. bei iBGP ist eine durchaus längere Routingstrecke zwischen den Peers nichts ungewöhnliches.
Cisco als Gegenstelle
Zum Test lasse ich den Server gegen einen normalen Cisco Router arbeiten.
router bgp 15725 neighbor <WindowsIP> remote-as 65432 address-family ipv4 neighbor <WindowsIP> activate neighbor <WindowsIP> soft-reconfiguration inbound neighbor <WindowsIP> prefix-list from_windows in neighbor <WindowsIP> prefix-list to_windows out exit-address-family ! ip prefix-list from_windows seq 5 deny 0.0.0.0/0 le 32 ip prefix-list to_windows seq 1 permit 185.98.236.0/22 ip prefix-list to_windows seq 5 deny 0.0.0.0/0 le 32
Für den Anfang gebe ich nur eine Route raus und nehme nichts an. Sicher ist sicher.
Die BGP Session kommt hoch und das Windows lernt eine Route!
Mit Get-BgpPeer und Get-BgpRouteInformation kann man sich die Ergebnisse ansehen. Die Route taucht sogar in der normalen Routing Tabelle auf.
Auffällig ist aber, dass die Cisco etwas seltsames anzeigt:
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised
Address family IPv4 Unicast: advertised and received
Graceful Restart Capability: advertised
Enhanced Refresh Capability: advertisedIrgendwie fehlt da die 4-Byte ASN Funktionalität. Gleich mal ausprobieren.
PS> Add-BgpPeer test4byte -LocalIPAddress <IPAddress> -PeerASN 199932 -PeerIPAddress <IPAddress>
Oops. Das ist ein KO-Kriterium. Eigentlich müsste ich hier sofort aufhören zu evaluieren.
Full Table
Aber probieren wir mal was anderes. Was tut die Kiste, wenn sie der vollen Internet-Routingtabelle ausgesetzt wird?
(config)#ip prefix-list to_windows seq 2 perm 0.0.0.0/0 le 24
Die CPUs gehen auf Anschlag und bleiben dort eine ganze Weile. Trotzdem bleibt das System benutzbar. Der RAM Bedarf steigt um zwei GByte, was ziemlich okay ist.
Anschließend sind alle Kerne mit ca 50% CPU belastet ohne dass irgendeine Aktivität von außen rein kommt. Seltsam.
Ein Blick in die BGP Routingtabelle mit Get-BgpRouteInformation zeigt, dass alle knapp 750.000 Routen angekommen sind. Allerdings braucht die Maschine unter CPU Volllast für die Ausgabe geschlagene drei Minuten.
Die Überraschung gibt es aber mit dem Blick in die aktive Routing Tabelle:
Dies ist mit unvollständig nur unzureichend umschrieben.
Real fehlen abertausende Routen wie die folgenden:
B 206.0.0.0/15 [20/0] via 94.135.173.249, 4d15h B 206.2.0.0/16 [20/0] via 94.135.173.249, 4d15h B 206.2.76.0/24 [20/0] via 94.135.173.249, 00:36:24 B 206.3.0.0/19 [20/0] via 5.102.160.98, 4w0d B 206.3.32.0/19 [20/0] via 94.135.173.249, 4d15h B 206.3.42.0/24 [20/0] via 5.102.160.98, 19:43:50 B 206.3.64.0/18 [20/0] via 94.135.173.249, 4d15h B 206.3.128.0/17 [20/0] via 94.135.173.249, 4d15h B 206.4.0.0/14 [20/0] via 94.135.173.249, 4d15h B 206.5.12.0/22 [20/0] via 94.135.173.249, 4d15h B 206.8.0.0/14 [20/0] via 94.135.173.249, 4d15h B 206.8.2.0/24 [20/0] via 94.135.173.249, 4d15h B 206.8.88.0/24 [20/0] via 5.102.160.98, 19:43:49 B 206.8.120.0/24 [20/0] via 94.135.173.249, 4d15h B 206.8.121.0/24 [20/0] via 94.135.173.249, 4d15h B 206.8.122.0/24 [20/0] via 94.135.173.249, 4d15h
Das heißt, dass die Maschine nun nicht in der Lage die Pakete korrekt ans Ziel zuzustellen!
Das ist ein KO-Kriterium. Eigentlich müsste ich hier sofort aufhören zu evaluieren.
Wegräumen
Also nehme ich das Announcement der Routen wieder weg.
(config)#no ip prefix-list to_windows seq 2 perm 0.0.0.0/0 le 24
Nach erfreulich schnellen 40 Sekunden sinkt die CPU Last rapide auf nahe 0. Allerdings sind noch immer tausende von Routen im Kernel aktiv.
Als ich zur Kontrolle mir die BGP Routingtabelle mit Get-BgpRouteInformation anzeigen lassen will, behauptet das System, dass die betreffenden Dienste nicht laufen würden.
Erst im Ereignislog zeigt sich das ganze Ausmaß der Katastrophe:
Es hat so ziemlich jeden laufenden Dienst abgeschossen. Nicht nur Routing, sondern auch die Nutzerverwaltung, die Hardware Treiber etc. pp.
Das ist ein KO-Kriterium. Eigentlich müsste ich hier sofort aufhören zu evaluieren.
Zum Glück starten alle Services von alleine neu und ich kann Screenshots für den Blog machen.
IPv6 teste ich nicht mehr.
Das ist ein KO-Kriterium. Eigentlich müsste ich hier sofort aufhören zu evaluieren.
2 Kommentare