Reprise du message précédent :

Beaucoup plus compliqué que ça

 
Twingo diesel avec un pneu crevé j’irai pas plus loin  

 
Je suis un homme simple ; tu me donnes une R34, je vais où tu veux    

 
CARAMBA ! ENCORE RATE !  

Si on fait dans le vintage  
 

Je réalise que les serveurs de notre cluster big data sont sur 25.0.0.0/8 ... on est pas les seuls apparemment: https://blog.wireshark.org/2010/04/ [...] or-insane/
 
Quel est l'intérêt de ce genre de blague?

C'est comme le bloc public filé à des ISP pour du routing interne, un truc normalisé il y'a peu ?

 
Chercher les emmerdes  

 
Avoir des IP uniques, sans collision avec rien (les gens qui font ce genre de truc ont l'air d'imaginer qu'ils sont les seuls à avoir eu l'idée).

Surtout qu'à la louche un /23 suffirait et on est loin d'être à court d'adresses dans 10.0.0.0/8.

C'est un vieil article de 2010, depuis lors il y a le 100.64.0.0/10 de la RFC6598 qui a été alloué pour ces usages de type carrier-grade NAT  
https://datatracker.ietf.org/doc/html/rfc6598
J'imagine qu'à l'époque ça évitait tout conflit d'adressage avec la RFC1918 utilisée sur les réseaux privés. C'est comme Microsoft qui se sert d'adressage APIPA 169.254 sur les peerings BGP expressroute, c'est un trick astucieux mais un peu détourné de l'usage prévu par les RFC

Ah voilà c'est ça dont je parlais

Tu fais comment si le 10.x.y.z/23 du réseau mobile est également utilisé pour adresser tes serveurs dans ton entreprise ? Dès que le téléphone est sur ton réseau d'entreprise, il y a compétition entre le linerate des interfaces wifi et 4G pour savoir quelle route sera prioritaire dans l'OS, entre l'accès à ton LAN et l'accès au réseau mobile ?  
Devoir réadresser tes serveurs à cause de ton opérateur mobile est assez discutable comme raison

Non mais je comprends plus ou moins la motivation dans le cas de T-Mo en 2010, mais pas dans mon cas.
 
C'est un cluster de serveurs dont les IPs sont de toute manière pas routées depuis les autres sous-réseaux, et ni dans l'autre sens, ou presque.
Alors oui ça risque pas de causer des problèmes non plus, mais je vois pas l'intérêt.

équipes différentes qui gèrent l'adressage IP général et l'adressage IP de ce système, et qui ne peuvent/veulent pas collaborer.
Avec éventuellement en bonus un pattern trouvé sur le net et repris tel quel sans trop y réfléchir.

Ouais, ou un intégrateur qui déploie tout de la même façon son système complet et pour pas avoir de soucis a décidé que ses clusters seraient dans ce subnet utilisé par personne.

Ou peut être un playbook Ansible pour déployer le cluster qui a ces valeurs par défaut et personne les a updatées  

J'ai rien capté à cette page, au revoir messieurs, je ne pense pas être un informaticien, j'suis juste aigri en fait  

Faut faire partie des gens du réseau  
T'as un GPS dans ton alimentation ?

c'est déjà 50% des problèmes en moins

 
J'ai vu des mecs chez nous implémenter Openstack. Le truc est tellement mal branlé que si tu faisais pas partie de l'équipe de base, tu te fais le même genre de réflexion

Pareil, pas tout capté mais je viens de voir que Free me file une IP en 10.63.X.Y en 4G et à la cogip où j'interviens c'est en 10.0.0.0 /8
Y a des tests marrants à faire lundi  ?

IPv6 ?

 
si ils t'attribuent un /32 ça a peu de chance de poser problème

Comment ça se passe le routage dans ce cas-là ?  

j'imagine que le terminal 4G monte un VPN avec la cogip de toute façon, donc il n'y a vraiment que si la cogip a une ressource interne pile à la même IP que le terminal que ça va poser problème.
S'il n'y a pas de VPN entre le terminal et le SI de la cogip, l'IT a sûrement pris en compte (voire décidé) le range d'IP utilisé par free pour les terminaux, donc pas de problème non plus.