Nerim et son routage interne

Ce document décrit la manière dont le routage est opéré à l’intérieur du réseau Nerim, entre ses différentes parties. Les processus de routage décrits ici ne concernent donc que les adresses IP Nerim, aux adresses des interconnexions externes (/30 d’interconnexion ou LANs peerings) près.

Quelques définitions

Les notions de « préfixe » et de « protocole de routage » ont été définies sur le document concernant le routage externe. Ce sont les mêmes dans le cadre du routage interne.

IGPs (Interior Gateway Protocols – Protocoles de Passerelles Intérieures) : Ces protocoles sont destinés au routage à l’intérieur d’un même AS. La « philosophie » de l’IGP repose sur l’échange de routes entre routeurs d’un même réseau (AS), et sur la collaboration avec le BGP pour la gestion des interconnexions externes, quand il y en a.
Il existe plusieurs types d’IGP, le plus connu étant sans doute RIP (Routing Information Protocol), un protocole simple fonctionnant en UDP, et en broadcast. Il y en a d’autres nettement plus évolués comme OSPF (Open shortest path first) ou IS-IS (Intermediate system to intermediate system).
Routes statiques/routes connectées : Les IGPs (Interior Gateway Protocol) font la différence entre deux types de routes principalement (je passe sur les autres types qui peuvent dépendre des équipements). Une route « statique » est entrée manuellement sur l’équipement au moyen de la commande « ip route » sur Cisco, par exemple. Une route « connectée » est une route qui est automatiquement générée dans la table de routage de l’équipement lorsque celui-ci est relié à un réseau. C’est donc une route directement atteignable par un lien connecté sur cet équipement. A noter que certains OS anciens (notamment Linux 2.0) ne font pas de différence entre les routes statiques et les routes connectées, toute connexion directe nécessitant l’ajout d’une route statique pour fonctionner.
Route par défaut : Route vers le préfixe 0.0.0.0/0, c’est à dire n’importe quelle adresse IP. Cette route, dont on ne parle pas en routage externe, mérite qu’on s’y arrête quelques temps en ce qui concerne le routage interne. Pour éviter des boucles de routage, la plupart des IGPs désactivent les annonces de la route par défaut entre les routeurs. Pour annoncer la route par défaut, il faut souvent le forcer dans l’IGP au moyen d’une commande spécifique.
Nullroute : Route statique vers l’interface Null0 sur un routeur Cisco. Lorsque le routeur disposant d’une telle route reçoit un paquet lui correspondant, cela provoque sa destruction. Une nullroute est annoncée normalement sur le réseau, et n’est pas considérée comme telle tant qu’on n’a pas atteint le routeur disposant de la route statique. Les nullroutes servent à détruire les paquets vers certaines destinations en dernier recours, lorsqu’aucune route n’a pu être trouvée.

Historique du routage chez Nerim

Entre septembre 1999 et avril 2001, le routage a été géré de manière statique chez Nerim. RIP a été légèrement utilisé chez Nerim entre 1999 et 2000, mais jamais seul. Il y a eu pendant toute cette période une collaboration avec des routes statiques. Finalement, RIP a disparu du réseau à la fin 2000, peu avant l’arrivée du lien FSA.

Le réseau de Nerim en 2000 comportait deux routeurs « Internet » (Cisco 3620 et Lucent Pipeline 130), ainsi que quatre passerelles internes (cynthia, balaba, myrtille, rythana) sous FreeBSD. L’ensemble était configuré avec un ensemble commun de routes statiques, mis à jour à chaque fois qu’un nouveau « morceau » était rajouté dans le réseau.

Bien que ce ne soit pas indispensable au fonctionnement de réseau (comme ça l’est maintenant), de l’OSPF a été mis en place en avril 2001. Le choix s’est porté sur ce protocole car il converge très rapidement, permet des manipulations intéressantes sur les routes (filtrages, gestion de métriques différentes suivant l’équipement et le type de routes) mais aussi parce
qu’il est bien implémenté à la fois sur Zebra et sur Cisco (dans des versions qui communiquent très bien, ce qui est remarquable !). OSPF dispose de son propre protocole IP (ce n’est ni de l’UDP, ni du TCP, c’est de « l’OSPF/IP ») et fonctionne en multicast. Les routeurs OSPF s’incrivent dans le groupe multicast qui correspond pour recevoir les annonces.

