VPN BGP-MPLS VPN. Types de VPN. Objectifs des VPN Virtual Private Networks interconnecter équipements à travers réseau tiers

Transcription

1 VN BG-MLS 2008 VN BG-MLS 1 VN Objectifs des VN Virtual rivate Networks interconnecter équipements à travers réseau tiers (FAI, ) raisons économiques, partage d une infrastructure longue distance coût du personnel et de la maintenance, mobilité (personnel à domicile, commerciaux, ) garder caractéristiques réseau privé sécurité maîtrise routage, adressage, management 2008 VN BG-MLS 2 Types de VN 1) implanté dans équipement client (CE) ex : tunnels Isec, GRE, L2T, pas de multicast, transparent opérateur configuration client : autant de tunnel que site? équipement opérateur ex : VN RFC 2547 (BG-MLS) service offert par l opérateur 2) sur un réseau niveau 3 (I) «niveau 2» (ATM, Frame Relay) niveau 2 sur niveau 3 (VLS) 2008 VN BG-MLS 3 1

2 VN type «RFC2547» Service fourni par l opérateur (E) pas ou peu de configuration chez client transparence espace adressage client accès possible du VN à Internet extensible taille VN choix routage interne au VN : étoile,mesh, nombre VN 2008 VN BG-MLS 4 Termes : Customer Equipment routeur simple (routage intra par exemple) E : rovider Equipment routeur BG/MLS/RFC2547 : Equipement interne du rovider routeur MLS (LSR) VRF Virtual Routing and Forwarding RIB et FIB «virtuelle» pour un VN 2008 VN BG-MLS 5 VN A VN A E E E VN C VN B VN B 2008 VN BG-MLS VN 6 A 2

3 rincipes E ont plusieurs tables de routage virtuelles (VRF): 1 par VN trafic des VN entre E encapsulé via MLS informations de routage d un VN transmises via BG 2 niveaux de label fond de pile identifie VN (ou VRF ou même route) : sémantique bout en bout sommet de pile : LS entre 2 E 2008 VN BG-MLS 7 Routage : Extensions BG 1) nouvelle famille d adresse : VN Iv4 AFI=1 (Iv4), SAFI=128 <RD> <Adresse Iv4> Route Distinguisher 8 octets <type field> <value field> ex : Type 0 <ASN> <Sous-numéro> ASN du provider, 2 octets le sous numéro repère le VN (géré par cet AS), 4 octets Type 1 <I address> <sous-numéro> I adresse publique (4 octets) sous-numéro géré par propriétaire adresse (2 octets) 2008 VN BG-MLS 8 Routage : Extensions BG Type 2 <ASN> <Sous-numéro> idem type 0 mais ASN sur 4 octets deux préfixes de 2 VN différents => RD différents (provider identique ou différent) Remarque : d après le RFC 4364, les adresses des E (next hop) doivent être encapsulées dans des adresses I4 VN avec RD = VN BG-MLS 9 3

4 Extensions BG (2) 2) Nouvel attribut «label VN» de type Label 3) Nouvel attribut «route target» de type «extended communities» (RFC 4360) une VRF a une liste d import et d export contrôle de la topologie du VN route marquée route Target RT1 = EC RT1 utilisée entre E1 et E2 <=> E1 exporte RT1 et E2 importe RT VN BG-MLS 10 Topologie et Route Target (1) 1) Mesh (maillage complet) une seule communauté tout VRF importe et exporte cette communauté équivalent Full Mesh ibg + court chemin dans le réseau opérateur 2008 VN BG-MLS 11 Topologie et Route Target (2) 2) Hub (étoile) 2 communautés HI et HO Hub importe HI et exporte HO Stubs importent HO et exportent HI Entre 2 stubs, 1 saut via hub en plus permet de centraliser politique au Hub redistribution entre sites du VN, vers Internet 2008 VN BG-MLS 12 4

