documentation:collecte_fai_local [Fédération FDN]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
===== Modes de fonctionnement d'un FAI local collecté par FDN =====

Parmi les options permettant à un FAI local de fournir des accès à ses adhérents, il existe la possibilité de mutualiser les infrastructures dont dispose FDN, pour terminer des accès ADSL.

Trois modes sont envisageables :
  * collecte en "marque blanche" : les lignes sont facturées au FAI associatif à un tarif //revendeur//, dégageant un espace économique lui permettant d'assurer son fonctionnement. Les accès utilisent des logins « FDN » et utilisent le pool d'adresse IP et la connectivité de FDN.
  * routage vers la connectivité du FAI local : les frais refacturés correspondent uniquement aux couts de collecte, le trafic, pour sortir vers Internet est envoyé vers un routeur du FAI local, qui dispose de ses propres IPs et de se propre connectivité.
  * terminaison sur un LNS du FAI local : les connexions sont transférées telles que reçues, dans un tunnel L2TP entre FDN et le FAI associatif. Il termine alors les accès comme il le souhaite, sur ses propres adresses, et sa propre connectivité. // cette option n'est pas immédiatement réalisable, techniquement parlant //

==== Collecte marque blanche ====

C'est la façon la plus simple et la plus immédiate. FDN //revend// en gros (ie plusieurs lignes facturées à une seule association) des accès, qui sont techniquement similaires aux lignes en propre de FDN.

{{:documentation:schema_adsl_simple.png|}}

Sur ce schéma, le réseau de collecte (première boite bleue) est simplifié. Pour un peu plus de détail voir [[schema_fai]] et [[schema_collecte_routage_fdn]].

On y voit que l'authentification, utilisant le protocole [[http://fr.wikipedia.org/wiki/RADIUS_%28informatique%29|Radius]], est proxysé, au départ de l'opérateur de collecte, puis Nerim, puis enfin FDN, qui va vérifier que le nom d'utilisateur et le mot de passe sont corrects, et déterminer quelle adresse IP est distribuée à l'utilisateur. On peut aussi trouver, dans la réponse, des informations concernant un bloc d'IPs, v4 ou v6, à router sur cet accès.

La demande Radius nous arrive finalement du LNS,  dans un paquet ''Access-Request'' comme celui-ci :

  Packet-Type = Access-Request
  Mon May 16 12:21:27 2011
        User-Name = "dominique.rousseau@fdn.nerim"
        User-Password = "XXXX"
        NAS-Port = 142
        Service-Type = Framed-User
        Framed-Protocol = PPP
        Called-Station-Id = "8888"
        NAS-IP-Address = 62.4.16.41
        Client-IP-Address = 80.67.161.141
        Huntgroup-Name = "fdn"

Les seuls attributs qui nous intéressent vraiment sont ''User-Name'' et ''User-Password'', le reste, on en fait rien (mais on pourrait :).

Le serveur Radius répond avec un paquet ''Access-Accept'' (ou ''Reject'' si les identifiants ne sont pas bons) :

  Packet-Type = Access-Accept
  Mon May 16 12:21:27 2011
        Framed-IP-Address = 80.67.176.2
        Framed-IP-Netmask = 255.255.255.255
        Service-Type := Framed-User
        Framed-Protocol := PPP
        Framed-Routing := None
        Idle-Timeout := 86400

On peut avoir de façon optionelle des attributs ''Framed-Route'' (pour attribuer une route ipv4 : ''subnet/mask'') ou ''Framed-IPv6-Route'' (pour une route ipv6, même format)

Dans la section ''L2TP'' (du réseau opérateur jusqu'à FDN), on trouve plusieurs connexions PPP, provenant de plusieurs connectés (''[1]'', ''[2]'', etc.).

Le bloc ''Internet'' correspond à Gitoyen + sa conenctivité.

==== Routage vers FAI local ====

Dans le cas d'un FAI qui dispose de sa propre connectivité vers Internet, et de ses propres blocs d'IPs, le schéma donne ça :

{{:documentation:schema_adsl_source-route.png|}}

Cette fois ci, on trouve les connectés de FDN (toujours en jaune), et les connectés de ''FaiA'', en rouge.

Ils empruntent le même réseau de collecte opérateur, ainsi que chez Nerim.


La différence se fait une fois arrivé chez FDN. On trouve ici un lien (un simple cable reliant le switch de FDN et celui de FaiA, un Lan2Lan vers "loin", etc.) qui relie FDN et FaiA.

Et celà à deux niveaux :
  * l'authentification va être proxysée une fois de plus, du serveur Radius d'FDN vers celui de FaiA. Le transfert se fera sur la base d'un sous //realm// (royaume).
  * le trafic sortant est envoyé vers le routeur de FaiA. Le trafic entrant arrive naturellement vers son réseau, et il transmet aux routeurs d'FDN.

Pour les requetes Radius, elles auront une forme sur laquelle les 2 se sont mis d'accord, par exemple :

  User-Name = "gerard.dugenou/faia@fdn.nerim"

Dans ce cas, le serveur Radius d'FDN sera configuré de telle façon qu'il saura qu'il doit transmettre la requete Radius vers un autre serveur.

Le Radius de FaiA répondra, lui, avec un paquet contenant, par exemple :

  Framed-IP-Address = 91.224.148.5

Si on reprend le schéma en se concentrant sur l'interconnexion de FDN et FaiA, ça donne :

{{:documentation:interco_avec_faia.png|}}

On va supposer que FaiA va distribuer des adresses IPs faisant partie de ''91.224.148.0/26''.

Côté FDN, on va faire du routage en fonction de l'adresse IP source (les paquets ont pour origine une adresse IP dans ''91.224.148..0/26'', et pour destination « n-importe-où-sur-internet ». Sous Linux, avec ''iproute2'', ça donnerait quelque chose qui reseemble à ça :

  ip rule add from 91.224.148.0/26 table faia
  ip route add default table faia via 80.67.161.242

Ces règles ont pour effet de :
  * créer une nouvelle table de routage nommée ''faia''. On définit qu'on doit utiliser cette table, plutot que la table par défaut, lorsque l'ip source est dans ''91.224.148.0/26''.
  * on définit que la route par défaut, dans cette table est de passer par ''80.67.161.242''

Une fois transmis à ''80.67.161.242'' (routeur de FaiA), c'est à lui de se débrouiller, et d'utiliser ses propres règles de routage pour atteindre la destination.

Dans l'autre sens, FaiA est le point d'entrée annoncé à tout l'internet pour gérer ''91.224.148.0/24'' (ie un sur-réseau de ''91.224.148.0/26''). Il va donc devoir acheminer les paquets à destination de ''91.224.148.0/26'' vers le routeur d'FDN. Une seule règle de routage suffit pour faire celà :

  ip route add 91.224.148.0/26 via 80.67.161.241


==== Transfert en L2TP ====

// pas réalisable pour l'instant //

{{:documentation:schema_adsl_l2tp-forward.png|}}