Ruting med ExpressRoute for Office 365

Viktig: Denne artikkelen er maskinoversatt, se ansvarsfraskrivelsen. Du finner den engelske versjonen av artikkelen her som referanse.

For å forstå trafikkruting til Office 365 ved bruk av Azure ExpressRoute, trenger du en god forståelse for de viktigste rutingkravene for ExpressRoute og kretser og rutingsdomener for ExpressRoute. Disse artiklene gir grunnleggende informasjon for bruk av ExpressRoute, og denne informasjon er viktig for Office 365-kunder.

Noen av de viktigste elementene i artiklene ovenfor som du må forstå, omfatter:

  • ExpressRoute-kretser tilordnes ikke til noen bestemt fysisk infrastruktur, men er en logisk forbindelse etablert på en enkelt nodenettplassering av Microsoft og en nodenettleverandør på dine vegne.

  • Det er en 1:1-tilordning mellom en ExpressRoute-krets og en kunde-s-nøkkel.

  • Hver krets kan støtte opptil 3 uavhengige nodenettrelasjoner (Azure Private-nodeplassering, Azure Private-nodefordeling og Microsoft-nodeplassering); Office 365 krever Microsoft-nodefordeling.

  • Hver krets har en fast båndbredde som deles på tvers av alle nodenettrelasjoner.

  • Alle offentlige IPv4-adresser og offentlige AS-tall som skal brukes for ExpressRoute-kretsen, må være godkjent som din eiendom eller tilordnet utelukkende til deg av eieren av adresseområdet.

  • ExpressRoute-kretser er i seg selv overflødige globalt og følger standard praksiser for BGP-ruting.

Se Vanlige spørsmål-siden for mer informasjon om tjenestene som støttes, kostnader og konfigureringsdetaljer. Se artikkelen om ExpressRoute-plasseringer for informasjon om listen over tilkoblingsleverandører som tilbyr kundestøtte for Microsoft-nodefordeling. Vi har også registrert en 10-dels Azure ExpressRoute for Office 365-opplæring-serie på Channel 9 for å forklare konseptene mer grundig.

Merknad: Azure ExpressRoute for Office 365 fungerer ikke med IPv6 ennå. Du må deaktivere IPv6, for ellers vil tilkoblingen bruke IPv6 som standard i stedet for ExpressRoute-tilkoblingen.

Infrastrukturen som godtar kundetrafikk for Office 365-programmer, er tilgjengelig på Internett og ExpressRoute eller på flere ExpressRoute-kretser. Nettverkstrafikk fra Office 365 til kundenettverket går gjennom ExpressRoute når både Internett og ExpressRoute er tilgjengelige. Dette innebærer en fare for asymmetri i rutingen dersom trafikk fra kundenettverket foretrekker Internett-ruten. Asymmetriske ruter er et problem fordi enheter som utfører tilstandsavhengig pakkeinspeksjon kan blokkere returtrafikk som følger en annen bane enn de utgående pakkene fulgte.

Når en kundedatamaskin etablerer en tilkobling til Office 365 via Internett, må kundens endepunkter tilknyttet forespørselen kunne rutes offentlig. Det samme gjelder for kundeetablerte tilkoblinger over ExpressRoute. Ettersom mange kunder bruker nodenett direkte med Microsoft, er det å ha private adresser der duplisering er mulig mellom kunder, ikke gjennomførbart.

Følgende er scenarioer der kommunikasjon fra Office 365 til det lokale nettverket blir startet:

For at Microsoft skal kunne rute tilbake til nettverket ditt for disse toveistrafikkflytene, må BGP-rutene til de lokale enhetene dine deles med Microsoft.

For å koble til Office 365 over en ExpressRoute-krets må du konfigurere en noderelasjon ved hjelp av noderutingsdomenet for Microsoft. Nodenett for Azure Public og Private er ikke nødvendig for Office 365. Det finnes imidlertid tjenester relatert til Office 365 som krever Azure Public-rutingsdomenet. For eksempel er Azure RemoteApp og administrasjonspakken for Office 365 basert på Microsoft Azure. Siden det er et program som er innebygd i Azure, er noen av endepunktene tilgjengelige over Azure Public-nettverksnoding.

