Auteur Sujet: Signification des reverse-DNS chez Orange (Lu 42196 fois)

levieuxatorange · « **Réponse #24 le:** 25 août 2025 à 11:01:56 »

Citation de: vivien le 25 août 2025 à 10:59:02

Les BAS vont mourir avec la fin du cuivre, non ?

Non, les BAS fonctionnent aussi en FTTH pour les client qui font du PPPoE en fibre (y'en a) principalement sur ONT externe.

Mais cela va devenir de plus en plus marginal avec le temps.

LeVieux

simon · « **Réponse #25 le:** 25 août 2025 à 11:04:14 »

Citation de: vivien le 25 août 2025 à 10:59:02

Les BAS vont mourir avec la fin du cuivre, non ?

À mon sens ils vont les garder pour les irréductibles pros utilisant toujours leur accès PPPoE, quitte à les virtualiser et/ou les concentrer sur un ou deux DC au niveau du pays. Le trafic doit être minime de nos jours.

Je suppose que si Orange facilitait la migration sans nécessiter des options DHCP et tags CoS souvent non implémentés par les routeurs SOHO, le retrait du PPPoE serait probablement plus simple pour eux.

levieuxatorange · « **Réponse #26 le:** 25 août 2025 à 13:03:32 »

Citation de: simon le 25 août 2025 à 11:04:14

Je suppose que si Orange facilitait la migration sans nécessiter des options DHCP et tags CoS souvent non implémentés par les routeurs SOHO, le retrait du PPPoE serait probablement plus simple pour eux.

Oui et non :
Oui : cela simplifierait l'usage de routeur sur étagère.
Non : plusieurs soucis, :
- l'un étant entre autre que on gère des clients et pas des identification de ligne
- dans le PPPoE, le lien PPP maintien toutes les session et il est trivial de priorisé les paquets PPP Link. En DHCP, il faut trouver des choses pour palier à la disparition de cette couche. Sinon le client peut avoir un routeur qui lui dit "tout marche" alors que en fait, non ....

Et enfin, on a des clients "conservateurs" .... Un des cas qui me vient en tête et un client en NITISSIMO 2 en 2017 qui refusait de changer même si on envoyait un tech avec garantie de continuité de service ... en 2017 payer 45€ pour un 512 Kb ...

LeVieux

hwti · « **Réponse #27 le:** 26 août 2025 à 01:18:26 »

Citation de: levieuxatorange le 25 août 2025 à 10:48:11

- le reverse à la maille de l'opérateur est suffisant.

Les informations peuvent aider pour le debug, surtout que toutes les IP dans les traceroute n'ont pas de reverse.

Par exemple :
- A Chambly (60) : lfbn-idf1-1-781-xxx.w86-245.abo.wanadoo.fr (et sauts via ae94-0.ncidf103.rbci.orange.net / lag-41.niidf103.rbci.orange.net) : je suis sur IDF1 (Puteaux ?), comme une autre ligne à Colombes
- A Belle-Isle-en-Terre (22), lfbn-ren-1-xxx-2.w86-253.abo.wanadoo.fr (pas de reverse sur les sauts) : le POP est donc à Rennes (à 150km !) mais comme il est en direction de Paris, ça reste correct pour la latence

Au passage, comment nPerf sélectionne-t-il automatiquement le meilleur Orange le plus près (respectivement Paris et Rennes) ? Avec le reverse, ou avec une base de données de géolocalisation ?

simon · « **Réponse #28 le:** 26 août 2025 à 08:00:10 »

Citation de: levieuxatorange le 25 août 2025 à 13:03:32

- dans le PPPoE, le lien PPP maintien toutes les session et il est trivial de priorisé les paquets PPP Link. En DHCP, il faut trouver des choses pour palier à la disparition de cette couche. Sinon le client peut avoir un routeur qui lui dit "tout marche" alors que en fait, non ....

Ce n'est pas déjà le cas ? J'ai un script sur mon routeur qui ping fe80::ba0:bab et qui relance les clients DHCP si pas de réponse pendant ~10 minutes.
Il ne sert pas souvent (peut-être 1 fois tous les 4-6 mois) mais sans ce script, mon routeur penserait que "tout marche" alors qu'effectivement, ce n'est pas le cas.

Alors oui, prioriser DHCP/ND/ARP au niveau Ethernet est une bonne idée pour la qualité de service de la majorité des clients, mais pourquoi l'avoir imposé sur le réseau d'accès? Il doit y avoir une raison qui m'échappe

Si on est sur le sujet des reverse et du debug, pourrait-on avoir des reverse pour les noeuds du réseau en v6? Par exemple:

Code: [Sélectionner]

$ mtr www.orange.fr
Start: 2025-08-26T07:57:58+0200
HOST: xxxxxxx                                                                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- xxxxxxxx (2a01:cb08:xxxx:xxxx::1)                                                        0.0%    10    1.0   1.0   0.9   1.2   0.1
  2.|-- 2a01cb08a00402150193025300760242.ipv6.abo.wanadoo.fr (2a01:cb08:a004:215:193:253:76:242)  0.0%    10    2.0   1.9   1.3   2.6   0.4
  3.|-- 2a01:cfc0:200:8000:193:252:102:43                                                         0.0%    10    9.6   9.4   8.9  10.1   0.4
  4.|-- 2a01:cfc4:0:1d00::3                                                                       0.0%    10   21.5  10.4   8.6  21.5   3.9
  5.|-- 2a01:c9c0:cf:2999::167                                                                    0.0%    10    9.3   8.9   8.4   9.6   0.4
  6.|-- 2a01:c9c0:c3:229::19

Aucun des routeurs traversés ne semble avoir de reverse, ou alors, un reverse générique.

levieuxatorange · « **Réponse #29 le:** 26 août 2025 à 08:57:20 »

Citation de: simon le 26 août 2025 à 08:00:10

Alors oui, prioriser DHCP/ND/ARP au niveau Ethernet est une bonne idée pour la qualité de service de la majorité des clients, mais pourquoi l'avoir imposé sur le réseau d'accès? Il doit y avoir une raison qui m'échappe

Raison toute simple : le faire en Cos0 et en Cos6 fait *2 en conf sur les OLT (de certaines marques) pour la partie configuration des CLID/REMOTEID dans les trames DHCP.
Et le nombre de contexte de conf est limité ...

Citation de: simon le 26 août 2025 à 08:00:10

Si on est sur le sujet des reverse et du debug, pourrait-on avoir des reverse pour les noeuds du réseau en v6? Par exemple:
Code: [Sélectionner]
$ mtr www.orange.fr Start: 2025-08-26T07:57:58+0200 HOST: xxxxxxx Loss% Snt Last Avg Best Wrst StDev 1.|-- xxxxxxxx (2a01:cb08:xxxx:xxxx::1) 0.0% 10 1.0 1.0 0.9 1.2 0.1 2.|-- 2a01cb08a00402150193025300760242.ipv6.abo.wanadoo.fr (2a01:cb08:a004:215:193:253:76:242) 0.0% 10 2.0 1.9 1.3 2.6 0.4 3.|-- 2a01:cfc0:200:8000:193:252:102:43 0.0% 10 9.6 9.4 8.9 10.1 0.4 4.|-- 2a01:cfc4:0:1d00::3 0.0% 10 21.5 10.4 8.6 21.5 3.9 5.|-- 2a01:c9c0:cf:2999::167 0.0% 10 9.3 8.9 8.4 9.6 0.4 6.|-- 2a01:c9c0:c3:229::19
Aucun des routeurs traversés ne semble avoir de reverse, ou alors, un reverse générique.

Bonne question, je vais aller poser la question à mes archis RBCI

LeVieux

gpe · « **Réponse #30 le:** 26 octobre 2025 à 14:26:13 »

Bonjour,

J'ai une situation bizarre sur une installation pas très loin de Dijon. Avant un reverse DNS me donnait quelque chose du genre:

lfbn-dij-1-xxxxxxxxxxxxxxxxxxxxx.abo.wanadoo.fr

ce qui correspondait bien à Dijon.
Actuellement ça me retourne:

anice-653-1-xxxxxxxxxxxxxxxxxxxxx.abo.wanadoo.fr

Donc à ce que je crois comprendre, de l'ADSL à Nice ?

Paul · « **Réponse #31 le:** 26 octobre 2025 à 15:02:26 »

C'est juste une réorganisation du plan d'adressage, ils n'ont pas mis les enregistrements PTR à jour.