Depuis avril 2001, il n’y a pas eu de changements majeurs dans le fonctionnement du routage interne.

Stratégie d’implémentation du routage interne chez Nerim

L’OSPF fonctionne par le principe des aires. Sans rentrer dans les détails et en simplifiant (ce n’est pas tout à fait exact, mais fait comme cela chez Nerim) une aire est un ensemble de routeurs directement visibles (dans le même VLAN par exemple). En OSPF, une l’aire numéro 0 est appelée « aire backbone ». Chez Nerim, l’aire 0 correspond à ce qui s’appelle « LAN
Backbone », elle contient tous les routeurs internes et externes vers les destinations principales du réseau :

Serveurs,
Réseau d’administration,
Abonnés ADSL Île-de-France,
Abonnés ADSL Province,
Abonnés ADSL/SDSL LDCOM,
…

Le LAN Backbone est 62.4.16.0/27. Tous les routeurs situés dans ce réseau ont l’ensemble de la table de routage interne du réseau. Chaque routeur connectant un morceau du réseau est chargé des annonces correspondantes, c’est à dire qu’il n’y a pas de « route servers » gérant l’ensemble des annonces.

Il existe quelques autres aires OSPF dans le réseau, un second niveau de routage dynamique étant parfois nécessaire soit pour simplement annoncer les routes, soit pour prendre des décisions de routage.

Aire 0 : LAN Backbone (62.4.16.0/27 – entre les passerelles internes),
Aire 1 : LAN Core (62.4.32.0/29 – entre les routeurs Internet),
Aire 7 : LAN FSA (62.4.16.208/28 – entre les LNS FSA),
Aire 34 : SFINX (62.4.16.48/30 – pour le routeur du SFINX).

Les aires 7 et 34 ne vont pas tarder à disparaître, respectivement avec la disparition du lien FSA, et avec la production de la liaison Fast Ethernet vers le SFINX (l’architecture SFINX utilisera alors directement le LAN Core, comme c’est fait pour le FreeIX).

Chez Nerim, il a été choisi de NE PAS ANNONCER la route par défaut. En effet cela pose de gros problèmes à certains équipements, et les empêche parfois d’échanger les routes. Pour sécuriser la sortie Internet, des routes par défaut statiques vers des adresses IP HSRP sont utilisées (voir les Annexes).

Le routage interne a été conçu de la manière suivante : toute route interne doit être directement spécifiée par le routeur interne qui lui correspond, si elle est valide dans le réseau. Les routeurs Internet ne doivent être empruntés que pour sortir vers Internet.

Que se passe-t-il si une route (vers une adresse IP interne) n’existe pas ? Le routeur interne qui a reçu le paquet va la considérer comme une route externe, adresse IP de Nerim ou non (ils ne font pas la différence). Le routeur Internet, lui, fait la différence entre les adresses IP Nerim et non-Nerim. S’il reçoit un paquet à destination d’une adresse IP Nerim, mais qu’il ne dispose pas de route interne pour acheminer le paquet, il le détruit, grâce aux nullroutes qu’il possède (une par bloc IP Nerim).

Cela provoque les fameux ‘traceroute’ qui s’échouent sur les routeurs Internet lorsque la route interne n’est pas valide (typiquement, non implémentée ou abonné ADSL non connecté).

11:38 mallaury ~% traceroute 62.212.124.5
traceroute to 62.212.124.5 (62.212.124.5), 30 hops max, 40 byte packets
1 maina (62.4.17.1) 0.264 ms 0.183 ms 0.156 ms
2 pchan1-thevenin.nerim.net (62.4.16.7) 1.121 ms 1.498 ms 1.259 ms
3 * * *
4 * * *
[…]

