##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...) 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 ### 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 ###RIP ###Open Shortest Path First (OSPF) ##Border Gateway Protocol (BGP) ###Attributes *ORIGIN -tells the receiver the type of original src of NLRI inf *AS_PATH -contains a list of ASs traversed *NEXT_HOP -defines the IP-address of the next-hop router to be used for the next hop for all dsts listed in the NLRI field of the UPDATE message *MULTI_EXIT_DISC (kun i eBGP) -the lower the MED value, the more preferred the route will be *LOCAL_PREF (kun i iBGP) -the higher the local preference value, the more preferred the route *ATOMIC_AGGREGATE -indicates that an AS is passing a less specific --rather than more specific-- route '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 *COMMUNITIES -routes that share some common property -a route can be tagged with more than one community *ORIGINATOR_ID -supports the route reflector feature used for scaling iBGP meshes -identifies the src of routes *CLUSTER_LIST -supports the route reflector feature used for scaling iBGP meshes -a mini-AS_PATH used to detect updates that are looping inside the cluster *Multiprotocol Reachable NLRI *Multiprotocol Unreachable NLRI ###BGP Messages * Open

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