Auteur Sujet: Topologie du réseau mobile (Lu 5568 fois)

zergflag · « **le:** 24 août 2024 à 20:09:33 »

Salut, j'ai remarquer que chez Orange le nombre de saut entre le téléphone et la fin de l'EPC était assez élevé (par rapport aux autres en tout cas) :

Code: [Sélectionner]

                                                                                                              Packets               Pings
 Host                                                                                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2a01:cb06:b000:1b94::e3                                                                                  0.0%    10    0.9   1.1   0.9   1.2   0.1
 2. 2a01:cd00:7ff0:3000::110                                                                                 0.0%    10   24.1  32.0  21.8  43.0   7.4
 3. 2a01:cd00:7ff0:3000::110                                                                                 0.0%    10   27.2  31.3  19.0  47.3   8.4
 4. 2a01:cd00:7ff0:2002:ffff:ffff:ffff:ff7e                                                                  0.0%    10   32.3  32.2  22.5  50.5   8.3
 5. 2a01:cfc4:1000:4e00::3                                                                                   0.0%    10   40.5  33.8  24.5  40.5   5.8
 6. 2a01:cfc4:1000:4e00::2                                                                                   0.0%    10   23.3  28.0  18.8  39.6   7.2
 7. 2a01:cfc0:200:8000:193:252:102:215                                                                       0.0%    10   27.6  31.9  20.5  48.3   8.1
 8. 2a01:cfc0:200:8000:193:252:102:219                                                                       0.0%    10   47.7  31.4  24.6  47.7   6.9
 9. 2a01:cfc4:0:200::3                                                                                      88.9%    10   28.8  28.8  28.8  28.8   0.0
10. 2001:4860:1:1::6ce                                                                                       0.0%    10   40.8  34.1  23.8  40.8   5.5
11. 2a00:1450:817c::1                                                                                        0.0%    10   23.8  29.3  17.6  40.9   6.8
12. 2001:4860:0:1::5870                                                                                      0.0%    10   28.8  31.8  24.7  40.9   4.6
13. 2001:4860:0:1::1978                                                                                      0.0%    10   32.9  31.4  18.8  42.0   7.3
14. 2001:4860::c:4002:51c7                                                                                   0.0%    10   36.9  30.1  20.8  45.0   7.6
15. 2001:4860::9:4003:6041                                                                                   0.0%    10   59.3  41.5  20.1  59.3  14.4
16. 2001:4860:0:1::7fcf                                                                                      0.0%    10   23.7  33.7  23.7  47.6   8.4
17. 2001:4860:0:1::1f97                                                                                      0.0%    10   28.1  28.3  16.9  36.8   6.0
18. 2a00:1450:4007:80d::2003                                                                                 0.0%    10   32.1  32.2  18.4  44.2   8.4