Les routes dans le réseau ne sont en effet annoncées que si elles servent. C’est donc le cas en permanence pour les différents VLANs de Nerim, tant que la passerelle qui gère le VLAN en question est disponible. Pour les abonnés ADSL connectés en PPP, leurs routes ne sont annoncées que lorsqu’ils sont connectés, par le LNS où ils sont connectés. C’est ce principe qui permet de gérer les adresses IP fixes chez Nerim tout en disposant d’un partage des connexions entre plusieurs LNS.

Lorsque l’abonné se déconnecte et passe sur un autre LNS, l’annonce de sa route est réémise. Grâce à la convergence rapide d’OSPF, cette modification du routage interne n’est pas visible par l’abonné.

Cela permet aussi, accessoirement, de contenir les floods. Lorsqu’un abonné connecté se fait déconnecter suite à un flood, son annonce disparaît du réseau interne, et ne dépasse plus les routeurs Internet. Le LNS cesse donc de recevoir les paquets « pourris ».

Métriques dans le réseau interne – Puits du réseau

L’OSPF permet de faire un choix entre des annonces du même préfixe, mais avec des métriques différentes. Contrairement à BGP, OSPF n’est pas obligé de faire un choix. Ainsi si les métriques sont équivalentes, les équipements vont envoyer un paquet sur deux sur chacune des routes.

Cela permet de faire du partage de charge, je le cite pour information (ce n’est pas du tout utilisé chez Nerim). En OSPF, le métrique le plus faible est préféré.

Généralement, les routes statiques sont toujours annoncées avec un métrique plus élevé que celles des routes connectées, puisque ces dernières ne peuvent pas être atteintes plus facilement que par le routeur qui les annonce.

Dans le réseau de Nerim il y a beaucoup plus de routes connectées que de routes statiques. Les routes statiques sont essentiellement :

Les routes vers les blocs IP des abonnés,
Les routes vers les sous-réseaux des hébergés, quand ils en ont,
Les nullroutes.

Les routes connectées sont annoncées avec le métrique 100, et les routes statiques avec le métrique 120 sur la plupart des passerelles.

Il existe quelques exceptions, notamment les LNS n’annoncent pas leurs routes en 100/120, ceci afin d’éviter toute annonce erronée qui pourrait résulter d’une mauvaise négociation de l’adresse IP. Les LNS du lien FSA, co-administrés par Transpac, annoncent leurs routes avec un métrique encore légèrement plus élevé que ceux des LNS CIPA, ceci afin de se prévenir contre les erreurs de configuration, et aussi de pouvoir gérer la redondance des comptes d’accès, sans autoriser la double connexion.

Enfin les routeurs Internet annoncent les nullroutes avec le métrique le plus élevé du réseau, afin que ces annonces ne soient prises en compte lorsque aucune autre annonce n’a pu être trouvée.

Type d’équipement Route connectée Route statique
-----------------------------------------------------------------
LNS du lien CIPA (net1) 115 125
LNS du lien CIPA (net2) 110 120
LNS du lien FSA 120 140
nas211-dsl-courbevoie 130 150
cecilia 170 190
100 120
holger 230 250
svenny 210 230
thevenin 200 220
edou 220 240¨C115Cbeno 310 ¨C116Cjulo 300

La séparation Netissimo 1/Netissimo 2 sur le CIPA que j’avais introduit n’a jamais été exploitée. Sur le lien FSA, cela n’avait d’ailleurs pas été fait. Les équipements en test ou supportant des services en test utilisent des métriques plus élevés. Enfin les routeurs Internet disposent des métriques les plus élevés, puisque ceux-ci servent essentiellement à redistribuer les nullroutes.

Le routeur thevenin a le métrique le plus faible parmi les routeurs backbone, c’est donc lui, par défaut, qui va recevoir les paquets qui n’ont pas pu être routés en interne, et qui va les détruire : c’est ce qu’on appelle le puits du réseau (on dit aussi « trou noir »). Parmi eux, les routeurs de peering on un rôle un peu plus spécial. Ils redistribuent leurs routes connectées seulement, cela inclut donc les routes correspondant aux LANs des points d’échange.

