La Fibre

Télécom => Réseau => reseau IPv6 => Discussion démarrée par: renaud07 le 24 janvier 2024 à 21:35:10

Titre: Test du MAP-T et MAP-E en LAB
Posté par: renaud07 le 24 janvier 2024 à 21:35:10
Bonjour,

J'avais dit dans le topic FAI: Les solutions pour partager l'IPv4 entre plusieurs clients que je testerais bien le MAP-T. C'est chose faite, et je touche presque au but après il faut le dire des heures de fumage de cerveau, à essayer de trouver la bonne syntaxe jusqu'à ce que je retrouve la nouvelle adresse du très pratique générateur de config DHCPv6 de cisco (https://map46.cisco.com/) (écrit par un français en plus, merci Arthur !) et pouf tout marche instantanément... mais il reste un soucis.

Le setup :
-Le BR : debian avec ISC-DHCP, Jool et radvd
-Le CE : Un openWRT

La conf :
-IPv4 prefix :192.168.46.0/30
-Ipv6 prefix (BMR) : 2001:db8:9400::/60
-CE prefix : 2001:db8:9400:: → 2001:db8:9400:c:: /62
-BR prefix (DMR) : 4464:ff9b:ce::/64 (je me suis inspiré du well know prefix du DNS64, c'est d'ailleurs ce que l'auteur de jool utilise pour sa démo, le vrai en /96, mais le générateur de cisco ne génère qu'avec des /64)

Pour la faire court tout fonctionne presque : les paquets v4 partent, sont translatés, reviennent, re-translation, mais je ne les vois jamais arriver. Je soupçonne le parefeu de l'opemwrt de les dropper, ce qui est étrange étant donné que la connexion est initiée depuis le LAN. idem depuis OWRT lui-même d'ailleurs. Le test est basique avec des ping, qui normalement ne sont pas bloqués, même en config par défaut. Si je connecte l'OWRT normalement à mon LAN, aucun soucis, tout fonctionne.

Vu que je provisionne par DHCP, une interface MAP virtuelle est créée, je ne sais pas si ça change quelque chose. Car un ip a, retourne une unique link local sur celle-ci et pas d'ipv4 alors que sur une conf manuelle, comme celle de Free par ex (mais c'est du MAP-E) on a bien l'ipv4 renseignée.

Le message du kernel lors de la création :
nat46: configure device (map-wan6_4) with 'local.style MAP local.v4 192.168.46.0/30 local.v6 2001:db8:9400::/60 local.ea-len 2 local.psid-offset 1 remote.v4 0.0.0.0/0 remote.v6 4464:ff9b:ce::/64 remote.style RFC6052 remote.ea-len 0 remote.psid-offset 0'
Pour la config, je fais d'abord simple avec une adresse complète car quand j'ai voulu tester le partage, ça n'a pas fonctionné et les paquets ne passaient plus le BR en retour. J'imagine que je me suis planté sur la règle de jool ou les paramètres DHCP, car je n'ai pas tout saisi ces histoires de PSID/EA-bits (je suis très nul en maths, faut pas trop m'en demander  ;D)

Les commandes pour jool :
jool_mapt instance add "BR" --netfilter --dmr 4464:ff9b:ce::/64
jool_mapt -i "BR" fmrt add 2001:db8:9400::/60 192.168.46.0/30 2 0
jool_mapt -i "BR" global update map-t-type BR

Je n'ai pas compris à quoi correspond le 0 après le 2, est-ce la valeur a dont l'auteur parle ici ? : https://www.jool.mx/en/map-t.html#the-a-k-and-m-configuration-variables Je me demande si c'est pas ça qui résoudrait l'énigme du partage de ports (mais on va tenter de résoudre le soucis avec un adresse complète d'abord).

Si quelqu'un a une idée sur ce qui cloche...

