Routed Bridged Encapsulation

Présentation au sujet: "Routed Bridged Encapsulation"— Transcription de la présentation:

1 Routed Bridged Encapsulation
RBE - Routed Bridged Encapsulation - Architecture de base avec Cisco UAC 6400

2 Sommaire • Introduction
- Hypothèses • Aperçu de la technologie • Description du fonctionnement Avantages - Inconvénients • Considérations sur l'implémentation • Architecture de réseau • Considérations de conception pour l'architecture RBE • Points clés de RBE - Equipement du client - Gestion IP • Comment le service destinataire est-il atteint? Fourniture de l'accès Internet Services globaux Accès d'entreprise Capacités de sélection de service • Conclusion

3 Réseau d'entreprise ou Opérateur
Introduction Ce document décrit une architecture ADSL ( Asymetric Digital Subscriber Line) de bout en bout utilisant RBE (Routed Bridged Encapsulation) pour l'UAC (Universal Access Concentrator) Cisco RBE a été développé pour corriger les problèmes du bridging RFC1483 concenant les tempêtes de broadcast et la sécurité. Excepté le fait que RBE opère exclusivement sur ATM, les fonctionnalités de RBE sont identiques à celles du demi-pontage ou "half-bridging". De plus évolutivité, performance et sécurité peuvent être réalisées en utilisant les caractéristiques uniques des abonnés xDSL. Hypothèse La base de l'architecture est conçue en utilisant le modèle de l'architecture de référen- ce de l'ATM Forum. Cette architecture couvre différentes offres de services par le four- nisseur d'accès réseau et différents scénarios décrivent comment le trafic abonné est acheminé vers le fournisseur de services. Dans cette architecture, RBE est la méthode d'encapsulation utilisée par l'équipement Cisco UAC Le contenu de ce docu- ment est basé sur des déploiements existants et sur des tests en laboratoire réalisés sur l'architecture. Ce document est limité à l'utilisation de l'équipement Cisco UAC Aperçu de la technologie Du point de vue réseau, la connexion ATM est vue comme une connexion routée. Le trafic de données est reçu comme des paquets RFC1483 mais ce sont des trames Ethernet RFC1483 ou IEE Au lieu de ponter la trame Ethernet ou 802.3, comme dans le cas du pontage RFC1483, le routeur route sur la base de l'en-tête de couche 3. A l'exception de simples vérification, l'en-tête de pontage est ignoré. Ceci est expliqué dans les sections suivantes. Description de fonctionnement Pile de Protocoles PVC DSLAM Agrégateur Routeur L3 Core Routeur PC/ATU-R IP RFC1483 sur ATM IP IP IP IP 802.3 802.3 RFC 1483 RFC 1483 AAL5 AAL5 ATM ATM ATM ATM ATM ATM ADSL ADSL PHY PHY PHY PHY Equipement du Client DSLAM Réseau d'entreprise ou Opérateur Agrégateur