Cela est effectué à des fins de routage BGP. En effet, le BGP a besoin de savoir, au moyen de l’IGP, comment atteindre le voisin BGP correspondant à la route d’un peer, car en iBGP ce paramètre n’est pas réécrit avec l’adresse du routeur de sortie, comme c’est le cas en eBGP.

Le routeur du FreeIX annonce sa route avec un métrique plus faible parce que le lien vers le point de peering est plus gros. Il est probable que cela change, et que le point de peering le moins chargé soit préféré.

Consultation des routes internes via le looking-glass

Comme vous le savez maintenant, les routeurs Internet « core » disposent à la fois des routes BGP d’Internet, et des routes OSPF internes de Nerim. Vous pouvez donc utiliser le looking-glass afin de consulter les routes internes (choisir la commande « show ip route »).

Exemple :

svenny#show ip route 80.65.225.67
Routing entry for 80.65.225.67/32
Known via "ospf 13193", distance 110, metric 115, type extern 2, forward
metric 1
Last update from 62.4.16.27 on FastEthernet0/0, 00:00:00 ago
Routing Descriptor Blocks:
* 62.4.16.27, from 62.4.16.27, 00:00:00 ago, via FastEthernet0/0
Route metric is 115, traffic share count is 1

Il s’agit là d’une adresse IP PPP (/32) d’un abonné connecté sur
lns104-tip-telehouse (62.4.16.27).

Annexes

Utilisation du protocole HSRP chez Nerim

HSRP (Hot Standby Routing Protocol) est un protocole propriétaire Cisco fonctionnant en broadcast UDP.

Le but de HSRP est de fournir une adresse IP virtuelle partagée entre deux (ou plus) routeurs afin que si l’un devienne indisponible, l’autre puisse répondre à sa place. Dès lors on peut utiliser ces adresses IP virtuelles comme passerelle par défaut, par exemple. C’est l’utilisation qui en est faite chez Nerim.

Il y a quatre adresses IP HSRP en fonction chez Nerim. Généralement le routeur principal est celui du site, et le routeur secondaire celui du site le plus proche, exception faite pour Téléhouse qui dispose de deux routeurs Internet.

Adresse IP Routeur primaire Routeur secondaire ("standby")
------------------------------------------------------------------------
hsrp0-aboukir holger thevenin
hsrp0-telehouse thevenin svenny
hsrp1-telehouse svenny thevenin
hsrp0-courbevoie edou svenny

Toutes les routes par défaut des passerelles internes sont positionnées sur l’adresse IP HSRP du site. Pour Téléhouse, c’est alternativement hsrp0-telehouse et hsrp1-telehouse, avec un peu plus de passerelles sur hsrp0-telehouse, car thevenin est plus puissant que svenny (et dispose aussi du plus gros lien de transit).

Répartition interne des adresses IP Nerim

Voici l’affectation actuelle des différentes adresses IP de l’AS13193. Pour que ce soit plus simple à lire (et aussi à écrire), la liste ne comprend que des préfixes plus grands que /24. Les préfixes plus petits sont notés avec un intervalle (par exemple 62.212.[96-99].0/24 pour 62.212.96.0/22). Je ne rentre pas dans les détails, voir certaines notes pour un complément d’informations.

