Routing med ExpressRoute til Office 365

Vigtigt: Denne artikel er maskinoversat. Se ansvarsfraskrivelsen. Du kan finde den engelske version af denne artikel her til din orientering.

For at forstå routing af trafik til Office 365 med Azure ExpressRoute må du sætte dig ind i de grundlæggende krav til ExpressRoute-routing og ExpressRoute-kredsløb og routingdomæner. Disse skitserer de grundlæggende elementer for brug af ExpressRoute, som Office 365-kunder er afhængige af.

Nogle af de vigtigste elementer, som du skal læse om i artiklerne ovenfor, omfatter:

  • ExpressRoute-kredsløb er ikke knyttet til en specifik fysisk infrastruktur, men er en logisk forbindelse, der er lavet på en enkelt peeringplacering af Microsoft og en peeringudbyder på dine vegne.

  • Der findes en 1:1-tilknytning mellem et ExpressRoute-kredsløb og en kundes s-tast.

  • Hvert kredsløb kan understøtte op til tre uafhængige peeringrelationer (offentlig Azure-peering, privat Azure-peering og Microsoft-peering). Office 365 kræver Microsoft-peering.

  • Hvert kredsløb har en fast båndbredde, der deles på tværs af alle peeringrelationer.

  • Offentlige IPv4-adresser og offentlige AS-tal, der skal bruges til ExpressRoute-kredsløb, skal være valideret som ejet af dig eller tildelt udelukkende til dig af ejeren af adresseområdet.

  • Selve ExpressRoute-kredsløbene er redundante og følger standardfremgangsmåderne for BGP-routing.

Se siden med ofte stillede spørgsmål for at få flere oplysninger om tjenesterne, der understøttes, omkostninger og konfigurationsoplysninger. Se artiklen om ExpressRoute-placeringer for at få oplysninger om listen over netværksudbydere, der tilbyder Microsoft-peeringsupport. Vi har også optaget et Azure ExpressRoute til Office 365-kursus i 10 dele på kanal 9, der kan hjælpe med at forklare begreberne nærmere.

Bemærk: Azure ExpressRoute til Office 365 fungerer endnu ikke sammen med IPv6. Du skal deaktivere IPv6. Ellers vil det som standard blive brugt, så ExpressRoute-forbindelsen ikke bliver brugt.

Infrastruktur, der accepterer kundetrafik for Office 365-programmer, er tilgængelige både på internettet og ExpressRoute eller på flere ExpressRoute-kredsløb. Netværkstrafik fra Office 365 til kundens netværk vil løbe i ExpressRoute-netværket, når både internet- og ExpressRoute er tilgængelige. Dette åbner op for muligheden for ruteasymmetri, hvis trafikken fra kundens netværk foretrækker internetruten. Asymmetriske ruter er et problem, da enheder, der udfører SPI, kan blokere returtrafik, der følger en anden sti, end de udgående pakker fulgte.

Når en kundes computer opretter forbindelse til Office 365 via internettet, skal kundens slutpunkter, der er tilknyttet anmodningen, kunne sendes offentligt. Det samme gælder for forbindelser, der er startet af kunden over ExpressRoute. For mange kunder med peering direkte hos Microsoft, er det ikke muligt at have private adresser, hvor duplikering er muligt mellem kunder.

Følgende er scenarier, hvor meddelelser fra Office 365 til dit lokale netværk startes:

Hvis Microsoft skal route tilbage til dit netværk for disse tovejstrafikstrømme, skal BGP-ruterne til dine lokale enheder deles med Microsoft.

Hvis du vil oprette forbindelse til Office 365 over et ExpressRoute-kredsløb, skal du konfigurere en peeringrelation ved hjælp af Microsoft-peeringroutingdomænet. Offentlig og privat Azure-peering er ikke påkrævet for Office 365. Der er dog tjenester, der er relateret til Office 365, som kræver offentligt Azure routing-domæne. Eksempelvis er Azure RemoteApp og Office 365 Management Pack bygget oven på Microsoft Azure. Som følge af at være et program, der er indbygget i Azure, er nogle af slutpunkterne tilgængelige via offentlig Azure-peering.

