Les clients arrivent !
Un backbone d'un OC a 2 grandes missions :
- Accès à Internet
- Collecter les liens des OI
Les premiers épisodes avaient pour but final Internet ! Maintenant place à la partie collecte.
Comme on l'a vu dans le premier épisode, l'OC ne possède pas le niveau 1. Orange / Covage / Bytel / IELO / Appliwave sont des OI. Ce sont eux qui tirent la fibre jusqu'au client final.
Mais comment on va faire pour avoir des clients si on possède pas le niveau 1 ?
Et bah on va s'interconnecter avec un OI en niveau 2 ou niveau 3.
Pour la collecte L2, l'OI va nous livrer le client sur un VLAN. Un VLAN = un client (bon OK sauf pour les collectes C2E et Optimum Collecte d'Orange).
Pour la collecte L3, on va avoir une interco IP qui va servir à monter un tunnel L2TP avec l'OI. Ce tunnel va permettre d'encapsuler du niveau 2 (PPP ?) dans du niveau 3. En l'occurrence, faire passer du PPP à travers le réseau IP de l'OI.
De mon point de vue, je DETESTE la collecte L3. Beaucoup trop chiant à monter et surtout pour un projet que j'ai. Monter un tunnel L2TP irait à l'encontre de ce que je veux faire (je vais pas vous spoil 😄).
Qui dit niveau 2 dit.............switch. Exact ! On va brancher un câble avec le réseau Covage (par exemple) et un de nos switchs.
On appelle ça une porte de collecte. Et ca donne quoi dans notre infrastructure ?
Le switch Collecte_L2 est branché sur un Leaf en B1 et un autre en B2. Pourquoi sur deux ? Pour la redondance (mais attention à la boucle ! On peut commander une porte de collecte en actif/passif. Dans mon cas, je simule l'actif/passif en shutant mon port sur Leaf3-B2).
OK, on s'est interconnecté avec un OI. Mais maintenant, comment on interconnecte nos CPE avec notre backbone ? On a juste besoin que notre CPE ait une IP publique (enfin qu'il arrive à NATTER sur une IP publique).
Plusieurs solutions possibles, allez ca va dérouler !
La plus dégelasse !
On pourrait monter pour chaque CPE, une interco IP avec lui et nos LNS et ensuite router une IP publique sur ce segment.
Allez, pour un client OK, deux clients OK mais pour des centaines.... Misère
On pourrait optimiser un peu avec un protocole de routage dynamique mais bon, à quoi bon ?
DHCP
Le DHCP est un protocole qui permet d'allouer dynamiquement des IPs à des clients. Connu pour être utilisé dans le LAN, beaucoup d'opérateurs l'utilisent pour les CPE que ce soit en BtoB qu'en BtoC.
Bon c'est déjà un peu plus propre nan ? J'ai mis sur le schéma un DHCP relay (permet de router les échanges broadcast DHCP à travers un routeur). Il n'est pas essentiel. On peut très bien acheminer le VLAN client jusqu'au DHCP et créer une sous interface 802.1q sur le linux.
Plus aucune configuration sur le routeur, les seuls ajouts vont être poussés sur le linux, en utilisant une API ? Imaginer un simple serveur web apache avec un PHP qui pousse un script utilisant une RESTAPI pour aller PUT un nouveau client ?
Ca fait rêver ! Mais on va pas utiliser ça (quoique, pas pour ma première collecte !).
PPP
Et oui, on va utiliser ce bon vieux protocole. Sa RFC a été écrite en Juillet 1994 et n'est pas obsolète ! 30 ans de loyaux services et il n'est pas prêt de disparaître.
Au delà du fait que le PPP permet d'attribuer une IP, il permet aussi tout pleins de choses !
Déjà le AAA (Authentication Authorization Accouting). Le client doit s'authentifier, doit avoir les droits et toutes ses sessions sont log. Idéal nan ? En un clin d'œil, on peut voir quelle session cliente est KO.
On peut router un pool d'IP avec le champ framed-routes, de la délagation de préfixe IPv6 est dispo,etc. Enfin bref, beaucoup d'options sont possibles ce qui fait de lui un protocole répandu et très utilisé.
Comme vous l'avez, je pense, compris, ma première collecte L2 sera en PPP 😃
Configuration Porte de collecte
VXLAN permet d'avoir jusqu'à 16 millions de VNI mais un switch en local ne peut contenir que 4096 VLANs.
Si un client = un VLAN et qu'on ait plusieurs portes de collectes sur le même Leaf, on va avoir des recouvrements de VLAN.
Comment résoudre ce problème ?
On va utiliser de la QinQ ! C'est quoi le principe ? On encapsule un VLAN dans un autre VLAN.
Deux termes importants : le OUTER VLAN (Super VLAN / VLAN de transport / SVLAN) et le INNER VLAN (Client VLAN / CVLAN).
La configuration est vraiment trop simple :
Leaf1-B1#sh run int eth2
interface Ethernet2
description COLLECTE_COVAGE_L2
switchport access vlan 500
switchport mode dot1q-tunnel
spanning-tree bpdufilter enable
On place le port en mode dot1q-tunnel et on lui dit que le vlan 500 est notre SVLAN. Bien sûr, pour pas faire chier l'OI, on active le bdpufilter du spanning-tree sur le port (il va pas émettre de trames spanning-tree). Bon normalement, vu qu'il est desactivé, la commande ne sert à rien mais on est jamais trop sûr !
Leaf1-B1#sh run int eth5
interface Ethernet5
description IN_LNS1
switchport trunk allowed vlan 500
switchport mode trunk
channel-group 20 mode active
Leaf1-B1#sh run int po20
interface Port-Channel20
description PO_IN_LNS1
switchport trunk allowed vlan 500
switchport mode trunk
mlag 20
Ensuite, on achemine le SVLAN jusqu'au LNS. On utilise toujours le MLAG (donc il faut monter le même côté Leaf2-B1).
En mettant toute cette configuration, on a aucun visu sur le CVLAN au niveau de la porte de collecte ! Tous les CVLANs de la porte de collecte seront encapsulé dans le SVLAN 500.
Bon allez maintenant, place aux LNS.
Configuration LNS
Petit changement de la topologie malheureusement ! On ne peut pas faire de QinQ sur des interfaces Etherchannel L3 sur les vCSR. On va placer un switch entre les Leaf et les LNS sur sa patte IN. (C'est pas beau, idéalement, je voulais accuellir le SVLAN directement sur le PO en MLAG). Mais bon, pas le choix !
LNS1#sh run interface GigabitEthernet1
interface GigabitEthernet1
description IN_LEAF
mtu 9214
no ip address
negotiation auto
no mop enabled
no mop sysid
end
LNS1#sh run interface GigabitEthernet1.500
interface GigabitEthernet1.500
description COLLECTE_COVAGE_L2
encapsulation dot1Q 500 second-dot1q any
pppoe enable group global
end
On crée une sous interface dot1q avec comme premier VLAN notre ID de SVLAN (500) et ensuite un second-dot1q où on va préciser any. Ca signifie que tous les CVLANs transportés par le SVLAN 500 matcheront avec cette interface.
Le pppoe enable group global permet de placer cette interface en PPP. Ensuite, il faut lier le groupe pppoe global à une interface-template. Et on va préciser, la méthode d'authentification (PAP ou CHAP), la MTU et le pool d'IP réservées pour les clients. Pour finir, on crée un utilisateur pour notre client.
LNS1#sh run | s bba
bba-group pppoe global
virtual-template 1
LNS1#sh run int virtual-template 1
interface Virtual-Template1
mtu 1492
ip unnumbered Loopback2
peer default ip address pool TEST
ppp authentication chap
end
LNS1#sh run | s TEST
ip local pool TEST 109.205.64.50 109.205.64.100
LNS1#sh run int lo2
interface Loopback2
ip address 109.205.64.1 255.255.255.255
end
LNS1#sh run | i nathan
username nathan password 0 nathan
C'était pas bien compliqué ?
Et du côté de nos CPE, ca donne quoi ?
Configuration CPE Mikrotik / Cisco
On commence par les mikrotik et bordel, que c'est simple !
[admin@MikroTik] > /interface/pppoe-client/ add add-default-route=yes disabled=no interface=ether1 name=test service-name=Internet user=nathan password=nathan
[admin@MikroTik] > export
/interface pppoe-client
add add-default-route=yes disabled=no interface=ether1 name=test \
service-name=internet user=nathan
[admin@MikroTik] /ip/address> print
Flags: D - DYNAMIC
Columns: ADDRESS, NETWORK, INTERFACE
# ADDRESS NETWORK INTERFACE
0 D 109.205.64.50/32 109.205.64.1 test
Notre CPE récupère l'IP 109.205.64.50. Si tout est bon, le CPE devrait pouvoir joindre internet :
[admin@MikroTik] /ip/address> /ping 1.1.1.1
SEQ HOST SIZE TTL TIME STATUS
0 1.1.1.1 56 252 277ms984us
1 1.1.1.1 56 252 21ms838us
2 1.1.1.1 56 252 20ms831us
sent=3 received=3 packet-loss=0% min-rtt=20ms831us avg-rtt=106ms884us
max-rtt=277ms984us
YES ! Enfin notre business commence ?
Du côté LNS, on peut afficher les sessions actives avec la commande show subscriber session :
LNS1#sh subscriber session
Codes: Lterm - Local Term, Fwd - forwarded, unauth - unathenticated, authen -
authenticated, TC Ct. - Number of Traffic Classes on the main session
Current Subscriber Information: Total sessions 1
Uniq ID Interface State Service Up-time TC Ct. Identifier
1 Vi2.1 authen Lterm 00:00:45 0 nathan
On peut aussi voir le nombre de paquets, d'octets émis par le client :
LNS1#sh subscriber session username nathan detailed
Type: PPPoE, UID: 1, State: authen, Identity: nathan
IPv4 Address: 109.205.64.50
IPv6 Address: 2001:ABCD::
Session Up-time: 00:08:11, Last Changed: 00:08:11
Interface: Virtual-Access2.1
Switch-ID: 4097
Policy information:
Context 7F6E02216550: Handle 02000001
AAA_id 0000000C: Flow_handle 0
Authentication status: authen
Classifiers:
Class-id Dir Packets Bytes Pri. Definition
0 In 126 5566 0 Match Any
1 Out 61 1558 0 Match Any
Configuration Sources:
Type Active Time AAA Service ID Name
INT 00:08:11 - Virtual-Template1
Plutôt pas mal le PPP nan ?
Et du côté de Cisco, ça donne ça :
Router#sh run int gi1
interface GigabitEthernet1
no ip address
negotiation auto
pppoe enable group global
pppoe-client dial-pool-number 1
no mop enabled
no mop sysid
end
Router#sh run int dialer 1
interface Dialer1
ip address negotiated
encapsulation ppp
dialer pool 1
ppp authentication chap callin
ppp chap hostname test
ppp chap password 0 test
end
Je ne vais pas détailler la configuration des Cisco. C'est juste pour donner un comparatif avec le constructeur le plus répandu sur le marché.
Wireshark
Et ca donne quoi dans les trames ?
Le PPP est assez similaire au DHCP, d'abord un PADI :
Le CPE envoie un broadcast sur son segment pour découvrir un serveur PPP. On peut retrouver le max payload (05d4) qui correspond à la MTU de 1492.
Une fois la découverte du LNS, ce dernier renvoie une offre PPP, le PADO :
Le LNS répond au CPE pour lui dire : Oui je suis là, je suis serveur PPP. Le LNS renvoie la MTU maximum aussi (1492), son AC-Name et un cookie.
Le client renvoie un PADR :
Le client répond pour lui dire OK, je te choisis, je veux bien avoir une session avec toi, mon serveur PPP.
Enfin, un PADS délivré par le LNS :
La session est initialisé entre les deux. On retrouve le session ID, qui sera utilisé lors des autres échanges entre le CPE et le LNS.
Mais où se trouve l'IP délivrée par le LNS ?
Pas si vite ! Avant, ils doivent se mettre d'accord sur quelle algorithme ils utilisent pour l'username et le mot de passe !
C'est dans un Configuration Request émise par le LNS :
Et un ack par le CPE :
On y retrouve bien le CHAP with MD5 qui signifie que le client, en l'occurrence, le CPE, va utiliser du CHAP avec du MD5.
Ensuite, à la méthode d'un 3 way Handshake, ils partagent le mot de passe de la session PPP (le mot de passe qu'on a définit pour l'username nathan).
Ici, l'authentification est unidirectionnelle. Mais dans certains cas, l'authentification peut être bidirectionnelle (honnêtement je ne vois pas l'utilité). Il faut savoir que sur mikrotik, l'authentification est par défaut unidirectionnelle mais sur un Cisco, il faut renseigner l'option callin dans le chap.
Une fois tous ces échanges finis, le LNS peut enfin proposer une configuration dans une trame request :
Comme d'habitude, on retrouve bien le session ID qui est resté le même. Le client répond avec un ack.
Et béh ! Enfin fini 😄
LNS1#sh pppoe session
1 session in LOCALLY_TERMINATED (PTA) State
1 session total
Uniq ID PPPoE RemMAC Port VT VA State
SID LocMAC VA-st Type
2 2 5000.000b.0000 Gi1.500 1 Vi2.2 PTA
5000.000d.0000 VLAN: 500/1001 UP
On retrouve bien l'adresse MAC du CPE sur notre LNS.
Le dernier échange qu'on peut trouver est un PADT. Il signifie que la session PPP est terminée. On peut la simuler en faisant un clear de la session sur le LNS
LNS1#clear subscriber session username nathan
Je sais pas si vous avez vu dans les trames les CVLAN et les SVLAN ?
On voit bien le SVLAN 500. Et dans ce VLAN est présent le CVLAN (ici 1001). Le CVLAN est donné par l'OI. Quoique, de mémoire, je crois que certains OI donnent la possibilité de choisir le CVLAN.
Améliorations
Si vous avez bien lu, j'ai parlé de la possibilité d'ajouter des champs framed-routes et tout plein de choses avec le PPP. Dans la configuration mise en place, tout sur le LNS, on peut pas !
On va donc utiliser un radius (serveur d'authentification). On va lier ce serveur à notre LNS pour que toutes les requêtes PPP arrive sur le radius.
Et dans le fichier de conf des users dans le radius, on va pouvoir renseigner ces fameux champs !!
Pour l'instant, j'ai deux sujets chaud qui vient : la collecte des liens tiers et le début de l'automatisation de la fabric.
Allez, prochain épisode, on parle de la collecte 4G / Starlink et notre VRF VOIP.
Je termine sur un petit mot de fin : Boruto, mais qu'il est bon ce poulet