Préfixe/Groupe de préfixes Affectation
-----------------------------------------------------------------------------
62.4.16.0/24 Backbone et serveurs (i)
62.4.17.0/24 NOC (réseau d'administration)
62.4.18.0/24 ADSL Netissimo 1 (ii)
62.4.19.0/24 ADSL Netissimo 2 (ii) et blocs IP (iii)
62.4.20.0/24 ADSL Netissimo 1
62.4.21.0/24 Mixte (iv) entre ADSL et hébergement
62.4.22.0/24 ADSL Netissimo 1
62.4.23.0/24 ADSL Netissimo 2 et blocs IP
62.212.[96-110].0/24 ADSL Netissimo 1
62.212.[111-112].0/24 ADSL Netissimo 2
¨C175C62.212.[113-117].0/24 ADSL Netissimo 1
¨C176C62.212.[118-119].0/24 ADSL dynamique (v) lien FSA
¨C177C62.212.[120-127].0/24 ADSL et SDSL via LDCOM
¨C178C80.65.[224-226].0/24 ADSL Netissimo 1
¨C179C80.65.227.0/24 ADSL Netissimo 2
¨C180C80.65.228.0/24 Deine (fait partie de l'AS21163)
¨C181C80.65.229.0/24 Blocs IP Netissimo 1
¨C182C80.65.230.0/24 Blocs IP Netissimo 2
¨C183C80.65.231.0/24 Phoenix Telecom
¨C184C80.65.232.0/24 Serveur-Express
¨C185C80.65.233.0/24 
¨C186C80.65.234.0/27 Metaboli
¨C187C80.65.234.[32,64,96]/27 
¨C188C80.65.234.128/25 
¨C189C80.65.235.0/24 
¨C190C80.65.236.0/24 Blocs IP Netissimo 1
¨C191C80.65.237.0/24 Blocs IP Netissimo 2
¨C192C80.65.238.0/24 Akamai
¨C193C80.65.238.32/24 LAN Services (Atlas 4, Atlas 5)
¨C194C80.65.238.64/26 Troisième LAN d'hébergement
¨C195C80.65.238.128/25 LAN Infiniland (offre "Nerim Hosting")
¨C196C80.65.239.0/24 LAN ADM (welcome to pouffZ' land)
¨C197C213.41.[128-131].0/24 ADSL Netissimo 2
¨C198C213.41.[132-133].0/24 ADSL Netissimo 1
¨C199C213.41.[134-183].0/24 Réservé pour de l'ADSL
¨C200C213.41.[184-191].0/24 ADSL dynamique via lien CIPA

(i) Ceci comprend les LAN Backbone et Core, les adresses d’interconnexion avec les clients en capacité ou transit (des /30), le LAN des Serveurs (derrière la passerelle miren aujourd’hui, à Téléhouse – sachant que certains serveurs sont dans le LAN NOC), les adresses IP des routeurs de collecte ainsi que leurs interfaces loopback, et quelques clients historiques (1999/2000) qui sont toujours clients et à qui on laisse donc ces blocs en 62.4.16.0 (ils ne sont pas réattribués quand les clients résilient).
(ii) Cette dénomination concerne les /32 utilisés pour le PPP, et renvoyées au client lors de l’authentification.
(iii) Il s’agit des blocs d’adresses IP (/30 à /27) qui sont attribués aux clients ADSL (renvoyés au LNS par le RADIUS lors de la connexion) lorsqu’ils ont un sous-réseau routé vers leur accès.
(iv) Historiquement, la classe « fourre-tout ». Comprend notamment le Second LAN d’Hébergement (62.4.21.224/27), les anciens /29 pour la première expérimentation de dégroupage avec LDCOM en 2000, convertis en blocs IP sur Netissimo 1 et quelques adresses ADSL PPP pour des clients (historiques, toujours).
(v) Pools dynamiques uniquement attribués à des utilisateurs Netissimo 1. Les classes d’adresses dépendent du LNS où le client se connecte. Le nom du LNS est présent dans le nom associé à l’adresse IP.
(vi) Non routé pour l’instant, mais sera forcément utilisé pour des adresses PPP. Suivant les besoins de Nerim, ce seront des /24 utilisés pour des adresses Netissimo 0 (?), 1 ou 2, ainsi que pour de l’adressage dynamique (Netissimo 0 ou 1). Pas pour autre chose que de l’ADSL FT, donc.

Anciennes tables de routes statiques

Pour les amateurs d’histoire, voici la table de routage statique du Cisco 3620 de Nerim vers Isdnet, telle qu’elle était le 20 février 2001.

ip route 0.0.0.0 0.0.0.0 Hssi0/0.1
ip route 62.4.16.0 255.255.248.0 Null0
ip route 62.4.16.64 255.255.255.192 62.4.16.20
ip route 62.4.16.128 255.255.255.240 62.4.16.11
ip route 62.4.16.144 255.255.255.252 62.4.16.15
ip route 62.4.16.148 255.255.255.252 62.4.16.15
ip route 62.4.16.152 255.255.255.248 62.4.16.15
ip route 62.4.16.160 255.255.255.252 62.4.16.13
ip route 62.4.16.168 255.255.255.248 62.4.16.11
ip route 62.4.16.176 255.255.255.248 62.4.16.11
ip route 62.4.16.184 255.255.255.248 62.4.16.15
ip route 62.4.16.192 255.255.255.224 62.4.16.15¨C231Cip route 62.4.16.224 255.255.255.252 62.4.16.15¨C232Cip route 62.4.16.228 255.255.255.252 62.4.16.14¨C233Cip route 62.4.16.232 255.255.255.248 62.4.16.11¨C234Cip route 62.4.16.240 255.255.255.252 62.4.16.8¨C235Cip route 62.4.16.244 255.255.255.252 62.4.16.8¨C236Cip route 62.4.17.0 255.255.255.0 62.4.16.28¨C237Cip route 62.4.18.0 255.255.254.0 62.4.16.8¨C238Cip route 62.4.20.0 255.255.255.0 62.4.16.8¨C239Cip route 62.4.21.0 255.255.255.128 62.4.16.14¨C240Cip route 62.4.21.224 255.255.255.224 62.4.16.11¨C241Cip route 62.4.22.0 255.255.254.0 62.4.16.8

Voici son pendant sur la passerelle myrtille, datant d’un peu plus tard (quelques jours avant l’implémentation d’OSPF).

route_servers="-net 62.4.16.64 -netmask 255.255.255.192 62.4.16.20"
route_nerim_fp2200="-net 62.4.16.144 -netmask 255.255.255.252 62.4.16.15"
route_codeine_fp2200="-net 62.4.16.148 -netmask 255.255.255.252 62.4.16.15"
route_codeine_blk16_1="-net 62.4.16.152 -netmask 255.255.255.248 62.4.16.15"
route_point94="-net 62.4.16.160 -netmask 255.255.255.252 62.4.16.13"
route_pderuel="-net 62.4.16.168 -netmask 255.255.255.248 62.4.16.131"
route_tigersushi_dmz="-net 62.4.16.176 -netmask 255.255.255.248 62.4.16.130"
route_codeine_blk16_2="-net 62.4.16.184 -netmask 255.255.255.248 62.4.16.15"
route_codeine_blk16_3="-net 62.4.16.192 -netmask 255.255.255.224 62.4.16.15"
route_codeine_interco="-net 62.4.16.224 -netmask 255.255.255.252 62.4.16.15"
route_codeine_interco_2="-net 62.4.16.228 -netmask 255.255.255.252 62.4.16.14"
route_infolibre="-net 62.4.16.232 -netmask 255.255.255.248 62.4.16.135"¨C257Croute_rtip_rg="-net 62.4.16.240 -netmask 255.255.255.252 62.4.16.8"¨C258Croute_fsa_gw="-net 62.4.16.244 -netmask 255.255.255.252 62.4.16.8"¨C259Croute_noc="-net 62.4.17.0 -netmask 255.255.255.0 62.4.16.28"¨C260Croute_adsl_18_19="-net 62.4.18.0 -netmask 255.255.254.0 62.4.16.8"¨C261Croute_adsl_20="-net 62.4.20.0 -netmask 255.255.255.0 62.4.16.8"¨C262Croute_degroupage="-net 62.4.21.0 -netmask 255.255.255.128 62.4.16.14"¨C263Croute_adsl_21="-net 62.4.21.128 -netmask 255.255.255.192 62.4.16.8"¨C264Croute_adsl_22_23="-net 62.4.22.0 -netmask 255.255.254.0 62.4.16.8"