polimd/Piattaforme Software per la Rete/MOD1/lesson_16.md

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.

6. Massima LOCAL-PREF

7. Scegli percorsi originati localmente

8. AS_PATH piú corto

9. minima ORIGIN (IGP < EGP < INCOMPLETE)

10. minimo MED

11. Preferisci eBGP su iBGP

12. Minimo costo verso il NEXT-HOP

13. Se i percorsi sono tutti esterni, tieni il piú vecchio

14. 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:(...)