Merci d'avance  :)
Titre: Test du MAP-T en LAB : J'y suis... presque
Posté par: kgersen le 24 janvier 2024 à 23:44:11
d'apres le code source c'est le "PSID Offset" dans la RFC. (donc c'est bien la valeur "a").

/* For MAP-T */
struct mapping_rule {
struct ipv6_prefix prefix6;
struct ipv4_prefix prefix4;
__u8 o; /* The EA-bits length, in bits. */

/*
* Length of the Port-Restricted Port Field's "i" slice. (Also known as
* the "A" slice.)
* The RFCs have an unfortunate long name for "a": "PSID offset."
* In my opinion, this is a poor choice because it only makes sense if
* you're looking at the Port-Restricted Port Field diagram, and is very
* confusing if you're looking at the MAP IPv6 Address Format diagram.
* (`a` does not have anything to do with `n + p`.)
*
* Remember that k = q = o - p, and m = 16 - a - k.
* So storing those fields would be redundant.
*
* Yes, I know the RFCs imply that `a` doesn't belong to mapping rules.
* But let's be honest: Those RFCs are massive, massive trainwrecks.
* In practice, there's no reason to force all mapping rules to share
* the same `a`.
*
* You see, the RFCs have a massive problem in that the notion of a
* "MAP domain" is not consistent through them. I've decided to go with
* the version that makes sense to me, which is "each MAP domain has a
* distinct BMR." According to that definition, it doesn't make sense to
* force every connected MAP domain to have the same Port-Restricted
* Port Field.
*/
__u8 a;
};
Titre: Test du MAP-T en LAB : J'y suis... presque
Posté par: renaud07 le 25 janvier 2024 à 02:15:03
Merci, je commence à comprendre. Le pire c'est qu'il y a les détails sur le générateur lorsqu'on clique sur les règles avancées. Ça modifie le nombre de ports réservés et de ranges en fait.

J'ai donc réessayé avec 192.168.46.1/32, et un offset à 0 ce qui nous fait 16384 ports pour 4 CE et la commande jool kivabien jool_mapt -i "BR" fmrt add 2001:db8:9400::/60 192.168.46.1/32 2 0

Et... it works !
root@debian:~# tcpdump -i enp0s8 tcp port 80
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), snapshot length 262144 bytes
01:28:07.257591 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49182 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [S], seq 3790998064, win 64240, options [mss 1440,sackOK,TS val 2133491635 ecr 0,nop,wscale 7], length 0
01:28:07.508276 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49183 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [S], seq 3576058630, win 64240, options [mss 1440,sackOK,TS val 2133491886 ecr 0,nop,wscale 7], length 0
01:28:07.541135 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49183: Flags [S.], seq 453561669, ack 3576058631, win 65160, options [mss 1460,sackOK,TS val 1309919073 ecr 2133491886,nop,wscale 10], length 0
01:28:07.541546 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49183 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [.], ack 1, win 502, options [nop,nop,TS val 2133491919 ecr 1309919073], length 0
01:28:07.541634 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49183 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [P.], seq 1:361, ack 1, win 502, options [nop,nop,TS val 2133491920 ecr 1309919073], length 360: HTTP: GET / HTTP/1.1
01:28:07.581605 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49183: Flags [.], ack 361, win 64, options [nop,nop,TS val 1309919110 ecr 2133491920], length 0
01:28:07.586303 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49183: Flags [.], seq 1:1429, ack 361, win 64, options [nop,nop,TS val 1309919112 ecr 2133491920], length 1428: HTTP: HTTP/1.1 200 OK
01:28:07.587232 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49183 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [.], ack 1429, win 501, options [nop,nop,TS val 2133491965 ecr 1309919112], length 0
01:28:07.590272 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49183: Flags [P.], seq 1429:2857, ack 361, win 64, options [nop,nop,TS val 1309919112 ecr 2133491920], length 1428: HTTP
01:28:07.591359 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49183: Flags [P.], seq 2857:3488, ack 361, win 64, options [nop,nop,TS val 1309919112 ecr 2133491920], length 631: HTTP
01:28:07.591603 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49183 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [.], ack 2857, win 501, options [nop,nop,TS val 2133491969 ecr 1309919112], length 0
01:28:07.592460 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49183 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [.], ack 3488, win 501, options [nop,nop,TS val 2133491970 ecr 1309919112], length 0
01:28:07.615214 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49184 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [S], seq 1856372793, win 64240, options [mss 1440,sackOK,TS val 2133491993 ecr 0,nop,wscale 7], length 0
01:28:07.646146 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49184: Flags [S.], seq 3639631816, ack 1856372794, win 65160, options [mss 1460,sackOK,TS val 1309919179 ecr 2133491993,nop,wscale 10], length 0
01:28:07.646825 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49184 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [.], ack 1, win 502, options [nop,nop,TS val 2133492025 ecr 1309919179], length 0
01:28:07.646991 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49184 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [P.], seq 1:330, ack 1, win 502, options [nop,nop,TS val 2133492025 ecr 1309919179], length 329: HTTP: GET /connectivity.php HTTP/1.1
01:28:07.679802 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49184: Flags [.], ack 330, win 64, options [nop,nop,TS val 1309919215 ecr 2133492025], length 0
01:28:07.683130 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49184: Flags [P.], seq 1:577, ack 330, win 64, options [nop,nop,TS val 1309919216 ecr 2133492025], length 576: HTTP: HTTP/1.1 200 OK
root@debian:~# tcpdump -i enp0s3 tcp port 80
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
01:29:20.341833 IP 192.168.46.1.49185 > fr.archive.ubuntu.com.http: Flags [S], seq 4137385102, win 64240, options [mss 1440,sackOK,TS val 2133564723 ecr 0,nop,wscale 7], length 0
01:29:20.371742 IP fr.archive.ubuntu.com.http > 192.168.46.1.49185: Flags [S.], seq 1165256997, ack 4137385103, win 65160, options [mss 1460,sackOK,TS val 1309991908 ecr 2133564723,nop,wscale 10], length 0
01:29:20.372454 IP 192.168.46.1.49185 > fr.archive.ubuntu.com.http: Flags [.], ack 1, win 502, options [nop,nop,TS val 2133564754 ecr 1309991908], length 0
01:29:20.372516 IP 192.168.46.1.49185 > fr.archive.ubuntu.com.http: Flags [P.], seq 1:361, ack 1, win 502, options [nop,nop,TS val 2133564754 ecr 1309991908], length 360: HTTP: GET / HTTP/1.1
01:29:20.408268 IP fr.archive.ubuntu.com.http > 192.168.46.1.49185: Flags [.], ack 361, win 64, options [nop,nop,TS val 1309991942 ecr 2133564754], length 0
01:29:20.408762 IP fr.archive.ubuntu.com.http > 192.168.46.1.49185: Flags [.], seq 1:1429, ack 361, win 64, options [nop,nop,TS val 1309991944 ecr 2133564754], length 1428: HTTP: HTTP/1.1 200 OK
01:29:20.410092 IP 192.168.46.1.49185 > fr.archive.ubuntu.com.http: Flags [.], ack 1429, win 501, options [nop,nop,TS val 2133564791 ecr 1309991944], length 0
01:29:20.411907 IP fr.archive.ubuntu.com.http > 192.168.46.1.49185: Flags [P.], seq 1429:2857, ack 361, win 64, options [nop,nop,TS val 1309991944 ecr 2133564754], length 1428: HTTP
01:29:20.412240 IP 192.168.46.1.49185 > fr.archive.ubuntu.com.http: Flags [.], ack 2857, win 501, options [nop,nop,TS val 2133564794 ecr 1309991944], length 0
01:29:20.412518 IP fr.archive.ubuntu.com.http > 192.168.46.1.49185: Flags [P.], seq 2857:3488, ack 361, win 64, options [nop,nop,TS val 1309991944 ecr 2133564754], length 631: HTTP
01:29:20.412769 IP 192.168.46.1.49185 > fr.archive.ubuntu.com.http: Flags [.], ack 3488, win 501, options [nop,nop,TS val 2133564794 ecr 1309991944], length 0
01:29:20.432203 IP 192.168.46.1.49186 > fr.archive.ubuntu.com.http: Flags [S], seq 902139922, win 64240, options [mss 1440,sackOK,TS val 2133564813 ecr 0,nop,wscale 7], length 0
01:29:20.463630 IP fr.archive.ubuntu.com.http > 192.168.46.1.49186: Flags [S.], seq 1840750512, ack 902139923, win 65160, options [mss 1460,sackOK,TS val 1309991998 ecr 2133564813,nop,wscale 10], length 0
01:29:20.464133 IP 192.168.46.1.49186 > fr.archive.ubuntu.com.http: Flags [.], ack 1, win 502, options [nop,nop,TS val 2133564845 ecr 1309991998], length 0
01:29:20.464253 IP 192.168.46.1.49186 > fr.archive.ubuntu.com.http: Flags [P.], seq 1:330, ack 1, win 502, options [nop,nop,TS val 2133564845 ecr 1309991998], length 329: HTTP: GET /connectivity.php HTTP/1.1
01:29:20.500685 IP fr.archive.ubuntu.com.http > 192.168.46.1.49186: Flags [.], ack 330, win 64, options [nop,nop,TS val 1309992034 ecr 2133564845], length 0
01:29:20.503893 IP fr.archive.ubuntu.com.http > 192.168.46.1.49186: Flags [P.], seq 1:577, ack 330, win 64, options [nop,nop,TS val 1309992035 ecr 2133564845], length 576: HTTP: HTTP/1.1 200 OK

