OSPF Sham-link pour VPN MPLS

Présentation au sujet: "OSPF Sham-link pour VPN MPLS"— Transcription de la présentation:

1 OSPF Sham-link pour VPN MPLS
ccnp_cch ccnp_cch

2 Sommaire • Introduction
• Présentation de la fonctionnalité Utilisation d'OSPF dans les connexions routeurs PE-CE Utilisation d'une sham-link pour corriger le routage OSPF arrière Exemple de configuration sham-link Avantages - Restrictions - Fonctionnalités et technologies liées Documents liés ● Plateformes supportées • Standards, MIBs et RFCs supportés ● Prérequis • Tâches de configuration - Créer une sham-link Vérifier la création d'une sham-link Superviser et maintenir une sham-link ● Exemples de configuration ccnp_cch

3 Présentation de la fonctionnalité
Introduction Ce document décrit comment configurer et utiliser une sham-link pour connecter des sites clients VPN qui opèrent avec le protocole OSPF (Open Shortest Path First) et par- tagent des liaisons OSPF arrière dans une configuration VPN MPLS. Historique de la fonctionnalité Release Modification 12.2(8)T Cette fonctionnalité a été introduite. Ce document décrit comprend les sections suivantes:  Présentation de la fonctionnalité • Plateformes supportées • Standards, MIBs et RFCs supportés • Prérequis • Tâches de configuration • Exemples de configuration Présentation de la fonctionnalité Utilisation d'OSPF dans les connexions routeurs PE-CE Dans une configuration VPN MPLS, le protocole OSPF est une des solutions pour con- necter les routeurs CE (Customer Edge) aux routeurs PE (Provider Edge) de l'opérateur dans un backbone VPN. OSPF est souvent utilisé par des clients qui l'utilise comme protocole de routage interne à un site, souscrivent un service VPN et veulent échanger des informations de routage OSPF entre sites (pour une période de migration ou en permanence) sur un backbone VPN MPLS. La figure suivante montre un exemple sur comment des sites ccnp_cch

4 Présentation de la fonctionnalité
Introduction Ce document décrit comment configurer et utiliser une sham-link pour connecter des sites clients VPN qui opèrent avec le protocole OSPF (Open Shortest Path First) et par- tagent des liaisons OSPF arrière dans une configuration VPN MPLS. Historique de la fonctionnalité Release Modification 12.2(8)T Cette fonctionnalité a été introduite. Ce document décrit comprend les sections suivantes:  Présentation de la fonctionnalité • Plateformes supportées • Standards, MIBs et RFCs supportés • Prérequis • Tâches de configuration • Exemples de configuration Présentation de la fonctionnalité Utilisation d'OSPF dans les connexions routeurs PE-CE Dans une configuration VPN MPLS, le protocole OSPF est une des solutions pour con- necter les routeurs CE (Customer Edge) aux routeurs PE (Provider Edge) de l'opérateur dans un backbone VPN. OSPF est souvent utilisé par des clients qui l'utilise comme protocole de routage interne à un site, souscrivent un service VPN et veulent échanger des informations de routage OSPF entre sites (pour une période de migration ou en permanence) sur un backbone VPN MPLS. La figure suivante montre un exemple sur comment des sites clients qui opèrent avec OSPF peuvent se connecter sur un backbone VPN MPLS. ccnp_cch

5 ccnp_cch Area 1 Backbone VPN MPLS Area 2 Area 0 Area 3
Quand OSPF est utilisé pour connecter les routeurs PE et CE toutes les informations de routage apprises d'un site VPN sont placées dans une instance VRF (VPN Routing Forwarding) associée à l'interface entrante. Les routeurs PE qui sont attachés au VPN utilisent BGP pour distribuer les routes à chacun des autres routeurs. Un routeur CE peut ensuite apprendre les routes des autres sites dans le VPN par association avec le routeur PE attaché. Le superbackbone VPN MPLS fournit un niveau additionnel de hiérarchie de routage pour interconnecter les sites VPN opérant avec OSPF. Quand les routes OSPF sont propagées sur le backbone VPN MPLS, des informations additionnelles sur le préfixe, sous la forme de communautés BGP étendues (type de route, domaine ID de communauté étendue,..), sont ajoutées à la mise à jour BGP. Cette information de communauté est utilisée par le routeur PE receveur de décider du type de LSA à générer quand la route BGP est redistribuée vers le processus OSPF PE-CE. De cette manière là, les routes OSPF internes qui appartiennent au même VPN et qui sont annoncées sur backbone VPN sont vues comme des routes inter-area sur les sites distants. Utilisation d'une sham-link pour corriger le routage arrière OSPF Bien que les connexions OSPF CE-PE supposent que le seul chemin entre deux sites clients se fasse à travers le backbone VPN MPLS, des chemins en arrière entre les sites VPN peuvent exister. Si ces sites appartiennent à la même area OSPF, le chemin par cette liaison arrière sera toujours préféré car OSPF préfère en priorité les chemins intra-area aux chemins inter-area (les routeurs PE annoncent les routes apprises avec OSPF sur le backbone VPN comme des routes inter-area). ccnp_cch