J'ai fait ce traceroute depuis mon partage de connexion donc le saut n°1 est mon téléphone, mais qu'en est il du saut 2 et 3 qui ont la même adresse ? Si on s'en suit à la norme LTE c'est censé être le P-GW/PDNG (d'ailleurs ils ont tous les deux la même adresse) ? Si c'est bien le cas, pourquoi y'a t'il au moins 3 saut après la P-GW/PDNG ? Si on fait un lookup sur les adresses IPv4 codé dans les adresses IPv6 des sauts 7 et 8 on obtient un nom type niidfxxx.rbci.orange.net donc qu'on est en IDF (pas étonnant pour ça)

zergflag · « **Réponse #1 le:** 24 août 2024 à 20:26:16 »

Je pense que le saut 2 et/ou 3 sont bien la P-GW car le NAT64 à l'air de s'effectuer à partir du saut 4 :

Code: [Sélectionner]

                                                                                                              Packets               Pings
 Host                                                                                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2a01:cb06:b000:1b94::e3                                                                                  0.0%    11    1.1   1.1   1.0   1.3   0.1
 2. 2a01:cd00:7ff0:3000::110                                                                                 0.0%    10   61.5  47.1  29.1  61.5  10.9
 3. 2a01:cd00:7ff0:3000::110                                                                                 0.0%    10   23.2  42.9  23.2  61.1  11.6
 4. 64:ff9b::a43:cafd                                                                                        0.0%    10   25.9  41.2  25.9  65.8  11.3
 5. 64:ff9b::51fd:9c0a                                                                                       0.0%    10   42.5  47.6  33.4  66.2  10.8
 6. 64:ff9b::51fd:9c09                                                                                       0.0%    10   31.3  42.1  30.3  51.3   8.4
 7. 64:ff9b::c1fc:a25e                                                                                       0.0%    10   34.0  40.2  21.4  58.6  11.8
 8. 64:ff9b::c1fc:62a1                                                                                       0.0%    10   36.7  45.1  20.2  82.2  17.6
 9. (waiting for reply)
10. 64:ff9b::480e:d3ea                                                                                       0.0%    10   56.1  52.2  34.0  90.6  15.4
11. 64:ff9b::d8ef:284b                                                                                       0.0%    10   31.9  44.4  31.9  94.4  18.3
12. 64:ff9b::d8ef:302b                                                                                       0.0%    10   25.1  39.7  25.1  72.1  15.1
13. 64:ff9b::d83a:d6ae                                                                                       0.0%    10   28.3  42.3  28.3  57.9   8.4

renaud07 · « **Réponse #2 le:** 26 août 2024 à 04:01:54 »

Salut,

Assez étonnant tes résultats en effet. J'ai fait pareil de mon côté et ce c'est pas tout a fait le même traceroute :

Code: [Sélectionner]

traceroute 64:ff9b::d83a:d6ae
traceroute to 64:ff9b::d83a:d6ae (64:ff9b::d83a:d6ae), 30 hops max, 80 byte packets
 1  2a01cb09d02964c20000004b7d01a840.ipv6.abo.wanadoo.fr (2a01:cb09:d029:64c2:0:4b:7d01:a840)  53.597 ms  53.719 ms  53.899 ms
 2  * * *
 3  2a01:cd00:19f:100::2 (2a01:cd00:19f:100::2)  54.104 ms  54.151 ms  54.212 ms
 4  2a01:cd00:19f:12::62 (2a01:cd00:19f:12::62)  54.006 ms  53.932 ms  54.259 ms
 5  64:ff9b::ad8:1241 (64:ff9b::ad8:1241)  54.319 ms  54.390 ms  54.511 ms
 6  64:ff9b::51fd:b8fe (64:ff9b::51fd:b8fe)  54.435 ms  34.453 ms  51.028 ms
 7  64:ff9b::c1fb:6e31 (64:ff9b::c1fb:6e31)  41.060 ms  43.344 ms  50.928 ms
 8  64:ff9b::c1fc:9f99 (64:ff9b::c1fc:9f99)  51.165 ms  51.281 ms  51.234 ms
 9  64:ff9b::c1fc:894e (64:ff9b::c1fc:894e)  51.309 ms  51.396 ms  51.468 ms
10  64:ff9b::d155:ad62 (64:ff9b::d155:ad62)  51.503 ms 64:ff9b::d155:aca2 (64:ff9b::d155:aca2)  52.867 ms 64:ff9b::d155:ad62 (64:ff9b::d155:ad62)  48.552 ms
11  64:ff9b::acfd:46a5 (64:ff9b::acfd:46a5)  40.100 ms * *
12  64:ff9b::8efa:e0c6 (64:ff9b::8efa:e0c6)  55.841 ms 64:ff9b::8efb:fd24 (64:ff9b::8efb:fd24)  45.648 ms 64:ff9b::42f9:5e52 (64:ff9b::42f9:5e52)  54.555 ms
13  64:ff9b::d83a:d6ae (64:ff9b::d83a:d6ae)  55.601 ms 64:ff9b::6caa:ffee (64:ff9b::6caa:ffee)  55.598 ms 64:ff9b::6caa:ffa8 (64:ff9b::6caa:ffa8)  55.587 ms

Code: [Sélectionner]

traceroute 2a00:1450:4007:80d::2003
traceroute to 2a00:1450:4007:80d::2003 (2a00:1450:4007:80d::2003), 30 hops max, 80 byte packets
 1  2a01cb09d02964c20000004b7d01a840.ipv6.abo.wanadoo.fr (2a01:cb09:d029:64c2:0:4b:7d01:a840)  43.274 ms  43.344 ms  53.809 ms
 2  * * *
 3  2a01:cd00:19f:101::10 (2a01:cd00:19f:101::10)  59.994 ms  59.908 ms  65.791 ms
 4  2a01:cd00:19f:12::62 (2a01:cd00:19f:12::62)  59.797 ms  65.864 ms  65.971 ms
 5  2a01:cd00:19f:13::65 (2a01:cd00:19f:13::65)  66.047 ms  66.122 ms  66.239 ms
 6  2a01:cfc4:1000:6100::3 (2a01:cfc4:1000:6100::3)  66.192 ms 2a01:cfc4:1000:6000::3 (2a01:cfc4:1000:6000::3)  38.177 ms 2a01:cfc4:1000:6100::3 (2a01:cfc4:1000:6100::3)  48.219 ms
 7  2a01:cfc0:200:8000:193:252:102:213 (2a01:cfc0:200:8000:193:252:102:213)  41.771 ms 2a01:cfc0:200:8000:193:252:102:214 (2a01:cfc0:200:8000:193:252:102:214)  35.663 ms 2a01:cfc0:200:8000:193:252:102:213 (2a01:cfc0:200:8000:193:252:102:213)  35.863 ms
 8  2a01:cfc0:200:8000:193:252:102:135 (2a01:cfc0:200:8000:193:252:102:135)  35.702 ms 2a01:cfc0:200:8000:193:252:102:136 (2a01:cfc0:200:8000:193:252:102:136)  29.841 ms  40.602 ms
 9  bundle-ether149.pastr4.paris.opentransit.net (2a01:cfc4:0:400::3)  40.588 ms * *
10  2001:4860:1:1::36a (2001:4860:1:1::36a)  45.162 ms 2001:4860:1:1::336 (2001:4860:1:1::336)  45.256 ms 2001:4860:1:1::36c (2001:4860:1:1::36c)  39.257 ms
11  2a00:1450:8121::1 (2a00:1450:8121::1)  44.368 ms 2001:4860:0:1::7fcd (2001:4860:0:1::7fcd)  44.371 ms  44.294 ms
12  2001:4860:0:1::1f97 (2001:4860:0:1::1f97)  49.597 ms 2001:4860:0:1::51f8 (2001:4860:0:1::51f8)  49.639 ms 2001:4860:0:1::51fc (2001:4860:0:1::51fc)  49.518 ms
13  2001:4860:0:1::216d (2001:4860:0:1::216d)  38.868 ms 2001:4860:0:1::28fa (2001:4860:0:1::28fa)  44.569 ms par10s21-in-x03.1e100.net (2a00:1450:4007:80d::2003)  39.702 ms

Chez moi aussi y'a mystère sur le 2nd saut qui devrait être le PGW... car je ne crois pas que le SGW soit visible du fait des tunnels. Et dans mon cas, le NAT64 est plus en amont on dirait, visiblement, il n'est pas forcément fait par le PGW (qui doit déjà avoir beaucoup de connexions à gérer).

Par contre, je ne pensais pas qu'on puisse voir le traceroute en NAT64, étonnant !

Pour la topologie en elle-même, vu le nombre d'abonnés qu'à orange, ça ne m'étonne pas vraiment. Après on est pas dedans pour savoir le rôle de chacun et si certains seraient effectivement dispensable.

simon · « **Réponse #3 le:** 26 août 2024 à 15:39:43 »

Citation de: renaud07 le 26 août 2024 à 04:01:54

Par contre, je ne pensais pas qu'on puisse voir le traceroute en NAT64, étonnant !

C'est fonction de l'équipement et de son paramétrage pour sûr, mais comme le NAT64 est stateful, il y a peu de raison qu'il ne puisse pas translater les erreurs ICMP. La valeur du Hop Limit (IPv6) est bien conservée dans le TTL (IPv4) lors du passage à travers le NAT64, et très probablement vice versa.

Ca marche aussi chez Bouygues, par exemple :

Code: [Sélectionner]

$ mtr 64:ff9b::d83a:d6ae
Start: 2024-08-26T15:10:31+0200
HOST: bones                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a04:cec0:102e:779a:9092:65ad:2094:528b         0.0%    10    2.2   4.0   1.8  13.8   3.6
  2.|-- 2a04:cec0:102e:779a:0:5b:d60a:9340              0.0%    10   31.0  35.1  31.0  38.5   2.4
  3.|-- ???                                            100.0    10    0.0   0.0   0.0   0.0   0.0
  4.|-- 2001:860:b215:5100::19:4                       50.0%    10   44.6  38.8  34.5  44.6   4.5
  5.|-- 2001:860:b215:5100::15:2                        0.0%    10   38.4  38.7  31.3  44.1   3.5
  6.|-- 64:ff9b::a97:e32                                0.0%    10   38.9  41.9  35.4  49.0   4.2
  7.|-- 64:ff9b::5959:6538                             90.0%    10  2201. 2201. 2201. 2201.   0.0
  8.|-- 64:ff9b::3e22:2a9                               0.0%    10   40.7  42.2  31.6  64.1   8.5
  9.|-- be5.cbr01-ntr.net.bbox.fr (64:ff9b::d4c2:ab89)  0.0%    10   36.3  41.8  34.3  49.7   4.7
 10.|-- ???                                            100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- 64:ff9b::480e:dd60                              0.0%    10   43.1  41.8  32.5  46.6   4.7
 12.|-- 64:ff9b::6caa:ee2d                              0.0%    10   33.6  43.2  33.6  56.2   7.1
 13.|-- 64:ff9b::d8ef:302b                              0.0%    10   44.4  42.2  34.1  47.6   4.8
 14.|-- mad01s26-in-f14.1e100.net (64:ff9b::d83a:d6ae)  0.0%    10   44.9  43.9  38.6  48.2   3.5

Citation de: zergflag le 24 août 2024 à 20:09:33

Si c'est bien le cas, pourquoi y'a t'il au moins 3 saut après la P-GW/PDNG ?

Le PGW est le point de "sortie" du réseau radiomobile, mais il faut après ca des routeurs et un réseau pour le connecter à Internet, ou du moins pour arriver sur le RBCI d'Orange dans ton traceroute. Il y a probablement des firewalls et autres joyeusetés, également.

Par contre, difficile de savoir à quoi correspondent les noeuds avant le PGW. Comme le dit renaud, le tunnel entre l'UE et le PGW devrait être opaque, mais dans le cas où un SGW ou un eNodeB permettrait de faire du local exit, est-ce qu'il ne se doit pas d'être visible au niveau IP, vu qu'il fait du routage ?

On peut aussi imaginer une implémentation similaire à un réseau MPLS, qui, en fonction de sa configuration, est entièrement opaque (rien de visible entre le routeur PE d'entrée et celui de sortie) ou le dont les noeuds intermédiaires répondent par des TTL expired.

Chez Bouygues, j'ai l'impression que le réseau conserve le PGW sur lequel tu as ouvert ton PDP context lorsque tu te déplaces géographiquement : j'ai déjà conservé le même /64 en faisant un Vannes <> Toulouse en TGV.
Je pouvais voir la liste des sauts intermédiaires sur les traceroutes s'allonger : il y a donc bien un routage L3 qui s'opère sur le payload du tunnel en amont du PGW.

renaud07 · « **Réponse #4 le:** 26 août 2024 à 18:14:21 »

Citation de: simon le 26 août 2024 à 15:39:43

C'est fonction de l'équipement et de son paramétrage pour sûr, mais comme le NAT64 est stateful, il y a peu de raison qu'il ne puisse pas translater les erreurs ICMP. La valeur du Hop Limit (IPv6) est bien conservée dans le TTL (IPv4) lors du passage à travers le NAT64, et très probablement vice versa.

Je crois que j'ai confondu avec le traceroute en ipv4 où on ne voit effectivement rien.

Citation de: simon le 26 août 2024 à 15:39:43

Par contre, difficile de savoir à quoi correspondent les noeuds avant le PGW. Comme le dit renaud, le tunnel entre l'UE et le PGW devrait être opaque, mais dans le cas où un SGW ou un eNodeB permettrait de faire du local exit, est-ce qu'il ne se doit pas d'être visible au niveau IP, vu qu'il fait du routage ?

Sauf erreur, je ne crois pas qu'il soit possible pour une eNodeB ou même un SGW de faire sortir du trafic d'un abonné, tout passe par le PGW obligatoirement car il faut gérer la mobilité. Ce qui voudrait dire aussi que chaque eNb devrait avoir un pool d'IP à disposition (et donc changer d'ip à chaque changement de site). C'est là que tu te rends compte pourquoi y'a tout ce système de tunnel entre pour faire un LAN virtuel entre le PGW et les eNb.

Citation de: simon le 26 août 2024 à 15:39:43

Chez Bouygues, j'ai l'impression que le réseau conserve le PGW sur lequel tu as ouvert ton PDP context lorsque tu te déplaces géographiquement : j'ai déjà conservé le même /64 en faisant un Vannes <> Toulouse en TGV.
Je pouvais voir la liste des sauts intermédiaires sur les traceroutes s'allonger : il y a donc bien un routage L3 qui s'opère sur le payload du tunnel en amont du PGW.

D'après ce que j'ai compris il y a très peu de PGW dans un cœur de réseau mobile, donc c'est peut-être que celui-ci couvre une bonne partie de l'ouest de la France ? Mais ton hypothèse est sans doute valable aussi. Faudrait faire un Lille <> Marseille pour voir^^

Par contre j'ai pas compris ta dernière phrase, tu dis en amont mais tu parles du tunnel. Hors il n'y a en théorie plus de tunnel en amont du PGW.

simon · « **Réponse #5 le:** 28 août 2024 à 10:04:43 »

Citation de: renaud07 le 26 août 2024 à 18:14:21

Je crois que j'ai confondu avec le traceroute en ipv4 où on ne voit effectivement rien.

Avec un traceroute effectué en IPv4 depuis l'UE ? Ca ne serait pas une limitation liée à l'implémentation du CLAT sur l'UE ? Avec tayga en NAT64 sur le routeur et en CLAT sur un PC (https://github.com/toreanderson/clatd), j'arrive bien à voir tous les noeuds intermédiaires.
Après, je ne suis pas sur le réseau mobile d'Orange, mais si tu peux voir les routeurs d'un traceroute IPv6 vers une destination dans ff9b::, tu devrais passer par le même chemin réseau (i.e. le même NAT64) pour atteindre une destination IPv4. Il y a juste le CLAT et probablement quelques règles de masquerading/filtering sur l'UE en plus.

Citation de: renaud07 le 26 août 2024 à 18:14:21

Sauf erreur, je ne crois pas qu'il soit possible pour une eNodeB ou même un SGW de faire sortir du trafic d'un abonné, tout passe par le PGW obligatoirement car il faut gérer la mobilité. Ce qui voudrait dire aussi que chaque eNb devrait avoir un pool d'IP à disposition (et donc changer d'ip à chaque changement de site). C'est là que tu te rends compte pourquoi y'a tout ce système de tunnel entre pour faire un LAN virtuel entre le PGW et les eNb.