4 Du point de vue du fonctionnement, le routeur opère comme si l'interface "routed-brid- ge" était connectée à un LAN Ethernet. Le fonctionnement est décrit ci-dessous pour les deux sens: paquets issus de l'équipement du client et paquets destinés à l'équipe- ment du client. Pour les paquets issus de l'équipement client, l'en-tête Ethernet est ignoré et l'adresse de destination IP est examinée. Si l'adresse de destination IP est dans le cache de route , le paquet est commuté (Fast Switching) sur l'interface de sortie. Si l'adresse IP de des- tination n'est pas dans le cache de route, le paquet le paquet est mis en file d'attente pour être traité par le processus de commutation. Le processus de commutation trouve l'interface de sortie sur laquelle le paquet doit être routé en examinant la table de rou- tage. Lorsque l'interface est identifiée, le paquet est routé vers cette interface. Ceci est fait sans avoir recours à un "Bridge Group" ou à un "Bridge group Virtual Interface" ou BVI. Pour les paquets à destination de l'équipement du client, l'adresse IP de destination du paquet est examinée en premier. L'interface de destination est déterminée à partir de la table de routage. Ensuite le routeur vérifie la table ARP avec l'interface pour trouver l'adresse MAC de destination associée et la placer dans l'en-tête Ethernet. Si aucune association n'est trouvée, le routeur génère une requête ARP pour l'adresse IP de desti- natiion. La requête ARP est acheminée uniquement sur l'interface de destination ce qui est en opposition avec le bridging dans lequel la requête ARP est transmise à toutes les interfaces dans le "Bridge Group". Pour un scénario utilisant les interfaces "unnumbered" (deux abonnés peuvent être sur le même sous-réseau) l'interface "routed-bridge" utilise un proxy ARP. Par exemple le host A à l'adresse veut communiquer avec le host B à l'adresse Cependant le host A et le host B sont sur le même sous-réseau. Le host A doit apprendre l'adresse MAC du host B en envoyant un broadcast ARP vers le host B. Quand l'interface "routed-bridge" sur l'équipement d'agrégation reçoit ce broadcast, elle transmet une réponse proxy ARP avec l'adresse MAC de vers le host A. Le host A va prendre cette adresse ,la placer dans sa trame Ethernet et transmettre le paquet. Quand le routeur reçoit le paquet, il ignore l'en-tête Ethernet et regarde l'adresse IP de destination avec laquelle il va router le paquet sur la bonne interface. Avantages de RBE RBE a été développé avec l'intention de corriger certains problèmes rencontrés avec l'architecture de bridging RFC1483. RBE garde tous les avantages de l'architecture de bridging RFC1483 tout en éliminant la majorité des inconvénients. ● Configuration minimale à l'installation de l'équipement du client Le fournisseur de service considère ceci comme très important car cela demande plus d'équipements spécifiques ni d'investissements lourds en personnel pour le support des protocoles de couches hautes. L'équipement client est peu impliqué dans les problèmes car tout ce qui entre par Ethernet passe directement côté WAN.

5 Considérations sur l'implémentation
● Il est aisé de migrer depuis l'architecture de bridging pur vers RBE. Il ny a pas de changement nécessaire côté abonné. ● Evite l'usurpation d'adresse IP et d'ARP rencontrés dans l'architecture de bridging pur. RBE empêche les tempêtes de broadcast en utilisant des connexions poit à point. La sécurité est un inconvénient majeur dans les architectures de bridging pur. ● Comparé à l'architecture de bridging pur, RBE a de meilleures performances à cause de l'implémentation du routage sur l'équipement d'agrégation. RBE est aussi plus évolutif car il n'y a pas de limitation des "bridge group". ● Supporte "Layer 3 Web Selection" en utilisant l'équipement Cisco SSG (Service Selec- tion Gateway). Considérations sur l'implémentation Les quelques points clés à considérer avant d'implémenter cette architecture sont les mêmes que ceux mentionnés dans le document "Architecture de Bridging RFC1483". RBE est recommandé quand: ● Les scénarios sont les mêmes que ceux existants dans les architectures de bridging existantes. ● L'opérateur veut faire une gestion minimale des équipements des clients. Le concept d'un équipement client simple requiert une configuration minimale ou pas de con figuration une fois que l'équipement du client est déployé sur le site ● L'opérateur ne veut pas installer et maintenir des clients (logiciels) sur les hosts derrière l'équipement d'accès ponté de l'abonné. Ces tâches d'installation et de maintenance accroissent les coûts de déploiement et de maintanace y compris la mise en place d'un helpdesk qui a la connaissance du logiciel client et du système d'exploitation sur lequel le client opère. ● L'opérateur veut déployer un réseau ponté évolutif et sécurisé en utilisant les équi- pements clients existants (qui peuvent opérer uniquement en mode bridging RFC 1483) et veut offrir des capacités de sélection de service.

