IMA3/IMA4 2019/2021 P2 : Différence entre versions
(→Diagnostics) |
|||
(10 révisions intermédiaires par le même utilisateur non affichées) | |||
Ligne 21 : | Ligne 21 : | ||
[[File:Wic1adsl.jpeg|thumbs|200px|left|Carte ADSL]] | [[File:Wic1adsl.jpeg|thumbs|200px|left|Carte ADSL]] | ||
− | Le 1721 peut prendre deux cartes WIC classiques, dont en particulier la carte <tt>WIC-1ADSL=</tt>. La configuration de l'interface ATM | + | Le 1721 peut prendre deux cartes WIC classiques, dont en particulier la carte <tt>WIC-1ADSL=</tt>. Ces cartes peuvent se trouver d'occasion autour de 4 euros. |
+ | |||
+ | La configuration de l'interface ATM de la carte ADSL est simple : | ||
interface ATM0 | interface ATM0 | ||
Ligne 66 : | Ligne 68 : | ||
= Seconde approche Cisco C2600 = | = Seconde approche Cisco C2600 = | ||
− | [[File:2621.jpg|thumbs| | + | [[File:2621.jpg|thumbs|500px|left|2621 en baie]] |
− | Il est possible de récupérer les cartes ADSL <tt> | + | Il est possible de récupérer les cartes ADSL <tt>WIC-1ADSL</tt> de ces routeurs pour les installer sur un Cisco 2621 un peu plus puissant. De plus ce routeur n'est pas affecté par le bogue CSCsa90021, les 2 cartes ADSL peuvent être configurées simultanément. Le 2621 dont nous disposions possédait lui aussi une mémoire flash de 32Mo et une mémoire vive de 64Mo. Du coup le 2621 peut tourner sous un IOS sensiblement identique à celui du 1721 soit un IOS 12.4. |
Pas de modification notable dans la configuration des interfaces ATM, hors numérotation des interfaces et nouvelles options ATM par défaut : | Pas de modification notable dans la configuration des interfaces ATM, hors numérotation des interfaces et nouvelles options ATM par défaut : | ||
− | |||
interface ATM0/0 | interface ATM0/0 | ||
no ip address | no ip address | ||
Ligne 114 : | Ligne 115 : | ||
A noter : l'équilibrage n'a pas été testé avec cette configuration, les deux lignes ADSL n'ayant pas pu être opérationnelles simultanément avant l'acquisition de nouvelles cartes ADSL et le passage à un Cisco 2901. | A noter : l'équilibrage n'a pas été testé avec cette configuration, les deux lignes ADSL n'ayant pas pu être opérationnelles simultanément avant l'acquisition de nouvelles cartes ADSL et le passage à un Cisco 2901. | ||
− | Cette solution à base de 2621 est fonctionnelle mais toujours avec le défaut que les <tt> | + | Cette solution à base de 2621 est fonctionnelle mais toujours avec le défaut que les <tt>WIC-1ADSL=</tt> ne sont pas suffisantes pour obtenir un débit satisfaisant avec les limitations ou défauts suivant : |
<br style="clear: both;"/> | <br style="clear: both;"/> | ||
Ligne 120 : | Ligne 121 : | ||
= Troisième approche Cisco C2900 = | = Troisième approche Cisco C2900 = | ||
− | [[File:2901.jpg|thumbs| | + | [[File:2901.jpg|thumbs|500px|left|2901 en baie]] |
+ | |||
+ | A l'origine l'idée était d'installer les cartes <tt>WIC-1ADSL=</tt> dans 2 des 4 slots WIC d'un Cisco 2901. Mais les slots WIC du 2901 sont des EHWIC (Enhanced High-Speed WAN Interface Cards). Et étrangement les cartes WIC classiques (du moins les <tt>WIC-1ADSL=</tt>) ne fonctionnent pas dans ces slots ou ne sont pas prises en compte par l'IOS. | ||
+ | |||
+ | Un mal pour un bien, il faut utiliser des cartes ADSL plus récentes comme les <tt>HWIC-1ADSL-M</tt>. Ces cartes peuvent être achetées d'occassion autour de 14 euros. C'est plus cher que les <tt>WIC-1ADSL=</tt> mais cela reste tout à fait acceptable. De plus ces cartes sont compatible ADSL version 2 voire même version 2+ ce qui va nettement améliorer le débit des connexions. | ||
+ | |||
+ | Du coté de l'IOS pas de changement par rapport aux 1721 et 2621, nous sommes toujours sur un IOS classique version 12.4 (pour être précis l'image utilisée est <tt>c2900-universalk9-mz.SPA.154-1.T1.bin</tt>). Par contre la complexité de la configuration augmente du au fait que le routeur est déjà utilisé à d'autres fins. Il n'est donc pas possible de modifier la table de routage principale. Il va donc falloir utiliser le dispositif PBR (Policy-Based Routing) de Cisco. Hélas ce dispositif est bien moins abouti que la politique de routage de Linux qui permet d'utiliser de vraies tables de routages annexes et pas seulement de modifier un peu la table principale. Nous allons aussi utiliser le dispositif SLA (Service Level Agreements) dont le principe est de de suivre l'état de services Internet et qui va au delà du simple suivi d'interfaces (tracking) dont nous nous sommes servis jusque là. | ||
+ | |||
+ | <br style="clear: both;"/> | ||
+ | |||
+ | == Configuration ADSL == | ||
+ | |||
+ | La configuration ADSL est strictement semblable à celle déjà utilisée avec les routeurs précédents. | ||
+ | |||
+ | interface ATM0/0/0 | ||
+ | no ip address | ||
+ | no atm ilmi-keepalive | ||
+ | dsl enable-training-log | ||
+ | pvc 8/35 | ||
+ | pppoe-client dial-pool-number 1 | ||
+ | ! | ||
+ | ! | ||
+ | |||
+ | interface Dialer1 | ||
+ | mtu 1492 | ||
+ | ip address negotiated | ||
+ | ip nat outside | ||
+ | ip virtual-reassembly in | ||
+ | encapsulation ppp | ||
+ | dialer pool 1 | ||
+ | dialer idle-timeout 0 | ||
+ | dialer persistent | ||
+ | ppp chap hostname IDENTIFIANT | ||
+ | ppp chap password 0 MOTDEPASSE | ||
+ | ! | ||
+ | |||
+ | Une tentative de récupérer une adresse IPv6 au niveau des interfaces <tt>Dialer</tt> n'a pas réussi. Il faut dire que je ne suis pas convaincu que le fournisseur en propose une. | ||
+ | |||
+ | == Configuration SLA == | ||
+ | |||
+ | La configuration de vérification de l'état des connexions : | ||
+ | |||
+ | ip sla 20 | ||
+ | icmp-echo IPV4_ISP_ADSL1 | ||
+ | ip sla schedule 20 life forever start-time now | ||
+ | ip sla 21 | ||
+ | icmp-echo IPV4_ISP_ADSL2 | ||
+ | ip sla schedule 21 life forever start-time now | ||
+ | track 20 ip sla 20 reachability | ||
+ | track 21 ip sla 21 reachability | ||
+ | |||
+ | Dans notre configuration le dispositif SLA est clairement sous-exploité. | ||
+ | |||
+ | == Configuration PBR == | ||
+ | |||
+ | Sur l'interface du réseau local il est fait référence à la <tt>route-map</tt> qui implante notre politique de routage (PBR) : | ||
+ | |||
+ | interface INTERFACE | ||
+ | ... | ||
+ | ip nat inside | ||
+ | ip virtual-reassembly in max-reassemblies 128 | ||
+ | ip tcp adjust-mss 1452 | ||
+ | ip policy route-map to_adsl | ||
+ | ! | ||
+ | |||
+ | La <tt>route-map</tt> en question : | ||
+ | |||
+ | route-map to_adsl permit 10 | ||
+ | match ip address 20 | ||
+ | set ip next-hop verify-availability IPV4_ISP_ADSL1 1 track 20 | ||
+ | set ip next-hop verify-availability IPV4_ISP_ADSL1 2 track 21 | ||
+ | ! | ||
+ | |||
+ | Et vous constatez le problème : l'obligation d'un numéro de séquence pour le <tt>next-hop</tt> (juste après l'adresse IPv4 du saut). Du coup les deux routeurs ne sont pas au même niveau (il est interdit d'utiliser deux numéros identique) et donc pas d'équilibrage de charge juste un lien de secours. | ||
+ | |||
+ | == La mascarade == | ||
+ | |||
+ | Aucun changement dans la définition de la mascarade : | ||
+ | |||
+ | access-list 20 permit 192.168.0.0 0.0.0.255 | ||
+ | route-map ADSL2 permit 10 | ||
+ | match ip address 20 | ||
+ | match interface Dialer2 | ||
+ | ! | ||
+ | route-map ADSL1 permit 10 | ||
+ | match ip address 20 | ||
+ | match interface Dialer1 | ||
+ | ! | ||
+ | ip nat inside source route-map ADSL1 interface Dialer1 overload | ||
+ | ip nat inside source route-map ADSL2 interface Dialer2 overload | ||
+ | |||
+ | == Diagnostics == | ||
+ | |||
+ | Cette sous-section présente quelques commandes permettant un rapide diagnostic des liaisons ADSL. | ||
+ | |||
+ | Tout d'abord il faut vérifier si le circuit ATM de la connexion ADSL a pu être établi. Ici ce n'est pas le cas : | ||
+ | #show interface ATM0/0/0 | include VCs | ||
+ | 23 maximum active VCs, 256 VCs per VP, 0 current VCCs | ||
+ | alors que là tout va bien : | ||
+ | #show interface ATM0/0/0 | include VCs | ||
+ | 23 maximum active VCs, 256 VCs per VP, 1 current VCCs | ||
+ | Si vous avez un problème à ce niveau c'est que la connexion physique vers votre ISP est hors-service. Voyez avec eux. | ||
+ | |||
+ | Il est ensuite possible d'apprécier la qualité de la ligne : | ||
+ | #show dsl interface atm 0/0/0 | include Attenuation: | ||
+ | Attenuation: 38.5 dB 22.0 dB | ||
+ | L'atténuation est de 40db sur l'autre ligne. Ces valeurs sont cohérentes avec celles mesurées par les techniciens de l'opérateur. Ils expliquent aussi les débits obtenus dans la sous-section suivante. | ||
+ | |||
+ | Vous pouvez regarder si l'identification PPPoE se passe bien : | ||
+ | #show pppoe session | ||
+ | Uniq ID PPPoE RemMAC Port VT VA State | ||
+ | SID LocMAC VA-st Type | ||
+ | N/A 18215 xxxx.yyyy.zzzz ATM0/0/0 Di1 Vi1 UP | ||
+ | xxxx.yyyy.zzzz VC: 8/35 UP | ||
+ | N/A 2968 xxxx.yyyy.zzzz ATM0/1/0 Di2 Vi2 UP | ||
+ | xxxx.yyyy.zzzz VC: 8/35 UP | ||
+ | Ici un miracle : les deux lignes sont actives. | ||
+ | |||
+ | Pour aller plus loin le suivi des accès est-il correct ? | ||
+ | #sh ip sla summary | ||
+ | IPSLAs Latest Operation Summary | ||
+ | Codes: * active, ^ inactive, ~ pending | ||
+ | ID Type Destination Stats Return Last | ||
+ | (ms) Code Run | ||
+ | ----------------------------------------------------------------------- | ||
+ | *20 icmp-echo IPV4_ISP_ADSL1 TT=16 OK 0 seconds ago | ||
+ | *21 icmp-echo IPV4_ISP_ADSL2 TT=20 OK 55 seconds ago | ||
+ | Là encore tout se passe bien les deux lignes ADSL sont opérationnelles, du moins les adresses IPv4 des ISP répondent bien au ping. | ||
+ | |||
+ | Enfin vous pouvez vérifier si la mascarade est opérationnelle : | ||
+ | #sh ip nat statistics | ||
+ | Total active translations: 420 (1 static, 419 dynamic; 411 extended) | ||
+ | Peak translations: 11285, occurred 4w5d ago | ||
+ | ... | ||
+ | Dynamic mappings: | ||
+ | -- Inside Source | ||
+ | [Id: 2] route-map ADSL1 interface Dialer1 refcount 1 | ||
+ | [Id: 3] route-map ADSL2 interface Dialer2 refcount 0 | ||
+ | Le <tt>refcount 1</tt> indique que la première ligne ADSL est utilisée même si elle n'est pas surchargée. Par contre le <tt>refcount 0</tt> montre le défaut d'équilibrage de charge. | ||
+ | |||
+ | == Conclusion == | ||
+ | |||
+ | Les cartes ADSL2+ permettent d'obtenir de meilleurs débits. Avec quelques rapides mesures en utilisant <tt>ssh</tt> et <tt>dd</tt> les résultats suivants sont obtenus : | ||
+ | * ADSL "pro" : 1,1Mo/s descendant et 100Ko/s montant | ||
+ | * ADSL B.I.O. : 1,3Mo/s descendant et 130Ko/s montant | ||
− | + | A noter que les débits "certifiés" pour la liaison B.I.O. ne sont absolument pas tenus. La société orange dirait probablement que les routeurs Cisco ne sont pas assez performants. | |
− | + | Le point négatif est tout de même l'impossibilité, à notre connaissance, d'arriver à effectuer de l'équilibrage de charge avec le dispositif PBR. | |
− | |||
− | |||
+ | = Améliorations = | ||
− | + | Plusieurs améliorations de notre configuration sont possibles : | |
+ | * Mettre en place un routeur dédié : l'utilisation de PBR avec la limitation rencontrée sur l'équilibrage de charge peut être contourner en dédiant un routeur aux seules lignes ADSL. Dans ce cas PBR n'est plus nécessaire et le routage peut se faire comme pour le 2621 avec deux routes par défaut dans la table de routage principale. | ||
+ | * Passer sur une routeur plus récent : nous avons acheté un routeur Cisco 9300 avec un IOS plus récent permettant SLA, PBR et mascarade (cette dernière étant impossible sur un C9200), la limitation sur l'équlibrage de charge PBR de l'IOS 12.4 est peut-être levée ? Au pire le C9300 va remplacer le 2901 qui sera dédié aux lignes ADSL. | ||
+ | * Passer à une technologie de connexion plus récente : un travail de fourmies a été mené par la plateforme maths/info pour recenser les lignes de communication utilisées par Polytech'Lille, une bonne partie étant obsolètes il a été possible de négocier une mutation des lignes ADSL, Numéris, dédiées et SDSL pour se concentrer sur un accès fibre 200Mb/s symétrique. |
Version actuelle datée du 3 octobre 2022 à 09:40
Sommaire
Introduction
Le réseau RENATER n'est pas adapté à l'enseignement : trop de restrictions par les différents administrateurs réseau. Il est par exemple très compliqué de faire installer des serveurs (DNS, SMTP, Web, etc) aux élèves.
La plateforme mathématiques et informatique s'est donc dotée de lignes spécifiques à l'enseignement. Ces lignes commencent à dater et utilisent la technologie cuivre / ADSL. La migration vers la fibre est en cours.
En attendant, il faut maintenir les lignes ADSL. Les opérateurs, bien que continuant à présenter des factures, ne sont plus en mesure de remplacer les modems / routeurs initialement fournis. Le sujet de ce projet consiste à basculer sur du matériel réseau de la plateforme pour gérer les liaisons ADSL. Le coût doit rester minimal vu qu'il s'agit d'une solution temporaire.
Les deux lignes ADSL sont des lignes France Télécom conservées lors de la privatisation de l'institution sous le nom commercial "orange". La première ligne a même été négociée avec Oléane au début des années 2000 pour permettre aux élèves logés dans la résidence crous Eiffel d'avoir un accès Internet. Une dizaine d'année plus tard la direction de l'école a accédé aux sollicitations du crous pour confier l'accès Internet à un opérateur privé. Nostalgie à part la dénomination officielle des deux lignes est :
- ADSL business internet office (vendue pour un débit 18Mb/s descendant et 80Kb/s montant) ;
- ADSL internet pro solo (accès classique comme pour les particuliers).
Les deux modems / routeurs de ces lignes ont cessé de fonctionner (en 2018 pour la première ligne et en 2020 pour la seconde ligne).
Première approche Cisco C1700
Un premier test a été effectué avec un routeur Cisco 1721. Avec une mémoire flash de 32Mo et une mémoire vive de 64Mo, il est possible de le faire tourner sous un IOS 12.4.
Le 1721 peut prendre deux cartes WIC classiques, dont en particulier la carte WIC-1ADSL=. Ces cartes peuvent se trouver d'occasion autour de 4 euros.
La configuration de l'interface ATM de la carte ADSL est simple :
interface ATM0 no ip address no atm ilmi-keepalive dsl operating-mode auto pvc 8/35 pppoe-client dial-pool-number 1 ! !
A noter que les caractéristiques (ici 8/35) du circuit vers le fournisseur d'accès dépendent totalement du dit fournisseur. Les identifiants pour l'accès au fournisseur sont déclarés dans une interface virtuelle Dialer qui se charge du protocole PPPoE (Point-to-Point Protocol over Ethernet). Le numéro du dial pool doit être le même dans la référence de l'interface ATM et dans la configuration de l'interface Dialer (ici le numéro est 1).
interface Dialer1 mtu 1492 ip address negotiated ip virtual-reassembly encapsulation ppp dialer pool 1 dialer idle-timeout 0 dialer persistent ppp chap hostname IDENTIFIANT ppp chap password 0 MOTDEPASSE !
Bien entendu il faut remplacer les mot IDENTIFIANT et MOTDEPASSE avec l'identification fournie par votre fournisseur d'accès. A noter que la récupération de ces identifiants n'est pas toujours évidente. Pour l'ADSL Pro d'orange une demande a été suivie par un courriel contenant l'identifiant le lendemain mais pour l'accès ADSL BIO il a été nécessaire de fournir un document d'autorisation de divulgation par un responsable de l'établissement.
La configuration mtu 1492 n'est pas optionnelle sans elle le passage par l'interface ATM casse la découverte du MTU maximal d'une façon ou d'une autre. Pour les liaisons peu stables, comme les notres, la directive dialer persistent est très utile pour relancer l'identification sur la connexion.
Enfin une liaison ADSL sans mascarade n'est pas très utile vu que l'opérateur ne donne qu'une adresse IPv4 routée. Pour mettre en place la mascarade il faut ajouter la directive ip nat outside dans l'interface de sortie vers Internet (ici Dialer1) et il faut ajouter ip nat inside dans l'interface du réseau local (généralement une interface Ethernet). Enfin il faut définir la mascarade par elle-même :
access-list 1 permit 192.168.0.0 0.0.0.255 ip nat inside source list 1 interface Dialer1 overload
Il ne reste plus qu'à ajouter la route par défaut : ip route 0.0.0.0 0.0.0.0 Dialer1.
Dans cette configuration il est supposé que le réseau IPv4 local est 192.168.0.0/24.
La solution à base de 1721 est fonctionnelle mais avec les limitations ou défauts suivant :
- la carte WICADSL1= n'implante que ADSL version 1, dans le cas de notre liaison avec 40db d'atténuation on se retrouve avec des débit de quelques Mb/s même sur la ligne certifiée à 18Mb/s ;
- il n'est pas possible de configurer deux WIC ADSL dans un 1721, ce bogue est répertorié sous le numéro CSCsa90021 ;
- le 2721 est un routeur de bureau non facilement intégrable dans une baie (non fixable sur les rails, alimentation massive séparée), d'autant plus s'il en faut deux, un par liaison ADSL.
Seconde approche Cisco C2600
Il est possible de récupérer les cartes ADSL WIC-1ADSL de ces routeurs pour les installer sur un Cisco 2621 un peu plus puissant. De plus ce routeur n'est pas affecté par le bogue CSCsa90021, les 2 cartes ADSL peuvent être configurées simultanément. Le 2621 dont nous disposions possédait lui aussi une mémoire flash de 32Mo et une mémoire vive de 64Mo. Du coup le 2621 peut tourner sous un IOS sensiblement identique à celui du 1721 soit un IOS 12.4.
Pas de modification notable dans la configuration des interfaces ATM, hors numérotation des interfaces et nouvelles options ATM par défaut :
interface ATM0/0 no ip address atm restart timer 300 ! nouvelle option par défaut no atm ilmi-keepalive dsl operating-mode auto dsl enable-training-log ! nouvelle option par défaut pvc 8/35 pppoe-client dial-pool-number 1 ! !
La configuration de l'interface ATM0/1 est identique mis à part le numéro du dial-pool-number. Les interfaces virtuelles Dialer se configurent de façon strictement semblable sur le 2921 par rapport au 1721.
Par contre cette fois nous avons deux interfaces de sortie par les deux lignes ADSL. Le routage et la mascarade deviennent plus compliqué à configurer.
track 1 ip route IPV4_ISP_ADSL1 255.255.255.255 reachability track 2 ip route IPV4_ISP_ADSL2 255.255.255.255 reachability ip route 0.0.0.0 0.0.0.0 Dialer1 track 1 ip route 0.0.0.0 0.0.0.0 Dialer2 track 2
Ce bloc ajoute les routes par défaut via les lignes disponibles à un moment donné. La disponibilité se fait par test ICMP sur les adresses IPv4 coté fournisseur d'adresse. Si deux routes par défaut sont ajoutées, l'algorithme de routage doit équilibrer le trafic sur les différentes lignes ADSL. Dans notre cas le trafic se fait principalement via un mandataire Web. L'algorithme Cisco classique original peut suffire. Cet algorithme route toutes les communications d'une adresse IPv4 donnée vers une autre adresse IPv4 donnée vers la même sortie. Si les sites web visités sont peu variés il vaut mieux passer sur l'algorithme universal qui ajoute les ports sources et destination dans les éléments de choix de la route de sortie. Cela peut se faire avec la commande
(config)# ip cef load-sharing algorithm universal
Pour la mascarade la configuration est de la forme :
access-list 1 permit 192.168.0.0 0.0.0.255 route-map ADSL1 permit 10 match ip address 1 match interface Dialer1 ! route-map ADSL2 permit 10 match ip address 1 match interface Dialer2 ! ip nat inside source route-map ADSL1 interface Dialer1 overload ip nat inside source route-map ADSL2 interface Dialer2 overload
Vous constatez que l'astuce consiste à passer par des route-map pour que la mascarade puisse se faire en bonne intelligence avec l'équilibrage de charge. Ne pas oublier d'ajouter les ip nat inside sur l'interface du réseau local et les ip nat outside dans les deux interfaces Dialer.
A noter : l'équilibrage n'a pas été testé avec cette configuration, les deux lignes ADSL n'ayant pas pu être opérationnelles simultanément avant l'acquisition de nouvelles cartes ADSL et le passage à un Cisco 2901.
Cette solution à base de 2621 est fonctionnelle mais toujours avec le défaut que les WIC-1ADSL= ne sont pas suffisantes pour obtenir un débit satisfaisant avec les limitations ou défauts suivant :
Troisième approche Cisco C2900
A l'origine l'idée était d'installer les cartes WIC-1ADSL= dans 2 des 4 slots WIC d'un Cisco 2901. Mais les slots WIC du 2901 sont des EHWIC (Enhanced High-Speed WAN Interface Cards). Et étrangement les cartes WIC classiques (du moins les WIC-1ADSL=) ne fonctionnent pas dans ces slots ou ne sont pas prises en compte par l'IOS.
Un mal pour un bien, il faut utiliser des cartes ADSL plus récentes comme les HWIC-1ADSL-M. Ces cartes peuvent être achetées d'occassion autour de 14 euros. C'est plus cher que les WIC-1ADSL= mais cela reste tout à fait acceptable. De plus ces cartes sont compatible ADSL version 2 voire même version 2+ ce qui va nettement améliorer le débit des connexions.
Du coté de l'IOS pas de changement par rapport aux 1721 et 2621, nous sommes toujours sur un IOS classique version 12.4 (pour être précis l'image utilisée est c2900-universalk9-mz.SPA.154-1.T1.bin). Par contre la complexité de la configuration augmente du au fait que le routeur est déjà utilisé à d'autres fins. Il n'est donc pas possible de modifier la table de routage principale. Il va donc falloir utiliser le dispositif PBR (Policy-Based Routing) de Cisco. Hélas ce dispositif est bien moins abouti que la politique de routage de Linux qui permet d'utiliser de vraies tables de routages annexes et pas seulement de modifier un peu la table principale. Nous allons aussi utiliser le dispositif SLA (Service Level Agreements) dont le principe est de de suivre l'état de services Internet et qui va au delà du simple suivi d'interfaces (tracking) dont nous nous sommes servis jusque là.
Configuration ADSL
La configuration ADSL est strictement semblable à celle déjà utilisée avec les routeurs précédents.
interface ATM0/0/0 no ip address no atm ilmi-keepalive dsl enable-training-log pvc 8/35 pppoe-client dial-pool-number 1 ! !
interface Dialer1 mtu 1492 ip address negotiated ip nat outside ip virtual-reassembly in encapsulation ppp dialer pool 1 dialer idle-timeout 0 dialer persistent ppp chap hostname IDENTIFIANT ppp chap password 0 MOTDEPASSE !
Une tentative de récupérer une adresse IPv6 au niveau des interfaces Dialer n'a pas réussi. Il faut dire que je ne suis pas convaincu que le fournisseur en propose une.
Configuration SLA
La configuration de vérification de l'état des connexions :
ip sla 20 icmp-echo IPV4_ISP_ADSL1 ip sla schedule 20 life forever start-time now ip sla 21 icmp-echo IPV4_ISP_ADSL2 ip sla schedule 21 life forever start-time now track 20 ip sla 20 reachability track 21 ip sla 21 reachability
Dans notre configuration le dispositif SLA est clairement sous-exploité.
Configuration PBR
Sur l'interface du réseau local il est fait référence à la route-map qui implante notre politique de routage (PBR) :
interface INTERFACE ... ip nat inside ip virtual-reassembly in max-reassemblies 128 ip tcp adjust-mss 1452 ip policy route-map to_adsl !
La route-map en question :
route-map to_adsl permit 10 match ip address 20 set ip next-hop verify-availability IPV4_ISP_ADSL1 1 track 20 set ip next-hop verify-availability IPV4_ISP_ADSL1 2 track 21 !
Et vous constatez le problème : l'obligation d'un numéro de séquence pour le next-hop (juste après l'adresse IPv4 du saut). Du coup les deux routeurs ne sont pas au même niveau (il est interdit d'utiliser deux numéros identique) et donc pas d'équilibrage de charge juste un lien de secours.
La mascarade
Aucun changement dans la définition de la mascarade :
access-list 20 permit 192.168.0.0 0.0.0.255 route-map ADSL2 permit 10 match ip address 20 match interface Dialer2 ! route-map ADSL1 permit 10 match ip address 20 match interface Dialer1 ! ip nat inside source route-map ADSL1 interface Dialer1 overload ip nat inside source route-map ADSL2 interface Dialer2 overload
Diagnostics
Cette sous-section présente quelques commandes permettant un rapide diagnostic des liaisons ADSL.
Tout d'abord il faut vérifier si le circuit ATM de la connexion ADSL a pu être établi. Ici ce n'est pas le cas :
#show interface ATM0/0/0 | include VCs 23 maximum active VCs, 256 VCs per VP, 0 current VCCs
alors que là tout va bien :
#show interface ATM0/0/0 | include VCs 23 maximum active VCs, 256 VCs per VP, 1 current VCCs
Si vous avez un problème à ce niveau c'est que la connexion physique vers votre ISP est hors-service. Voyez avec eux.
Il est ensuite possible d'apprécier la qualité de la ligne :
#show dsl interface atm 0/0/0 | include Attenuation: Attenuation: 38.5 dB 22.0 dB
L'atténuation est de 40db sur l'autre ligne. Ces valeurs sont cohérentes avec celles mesurées par les techniciens de l'opérateur. Ils expliquent aussi les débits obtenus dans la sous-section suivante.
Vous pouvez regarder si l'identification PPPoE se passe bien :
#show pppoe session Uniq ID PPPoE RemMAC Port VT VA State SID LocMAC VA-st Type N/A 18215 xxxx.yyyy.zzzz ATM0/0/0 Di1 Vi1 UP xxxx.yyyy.zzzz VC: 8/35 UP N/A 2968 xxxx.yyyy.zzzz ATM0/1/0 Di2 Vi2 UP xxxx.yyyy.zzzz VC: 8/35 UP
Ici un miracle : les deux lignes sont actives.
Pour aller plus loin le suivi des accès est-il correct ?
#sh ip sla summary IPSLAs Latest Operation Summary Codes: * active, ^ inactive, ~ pending ID Type Destination Stats Return Last (ms) Code Run ----------------------------------------------------------------------- *20 icmp-echo IPV4_ISP_ADSL1 TT=16 OK 0 seconds ago *21 icmp-echo IPV4_ISP_ADSL2 TT=20 OK 55 seconds ago
Là encore tout se passe bien les deux lignes ADSL sont opérationnelles, du moins les adresses IPv4 des ISP répondent bien au ping.
Enfin vous pouvez vérifier si la mascarade est opérationnelle :
#sh ip nat statistics Total active translations: 420 (1 static, 419 dynamic; 411 extended) Peak translations: 11285, occurred 4w5d ago ... Dynamic mappings: -- Inside Source [Id: 2] route-map ADSL1 interface Dialer1 refcount 1 [Id: 3] route-map ADSL2 interface Dialer2 refcount 0
Le refcount 1 indique que la première ligne ADSL est utilisée même si elle n'est pas surchargée. Par contre le refcount 0 montre le défaut d'équilibrage de charge.
Conclusion
Les cartes ADSL2+ permettent d'obtenir de meilleurs débits. Avec quelques rapides mesures en utilisant ssh et dd les résultats suivants sont obtenus :
- ADSL "pro" : 1,1Mo/s descendant et 100Ko/s montant
- ADSL B.I.O. : 1,3Mo/s descendant et 130Ko/s montant
A noter que les débits "certifiés" pour la liaison B.I.O. ne sont absolument pas tenus. La société orange dirait probablement que les routeurs Cisco ne sont pas assez performants.
Le point négatif est tout de même l'impossibilité, à notre connaissance, d'arriver à effectuer de l'équilibrage de charge avec le dispositif PBR.
Améliorations
Plusieurs améliorations de notre configuration sont possibles :
- Mettre en place un routeur dédié : l'utilisation de PBR avec la limitation rencontrée sur l'équilibrage de charge peut être contourner en dédiant un routeur aux seules lignes ADSL. Dans ce cas PBR n'est plus nécessaire et le routage peut se faire comme pour le 2621 avec deux routes par défaut dans la table de routage principale.
- Passer sur une routeur plus récent : nous avons acheté un routeur Cisco 9300 avec un IOS plus récent permettant SLA, PBR et mascarade (cette dernière étant impossible sur un C9200), la limitation sur l'équlibrage de charge PBR de l'IOS 12.4 est peut-être levée ? Au pire le C9300 va remplacer le 2901 qui sera dédié aux lignes ADSL.
- Passer à une technologie de connexion plus récente : un travail de fourmies a été mené par la plateforme maths/info pour recenser les lignes de communication utilisées par Polytech'Lille, une bonne partie étant obsolètes il a été possible de négocier une mutation des lignes ADSL, Numéris, dédiées et SDSL pour se concentrer sur un accès fibre 200Mb/s symétrique.