Maintenant, je n'ai plus qu'à tester avec plusieurs CPE et aussi retenter avec un /30 vu que ça n'avait pas l'air de vouloir fonctionner.

Et à priori pour l'interface virtuelle, la link local seule est normal, il n'y a pas eu apparition de l'ipv4.
Titre: Test du MAP-T en LAB : J'y suis... presque
Posté par: ppn_sd le 25 janvier 2024 à 08:55:11
Pourrais-tu faire un retour sur une liste complète des commandes si cela diffère de la doc (https://www.jool.mx/en/run-mapt.html#configuration (https://www.jool.mx/en/run-mapt.html#configuration)) ?
Les exemples de la documentation (sur d'autres configurations en tout cas) laissent parfois de côté des commandes.
Titre: Test du MAP-T en LAB : J'y suis... presque
Posté par: renaud07 le 25 janvier 2024 à 15:34:07
Oui pas de soucis.

Pour le moment je n'ai utilisé que la partie BR. La conf full manuelle était inutile dans mon cas vu que j'utilise openwrt et pas une debian nue en guise de CE (cela dit c'est bien pour voir comment ça marche en backstage). Je voulais un minimum de réel pour communiquer avec mon LAN et internet.
Titre: Test du MAP-T en LAB : J'y suis... presque
Posté par: renaud07 le 25 janvier 2024 à 21:04:41
Il semblerait que tout soit nickel : les 4 CPE marchent de concert, le forwarding/découpage des ports aussi  8) Et même avec des ipv6 invalides (range pour la doc), je peux quand même accéder au net en v4. Je vais tester avec mon préfixe orange histoire de valider la v6 aussi, mais à mon avis, c'est une simple formalité.

Je n'ai pas encore retesté avec une IPv4 complète.
Titre: Test du MAP-T en LAB : J'y suis... presque
Posté par: renaud07 le 26 janvier 2024 à 17:59:53
Je suis en train de tester avec mon préfixe orange, mais étant en wifi sur mon PC portable, y'a des problèmes avec l'ipv6 et virtualbox. Du coup, j'avais monté un système de VXLAN pour bypasser les restrictions.

Sauf que maintenant, j'ai un soucis de routage : je voudrais router le trafic sortant du BR ou du moins le /60 sur le VXLAN et non sur la route par défaut. Et j'ai un doute sur si c'est possible ou pas (je n'arrive pas à trouver d'explication claire). J'imagine qu'il faut utiliser l’argument src avec ip route, mais je trouve pas d'exemple avec IPv6.
Titre: Test du MAP-T en LAB : J'y suis... presque
Posté par: Hugues le 26 janvier 2024 à 18:12:21
src c'est autre chose, tu veux plutôt faire du PBR je pense
Titre: Test du MAP-T en LAB : J'y suis... presque
Posté par: renaud07 le 26 janvier 2024 à 18:25:13
En effet, c'est ça, je retrouvais plus le nom.

Du coup, ça donnerait un truc comme (en omettant les autres commandes) :
ip -6 rule add from 2001:DB8:9400::/60 table vxlan
ip -6 route add default via fe80::linklocal-vxlan dev vxlan table vxlan

J'ai bon ? Inspiré de ce post : https://serverfault.com/questions/854094/linux-ipv6-policy-based-routing-fails

EDIT : À priori on est obligé de mettre une GUA dans ce cas.
Titre: Test du MAP-T en LAB : J'y suis... presque
Posté par: renaud07 le 27 janvier 2024 à 03:31:44
On dirait bien que c'est un succès, dual stack fonctionnel, le tout par dessus du VXLAN  8) Après pas mal de bourdes dont j'ai le secret (comme remplacer les b par des d dans le préfixe et s'étonner que les paquets reviennent pas ou choisir la mauvaise interface pour la route  :P) L'ipv4 complète fonctionne aussi, il faut simplement mettre les EA bits lenght et le PSID offset à 0 côté jool.

Il ne manque plus que la cerise sur le gâteau : écrire un bout de code pour luci afin d'indiquer l'ipv4 publique et le/les ranges/nombre de ports sur l'interface MAP virtuelle (à la manière de Free). C'est compliqué ou pas ?

J'avais aussi oublié de poster à quoi doit ressembler l'option 95 si vous voulez tester (vaut mieux se servir du générateur, au risque d'envoyer une chaîne totalement pétée et chose appréciable, il fonctionne sur le navigateur rien n'est envoyé)
Titre: Test du MAP-T en LAB
Posté par: renaud07 le 29 janvier 2024 à 04:24:29
J'essaie de faire fonctionner le MAP-E de façon simplifiée.

J'ai tenté le tunnel ipip6 statique BR → CE (vu que dans l'autre sens c'est déjà monté), sauf que le BR n'a pas de "vrai" tunnel avec chaque CE, si ? Et évidemment en l'état, rien ne passe. Je me doute que c'est un poil plus compliqué et qu'il faut décapsuler l'ipv4 avant de forwarder.

Une idée ?

Si seulement jool supportait le MAP-E... en plus ça à l'air, du moins en apparence, moins compliqué que MAP-T vu qu'il n'y a pas de translation.
Titre: Test du MAP-T en LAB
Posté par: renaud07 le 30 janvier 2024 à 18:31:39
Quelqu'un a déjà utilisé VPP ? https://wiki.fd.io/view/VPP

Je vois que ça implémente MAP-E (la seule implémentation que j'ai trouvé pour du BR), mais impossible à faire fonctionner. Je n'arrive même pas à sortir sur le net. C'est une tannée à configurer...
Titre: Test du MAP-T en LAB
Posté par: renaud07 le 31 janvier 2024 à 03:47:32
La bataille fut rude, mais je l'ai eu !  :D

Au final c'est presque comme une debian normale, sauf qu'il faut bien connaître la syntaxe qui diffère, sans compter tout le travail préparatoire. J'ai dû aussi installer une interface graphique pour avoir le copier/coller fonctionnel car sans accès SSH (voir plus bas) c'était un poil relou de tout taper à la main...

Installation du repo : https://wiki.fd.io/view/VPP/Installing_VPP_binaries_from_packages puis :
apt install vpp vpp-plugin-dpdk vpp-plugin-core
Édition de /etc/vpp/startup.conf pour ajouter les identifiants des cartes physiques (faire un lshw) exemple chez moi  :
dpdk {
dev 0000:00:03.0 {
}
dev 0000:00:08.0
}

Bien penser à down les interfaces avant de démarrer VPP sinon il ne peut pas en prendre le contrôle (visible en faisant un systemctl status). Conséquence, elle disparaissent et l’hôte n'a plus de connectivité, à moins après coup de créer une "host-interface" qui, je pense, permet de lui redonner un accès (pas encore testé).

Entrée dans vpp avec vppctl. À partir de là on commence la conf proprement dite :
# vérifier le noms des interfaces
show interface

# définiton des adresses
set interface ip address GigabitEthernet0/3/0 192.168.1.164/24
set interface ip address GigabitEthernet0/8/0 2001:db8:940e::1/64
set interface ip address GigabitEthernet0/8/0 fe80::ba0:bab/128 # petite ref à orange ;)


# activation des interfaces
set interface state GigabitEthernet0/3/0 up
set interface state GigabitEthernet0/8/0 up

#ajout de la route par défaut (carte LAN)
ip route add 0.0.0.0/0 via 192.168.1.1 GigabitEthernet0/3/0

# ajout de chaque CE (un seul pour l'exemple) (carte CE)
ip route add 2001:db8:940e:4::/62 via fe80::a00:27ff:fe46:d036 GigabitEthernet0/8/0

#création du domaine
map add domain ip4-pfx 192.0.2.0/30 ip6-pfx 2001:db8:940e::/60 ip6-src 2001:db8:940e::1 ea-bits-len 2 psid-offset 0 psid-len 0

#activation du MAP-E sur les 2 interfaces (sinon ça marche pas), si on fait du MAP-T, il faut ajouter "map-t" après les noms d'interface
map interface GigabitEthernet0/8/0
map interface GigabitEthernet0/3/0

J'ajoute avec tout ça le provisionnement des CE par DHCPv6 comme pour MAP-T (via une autre VM). Ainsi que les routes sur le routeur principal.

Et en théorie ça doit marcher !

Ce n'est qu'un premier essai et tout n'est pas fonctionnel comme l'ipv6 (pas monté de vxlan par ex, je pourrais tester en filaire cela dit). Y'a aussi un peu de tunning à faire comme le fait que ça bouffe 2 Go de RAM à vide (même service arrêté, j'ai trouvé ça étonnant, il faut le désinstaller pour que ça cesse) et 100% du CPU en permanence, va falloir creuser un peu. Mais le plus important fonctionne et c'est le principal  :)
Titre: Test du MAP-T en LAB
Posté par: ppn_sd le 31 janvier 2024 à 08:27:43
Merci pour les tests !

Y'a aussi un peu de tunning à faire comme le fait que ça bouffe 2 Go de RAM à vide (même service arrêté, j'ai trouvé ça étonnant, il faut le désinstaller pour que ça cesse) et 100% du CPU en permanence, va falloir creuser un peu.

Pour l'utilisation du CPU, c'est "normal" pour DPDK :
https://doc.dpdk.org/guides-22.11/prog_guide/power_man.html#empty-poll-api
https://s3-docs.fd.io/vpp/23.10/gettingstarted/troubleshooting/cpuusage.html#vpp-cpu-load
Titre: Test du MAP-T et MAP-E en LAB
Posté par: renaud07 le 31 janvier 2024 à 18:33:56
Merci pour l'info, il me semblait bien avoir lu un truc là dessus. Mais je viens de trouver un paramètre qui permet de mettre en pause malgré le polling : https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/users/configuring/startup.html#unix

Il faut rajouter poll-sleep-usec 100 (ou autre valeur suivant ce qu'on veut obtenir) dans la section unix { } de startup.conf Et magie, la conso CPU retombe à 1-2%. Il ne reste que la RAM, mais bon c'est pas gênant, ça ne consomme pas plus de watts qu'elle soit plus utilisée ou non.

J'ai alors fait un speedtest et le débit est vraiment bon, je ne vois pas de différence significative avec une connexion directe (entre 200-300 mbps, je suis un peu éloigné de mon AP) avec une conso CPU ridicule de 5%, là où Jool avec MAP-T prend bien 20-25%. Il faudrait que je compare, voir si VPP s'en sort mieux.
Titre: Test du MAP-T et MAP-E en LAB
Posté par: renaud07 le 01 février 2024 à 00:41:09
J'essaie de créer un domaine MAP-T pour faire la comparaison avec Jool mais rien à faire, l'option n'est pas reconnue... J'ai cru que la syntaxe avait changée, mais j'ai vérifié et c'est pas le cas. Tous les arguments y compris tag et mtu qui ne sont pas indispensables, passent. Il doit y avoir un bug quelque part.

https://docs.fd.io/vpp/23.10/cli-reference/clis/clicmd_src_plugins_map.html#map-add-domain

EDIT : upgrade vers la dernière version en rc (24.06) et même soucis... Bizarre.
Titre: Test du MAP-T et MAP-E en LAB
Posté par: renaud07 le 02 février 2024 à 02:37:02
Surprise ce soir, MAP-T s'est mis à fonctionner. L'argument ne sert en fait à rien (et a sans doute été supprimé) lors de l'ajout du domaine, le tout est de bien l'activer sur chaque interface. Mais j'ai l'impression que ça déconne un peu, des fois il n'est pas pris en compte et il faut le supprimer/recréer une seconde fois. C'est peut-être ce qui est arrivé.

J'ai donc fait un petit ST et le résultat est sans appel : environ 15% de CPU lors du transfert à 300 Mbps, moins consommateur que jool.

Par contre un truc bizarre, la conso totale ne rapporte pas la même valeur que le processus, mais genre 6% (sur htop). Faut que je vérifie pour jool, car je m'étais fié à la conso totale.

Pour la commande il suffit de remplacer ip6-src par la DMR au lieu de l'adresse du BR en MAP-E ce qui donne :
add domain ip4-pfx 192.0.2.0/30 ip6-pfx 2001:db8:9400::/60 ip6-src 4464:ff9b:ce::/64 ea-bits-len 2 psid-offset 0
Et petite astuce : si on ne veut pas se servir de la première v4 en .0 qui peut potentiellement générer des soucis avec certains systèmes, il ne faut pas attribuer le premier préfixe (ici un /62), ou plus laborieux, attribuer une règle à chaque CE avec une v4 en /32 et le /62 associé (mais plus pénible à maintenir), bien ajuster le ea-bits-len en conséquence (0 dans ce cas).

EDIT : Pour que l’hôte retrouve un accès au réseau :
# Hôte
ip link add name vpp1out type veth peer name vpp1host
ip link set dev vpp1out up
ip link set dev vpp1host up
ip addr add 10.10.1.1/24 dev vpp1host

# VPP
create host-interface name vpp1out
set int state host-vpp1out up
set int ip address host-vpp1out 10.10.1.2/24

# Hôte
ip route add default via 10.10.1.2

Ne pas oublier de rajouter la route sur le routeur principal (ou faire du NAT en sortie de VPP)
Titre: Test du MAP-T et MAP-E en LAB
Posté par: renaud07 le 17 février 2024 à 16:25:06
Petite question python : j'essaie depuis hier de faire pondre à chatGPT un script pour calculer l'ipv4 public et les ports, sauf que je n'arrive à rien. J'ai fait une dizaine d'essais avec différents prompts, mais y'a toujours une erreur quelque part, de fonction non supportée ou de valeur incohérente, même en lui précisant la version de python. À chaque fois que je lui soumet sa propre erreur, une autre apparaît et ça n'en fini pas. La seule fois où j'ai eu un résultat, c'était totalement incohérent.

Mon niveau en dev étant très proche de 0, je suis bien incapable de déboguer ça tout seul. La seule chose qu'il me fait bien c'est d'avoir une belle ligne de commande avec les arguments à passer, ainsi qu'un joli code commenté, mais qui ne fonctionne pas  :P

Voici sa dernière proposition, car évidemment, le même prompt me ressort un code différent à chaque fois sinon c'est pas drôle...

Merci d'avance
Titre: Test du MAP-T et MAP-E en LAB
Posté par: Cochonou le 18 février 2024 à 10:52:24
En gros c'est ça qu'il faut implémenter ?
https://datatracker.ietf.org/doc/html/rfc7599#appendix-A

Titre: Test du MAP-T et MAP-E en LAB
Posté par: renaud07 le 18 février 2024 à 14:28:21
Exactement. Si ça à l'air plutôt simple en apparence...

Je voulais aussi rajouter l'IPv6 du CE, mais quand j'ai vu comment il me générait ça, j'ai laissé tomber cette partie.

J'ai retenté en lui donnant l'exemple directement, mais toujours pas.
Titre: Test du MAP-T et MAP-E en LAB
Posté par: renaud07 le 19 février 2024 à 17:42:37
Après d'autres essais, je crois que je tiens un script plus fonctionnel, mais j'ai une erreur d'utilisation avec split(), qu n'est pas utilisé correctement, et j'ai beau regarder des exemples sur le net, je ne comprends pas comment corriger la chose sur le code. Et chatGPT me propose une correction qui ne fonctionne pas et que je trouve bizarre.

Je sens qu'il manque pas grand chose, mais y'a toujours un petit truc qui coince. Je n'ai pas vérifié les variables de calcul, c'est peut-être pas bon non plus, mais pour ça faudrait déjà que je puisse l'exécuter.

L'erreur en question :
File "mapports6.py", line 151, in <module>
    print("Ports disponibles :", calculate_available_ports(bmr["ipv4_prefix"], ipv4_address, psid))
  File "mapports6.py", line 90, in calculate_available_ports
    ipv4_suffix = ipv4_to_bin(ipv4_address)[32-p:]
  File "mapports6.py", line 39, in ipv4_to_bin
    octets = ipv4.split(".")
AttributeError: 'function' object has no attribute 'split'
Titre: Test du MAP-T et MAP-E en LAB
Posté par: kgersen le 21 février 2024 à 23:50:56
chat-gpt pour coder ... mouais. c'est un LLM , un "compléteur" de texte, rien de plus.

ca marche en démo sur des exemples simples et triviaux pour attirer les financements et faire du médiatique et peur aux gens... sur du vrai code ce n'est pas la meme histoire.

En regardant rapido, ton fichier est plein de bugs. On peut tenter de les corriger pour qu'il ne plante plus mais ca ne garantira forcement pas le résultat

il vaut mieux peut-etre poser 'les formules en francais" et construire le code à partir de la  ?

sinon utiliser Gemini (le GPT de Google) et lui demander EN ANGLAIS:
"python code to calculate IPv6 MAP-T and MAP-E parameters"

la il te répond qu'il existe une lib python pour cela (https://github.com/ejordangottlieb/pyswmap) et il te donne un exemple:


from pyswmap import MapCalc

# Configure parameters
rule_v6 = "fd80::/48"  # IPv6 rule prefix
rule_v4 = "24.50.100.0/24"  # IPv4 rule prefix
port_value = 40000  # Layer-4 port

# Create MapCalc object
map_calc = MapCalc(rulev6=rule_v6, rulev4=rule_v4)

# Calculate PSID
psid = map_calc.gen_psid(port_value)

# Get other information
originating_prefix = map_calc.get_originating_prefix(port_value)
map_address = map_calc.get_map_address(port_value)

print(f"PSID: {psid}")
print(f"Originating IPv6 prefix: {originating_prefix}")
print(f"MAP address: {map_address}")

mais en regardant dans le repo, y'a plein d'exemples:
git clone https://github.com/ejordangottlieb/pyswmap
cd pyswmap/examples
tu as plein d'exemples la dedans.
Titre: Test du MAP-T et MAP-E en LAB
Posté par: renaud07 le 22 février 2024 à 00:41:43
Mais quel abruti je suis... Faudrait me mettre des claques des fois.

J'ai trouvé ce projet en faisant mes recherches (que j'ai suggéré ici (https://lafibre.info/remplacer-freebox/supprimer-une-mini-4k-avec-boitier-ontv2-en-zmd-probleme-dauthentification/msg1056920/#msg1056920) quelques jours avant), mais lorsque j'essayais de tirer quelque chose de ce c*n de chatGPT, tu crois que j'y ai pensé ? Pas une seule seconde.

Heureusement que t'es là pour me le rappeler  ;)



Titre: Test du MAP-T et MAP-E en LAB
Posté par: renaud07 le 22 février 2024 à 02:13:15
Et ben franchement, il manque pas grand chose pour que ce soit nickel.

listmapaddresses.py qui calcule tous les préfixes, se suffit presque à lui-même. Juste à rajouter un petit grep derrière pour filtrer son préfixe délégué et on a déjà l'IP publique et le PSID (ce qui bien l'info importante pour une conf statique).

Le petit truc qui manque c'est l'affichage du ou des ranges de ports (comme le simulateur de cisco) et non l'ensemble. En plus dans le terminal, ça fait un affichage bizarre qui coupe les lignes, à moins de l'exporter dans un fichier.
Titre: Test du MAP-T et MAP-E en LAB
Posté par: renaud07 le 22 février 2024 à 11:03:18
sinon utiliser Gemini (le GPT de Google) et lui demander EN ANGLAIS:
"python code to calculate IPv6 MAP-T and MAP-E parameters"

la il te répond qu'il existe une lib python pour cela (https://github.com/ejordangottlieb/pyswmap) et il te donne un exemple:

J'ai voulu tester par curiosité, mais pas moyen d'y accéder. Il me dit que mon compte n'est pas compatible, mais je ne suis dans aucun des cas bloquant décrit dans l'aide. Encore un truc bien foutu...
Titre: Test du MAP-T et MAP-E en LAB
Posté par: kgersen le 22 février 2024 à 14:14:50
Et ben franchement, il manque pas grand chose pour que ce soit nickel.

listmapaddresses.py qui calcule tous les préfixes, se suffit presque à lui-même. Juste à rajouter un petit grep derrière pour filtrer son préfixe délégué et on a déjà l'IP publique et le PSID (ce qui bien l'info importante pour une conf statique).

Le petit truc qui manque c'est l'affichage du ou des ranges de ports (comme le simulateur de cisco) et non l'ensemble. En plus dans le terminal, ça fait un affichage bizarre qui coupe les lignes, à moins de l'exporter dans un fichier.

la boucle d'affichage de listmapaddresses.py (listaddr.py plutot c'est le meme mais en passant les parametres) est simple a modifier. tu veux quel format de sortie ?
si ton terminal coupe les lignes trop longues , ca se règle aussi.

Titre: Test du MAP-T et MAP-E en LAB
Posté par: renaud07 le 22 février 2024 à 16:20:25
Le format inchangé si on entre rien. Et les ports en plus si on spécifie un préfixe particulier (-pfx) avec une présentation un peu plus lisible, ex :

Sans offset :
User prefix: 2001:db8:0:3fc0::/60 
MAP address: 2001:db8:0:3fc0:0:5ba0:ff:0 
PSID: 0
IPv4: 91.160.0.255
Reserved ports: None
Available ports (1 range): 0-16384

Ou avec offset (ici 2) :
User prefix: 2001:db8:0:3fc0::/60 
MAP address: 2001:db8:0:3fc0:0:5ba0:ff:0 
PSID: 0
IPv4: 91.160.0.255
Reserved ports: 0-4095
Available ports (3 ranges): 16384-20479, 32768-36863, 49152-53247

Tu me dis si je t'en demande trop  ;)

Et merci encore.
Titre: Test du MAP-T et MAP-E en LAB
Posté par: kgersen le 25 février 2024 à 21:56:08
m'en faut un peu plus niveau explication...

ce résultat
User prefix: 2001:db8:0:3fc0::/60
MAP address: 2001:db8:0:3fc0:0:5ba0:ff:0
PSID: 0
IPv4: 91.160.0.255
Reserved ports: None
Available ports (1 range): 0-16384

serait avec quels paramètres en entrée ?




Titre: Test du MAP-T et MAP-E en LAB
Posté par: renaud07 le 26 février 2024 à 22:37:55
Ah... je pensais que t'avais saisi.

Je parle de la règle dans le script directement, sauf qu'on spécifie en plus le /60 (ou autre) qu'on veut en particulier comme argument :
m = MapCalc( rulev6='2001:db8::/50',
             rulev4='91.160.0.0/24',
             #psidoffset=6,
             ratio=4,
             ealen=10,
                   )

Et l'autre avec l'offset dé-commenté.

Mais je me demande si c'est pas plus simple de tout mettre en argument, plutôt que de modifier le script à chaque fois et faire (ou simplifié sans les options -v6 -v4...) :
listmapaddresses.py -v6 2001:db8::/50 -v4 91.160.0.0/24 -off 0 -ratio 4 -ea 10
Ce qui donne :
User prefix: 2001:db8::/60  MAP address: 2a01:e0a::5ba0:0:0  PSID: 0 IPv4: 91.160.0.0
User prefix: 2001:db8:0:10::/60  MAP address: 2a01:e0a:0:10:0:5ba0:0:1  PSID: 1 IPv4: 91.160.0.0
User prefix: 2001:db8:0:20::/60  MAP address: 2a01:e0a:0:20:0:5ba0:0:2  PSID: 2 IPv4: 91.160.0.0
User prefix: 2001:db8:0:30::/60  MAP address: 2a01:e0a:0:30:0:5ba0:0:3  PSID: 3 IPv4: 91.160.0.0
User prefix: 2001:db8:0:40::/60  MAP address: 2a01:e0a:0:40:0:5ba0:1:0  PSID: 0 IPv4: 91.160.0.1
User prefix: 2001:db8:0:50::/60  MAP address: 2a01:e0a:0:50:0:5ba0:1:1  PSID: 1 IPv4: 91.160.0.1
User prefix: 2001:db8:0:60::/60  MAP address: 2a01:e0a:0:60:0:5ba0:1:2  PSID: 2 IPv4: 91.160.0.1
User prefix: 2001:db8:0:70::/60  MAP address: 2a01:e0a:0:70:0:5ba0:1:3  PSID: 3 IPv4: 91.160.0.1
...

Et listmapaddresses.py -v6 2a01:e0a::/50 -v4 91.160.0.0/24 -off 0 -ratio 4 -ea 10 -pd 2001:db8:0:3fc0::/60User prefix: 2001:db8:0:3fc0::/60
MAP address: 2001:db8:0:3fc0:0:5ba0:ff:0
PSID: 0
IPv4: 91.160.0.255
Reserved ports: None
Available ports (1 range): 0-16384
Titre: Test du MAP-T et MAP-E en LAB
Posté par: kgersen le 28 février 2024 à 12:32:42
"Reserved ports" je ne vois pas dans la lib ou c'est.
sinon ca donne un truc du genre (vire fait, pas propre mais ca devrait marcher):

#!/usr/bin/env python
import sys
import argparse

sys.path.append("..")

from pyswmap import MapCalc


parser=argparse.ArgumentParser(description="MapCalc")
parser.add_argument("-v6")
parser.add_argument("-v4")
parser.add_argument("-ratio",type=int)
parser.add_argument("-ea",type=int)
parser.add_argument("-off",type=int)
parser.add_argument("-pd")
args=parser.parse_args()

# This prints out a list of all possible MAP end-user IPv6 prefixes,
# applicable MAP IPv6 addresses, and PSIDs for a particular domain.
# PSID will always equal 0 for a sharing ratio of 1:1.  This script is
# allows the entering in of the mapping rule via the command line but is
# otherwise the same as listmapaddresses.py.


# Define MAP domain characteristics.  The values may be changed to suite
# a alternate MAP domain configurations.

m = MapCalc(
    rulev6=args.v6,
    rulev4=args.v4,
    psidoffset=args.off,
    ratio=args.ratio,
    ealen=args.ea,
)

# print contiguous ranges in a list of ordered integers
def print_ranges(l):
  if not l:
    print("no range!")
    return

  first = l[0]
  curr = first

  for n in l[1:]:
    if n != curr + 1:
      print("{}-{}, ".format(first,curr),end="")
      first = n
    curr = n
  print("{}-{}".format(first,curr))



# The attribute rulev4object is the object returned for a particular
# instance of the ip_address class from module Python ipaddress.
for y in range(m.rulev4object.num_addresses):
    for w in range(2**m.psidbits):
        mapce = m.get_mapce_addr(m.rulev4object[y], w)
        pd = m.get_mapce_prefix(m.rulev4object[y], w)
        if args.pd is None:
            print(
                "User prefix: {}  MAP address: {}  PSID: {} IPv4: {}".format(
                    pd,
                    mapce,
                    w,
                    m.get_map_ipv4(mapce),
                )
            )
        if args.pd == pd:
            print(
                "User prefix: {}\nMAP address: {}\nPSID: {}\nIPv4: {}".format(
                    pd,
                    mapce,
                    w,
                    m.get_map_ipv4(mapce),
                )
            )
            print("reversed ports: {}\nAvailable ports ({} range): ".format(
                    "todo",
                    m.port_ranges(),
                ),end=""
            )
            print_ranges(m.port_list(w))

Titre: Test du MAP-T et MAP-E en LAB
Posté par: renaud07 le 28 février 2024 à 15:05:49
Merci beaucoup, ça marche nickel  :)