Andre programmer som Office 365 Video er et Office 365-program, men Office 365 Video består av tre ulike komponenter, portalen, direkteavspillingstjenesten og innholdsleveringsnettverket. Portalen er plassert i SharePoint Online, direkteavspillingstjenesten er i Azure Media Services og innholdsleveringsnettverket finner du i Azure CDN. Tabellen nedenfor gir en oversikt over disse komponentene.

Komponent

Underliggende program

Domene for ruting

Bruk

Office 365-videoportal

SharePoint Online

Microsoft-nodenett

Oppsett, last opp

Office 365 Video direkteavspillingstjeneste

Azure Media Services

Azure offentlig nodenett

Direkteavspillingstjeneste, som brukes i tilfelle videoen ikke er tilgjengelig fra CDN-tjenesten

Innholdsleveringsnettverk for Office 365 Video

Azure CDN

Ingen

Primær kilde for nedlasting/direkteavspilling av video. Finn ut mer om Office 365 videonettverk.

Azure RemoteApp, altså Office 365-administrasjonspakken og Office 365 Video er de eneste programmene som har faste avhengigheter på rutingdomenet for Azure Public, men flere programmer kan kreve dette i fremtiden. For å forstå hvilke Office 365-funksjoner og -programmer som er tilgjengelige, kan du lese deg opp med artikkelen om Office 365-endepunkter. Det finnes en kolonne for hvert oppførte program som angir om funksjonen er tilgjengelig med Microsoft-nodenett eller ikke.

Hver av Office 365-funksjonene som er tilgjengelige ved hjelp av Microsoft peering er oppført i Office 365 endepunktene artikkelen ved programtypen og FQDN. Hvorfor bruke FQDN i tabellene er slik at kundene kan administrere trafikk ved hjelp av PAC filer eller andre proxy-konfigurasjoner, kan du se våre veiledning for å Administrere Office 365 endepunktene for eksempel PAC filer. IP-adressene alle programmene krever er delt opp i det programmet og ikke funksjonen nivå. For alle programmene som er tilgjengelig over ExpressRoute, IP-adresseområder omtales i en egen tabell og IP-områder som er tilgjengelige via Internett bare og Internett og ExpressRoute vises detaljert.

Disse IP-adressene er gruppert i BGP-fellesskapskoder for å gjøre administrering av ruting enklere. Blant annet følgende fellesskapskoder er i bruk:

Fellesskaps-strengkode

Programmer som er inkludert

Exchange

Exchange Online

Exchange Online Protection

Skype for Business

Skype for Business Online

SharePoint

SharePoint Online

Andre Office 365-tjenester

Portal og delt

Godkjenning og identitet

Office Online

De fleste FQDN-er oppført som blir annonsert til ExpressRoute og Internett er alle inklusive. I enkelte situasjoner har vi brukt jokertegn i en FQDN i en situasjon der én eller flere sub-FQDN-er ved hjelp av annerledes enn høyere nivå jokertegn FQDN. Dette skjer vanligvis når jokertegnet representerer en lang liste med servere som alle ved hjelp av til ExpressRoute og Internett og er et lite sekundære sett med servere eller CNAMEs bare ved hjelp av til Internett, eller omvendt. Se tabellene nedenfor for å forstå hvor forskjellene er.

Denne tabellen viser jokertegn-FQDN-er som er annonsert til Internett og Azure ExpressRoute sammen med under-FQDN-er som kun er annonsert på Internett.

Jokertegn-FQDN annonsert til ExpressRoute og Internett

Under-FQDN annonsert til Internett utelukkende

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