Andre programmer, f.eks. Office 365 Video, er et Office 365-program, men Office 365 Video består af tre forskellige komponenter: Portalen, streamingtjenesten og netværket til levering af indhold. Portalen findes i SharePoint Online, streamingtjenesten findes i Azure Media Services, og netværket til levering af indhold findes i Azure CDN. Følgende tabel skitserer disse komponenter.

Komponent

Underliggende program

Rutedomæne

Brug

Office 365 Video-portal

SharePoint Online

Microsoft-peering

Konfiguration, upload

Office 365 Video-streamingtjeneste

Azure Media Services

Offentlig Azure-peering

Streamingtjeneste, brugt i tilfælde af, at videoen er ikke tilgængelig fra CDN

Netværk til levering af indhold for Office 365 Video

Azure CDN

Ingen

Primær kilde til download af video/videostreaming. Lær mere om Office 365 videonetværk.

Mens Azure RemoteApp, Office 365 Management Pack og Office 365 Video er de eneste programmer, der har strenge afhængigheder på det offentlige Azure-routingdomæne, kræver flere programmer muligvis dette i fremtiden. For at forstå hvilke Office 365-funktioner og -programmer, der er tilgængelige, skal du se artiklen om Office 365-slutpunkter. For hvert angivne program er der en kolonne, som angiver, om funktionen er tilgængelig ved hjælp af Microsoft-peering eller ej.

Hver af de Office 365 funktioner, der er tilgængelige ved hjælp af Microsoft peering findes i Office 365 slutpunkter artikel ved programtype og fulde Domænenavn. Årsagen til at bruge det fulde Domænenavn i tabellerne er så kunderne kan administrere trafik ved hjælp af PAC filer eller andre proxy konfigurationer, skal du se vores vejledning til Administration af Office 365 slutpunkter for eksempel PAC filer. IP-adresser for, at hver af programmerne kræver er delt op på niveauet for programmet på computeren og ikke niveauet funktion. IP-adresseområder er nævnt i en separat tabel og IP-intervaller, der er tilgængelige via internettet kun for hvert program, der er tilgængelig via ExpressRoute, og internet- og ExpressRoute gennemgås.

Disse IP-adresser er grupperet i BGP-community-tags for at gøre administration af routing nemmere. Community-tags i brug omfatter:

Community-strengtag

Programmer, der følger med

Exchange

Exchange Online

Exchange Online Protection

Skype for Business

Skype for Business Online

SharePoint

SharePoint Online

Andre Office 365-tjenester

Portal og delt

Godkendelse og identitet

Office Online

De fleste FQDN'er er angivet som blive reklame for ExpressRoute og internettet er alt er inkluderet. Vi har brugt et jokertegn i en fulde Domænenavn i en situation, hvor en eller flere sub-FQDN'er meddeles anderledes end den højere niveau jokertegn fulde Domænenavn i nogle situationer. Dette sker normalt, når jokertegnet repræsenterer en lang liste over servere, der er alle reklame for ExpressRoute og internettet, og der er et lille underordnede sæt servere eller CNAMEs, der er kun reklame for internettet eller omvendt. Se i tabellerne nedenfor for at forstå, hvor der er følgende forskelle.

Denne tabel viser FQDN'er med jokertegn, der er annonceret til både internettet og Azure ExpressRoute sammen med de under-FQDN'er, der kun er annonceret til internettet.

FQDN med jokertegn annonceret til ExpressRoute og internettet

Under-FQDN kun annonceret til internettet

*.microsoftonline.com

click.email.microsoftonline.com

portal.microsoftonline.com

provisioningapi.microsoftonline.com

adminwebservice.microsoftonline.com

*.officeapps.live.com

NexusRules.officeapps.live.com

Nexus.officeapps.live.com

odc.officeapps.live.com

odc.officeapps.live.com

cdn.odc.officeapps.live.com

ols.officeapps.live.com

ocsredir.officeapps.live.com

ocws.officeapps.live.com