6 Pour cette raison, les liaisons OSPF arrière entre les sites VPN doivent être prises en
compte ainsi le routage est réalisé sur la base d'une politique. Backbone VPN MPLS Area 1 PE PE PE Winchester Brighton Stockholm Vienne Par exemple la figure ci-dessus montre trois sites clients VPN chacun avec des liaisons arrière. Comme chaque site opère avec OSPF dans la même area, tout le routage entre ces trois sites suit le chemin intra-area à travers les liaisons arrières au lieu de passer par le backbone VPN MPLS. L'exemple suivant montre les entrées de la table de routage BGP pour le préfixe /32 sur le routeur PE-1. Ce préfixe est celui de l'interface loopback du routeur CE Winchester. Comme cela est indiqué en caractères gras, l'interface loopback est ap- prise via BGP de PE-2 et PE-3. Ce préfixe est également généré au travers de la redistri- bution dans BGP sur PE PE-1# show ip bgp vpnv4 all BGP routing table entry for 100:251: /32, version 58 Paths: (3 available, best #2) Advertised to non peer-group peers: Local (metric 30) from ( ) Origin incomplete, metric 22, localpref 100, valid, internal Extended Community: RT:1:793 OSPF DOMAIN ID: OSPF RT:1:2:0 OSPF 2 ccnp_cch

7 Local from ( ) Origin incomplete, metric 86, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:1:793 OSPF DOMAIN ID: OSPF RT:1:2:0 OSPF 2 (metric 30) from ( ) Origin incomplete, metric 11, localpref 100, valid, internal Dans BGP, la route générée localement ( ) est considérée comme la meilleure route. Cependant comme cela est montré en caractères gras dans l'exemple suivant, la table de routage VRF montre que le chemin sélectionné est appris via OSPF avec le prochain saut qui est le routeur CE Vienne. PE-1# show ip route vrf ospf Routing entry for /32 Known via "ospf 100", distance 110, metric 86, type intra area Redistributing via bgp 215 Advertised by bgp 215 Last update from on Serial0/0/0, 00:00:17 ago Routing Descriptor Blocks: * , from , 00:00:17 ago, via Serial0/0/0 Route metric is 86, traffic share count is 1 Ce chemin est sélectionné car :  Le chemin OSPF intra-area est préféré par rapport au chemin inter-area (par le back bond VPN MPLS) généré par le routeur PE  OSPF a une distance administrative plus faible que iBGP ( BGP opérant entre rou teurs résidant dans le même système autonome). Si les liaisons arrière entre sites sont utilisées uniquement pour un besoin de secours et ne participent pas au service VPN alors la sélection par défaut de route de l'exemple précédent n'est pas souhaitable. Pour rétablir la sélection de chemin désirée sur le backbone VPN MPLS, vous devez créer une liaison intra-area OSPF additionnelle (lo- gique) entre les VRFs entrants et sortants sur les routeurs PEs concernés. Cette liaison est appelée "sham-link". Une sham-link est requise entre toutes les paires de sites VPN qui appartiennent à la même area OSPF et partagent une liaison OSPF arrière. Si aucune liaison OSPF arrière n'existe entre les sites VPN alors aucune sham-link n'est requise. La figure suivante montre un exemple de sham-link entre PE1 et PE-2. Un coût confi- guré avec chaque sham-link est utilisé pour décider si le trafic doit être transmis sur le chemin sham-link. Quand une sham-link est configurée entre routeurs PE, les PEs peuvent remplir la table de routage VRF avec les routes OSPF apprises par la liaison sham-link. ccnp_cch