On doit pouvoir faire du routage triangulaire (les paquets UE -> internet font du local exit, les paquets retour remontent au PGW) voire du full local exit en faisant de la translation de préfixe sur l'eNodeB/SGW. Ca se verrait sur le traffic vers internet, mais pour le traffic UE <-> IMS, ca permettrait d'éviter le passage par un PGW.
Ou un truc baroque à la software defined networking, qui permettrait de déplacer certaines fonctions du PGW dans le réseau une fois le tunnel établi...

Ou alors, ce qui est plus probable, le traffic reste dans le tunnel UE<>PGW de bout en bout, mais les noeuds intermédiaires décrémentent le Hop Limit et envoient des ICMP hop limit exceeded à la source, à l'image de ce qui est fait en MPLS. Pour donner un peu de transparence au réseau et aider à débugger, par exemple.

Ou encore autre chose... note que je n'ai aucune info sur l'implémentation d'Orange, je ne fais qu'émettre des théories farfelues pour expliquer la visibilité de ces noeuds intermédiaires

Citation de: renaud07 le 26 août 2024 à 18:14:21

D'après ce que j'ai compris il y a très peu de PGW dans un cœur de réseau mobile, donc c'est peut-être que celui-ci couvre une bonne partie de l'ouest de la France ? Mais ton hypothèse est sans doute valable aussi. Faudrait faire un Lille <> Marseille pour voir^^

