Architecture de référence RBE (encapsulation du type pont routeur)
Contenu
Introduction
Ce document décrit une architecture ADSL (asymetric digital Subscriber Line) de bout en bout qui utilise la fonction RBE (Routed Bridged Encapsulation) du Cisco 6400 Universal Access Concentrator (UAC). RBE a été développé pour traiter les problèmes de pontage connus de la RFC1483, y compris les tempêtes de diffusion et la sécurité. À l'exception du fait qu'il fonctionne exclusivement sur ATM, la fonction RBE fonctionne de la même manière que le pontage à mi-chemin. L'évolutivité, les performances et la sécurité supplémentaires peuvent être obtenues en utilisant les caractéristiques uniques des abonnés xDSL.
Hypothèse
L'architecture de référence est conçue à l'aide du modèle ADSL Forum Reference Architecture. L'architecture couvre différentes offres de services par le fournisseur d'accès réseau (NAP) et différents scénarios de transmission du trafic d'abonné au fournisseur de services réseau (NSP). Dans cette architecture, RBE est la méthode d’encapsulation utilisée par le Cisco 6400. Le contenu de ce document est basé sur les déploiements existants, ainsi que sur certains tests internes effectués sur l'architecture. Pour obtenir des informations sur les fonctionnalités avancées et les modifications, reportez-vous aux notes de version de la dernière version du logiciel Cisco IOS®. Actuellement, RBE est pris en charge sur les plates-formes Cisco 6400, Cisco 7200 et Cisco 7500. Ce document est limité aux discussions sur le Cisco 6400.
Présentation technologique
Du point de vue du réseau, la connexion ATM ressemble à une connexion routée. Le trafic de données est reçu sous forme de paquets RFC1483, mais il s'agit de trames Ethernet RFC1483 ou IEEE 802.3. Au lieu de ponter la trame Ethernet ou IEEE 802.3, comme dans le cas du pontage RFC1483 normal, le routeur achemine les paquets sur l’en-tête de couche 3. À l'exception de certaines vérifications de ligne, l'en-tête de pont est ignoré. Ceci est expliqué en détail dans la section suivante.
Description opérationnelle
Du point de vue opérationnel, le routeur fonctionne comme si l’interface de pont routé était connectée à un réseau local Ethernet. L'opération est décrite ci-dessous de deux façons : paquets provenant des locaux du client et paquets destinés aux locaux du client.
Pour les paquets provenant des locaux du client, l’en-tête Ethernet est ignoré et l’adresse IP de destination est examinée. Si l’adresse IP de destination se trouve dans le cache de route, le paquet est commuté rapidement vers l’interface de sortie. Si l’adresse IP de destination ne figure pas dans le cache de route, le paquet est mis en file d’attente pour la commutation de processus. En mode de commutation de processus, l’interface de sortie par laquelle le paquet doit être acheminé se trouve dans la table de routage. Une fois l’interface sortante identifiée, le paquet est acheminé via cette interface. Cela se produit sans qu'il soit nécessaire d'utiliser un groupe de ponts ou une interface BVI (Bridge Group Virtual Interface).
Pour les paquets destinés aux locaux 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 IP. Ensuite, le routeur vérifie dans la table ARP (Address Resolution Protocol) associée à cette interface l’adresse MAC de destination à placer dans l’en-tête Ethernet. Si aucun n’est trouvé, le routeur génère une requête ARP pour l’adresse IP de destination. La requête ARP est transmise à l’interface de destination uniquement. Contrairement au pontage, dans lequel la requête ARP est envoyée à toutes les interfaces du groupe de pontage.
Pour un scénario utilisant des interfaces non numérotées (où vous pouvez trouver deux abonnés sur le même sous-réseau), l'interface de pont routé utilise le proxy ARP. Par exemple, 192.168.1.2 (Hôte A) veut communiquer avec 192.168.1.3 (Hôte B). Cependant, l’hôte A se trouve sur le même sous-réseau que l’hôte B.
L’hôte A doit apprendre l’adresse MAC de l’hôte B en envoyant une diffusion ARP à l’hôte B. Lorsque l’interface de pont routé au niveau du périphérique d’agrégation reçoit cette diffusion, elle envoie une réponse ARP proxy avec l’adresse MAC 192.168.1.1, Hôte A. Il prend cette adresse MAC, la place dans son en-tête Ethernet et envoie le paquet. Lorsque le routeur reçoit le paquet, il rejette l’en-tête et examine l’adresse IP de destination, puis le achemine sur l’interface appropriée.
Avantages de RBE
RBE a été développé dans le but de résoudre certains des problèmes rencontrés par l'architecture de pontage RFC1483. RBE conserve les principaux avantages de l'architecture de pontage RFC1483, tout en éliminant la plupart de ses inconvénients.
-
Configuration minimale au niveau de l’équipement client (CPE).
Le fournisseur de services considère que c'est important car il n'a plus besoin d'un grand nombre de camions et n'a plus besoin d'investir massivement dans le personnel pour la prise en charge de protocoles de niveau supérieur. Le CPE en mode pont agit comme un périphérique très simple. Un dépannage minimal est nécessaire au niveau de l’équipement d’abonné, car tout ce qui provient d’Ethernet passe directement du côté du WAN.
-
Facilité de migration des architectures de pontage pures vers RBE. Aucune modification n'est requise au niveau de l'abonné.
-
Évite les problèmes de piratage IP et d'usurpation ARP rencontrés dans les architectures de pontage pures classiques. RBE empêche également les tempêtes de diffusion en utilisant des connexions point à point. La sécurité est le principal inconvénient des architectures de pontage pures.
-
Par rapport aux architectures de pontage pures, RBE offre des performances supérieures en raison de la mise en oeuvre du routage au niveau du périphérique d'agrégation. En outre, RBE est plus évolutif, car il n'a pas de limitations de groupe de ponts.
-
Prend en charge la sélection Web de couche 3 à l'aide de la passerelle de sélection de services Cisco (SSG).
Considérations relatives à la mise en œuvre
Certains des points clés à prendre en compte avant de mettre en oeuvre cette architecture sont les mêmes que ceux mentionnés dans le document RFC1483 Bridging Baseline Architecture.
RBE est recommandé lorsque :
-
Les scénarios sont les mêmes que dans les architectures de pontage existantes.
-
Le PAN veut seulement effectuer une gestion minimale des CPE. Le concept d'un CPE simple nécessite une configuration minimale ou nulle après le déploiement du CPE sur le site de l'abonné.
-
Le NAP ne veut pas installer et gérer des clients hôtes sur les hôtes derrière le CPE ponté. Ces tâches d'installation et de maintenance augmentent les coûts de déploiement et de maintenance, notamment en fournissant au personnel du centre d'assistance une connaissance du logiciel client et du système d'exploitation sur lequel le client est exécuté.
-
Le NAP souhaite déployer un réseau ponté évolutif et sécurisé à l'aide d'équipements CPE existants (qui ne peuvent fonctionner qu'en mode pontage RFC1483) et souhaite offrir des fonctionnalités de sélection de services.
La discussion suivante explique comment l'architecture RBE s'adapte et s'adapte aux différents modèles commerciaux.
Architecture réseau
L'architecture réseau RBE est similaire à l'architecture de pontage RFC1483. Comme spécifié dans cette architecture, le périphérique d'agrégation peut se trouver soit dans le NAP, soit dans le NSP. Si une architecture de circuit virtuel permanent (PVC) de bout en bout est utilisée, le NSP termine les abonnés et configure RBE au niveau du périphérique d'agrégation. Si le NAP préfère fournir des services de gros plus la sélection de services, il peut choisir de mettre fin à ces abonnés et d'obtenir des adresses IP à partir d'un serveur DHCP (Dynamic Host Configuration Protocol) local. Dans le cas des services de gros, le NAP peut choisir d’obtenir les adresses IP du NSP. Ces scénarios sont décrits en détail dans la section Gestion IP de ce document.
Considérations de conception pour l'architecture RBE
RBE élimine les principaux risques de sécurité liés à l'architecture de pontage RFC1483. En outre, RBE offre de meilleures performances et est plus évolutif car les sous-interfaces sont traitées comme des interfaces routées.
Cette section explique certains des points clés à prendre en compte avant de concevoir une architecture RBE. Pour les abonnés, les principes de conception restent les mêmes que dans l'architecture de pontage RFC1483.
Dans RBE, un circuit virtuel unique (VC) se voit attribuer une route, un ensemble de routes ou un sous-réseau de routage interdomaine sans classe (CIDR). Ainsi, l'environnement de confiance est réduit à seulement les locaux d'un seul client représentés par les adresses IP dans l'ensemble de routes ou le bloc CIDR. Le FAI contrôle également les adresses attribuées à l’utilisateur. Pour cela, vous devez configurer un sous-réseau sur la sous-interface pour cet utilisateur. Par conséquent, si un utilisateur configure un équipement avec une adresse IP en dehors de la plage d'adresses allouée (ce qui peut entraîner le flux des paquets ARP vers le routeur), le routeur génère une erreur de « câble incorrect » et refuse d'entrer le mappage d'adresses IP à MAC erroné dans sa table ARP.
RBE peut être déployé uniquement à l’aide de sous-interfaces ATM point à point. Il ne peut pas être déployé sur des sous-interfaces multipoints. Même si le côté abonné est ponté, vous n'avez pas besoin de définir de groupes de ponts ou d'interfaces BVI car les sous-interfaces sont traitées comme des interfaces routées.
Les sous-interfaces point à point ATM peuvent être numérotées ou non numérotées sur d’autres interfaces.
Par définition, une interface numérotée est une interface à laquelle une adresse IP spécifique est affectée avec un masque de sous-réseau fixe. Exemple :
Interface atm0/0/0.132 point-to-point ip address 192.168.1.1 255.255.255.252
Comme indiqué dans cet exemple, lorsque RBE est déployé avec une interface numérotée, il doit y avoir un sous-réseau distinct pour chaque abonné. L'hôte à l'extrémité de l'abonné doit être configuré pour 192.168.1.2. Il n'y a qu'un seul hôte à l'extrémité de l'abonné. Si la condition requise est de prendre en charge plusieurs hôtes, le masque de sous-réseau choisi doit prendre en charge plus d’hôtes.
Les interfaces numérotées permettent au contrôle NAP de contrôler le nombre d’hôtes que l’abonné a connectés derrière le CPE. Comme expliqué ci-dessus, ce manque de contrôle était un problème majeur dans l'architecture de pontage RFC1483.
Cependant, cette méthodologie consomme trop d’adresses IP. Vous devez allouer un sous-réseau par abonné, utiliser une adresse IP pour la sous-interface ATM et laisser l'adresse de diffusion et toutes les adresses zéro inutilisées. Pour disposer d’un hôte derrière le CPE, vous devez au moins définir le masque de sous-réseau 255.255.255.252. Compte tenu de la rareté des adresses IP, cette option peut ne pas être envisageable à moins que le NAP/NSP n'utilise l'espace d'adresses privé et effectue la traduction d'adresses de réseau (NAT) pour atteindre le monde extérieur.
Afin de conserver les adresses IP, une alternative consisterait à utiliser des interfaces non numérotées. Par définition, une interface non numérotée est une interface qui utilise l'adresse IP d'une autre interface à l'aide de la commande ip unnumbered. Exemple :
! interface loopback 0 ip address 192.168.1.1 255.255.255.0 ! interface atm0/0/0.132 point-to-point ip unnumbered loopback 0 ! interface atm0/0/0.133 point-to-point ip unnumbered loopback 0
Comme indiqué dans l'exemple ci-dessus, une adresse IP et un sous-réseau ne sont appliqués qu'à l'interface de bouclage. Toutes les sous-interfaces ATM ne seraient pas numérotées vers cette interface de bouclage. Dans ce scénario, tous les abonnés terminés sur les sous-interfaces ATM (non numérotés à bouclage 0) se trouveraient sur le même sous-réseau que celui de bouclage 0. Cela signifie que les abonnés se trouveraient sur le même sous-réseau, mais passeraient par différentes interfaces routées. Dans ce cas, il devient difficile pour le routeur d’identifier l’abonné derrière lequel se trouve la sous-interface ATM. Pour Cisco IOS, 192.168.1.0 (dans le diagramme de gestion IP) est directement connecté via le bouclage d'interface 0, et il n'enverra jamais de trafic destiné à l'une des adresses d'hôte de ce sous-réseau via une autre interface. Pour résoudre ce problème, vous devez configurer explicitement les routes d'hôte statiques. Exemple :
ip route 192.168.1.2 255.255.255.255 atm0/0/0.132 ip route 192.168.1.3 255.255.255.255 atm0/0/0.133
Comme indiqué dans cet exemple, lorsque le routeur doit prendre une décision de routage et transférer le trafic destiné à 192.168.1.2, il choisit ATM 0/0/0.132 comme interface sortante, etc. Sans spécifier ces routes d’hôte statiques, le routeur choisirait l’interface sortante comme bouclage 0 et abandonnerait le paquet.
Même si l'interface non numérotée conserve les adresses IP, elle nécessite une tâche supplémentaire de configuration des routes d'hôte statiques sur le processeur de routage de noeud (NRP) pour chaque abonné. Notez que si un abonné a, par exemple, 14 hôtes derrière le CPE, il n'est pas nécessaire d'avoir des routes d'hôte statiques pour chaque hôte. Une route récapitulative peut être définie pour la sous-interface ATM.
Jusqu’à présent, cette explication a supposé que les hôtes derrière le CPE seront configurés pour les adresses IP statiques. Cette hypothèse n'est pas vraie dans les conceptions réelles. Dans la pratique, le NAP souhaite effectuer une configuration et une maintenance minimales pour le CPE et les hôtes qui lui sont reliés. Pour ce faire, les hôtes doivent obtenir leurs adresses dynamiquement à l’aide d’un serveur DHCP.
Pour obtenir leurs adresses IP dynamiquement, les hôtes doivent être configurés pour obtenir des adresses IP à partir d'un serveur DHCP. Lorsque l’hôte démarre, il envoie des requêtes DHCP. Ces requêtes sont ensuite transmises au serveur DHCP approprié, qui attribue une adresse IP à l'hôte à partir d'une adresse dans sa portée précédemment définie.
Afin de transférer les requêtes DHCP initiales de l'hôte vers le serveur DHCP approprié, vous devez appliquer la commande ip helper-address à l'interface qui reçoit les diffusions. Une fois les diffusions reçues, Cisco IOS examine la configuration de l’adresse ip helper-address pour cette interface et transmet ces requêtes dans un paquet de monodiffusion au serveur DHCP approprié dont l’adresse IP est spécifiée dans l’adresse ip helper-address. Une fois que le serveur DHCP a répondu avec l’adresse IP, il envoie la réponse à l’interface du routeur qui a initialement transféré la requête. Il est utilisé comme interface de sortie pour envoyer la réponse du serveur DHCP à l'hôte qui a demandé le service à l'origine. Le routeur installe également automatiquement une route hôte pour cette adresse.
Si RBE est activé sur une sous-interface et est une unité de données de protocole ponté (PDU) IEEE 802.3, l’encapsulation Ethernet est examinée après l’encapsulation de pont ATM. S'il s'agit d'un paquet IP/ARP, il est traité comme tout autre paquet IP/ARP. Le paquet IP est commuté rapidement. Si elle échoue, elle est mise en file d'attente pour la commutation de processus.
Les performances de RBE sont une grande victoire. Le code de pontage standard d'aujourd'hui a le problème inhérent d'exiger deux classifications distinctes pour un paquet avant qu'une décision de transmission puisse être prise. Une classification est définie comme le processus d'examen (en amont) et de modification (en aval) de l'en-tête de paquet pour le transfert d'informations, qui est relativement coûteux. Une recherche de couche 2 est nécessaire pour déterminer si le paquet doit être routé ou ponté. Ensuite, au niveau de la couche 3, une recherche est nécessaire pour identifier l’emplacement auquel le paquet doit être acheminé. Cette classification se fait en amont comme en aval, ce qui a un impact sur les performances.
Pour RBE, il est prédéterminé par la configuration que le paquet doit être routé dans la direction amont. Par conséquent, il n'est pas nécessaire de passer par le chemin de transfert de pontage, qui était nécessaire dans le cas du pontage standard.
Points clés de RBE
CPE
La configuration du CPE reste identique à celle du pontage standard. Aucune modification du CPE n'est requise pour déployer RBE.
Gestion IP
Lors du déploiement des interfaces numérotées pour RBE, l'allocation d'adresse IP à l'hôte derrière le CPE ponté est généralement gérée via un serveur DHCP. Comme indiqué précédemment, le serveur DHCP peut résider dans le NAP ou dans le NSP. Dans les deux cas, la sous-interface ATM numérotée doit être configurée avec la commande ip helper-address. Si le serveur DHCP doit se trouver au niveau du NSP, le périphérique d'agrégation NAP doit disposer d'une route pour atteindre ce serveur. Le seul scénario dans lequel un NAP utiliserait son propre serveur DHCP et sa propre plage d'adresses IP est quand il veut offrir des fonctionnalités de sélection de service aux abonnés, et ces abonnés sont connectés au réseau local (LAN) au réseau local (NAP).
Si le NAP souhaite utiliser l’espace d’adresses IP du NSP, une des adresses IP de chaque sous-réseau doit être attribuée à la sous-interface ATM. En outre, il devrait y avoir un accord mutuel entre le PAN et le PNN afin que le PAN configure l'adresse correcte. Lorsque le serveur DHCP du NSP attribue des adresses IP, ce contrat doit être en place pour s'assurer que le serveur fournit les informations de passerelle par défaut correctes à l'hôte. Le NAP peut alors résumer une route statique pour toutes les adresses attribuées aux abonnés, ou choisir d'exécuter un protocole de routage avec le NSP pour annoncer ces routes. Dans la plupart des scénarios, les protocoles NAP et NSP préfèrent ne pas utiliser de protocole de routage. Fournir une route statique est une bonne option.
Il s'agit de la configuration de base requise sur le NRP pour le déploiement de RBE avec des interfaces numérotées :
! interface ATM0/0/0.132 point-to-point ip address 192.168.1.1 255.255.255.0 ip helper-address 192.168.3.1 no ip directed-broadcast atm route-bridged ip pvc 1/32 encapsulation aal5snap ! interface ATM0/0/0.133 point-to-point ip address 192.168.2.1 255.255.255.0 ip helper-address 192.168.3.1 no ip directed-broadcast atm route-bridged ip pvc 1/33 encapsulation aal5snap
L’utilisation d’interfaces non numérotées est la meilleure façon de conserver les adresses IP. Comme expliqué précédemment, lorsque des interfaces non numérotées sont utilisées avec DHCP, les routes hôtes sont installées dynamiquement. Il s'agit peut-être de la meilleure approche pour déployer RBE. Le serveur DHCP peut ensuite être situé au niveau du NAP ou du NSP, comme pour les interfaces numérotées.
Il s'agit de la configuration de base requise sur le NRP pour le déploiement de RBE avec des interfaces non numérotées :
interface Loopback0 ip address 192.168.1.1 255.255.255.0 no ip directed-broadcast ! interface ATM0/0/0.132 point-to-point ip unnumbered Loopback0 no ip directed-broadcast ATM route-bridged ip pvc 1/32 encapsulation aal5snap ! interface ATM0/0/0.133 point-to-point ip unnumbered Loopback0 no ip directed-broadcast ATM route-bridged ip pvc 1/33 encapsulation aal5snap
Comment une destination de service est atteinte
Jusqu'à présent, ce document a traité de la technologie d'accès de base utilisant RBE comme méthode d'encapsulation. Cependant, à l'aide de cette architecture, le NAP/NSP peut également offrir divers services et différentes options pour le transfert du trafic d'abonné au NSP par le NAP. Ces concepts sont expliqués dans les sections suivantes.
Accès Internet
Dans ce scénario, la fonction principale du NSP est de fournir un accès Internet haut débit aux abonnés finaux. Puisque le NSP va fournir le service final, la gestion des adresses IP devient la responsabilité du NSP. Il peut attribuer des adresses IP publiques à ses abonnés finaux à l'aide d'un serveur DHCP, ou choisir de fournir des adresses IP privées aux abonnés, puis effectuer la NAT pour atteindre le monde extérieur.
Services de gros
Si le PAN veut offrir des services de gros à d’autres FAI, il peut le faire. Dans ce scénario, le NAP ne préfère généralement pas gérer les adresses IP de tous les abonnés des différents NSP. Le NAP prend des dispositions avec le FAI pour fournir des adresses IP à ces abonnés. Pour ce faire, le NAP transfère les requêtes DHCP provenant des abonnés aux serveurs DHCP des NSP. Le NAP doit configurer ses sous-interfaces ATM avec l’une des adresses IP de cette plage, et il doit annoncer ces routes au NSP. L’annonce de route peut prendre la forme d’une route statique ou d’un protocole de routage entre le NAP et le NSP. La route statique est la méthode préférable pour le protocole NAP, ainsi que pour le protocole NSP.
Accès d'entreprise
L'accès d'entreprise nécessite généralement des services de réseau privé virtuel (VPN). Cela signifie que la société ne fournira aucune adresse IP au NAP et ne permet pas au NAP d'annoncer l'espace d'adresses IP de l'entreprise dans le coeur IP du NAP, car cela pourrait entraîner une violation de la sécurité. Les entreprises préfèrent généralement appliquer leurs propres adresses IP à leurs clients, ou elles autoriseront l'accès via certains moyens sécurisés tels que la commutation multiprotocole par étiquette/réseau privé virtuel (MPLS/VPN) ou le protocole L2TP (Layer 2 Tunneling Protocol).
L’autre approche pour fournir un accès sécurisé à l’entreprise consiste à fournir les adresses IP initiales à ces abonnés. Par conséquent, les abonnés deviennent connectés au réseau local (LAN) au NAP. Une fois que les abonnés ont des adresses IP initiales, ils peuvent lancer un tunnel vers la société via le logiciel client L2TP exécuté sur l'hôte. À son tour, la société authentifiera cet abonné et fournira une adresse IP à partir de son espace d'adressage IP. Cette adresse IP est utilisée par la carte VPN L2TP. De cette manière, les abonnés ont la possibilité de se connecter à leur FAI pour une connexion Internet ou d'accéder à leur entreprise via un accès sécurisé au tunnel L2TP. Cependant, cela exige que la société fournisse l'adresse IP de destination du tunnel à l'abonné, qui doit être routable via le coeur IP du NAP.
Fonctionnalités de sélection de service
Le NAP peut offrir diverses fonctionnalités de sélection de services à l'aide de la fonctionnalité Cisco SSG. Le SSG propose deux méthodes de sélection des services : via la sélection Web de couche 2 (appelée PTA-MD) et de couche 3. Avec RBE, seule la méthode de sélection Web de couche 3 peut être utilisée. Pour cela, les abonnés doivent être connectés au réseau local (LAN) au réseau national d'adaptation (NAP) ; autrement dit, le NAP fournit l'adresse IP initiale à l'abonné et donne accès au tableau de bord de sélection de services Cisco (SSD).
Dans le cas de l'architecture RBE, la méthode de sélection Web de Cisco SSG est un bon moyen de rendre compte du trafic des abonnés.
Conclusion
RBE offre de meilleures performances et est plus évolutif que le pontage standard. Il surmonte également tous les problèmes de sécurité rencontrés dans le pontage standard. RBE élimine les problèmes de tempête de diffusion du pontage standard. RBE fournit une architecture robuste pour le NAP qui veut éviter la maintenance du logiciel hôte client, les problèmes liés au pontage et veut réduire les coûts de déploiement. Avec RBE, tout cela est possible tout en utilisant l'architecture de pontage existante.
Commentaires