8 Backbone VPN MPLS Area 1 PE PE PE Winchester Brighton Stockholm Vienne Net= LSA Type 1 Net= Route-Type 1:2:0 Net= LSA Type 1 Sham-link MP-BGP Comme la sham-link est vue comme une liaison intra-area entre routeurs PE, une ad- jacence OSPF est crée et l'échange des bases de données (pour le processus OSPF par- ticulier) s'effectue à travers la liaison. Le routeur PE ensuite diffuser les LSAs entre si- tes à travers le backbone VPN MPLS. Le résultat est que la connectivité intra-area dési- rée est crée. La section "Créer une sham-link" décrit comment configurer une sham-link entre deux routeurs PE. Exemple de configuration de sham-link Cet exemple dans cette section est conçu pour montrer comment une sham-link est utilisée pour influencer la sélection du chemin intra-area OSPF des routeurs PE et CE. Le routeur PE utilise également l'information reçue de MP-BGP pour fixer le label de sortie de pile des paquets entrants et décider vers quel routeur PE de sortie commuter les paquets avec ce label. La figure suivante montre un exemple de topologie VPN MPLS dans laquelle une con- figuration sham-link est nécessaire. Un client VPN a trois sites, chacun avec une liai- son arrière. Deux sham-link ont été configurées; une entre PE1 et PE2 et l'autre entre PE-2 et PE-3. Une sham-link entre PE-1 et PE-3 n'est pas nécessaire dans cette confi- guration car les sites Vienne et Winchester ne partagent pas de liaison arrière. ccnp_cch

9 ccnp_cch Backbone VPN MPLS Area 1 Area 1 Area 1
PE Winchester Area 1 Sham-link Sham-link Brighton PE PE Area 1 Area 1 Stockholm Vienne L'exemple suivant montre l'acheminement entre sites du point de vue de PE-1 pour le préfixe /32, l'interface loopback 1 du routeur CE Winchester. PE-1# show ip bgp vpnv4 all BGP routing table entry for 100:251: /32, version 124 Paths: (1 available, best #1) Local (metric 30) from ( ) Origin incomplete, metric 11, localpref 100, valid, internal, best Extended Community: RT:1:793 OSPF DOMAIN ID: OSPF RT:1:2:0 OSPF 2 PE-1# show ip route vrf ospf Routing entry for /32 Known via "ospf 100", distance 110, metric 13, type intra area Redistributing via bgp 215 Last update from :12:59 ago Routing Descriptor Blocks: (Default-IP-Routing-Table), from , 00:12:59 ago ccnp_cch

10 L'exemple suivant montre l'acheminement de l'information dans laquelle le prochain
saut pour la route est le routeur PE-3 au lieu du routeur PE-2 (qui est le meil- leur chemin selon OSPF). La raison pour laquelle la route OSPF n'est pas redistribuée dans BGP est que celle-ci est déjà redistribuée dans BGP à l'autre extrémité de la liai- son sham-link. La liaison OSPF sham-link est utilisée uniquement pour influencer la sélection de chemin intra-area. Quand du trafic est transmis vers une destination par- ticulière, le routeur PE utilise l'information d'acheminement MP-BGP. PE-1# show ip bgp vpnv4 all tag | begin / notag/38 PE-1# show tag-switching forwarding Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface / PO3/0/0 point2point PE-1# show ip cef vrf ospf /32, version 73, epoch 0, cached adjacency to POS3/0/0 0 packets, 0 bytes tag information set local tag: VPN-route-head fast tag rewrite with PO3/0/0, point2point, tags imposed: {42 38} via , 0 dependencies, recursive next hop , POS3/0/0 via /32 valid cached adjacency tag rewrite with PO3/0/0, point2point, tags imposed: {42 38} Si un préfixe est appris à travers une sham-link et que le chemin via la sham-link est sélectionné comme étant le meilleur, le routeur PE ne génère pas de mise à jour BGP pour le préfixe. Il n'est pas possible de router le trafic d'une sham-link vers une autre sham-link. Dans l'exemple suivant, PE-2 montre comment une mise à jour MP-BGP pour le préfixe n'est pas générée. Bien que /32 ait été appris via OSPF à travers la sham-link comme cela est montré en caractères gras, aucune génération locale de route n'est réa- lisée dans BGP. La seule entrée dans la table BGP est la mise à jour MP-BGP reçue de PE-3 (le routeur PE de sortie pour le préfixe /32). PE-2# show ip route vrf ospf Routing entry for /32 Known via "ospf 100", distance 110, metric 12, type intra area Redistributing via bgp 215 Last update from :00:10 ago Routing Descriptor Blocks: * (Default-IP-Routing-Table), from , 00:00:10 ago Route metric is 12, traffic share count is 1 ccnp_cch

