Ainsi un NAS peut proposer des acc\u00e8s t\u00e9l\u00e9phoniques classiques (dits RTC), des acc\u00e8s de type RNIS (pour notre cas c\u2019est obligatoire\u00a0!), des acc\u00e8s en mode synchrone ou asynchrone, et voir des acc\u00e8s de type GSM ou UMTS pourquoi pas\u00a0!<\/p>\n
Plus le NAS permettra des acc\u00e8s vari\u00e9s et en nombre plus il sera cher\u00a0! Mais ce n\u2019est ici pas notre probl\u00e8me\u00a0! En effet, je n\u2019ai pas l\u2019intention de vous inviter \u00e0 installer un NAS \u00ab\u00a0personnel\u00a0\u00bb sur votre r\u00e9seau, c\u2019est totalement d\u00e9suet de nos jours (dans ma longue carri\u00e8re je ne l\u2019ai vu qu\u2019une seule fois\u00a0!<\/em>), c\u2019est cher et finalement gu\u00e8re moins compliqu\u00e9 (sur les aspects dimensionnements) que ce que nous avons vu pr\u00e9c\u00e9demment.<\/p>\n Nous allons donc plut\u00f4t nous orienter vers l\u2019utilisation des NAS que proposent la majorit\u00e9 des op\u00e9rateurs dans le cadre de leurs offres de r\u00e9seaux.<\/p>\n Les NAS fournis par les op\u00e9rateurs ont vraiment de gros avantages\u00a0:<\/p>\n Ils sont plac\u00e9s en c\u0153ur de r\u00e9seau\u00a0:<\/u><\/strong> ceci implique que tout \u00e9quipement qui \u00e9tabli une connexion sur le NAS est de ce fait directement connect\u00e9 au backbone. Dans le cas d\u2019un secours RNIS, le site en mode secours sera donc about\u00e9 au r\u00e9seau de la m\u00eame fa\u00e7on que lorsqu\u2019il est connect\u00e9 en mode nominal sauf qu\u2019au lieu d\u2019\u00eatre \u00e0 l\u2019extr\u00e9mit\u00e9 d\u2019une liaison permanente il est connect\u00e9 sur une liaison commut\u00e9e (RNIS). Ceci supprime les soucis de transfert de trafic identifi\u00e9s dans le cas d\u2019un secours bout en bout (le site accueillant la connexion de secours devant assurer le renvoi du trafic du site secouru dans le r\u00e9seau via son propre raccordement nominal).<\/p>\n Le dimensionnement des acc\u00e8s n\u2019est plus de votre ressort<\/u><\/strong>\u00a0: vous n\u2019avez plus \u00e0 d\u00e9finir un potentiel d\u2019usage en mode secours pour dimensionner le nombre d\u2019acc\u00e8s RNIS \u00e0 mettre en place. C\u2019est \u00e0 l\u2019op\u00e9rateur de surveiller les taux d\u2019utilisation et de mettre en \u0153uvre les upgrades n\u00e9cessaires. D\u2019ailleurs si l\u2019op\u00e9rateur est s\u00e9rieux il aura plus d\u2019un NAS\u00a0! Il pourra donc s\u2019arranger pour r\u00e9partir la charge\u00a0! Pour votre cas, vous devez donc juste estimer le d\u00e9bit de secours n\u00e9cessaire pour votre site (ou pour chaque site de votre r\u00e9seau).<\/p>\n Ils sont g\u00e9n\u00e9ralement secourus\u00a0:<\/u><\/strong> comme indiqu\u00e9 pr\u00e9c\u00e9demment, tout op\u00e9rateur s\u00e9rieux aura plus d\u2019un NAS sur son r\u00e9seau backbone. Il pourra donc s\u2019assurer d\u2019un re-routage des demandes de connexion si le NAS appel\u00e9 ne r\u00e9pond pas (hors service ou surcharge). Pour cela il utilisera les fonctionnalit\u00e9s du R<\/strong>\u00e9seau I<\/strong>ntelligent (RI<\/strong>). Essayons d\u2019expliquer simplement ce qu\u2019est le RI\u00a0!<\/p>\n Le RI<\/strong> est en fait un ensemble de services \u00e9volu\u00e9s construits sur la base des fonctionnalit\u00e9s offertes par le r\u00e9seau de signalisation RNIS. Ce r\u00e9seau de signalisation est distinct du r\u00e9seau de commutation lui-m\u00eame, on l\u2019appelle le r\u00e9seau \u00ab\u00a0s\u00e9maphore<\/strong>\u00a0\u00bb, il utilise la normalisation CCITT N\u00b0 7<\/strong> (pour les curieux ou \u00e9rudits\u00a0: on parle aussi bien de r\u00e9seau \u00ab\u00a0s\u00e9maphore\u00a0\u00bb que de r\u00e9seau \u00ab\u00a0CCITT N\u00b0 7\u00a0\u00bb\u00a0! C\u2019est la m\u00eame chose\u00a0!<\/em>). En fait, les canaux B d\u2019un acc\u00e8s RNIS sont connect\u00e9s au r\u00e9seau de commutation, et les canaux D sont connect\u00e9s au r\u00e9seau \u00ab\u00a0s\u00e9maphore\u00a0\u00bb. C\u2019est le r\u00e9seau s\u00e9maphore qui v\u00e9hicule toute la signalisation n\u00e9cessaire \u00e0 l\u2019\u00e9tablissement, la gestion et la lib\u00e9ration d\u2019une communication sur canaux B. Avant chaque \u00e9tablissement de connexion il y a donc au pr\u00e9alable des \u00e9changes de signalisation sur canal D entre les deux partenaires. Ces \u00e9changes de signalisation ne sont pas directs, ils sont relay\u00e9s par le r\u00e9seau s\u00e9maphore. Lorsque A (site \u00e0 secourir) souhaite \u00e9tablir une communication vers B (NAS de secours), il transmet sur canal D la demande de connexion en indiquant le d\u00e9bit souhait\u00e9 (d\u00e9fini le nombre de canaux B \u00e0 \u00e9tablir), le type de service (il est possible en RNIS d\u2019indiquer le type de service que l\u2019on souhaite v\u00e9hiculer sur les canaux B. Il existe les services Voix ou Data), le num\u00e9ro appel\u00e9 et une foule d\u2019autres petites informations pas forc\u00e9ment captivantes pour nous ici\u00a0! Le r\u00e9seau s\u00e9maphore va relayer ses informations vers B. Si l\u2019\u00e9quipement connect\u00e9 \u00e0 B n\u2019est pas disponible (hors service ou surcharg\u00e9), le point d\u2019acc\u00e8s s\u00e9maphore de raccordement le saura. Le titulaire du raccordement pourra avoir souscrit \u00e0 des diff\u00e9rentes options comme \u00ab\u00a0Re-routage sur indisponibilit\u00e9s<\/strong>\u00a0\u00bb. L\u2019op\u00e9rateur RNIS aura dans ce cas programm\u00e9 dans un le r\u00e9seau s\u00e9maphore une redirection de l\u2019appel vers un autre num\u00e9ro en cas d\u2019indisponibilit\u00e9 de B. L\u2019appel de A sera donc envoy\u00e9 ainsi vers un autre NAS\u00a0! Le secours est ainsi assur\u00e9 de mani\u00e8re totalement transparente pour A\u00a0!<\/p>\n Ils sont r\u00e9partis g\u00e9ographiquement<\/u><\/strong>\u00a0: si le backbone op\u00e9rateur est \u00e9tendu (dimension nationale ou internationale) il est probable que les NAS soient r\u00e9partis sur l\u2019ensemble du territoire couvert. Ceci permet\u00a0:<\/p>\n Petite remarque<\/strong>\u00a0: Bien souvent l\u2019op\u00e9rateur n\u2019aura qu\u2019un seul et m\u00eame num\u00e9ro d\u2019appel pour ses diff\u00e9rents NAS d\u2019un m\u00eame pays. Donc tous les routeurs RNIS fran\u00e7ais (par exemple) de votre r\u00e9seau auront le m\u00eame num\u00e9ro d\u2019appel vers le NAS, que le site soit \u00e0 Marseille ou \u00e0 Paris. C\u2019est encore une fois le RI qui assurera le reroutage vers le NAS le plus proche du site appelant. On appelle cela le routage g\u00e9ographique\u00a0! Ha\u00a0! Il est fameux ce RI\u00a0!<\/em><\/p>\n La tarification est plus attractive<\/u><\/strong>\u00a0: au final, une solution de secours par NAS pr\u00e9sentera une tarification beaucoup plus attractive qu\u2019un secours bout en bout personnalis\u00e9. Ceci en raison des principaux points suivants\u00a0:<\/p>\n Le secours par NAS (op\u00e9rateur) permet donc de s\u2019affranchir de la majorit\u00e9 des points d\u2019imperfections soulev\u00e9s dans l\u2019option de secours bout en bout. Seul reste le probl\u00e8me d\u2019un d\u00e9bit de secours assez limit\u00e9 li\u00e9 \u00e0 la technologie RNIS. A noter de plus que dans la th\u00e9orie avec un secours bout en bout vous pourriez atteindre un d\u00e9bit de 1920 Kbps (30 canaux B\u00a0cumul\u00e9s) ce qu\u2019aucun op\u00e9rateur ne vous proposera sur technologie NAS. G\u00e9n\u00e9ralement le d\u00e9bit maximum de secours propos\u00e9 sur NAS op\u00e9rateur est de 512 Kbps.<\/p>\n L\u2019approche est franchement similaire \u00e0 celle du secours bout en bout. En effet, apr\u00e8s tout un secours par NAS c\u2019est un secours RNIS bout en bout avec \u00e0 une extr\u00e9mit\u00e9 un routeur et \u00e0 l\u2019autre un NAS\u00a0! Les notions de d\u00e9tection d\u2019indisponibilit\u00e9, d\u2019\u00e9tablissement de communication et de lib\u00e9ration de la connexion sont les m\u00eames. Toutefois, en regard du caract\u00e8re \u00ab\u00a0mutualis\u00e9\u00a0\u00bb du NAS il sera n\u00e9cessaire de mettre en \u0153uvre quelques artifices de s\u00e9curisation suppl\u00e9mentaires.<\/p>\n Nous avons vu pr\u00e9c\u00e9demment que l\u2019identification d\u2019un appelant pouvait se faire sur deux niveaux\u00a0:<\/p>\n Pour ce deuxi\u00e8me point il faut donc que le NAS qui accueille la connexion ait une table des identifiants \/ Mot de passe de chaque utilisateur (si nomade) ou routeur (si secours RNIS) pour v\u00e9rifier ces identifications.<\/p>\n On pourrait envisager une table locale m\u00e9moris\u00e9e dans le NAS lui-m\u00eame. Charge \u00e0 l\u2019op\u00e9rateur de mettre \u00e0 jour cette table \u00e0 chaque cr\u00e9ation de user. Mais nous avons vu que le RI permettait de rerouter l\u2019appelant vers d\u2019autres NAS si celui le plus proche est indisponible ou surcharg\u00e9. On ne peut donc pas anticiper le NAS de connexion ! Ceci implique qu\u2019il faudrait entrer les identifications dans tous les NAS\u00a0!<\/p>\n L\u2019op\u00e9rateur est plut\u00f4t pragmatique \u2026 Il va donc pr\u00e9f\u00e9rer utiliser une base centralis\u00e9e qui sera consult\u00e9e par chaque NAS \u00e0 chaque demande de connexion. La solution d\u2019identification la plus connue dans ce type d\u2019usage est la base RADIUS (Remote Authentication Dial In User Service). Cette technologie permet de mettre en \u0153uvre des fonctionnalit\u00e9s d\u2019identification tr\u00e8s \u00e9volu\u00e9e avec des volum\u00e9tries pharamineuses, mais ce n\u2019est pas l\u2019objet de notre cours. Retenons simplement que ces bases sont impl\u00e9ment\u00e9es sur des serveurs d\u00e9di\u00e9s que l\u2019on appelle couramment\u00a0: Serveur Radius<\/strong>.<\/p>\n Par contre, si ce serveur (ou ces serveurs lorsqu\u2019on pense \u00e0 installer des serveurs de secours) doit \u00eatre contact\u00e9 par n\u2019importe quel NAS, il faut que chacun d\u2019entre-eux puisse le joindre \u00e0 travers un r\u00e9seau. Il faut donc installer les NAS en r\u00e9seau avec le serveur Radius<\/strong>.<\/p>\n Les NAS sont des \u00e9quipements co\u00fbteux qu\u2019il est indiqu\u00e9 d\u2019optimiser. Un op\u00e9rateur envisagera tr\u00e8s certainement d\u2019utiliser ces \u00e9quipements pour divers types d\u2019utilisation. Nous avons \u00e9voqu\u00e9 tout \u00e0 l\u2019heure la possibilit\u00e9 de connecter des nomades en plus de l\u2019utilisation pour les backup RNIS. Mais l\u2019op\u00e9rateur pourra \u00e9ventuellement les utiliser pour des acc\u00e8s \u00e0 Internet comme pour des acc\u00e8s \u00e0 un r\u00e9seau priv\u00e9 type VPN. Pour certains (les plus gros) ils peuvent m\u00eame \u00ab\u00a0revendre\u00a0\u00bb de la capacit\u00e9 d\u2019acc\u00e8s \u00e0 d\u2019autres op\u00e9rateurs plus petits pour leur permettre d\u2019offrir des acc\u00e8s \u00e0 leur propre r\u00e9seau.<\/p>\n On pourra alors \u00eatre confront\u00e9 \u00e0 la mise en relation des NAS avec plusieurs bases Radius, chacune g\u00e9rant l\u2019identification des acc\u00e8s pour un service donn\u00e9. On pourra dans ce cas utiliser un serveur dit \u00ab\u00a0Proxy Radius\u00a0\u00bb qui proc\u00e9dera \u00e0 une analyse partielle de l\u2019identifiant afin de relayer la demande d\u2019acc\u00e8s vers le bon Radius.<\/p>\n Le sch\u00e9ma ci-dessus illustre le cas de l\u2019utilisation d\u2019un m\u00eame NAS pour deux services diff\u00e9rents\u00a0:<\/p>\n Le proxy-radius analyse l\u2019identifiant transmis pour identifier la base Radius \u00e0 interroger. Ceci imposera g\u00e9n\u00e9ralement de s\u2019accorder sur un format bien connu pour l\u2019identifiant. Ici nous donnons un exemple d\u2019identifiant structur\u00e9 en user@service_ID<\/a>. La partie service_ID<\/strong> permet au proxy Radius d\u2019identifier le Radius vers qui relayer la requ\u00eate (base de correspondance dans le proxy-radius). Mais ce n\u2019est qu\u2019un exemple \u2026 tr\u00e8s \u2026 r\u00e9el<\/em>\u00a0!<\/p>\n Nous supposons maintenant que l\u2019autorisation d\u2019acc\u00e8s \u00e0 chaque service a \u00e9t\u00e9 donn\u00e9 au nomade ou au routeur par les Radius concern\u00e9s. L\u2019autorisation a \u00e9t\u00e9 relay\u00e9e par le proxy-radius, chaque NAS la re\u00e7oit. Que font-ils\u00a0?<\/p>\n Le cas simple mais irr\u00e9el<\/u><\/strong>\u00a0: chaque NAS est connect\u00e9 \u00e0 un PoP qui donne acc\u00e8s au service consid\u00e9r\u00e9. Le NAS envoie donc tous les paquets IP en provenance de la connexion PPP vers le PoP d\u2019acc\u00e8s au service (r\u00e9seau priv\u00e9 pour le routeur, Internet pour le nomade). Mais comme nous avons vu que nous ne pouvons pas pr\u00e9dire sur quel NAS se pr\u00e9sentera la connexion (routage du RI), ceci suppose que chaque NAS devra \u00eatre connect\u00e9 \u00e0 tous les PoP des diff\u00e9rents services\u00a0! Ceci complexifie grandement l\u2019architecture et en augmente le co\u00fbt\u00a0!<\/p>\n Comme l\u2019indique le sch\u00e9ma ci-dessus, il faudra autant de ports d\u2019entr\u00e9e sur les PoP qu\u2019il y a de NAS potentiels. Sur les NAS il faudra autant de ports de sortie qu\u2019il y a de PoP de service \u00e0 atteindre\u00a0! Sans compter le co\u00fbt des liaisons car les PoP ne seront pas forc\u00e9ment co-localis\u00e9s aux NAS\u00a0!<\/p>\n La solution\u00a0apparemment plus simple<\/u><\/strong> : int\u00e9grer les PoP dans le r\u00e9seau IP de connexion des NAS, celui-ci supportant d\u00e9j\u00e0 les Radius.<\/p>\n Les NAS ont d\u00e9j\u00e0 une connexion au r\u00e9seau de collecte pour l\u2019acc\u00e8s aux Radius (via un PoP g\u00e9n\u00e9ralement co-localis\u00e9). Il suffit de connecter les PoP d\u2019acc\u00e8s aux diff\u00e9rents services sur ce m\u00eame r\u00e9seau et les NAS pourront envoyer les paquets IP dans ce r\u00e9seau pour qu\u2019ils atteignent les PoP et donc les services souhait\u00e9s \u2026<\/p>\n Il y a deux probl\u00e8mes induits par cette configuration<\/u><\/strong>\u00a0:<\/p>\n La r\u00e9ponse par le tunneling (tunnel IP)<\/u><\/strong>\u00a0: Le NAS va \u00e9tablir un tunnel IP entre lui et le PoP d\u2019acc\u00e8s au service correspondant \u00e0 la demande de l\u2019initiateur de la connexion. Il placera dans ce tunnel les paquets \u00e0 destination du service concern\u00e9. Ceci lui permet ainsi d\u2019avoir un plan d\u2019adressage dans le r\u00e9seau de collecte compl\u00e9tement dissoci\u00e9 de celui des r\u00e9seaux qu\u2019il interconnecte\u00a0et garanti l\u2019isolation des paquets dans le r\u00e9seau de collecte.<\/p>\n Il existe de nombreux principes et protocoles de tunneling, les plus connus \u00e9tant l\u2019IPSec<\/strong> (IP s\u00e9curis\u00e9) mais aussi GRE<\/strong> (sp\u00e9cifique Cisco) ou L2F<\/strong>.<\/p>\n Chacun a ses avantages ou inconv\u00e9nient\u00a0: IPsec offre en plus du tunneling une encryption des donn\u00e9es permettant d\u2019envisager des communications confidentielles m\u00eame \u00e0 travers Internet. GRE est un mode de tunneling \u00ab\u00a0ligth\u00a0\u00bb consistant \u00e0 placer un paquet IP dans un autre paquet IP sans g\u00e9rer de mode \u00ab\u00a0connect\u00e9\u00a0\u00bb sur le tunnel. Ceci en fait un protocole rentable (peu de surencapsulation, pas de paquet de gestion de connexion) mais peu fiable (impossible de savoir si le tunnel est bien actif ou pas).<\/p>\n Un autre protocole beaucoup plus usit\u00e9 est le L2TP<\/strong> (L<\/strong>ayer 2<\/strong> T<\/strong>unneling P<\/strong>rotocol). C\u2019est celui qui est g\u00e9n\u00e9ralement impl\u00e9ment\u00e9 sur les r\u00e9seaux de NAS car il permet d\u2019encapsuler directement la trame PPP dans un paquet IP. De plus il offre deux niveaux d\u2019authentification.<\/p>\n L2TP r\u00e9alise une encapsulation de PPP dans UDP\/IP. Il y a donc un overhead d\u2019encapsulation sup\u00e9rieur \u00e0 GRE mais pas d\u2019ajo\u00fbts lourd protocolaire car UDP reste une proc\u00e9dure de niveau 4 tr\u00e8s \u00ab\u00a0ligth\u00a0\u00bb (pas de mode connect\u00e9, pas de gestion de flux, pas de reprise sur erreur). On aurait pu penser qu\u2019une encapsulation PPP dans TCP\/IP aurait \u00e9t\u00e9 plus s\u00e9curis\u00e9, mais les proc\u00e9dures TCP auraient fait double emploi avec celles de PPP\u00a0!<\/p>\n Le tunnel est \u00e9tabli entre deux \u00e9quipements d\u2019extr\u00e9mit\u00e9\u00a0:<\/p>\n Le LAC<\/strong> (L<\/strong>2TP A<\/strong>ccess C<\/strong>oncentrator) qui est l\u2019organe d\u2019\u00e9tablissement du tunnel. C\u2019est donc pour notre cas le NAS. Il traite les demandes de connexion, v\u00e9rifie les droits d\u2019acc\u00e8s et v\u00e9rifie l\u2019existence d\u2019un tunnel L2TP actif vers la destination souhait\u00e9e. Dans le cas contraire il \u00e9tabli une session.<\/p>\n Le LNS<\/strong> (L<\/strong>2TP N<\/strong>etwork S<\/strong>erver) qui est l\u2019organe de r\u00e9ception (terminaison) du tunnel. C\u2019est donc pour notre cas, un PoP d\u2019acc\u00e8s au service souhait\u00e9. Il r\u00e9alise \u00e9galement une ultime v\u00e9rification des droits d\u2019acc\u00e8s.<\/p>\n<\/div>\n Nous avons pr\u00e9c\u00e9demment expos\u00e9 le principe des serveurs Radius et Proxy Radius pour la gestion des authentifications et avons indiqu\u00e9 que le protocole L2TP g\u00e9re une double authentification.<\/p>\n Pour terminer en beaut\u00e9e sur le secours par NAS, le sch\u00e9ma ci-contre pr\u00e9sente le chronogramme d\u2019\u00e9tablissement d\u2019une communication RNIS via NAS.<\/p>\n Le protocole Radius permet d\u2019embarquer la fourniture de nombreux attributs divers. Lorsque le serveur est sollicit\u00e9 par un NAS ou un LNS afin d\u2019authentifier une identification il pourra retourner dans sa r\u00e9ponse des param\u00e8tres compl\u00e9mentaires comme\u00a0:<\/p>\n Un des soucis majeurs de l\u2019op\u00e9rateur est de pouvoir contr\u00f4ler le taux d\u2019utilisation du service et le cas \u00e9ch\u00e9ant facturer l\u2019usage (ceci d\u00e9pend du type de service souscrit). Le LAC,\u00a0 le LNS ou le Radius (selon le cas) pourront \u00eatre interfac\u00e9 avec un serveur de \u00ab\u00a0ticketting\u00a0\u00bb. A chaque \u00e9tablissement de connexion ils envoient un START et \u00e0 chaque d\u00e9connexion ils \u00e9mettent un STOP pour un userID donn\u00e9. Le serveur enregistre ainsi les nombres et dur\u00e9es de communication qui peuvent ensuite \u00eatre mises en rapport avec une base de facturation. Celle-ci comportera les informations d\u2019abonnement au service relatives au user (type de forfait ou facturation \u00e0 l\u2019usage, type de communication dans ou hors forfait, etc \u2026). Il sera alors facile de g\u00e9n\u00e9rer une facturation automatique.<\/p>\n Ces bases d\u2019authentification Radius et de \u00ab\u00a0ticketting\u00a0\u00bb pourront \u00eatre mises \u00e0 disposition du client via des frontaux http (par exemple) afin de leur offrir un Web d\u2019administration proposant\u00a0:<\/p>\n On voit donc tous les avantages que l\u2019on peut tirer de ce type d\u2019architecture. Mais bien s\u00fbr ceci n\u2019est rentable que dans le cadre d\u2019une volum\u00e9trie importante, donc assez peu adapt\u00e9e \u00e0 des flottes \u00ab\u00a0personnelles\u00a0\u00bb.<\/p>\n Nous avons tout de m\u00eame un peu d\u00e9riv\u00e9 du sujet initial \u00ab\u00a0Backup par NAS\u00a0\u00bb car beaucoup de ces fonctions ne sont en fait utiles que pour des usages en nomade et non pas en mode routeur de secours.<\/p>\n Pour illustrer ce long discours sur les \u00e9l\u00e9ments \u00e0 prendre en compte dans une solution de secours RNIS par NAS, voici en exemple un extrait partiel de param\u00e8trage d\u2019un routeur Cisco. Merci \u00e0 Laurent<\/strong> (qui se reconna\u00eetra !) pour cet extrait de configuration !<\/p>\n interface ATM0\/0.1 point-to-point<?xml:namespace prefix = o ns = \u00ab\u00a0urn:schemas-microsoft-com:office:office\u00a0\u00bb \/><\/p>\n description — EQ_VPN_TDSL LDEF001 vers PE TLS14 ATM2\/0\/1.51 —<\/p>\n bandwidth 1280<\/p>\n ip address 171.20.3.230 255.255.255.252<\/p>\n no snmp trap link-status<\/p>\n pvc 8\/35<\/p>\n vbr-nrt 1272 1272 1<\/p>\n tx-ring-limit 3<\/p>\n oam-pvc manage 5<\/strong><\/p>\n oam retry 3 5 1<\/strong><\/p>\n encapsulation aal5mux ip<\/p>\n service-policy input COUNT-IN<\/p>\n service-policy output COS-OUT<\/th>\n Les lignes oam<\/strong> d\u00e9finissent la fr\u00e9quence \u00e0 laquelle le routeur v\u00e9rifie l\u2019\u00e9tat \u00ab\u00a0up\u00a0\u00bb de la ligne.<\/p>\n => D\u00e9tection d\u2019indisponibilit\u00e9 du lien<\/th>\n<\/tr>\n description *** Sec RNIS **SPN PE-LNS** <\/strong><\/p>\n no ip address<\/strong><\/p>\n encapsulation ppp<\/strong><\/p>\n no ip route-cache cef<\/strong><\/p>\n no ip route-cache<\/strong><\/p>\n no ip mroute-cache<\/strong><\/p>\n dialer pool-member 1<\/strong><\/p>\n isdn switch-type basic-net3<\/strong><\/p>\n isdn point-to-point-setup<\/strong><\/p>\n no fair-queue<\/strong><\/p>\n no cdp enable<\/strong><\/p>\n ppp multilink<\/strong><\/p>\n \u00a0<\/strong><\/p>\n interface BRI1\/0 encapsulation ppp<\/strong><\/p>\n no ip route-cache cef<\/strong><\/p>\n no ip route-cache<\/strong><\/p>\n no ip mroute-cache<\/strong><\/p>\n dialer pool-member 1<\/strong><\/p>\n isdn switch-type basic-net3<\/strong><\/p>\n isdn point-to-point-setup<\/strong><\/p>\n no fair-queue<\/strong><\/p>\n no cdp enable<\/strong><\/p>\n ppp multilink<\/strong><\/td>\n Chez Cisco on d\u00e9fini un minimum de param\u00e8trage sur les interfaces \u00ab\u00a0dial\u00a0\u00bb directement.<\/p>\n La commande \u00ab\u00a0dialer pool-member<\/strong>\u00a0\u00bb permet de regrouper plusieurs interfaces physiques en un m\u00eame \u00ab\u00a0pool\u00a0\u00bb d\u2019interfaces. Ceci permet donc d\u2019obtenir une interface virtuelle compos\u00e9e de plusieurs interfaces physiques. Le d\u00e9bit total possible de l\u2019interface virtuelle est donc ici de 256 Kbps (2 acc\u00e8s RNIS soit 4 canaux B).<\/p>\n <\/p>\n <\/p>\n On notera la commande \u00ab\u00a0ppp multilink<\/strong>\u00a0\u00bb permettant d\u2019impl\u00e9menter un cumul des connexions PPP pour ne pr\u00e9senter sur les 4 canaux B qu\u2019une seule et m\u00eame connexion de niveau 2<\/td>\n<\/tr>\n description *-*-*-* Sec RNIS ** SPN PE-LNS – <\/strong><\/p>\n ip unnumbered FastEthernet0\/0<\/strong><\/p>\n encapsulation ppp<\/strong><\/p>\n no logging event link-status<\/strong><\/p>\n dialer pool 1<\/strong><\/p>\n dialer idle-timeout 108<\/strong><\/p>\n dialer enable-timeout 5<\/strong><\/p>\n dialer wait-for-carrier-time 15<\/strong><\/p>\n dialer string [num\u00e9ro de NAS \u00e0 appeler]<\/strong><\/p>\n dialer hold-queue 5<\/strong><\/p>\n dialer load-threshold 1 either<\/strong><\/p>\n dialer-group 1<\/strong><\/p>\n no cdp enable<\/strong><\/p>\n ppp chap hostname [userID@clientID]<\/strong><\/p>\n ppp chap password 7 1210171B17181C0A<\/strong><\/p>\n ppp multilink<\/strong><\/td>\n La commande \u00ab\u00a0ip unnumbered FastEthernet0\/0\u201d <\/strong>indique que l\u2019interface RNIS lorsqu\u2019elle sera active prendra l\u2019adresse IP de l\u2019interface Eth0. C\u2019est une sp\u00e9cificit\u00e9 Cisco qui permet d\u2019\u00e9viter d\u2019affecter des IP \u00e0 des interfaces Dial. Le routeur transf\u00e8re tout le trafic vers l\u2019Ethernet.<\/p>\n Les \u00ab\u00a0dialer enable-timeout, wait for carrier, idle-timeout\u00a0\u00bb d\u00e9finissent les timers d\u2019attente avant connexion, avant d\u00e9connexion ou attente de porteuse.<\/p>\n On note les param\u00e8trages PPP (encapsulation, multilink, identifiant et mot de passe CHAP).<\/p>\n La commande \u00ab\u00a0load-treshold\u00a0\u00bb d\u00e9fini comment et combien de canaux B doivent \u00eatre ouverts en fonction de la charge.<\/p>\n La commande \u00ab\u00a0dialer-group\u00a0\u00bb renvoie aux commandes \u00ab\u00a0dialer pool-member\u00a0\u00bb des interfaces BRI permettant ainsi de d\u00e9finir quelles interfaces BRI sont group\u00e9es sous l\u2019interface \u00ab\u00a0dialer 1\u00a0\u00bb.<\/p>\n <\/td>\n<\/tr>\n access-list 101 deny\u00a0\u00a0 udp any eq netbios-ns any<\/strong><\/p>\n access-list 101 deny\u00a0\u00a0 udp any eq ntp any eq ntp<\/strong><\/p>\n access-list 101 deny\u00a0\u00a0 udp any eq rip any eq rip<\/strong><\/p>\n access-list 101 permit ip any any<\/strong><\/p>\n dialer-list 1 protocol ip list 101<\/strong><\/td>\n Ici tout trafic IP peut activer l\u2019interface sauf le trafic netbios, ntp et rip.<\/p>\n La commande \u00ab\u00a0dialer-list\u00a0\u00bb indique qu\u2019on applique la liste de filtres 101 \u00e0 l\u2019interface \u00ab\u00a0dialer 1\u00a0\u00bb.<\/p>\n <\/td>\n<\/tr>\n \u00a0<\/strong><\/p>\n \u00a0<\/strong><\/p>\n ip route 0.0.0.0 0.0.0.0 Dialer1\u00a0250<\/strong><\/td>\n Par contre la deuxi\u00e8me ligne indique la m\u00eame chose mais vers l\u2019interface \u00ab\u00a0dialer 1\u00a0\u00bb avec un co\u00fbt de 250.<\/p>\n Donc tant qu\u2019ATM0 est active Dialer 1 n\u2019est pas utilis\u00e9e.<\/td>\n<\/tr>\n Nous voici arriv\u00e9 au terme de ce long chapitre sur le secours RNIS par NAS. Vous aurez remarqu\u00e9 que m\u00eame sur un sujet aussi simple, on peut en dire long. J\u2019ai souhait\u00e9 \u00eatre pr\u00e9cis car c\u2019\u00e9tait l\u2019occasion id\u00e9ale de mettre en lumi\u00e8re la technologie RNIS, les probl\u00e9matiques d\u2019authentification et de s\u00e9curit\u00e9 ainsi que certains principes de routage et de dimensionnement.<\/p>\n Mais il est toujours bien de ne retenir que l\u2019essentiel, et je vous propose les ponts suivants\u00a0:<\/p>\n Le secours RNIS reste tout de m\u00eame une technologie offrant un d\u00e9bit relativement limit\u00e9 dans une technologie assez couteuse.\u00a0Nous verrons dans le chapitre suivant que l’av\u00e8nement de l’ADSL a compl\u00e9tement chang\u00e9 l’approche du secours. Reste \u00e0\u00a0s’affranchir des probl\u00e8mes d’\u00e9ligiblit\u00e9s !<\/p>\n Il vous faudra toutefois patienter un peu, car ce chapitre n’est pas encore \u00e9crit \u00e0 ce jour (Juin 2009) !<\/p>\n Un NAS c\u2019est quoi\u00a0? Le NAS (Network Access Server) est une sorte de PoP (Point Of Presence ou Point d\u2019acc\u00e8s) un peu sp\u00e9cifique. Il a pour fonction premi\u00e8re de fournir des m\u00e9thodes d\u2019acc\u00e8s les plus vari\u00e9es possibles sur un r\u00e9seau. Ainsi un NAS peut proposer des acc\u00e8s t\u00e9l\u00e9phoniques classiques (dits RTC), des acc\u00e8s de type\u2026 Lire la suite »<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":52,"comment_status":"closed","ping_status":"closed","template":"page-templates\/full-width.php","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"class_list":["post-598","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/pages\/598","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/comments?post=598"}],"version-history":[{"count":5,"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/pages\/598\/revisions"}],"predecessor-version":[{"id":631,"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/pages\/598\/revisions\/631"}],"wp:attachment":[{"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/media?parent=598"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Les avantages du NAS op\u00e9rateur<\/h2>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_NAS1.jpg\")
<\/p>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_NAS2.jpg\")
<\/p>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_RI.jpg\")
<\/p>\n\n
\n
Architecture technique du secours par NAS<\/h2>\n
L\u2019identification de l\u2019utilisateur<\/h3>\n
\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_RADIUS1.jpg\")
<\/p>\nL\u2019identification du service<\/h3>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_PROXY_RADIUS.jpg\")
<\/p>\n\n
\nLes deux connexions empruntent le m\u00eame NAS. Celui-ci relaie les identifiants re\u00e7us par la connexion PPP (rappelez-vous \u2026 PAP\/CHAP<\/em>) vers le proxy-radius.<\/li>\n<\/ul>\nL\u2019acc\u00e8s au service<\/h3>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_POP1.jpg\")
<\/p>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_POP2.jpg\")
<\/div>\n\n
Principe du tunneling<\/h3>\n
Principes du tunneling L2TP<\/h3>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_L2TP.jpg\")
<\/p>\nCha\u00eene d\u2019authentification et de connexion<\/h3>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_AUTHENT_L2TP.jpg\")
<\/p>\nUn peu plus sur le Radius et sur les LAC\/LNS<\/h3>\n
\n
\n
\n
Exemple de param\u00e8trage d\u2019un routeur<\/h2>\n
\n\n
\n \n Ici une interface routeur de type SDSL impl\u00e9mentant ATM en protocole de niveau 2<\/p>\n \n interface BRI1\/0<\/strong><\/p>\n
\n<\/strong>description *** Sec RNIS **SPN PE-LNS**
\nno ip address<\/strong><\/p>\nParam\u00e8trage de deux interfaces RNIS pour le secours.<\/p>\n \n interface Dialer1<\/strong><\/p>\n C\u2019est ici que l\u2019on param\u00e8tre r\u00e9ellement la connexion RNIS.<\/p>\n \n access-list 101 remark **** Conditions montee RNIS et maintien de connexion ****<\/strong><\/p>\n On d\u00e9fini ici la nature du trafic \u00e0 scanner susceptible d\u2019activer la connexion RNIS.<\/p>\n \n ip route 0.0.0.0 0.0.0.0 ATM0\/0.1<\/p>\n Ici un extrait de la configuration du routage (en statique ici). On voit que le trafic pour n\u2019importe quelle destination (0.0.0.0 0.0.0.0) est rout\u00e9 sur l\u2019interface nominale ATM0. Sans co\u00fbt indiqu\u00e9 (co\u00fbt nul)<\/p>\n \n <\/td>\n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n En r\u00e9sum\u00e9<\/h2>\n
\n
\n
Page Pr\u00e9c\u00e9dente <\/a>| Sommaire<\/a><\/h5>\n","protected":false},"excerpt":{"rendered":"