Vanligvis PAC filer er ment å sende nettverksforespørsler til ExpressRoute annonsert sluttpunkt direkte til kretsen og alle andre nettverk forespørsler om å proxy-serveren. Hvis du konfigurerer en PAC-fil slik ut, Skriv PAC filen i følgende rekkefølge:

  1. Ta med under-FQDN-er fra kolonne to i tabellen ovenfor øverst i PAC-filen, slik at trafikken sendes mot proxy-serveren. Vi har utviklet en PAC-eksempelfil du kan bruke i vår artikkel på administrere Office 365-endepunktene.

  2. Inkluder alle FQDN-er som er merket som annonsert til ExpressRoute i denne artikkelen nedenfor den første inndelingen, slik at trafikken direkte sendes til ExpressRoute-kretsen.

  3. Inkluder eventuelle andre nettverksendepunkter eller regler under disse to postene, slik at trafikken sendes til proxy-serveren.

Denne tabellen viser jokertegn FQDN-er som ved hjelp av Internett bare sammen med de sub-FQDN-er som er annonsert Azure ExpressRoute og Internett. For PAC filen ovenfor, FQDN-er i to-kolonnen i den under tabellen, er oppført som blir annonseres til ExpressRoute i koblingen refererer til, noe som betyr at de er inkludert i den andre gruppen oppføringene i filen.

Jokertegn-FQDN annonsert kun til Internett

Under-FQDN annonsert til ExpressRoute og Internett

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

For å rute til Office 365-programmet du foretrekker, må du finne ut av en rekke viktige faktorer.

  1. Hvor mye båndbredde programmet krever. Utvalg eksisterende Bruk er bare pålitelig metode for å fastsette dette i organisasjonen. Bruke våre kalkulatorer bare til å validere testingen.

  2. Hvilke utgangsplassering(er) du vil at nettverkstrafikken skal forlate nettverket ditt fra. Du bør planlegge å minimere nettverksventetid for tilkobling til Office 365, da dette vil påvirke ytelsen. Fordi Skype for Business bruker sanntidstale og -video er det spesielt utsatt for dårlig nettverksventetid.

  3. Hvis du vil at alle eller et delsett av nettverksplasseringene dine skal utnytte ExpressRoute.

  4. Hvilke plasseringer din valgte nettverksleverandør tilbyr ExpressRoute fra.

Når du har funnet ut svarene på disse spørsmålene, kan du legge til en ExpressRoute krets som dekker behovene båndbredde og plassering. For mer nettverket planlegging hjelp, kan du se Office 365-nettverket justering veiledningen and eksempelstudie på hvordan Microsoft håndtakene på nettverket ytelse planlegging.

Eksempel 1 Enkel geografisk plassering

Dette eksemplet er et scenario for et fiktivt firma ved navn Trey Research som har én enkelt geografisk plassering.

Ansatte ved Trey Research er bare tillatt å koble til tjenestene og nettstedene til Internett som er eksplisitt tillatt av sikkerhetsavdelingen, via paret med utgående proxyer som sitter mellom firmanettverket og deres Internett-leverandør.

Trey Research har tenkt å bruke Azure ExpressRoute for Office 365 og gjenkjenner at noen trafikk for eksempel trafikk skal sendes til levering av innhold nettverk ikke vil kunne rute over ExpressRoute for Office 365 tilkobling. Siden alle trafikk allerede ruter til proxy-enheter som standard, vil disse forespørsler fortsette å fungere som før. Når Trey Research bestemmer de kan de kravene Azure ExpressRoute ruting, fortsette de å opprette en krets, konfigurerer ruting og koble den nye ExpressRoute kretsen til et virtuelt nettverk. Når grunnleggende Azure ExpressRoute konfigurasjonen er på plass, legger Trey Research Office 365 endepunktene støttes av ExpressRoute for Office 365 til en automatisk proxy-konfigurasjonsfil (PAC) eller URL-adressen til å rute trafikk med bestemte kundedata over direkte ExpressRoute for Office 365 tilkoblinger.

