ExpressRoute - Grundlagen
Die meisten Cloud-Angebot nutzen das Internet als Transport. Der Client ist also irgendwo beim Kunden und der Anbieter irgendwo anders. Dazwischen werden die Daten über unterschiedlicher Carrier und ggfls. Landesgrenzen übertragen. Und das ist nicht immer "problemlos.
Beachte dazu auch die Seite Office 365 Netzwerkziele und Express Way
Wie gut ist eine Verbindung?
Eine Verbindung über das Internet zu einem Service durchläuft mehrere Stationen, die alle unterschiedlichen Begrenzungen unterliegen. Meist ist es Bandbreite die eine absolute Obergrenze hat und wenn diese hoch belastet ist, direkten Einfluss auf die Laufzeit (Latenz, Jitter) und bei extremer Überlast natürlich auch auf die Erreichbarkeit (Packet Loss). Auch der Weg zwischen zwei Stationen ist nicht immer identisch. Redundante Router und Verbindungen als auch Rerouting durch Ausfälle können das Verhalten ändern. Erschwerend kommt dazu , dass auch der Faktor Zeit eine Rolle spielt. Wenn die Einwohner abends Video On Demand nutzen, dann hat das nicht nur Einfluss auf ein Home-Office, sondern über das Backbone auch auf Firmenverbindungen über das Internet. Behalten Sie als die Kriterien im Kopf:
- Latenz, Jitter
- Durchsatz und Packet Loss
- Zuverlässigkeit
Wenn mehr Firmen die Qualität ihrer Leitung korrekt erfassen würden, würden dies viel häufiger auffallen. (Sieh z.B. ). Das gilt für ExpressRoute noch um so mehr, dass Sie nicht nur einen Carrier für eine gute Verbindung bezahlen, sondern auch kontrollieren, dass die gelieferte Ware stimmt. Microsoft selbst überwacht von seiner Seite aus die Qualität aber das ist keine echte "Ende zu Ende"-Überwachung.
Network Assessment sind keine einmalige Aktion vor der Einführung einer Lösung, sondern eine permanente Aufgabe.
Der Weg der Pakete vom internen Client zum Service ist bei der Nutzung von Hosting-Angeboten natürlich deutlich länger und steiniger als zu einem internen Server. für externe Client kann es je nach Standort aber sogar besser sein, den Dienst in der Cloud zu nutzen. Ein interner Client durchläuft in der Regel folgende Stationen:
- Internes LAN
Wenn es sich um den Hauptstandort mit z.B. Gigabit handelt, dann ist dies gleichwertig zum Betrieb interner Server. Etwas anders sieht es aus, wenn Sie intern auch noch ihre eigenes WAN mit mehreren Standorten haben. Dann sind diese Links relevant. ExpressRoute verbindet immer einen Standort mit Office 365. - Internet Connection zum Carrier
Ohne ExpressRoute gehen die Verbindungen zum Hosting-Provider natürlich über das "Internet" und damit auch über ihren WAN-Link zu ihrem Zugangsprovider. Hier müssen sich die Office 365 Daten natürlich die Bandbreite mit all den anderen Daten (YouTube-betrachten, Mailverkehr, Surfen, VPN etc.) teilen. - Carrier Backbone
Ihr "Internet Provider" leitet die Daten dann über sein eigenes Backbone entweder direkt zum Ziel, z.B. wenn ihr Carrier schon eine Verbindung mit Office 365 hat. In den meisten Fällen wird die Verbindung aber über einen der großen Carrier gehen, mit denen ihr Provider entsprechende Abkommen geschlossen hat oder über große Austauschpunkte wie das DECIX und andere. - Carrier Peering
DECIX und andere haben sicher genug "Backplane"-Kapazität um alle Daten zu vermitteln. Aber jeder Carrier hat natürlich nur einen begrenzten Anschluss an solch einen Austauschpunkt. - Peering Carrier Backbone (auch mehrere)
Damit sind die Daten nun bei einem zweiten Carrier, der aber keinen direkten Vertrag mit ihnen hat, sondern nur über das Peering die Daten weiter leitet. Auch dieses Backbone ist natürlich nicht unendlich leistungsfähig. - Hosting Connection
Zuletzt gibt es auch den Übergang zum Microsoft Netzwerk. Sie können sicher sein, dass Microsoft nicht nur an seinen direkten Serverstandorten entsprechende Übergänge hat, sondern selbst ein weltweites WAN in Eigenverantwortung betreibt. Je nach Standort ihres Clients löst z.B. "outlook.office365.com" auf eine andere IP-Adresse auf, so dass der Weg über das "nicht qualitätsgesicherte" Internet möglichst kurz ist und die Daten schnell z.B. bei einem Exchange Server landen, der dann diese über ein internes QoS-gesichertes Netz an den Postfachserver weiter gibt.
Leider veröffentlichen nicht alle Provider sehr freizügig ihre Daten über das interne Netzwerk. Selbst wenn das aber jeder Provider tun würde, könnten wohl die wenigsten Kunden daraus die richtigen Schlüsse ziehen. Hier dennoch mal ein paar Links zu solchen Seiten:
-
www.peeringdb.com
Eine Webseite, in der anscheinend viele Carrier hinterlegen, welche Verbindung sie pflegen.- Telekom
https://www.peeringdb.com/private/participant_view.php?id=196
Mit ca. 7 "Public Peerings" und 27 "private Peerings" ein scheinbar kleiner Provider. - 1und1
https://www.peeringdb.com/private/participant_view.php?id=262
Hat zumindest viel mehr Public Peerings - DeCIX
https://www.peeringdb.com/private/exchange_view.php?id=31
Hier sind natürlich ganz viele "verbunden". Da tauchen auch plötzlich Firmen wie Amazon, Apple, Akamai etc. auf, die dort angebunden sind.
Interessant ist hier auch der öffentliche Zugriff auf die Auslastung unter http://www.de-cix.net/info/traffic.html - Microsoft
Microsoft Content https://www.peeringdb.com/private/participant_view.php?id=7472
Microsoft NSP https://www.peeringdb.com/private/participant_view.php?id=694
Interessant ist hier nur der Netzwerk Teil. Und hier ist wirklich zu sehen, wie gut "vernetzt" Microsoft ist. 17 Seiten a 12 Einträge alleine bei Public Peerings
- Telekom
- OVH
Ein nicht ganz kleiner Provider, der sehr umfangreich auch sein internes Netzwerk aufzeigt
https://www.ovh.com/us/about-us/network.xml
Echtzeitstatus über das eigene Netzwerk
hhttps://www.ovh.co.uk/community/status/ - Weitere Statusseiten addiere ich bei Gelegenheit
ExpressRoute Connectivity Partners
Um diese "Probleme" zu reduzieren, bietet Microsoft in Verbindung mit entsprechenden Partnern eigene qualitätsgesicherte Verbindungen zwischen dem Kundennetzwerk und Office 365 an. ExpressRoute ist also nicht nur eine reine Konfigurationsmaßnahme, sondern ein zugelassener Carrier schaltet ihnen eine entsprechende exklusive Verbindung zum Office 365 Datacenter mit einer garantierten Bandbreite aber auch eine zugesicherten Verfügbarkeit. Microsoft schreibt selbst dazu:
Each ExpressRoute circuit automatically delivers two active physical
connections für high availability, and the Microsoft networking elements are
backed by our connection uptime SLA of 99.9 percent. We’re the only public cloud
provider to offer this level of guaranteed availability für the connection. Of
course, we are also the only public cloud provider who can offer both Azure and
Office 365 services on a single network connection.
Quelle:
hhttps://blogs.office.com/2015/03/17/announcing-azure-ExpressRoute-connectivity-to-office-365/
ExpressRoute is available today für access to Azure services, and is expected to be available für Office 365 in the third quarter of 2015. Network capacity planning is a first step to any networking project,
Achtung:
Azure ExpressRoute ist eine Verbindung zur Cloud mit einer
garantierten Bandbreite und Verfügbarkeit. für den Einsatz
mit CloudPBX ist es aber dringend angeraten, einen Carrier
zu wählen, die auch die Office 365 Workload in dem Tunnel
per QoS priorisieren und das Tagging erlauben. Nicht alle
Provider unterstützen dies.
Früher war es angeblich so gar möglich, eine eigene WAN-Verbindung bis in das Datacenter von Microsoft zu legen und quasi dort dann noch Firewall, Router etc. zu betreiben. Das war aber nur für sehr große Firmen und für die Anfangszeit eine Option. So eine Technik skaliert natürlich nicht. Daher nutzt Express-Route aktuell entsprechende Provider, die ihrerseits die komplexe Anbindung an Microsoft auf ihrer Seite umgesetzt haben und nun die Kunden in diesen Verbund einbinden. Es gibt einige bekannte Provider auf dem Bild von September 2015:
Aktuell ist natürlich die Liste der Standorte und Partner auf den Seiten von Microsoft
- ExpressRoute partners and peering
locations
https://azure.microsoft.com/en-us/documentation/articles/ExpressRoute-locations/
Zumal die nächsten Monate sicher weitere Netzwerkstandorte und damit Netzwerkknoten dazu kommen. Auch die Liste der Carrier wird sicher noch wachsen. So werden vermutlich auch Telekom und Vodafone ein Stück vom Kuchen haben wollen. Eigentlich bin ich überrascht, dass Sie noch nicht dabei sind, da sie ja durchaus viele Kunden mit einem MPLS-Netzwerk versorgen und der Übergang eigentlich nur logisch erscheint.
Alternative Anbindungen
Sie müssen aber gar nicht ihr LAN direkt mit einem der Partner mit Office 365 direkt verbinden. Es gibt auch noch alternative Möglichkeiten über einen anderen Provider. Stellen Sie sich vor, eine Firma betreibt ein Rechenzentrum mit entsprechenden Anbindungen zu Office 365 aber auch anderen Cloud Services (Amazon AWS, Google, SAP, DATEV etc.) und sie verbinden ihr LAn einfach mit diesem Austauschpunkt. Natürlich geht das über eine weitere Relay-Station aber das kann letztlich für Sie günstiger sein, als die Einrichtung selbst durchzuführen. Das gilt insbesondere, wenn Sie mehrere Cloud-Services nutzen wollen und damit die Komplexität von Routing-Protokollen durch ihre IT bedient werden müsste.
Wenn Sie nun aber schon eine Leitung zu so einem Dienstleister in dessen RZ aufbauen, welches gut mit anderen Diensten verbunden ist, dann kann es weiterhin sinnvoll sein, dort gleich noch einige andere Dienste zu platzieren. Warum sollten Sie ihr Mail-Relay, ihren VPN-Zugangsknoten oder ADFS-Server noch im eigenen RZ betreiben, welches nur mit einem Provider gut verbunden ist?. Wenn Sie die Dienste direkt vor Ort beim Verbindungsprovider mit hinstellen, dann sind ihre Dienste von vielen Netzwerken vermutlich besser erreichbar und ihre eigene WAN-Leitung wird sogar noch entlastet.
Insofern sollten Sie sich tagesaktuell immer mal umschauen, welche Provider es gibt, die ihnen ExpressRoute quasi als "Wiederverkäufer" zuliefern können. Meine Liste hier ist sicher nicht vollständig.
- interxion CLOUD CONNECT
http://www.interxion.com/de/Produkte/interconnection/cloud-connect/ - DeCIX DirectCLOUD
https://www.de-cix.net/de/services/directcloud
https://de-cix.net/de/about-de-cix/media-center/press-releases/de-cix-introduces-new-service-model-and-expands-portfolio
Preise
Microsoft hat auf seiner Webseite Preise für "Ports" angegeben, die nach Geschwindigkeit abgerechnet werden. Allerdings ist das nur der Preis, den Sie an Microsoft für die Anbindung zahlen. Der Weg dorthin ist in dem Preis nicht enthalten.
Sobald ich einige Anbindungen mit ExpressRoute aufgebaut und die Freigabe vom Kunden habe, werde ich hier weitere Details senden.
- ExpressRoute Pricing
https://azure.microsoft.com/en-us/pricing/details/ExpressRoute/ - ExpressRoute documentation
https://azure.microsoft.com/en-us/documentation/services/ExpressRoute - ExpressRoute workflows for circuit
provisioning and circuit states
https://azure.microsoft.com/en-us/documentation/articles/ExpressRoute-workflows
Routing von Paketen
Nun ist es an der Zeit zu überlegen, wie die Pakete von den Clients zu Office 365 kommen und wie diese den "richtigen" Weg dorthin nehmen. Ohne Azure ExpressRoute können Sie drei Netzwerkbereiche:
- Das interne LAN
Dieses Netzwerk in ihrer Firma nutzt idealerweise private IP-Adressen (10.x.x.x, 172.16.x.x-172.32.x.x oder 192.168.x.x) oder in seltenen Fällen ihnen offiziell zugewiesene Adressen. Wer hier Adressen aus anderen Bereichen nutzt, kann ohne zusätzliche Umsetzungen kaum Dienste in der Cloud nutzen. Auch ein internes privates WAN gehört in diesen Bereich. - Das Internet
Über das große Internet mit allen anderen Adressen kommunizieren alle beteiligten Partner damit. Alle Endpunkte müssen dazu öffentliche und routingfähige IP-Adressen verwenden, die auch in den Leitwegen, früher RIP und heute BGP (Border Gateway Protocol). Office 365 ist auch einfach nur eine Gegenstelle - Home Office / Mobile User)
Neben den Firmenanwendern gibt es natürlich auch Personen, die aus dem Hotel, dem Zuhause oder Mobil arbeiten und dort meist ebenfalls private Adressen nutzen, die aber nur per NAT-Router zum Internet übersetzt werden.
VPN-User, die einen komplette Tunnel fahren, fallen hingegen wieder in das "interne LAN" - Office 365 internes Netzwerk
Natürlich hat Microsoft interne Netzwerke, die sie aber nicht wirklich sehen und über deren Aufbau nicht so viel bekannt ist. Wer einen Teilbereich davon erleuchten möchte, möge einfach mal die SMTP-Header einer Mail betrachten. Teilweise sind hier Rechnernamen und auch IP-Adressen zu sehen. für die weitere Betrachtung sind diese ebenfalls private Netzwerke aber nicht relevant.
Zwischen den Netzwerken gibt es natürlich Übergänge und zwischen den privaten Adressen im internen LAN oder Home-Office muss eine Adressumsetzung Richtung Internet erfolgen. Im Home Office ist das in der Regel der DSL-Router. In Firmen meist ein HTTP-Proxy-Server.
Mit einer Azure ExpressRoute ändert sich hier hier nur an einer Stelle etwas: Die Clients im internen Netzwerk dürfen nicht mehr den normalen Weg über die Internet-Anbindung der Firma zu Office 365 nehmen, sondern müssen über den ExpressRoute Weg gehen. Die Clients fragen aber weiterhin per DNS die gleichen Zugangspunkte von Office 365 ( z.B. outlook.office365.com oder login.microsoftonline.com etc.) ab und bekommt natürlich auch weiterhin die gleichen Adressen geliefert.
Die Anbindung von ExpressRoute arbeitet nun derart, dass die IP-Leitwege zum Internet "umgestellt" werden. Über BGP-Routen bekommen die Router mit, dass bestimmte Subnetze nicht mehr über die "Default Route" laufen, sondern über einen anderen Weg.
Hier in dem Beispiel sind zwei Router bei der Firma installiert und über Leitwege wird sichergestellt, dass die Office 365-Netzwerk über ExpressRoute laufen. Natürlich muss auch hier an der Schnittstelle eine Adressumsetzung erfolgen, damit auf dem ExpressRoute und Office 365 nur offizielle IP-Adressen erscheinen. Schließlich muss auch Office 365 den Rückweg zu diesem Kunden genauso über ExpressRoute weiter leiten.
Das hier ist eine vereinfachte Beschreibung. Sie können über ExpressRoute natürlich auch z.B. Systeme mit privaten IP-Adressen im LAN mit anderen Systemen in Azure, die ebenfalls private IP-Adressen nutzen, verbinden.
- ExpressRoute technical overview
https://azure.microsoft.com/en-us/documentation/articles/ExpressRoute-introduction/ - ExpressRoute circuits and routing
domains
https://azure.microsoft.com/en-us/documentation/articles/ExpressRoute-circuit-peerings/ - AS-Microsoft ASN= 8075
https://www.ultratools.com/tools/asnInfoResult?domainName=AS8075 - RIPEstat
https://stat.ripe.net/AS8075 - BGP Lookup Tool - Subnetze von ASN8075
https://www.dan.me.uk/bgplookup?asn=8075
Layer 2 und Layer 3 Anbindung
Wenn Sie die Unterlagen zu Express Route lesen, dann gibt es unterschiedliche Anbindungen. Grundlegend lässt sich die Anbindung in zwei Varianten unterscheiden
- Layer-2
Der Provider stellt die reine Bitübertragungsschicht bereit. Die eigentliche Konfiguration der Netzwerkkomponenten obliegt ihnen oder einem anderen Dienstleister, der Sie unterstützt. - Layer-3
Der Betreiber übernimmt das logische IP-Routing mit allen Facetten. Sie müssen eventuell noch einen Leitweg anpassen aber alles andere konfiguriert der Anbieter für Sie
Man kann gar nicht allgemein sagen, welche Anbindung "besser" ist. Wenn ihr Provider ihnen eine Layer-3 Anbindung zu einem fairen Preis bereitstellt, dann haben Sie im Idealfall überhaupt keine Arbeit, denn der Anbieter übernimmt nicht nur die technische Verbindung sondern auch die Umsetzung von IP-Adressen (NAT) und die Veröffentlichung von Leitwegen per BGP. Allerdings ist der Anbieter dann schon sehr eng mit ihrem Netzwerk vertraut. In der Regel ist es ihr MPLS-Provider.
Mit Layer-2 können (und müssen) sie mehr oder minder alles selbst machen. Da kommen irgendwo zwei Kabel an und sie müssen selbst Firewalls, Router, VLAN-Tagging, NAT und BGP-Konfiguration umsetzen. Allerdings haben Sie dann natürlich auch das Verständnis aufgebaut und werden nicht künstlich "dumm" gehalten. Gerade bei späteren Änderungen oder auch dem Netzwerktest ist es wichtig auf Augenhöhe mit den Anwendern und den Netzwerkbetreibern zu sein.
MPLS und ExpressRoute
Anfangs hatte ich geschrieben, dass ExpressRoute je Standort einzurichten ist. Sie können mit einer ExpressRoute Verbindung also nicht mehrere Standorte verbinden. Jeder Standort bräuchte seine eigene ExpressRoute Verbindung. Allerdings haben die meisten dezentralen Firmen auch heute schon WAN-Verbindungen, die in der Regel von einem Carrier bereit gestellt werden. Ich kenne mehr Firmen, die MPLS nutzen, als Firmen, die eigene Daten-Direkt-Verbindungen betreiben oder auf VPN-Verbindungen über das Internet als Standortlink verwalten.
Wenn natürlich dieser Carrier heute schon ein privates WAN für sie als Firma aufbaut, dann wäre es natürlich unlogisch, wenn Sie dann eine ExpressRoute-Verbindung zum zentralen Standort konfigurieren würden. Alle Daten der Niederlassungen würden dann über das Firmen-WAN erst einmal zur Zentrale laufen und dann vielleicht sogar über die gleiche Leitung wieder zu Microsoft.
Interessanter ist es hier dann, wenn der MPLS-Provider selbst quasi einen "virtuellen Standort" der Firma an einem günstig gelegenen Netzknotenpunkt aufbaut und die Verbindung zu Office 365 und Azure als Teil seiner WAN-Leistung betrachtet. Dann könnte jeder Standort seine "Cloud-Daten wie gewohnt über das MPLS verschlüsselt, abgeschottet und qualitätsgesichert zur Verbindung Richtung Office 365 senden. Die Daten müssten nicht mehr den Umweg über die "Zentrale" und eigene Express-Route-Verbindungen in Niederlassungen wären auch überflüssig.
ExpressRoute mit mehreren Sites
Größere Firmen haben natürlich mehrere Standorte, die sie mit eigenen MPLS-Verbindungen o.ä. verlinkt haben. Wenn nun alle Standorte auch Office 365 Dienste nutzen, dann kann eine Firma natürlich den Client Traffic zuerst über die eigenen Leitungen bis zum eigenen ExpressRoute Knotenpunkt leiten und dann in die Cloud. Viel interessanter ist natürlich eine lokale Verbindung per Express-Route zu Microsoft. Zum einen dürfte Microsoft ein besseres und schnelleres (eigenes) Netzwerk haben als sie als Kunde ihre MPLS-Leistung aufrüsten. Zudem entlasten Sie ihre MPLS-Leistung von Office 365 Verkehr, der schon vor Ort das Firmennetzwerk Richtung Cloud verlässt.
So ähnlich hat es auch Microsoft in einem Broadcast Meeting veröffentlicht. Nicht ganz ohne eine entsprechendes Zitat, welches letztlich nur symbolisch abgeschwächt wurde.
You should have one ExpressRoute
Connection per Continent, because the Microsoft Netzwork is
better than your MPLS
Quelle:
Quelle:
SfB Video Broadcast: Ep. 17 Networking
https://www.youtube.com/watch?v=4VcWKPGX-30 Minute 36
Einrichtung / BGP
Microsoft beschreibt die Einrichtung relativ allgemein. Das mag auch daran liegen, dass die verschiedenen Carrier eigene Vorgehensweisen haben. Die meisten Firmen werden sich auch gar nicht mit BGP-Routen etc. beschäftigen und überlassen diese Einrichtungen dem ExpressRoute Provider.
Daher möchte ich es hier bei einer kurzen Punkteliste belassen:
- Azure Subscription abschließen
Für den Einsatzsatz von ExpressRoute ist eine aktives Azure-Subscription erforderlich. - ExpressRoute Connectivity Provider
festlegen
Suchen Sie sich dann den "passenden" Provider, der ihnen an ihren Standorten ein entsprechendes Angebot erstellt. Microsoft führt die Provider auf der Liste unter https://azure.microsoft.com/en-us/documentation/articles/ExpressRoute-locations/ auf. Dieser Schritt wird vermutlich der aufwändigste Teil sein, da hier verschiedene Angebote einzuholen sind. Allerdings wird der Provider Sie natürlich fragen, wie viel Bandbreite sie brauchen, womit wir vielleicht vorher doch noch eine Analyse hierzu ansetzen sollten. Siehe dazu auch Office 365:WAN-Bandbreite u.a. - Azure Powershell installieren
Die weitere Einrichtung erfolgt per Powershell in Azure. Sie benötigen daher die Azure PowerShell Module
(Download unter https://azure.microsoft.com/de-de/documentation/articles/powershell-install-configure/) - ExpressRoute Service Key anfordern (Standard oder Premium)
Diese Schlüssel ist nichts anderes als eine GUID, die in der Folge alle Konfigurationseinstellungen kennzeichnet. - Service Key an Provider geben
Diesen Schlüssel benötigt auch der Provider, um die Anbindung an Microsoft durchzuführen - NAT und BGP-Routing einrichten
Nun wird es interessant, da Sie z.B. den Übergang von ihrem privaten Netzwerk in die Express-Route-Verbindung natürlich per NAT konfigurieren müssen. Dazu müssen ihre internen Clients aber auch mit bekommen, welchen neuen besseren Weg es nun Richtung Office 365 gibt. Microsoft
Hallo ExpressRoute Provider in
Deutschland:
Wie können mir gerne Links zu entsprechend hilfreichen
Seiten für meine Leser senden.
- Azure ExpressRoute Cmdlets
https://msdn.microsoft.com/en-us/library/dn683813.aspx - Get-AzureBGPPeering
https://msdn.microsoft.com/en-us/library/dn683821.aspx - Set-AzureBGPPeering
https://msdn.microsoft.com/en-us/library/dn683819.aspx - Remote Access Cmdlets in Windows
PowerShell
https://technet.microsoft.com/library/hh918399(v=wps.630).aspx
Sie haben nun an mehreren Stellen den Begriff "BGP" gelesen. Viel mehr, als dass es ich dabei um ein Routing-Protokoll handelt, kann ich aktuell auf der MSXFAQ nicht beschreiben. Hier sind andere Webseiten und Personen gefragt, die eine solche "Netzwerkanbindung" korrekt ausführen
- Border Gateway Protocol
https://de.wikipedia.org/wiki/Border_Gateway_Protocol - Border Gateway Protocol (BGP) –
Übersicht
https://technet.microsoft.com/de-de/library/dn614183.aspx - Border Gateway Protocol (BGP) with
Windows Server 2012 R2
http://blogs.technet.com/b/networking/archive/2013/10/11/border-gateway-protocol-bgp-with-windows-server-2012-r2.aspx - Microsoft BGP Router configuration
automation
https://gallery.technet.microsoft.com/BGP-Router-configuration-e2bae411 - RFC 4271 - Border Gateway Protocol 4 (BGP-4)
- RFC 2545 - Use of BGP-4 Multiprotocol Extensions für IPv6 Inter-Domain Routing
- RFC 4760 - Multiprotocol Extensions für BGP-4
- RFC 5492 - Capabilities Advertisement with BGP-4
- RFC 5004 - Avoid BGP Best Path Transitions from One External to Another
- RFC 4760 - Multiprotocol Extensions für BGP-4
- RFC 4486 - Sub codes für BGP Cease Notification Message
- RFC 2918 - Route Refresh Capability für BGP-4
- RFC 2545 - Use of BGP-4 Multiprotocol Extensions für IPv6 Inter-Domain Routing
- RFC 1997 - BGP Communities Attribute
Videos und Vorträge
Microsoft publiziert natürlich auch einige Informationen:
- Azure ExpressRoute for Office
365 Training
https://channel9.msdn.com/Series/aer/
10 Sessions mit ca. 8h Dauer
RSS-Feed https://s.ch9.ms/Series/aer/feed/mp4high- Session 1 Connectivity to the Microsoft cloud https://channel9.msdn.com/Series/aer/Session-1-Connectivity-to-the-Microsoft-cloud
- Session 2 VNet and Hybrid Network https://channel9.msdn.com/Series/aer/Session-2-VNet-and-Hybrid-Network
- Session 3 Azure ExpressRoute Deep Dive https://channel9.msdn.com/Series/aer/Session-3-Azure-ExpressRoute-Deep-Dive
- Session 4 ExpressRoute for Office 365 overview and scenarios https://channel9.msdn.com/Series/aer/Session-4-ExpressRoute-for-Office-365-overview-and-scenarios
- Session 5 Office 365 SaaS Networking https://channel9.msdn.com/Series/aer/Session-5-Office-365-SaaS-Networking
- Session 6 Skype for Business Connectivity with ExpressRoute https://channel9.msdn.com/Series/aer/Session-6-Skype-for-Business-Connectivity-with-ExpressRoute
- Session 7 Implementation Planning https://channel9.msdn.com/Series/aer/Session-7-Implementation-Planning
- Session 8 Planning for network security and high availability https://channel9.msdn.com/Series/aer/Session-8-Planning-for-network-security-and-high-availability
- Session 9 Planning Integration with LANs https://channel9.msdn.com/Series/aer/Session-9-Planning-Integration-with-LANs
- Session 10 Troubleshooting Asymmetric Routing and other ExpressRoute Connectivity https://channel9.msdn.com/Series/aer/Session-10-Troubleshooting-Asymmetric-Routing-and-other-ExpressRoute-Connectivity
- ExpressRoute Fridays
https://channel9.msdn.com/Shows/ExpressRoute-Fridays
9 Sessions a ca 1 Stunde - ExpressRoute for Office 365 and other
Network Connection Options
https://channel9.msdn.com/Events/Ignite/2015/BRK2161
Weitere Links
-
Express Way
Nur so als Idee - Warum braucht es ExpressRoute wenn der Provider gut verbunden ist? - Express Route: Circuits und VLANs
- Express Route: IP-Routing
- Express Route: BGP
- Office 365 Netzwerkziele
- Office 365:WAN-Bandbreite
- CloudPBX
- Office 365:Audio Services
- Network Assessment
- ExpressRoute technical overview
https://azure.microsoft.com/en-us/documentation/articles/ExpressRoute-introduction/ - Office 365: Client connectivity
https://support.office.com/en-us/article/Client-connectivity-4232abcf-4ae5-43aa-bfa1-9a078a99c78b?ui=en-US&rs=en-US&ad=US - DNS geolocation for Office 365, connecting you to your
nearest Datacenter for the fastest connectivity
https://blogs.technet.microsoft.com/onthewire/2014/06/27/dns-geolocation-for-office-365-connecting-you-to-your-nearest-datacenter-for-the-fastest-connectivity/ - Netzwerkplanung und Leistungsoptimierung für Office 365
https://support.office.com/de-de/rticle/Netzwerkplanung-und-Leistungsoptimierung-f%C3%BCr-Office-365-e5f1228c-da3c-4654-bf16-d163daee8848?ui=de-DE&rs=de-DE&ad=DE - Announcing Azure ExpressRoute connectivity to Office 365
hhttps://blogs.office.com/2015/03/17/announcing-azure-ExpressRoute-connectivity-to-office-365/ - ExpressRoute - Experience a faster, private connection to
Azure
http://azure.microsoft.com/en-us/services/ExpressRoute/ - Network planning and performance tuning für Office 365
https://support.office.com/en-us/article/Network-planning-and-performance-tuning-for-Office-365-e5f1228c-da3c-4654-bf16-d163daee8848 - Azure ExpressRoute in Australia via Equinix Cloud Exchange
http://blog.kloud.com.au/2015/07/01/azure-ExpressRoute-in-australia-via-equinix-cloud-exchange/