11 ccnp_cch PE-2# show ip bgp vpnv4 all 10.3.1.7
BGP routing table entry for 100:251: /32, version 166 Paths: (1 available, best #1) Not advertised to any peer Local (metric 30) from ( ) Origin incomplete, metric 11, localpref 100, valid, internal, best Extended Community: RT:1:793 OSPF DOMAIN ID: OSPF RT:1:2:0 OSPF 2 Le routeur PE utilise l'information reçue de MP-BGP pour fixer le label de pile des pa- quets entrants et décider vers quel routeur PE de sortie commuter les paquets avec le label. Avantages Connexion du Site Client à travers le backbone VPN MPLS Une sham-link modifie le comportement par défaut d'OSPF pour la sélection d'une rou- te arrière intra-area (PE à PE). Une sham-link assure que les sites Client OSPF qui par- tagent une liaison arrière peuvent communiquer sur le backbone VPN MPLS et partici- per aux services VPN. Routage flexible dans une configuration VPN MPLS Dans une configuration VPN MPLS, le coût OSPF configuré avec une sham-link vous permet de décider si le trafic du site client OSPF est routé sur une liaison arrière ou à travers le backbone VPN. Restrictions Quand OSPF est utilisé comme protocole de routage entre des routeurs PE et CE, la métrique OSPF est conservée quand les routes sont annoncées à travers le backbone VPN. La métrique est utilisée sur les routeurs PE distants pour sélectionner la route correcte. Pour cette raison vous ne devez pas modifier la valeur de la métrique quand OSPF est redistribué dans BGP et quand BGP est redistribué dans OSPF. Si vous mo- difiez la valeur de la métrique, des boucles de routage peuvent se former. Technologie et fonctionnalités liées • MPLS • OSPF • BGP ccnp_cch

12 Plateformes supportées • Cisco 1400 series
Documents liés • Cisco IOS Configuration Fundamentals Configuration Guide, Release 12.2 • Cisco IOS Configuration Fundamentals Command Reference, Release 12.2 • Cisco IOS IP Command Reference, Volume 2 of 3: Routing Protocols, Release 12.2 fiprrp_r/1rfospf.htm • MPLS Virtual Private Networks 120t/120t5/vpn.htm • Configuring OSPF fipr_c/ipcprt2/1cfospf.htm • Configuring BGP fipr_c/ipcprt2/1cfbgp.htm • RFC 1163, A Border Gateway Protocol • RFC 1164, Application of the Border Gateway Protocol in the Internet • RFC 2283, Multiprotocol Extensions for BGP-4 • RFC 2328, Open Shortest Path First, Version 2 • RFC 2547, BGP/MPLS VPNs Plateformes supportées • Cisco 1400 series • Cisco 1600 • Cisco 1600R • Cisco 1710 • Cisco 1720 • Cisco 1721 • Cisco 1750 • Cisco 1751 • Cisco 2420 • Cisco 2600 • Cisco 2691 • Cisco 3620 • Cisco 3631 ccnp_cch

13 ccnp_cch • Cisco 3640 • Cisco 3660 • Cisco 3725 • Cisco 3745
• URM • Cisco uBR7200 Standards, MIBs et RFCs supportés Standards Aucun standard nouveau ou modifié n'est supporté par cette fonctionnalité. MIBs Aucune MIB nouvelle ou modifiée n'est supportée pour cette fonctionnalité. RFCs Aucun RFC nouveau ou modifié n'est supporté par cette fonctionnalité. Prérequis Avant de configurer une sham-link dans un VPN MPLS, vous devez d'abord valider OSPF comme suit: • Créez un processus de routage OSPF • Spécifiez un intervalle d'adresses IP à associer avec le processus de routage • Affectez des ID aux areas associées aux adresses IP ccnp_cch

14 Tâches de configuration Voir les sections suivantes pour les tâches de configuration pour la fonctionnalité sham-link. Chaque tâche dans la liste est identifiée comme requise ou optionnelle. • Création d'une sham-link (Requis) • Vérification de la création d'une sham-link (Optionnel) Création d'une sham-link Avant de créer une sham-link entre routeurs PE dans un VPN MPLS, vous devez: • Configurez une adresse /32 séparée sur le routeur PE distant ainsi les paquets OSPF peuvent être transmis sur le backbone VPN vers l'extrémité distante de la sham-link L'adresse /32 avoir les caractéristiques suivantes: Appartenir à un VRF Ne pas être annoncée par OSPF Etre annoncée par BGP Vous pouvez utilisez l'adresse /32 pour d'autres sham-links. • Associez la sham-link avec une area OSPF existante. Pour créer une sham-link, utilisez les commandes suivantes en débutant en mode EXEC privilégié. Commande But Routeur1# configure terminal Entre en mode de configuration global sur le premier routeur PE. Routeur1(config)# interface loopback interface-number Crée une interface loopback devant être utilisée comme extrémité de la sham-link sur PE-1 et entre en mode de configuration interface. Routeur1(config-if)# ip vrf forwarding vrf-name Associe l'interface loopback à un VRF. Retire l'adresse IP. Routeur1(config-if)# ip address ip-address mask Reconfigure l'adresse IP de l'interface loopback sur PE-1. Routeur1(config-if)# end Retour en mode de configuration global. Routeur1(config)# end Retour en mode EXEC privilégié. Routeur2# configure terminal Entre en mode de configuration global sur le second routeur PE. Routeur2(config)# interface loopback interface-number comme extrémité de la sham-link sur PE-2 et Routeur2(config-if)# ip vrf forwarding vrf-name l'adresse IP ccnp_cch

15 Commande But Routeur2(config-if)# ip address ip-address mask Reconfigure l'adresse IP de l'interface loopback sur PE-2. Routeur2(config-if)# end Retour en mode de configuration global. Routeur1(config)# end Retour en mode EXEC privilégié. Routeur1(config)# router ospf process-id vrf vrf-name Configure le processus OSPF spécifié avec le VRF associé avec l'interface sham-link sur PE-1 et entre en mode de configuration interface. Router1(config-if)# area area-id sham-link source-address destination-address cost number Configure la sham-link sur l'interface de PE-1 dans une area OSPF spécifiée et les interfaces loopback spécifiées par les adresses IP comme extrémités. cost number configure le coût OSPF pour la transmission d'un paquet IP sur l'interfa- ce sham-link de PE-1. Routeur2(config)# router ospf process-id vrf vrf-name associé avec l'interface sham-link sur PE-2 et Router2(config-if)# area area-id sham-link source-address Vérification de création de sham-link Pour vérifier que la sham-link a été créée avec succès et fonctionne, utilisez la comman- de show ip ospf sham-link en mode EXEC privilégié. Router1# show ip ospf sham-links Sham Link OSPF_SL0 to address is up Area 1 source address Run as demand circuit DoNotAge LSA allowed. Cost of using 40 State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Hello due in 00:00:04 Adjacency State FULL (Hello suppressed) Index 2/2, retransmission queue length 4, number of retransmission 0 First 0x63311F3C(205)/0x63311FE4(59) Next 0x63311F3C(205)/0x63311FE4(59) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec Link State retransmission due in 360 msec ccnp_cch

16 Superviser et maintenir une sham-link
Pour superviser et maintenir une sham-link, utilisez les commandes suivantes en mode EXEC privilégié: Commande But Routeur# show ip ospf sham-links Affiche l'état opérationnel de toutes les sham-links configurées sur un routeur. Routeur# show ip ospf data router ip-address Affiche les informations sur comment la sham-link est annoncée comme une connexion non-nu- mérotée entre deux routeurs PE. Exemples de configuration L'exemple suivant montre comment configurer une sham-link entre deux routeurs PE. Routeur1(config)# interface loopback 1 Routeur1(config-if)# ip vrf forwarding ospf Routeur1(config-if)# ip address ! Routeur2(config)# interface loopback 1 Routeur2(config-if)# ip vrf forwarding ospf Routeur2(config-if)# ip address Routeur1(config)# router ospf 100 vrf ospf Routeur1(config-if)# area 1 sham-link cost 40 Routeur2(config)# router ospf 100 vrf ospf Routeur2(config-if)# area 1 sham-link cost 40 ccnp_cch