Pour les ports réservés, je ne crois pas que ça soit dedans non plus. C'est pas bien grave.

Y'aurait juste un petit truc à ajouter : c'est que ea length ou le ratio soit en option (vu que l'un découle de l'autre) comme le script de base.
Titre: Test du MAP-T et MAP-E en LAB
Posté par: kgersen le 28 février 2024 à 19:54:37
Y'aurait juste un petit truc à ajouter : c'est que ea length ou le ratio soit en option (vu que l'un découle de l'autre) comme le script de base.

on peut modifier de façon a passer directement les arguments de la ligne de commande a  MapCalc.

par contre on doit utiliser exactement les mêmes noms que MapCalc attend donc:

python3 listaddr.py  -rulev6 2a01:e0a::/50 -rulev4 91.160.0.0/24 -psidoffset 0 -ratio 4 -ealen 10avec argparse.SUPPRESS sur ratio et ealen on peut ignorer l'un ou l'autre (si on ignore les 2, MapCalc générera une erreur).

voici la nouvelle version de listaddr.py:
#!/usr/bin/env python
import sys
import argparse

sys.path.append("..")

from pyswmap import MapCalc


parser=argparse.ArgumentParser(description="MapCalc")
parser.add_argument("-rulev6")
parser.add_argument("-rulev4")
parser.add_argument("-ratio",type=int,default=argparse.SUPPRESS)
parser.add_argument("-ealen",type=int,default=argparse.SUPPRESS)
parser.add_argument("-psidoffset",type=int)
parser.add_argument("-pd")
args=parser.parse_args()