J'avais plutôt en tête qu'un PGW avait un pool de /64 qui lui était routé, et que lors de l'établissement du tunnel, l'UE était dirigé vers le plus proche. Une fois le tunnel établi, on ne peut pas "migrer" le tunnel vers un autre PGW lors d'un déplacement géographique, car le /64 routé à l'UE n'arrive qu'qu PGW d'origine. Si on veut migrer, il faut changer de /64.
Mais je ferai des traceroutes supplémentaires lors de mes prochains déplacements

Citation de: renaud07 le 26 août 2024 à 18:14:21

Par contre j'ai pas compris ta dernière phrase, tu dis en amont mais tu parles du tunnel. Hors il n'y a en théorie plus de tunnel en amont du PGW.

Pardon, en effet ce n'était pas clair. Je voulais dire qu'il y a du routage L3, ou du moins décrémentation des Hop Limit, entre l'UE et le PGW. Bien sûr, plus de tunnel après le PGW.

renaud07 · « **Réponse #6 le:** 28 août 2024 à 19:02:47 »

Citation de: simon le 28 août 2024 à 10:04:43

Avec un traceroute effectué en IPv4 depuis l'UE ? Ca ne serait pas une limitation liée à l'implémentation du CLAT sur l'UE ? Avec tayga en NAT64 sur le routeur et en CLAT sur un PC (https://github.com/toreanderson/clatd), j'arrive bien à voir tous les noeuds intermédiaires.