ocsa.officeapps.live.com

Normalt PAC-filer er beregnet til at sende netværksanmodninger til ExpressRoute annonceret slutpunkter direkte til kredsløbet og alle andre netværksanmodninger til din proxy. Hvis du er ved at konfigurere en PAC fil således, Skriv PAC filen i følgende rækkefølge:

  1. Medtag under-FQDN'er fra kolonne to i ovenstående tabel øverst i PAC-filen, som sender trafikken mod din proxyserver. Vi har bygget en PAC-eksempelfil, som du kan bruge i vores artikel om administrering af Office 365-slutpunkter.

  2. Medtag alle FQDN'er, der er markeret som annonceret til ExpressRoute i denne artikel under det første afsnit, hvilket sender trafikken direkte til dit ExpressRoute-kredsløb.

  3. Medtag andre netværksslutpunkter eller regler under disse to elementer, hvilket sender trafikken mod din proxyserver.

I denne tabel viser jokertegn FQDN'er, meddeles til internettet kun sammen med de sub-FQDN'er, der er annoncerede Azure ExpressRoute og på internettet. Til filen PAC over FQDN'er i kolonne to i den nedenstående tabel vises som blive reklame for ExpressRoute i feltet link, der refereres til, hvilket betyder, at de skal medtages i den anden gruppe af poster i filen.

FQDN med jokertegn kun annonceret til internettet

Under-FQDN annonceret til ExpressRoute og internettet

*.office.com

*.outlook.office.com

home.office.com

portal.office.com

www.office.com

*.office.net

agent.office.net

*.office365.com

outlook.office365.com

smtp.office365.com

*.outlook.com

*.protection.outlook.com

*.mail.protection.outlook.com

*.windows.net

login.windows.net

Hvis du vil route til et Office 365-program efter eget valg, skal du fastlægge en række vigtige faktorer.

  1. Hvor meget båndbredde programmet kræver. Indsamle eksisterende brugen er den kun pålidelig metode til at bestemme dette i organisationen. Bruge vores lommeregnere kun til at validere testen.

  2. Fra hvilket udgangspunkt/hvilke udgangspunkter ønsker du, at netværkstrafikken forlader dit netværk. Du skal planlægge at minimere netværksventetiden for forbindelsen til Office 365, da dette vil påvirke ydeevnen. Da Skype for Business anvender stemme og video i realtid, er det særligt udsat for dårlig netværksventetid.

  3. Hvis du vil have alle eller et undersæt af dine netværksplaceringer til at udnytte ExpressRoute.

  4. Hvilke placeringer din valgte netværksudbyder tilbyder ExpressRoute fra.

Når du har afgjort svarene på disse spørgsmål, kan du klargør et ExpressRoute kredsløb, der opfylder behovet båndbredde og placering. Se i Office 365 netværk justering vejledning og Casestudie på hvordan Microsoft håndtag-ydeevne planlægningpå flere netværk planlægning Hjælp.

Eksempel 1: En enkel geografisk placering

Dette eksempel er et scenarie for et fiktivt firma, Trey Research, der har en enkelt geografisk placering.

Medarbejdere på Trey Research må kun oprette forbindelse til de tjenester og websteder på internettet, som sikkerhedsafdelingen udtrykkeligt giver tilladelse til på de to udgående proxyservere, der står mellem virksomhedens netværk og internetudbyderen.

Trey Research planlægger at bruge Azure ExpressRoute til Office 365 og registrerer, at nogle trafik som trafik bestemt til levering af indhold netværk vil ikke kunne omdirigere over ExpressRoute til Office 365 forbindelse. Da alle trafik allerede omdirigerer til proxy-enheder som standard, vil disse anmodninger fortsat fungerer som før. Når Trey Research bestemmer de kan opfylder Azure ExpressRoute routing krav, fortsætte de konfigurere routing og sammenkæde det nye ExpressRoute kredsløb med et virtuelt netværk for at oprette et kredsløb. Når grundlæggende Azure ExpressRoute konfigurationen er på plads, tilføjer Trey Research Office 365 slutpunkterne understøttes af ExpressRoute til Office 365 til en automatisk proxy-konfigurationsfil (PAC) eller URL-adressen til at dirigere trafik med bestemte kundedata over direkte ExpressRoute til Office 365 forbindelser.

