# NRP - TD 3 - BGP

###### tags: `NRP` `S2`

## Rappels de cours BGP

BGP = routing entre des FAI qui ne se font pas confiance.
Protocole de routage a vecteur de chemin = on annonce pas une distance comme en RIP (on annonce des chemins par suite d'AS).
Le processus de décision d'un routeur BGP on applique une politique de sélection de chemin pour choisir le plus rentable pour le FAI.
Session BGP avec ses clients et fournisseurs d'access.
Config des routeurs pour préférer les chemins rentable économiquement.
ex : + de pref pour un chemin d'un client que pour un upstream.

On peut aussi empecher des chemins a travers son réseau propre. Les chemins peuvent etre indirects. On ne souhaite pas faire passerelle entre 2 FAI qui ne sont pas clients. solution : processus de filtrage pour n'annoncer les chemins les meilleurs que vers les clients par exemple.
BGP n'est pas philantrope : on contraint le transit dans le reseau pour les appliquer uniquement que quand c'est interressant.

Etat des session et etat des mémoires
3 structures de donée : routing info base des adjacences(Adj-rib-in). on peut y appliquer des regles. exemple : empecher que les voisins annoncent des routes vers son propre réseau. (on peut tagger les routes avec des informations comme le client donné pour transmettre des infos entre les routeurs)
On a ainsi un ensemble de routes, ensuite le routeurs va tester ses préférences sur les routes pour chaque destination que l'on va pouvoir utiliser et établir une "liste".
Adj-rib-out s'empèche d'empecher une route en sortie vers un voisin donné si elle n'est pas profitable.

Le choix du meilleur chemin pour une même destination se fait en fonction de plusieurs paramètres. A chaque égalité dans l'ordre des paramètres.

- Local pref : les choix qui viennent des clients auront une préférence locale haute. Tout les chemins qui viennent des fournisseurs d'acces auront un e préférence locale plus faible. on peut aussi mettre une valeur intermédiaire pour les pairs (qui sont neutres, il ne coutent pas mais ne rapportent pas). Si on a plusieurs clients qui nous donnent le meme chemin on peut avoir la meme préférence locale.
- AS Path length : Le nombre de liens intermédiaires qui sont nécéssaires. On cherche a le minimiser. (A ne pas confondre avec IGP metric qui se fie au routage OSPF et donc se fait en local.)
- MED : bypass pour les provider et peer (ca depend des contrats normalement non mais accord réciproque possible) mais pas pour les clients. On cherche à le minimiser. Le MED permet au client de choisir par ou le trafic va passer dans leur réseau. On s'en fout pour les provider parce qu'on a pas forcément envie de les arranger.
- Privilégier eBGP face à iBGP
- IGP metric: montre la distance intra domaine des autres routeurs, et donc on minimise le routage interne (config OSPF en général). Uniquement en iBGP
- d'autres critères a retrouver dans le diapo

role de bgp : trouver le meilleur point de sortie sur la base des routeurs qui nous parlent directement.

nextstop : Attribut BGP qui correspond a l'adresse IP du prochain routeur.

## Q1

Adjacency: 76 Upstream: 3 Downstream: 73
Upstream Adjacent AS list
AS6939 HURRICANE, US
AS3356 LEVEL3, US
AS5511 OPENTRANSIT, FR
Downstream Adjacent AS list
AS204748 AS_INDITEX, ES
AS202915 CUSTOS-AS, ES
AS48048 INDRASISTEMAS-AS, ES
AS15937 ADIF, ES
AS198193 ASN-TCABLE, ES
AS199581 DATARUSH Data Rush IT Services, S.L., ES
AS200832 EBMS, ES
AS199913 SOYTIC, ES
AS199611 TELCOMBS, ES
AS206954 NEXTRET-AS, ES
AS31346 DDOL-AS, ES
AS25487 DIGITALVALUE-AS, ES
AS41397 REDESTEL-AS, ES
AS24624 IASOFT-AS Zaragoza - SPAIN, ES
AS50235 EUIPO Autonomous System, ES
AS60551 ANT-AS, ES
AS16383 LACAIXA-AS, ES
AS199435 WIMAXONLINE-AS, ES
AS200595 CLOUDNET, ES
...

upstream = observée comme étant juste avant l'AS analysée
downstream = ensemble des chemins qui sont derrière l'AS analysée

Les AS upstream peuvent être les fournisseurs internet de l'AS analysée et les AS downstream seraient les clients.
Mais il ne faut pas généraliser, ce n'est pas systématiquement le cas.
L'AS analysé est un FAI espagnol (Orange espagne)

L'AS analysé est un exemple de ce qu'il ne faut pas faire, si on n'agrège pas les routes, la mémoire des routeurs exploserait.

## Q2

Un câble est coupé pendant

## Q3

Non convergence de BGP : configurations possibles à voir Bad Gadget, Nasty Gadget, Jennifer Rexford, Lixin Gao.

Dans les faits, les protocoles BGP convergent car on est dans un contexte économique

## Q4

Si la distance relative entre les points de sortie potentiels change, la décision de BGP risque de changer. Les points de sortie peuvent donc changer et se répercuter dans le réseau eBGP.

## Q5

En février 2008, les pakistanais voulaient couper youtube et ont décider d'envoyer dans un trou noir les requêtes des pakistanais vers youtube pour censurer le site dans le pays.
Le pakistan voulait bloquer les 3 @IP (208.65.153.238, 208.65.153.251 and 208.65.153.253.) de youtube du DNS.

Pakistan telecom a créé un /24 (sous ensemble du range de youtube qui est en /22). Il commencent par créer un réseau fictif OSPF configurée sur ce /24 et qui est une dummy interface c'est a dire qu'elle jette l'ensemble des paquets.

La redistribution du réseau interne était configurée en automatique et les routeurs BGP de pakistan télécom ont donc propagé ce sous ensemble de google comme étant dans l'AS de pakistan télécom.

Le chemin /24 a été choisi comme meilleur chemin par l'ensemble des AS du monde entier car le préfixe était très spécifique (notamment à cause de la longuest prefix max rule). Tous les paquets ont donc été routés par le /24 et redirigés vers le dummy interface.

En fait pour PCCW, pakistan télécom est un client et il a un AS path length de 1. Donc il utilise ce chemin. Et ce qui rend un chemin court pour beaucoup de monde sur la planete.

Comment ça peut être évité :
- on filtre les AS et on trouve bizarre de faire passer les paquets de google par un AS pakistanais (du coté de PCCW).

Ensuite youtube essaye de récupérer son préfixe et ils réannoncent le /24 eux-mêmes. BGP compare ses chemins et récupère le chemin pour la plupart des zones qui sont suffisament éloignées du pakistan.

Youtube décide donc de réannoncer un /25 en découpant le /24 en 2 sous-domaines. Sauf que les règles de filtrage bloquent les préfixes en /25 (ils correspondent à 128 machines et si tout le monde pouvait annoncer par groupe de 128 machines les routeurs n'auraient pas assez de RAM.

2 choix pour résoudre le pb :
- supprimer les règles OSPF => pas fait car demande du gouvernement
- rendre le chemin plus long (ils l'ont fait en s'annonçant 2 fois dans le chemin)

PCCW ont alors choisi de filtrer les annonces qui viennent de pakistan télécom pour le sous réseau de youtube.

## Q6.1

voir rappels de cours


## Q6.2

Il faut faire un peering trial pour tester le traffic en faisant comme si le lien de peering est up. On laisse quelques semaines pour faire des stats et on choisit de valider ou non le contrat de peering.
Le but est de diminuer le trafic venant des fournisseurs (cela fait perdre de l'argent) et d'augmenter le trafic en direction de nos clients (cela fait gagner de l'argent).

## Q7

free S.A -> moyen a grand FAI avec beaucoup de traffic download
AT&T -> grand fournisseur mondial avec grand transit americain
Netflix -> grand producteur de contenu

free ne veut pas peer avec YouTube car free estime qu'il doit etre client de YouTube car free offre l'utilisation du réseau. Mais en peerant il ne peut gagner d'argent des pubs YT

donc il vaut mieux etre netflix ou AT&T(il vaut mieux être un gros fournisseur car les petits fournisseurs ne font pas le poids)