Oui c'est ça depuis l'UE. J'ai pas réessayé avec tayga sur mon LAN par contre.

Citation de: simon le 28 août 2024 à 10:04:43

Après, je ne suis pas sur le réseau mobile d'Orange, mais si tu peux voir les routeurs d'un traceroute IPv6 vers une destination dans ff9b::, tu devrais passer par le même chemin réseau (i.e. le même NAT64) pour atteindre une destination IPv4. Il y a juste le CLAT et probablement quelques règles de masquerading/filtering sur l'UE en plus.

Je pense aussi.

Citation de: simon le 28 août 2024 à 10:04:43

On doit pouvoir faire du routage triangulaire (les paquets UE -> internet font du local exit, les paquets retour remontent au PGW) voire du full local exit en faisant de la translation de préfixe sur l'eNodeB/SGW. Ca se verrait sur le traffic vers internet, mais pour le traffic UE <-> IMS, ca permettrait d'éviter le passage par un PGW.
Ou un truc baroque à la software defined networking, qui permettrait de déplacer certaines fonctions du PGW dans le réseau une fois le tunnel établi...

Ça ne serait sans doute pas impossible à mettre en place, mais de tout ce que j'ai lu, je n'ai pas vu une seule fois mentionné un tel fonctionnement. Le seul truc qui ressemble à ce que tu décris, c'est le local breakout, qui permet en roaming de sortir par le réseau visité, mais ça passe toujours par un PGW.