Som vist i det følgende diagram er Trey Research i stand til at opfylde kravet om at dirigere Office 365-trafik via internettet og et undersæt af trafik over ExpressRoute ved hjælp af en kombination af konfigurationsændringer i routing og udgående proxy.

  1. En automatisk proxy-konfigurationsfil (PAC) eller URL-adresse bruges til at dirigere trafik via en separat internet udgangspunkt til Azure ExpressRoute til Office 365.

  2. Kunder er konfigureret med en standardrute mod Trey Researchs proxyservere.

I dette eksempelscenarie bruger Trey Research en udgående proxyenhed. På samme måde kan kunder, der ikke bruger Azure ExpressRoute til Office 365, bruge denne metode til at dirigere trafik baseret på prisen for at undersøge trafik, der er målrettet kendte slutpunkter med stor volumen.

Følgende er FQDN'er med højest volumen til SharePoint Online og Skype for Business Online:

ExpressRoute med kundegrænsenetværk
  • outlook.office365.com

  • outlook.office.com

  • <tenant-name>.sharepoint.com

  • <tenant-name>-my.sharepoint.com

  • <tenant-name>-<app>.sharepoint.com

  • *.Lync.com

Få mere at vide om installation og administration af proxyindstillinger i Windows 8 og sikre, at Office 365 ikke begrænset af din proxy.

Med et enkelt ExpressRoute-kredsløb er der ingen høj tilgængelighed for Trey Research. I tilfælde af at Treys reduntante grænseenheder, der behandler ExpressRoute-forbindelsen, mislykkes, er der ikke et ekstra ExpressRoute-kredsløb til failover. Herved sættes Trey Research i en svær position, da failover til internettet kræver manuel omkonfiguration og i nogle tilfælde nye IP-adresser. Hvis Trey ønsker at tilføje høj tilgængelighed, er den mest enkle løsning at tilføje yderligere ExpressRoute-kredsløb.

Det sidste scenarie, Routing af Office 365-trafik over ExpressRoute, er grundlaget for endnu mere kompleks routingarkitektur. Uanset antallet af steder, antal kontinenter, hvor disse placeringer eksisterer, antal ExpressRoute-kredsløb og så videre kan det være nødvendigt at omdirigere noget trafik til internettet og noget trafik over ExpressRoute.

De yderligere spørgsmål, der skal besvares for kunder med flere forskellige placeringer i flere geografiske områder, omfatter:

  1. Kræver de et ExpressRoute-kredsløb på hvert enkelt sted? Ved brug af Skype for Business, eller hvis kunden er bekymret over følsomhed over for ventetid for SharePoint Online og Exchange Online, anbefales et ExpressRoute-kredsløb på alle de kontinenter, hvor kunden har kontorer. Se vejledningen for mediekvalitet og ydeevne for netværksforbindelse i Skype for Business for at få flere oplysninger.

  2. Hvis et ExpressRoute-kredsløb ikke er tilgængeligt i et bestemt område, hvordan skal Office 365-bestemt trafik så routes?

  3. Hvad er den foretrukne metode til at konsolidere trafik i netværk med mange små placeringer?

Hver af disse præsenterer en unik udfordring, der kræver, at du evaluerer dine egne netværk og de indstillinger, der er tilgængelige fra Microsoft.

Overvejelse

Netværkskomponenter, der skal evalueres

Kredsløb på mere end én placering

Omkostninger, latenstid og båndbreddebehov skal sammenlignes.

Brug omkostninger til BGP-routing, PAC-filer og NAT til at administrere routing med flere kredsløb.

Routing fra placeringer uden et ExpressRoute-kredsløb

DNS-videresendelse kan bruges til at tillade, at eksterne kontorer kan finde det relevante slutpunkt.