6 fournisseur de service
Architecture de réseau Internet Télétravail 61xx/62xx Commutateurs ATM 6400 FAI 1 IP ou ATM IP+ATM Entreprise SOHO Réseau ATM 3810/3600 7200 Internet Résidentiel FAI 2 Abonné DSLAMs Réseau de l'opérateur Services Réseau du fournisseur de service L'architecture de réseau RBE est similaire à l'architecture de bridging RFC1483. Com- me cela est spécifié dans cette architecure, l'équipement d'agrégation peut être situé chez le fournisseur de service ou chez le fournisseur d'accès. Dans une architecture de circuit virtuel permanent d'extrémité à extrémité (PVC), le fournisseur de service gère jusqu'à la terminaisonabonné et configure RBE sur l'équipement d'agrégation. Si le fournisseur d'accès préfère fournir des services globaux et la sélection de service, il peut opter pour gérer la terminaison de ses abonnés et obtenir les adresses IP à partir d'un serveur DHCP. Dans le cas de services globaux, le fournisseur d'accès peut opter pour l'obtention d'adresses IP à partir du fournisseur de services. Ces scénarios sont décrits en détail dans la section "Gestion IP" de ce document. Considérations sur la conception de l'architecture RBE RBE élimine les risques majeurs de sécurité contenus dans l'architecture de bridging RFC1483. De plus RBE fournit une meilleure performance et une meilleure évolutivité car les sous-interfaces sont traitées comme des interfaces routées. Cette section explique quelques uns des points clés qui doivent être pris en compte avant de concevoir une architecture RBE. Pour le côté abonné, les principes de con- ception restent les mêmes que pour l'architecture "bridging RFC1483". Dans RBE, un seul circuit virtuel est alloué à une route, un ensemble de routes ou à un sous-réseau CIDR (Classless Inter-Domain Routing). Ainsi, l'environnemet de con- fiance est réduit uniquement au seul accès représenté soit par l'adresse IP dans l'en- semble de routes ou le bloc CIDR. Le fournisseur d'accès contrôle également les adres- ses affectées à l'utilisateur. Ceci est fait en configurant un sous-réseau sur la sous-in- terface de cet utilisateur. Par conséquent si cet utilisateur configure mal l'équipement