Citation de: simon le 28 août 2024 à 10:04:43

Ou alors, ce qui est plus probable, le traffic reste dans le tunnel UE<>PGW de bout en bout, mais les noeuds intermédiaires décrémentent le Hop Limit et envoient des ICMP hop limit exceeded à la source, à l'image de ce qui est fait en MPLS. Pour donner un peu de transparence au réseau et aider à débugger, par exemple.

Ou encore autre chose... note que je n'ai aucune info sur l'implémentation d'Orange, je ne fais qu'émettre des théories farfelues pour expliquer la visibilité de ces noeuds intermédiaires

Possible, je n'ai pas creusé le fonctionnement de GTP, juste les grandes lignes. C'est une question pour MoXxXoM ça.

Citation de: simon le 28 août 2024 à 10:04:43

J'avais plutôt en tête qu'un PGW avait un pool de /64 qui lui était routé, et que lors de l'établissement du tunnel, l'UE était dirigé vers le plus proche. Une fois le tunnel établi, on ne peut pas "migrer" le tunnel vers un autre PGW lors d'un déplacement géographique, car le /64 routé à l'UE n'arrive qu'qu PGW d'origine. Si on veut migrer, il faut changer de /64.
Mais je ferai des traceroutes supplémentaires lors de mes prochains déplacements

Oui c'est ça, chaque PGW a un pool de /64 et si on passe sur un autre, le /64 change. Pour ce qui est du comportement exact, est-ce que un PGW est conservé pendant une même session, même à l'autre bout de la France ou est-ce qu'il peut changer... j'ai pas trouvé la réponse (ou je l'ai lu quelque part mais je m'en rappelle plus...)

EDIT : En cherchant cette histoire de mobilité entre SGW et PGW, je suis tombé là dessus : https://www.istegroup.com/wp-content/uploads/2018/06/426_L%E2%80%99int%C3%A9gration-de-Wi-Fi-dans-le-r%C3%A9seau-de-mobiles-4G_P%C3%A9rez_Premi%C3%A8re-partie.pdf

Et on peut lire : L’entité PGW est la seule entité du réseau EPS qui route le paquet IP du mobile. Le réseau de transport IP qui permet la communication entre les entités du réseau EPS route le paquet IP support S1 ou S5. Les entités eNB et SGW n’effectuent pas de routage. Elles assurent uniquement la connexion entre les supports.

Donc c'est bien ce qu'il me semblait, pas de routage à proprement parler pour le SGW/eNb, tout passe exclusivement par le PGW pour joindre internet ou l'IMS.

simon · « **Réponse #7 le:** 29 août 2024 à 10:54:37 »

Citation de: renaud07 le 28 août 2024 à 19:02:47

Pour ce qui est du comportement exact, est-ce que un PGW est conservé pendant une même session, même à l'autre bout de la France ou est-ce qu'il peut changer... j'ai pas trouvé la réponse (ou je l'ai lu quelque part mais je m'en rappelle plus...)

D'après ce qu'on vient de dire, oui, le PGW est conservé durant toute la session, sinon le /64 changerait.
Le réseau pourrait ceci dit fermer la session lorsque tu franchis une frontière de zone, pour forcer ton UE à ré-étalblir un tunnel avec un nouveau /64. Mais encore une fois, j'ai pu conserver mon /64 sur de grandes distances chez Bouygues.

Citation de: renaud07 le 28 août 2024 à 19:02:47