# Define MAP domain characteristics.  The values may be changed to suite
# a alternate MAP domain configurations.

m = MapCalc(**vars(args))

# print contiguous ranges in a list of ordered integers
def print_ranges(l):
  if not l:
    print("no range!")
    return

  first = l[0]
  curr = first

  for n in l[1:]:
    if n != curr + 1:
      print("{}-{}, ".format(first,curr),end="")
      first = n
    curr = n
  print("{}-{}".format(first,curr))



# The attribute rulev4object is the object returned for a particular
# instance of the ip_address class from module Python ipaddress.
for y in range(m.rulev4object.num_addresses):
    for w in range(2**m.psidbits):
        mapce = m.get_mapce_addr(m.rulev4object[y], w)
        pd = m.get_mapce_prefix(m.rulev4object[y], w)
        if args.pd is None:
            print(
                "User prefix: {}  MAP address: {}  PSID: {} IPv4: {}".format(
                    pd,
                    mapce,
                    w,
                    m.get_map_ipv4(mapce),
                )
            )
        if args.pd == pd:
            print(
                "User prefix: {}\nMAP address: {}\nPSID: {}\nIPv4: {}".format(
                    pd,
                    mapce,
                    w,
                    m.get_map_ipv4(mapce),
                )
            )
            print("reversed ports: {}\nAvailable ports ({} range): ".format(
                    "todo",
                    m.port_ranges(),
                ),end=""
            )
            print_ranges(m.port_list(w))
Titre: Test du MAP-T et MAP-E en LAB
Posté par: kgersen le 28 février 2024 à 20:04:52
ps: j'ai forké le projet sur github , mes modifs sont dispo directement labas

fichier direct: https://github.com/kgersen/pyswmap/blob/master/examples/listaddr.py

ou

git clone https://github.com/kgersen/pyswmap.git
cd pyswmap/examples
python3 listaddr.py ...
Titre: Test du MAP-T et MAP-E en LAB
Posté par: renaud07 le 28 février 2024 à 23:55:14
Bonne idée le fork pour que ça profite à tout le monde, franchement c'est nickel.

Encore merci, ça fonctionne au poil  ;)