Som vist i følgende diagram kan Trey Research oppfylle kravet om å rute Office 365-trafikk over Internett og et delsett av trafikken over ExpressRoute ved hjelp av en kombinasjon av ruting og konfigurasjonsendringer for utgående proxy.

  1. En automatisk proxy-konfigurasjonsfil (PAC) eller URL-adressen brukes til å rute trafikk via en separat Internett-utgangspunktet for Azure ExpressRoute for Office 365.

  2. Klienter er konfigurert med en standardrute mot Trey Research-proxyer.

I dette eksempelscenarioet bruker Trey Research en utgående proxyenhet. På samme måte vil kunder som ikke bruker Azure ExpressRoute for Office 365 kanskje bruke denne teknikken til å rute trafikk basert på kostnaden av å undersøke trafikk som er ment for velkjente endepunkter med høyt volum.

FQDN-ene med høyest volum for Exchange Online, SharePoint Online og Skype for Business Online er følgende:

ExpressRoute Edge-nettverk for kunde
  • outlook.office365.com

  • outlook.office.com

  • <tenant-name>.sharepoint.com

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

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

  • *.Lync.com

Lære mer om distribuere og administrere proxy-innstillingene i Windows 8 og sørge for at Office 365 ikke er begrenset av proxy-serveren.

Med én enkelt ExpressRoute-krets er det ingen høy tilgjengelighet for Trey Research. I tilfelle Treys overflødige par med edge-enheter som vedlikeholder ExpressRoute-tilkoblingen, feiler, er det ikke noen ekstra ExpressRoute-krets som kan brukes som failover. Dette er svært alvorlig for Trey Research, da å ikke slå over til Internett vil kreve manuell rekonfigurering og i noen tilfeller nye IP-adresser. Hvis Trey ønsker å legge til høy tilgjengelighet, er den enkleste løsningen å legge til flere ExpressRoute-kretser.

Det siste scenarioet, altså å rute Office 365-trafikken over ExpressRoute, danner grunnlaget for en enda mer kompleks rutingsarkitektur. Uavhengig av hvor mange plasseringer, antall kontinenter der disse plasseringene finnes, antall ExpressRoute-kretser og så videre, er det nødvendig å kunne rute noe trafikk over Internett og noe trafikk over ExpressRoute.

Ytterligere spørsmål som må besvares for kunder med flere plasseringer i flere områder omfatter blant annet:

  1. Krever de en ExpressRoute-krets i hver plassering? Hvis det brukes Skype for business eller kunden er bekymret for latenssensitivitet for SharePoint Online eller Exchange Online, anbefales en ExpressRoute-krets i hvert kontinent der kunden har kontorer. Se mediekvalitet for Skype for Business og veiledningen for nettverkskonnektivitet for mer informasjon.

  2. Hvis en ExpressRoute-krets ikke er tilgjengelig i en bestemt region, hvordan skal da trafikk som er ment for Office 365, rutes?

  3. Hva er den foretrukne metoden for å konsolidere trafikk når det gjelder nettverk med mange små plasseringer?

Hver av disse utgjør en unik utfordring som krever at du evaluerer dine egne nettverk i tillegg til alternativene som er tilgjengelige fra Microsoft.

Spesielle hensyn

Nettverkskomponenter å evaluere

Kretser på mer enn en plassering

Behov for kostnad, båndbredde og ventetid må sammenlignes.

Bruk BGP-rutingkostnad, PAC-filer og NAT til å administrere ruting med flere kretser.

Ruting fra plasseringer uten noen ExpressRoute-krets

DNS-videresending kan brukes til å tillate eksterne kontorer å oppdage det aktuelle endepunktet.

Klienter i det eksterne kontoret må ha en rute tilgjengelig som gir tilgang til ExpressRoute-kretsen.

Konsolidering av lite kontor

Tilgjengelig båndbredde og databruk skal sammenlignes nøye.

