# Piattaforme e Software per la rete - lezione 16
#### Giacomo Verticale
###### 27 May 2016
## BGP Decision Process
1. Ricezione update dai vicini (inserimento in *ADJ-RIB-IN*)
2. Applicazione filtri import
3. Scelta del percorso migiore (inserimento in *LOC-RIB*)
4. Per ogni vicino: 
    - aggregazione delle rotte, 
    - applicazione filtri export, 
    - inserimento in ADJ-RIB-OUT
5. Invio UPDATE
### Algoritmo per la scelta del percorso migliore:
Questo algoritmo non ha nessuna garanzia di convergenza, quindi risulta necessario
garantire la presenza di un amministratore 24/7 per sistemare eventuali problemi.

1. Massima LOCAL-PREF
2. Scegli percorsi originati localmente
3. AS_PATH piú corto
4. minima ORIGIN (IGP < EGP < INCOMPLETE)
5. minimo MED
6. Preferisci eBGP su iBGP
7. Minimo costo verso il NEXT-HOP
8. Se i percorsi sono tutti esterni, tieni il piú vecchio
9. Scelgo il percorso annunciato dal router con ID minimo
(potrei scegliere a caso, scelta deterministica per evitare route-flapping)
(ID ROUTER = Indirizzo IP piú grande)

### Relazioni di organizzazione di internet
Fino a qualche anno fa le relazioni tra A.S. erano del tipo
- customer/provider in cui un A.S paga un altro per risolvere le connessioni
- peering in cui si scambiano traffico proveniente dai sottoalberi
(ultimamente si é parlato di peering a pagamento per A.S. di dimensioni diverse

I seguenti non sono standard ma best practice
Tipo di A.S. | Preferenza | Export Filter
--- | --- | ---
Customer | Massima prioritá | Inviato a tutti gli A.S. vicini
Peer | Media | Inviato a tutti gli A.S. customer
Provider | Minima | Inviato a tutti gli A.S. customer

__Teorema__
> Se tutte le regole di filtraggio sono in accordo con le regole della tabella,
> allora il routing é stabile (non succede *route flapping*)

Da qualche anno a questa parte il classico schema gerarchico (Tier 1/2/3) é stato
cambiato dall'introduzione di __Content Provider__ che generano una grande quantitá
di traffico, ed effettuano accordi di peering a vari livelli permettendo 
ai provider di avere latenze piú basse e bandwidth maggiori.

Un esempio di __Content provider__ sono Netflix, Google, YouTube... perché generano 
traffico, ad esempio Netflix negli stati uniti genera il 45% di traffico usato.

Akamai invece é un __Content Delivery__ service, cioé non genera contenuto ma
si occupa di fare accordi per distribuirlo.

Questo si inserisce nel discorso sulla __net neutrality__ per cui ci si chiede
se i contenuti dei content provider vengono trattati alla pari del traffico generato
da altri customer.

## Esercizio su OpenFlow
- Uno switch S1
- Tre host h1,h2,h3

MAC h1=00:00...:01
IP h1=10.0.0.1

Funzione che gestisce event switch features:
```
...
match = parser.OFPMatch()
actions = [ parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,ofproto.OFPCML_NO_BUFFER)]
...
invia flowmod a s1 con prioritá 0
```
```
match = parser.OFPmatch(eth_dst="00...3")
actions = [parser.OFPAction Output(3)]
invia flowmod con prioritá 1
...
match = parser.OFPmatch(eth_type=0x800,ip_dst="10.0.0.3")
actions = [output 3]
invia flowmod con prioritá 2
```

Il gestore della packet-in da un comando packet-out in flooding.

__Domande:__ 
- simulare:
    - h1 ping h2, 
    - h1 ping h3,
    - apertura connessione TCP da h2 a h3 (porte 123,80)

__Switch__
 
Prioritá | Match | Azione | Pkt counter
--- | --- | --- | ---
0 | * | output controller | 0
1 | eth_dst=0...3 | output 3 | 0
2 | eth_type=0x080 IP_dst=IP3 | - | - 

__h1 ping h2__
- *h1->s1*: MAC 1, MAC BROADCAST, ETHTYPE=ARP, IP 1, IP 2
- *s1->C*: (OF)PACKET_IN (pacchetto precedente)
- *C->s1*: (OF)PACKET_OUT(stesso pacchetto, action output=FLOOD)
- *s1->h2*:
- *s1->h3*:
- *h2->s1*: MAC 2, MAC 1, ETHTYPE=ARP, IP 2, IP 1
- *s1->C*: PKT_IN(...)
- *C->s1*: PKT_OUT(...)
- *s1->h3*:
- *s1->h1*: 
- *h1->s1*: MAC 1, MAC 2, IPv4, IP 1, IP 2, ICMP
- *s1->C*:
- *C->s1*:
- *s1->h2*:(...)
- *s1->h3*:(...)