##Nettverkslaget og linklaget ###Router arkitektur ###Switch arkitektur ###Spanning tree protocol (STP) STP er en protocol som konstruerer at asyklisk nettverktopologi i Ethernetnettverk. Spanningtreeprotokillen er *ikke* en ruting protocol, det er en protokol som unngår sykler i et stadig endrende nettverk. Fjerningen av sykler forhindrer broadcast stormen 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 foredgling av tidligere ider * Stadig større behov for Active networking (in band) - Nettverk som lar pakker kunne dynamisk endre hvordan nettverket opererer. Aktive nettverk kan programerer til å gjøre forsjellige handlinger/endringer på pakker. * Større behov for programmable networking (out of band) - 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 imot 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 forwading (control/data plane) - Standarisert API imot nettelement - Samling av kontroll logikk. En *Sentralisert* kontroller * API impliserer en protokoll mellom kontroller og nettelement - Hovedsaklig Openflow * Kost effektivt fleksibilitet og innovasjon - Unngår lock-in, enkle nett element og sentralisert kontroll skalerer godt i cloud - Standardiserte grensensitt imot nett element * Samvirker med andre trender: - NFV (etwork function virtualization) - virtualisering og slicing ### 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 nett element (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 objecter 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 * 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 ####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 er også 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 å isntallere 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 elle 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 * 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)** * Statistikkf or hvert 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 * 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) **Nytt i v1.4:** utenfor pensum??? **Nytt i v1.5:** Ikke nevnt i pensum ##Ruting protokoller Det finnes flere ruting protokoller, noen som ikke er kompatible, andre som kan jobbe sammen. Vi skiller disse i to grupper: Inter og intra domene: * Interdomene 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 vidresending av ruting informasjon * Funksjoner for dirigering av trafikk * Intradomene er rutingen som foregår mellom domener * Fokus på effektiv formidling av ruting informasjon * Velge hvilken informasjon som burde og ikke burde videreformidles (BGP) ###RIP RIP er en protokoll som beregner beste sti i et nettverk ved å bruke en **distance vector** algoritme. ###Open Shortest Path First (OSPF) Har som mål å opprette et topologi kart over et rutingdomenet, og beregne beste vei mellom alle noder. Men algoritmer som dijkstra og belman-ford bruker mye trafikk og regnekraft når nettverket blir stort. OSPF er: * Distribuert * Hver ruter beregner rute til alle andre rutere * **Link state** protokoll * Hver node flooder til alle andre rutere i domenet tilstanden til sine linker * 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 forsjellige areaer som bryter problemet opp i mindre deler. * Backbone (area 0), med mange veier, alle inter-area trafikk krysse area 0 * Grenserutere ABR (Area Border Router) mellom area oppsummerer area til resten av nettet * Topologi innad i et area er ikke synelig utenfor area (noen få unntak når det gjelder eksterne rutere) * Synkroniseringa av link state database ##Border Gateway Protocol (BGP) ###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 en 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 den egest AS nummer * Brukes i rutevalget, den korteste listen med AS nummer foretrekkes * NEXT_HOP (mandatory)

* 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 all 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 Messages * Open * Etablerer forbindelse mellom to BGP rutere * Forbindelse mellom to BGP peers har en gitt levetid. Da unngår man zombie routers * Etter at begge sider har sendt open, så sendes keepalive før de deler rutetabellene sine med update * Update * Utveksler informasjon om topologi * Første gang så sendes hele rutetabellen, senere så sendes endringer (nye ruter og ruter som fjernes) * Notfication * Signalerer fatale feil. TCP-forbindelsen brytes etter meldingen er sendt * Keep Alive * Sendes for å unngå timeout ###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.