7 avec une adresse IP hors de l'intervalle d'adresses allouées (causant probablement
l'envoi de paquets ARP vers le routeur), le routeur génère une erreur "wrong cable" et refuse d'entrer la correspondance adresse IP avec adresse MAC erronée dans sa table ARP. RBE peut être déployé en utilisant uniquement des soous-interfaces ATM point à point. Il ne peut pas être déployé sur des interfaces multipoint. Bien que le côté abon- né soit ponté, vous n'avez ps besoin de définir des "bridge group" ou des interfaces BVI (Bridge Virtual Interface) car les sous-interfaces sont traitées comme des interfa- ces routées. Les sous-interfaces ATM point à point peuvent être des interfaces avec adresses IP ou des interfaces avec adresses IP "unnumbered". Par définition une interface avec adresse IP est une interface avec une adresse IP spé- cifique affectée avec un masque de sous-réseau. par exemple: interface atm0/0/0.132 point−to−point ip address Comme cela est montré dans cet exemple quand RBE est déployé avec une interface IP classique, il doit y avoir un sous-réseau séparé pour chaque abonné. Le host à l'extré- mité abonné doit être configuré avec Il y a seulement un host à l'extré- mité abonné. Si l'exigence est de supporter plusieurs hosts, le masque de sous-réseau doit être choisi en conséquence. Les interfaces IP classiques donnent à l'opérateur le contrôle sur le nombre de hosts que l'abonné a connecté derrière son accès. Comme cela a déjà été expliqué, ce man- que de contrôle était un problème majeur de l'architecture "bridging RFC1483". Cependant, cette méthodologie consomme trop d'adresses IP. Vous aurez besoin d'al- louer un sous-réseau par abonné, une adresse IP pour la sous-interface ATM et laisser l'adresse de broadcast et l'adresse nulle non utilisées. Ainsi, pour avoir un seul host derrière l'accès, vous avez besoin de définir un masque de sous-réseau Considérant la rareté des adresses IP, ceci n'est pas une option réalisable sauf si l'opérateur utilise l'espace d'adressage privé et NAT (Network Address Translation) pour atteindre le monde externe. Pour économiser des adresses IP, une alternative serait d'utiliser des interfaces "un- numbered". Par définition une interface "unnumbered" est une interface qui utilise l'adresse IP d'une autre interface en utilisant la commande ip unnumbered. Par exemple: interface loopback 0 ip address ! ip unnumbered loopback 0 interface atm0/0/0.133 point−to−point

8 Comme cela est montré dans l'exemple précédent, une adresse IP et un masque sont appliqués uniquement à l'interface loopback. Toutes les sous-interfaces ATM seront "unnunmbered" avec cette interface loopback. Dans ce scénario, tous les abonnés ter- minés sur les sous-interfaces ATM (unnumbered avec loopback 0) seront sur le même sous-réseau que celui de l'interface loopback. Ceci implique que les abonnés seront sur le même sous-réseau mais entreront par différentes sous-interfaces. Dans cette situation cela pose problème au routeur pour identifier quel abonné est derrière quelle sous-interface ATM. Pour l'IOS Cisco, (dans le schéma de gestion IP) est directement connecté via l'interface loopback 0 et le routeur ne transmettra jamais de trafic destiné à toute adresse de host de ce sous-réseau sur une autre interface. Pour résoudre ce problème, il est nécessaire de configurer explicitement des routes stati- ques de host.Par exemple: ip route atm0/0/0.132 ip route atm0/0/0.133 Comme cela est spécifié dans cet exemple, quand le routeur a besoin de prendre une décision de routage et a besoin d'acheminer du trafic destiné à , il choisi- ra la sous-interface ATM0/0/0.132 comme interface de sortie. Sans la spécification de ces routes statiques de hosts, le routeur choisirait l'interface Loopback 0 comme interface de sortie et éliminerait le paquet. Bien que l'interface IP unnumbered économise des adresses IP cela demande une tâ- che de configuration additionnelle de routes statiques de hosts sur le NRP ( Node Rou- te Processor) pour chaque abonné. Notez que si un abonné a 14 hosts derrière son accès, il n'est pas nécessaire d'avoir une route statique pour chaque host. Une route agrégée peut être définie pour la sous-interface ATM. Cette explication a présumé que les hosts derrière l'équipement d'accès sont configu- rés avec des adresses IP statiques. Cette hypothèse n'est pas celle des conceptions réelles. Dans la pratique, l'opérateur veut réaliser une configuration et une mainte- nance minimum pour l'équipement d'accès et les hosts qui y sont attachés. Pour ac- complir cela, les hosts doivent obtenir leurs adresses IP dynamiquement en utilisant un serveur DHCP. Pour obtenir leurs adresses IP dynamiquement, les hosts doivent être configurés pour qu'ils obtiennent leurs adresses à partir d'un serveur DHCP. Quand le host démarre, il transmet des requêtes DHCP. Ces requêtes sont relayées vers le serveur DHCP ap- proprié qui affecte une adresse IP au host à partir d'une de ses étendues préalable- ment définies. Pour acheminer les requêtes DHCP initiales du host vers le serveur DHCP approprié, vous devez appliquer la commande ip helper-address à l'interface qui reçoit les broad- casts. Une fois que les broadcasts sont reçus , l'IOS Cisco regarde la configuration ip helper-address pour cette interface et achemine les requêtes en paquets unicast vers le serveur DHCP dont l'adresse est spécifiée dans ip helper-address. Après que le serveur DHCP ait répondu avec l'adresse IP, il transmet la réponse vers l'interface du routeur qui est à l'origine de l'acheminement de la requête. Celle-ci est utilisée comme interface de sortie pour transmettre la réponse du serveur DHCP vers le host qui est à l'origine de la requête. Le routeur installe automatiquement une route de host vers cette adresse.

9 tante et descendante ceci a un impact sur les performances.
Si RBE est validé sur une sous-interface et que c'est une PDU IEEE802.3 pontée, l'en- capsulation Ethernet est examinée après l'encapsulation ATM pontée. Si c'est un pa- quet IP/ARP, il est traité comme tout paquet IP/ARP. Le paquet IP est "Fastswitched" sinon le paquet est mis en file d'attente pour traitement. La performance pour RBE est une grande victoire. Aujourd'hui le code de pontage standard a le problème inhérent de requérir deux traitements séparés pour un paquet avant de prendre la décision d'acheminement. Un traitement est défini comme le pro- cessus d'examen (sur le flux montant) et de modification (sur le flux descendant) de l'en-tête du paquet pour l'information d'acheminement, ce qui est coûteux en temps. Un examen de couche 2 est nécessaire pour déterminer si le paquet est routé ou pon- té. Ensuite à la couche 3 un examen est nécessaire pour déterminer la destination vers laquelle le paquet doit être routé. Ce traitement est fait dans les directions mon- tante et descendante ceci a un impact sur les performances. Pour RBE, il est prédéterminé par configuration que le paquet doit être routé dans la direction montante. Ainsi il n'est pas nécessaire de passer par le chemin d'achemine- ment de pontage qui était nécessaire dans le cas d'un pontage standard. Points clés de RBE CPE - (Customer Premises Equipment) La configuration de l'équipement d'accès client est la même que celle du pontage stan- dard. Aucun changement n'est requis pour déployer RBE. Gestion IP Adresses IP classiques CPE ponté ATU-R 6400 IP= GW= IP= Core IP= CPE ponté ATU-R - Les abonnés sont dans des sous-réseaux différents - Les abonnés sont dans des domaines de broadcast différents - Le trafic est routé vers les destinations par le 6400 - L'adresse de l'interface RBE 6400 est la passerelle par défaut - Le 6400 définit des routes statiques si "ip unnumbered" n'est pas utilisé. - Plus évolutif que le bridging IP= GW=

10 Durant le déploiement des interfaces IP classiques pour RBE, l'allocation d'adresses IP au host derrière l'équipement d'accès ponté est habituellement géré par un serveur DHCP. Comme mentionné précédamment, le serveur DHCP peut être situé chez l'opé- rateur. Dans ce cas la sous-interface ATM doit être configurée avec la commande ip helper-address. Si le serveur DHCP est situé chez l'opérateur, l'équipement d'agréga- tion doit avoir une route pour atteindre le serveur. Le seul scénarion dans lequel l'opérateur a son propre serveur DHCP et son espace d'adresses est lorsqu'il veut of- fir des capacités de sélection de service aux abonnés et ces abonnés sont attachés au LAN opérateur. Si le fournisseur d'accès veut utiliser l'espace d'adresses du fournisseur de services, une des adresses IP de chaque sous-réseau doit être allouée à la sous-interface ATM. Aussi, il doit y avoir agrément mutuel entre le fournisseur d'accès et le fournisseur de services pour que le fournisseur d'accès configure l'adresse correcte. Quand le serveur DHCP du fournisseur de services affecte les adresses IP, cet agrément doit être effectif pour assurer que le serveur l'information de passerelle par défaut correcte au host. Le fournisseur d'accès peut soit agréger une route statique pour toutes les adresses affectées aux abonnés ou il peut choisir d'opérer avec un protocole de routage avec le fournisseur de services pour annoncer ces routes. Dans la majorité des scénarios, le fournisseur d'accès et de services préfèrent utiliser des routes statiques. Voici la configuration requise sur le NRP pour déployer RBE avec des interfaces IP classiques: ! interface ATM0/0/0.132 point−to−point ip address ip helper−address no ip directed−broadcast atm route−bridged ip pvc 1/32 encapsulation aal5snap interface ATM0/0/0.133 point−to−point ip address pvc 1/33 Utiliser des interfaces "unnumbered" est le meilleur moyen d'économiser des adresses IP. Comme cela a déjà été expliqué, quand des interfaces "unnumbered" sont utilisées avec DHCP, les routes de hosts sont installées dynamiquement. Ceci est peut-être la meilleure approche pour déployer RBE. Le serveur DHCP peut être localisé soit chez le fournisseur de services soit chez le fournisseur d'accès.

11 Voici la configuration requise sur le NRP pour déployer RBE avec des interfaces IP "unnumbered":
interface Loopback0 ip address no ip directed−broadcast ! interface ATM0/0/0.132 point−to−point ip unnumbered Loopback0 ATM route−bridged ip pvc 1/32 encapsulation aal5snap interface ATM0/0/0.133 point−to−point pvc 1/33 Comment le service destinataire est-il atteint? Jusqu'à ce point le thème a été la technologie de base de l'accès utilisant RBE comme méthode d'encapsulation. Cependant en utilisant cette architecture, l'opérateur peut offrir des services variés et différentes options pour lesquelles le fournisseur d'accès peut acheminer le trafic vers le fournisseur de services. Ces concepts sont expliqués dans les paragraphes qui suivent. Fourniture de l'accès Internet Dans ce scénario, la fonction principale de l'opérateur est de fournir un accès Internet à haut débit aux abonnés. Comme l'opérateur fournit le service final, la gestion des adresses IP est de la responsabilité de l'opérateur. Il peut attribuer des adresses IP publiques à ses abonnés en utilisant un serveur DHCP ou il peut opter pour des adresses privées et ensuite utiliser NAT pour joindre le monde extérieur. Services Globaux Si l'opérateur veut fournir des services à d'autres opérateurs, il put le faire. Dans ce scénario, l'opérateur ne préfère pas gérer les adresses IP de tous les abonnés des au- tres opérateurs. L'opérateur passe un accord avec les autres opérateurs pour fournir les adresses IP à ces abonnés. Ceci peut être accompli par l'opérateur d'accès en acheminant les requêtes DHCP venant des abonnés vers les serveurs DHCP des opé- rateurs de services. L'opérateur d'accès doit configurer ses sous-interfaces ATM avec une des adresses IP prise dans l'intervalle et doit annoncer ces routes à l'opérateur de services. l'annonce des routes peut être faite soit avec des routes statiques soit avec un protocole de routage dynamique entre les opérateurs. Les routes statiques sont préférables.

12 Accès d'entreprise L'accès d'entreprise requiert habituellement des services VPN (Virtual Private Network) Cela signifie que l'entreprise ne fournira aucune adresse à l'opérateur d'accès et n'au- torisera pas l'opérateur à annoncer l'espace d'adresses IP de l'entreprise dans le cœur de réseau de l'opérateur d'accès car cela pourrait introduire une faille de sécurité. Les entreprises préfèrent appliquer leurs propres adresses IP à leurs clients ou elles auto- riseront l'accès par des moyens sécurisés comme MPLS/VPN (Multiprotocol Label Switching/ Virtual Private Network) ou L2TP (Layer 2 Tunneling Protocol). L'autre ap- proche pour fournir des accès sécurisés à l'entreprise est le cas où l'opérateur d'accès fournit l'adresse IP initiale à ces abonnés. Par conséquent, les abonnés deviennent attachés au LAN de l'opérateur d'accès. Une fois que les abonnés ont leur adresse ini- tiale, ils peuvent initier un tunnel au travers d'un client logiciel L2TP opérant sur le host. A sont tour, l'entreprise authentifiera cet abonnéet fournira une adresse IP de son espace d'adresses. Cette adresse IP est utilisée pat l'adaptateur L2TP/VPN. De cette manière, les abonnés ont le choix entre la connexion Internet à haut débit ou l'accès au réseau d'entreprise au travers d'un tunnel L2TP sécurisé. Cependant ceci requiert que l'entreprise fournisse l'adresse IP destination du tunnel à l'abonné, laquelle doit être routable dans le cœur de réseau de l'opérateur d'accès. Capacités de sélection de service L'opérateur d'accès peut offrir des capacités variées de sélection de service en utilisant la fonctionnalité SSG (Service Selection Gateway). La SSG offre deux méthodes de sé- lection de service: sélection via la couche 2 ( connue sous le nom de PTA-MD) ou la couche 3 Web. Avec RBE seule la méthode couche 3 Web peut être utilisée. Ceci re- quiert que les abonnés soient attachés au LAN de l'opérateur d'accès; ce qui veut dire que l'opérateur d'accès fournit l'adresse IP initiale à l'abonné et fournit l'accès à Cisco SSD (Service Selection Dashboard). Dans le cas d'une architecture RBE, la méthode de sélection SSG Cisco Web est un excellent moyen pour justifier le trafic abonné. Conclusion RBE est plus évolutif que le pontage standard et fournit de meilleures performances. Il élimine également tous les problèmes de sécurité rencontrés avec le pontage stan- dard. RBE élimine les problèmes de tempête de broadcast du pontage standard. RBE fournit une architecture robuste pour l'opérateur d'accès qui veut éviter la maintenan- ce d'un client logiciel, les problèmes liés au pontage et veut de faibles coûts de déploie- ment. Avec RBE tout est réalisable en utilisant l'architecture de pontage existante.