Merknad: Microsoft foretrekker ExpressRoute via Internett hvis det er tilgjengelig, uansett fysisk plassering.

Hver av disse vurderingene må tas hensyn til for hvert unike nettverk. Nedenfor finner du et eksempel.

Eksempel 2: Flere geografiske plasseringer

Dette eksemplet er et scenario for et fiktivt firma kalt Humongous Insurance som har flere geografiske plasseringer.

Humongous Insurance er geografisk utspredt med kontorer over hele verden, og de skal implementere Azure ExpressRoute for Office 365 for å holde mesteparten av Office 365-trafikken deres på direkte nettverkstilkoblinger. Humongous Insurance har også kontorer på to andre kontinenter. De ansatte på det eksterne kontoret der ExpressRoute ikke er gunstig å implementere, må rute tilbake til én av de to primære fasilitetene for å bruke en ExpressRoute-tilkobling.

Det styrende prinsippet er å hente trafikk myntet på Office 365 til et Microsoft-datasenter så raskt som mulig. I dette eksemplet må Humongous Insurance bestemme om de eksterne kontorene bør rute over Internett til et Microsoft-datasenter over en hvilken som helst tilkobling så raskt som mulig, eller om de eksterne kontorene bør rute over et internt nettverk til et Microsoft-datasenter over en ExpressRoute-tilkobling så raskt som mulig.

Microsofts datasentre, nettverk og programarkitektur er utformet for å ta globalt uensartede kommunikasjoner og betjene dem på den mest effektive måten. Forespørsler ment for Office 365 som forblir på kundenettverk lenger enn nødvendig, vil ikke kunne dra nytte av denne arkitekturen.

I situasjonen for Humongous Insurance avhenger fremgangsmåten deres av programmene de har tenkt å bruke over ExpressRoute. Hvis de for eksempel er en Skype for Business Online-kunde, eller de har tenkt å bruke ExpressRoute-tilkobling når de kobler til eksterne Skype for Business Online-møter, anbefales følgende fremgangsmåte i veiledningen for mediekvalitet og nettverkstilkobling for Skype for Business: å legge til en ekstra ExpressRoute-krets for den tredje plasseringen. Dette kan være dyrere fra et nettverksperspektiv, men ruting av forespørsler fra ett kontinent til et annet før levering til et Microsoft-datasenter kan føre til en dårlig eller ubrukelig opplevelse under Skype for Business Online-møter og -kommunikasjon.

Hvis Humongous Insurance ikke bruker eller ikke har tenkt å bruke Skype for Business Online på noen måte, kan det være gunstig å rute nettverkstrafikk ment for Office 365 til et kontinent med en ExpressRoute-tilkobling. I begge tilfeller anbefaler det å rute Internett-myntet trafikk til det lokale nettstedet, for å dra nytte av innholdsleveringsnettverkene som Office 365 baserer seg på.

ExpressRoute med flere geografiske steder

Når Humongous Insurance planlegger sin strategi for flere geografiske områder, finnes det flere ting å vurdere rundt størrelsen på krets (nevnt her), antall kretser, failover og så videre.

Med ExpressRoute på én enkelt plassering med flere områder som prøver å bruke kretsen, ønsker Humongous Insurance å sikre at tilkoblinger til/fra Office 365 fra det eksterne kontoret sendes til Office 365-datasenterets nærmeste hovedkontor og mottas ved hovedkontorets fysiske plassering. For å gjøre dette implementerer Humongous Insurance DNS-viderekobling for å redusere antall rundturer og DNS-oppslag som kreves for å opprette den nødvendige tilkoblingen til Office 365-miljøet som ligger nærmest utgangspunktet for hovedkvarterets Internett-tilkobling. Du kan også lære å tilordne en betinget videresender for et domenenavn.