Klienter med fjernkontorer skal have en rute tilgængelig, der giver adgang til ExpressRoute-kredsløbet.

Konsolidering af lille kontor

Tilgængelig båndbredde og brug af data skal sammenlignes omhyggeligt.

Bemærk: Microsoft vil foretrække ExpressRoute via internettet, hvis ruten er tilgængelig uanset den fysiske placering.

Hver af disse overvejelser skal tages i betragtning for hvert entydige netværk. Nedenfor er et eksempel.

Eksempel 2: Flere geografiske placeringer

Dette eksempel er et scenarie for et fiktivt firma, der kaldes Humongous Insurance, som har flere geografiske placeringer.

Humongous Insurance er geografisk spredt med kontorer over hele verden, som vil implementere Azure ExpressRoute til Office 365 for at beholde størstedelen af deres Office 365-trafik på direkte netværksforbindelser. Humongous Insurance har også kontorer på to yderligere kontinenter. Medarbejdere i fjernkontoret, hvor ExpressRoute ikke er muligt, skal omdirigere tilbage til en af de to primære faciliteter for at bruge en ExpressRoute-forbindelse.

Det ledende princip er at få trafik, der er bestemt for Office 365, til et Microsoft-datacenter så hurtigt som muligt. I dette eksempel skal Humongous Insurance beslutte, om deres fjernkontorer skal omdirigere over internettet for at få adgang til et Microsoft-datacenter via en forbindelse så hurtigt som muligt, eller om deres fjernkontorer skal omdirigere via et internt netværk for at nå et Microsoft-datacenter over en ExpressRoute-forbindelse så hurtigt som muligt.

Microsofts datacentre, netværk og programarkitektur er designet til at tage globalt separat kommunikation og servicere den på den mest effektive måde. Anmodninger, der er bestemt til Office 365, og som forbliver på kundens netværk længere end nødvendigt, vil ikke kunne udnytte denne arkitektur.

I Humongous Insurances situation bør de fortsætte, afhængigt af de programmer, de har til hensigt at bruge over ExpressRoute. Hvis de f.eks. er en Skype for Business Online-kunde, eller de har planer om at udnytte ExpressRoute-forbindelsen, når de opretter forbindelse til eksterne Skype for Business Online-møder, er det anbefalede design i vejledningen for mediekvalitet og ydeevne for netværksforbindelse i Skype for Business at klargøre et ekstra ExpressRoute-kredsløb til den tredje placering. Dette kan være dyrere fra et netværksperspektiv, men routinganmodninger fra ét kontinent til et andet før levering til et Microsoft-datacenter kan medføre en dårlig eller ubrugelig oplevelse under Skype for Business Online-møder og -kommunikation.

Hvis Humongous Insurance ikke anvender eller har planer om at bruge Skype for Business Online på nogen måde, kan routing af netværkstrafik, der er bestemt til Office 365, tilbage til et kontinent med en ExpressRoute-forbindelse, være mulig. I begge tilfælde anbefales det at dirigere trafik, der er bestemt for internettet, til internettet på det lokale websted for at drage fordel af de netværk til levering af indhold, som Office 365 afhænger af.

ExpressRoute med multigeografi

Når Humongous Insurance planlægger deres multigeografiske strategi, er der nogle ting, de skal overveje vedrørende kredsløbets størrelse (gennemgås her), antal kredsløb, failover osv.

Med ExpressRoute på en enkelt placering i flere regioner, der forsøger at bruge kredsløbet, ønsker Humongous Insurance at sikre, at forbindelser til/fra Office 365 fra fjernkontoret sendes til det Office 365-datacenter, der ligger nærmest hovedkontoret og modtages på hovedkontoret. For at gøre dette implementerer Humongous Insurance DNS-videresendelse for at reducere antallet af ture og DNS-opslag, der kræves til at oprette den relevante forbindelse med det Office 365-miljø, der er tættest på hovedkontorets internetudgangspunktet. Du kan også lære at tildele en betinget videresendelse for et domænenavn.