Donc c'est bien ce qu'il me semblait, pas de routage à proprement parler pour le SGW/eNb, tout passe exclusivement par le PGW pour joindre internet ou l'IMS.

Dans les normes, oui. On peut imaginer des optimisations non-standard chez certains constructeurs, à l'image de ce que Cisco fait couramment.

Mais bon, encore une fois, je ne fais que supposer : je n'ai (malheureusement) pas d'info terrain, jamais fait de réseau radiomobile.

MoXxXoM · « **Réponse #8 le:** 30 août 2024 à 10:41:08 »

Tout dépend de la configuration du réseau et des interconnexions à l'intérieur du réseau mobile. Si c'est complètement à plat, et que tous les MME peuvent joindre toutes les SGW, et de meme si toutes les SGW peuvent joindre toutes les PGW c'est tout a fait possible d'avoir une session conservée lors de grands trajets. En effet lorsque le MME déclenche un changement de SGW, le F-TEID (fully qualified tunnel endpoint identifier, en gros l'IP de la PGW courante et l'identifiant du tunnel GTP) est transmis à la nouvelle SGW et donc la PGW peut, si c'est autorisé, rester inchangée. Et tant que la session tombe pas et que le réseau le permet un préfixe IPv6 peut voyager très loin. Avec le deploiement de la LTE et l'augmentation des capacités de transport en n x 100G c'est devenu très courant de laisser les flux se balader d'une région à l'autre.

renaud07 · « **Réponse #9 le:** 30 août 2024 à 17:39:35 »

Merci pour les précisons.

Concernant le handover entre PGW, j'ai trouvé un brevet intéressant : Inter-PGW Handover Architecture qui permet apparemment un passage sans interruption.