I dette scenarioet kan trafikk fra det eksterne kontoret løse infrastrukturen for frontenden for Office 365 i Nord-Amerika og benytte Office 365 for å koble til bakservere i henhold til arkitekturen til Office 365-programmet. For eksempel ville Exchange Online avsluttet tilkoblingen i Nord-Amerika, og disse frontserverne ville koblet til postboks-bakserveren der leieren befant seg. Se Klienttilkobling for mer informasjon om hvordan hvert program er designet til å håndtere kundetilkoblinger.

Hvis Humongous har større kontorer på flere kontinenter, anbefales minst én krets per kontinent for å redusere ventetiden for sensitive programmer som for eksempel Skype for Business. Hvis alle kontorer er på ett enkelt kontinent, eller ikke bruker samarbeid i sanntid, er det å ha et konsolidert eller distribuert utgangspunkt en kundespesifikk beslutning som ville avhengt av antall personer per plassering, bruk av programmet ved hver plassering, høye krav til tilgjengelighet og så videre. Når flere kretser er tilgjengelige, sikrer BGP-ruting failover dersom en enkeltkrets blir utilgjengelig.

Finn ut mer om eksemplarer av rutingkonfigurasjoner og https://azure.microsoft.com/en-us/documentation/articles/expressroute-config-samples-nat/.

Selektiv ruting med ExpressRoute kan være nødvendig av en rekke årsaker, for eksempel testing og distribuering av ExpressRoute til et delsett av brukere. Det finnes forskjellige verktøy kundene kan bruke til å selektivt rute Office 365-nettverkstrafikk over ExpressRoute:

  1. Ruting av filtrering/isolering – slik at BGP-rutene til Office 365 over ExpressRoute til et delsett av delnett eller rutere. Dette ruter selektivt etter kundenes nettverksegment eller fysisk kontorplassering. Dette er vanlig for forskjøvet utrulling av ExpressRoute for Office 365.

  2. PAC-filer/URL-adresser – henviser nettverkstrafikk ment for Office 365 for bestemte FQDN-er til å rute på en bestemt bane. Dette ruter selektivt etter klientdatamaskin som identifisert ved distribusjon av PAC-fil.

  3. BGP-fellesskap – filtrering basert på BGP-fellesskapskoder lar en kunde avgjøre hvilke Office 365-programmer som skal gå gjennom ExpressRoute og som skal gå via Internett.

Her er en kort kobling du kan bruke til å komme tilbake: https://aka.ms/erorouting

Beslektede emner

Nettverkstilkobling til Office 365
Azure ExpressRoute for Office 365
Administrere ExpressRoute for Office 365-tilkobling
nettverksplanlegging med ExpressRoute for Office 365
Implementering av ExpressRoute for Office 365
Media kvalitet og nettverksytelsen tilkobling i Skype for Business Online
optimalisering av nettverket for Skype for Business Online
ExpressRoute og QoS i Skype for Business Online
ringe flyt ved hjelp av ExpressRoute
ved hjelp av BGP fellesskap i ExpressRoute for Office 365-scenarier
Office 365 ytelsesjustering ved hjelp av referanseverdier og ytelse loggen
ytelse feilsøking plan for Office 365
Office 365-nettadresser og IP-adresseområder
Office 365-nettverket og ytelsesjustering

Merknad: Ansvarsfraskrivelse for maskinoversettelse: Denne artikkelen er oversatt av et datasystem i stedet for en oversetter. Microsoft tilbyr disse maskinoversettelsene slik at brukere som ikke snakker engelsk, får tilgang til innhold om Microsoft-produkter, -tjenester og –teknologier. Ettersom artikkelen er maskinoversatt, kan den inneholde feil i vokabular, syntaks eller grammatikk.

Utvid ferdighetene dine
Utforsk opplæring
Vær først ute med de nye funksjonene
Bli med i Office Insiders

Var denne informasjonen nyttig?

Takk for tilbakemeldingen!

Takk for tilbakemeldingen! Det høres ut som det kan være lurt å sette deg i kontakt med én av våre Office-kundestøtteagenter.

×