TTM4180: Nettverkshåndtering
Nettverkslaget og linklaget
ARP
Brukes i det lokale nettet for å finne MAC addressen til en destinasjon med en gitt IP-adresse. Prosedyren er å floode IP-addressen med ARP-pakker ved å sette MAC dest til FF:FF:FF:FF:FF:FF, for deretter lytte på svar fra enheten med den tilhørende IP-addressen.
Dynamic Host Configuration Protocol (DHCP)
Når en ny enhet kobler seg til nettverket så trenger den en IP-addresse. DHCP brukes til dette.
DNS (Domain name service)
Brukes for å matche en gitt adresse (for eksempel google.no) til en IP.
Distance vector
Link state
Spanning Tree Protocol (STP)
STP er en protokoll som konstruerer en asyklisk nettverkstopologi i Ethernetnettverk. Spanningtreeprotokollen er ikke en ruting protokoll, det er en protokoll som unngår sykler i et stadig endrende nettverk. Fjerningen av sykler forhindrer broadcaststormen som learningswitcher kan produsere. Denne topologien blir installert i flyttabellene til switchene.
Spanningtree velger en root og vil nivå for nivå utvide nettverket til alle nodene er dekket(tenk minimalt spenntre). Beste vei bestemmes av den kumulative linkkostnaden, utledet av båndbredden. En kan spesifisere en rekke kriterier for å få entydige valg av stier. Ubrukte/overflødige linker blir blokkert.
Software Defined Networking (SDN)
Historie
- SDN bygger på mange forskningsprosjekter.
- Er en foredling av tidligere ideer
- Stadig større behov for Active networking
- Nettverk som lar pakker kunne dynamisk endre hvordan nettverket opererer. Aktive nettverk kan programmeres til å gjøre forskjellige handlinger/endringer på pakker.
- Større behov for programmable networking
- Nettverket kan programmeres, typisk på flyt nivå.
- Håndtere spesielle pakkeheadere som VLAN, MPLS
- Arv: programmable functions in the network, demultiplex based on headers, unified middlebox construction
- Splitter kontroll og forwarding
- Linux Netlink, Force
- Et åpent interface inn mot dataplanet
- Sentralisert kontroll
- Fleksibilitet
- PCE(Path computation element) systemer hadde manglende funksjonalitet i IP forwading, ruting
- Arv: sentralisert kontroll, distributed state management
- Hadde stor suksess pga timing med cloud
Hva er SDN
SDN var et buzzword som dekker mye. SDN sine hovedtrekk er:
- Skille mellom kontroll og forwarding (control/data plane)
- Standarisert API imot nettelement
- Samling av kontrollogikk. En Sentralisert kontroller
- API impliserer en protokoll mellom kontroller og nettelement
- Hovedsaklig Openflow
- Kostnadseffektivt, fleksibilitet og innovasjon
- Unngår lock-in, enkle nettelement og sentralisert kontroll skalerer godt i cloud
- Standardiserte grensensitt mot nettelement
- Samvirker med andre trender:
- NFV (Network function virtualization)
- virtualisering og slicing
- NFV (Network function virtualization)
Kontroller
Det finnes mange ulike standardiseringsløp (Pox, opendaylight, Ryu, NodeFlow, osv...) Disse har som fellestrekk:
- Interface imot applikasjoner (North)
- Det er ingen standarisering på funksjonalitet
- De fleste kontrollere implementerer et HTTP REST grensesnitt
- Interface imot nettelement (South)
- Openflow mest brukt
- Interface imot andre kontrollere (East/West)
- Flere kontrollere som jobber sammen som enten likeverdige eller som mester/slaver.
- Gir redundans, robusthet og load sharing
Pox
Pox implementerer openflow 1.0, og tilrettelegger et biblotek for å håntere diverse hendelser, gjøre topology discovery, DHCP, Ping, Arp, med ulike forwarding komponenter som learningswitch og hub.
Callback:
- Brukes for å håndtere asynkrone hendelser/events.
- Du registrerer callbacks for hver pakke type (Hello, Packet_in, flow_removed, osv...)
- En kan registrere funksjoner eller objekter som lytter på flere events.
Openflow
Openflow er den mest brukte protokollen til å interagere med nettelementer. All kommunikasjon mellom switch og kontroller gjøres med openflow. Igjennom openflow kan man installere og endre på flows(filtere eller matcher i flyttabellene) med tilsvarende aksjoner(send til port A, drop, osv...) som blir gjort hvis en pakke matcher en flow. En openflow svitsj har flere utgående porter, som enten er fysiske eller logiske(flood, all, local, controller, in_port, normal, table). Nyere openflow svitsjer har også flere køer. En fysisk port kan ha flere køer med forsjellige prioriteter. På denne måten kan man implementere QoS. (Quality of Service)
Openflows funksjonalitets krav
- Forhandle protokoll versjon fordi Openflow ikke er bakover kompatibel
- Heartbeat, status på forbindelse
- Sende pakke til kontroller
- Sende pakke til svitsj
- Konfigurere svitsj
- Konfigurere køer
- Hente statistikk
- Event notifikasjoner fra svitsj
- Endre av port statuser eller feil
Openflow sine funksjoner/meldinger kan deles inn i tre grupper:
- Symmetriske
- initieres av både kontroller og svitsj. Hello, Echo, og vendor er symmetriske
- Kontroller-svitsj
- Meldinger som kun sendes fra kontrolleren til svitsjen. Her inngår svitsj konfigurering, statistikk, CFC (command from controller)
- packet_out, flow_mod, port_mod
- Meldinger som kun sendes fra kontrolleren til svitsjen. Her inngår svitsj konfigurering, statistikk, CFC (command from controller)
- Asynkron
- Meldinger som skal kunne bli sendt når som helst etter at oppkoblingen mellom svitsj og kontroller har blitt opprettet. For det meste forsjellige events som intreffer:
- packet_in, flow_remove, port_status, error
- Meldinger som skal kunne bli sendt når som helst etter at oppkoblingen mellom svitsj og kontroller har blitt opprettet. For det meste forsjellige events som intreffer:
Pakke prosessering:
Svitsjen vil prossesere alle pakkene som kommer inn på en port på dataplanet. Den vil lete igjennom flyttabellen sin etter én enkelt match. Den første raden som matcher pakken vil få sin tilhørende aksjoner utført. Flyttabellen er leksikalt ordnet etter prioritet og hvor spesifikk matchen er.
En match kan være IP src, IP dest, IP TOS, MAC src, MAC dest, port in, port ut, VLAN id, VLAN prioritet, osv... (se bilde over)
Openflow v1.0 og v1.1 har et lite sett med headerverdier den kan matche. de verdiene som ikke brukes får wildchar verdier istedet. IP adresse kan ha bitmaske.
Openflow v1.2 og oppover implementerer Extensible Matching (OXM) som kan matche det meste. Dette lagres som TLV verdier og er derfor utvidbart.
Aksjoner som kan gjøres når en pakke blir matchet kan være:
- drop
- send til kontroller
- sender pakkeheaderene + buffer id
- send til kø/port
- modifisert felt
- push/pop header
Det finnes også aksjoner for pakker som ikke matcher en flyt. Send to controller eller drop er standard. Ved å installere en flyt med wildchar på alle felt fjernes no match logikken
Openflow versjoner:
Nytt i v1.1:
- Multiple flyt tabeller
- Enklere logikk for matching av felt
- Hvert filter legger til action
- Action utføres etter siste match i siste tabell, ordning av rekkefølge på actions
- Copy ttl inwards, pop, push,copy ttl out, decrement ttl, set field, QoS, group, out
- Groups (mutlicast og tunnelering)
- Entry peker på en eller flere action buckets
- Port og action assosiert med bucket
- To ulike bruksområder
- En action bucket: Ruting entry for mange flyter, tunnellering
- Flere action bucket: Multicast
- Entry peker på en eller flere action buckets
- MPLS og VLAN tag støtte
- pus, pop, PLS header, generalisert
- Svitsj defined virtual ports
Nytt i v1.2:
- Extensible Matching support
- TLV (type-length-value) for å beskrive felt som skal brukes i filter
- Extensible set_field packet rewrite support
- CRC prosessering inkludert
- Utvidet metadata i packet_in
- Port_in, virtual port_in context data ifra prosessering i de ulike flyttabellene ikke spesifisert
- Grunn til packet_in, no match, instruction in pipeline, TTL error
- Multiple kontrollere
- Master, slave, like
- Definer utveksling av openflow meldinger, typer og logikk
Nytt i v1.3:
- Per flow meters (QoS)
- Statistikk for hver entry: summen av alle flows som bruker entry
- Hver entry har en liste med meter band
- Hver band angir en båndbredde, counter og tilhørende aksjon:
- Drop, DSCP remarking
- Det band som har høyeste lavere båndbredde enn målte båndbredde for entry brukes
- Dersom ingen match, ingen aksjon
- Normal bruk
- Maks båndbredde mappes til samme meter entry
- Ett meterband 2000, action remark dscp 42
- Maks båndbredde mappes til samme meter entry
- Per connection event filtering + Tillegs forbindelser (skalering med multiple kontrollere)
- Cookies in packet_in for å effektivisere kontroller prosessering (skalering)
- Prioritet i flow entry, time outs (bedre funksjonalitet)
- PBB tagging (utvidet bruksområde)
Ruting protokoller
Det finnes flere ruting protokoller, noen som ikke er kompatible, andre som kan jobbe sammen. Vi skiller disse i to grupper: Intra og inter domene:
- Intradomene er det som foregår innenfor ditt domene
- Hvordan bygge topologien innenfor domenet
- Sette opp regler for peering og transit avtaler
- reflekterer forretningsmodellen
- filtrering
- selektiv videresending av ruting informasjon
- Funksjoner for dirigering av trafikk
- reflekterer forretningsmodellen
- Interdomene er rutingen som foregår mellom domener
- Fokus på effektiv formidling av ruting informasjon
- Velge hvilken informasjon som burde og ikke burde videreformidles (BGP)
I et nettverk med flere rutingprotokoller kan det være nødvendig å utveklse rutinginformasjon. Forsjellige protokoller bruker forsjellige metrikker, og nettverkadministratoren kan derfor sette administrativ distanse for å prioritere mellom to ulike protokoller når de finner to ulike ruter til samme destinasjon.
Routing Information Protocol (RIP)
RIP er en intradomene rutingprotokoll som beregner beste stier i et nettverk ved å bruke en distance vector algoritme. Den beste vei er den med færrest antall hopp. Protokollen har en hopp grense på 15 hopp for å unngå løkker, og bredere nettverk ansees derfor som ugyldige. Endringer i et RIP nettverk propagerer/konvergerer treigt.
Open Shortest Path First (OSPF)
OSPF er en intradomeneprotokoll som har som mål å opprette et topologikart over et rutingdomene, og beregne beste vei mellom alle noder. OSPF er en link state protokoll som bygger en nettverkstopologi og beregner stiene ut ifra dette. Dette betyr at endringer i nettverket blir oppdaget og håndtert mye raskere enn i RIP. Men denne utvekslingen bruker mye trafikk, og algoritmer som Dijkstra og Bellman-Ford bruker mye regnekraft når nettverkene blir store. OSPF er en egen protokoll på toppen av IP (protokoll 89).
OSPF er:
- Distribuert
- Hver ruter beregner rute til alle andre rutere
- Link state protokoll
- Hver node flooder tilstanden til sine linker til alle andre rutere i domenet
- Hver link er assosiert en metrikk
- Hver node regner ut sin korteste vei til alle andre rutere
- Dijkstras algoritme
- Hierarkisk
- Dijkstras algoritme blir fort dyr: O(|E| + |V| log |V|) Deler derfor opp nettverket i forskjellige areas som bryter problemet opp i mindre deler.
- Backbone (area 0), med mange veier, all inter-area-trafikk krysser area 0
- Grenserutere ABR (Area Border Router) mellom areas oppsummerer area til resten av nettet
- Topologi innad i et area er ikke synlig utenfor area (noen få unntak når det gjelder eksterne rutere)
- Synkroniseringen av link state database
- Intradomene nodene skal alle se samme informasjon => flooding, ingen filtrering
- Link State => finne nabo
- Signalisere endringer => flooding er upålitelig, så sekvensnummer brukes og setter alder på endringer
- Shortest path krever konsistent topologi database => signaliserer endring, synkroniserer LS database
- Ulike alternative veier kan gi forskjellig topologi => link og nettmetrikk bestemmer
- Linkoppgradering krever ressurser, overhead, CPU
- Kostbart med flate nett
- Oppdatering er bare relevant i et begrenset område
- Deler derfor inn i subnett/area
- Trenger rutere som tilhører flere area (ABR), har derfor forskjellige oppgaver for rutere
- Rutere sammenkoblet med Ethernet gir mange logiske forbindelser mellom rutere
- OSPF velger derfor et knutepunkt per ethernet
- Designated Router (DR) og Backup Designated Router (BDR) implementerer en form for multicasting innenfor et Ethernett nettverk
- OSPF velger derfor et knutepunkt per ethernet
- Kostbart med flate nett
- Inndeling i sammenkoblede subnett (area)
- Alle area må henge sammen
- Har derfor backbone (area 0) og stubber
- Topologi-informasjon aggregert på grensen mellom subnett/area
- Aggregering på grenserutere (ABR), signaliserer konnektivitet til nett
- Sammenhengenede nettaddresser tildelt på bit grenser per area
- Aggregering på grenserutere (ABR), signaliserer konnektivitet til nett
- Signaliserer endring i nett, link, eksterne nett
- ulike LSA (link state announcement) typer.
- Link
- nett
- eksterne nett
- sammenkoblingspunkter
- ulike LSA (link state announcement) typer.
- Alle area må henge sammen
Metrikker
- Standard Dijkstra forutsetter additive linkkostnader:
- Kost per byte, delay, antall hopp er additive
- Bitrate eller feilrate er derimot ikke en additiv metrikk
- Kost per link er ikke spesifisert i OSPF RFC
- Cisco anbefalte 100millioner / båndbredde i bits per sec
- Proposjonal med transmisjon delay
- Cisco anbefalte 100millioner / båndbredde i bits per sec
Area
- Backbone area kalles Area 0
- Alle andre area har en eller flere felles grenserutere (ABR) med backbone
- Hvert area har en unik ID
- Area = separat nettverk med gitt maske
- All inter-area trafikk passerer gjennom Area 0
- Hver ruter i et area ser kun area topology, andre area kun representert som sammendrag (med bitmasker)
- Konsepter:
- Internal router
- ABR (Area Border Router)
- Beregnet ruter i flere area
- Kan oppsummere ruter under et area til et annet
- ASBR (AS border router) (AS = Autonomous System)
- Importerer ruter fra andre AS eller rute protokoller
- Virtuell link fra area 0 til et annet area gjennom et av de andre area'ene (mellom ABR)
- Ikke et godt oppsett, og brukes kun midlertidig under utbygging
Forsjellige typer Area:
- Area kan ha forskjellige funksjoner og derfor forskjellige krav til utveksling av ruteinformasjon
- Backbone
- Trenger stor båndbredde
- Vanlig area
- Stub area
- Default rute gjennom ABR til eksterne nettverk, inter-area rute via ABR, intra-area ruter-topologi innen area utveksles ikke med resten av areaene
- Totally stubby area
- Default rute gjennom ABR for alt unntatt intra-area-trafikk
- Not so stubby area (NSSA)
- Stub area som kan ha en ASBR ruter.
- Designet for nettverk med uforventet vekst
Area og ulike type LSA
Det finnes mange ulike typer ruter:
- Intra-area rute til destinasjon i samme area
- Resultat av Dijkstras algoritme på area DB
- Inter-area rute til destinasjon i annen area
- Path til ABR, ABR in til ABR out i Area 0, path til destinasjon i area
- Ekstern rute type 1
- Rute via en ASBR ruter
- Kost = kost i eksternt nett + kost til ASBR ruter
- Obs: kost i eksternt nett er ofte default verdi
- Rute via en ASBR ruter
- Ekstern rute type 2:
- Rute via en ASBR ruter
- Kost = kost i eksternt nett
- Obs: kost i ekstern nett er ofte default verdi
- Rute via en ASBR ruter
For dette finnes det flere typer LSA (Link State Announcement) pakker som sendes mellom ruterne:
- Type 1 Router:
- Beskriver punkt til punkt linker innenfor et area
- Intra-area informasjon
- Type 2 Network:
- Linker over ethernet valg av DR og BDR (Designated Router)
- Linker som brukes til broadcasting
- Type 3 Summary:
- Sammendrag av et area sendt fra ABR ut til Area 0 og videre
- Forenkler hele subnett ned til en enkel addresse og bitmaske
- Type 4 ASBR Summary:
- Ruten til en ASBR sendt fra ABR ut til Area 0 og videre
- Type 5 External:
- Beskriver nett utenfor OSPF
- Inneholder addresse og bitmaske + ASBR ID + forwarding gateway
- Type 7 External NSSA:
- Samme som type 5, men går ikke utenfor area.
- ABR kan oversette denne til type 5 hvis det må videreformidles
Versjon 3 av OSPF (IPv6) har flere LSA og noen endrede definisjoner
Alle LSA pakker har følgende felt:
- Sekvensnummer
- max age
- LSA Type
- linkid
- utsteder id
- varierende felt avhengig av type
OSPF prosess
- Etablering av nabo
- Utveksling av Hello pakker, synkronisering, fastslå adjacency
- Signalere endringer til resten av verden
- Sender Link State Announcements om link/nettverk/eksterne ruter
- Periodisk (default hver 30 min), og når linker endres
- Multicast istedet for flooding, med hjelp av DR
- Synkronisering av topologi database med nabo
- 4 way handshake
Innenfor et ethernet:
- Velge en Designated Router (DR) og Backup Designated Router (BDR)
- Standard prosess med Hello. Høyeste private addresse blir DR
- Ved å bruke en ruter til å broadcaste reduserer man n*(n-1)/2 naboskap til n
- DR sprer topologi info på link (type 2 LSA)
Border Gateway Protocol (BGP)
BGP er en protokoll, benyttet i blant annet kjernen av internett, for å utveksle rutinginformasjon mellom forskjellige AS (Autonomous System). Protokollen er beskrevet som en Path Vector protokoll. BGP er en rutingprotokoll som søker etter beste vei under en gitt nettverkspolitikk, som kan variere fra AS til AS.
Forretningsmodellene
Det finnes to hovedmodeller: Peering og Transit. Disse gir ulike kostnader for trafikkstrømmer
Transit
En transitavtale er avtale som tillater trafikk å krysse et nettverk imot betaling. Mindre ISPer kjøper ofte transitt gjennom andre AS for å bli koblet opp imot resten av internett. I transitavtaler betaler man ofte for mengden trafikk som sendes.
Peering
En peeringavtale åpner en direkte forbindelse mellom AS, der hvert AS bærer egne interne kostnader og ingen trafikkostnad. Det finnes unntak dersom det er kraftig asymmetri i mengden trafikk. Peering kan foregå på to forskjellige måter: Peering gjennom en peeringsentral, eller privat peering. I bilateral peering forhandler hver ISP frem egne avtaler og setter egne filtre. I multilateral peering annonserer alle alle rutene sine, men unngår å bruke peeringen som default. CDN (Content Delivery Network) firmaer blir ofte med i peeringsentraler, som reduserer transitkostnadene til ISPer.
Oppbygging av BGP
Internett har to nivå ruting pga skalering: 1. nivå frem til eier av prefix, 2. nivå innen et AS (f.eks OSPF eller RIP). BGPs oppgave er å formidle AS path frem til et prefix, rutene internt i et AS synes ikke av skaleringshensyn. Det er ingen plikt å formidle pakker mellom AS, kun egen interesse. Funksjonalitet henger derfor sammen med økonomisk operasjonelle hensyn mellom ulike ISP.
Funksjonalitet
- Formidle AS path til et prefix kun mellom AS. Rute internt i et AS synes ikke
- Siden topologi innen AS er ukjent har additative metrikker ingen verdi.
- Metrikker kun på AS egenskaper
- Prefiks og sekvens av AS:
- Mange path alternativer
- Må angi IP addresse til ruter inn i AS, next hop attributt
- ikke sterkt knyttet til IP addressering multiprotokoll BGP
- Alle AS path som formidles vil gå igjennom formidler
- Signalerer villighet til å videreformidle
- Siden topologi innen AS er ukjent har additative metrikker ingen verdi.
- Ingen plikt til å formidle pakker mellom AS, kun egeninteresse
- rutefiltre
- signaler for å utrykke preferanser, kontekst
- Ingen flooding av BGP informasjon
- Eksplisitt forbindelser mellom BGP rutere i ulike AS.
- Bruker TCP, som gjør synkronisering mindre viktig
- Styrt flooding, risiko for feil, må kunne oppdage ruting loops.
- Gjøres ved å inspisere AS path
- Ingen ende til ende garanti
- Noen må ha ansvar for at ISP har rute til alle prefix
- Må formidle BGP informasjon mellom to eksterne BGP rutere i samme AS
- eBGP og iBGP protokoller: samme protokoll, kun små forsjeller
- Basis funksjonalitet:
- Utveksle informasjon om konnektivitet til prefix
- Network Layer Reachability Information (NLRI)
- Annonsere en ny rute
- Trekke tilbake en gammel rute
- Trekke tilbake alle ruter dersom en BGP forbindelse brytes
- Flooder NLRI til utvalgte AS via BGP peering rutere
- Utveksle informasjon om konnektivitet til prefix
- Protokoll i utvikling
- Utvidbar protokoll => forsjellig funksjonalitet i ulike AS
- Må ha mulighet til forhandling av funksjonalitet
- BGP må være i stand til å hoppe over ukjente elementer
- TLV (type-length-value)
- BGP på vite hva en skal gjøre med ukjente elmenter:
- neglisjere
- videresende, transitive
- Skalering, sikkerhet, konvergens, QoS
- Bruksområder for BGP
- Interdomene ruteprotokol eBGP
- Intradomene informasjonsutveksler iBGP
- Utvidet til andre protokoll familier
- MBGP multiprotocol
- Mye av BGP informasjonen er uavhengig av protokollfamilie
- Utvidbar protokoll => forsjellig funksjonalitet i ulike AS
eBGP og IBGP
iBGP (internal BGP) og eBGP(external BGP) er samme protokoll, men med ulike roller. eBGP brukes mellom forsjellige AS mens iBGP sørger for at alle grenseruterene i et AS samarbeider som et sammenhengende AS. eBGP bruker AS_path for å unngå loops. Dette gir ingen mening internt siden alt er samme AS ID. iBGP rutere knytter seg til en reflektor som har et felles repository av policies og regler.
Filtrering og routing policy
En ISP har mulighet til å velge hvilken trafikk den skal forwarde, velge hvilke linker som skal brukes, velge hvem det skal være mulig å nå og velge sikkerhet. Det å drive ett datanettverk kan være kostbart. Derfor kan det være viktig å minimere mengden traffikk selskapet ikke får betalt for.
Hver rute er assosiert med attributter (RIB / Routing Information Base). Dette inneholder en ekstern prefix og andre attributter som uttrykker preferanse, og en intern prefix med metrikker. Dette kan resultere i annonsering (hvilken trafikk som ønskes inn) og akseptering (hvor skal trafikk gå).
En RPSL regel har formen: (Routing Policy Specification Language)
- "Import"/"Export"
- Ulike filter id:
- AS identifisering
- AS ID, eller et set med AS
- Rute
- Addresse nasjem origin + elementer for å beskrive egenskaper
- Ruter identifisering, fra hvilken, til hvilken
- Addresse
- AS identifisering
- Aksjoner
- Accept, endre felt i utgående melding
- Beskrivende felt
- Eierskap
- Rolle, personer
- Eierskap
- Tilgjengelighet
- www.irr.net
Annonsering og akseptering av ruting
- Basis regler:
- Kun annonser prefix som en ønsker å være transit ISP for
- Unntak peering partnere og eget prefix
- Filtrer ut private addresserom
- Filtrere ut addresserom for management og kontroll
- Kun prefix hvor next hop er kjent
- (absolutt krav gjøres automatisk i BGP path selection)
- Kun annonser prefix som en ønsker å være transit ISP for
- Prosess:
- 4 virtuell RIB
- Adjacent rib, de rå annonseringene ifra nabo rutere.
- Filtrering av disse inn til Lokal RIB.
- Main RIB inneholder aggregeringene av alle ruter.
- Main rib til Adjacent RIB Out filtrering ut ifra policy
- Både inn- og utgående rib gir mulighet for ¨minimalisere ruteoppdateringer pga policy endringer
- Gracefull restart
- 4 virtuell RIB
- Forwarding policy kommer i tillegg
- Kun forward trafikk ifra src innenfor eget tildelt addresserom
- Vanskeliggjør multihoming og mobilitet
- Kun forward trafikk ifra src innenfor eget tildelt addresserom
Rutevalg
Når BGP skal velge hvilke ruter den skal bruke sjekker den dette:
- Ulike attributter for å uttrykke hva som foretrekkes
- Rutevalg med ulike scope
- Local preference (internt valg BGP)
- Påvirke utgående path i fra eget AS
- MED (multiexit discriminator)
- brukes ved flere utgående alternativer til samme AS
- Sendes fra AS
- Påvirke hvordan nabo ruter kommer til eget AS
- Community
- Felt for å signalere tillhørighet
- Ingen standardisert mekanisme for å utrykke preferanse ovenfor AS som ikke er direkte tilknyttet
- Filtreres/påvirkes på veien av andre AS
- Intet kundeforhold mellom to non-adjacent AS, hvorfor bry seg?
- Local preference (internt valg BGP)
- Rutevalg med ulike scope
- Default rute
- kortest AS path
Rutevalg bestemmes av:
- Mere spesifikk rute
- Lengre maske enn tidligere
- Ny rute kan sees som et spesialtilfelle
- Velg rute med høyert local_preference (kun iBGP)
- Lokalt origin
- AS_path length
- interior origin
- Lowest med
- Through lowest IGP nabo
- Lavest origin ID
- Ulike regler for ulike leverandører, kan spesifiseres
- Reglene ifra RIB til FIB er annerledes
Oppbygging
BGP har 5 message typer med TLV koding. (4 omtalt i boken)
- Open
- Etablere forbindelse mellom to BGP rutere
- Forhandle ulike timere, frekvens, autentisering, kapabiliteter
- Forbindelse mellom to BGP peers har gitt levetid
- Unngå zombie rutere
- Etablere forbindelse mellom to BGP rutere
- Keep alive
- Unngå at en forbindelse brytes på timeout
- Notification
- Signalere fatale feil
- Forbindelse brytes
- Signalere fatale feil
- Update
- Route Refresh
- (Bruk av denne signaleres som en kapabilitet)
- Soft start av rute DB synkronisering
TLV attributter har reserverte bit for å signalere:
- Optional
- transitive
- partial change by intermediate
- extended length
Attributes
- ORIGIN (mandatory)
- Forteller mottaker om kilden til BGP sendingen (ENG: This attribute conveys the source of the BGP announcement). IGP, EGP eller incomplete.
- Selv om den er mandatory så har ikke attributten noen stor funksjon i praksis
- AS_PATH (mandatory)
- AS path er liste som består av alle AS nummer mellom ruteren og kilden til ruten.
- Forhindrer routing loops ved at en ruter ignorerer alle ruter den mottar som inneholder dens eget AS nummer
- Brukes i rutevalget, den korteste listen med AS nummer foretrekkes
-
NEXT_HOP (mandatory)
- Inneholder IP-adressen til neste ruter som vil akseptere pakker *The next hop attribute contains the IP address of the router within the remote AS that will accept packets for the current route.
-
MULTI_EXIT_DISC
- Angir preference mellom ruter til samme AS
- Propageres ikke videre
- Brukes ikke i iBGP, siden den bestemmer preferanser på ruter mellom AS
- Foretrekker ruten med lavest MED
- LOCAL_PREF
- Brukes til å vise preferanse internt i et AS (iBGP)
- BGP velger alltid ruten med høyest Local Preference
- Cisco default er 100
- COMMUNITIES
- En rute kan inneholde en eller flere communities.
- Et tag for å merke tilhørlighet til en rute
- 32-bit verdi, uttrykt som 701:120 dr 701 er AS nummeret og 120 er et tall med mening innad i AS 701
- Brukes ikke direkte i rutevalget, men de kan utløse brukerdefinerte handlinger
- Kan brukes i load balancing f.eks
- ATOMIC_AGGREGATE
- Indikerer at et AS sender en mindre spesifikk rute (en aggregert rute, dvs et adresserom)
- AGGREGATOR
- Contains the last AS number that formed the aggregate route, followed by the IP address of the BGP speaker that formed the aggregate route
BGP States
Idle
The router isn't trying to set up a BGP session, and if the neighbor were to attempt to create a session, the TCP connection would be refused. The router waits for a "start" event, typically the user enabling BGP or adding a neighbor or an interface coming up.
Connect
In this state, the router waits for its own TCP session establishment attempt to complete, and it listens for incoming TCP sessions
Active
BGP is waiting for a TCP session
OpenSent
The open message has been sent, but an open message hasn't yet been received from the neighbor.
OpenConfirm
The open message from the neighbor has been received, but not yet the initial keepalive message that completes the BGP session setup phase.
Established
The initial keepalive message has been received, and the session is now ready for transmission of update, keepalive, and notification messages.
Routing Information Base (RIB)
A routing table will only store one route per destination, while the RIB usually contains multiple routes. The RIB keeps track of routes that could possibly be used. If a route withdrawal is received and it only existed in the RIB, it is silently deleted from the RIB. No update is sent to peers. RIB entries never time out. They continue to exist until it is assumed that the route is no longer valid.