Par contre je ne sais pas si voué (ou déjà) intégré à la norme. Car la boite est d'après son site leader sur l'openRAN, donc cette "brevetisation" me parait curieuse (après je ne suis pas du tout au fait du juridique autour, mais de ma compréhension, si c'est "open" il ne devrait pas y avoir de brevets ?).

Et pour l'histoire du traceroute, on est censé voir les sauts intermédiaires ou pas ? (Du moins le SGW, les routeurs entre peut-être pas)

MoXxXoM · « **Réponse #10 le:** 31 août 2024 à 10:23:55 »

Citation de: renaud07 le 30 août 2024 à 17:39:35

Merci pour les précisons.

Concernant le handover entre PGW, j'ai trouvé un brevet intéressant : Inter-PGW Handover Architecture qui permet apparemment un passage sans interruption.

Par contre je ne sais pas si voué (ou déjà) intégré à la norme. Car la boite est d'après son site leader sur l'openRAN, donc cette "brevetisation" me parait curieuse (après je ne suis pas du tout au fait du juridique autour, mais de ma compréhension, si c'est "open" il ne devrait pas y avoir de brevets ?).

Et pour l'histoire du traceroute, on est censé voir les sauts intermédiaires ou pas ? (Du moins le SGW, les routeurs entre peut-être pas)

De mémoire (je me trompe peut-être) il n'y a pas de possibilité dans le standard de bouger d'une P-GW à une autre (toutefois les équipementiers proposent des clustering de P-GW, et un client peut bouger d'une P-GW à une autre mais pas d'un point de vue 3gpp / interface S5/S8). La majorité des histoires de mobilité dans le core network c'est standardisé autour de GTP (essentiellement dans la TS 29.274).

Il faut voir la connectivité data d'un mobile comme un tunnel vraiment hermétique entre la P-GW et le mobile, c'est un peu comme PPP, et donc le premier hop visible c'est directement la P-GW, mais pour tout un tas de raison le tunnel GTP peut être terminé sur un équipement et transformer en autre chose (genre du GRE pour agréger vers des équipement commun à l'accès fixe) et ça peut se voir sur les traceroute. Sinon concernant le premier hop, même s'il s'agit d'une IPv6 a priori publique (par ex. 2a01:cd00:7ff0:3000::110), il n'y a pas de route pour cette adresse dans la DFZ, donc il faut garder en tête que c'est vraiment de la tambouille interne du réseau mobile.

Dans le monde mobile les brevets ne sont pas exclus des standards ouverts, cf. ce genre de rapport https://dplgbgt8ul59z.cloudfront.net/assets/uploads/5G_SEP_IPR_Report.pdf, c'est l'ETSI la meilleure source officielle (https://ipr.etsi.org/), mais la le brevet c'est vraiment léger, il n'est pas pas dans la base de donnée de l'ETSI d'ailleurs.

C'est pas le sujet, mais Open Ran autant sur le papier c'est une bonne idée, autant en vrai le marché du RAN est trop dysfonctionnel pour que ça change quelque chose (Ericsson devient le fournisseur quasi exclusif de RAN aux US, Nokia va tellement mal que ça ressort des rumeurs de rachat par Samsung - https://www.reuters.com/technology/samsung-shows-interest-nokia-mobile-networks-assets-bloomberg-news-reports-2024-08-29/- et Huawei domine le reste du monde). Faire en sorte qu'eCPRI soit plus interopérable ça ne changera rien, tellement rien que c'est devenu un argument pour faire du mono-vendor (https://www.lightreading.com/open-ran/-open-ran-now-justifies-using-a-single-vendor).

renaud07 · « **Réponse #11 le:** 31 août 2024 à 17:56:56 »

Citation de: MoXxXoM le 31 août 2024 à 10:23:55

De mémoire (je me trompe peut-être) il n'y a pas de possibilité dans le standard de bouger d'une P-GW à une autre (toutefois les équipementiers proposent des clustering de P-GW, et un client peut bouger d'une P-GW à une autre mais pas d'un point de vue 3gpp / interface S5/S8). La majorité des histoires de mobilité dans le core network c'est standardisé autour de GTP (essentiellement dans la TS 29.274).

Oui, c'est ce qui est évoqué dans le brevet (et ce que j'en avait déduis aussi vu que personne n'en parle). Hormis une coupure nette de l'accès y'a pas de handover transparent. Intéressant le système du cluster pour compenser.

Citation de: MoXxXoM le 31 août 2024 à 10:23:55

Il faut voir la connectivité data d'un mobile comme un tunnel vraiment hermétique entre la P-GW et le mobile, c'est un peu comme PPP, et donc le premier hop visible c'est directement la P-GW, mais pour tout un tas de raison le tunnel GTP peut être terminé sur un équipement et transformer en autre chose (genre du GRE pour agréger vers des équipement commun à l'accès fixe) et ça peut se voir sur les traceroute.

Merci pour la confirmation, c'est bien ce qu'il me semblait. Par contre j'ai pas bien compris ta dernière phrase, c'est le PGW qui transforme le GTP en autre chose si besoin, ou le GTP peut se terminer sur un autre équipement après le PGW ? (Je sais je suis chiant^^ désolé)

Citation de: MoXxXoM le 31 août 2024 à 10:23:55

Sinon concernant le premier hop, même s'il s'agit d'une IPv6 a priori publique (par ex. 2a01:cd00:7ff0:3000::110), il n'y a pas de route pour cette adresse dans la DFZ, donc il faut garder en tête que c'est vraiment de la tambouille interne du réseau mobile.

J'étais justement allé voir si HE voyait cette adresse depuis le net et c'est pas le cas. Mais j'ai l'impression que c'est plus la politique d'orange que de ne pas annoncer les préfixes relatifs à leurs routeurs. J'ai testé pleins d'adresses différentes (aussi bien fixe que mobile) et à chaque fois ce n'était pas annoncé (contrairement à Bouygues par ex).

Citation de: MoXxXoM le 31 août 2024 à 10:23:55

Dans le monde mobile les brevets ne sont pas exclus des standards ouverts, cf. ce genre de rapport https://dplgbgt8ul59z.cloudfront.net/assets/uploads/5G_SEP_IPR_Report.pdf, c'est l'ETSI la meilleure source officielle (https://ipr.etsi.org/), mais la le brevet c'est vraiment léger, il n'est pas pas dans la base de donnée de l'ETSI d'ailleurs.

Ah ok, c'est assez particulier comme approche.

Citation de: MoXxXoM le 31 août 2024 à 10:23:55

C'est pas le sujet, mais Open Ran autant sur le papier c'est une bonne idée, autant en vrai le marché du RAN est trop dysfonctionnel pour que ça change quelque chose (Ericsson devient le fournisseur quasi exclusif de RAN aux US, Nokia va tellement mal que ça ressort des rumeurs de rachat par Samsung - https://www.reuters.com/technology/samsung-shows-interest-nokia-mobile-networks-assets-bloomberg-news-reports-2024-08-29/- et Huawei domine le reste du monde). Faire en sorte qu'eCPRI soit plus interopérable ça ne changera rien, tellement rien que c'est devenu un argument pour faire du mono-vendor (https://www.lightreading.com/open-ran/-open-ran-now-justifies-using-a-single-vendor).

Vu qu'ils ont démenti les rumeurs hier, espérons que ça ne se fasse pas. Perdre un acteur majeur dans le domaine et encore plus concentrer le marché...