alors, plusieurs choses.

Tout d'abord en ppp (archi historique), il y a eu dans le passé des lns en région. Par contre, l'affectation initiale n'a jamais été optimale car il n'y avait pas de lns dans chaque région. Donc un client breton pouvait se retrouver sur un lns à caen. En adsl ça ne rajoutait pas beaucoup à la latence par rapport à celle de la boucle locale, en ftth c'était plus casse-pied car ça rajoutait un aller-retour par paris, genre : client à coté de Saint Malo -> dslam dans son patelin -> brasseur atm ou routeur ethernet à St Malo -> routeur backbone à rennes -> routeur backbone à paris -> routeur backbone à caen -> lns -> re-routeur backbone à caen -> routeur à paris -> ... et idem dans l'autre sens.

Et ça, c'était obligatoire si le client avait déménagé en gardant son ip fixe, il pouvait se retrouver avec un lns vraiment à l'autre bout du réseau. Donc suite à ces problèmes dont pas mal d'abonnés se plaignaient, les lns ont été concentrés en idf pour limiter les aller-retour en région. Donc oui, ça impose un passage en idf, mais ça limite la casse. Et déployer un lns par région n'est pas économiquement viable non plus.

Maintenant avec la collecte en dhcp, c'est un peu différent. La fonctionnalité LNS en tant que telle n'existe plus, car c'était une terminaison L2TP (tunnel L2 over ethernet pour prolonger le ppp du LAC =bas au LNS) et il n'y a plus de l2tp désormais. Le routage des IP fixes est asymétrique, on peut le constater sur des traceroutes :

• dans le sens sortant (abonné -> internet ou autre abonné) le routage est "naturel", le traffic sort directement du routeur de collecte sur lequel le dslam ou olt est raccordé, pour joindre directement la destination
• dans le sens internet -> abonné, c'est là qu'il y a la magie qui opère pour "aggréger" les ip fixes par bloc. Des routeurs en idf vont annoncer en bgp ces blocs d'ip, et donc le routage va passer par là pour entrer dans un tunnel mpls vers le routeur de collecte de destination. L'impact est minimal, mais il y a un passage dans ce sens par l'idf.

Ces infras (le lns ou l'aggrégateur d'ip fixes) sont nécessaires pour garantir la pérennité d'une ip pour un client donné, peu importe les déménagement du client ou réaménagement du réseau. On pourrait essayer de faire sans, mais ça imposerait des choses pas très propres au niveau réseau (genre annonces /32), ou bien investir massivement pour en avoir partout, pour une rentabilité limité (et là les 15€/mois d'ip fixe ça va pas être suffisant .

En espérant que ça clarifie un peu les choses.

Pas tout à fait.

En ppp, la connexion est terminée sur le BAS, ou "BRAS". L'ip est attribuée par un radius en fonction des pools d'ip déclarés sur l'équipement (et annoncés dans le réseau, typiquement en bgp). Historiquement les BAS étaient tous en région, et on était routé de manière déterministe vers un BAS en particulier. Aujourd'hui c'est toujours comme ça en xdsl ppp, mais les clients ftth toujours en ppp sont concentrés sur des bas dédiés.

Le routage est ainsi symétrique et passe obligatoirement par le bas dans les deux sens vu qu'il est le point de terminaison du tunnel ppp.

En dhcp le routeur de collecte sur lequel sont raccordés dslams & olt est relais dhcp. Le client envoie son discover en broadcast, il est relayé en unicast vers un serveur dhcp national, l'offer redescend vers le routeur puis est relayée vers le client, request et ack. Le serveur dhcp sait à partir de l'ip du relais dhcp quels sont les pools à sa disposition, et va ainsi attribuer une ip au client qui sera annoncée sous la forme d'un réseau agrégé (genre un /20, pas N /32) dans le réseau.

Ici encore le routage est symétrique et le routeur de collecte est le point d'entrée et de sortie du trafic du client. On peut le voir sur les traceroutes, c'est le premier hop après la livebox (généralement sans rdns), ou le dernier en fonction du sens.

Sens sortant client -> internet :

Code: [Sélectionner]