I dette scenarie kan trafik fra fjernkontoret løse Office 365 frontend-infrastrukturen i Nordamerika og bruge Office 365 til at oprette forbindelse til back end-serverne i overensstemmelse med arkitekturen i Office 365-programmet. F.eks. vil Exchange Online afbryde forbindelsen i Nordamerika, og disse front end-servere vil oprette forbindelse til back end-postkasseserveren, uanset hvor lejeren var bosiddende. Se Klientforbindelse for at få flere oplysninger om, hvordan hvert program er skabt til at håndtere kundens forbindelse.

Hvis Humongous har større kontorer på flere kontinenter, anbefales mindst ét kredsløb pr. kontinent for at reducere ventetiden for følsomme programmer som f.eks Skype for Business. Hvis alle kontorer er på et enkelt kontinent eller ikke anvender samarbejde i realtid, er dét at have et konsolideret eller distribueret udgangspunkt en kundespecifik beslutning, som afhænger af antallet af personer pr. placering, brug af programmet på hver placering, krav til høj tilgængelighed og så videre. Når der findes flere kredsløb, sikrer BGP-routing failover, hvis et enkelt kredsløb ikke længere er tilgængeligt.

Lær mere om eksempel på routingkonfigurationer og https://azure.microsoft.com/en-us/documentation/articles/expressroute-config-samples-nat/.

Selektiv routing med ExpressRoute kan være nødvendigt til forskellige formål, f.eks. test og udrulning af ExpressRoute til et undersæt af brugere. Der findes forskellige værktøjer, som kunder kan bruge til selektivt at dirigere Office 365-netværkstrafik over ExpressRoute:

  1. Omdirigere filtrering/opdeling – tillade BGP-ruter til Office 365 over ExpressRoute til et undersæt af undernet eller routere. Dette dirigerer selektivt efter kundenetværkssegment eller fysisk placering af kontor. Dette er fælles for forskudt implementering af ExpressRoute til Office 365.

  2. PAC-filer/URL-adresser – dirigere netværkstrafik, der er bestemt til Office 365, til bestemte FQDN'er på en bestemt sti. Dette dirigerer selektivt efter klientcomputeren som identificeret af PAC-filinstallationen.

  3. BGP-communities – filtrering, der er baseret på BGP-community-tags gør det muligt for en kunde at bestemme, hvilke Office 365-programmer kan krydse ExpressRoute, og hvilke kan krydse internettet.

Her er et kort link, du kan bruge til at komme tilbage: https://aka.ms/o365ip6

Relaterede emner

Netværk forbindelse til Office 365
Azure ExpressRoute til Office 365
Administrere ExpressRoute til Office 365 connectivity
netværksplanlægning med ExpressRoute til Office 365
Implementere ExpressRoute til Office 365
Media kvaliteten og netværk Connectivity ydeevnen i Skype for Business Online
optimering af dit netværk til Skype for Business Online
ExpressRoute og QoS i Skype for Business Online
ringe flow ved hjælp af ExpressRoute
ved hjælp af BGP community'er i ExpressRoute til Office 365 scenarier
justering af ydeevnen i Office 365 ved hjælp af grundlinjer og ydeevne historik
ydeevne, fejlfinding i forbindelse med planen til Office 365
Office 365 URL-adresser og IP-adresseområder
Office 365 Netværks- og justering af ydeevnen

Bemærk: Ansvarsfraskrivelse for maskinoversættelse: Denne artikel er blevet oversat af et computersystem uden menneskelig indgriben. Microsoft tilbyder disse maskinoversættelse for at hjælpe ikke-engelsktalende brugere til at kunne nyde indhold om Microsofts produkter, tjenester og teknologier. Da artiklen er maskinoversat, kan den indeholde forkerte ord eller syntaks- eller grammatikfejl.

Udvid dine færdigheder
Gå på opdagelse i kurser
Få nye funktioner først
Bliv Office Insider

Var disse oplysninger nyttige?

Tak for din feedback!

Tak for din feedback! Det lyder, som om det vil kunne hjælpe, hvis du bliver sat i forbindelse med en af vores Office-supportteknikere.

×