5 Exemple annonce Hypothèses VN V1 associé à RD1 VRF1 est un «stub» pour VN V1 exporte vers HI, importe de HO VRF2 est un «hub» pour VN V1 exporte vers HO, importe de HI VRF3 est un «stub» : exporte vers HI, importe de HO 2008 VN BG-MLS 13 Exemple annonce E1 (VRF1) apprend préfixe du VN V1 (1) (via routage ) E1 choisit label L1 (associé à VRF1 ou int) E1 annonce <RD1, > <HI> <L1> NRLI et 2 attributs : Route Target et label E2(VRF2) accepte annonce importe HI place <RD1, > dans sa table annonce <RD1, > <HO> <L2> 2008 VN BG-MLS 14 Annonce (suite) E3(VRF3> refuse (ignore) 1ère annonce car n importe pas HI accepte 2ème annonce car importe HO Route de VRF3 vers passe par VRF2 (hub) utilisera LS L2 vers VRF2 puis L1 vers VRF VN BG-MLS 15 5

6 Label Choix du label : plusieurs possibilités 1) un label par VRF Egress => nécessite lookup (de ) à l arrivée VRF 2) un label par interface de sortie (~ FEC) évite tout lookup en réception sauf éventuellement pour link layer (AR) 3) un label par route (permet QoS) Remarque : un label par E ne serait pas suffisant même adresse I destination dans +sieurs VN 2008 VN BG-MLS 16 VRF (E2) Construction LS accepte <RD, > <RT> <L> de E1 LD demande LS vers E1 (si aucun) : Label Request FEC = E1 nécessite route vers E1 ( /32) un seul LS vers E pour plusieurs préfixes même VRF plusieurs VRF même E 2008 VN BG-MLS 17 VN A, /16 VN A, /16 BG (<RD, >, HI, L1) 1 = /16 = /16 E2 E1 X BG (<RD, >, HO, L2) BG (<RD, >, HI, L1) E3 VN C = /16 VN B, /16 3 VN B 2008 VN BG-MLS 18 VN A, /16 6

7 Données : Exemple (1) 3 reçoit paquet pour envoie à E3 (ex : route par défaut vers VN) E3 reçoit paquet par interface IntA VN A => VRF3A VRF3A : lookup /16 associé L2, E2 USH L2, puis USH L3 (label LS) (MLS «normal» FEC E2) émission 2008 VN BG-MLS 19 Données : Exemple (2) E2 reçoit paquet, O L2 : vers VRF2A (O de L2) lookup table, USH L1, USH L4 (label LS vers E1) E1 reçoit paquet, O L1 : vers VRF1 (et O L1) lookup table VRF1 : envoyé vers Int A (vers 1) 2008 VN BG-MLS 20 VN A, /16 VN A, /16 L5, L1 D L4, L1 D = /16 D E2 E1 L3, L2 D E3 VN C D VN B, /16 3 VN B 2008 VN BG-MLS 21 VN A, /16 7

8 Remarques Dans le réseau MLS une route /32 par E (indépendant routes externes) un LS par E (indépendant # VN) labels de fonds de pile uniques pour un E => pas de problème d allocation => système extensible à grande échelle Création VN définir Route Distinguisher (provider) pour VN définir politique routage (Hub, mesh, ) et les RT 2008 VN BG-MLS 22 Remarques (2) Connexion nouveau site client créer VRF si nouveau VN et associer Int. configurer politique import/extport route-map sur les Route-Target en général seulement sur 1 seul E configurer routage avec via interface Routage entre et E plusieurs possibilités routes statiques ( ex : pas de routeur ) IG (ex OSF) (une instance par VRF) ebg 2008 VN BG-MLS 23 Tunneling Si backbone non MLS remplacer LS (et label sommet pile) par tunnel plusieurs possibilités MLS dans I» entête I (V4 ou V6) adresses des extrémités du tunnel, proto = 137 (MLS unicast)» stack MLS» paquet 2008 VN BG-MLS 24 8

9 Encapsulation GRE (Generic Routing Encoding) GRE permet une protection (Cheksum optionnel), numéros de séquence (optionnel) C Reserved0 Ver rotocol Type Checksum (optional) Reserved1 (Optional) rotocol type est un «Ethertype» pour MLS 0x8847 (unicast) ou 0x8848 (multicast) On a donc I englobant (avec adresses tunnel, et proto = GRE= 47) entête GRE pile MLS paquet transporté 2008 VN BG-MLS 25 Tunneling (suite) paquets MLS / I ou MLS / GRE peuvent être protégés par Isec encapsulation => problème de MTU => utilisation du ath-mtu Discovery 2008 VN BG-MLS 26 Remarques (3) Extension multi-providers possible Fonctionnalités sur divers matériels Cisco, Juniper, Alcatel, roposé par plusieurs providers remière version RFC2547 (informationnel) mars 99 «RFC2547bis» publié comme RFC 4364 en février VN BG-MLS 27 9

10 biblio RFC 2547 BG/MLS VNs, mars 1999 remplacé par RFC BG/MLS I Virtual rivate Networks (VNs), février 2006 RFC 4360 BG Extended Communities Attribute, février 2006 RFC 2784 : encapsulation GRE mars 2000 RFC 4023 GRE pour MLS mars VN BG-MLS 28 10