$ mtr -rwc1 1.1
HOST: a                                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
1.|-- _gateway                                            0.0%     1    0.7   0.7   0.7   0.7   0.0
2.|-- 80.10.237.121                                       0.0%     1   10.0  10.0  10.0  10.0   0.0   <<< routeur de collecte
3.|-- ae112-0.ncren101.rbci.orange.net                    0.0%     1    8.8   8.8   8.8   8.8   0.0   <<< routeur backbone de plaque
4.|-- ae43-0.niidf301.rbci.orange.net                     0.0%     1   13.1  13.1  13.1  13.1   0.0   <<< routeur internet
5.|-- 81.253.184.6                                        0.0%     1   14.4  14.4  14.4  14.4   0.0   <<< point d'entrée dans le réseau OTI. Pas de rdns => regarder l'autre IP du subnet : 81.253.184.5 = ae0-0.niidf301.rbci.orange.net
6.|-- bundle-ether305.partr2.saint-denis.opentransit.net  0.0%     1   14.0  14.0  14.0  14.0   0.0   <<< routeur oti qui porte le raccordement cloudflare
7.|-- cloudflare-19.gw.opentransit.net                    0.0%     1   13.4  13.4  13.4  13.4   0.0   <<< routeur cloudflare sur un subnet d'interco appartenant à oti, d'où le rdns opentransit)
8.|-- one.one.one.one                                     0.0%     1   15.6  15.6  15.6  15.6   0.0
Sens descendant internet (depuis le raei, réseau business orange)-> livebox (la livebox ne répond pas au ping et n'apparait donc pas sur le traceroute) :

Code: [Sélectionner]

$ mtr -rwc1 83.205.212.55
HOST: link                                                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ???                                                       100.0     1    0.0   0.0   0.0   0.0   0.0
  2.|-- lag-43.arc2-ig3.archives.transitip.raei.francetelecom.net  0.0%     1   15.4  15.4  15.4  15.4   0.0   <<< routeur de sortie du réseau raei
  3.|-- intf-fogi-arc2-ig3.nmidf306.rbci.orange.net                0.0%     1   15.1  15.1  15.1  15.1   0.0   <<< routeur rbci sur lequel est raccordé le routeur raei
  4.|-- ae25-0.ncidf304.rbci.orange.net                            0.0%     1   15.2  15.2  15.2  15.2   0.0   <<< routeur de plaque
  5.|-- ae43-0.nridf302.rbci.orange.net                            0.0%     1   15.6  15.6  15.6  15.6   0.0   <<< routeur backbone inter-régional
  6.|-- ae40-0.nridf301.rbci.orange.net                            0.0%     1   15.5  15.5  15.5  15.5   0.0   <<< idem
  7.|-- ae41-0.ncren101.rbci.orange.net                            0.0%     1   28.9  28.9  28.9  28.9   0.0   <<< redescente sur le routeur de plaque
  8.|-- lag-112.nbren704.rbci.orange.net                           0.0%     1   19.4  19.4  19.4  19.4   0.0   <<< routeur de collecte
  9.|-- ???                                                       100.0     1    0.0   0.0   0.0   0.0   0.0
on retrouve dans les deux cas le nbren704 ainsi que le ncren101, le reste du parcours est différent. Depuis un abonné sur la même plaque régionale le routage serait encore plus court avec possiblement que le nbren704 entre les livebox.

Depuis un abonné sur la même plaque régionale le routage serait encore plus court avec possiblement que le nbren704 entre les livebox.

J'ai un hop de plus au niveau du point d'entrée dans le réseau OTI:

Code: [Sélectionner]

$ mtr -rwc1 1.1
HOST:                                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- _gateway                                            0.0%     1    0.6   0.6   0.6   0.6   0.0
  2.|-- 80.10.253.17                                        0.0%     1    1.9   1.9   1.9   1.9   0.0
  3.|-- ae97-0.ncren102.rbci.orange.net                     0.0%     1    1.8   1.8   1.8   1.8   0.0
  4.|-- ae43-0.niidf302.rbci.orange.net                     0.0%     1    6.5   6.5   6.5   6.5   0.0
  5.|-- 193.252.137.78                                      0.0%     1    6.5   6.5   6.5   6.5   0.0
  6.|-- 193.251.242.93                                      0.0%     1   10.3  10.3  10.3  10.3   0.0
  7.|-- bundle-ether310.partr2.saint-denis.opentransit.net  0.0%     1    7.6   7.6   7.6   7.6   0.0
  8.|-- cloudflare-19.gw.opentransit.net                    0.0%     1   17.1  17.1  17.1  17.1   0.0
  9.|-- one.one.one.one                                     0.0%     1    8.2   8.2   8.2   8.2   0.0

Ok et petite question, ça veut dire quoi ae dans les rdns du RBCI : ae43-0.niidf301.rbci.orange.net ?

• bundle-ether == un LAG sur un Cisco sous IOS-XR
• ae == un LAG sur un Juniper