Routing med ExpressRoute til Office 365

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.

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, er angivet i artiklen om Office 365-slutpunkter efter programtype og FQDN. Grunden til, at FQDN bruges i tabellerne, er at gøre det muligt for kunderne at administrere trafik ved hjælp af PAC-filer eller andre proxy-konfigurationer. De IP-adresser, som hvert enkelt af programmerne kræver, er opdelt på programniveau, ikke funktionsniveau. For hvert program, der er tilgængeligt over ExpressRoute, nævnes IP-adresseområder i en separat tabel, og de IP-adresseområder, der kun er tilgængelige via internettet og både internettet 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 af de FQDN'er, der er angivet til at blive annonceret til ExpressRoute og internettet, er altomfattende. I nogle situationer har vi brugt et jokertegn i en FQDN i en situation, hvor en eller flere under-FQDN'er er annonceret anderledes end den FQDN med jokertegn på et højere niveau. Dette sker typisk, når jokertegnet repræsenterer en lang liste med servere, der alle er annonceret til ExpressRoute og internettet, og der er et lille undersæt af servere eller CNAMEs, der kun er annonceret til internettet eller omvendt. Se tabellerne nedenfor for at forstå, hvor forskellene er.

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

*.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

Som regel er PAC-filer beregnet til at sende netværksanmodninger til ExpressRoute-annoncerede slutpunkter direkte til kredsløbet og alle andre netværksanmodninger til din proxyserver. Hvis du konfigurerer en PAC-fil på denne måde, skal du oprette PAC-filen i følgende rækkefølge:

  1. Medtag under-FQDN'er fra kolonne to i ovenstående tabel øverst i PAC-filen, hvilket sender trafikken mod din proxyserver.

  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.

Denne tabel viser FQDN'er med jokertegn, der kun er annonceret til internettet sammen med de under-FQDN'er, der er annonceret til Azure ExpressRoute og internettet. For PAC-filen herover angives FQDN'erne i kolonne to i den nedenstående tabel som annonceret til ExpressRoute i det 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. Beregning af det eksisterende brug er den eneste pålidelige metode til at afgøre dette i organisationen. Brug kun vores beregningsprogrammer som et udgangspunkt.

  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 svarene på disse spørgsmål, kan du klargøre et ExpressRoute-kredsløb, der opfylder kravene til båndbredde og placering. Hvis du ønsker mere hjælp til netværksplanlægning, kan du se vejledningen til justering af Office 365-netværk og casestudiet om, hvordan Microsoft håndterer planlægningen af netværksydeevnen.

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 er klar over, at noget trafik, f.eks. trafik, der er beregnet til netværk, der leverer indhold, ikke vil kunne routes over ExpressRoute til Office 365-forbindelsen. Da al trafik allerede som standard routes til proxyenheder, vil disse anmodninger blive ved med at fungere som hidtil. Efter at Trey Research har besluttet, at de kan imødekomme kravene til Azure ExpressRoute-routing, går de videre til at oprette et kredsløb, konfigurere routing og linke det nye ExpressRoute-kredsløb til et virtuelt netværk. Når den grundlæggende konfiguration af Azure ExpressRoute er udført, tilføjer Trey Research Office 365-slutpunkter, der understøttes af ExpressRoute til Office 365, til en automatisk proxykonfigurationsfil (PAC) eller URL-adresse for at dirigere trafik med kundespecifikke data over de 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 proxykonfigurationsfil (PAC) eller URL-adresse bruges til at dirigere trafik via et separat internetudgangspunkt for 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 implementering og administration af proxyindstillinger i Windows 8 og sikring af, at Office 365 ikke begrænses af din proxyserver.

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.

    Bemærk: BGP-communities frigives til ExpressRoute inden for kort tid.

Se også

Netværksforbindelse til Office 365

Azure ExpressRoute til Office 365

Netværksplanlægning med ExpressRoute til Office 365

Implementering af ExpressRoute til Office 365

Mediekvalitet og ydeevne for netværksforbindelse i Skype for Business Online

Optimering af dit netværk til Skype for Business Online

ExpressRoute og QoS i Skype for Business Online

Opkaldsflow ved hjælp af ExpressRoute

Brug af BGP-communities i ExpressRoute for Office 365-scenarier (eksempel)

Justering af ydeevne for Office 365 ved hjælp af oprindelige planer og historik for ydeevne

Fejlfinding af ydeevne i forbindelse med planen for Office 365

URL-adresser og IP-adresseområder for Office 365

Netværk og justering af ydeevnen for Office 365

Del Facebook Facebook Twitter Twitter Mail Mail

Var disse oplysninger nyttige?

Fantastisk! Har du mere feedback?

Hvordan kan vi forbedre det?

Tak for din feedback!

×