Nouvelle version MK !
Avec la nouvelle version v7.20, Mikrotik a release l'EVPN ! Bien qu'encore en beta, il est toujours intéressant de regarder les différentes alternatives sur le marché. Mikrotik a un gros avantage par rapport aux autres concurrents : le prix et le fait que la syntaxe soit très très très proche d'un linux 😄
Je compte quand même partir de l'Arista pour ma fabric. Ils ont développé leur matériel pour répondre à ces besoins précis mais pour mes PE, c'est une autre histoire.
Je souhaiterai avoir 4 ports 10G (Double LACP, un pour la collecte, l'autre pour le MPLS). Avec Cisco, je devrai partir sur de l'ASR-1001HX (bon sang le prix de plusieurs milliers d'euros). Avec Mikrotik ? Des beaux CCR2116-12G-4S+ qui coûte 700 euros. Le choix est vite vu, n'est ce pas ?
Donc quitte à changer mes PE, autant me baser sur la v7.20 pour voir ce que ca donne un full core Mikrotik !
Configuration Fabric EVPN/VXLAN
Underlay
On utilise cette architecture :
Je ne sais pas si vous vous en souvenez mais je m'étais basé sur un underlay et overlay en eBGP, le tout uniquement en IPv6.
On va réutiliser le même principe sauf que l'OSPF va jouer le rôle de l'underlay 😄 Je suis dans une petite fabric (>10) donc ce bon vieil ami ferait l'affaire ! Et ca permet de voir d'autre façon de faire.
Par contre, on reste dans le même schéma des IPv6 linklocal. Les adjacences OSPF vont monter de façon dynamique avec les fe80::/10.
#SPINE1
/routing bfd configuration
add interfaces=ether1,ether2,ether3,ether4
/routing ospf instance
add disabled=no name=Instance_Underlay router-id=100.127.0.1 version=3
/routing ospf area
add disabled=no instance=Instance_Underlay name=Area_Underlay
/routing ospf interface-template
add area=Area_Underlay disabled=no interfaces=lo passive
add area=Area_Underlay disabled=no interfaces=ether1,ether2,ether3,ether4 use-bfd=yes
C'est vrai que c'est une syntaxe bien particulière mais c'est assez simple à comprendre ! Tout d'abord, on crée une instance OSPF avec dedans la version utilisée, le nom et le router-id.
Ensuite, on crée l'aire (dans mon cas, c'est l'area 0) et on la lie à l'instance. Pour finir, on place les interfaces dans l'OSPF et l'affaire est dans le sac.
Je me suis permis de mettre en place du BFD. C'est un check agressif du neighbor d'en face, il va envoyer des requêtes toutes les x ms. Si un lien tombe, le voisin tombera aussitôt. Cela permet de gagner un peu de temps dans la convergence.
Côté Leaf, cela donne ça :
#LEAF1
/routing bfd configuration
add interfaces=ether1,ether2
/routing ospf instance
add disabled=no name=Instance_Underlay router-id=100.127.0.11 version=3
/routing ospf area
add disabled=no instance=Instance_Underlay name=Area_Underlay
/routing ospf interface-template
add area=Area_Underlay disabled=no interfaces=lo passive
add area=Area_Underlay disabled=no interfaces=ether1,ether2 use-bfd=yes
Les neighbors sont bien montés :
[admin@Leaf1] /routing/ospf/neighbor> pr
Flags: V - virtual; D - dynamic
0 D instance=Instance_Underlay area=Area_Underlay address=fe80::5200:ff:fe25:0%ether2 priority=128 router-id=100.127.0.2 dr=100.127.0.2
bdr=100.127.0.11 state="Full" state-changes=6 adjacency=28m35s timeout=35s
1 D instance=Instance_Underlay area=Area_Underlay address=fe80::5200:ff:fe24:0%ether1 priority=128 router-id=100.127.0.1 dr=100.127.0.1
bdr=100.127.0.11 state="Full" state-changes=6 adjacency=28m35s timeout=35s
Et j'apprends bien les loopbacks des autre switch dans la fabric (oui je n'ai pas branché Leaf2 et Leaf4) :
[admin@Leaf1] /ipv6/route> pr
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, o - OSPF; + - ECMP
Columns: DST-ADDRESS, GATEWAY, ROUTING-TABLE, DISTANCE
DST-ADDRESS GATEWAY ROUTING-TABLE DISTANCE
DAc fe80::/64 ether1 main 0
DAc fe80::/64 ether2 main 0
DAc fe80::/64 ether3 main 0
DAc fe80::/64 ether4 main 0
DAc fe80::/64 ether5 main 0
DAc fe80::/64 bridge main 0
DAc fe80::/64 Collecte_L2 main 0
DAc ::1/128 lo main 0
D o ::1/128 fe80::5200:ff:fe25:0%ether2 main 110
DAo 2001:100:127::1/128 fe80::5200:ff:fe24:0%ether1 main 110
DAo 2001:100:127::2/128 fe80::5200:ff:fe25:0%ether2 main 110
DAc 2001:100:127::11/128 lo main 0
DAo+ 2001:100:127::13/128 fe80::5200:ff:fe25:0%ether2 main 110
DAo+ 2001:100:127::13/128 fe80::5200:ff:fe24:0%ether1 main 110
L'underlay est bien configuré. Place à l'overlay en eBGP.
Overlay
Chaque Leaf possède sa propre AS tandis que tous les Spines ont la même. On part en mode écoute sur les Spines :
#SPINE1
/routing bgp instance
add as=65000 disabled=no name=Fabric router-id=100.127.0.1
/routing bgp template
add afi=evpn multihop=yes name=TPL_Overlay nexthop-choice=propagate
/routing bgp connection
add instance=Fabric local.address=2001:100:127::1 .role=ebgp name=Leafs_Overlay remote.address=2001:100:127::/64 templates=TPL_Overlay
On crée notre instance BGP avec le router-id et l'AS. Ensuite, afin de ne pas trop surchager la configuration du peer, j'ai crée une template qu'appelle l'afi et le multihop. Pour finir, place à la configure du BGP listent range sur mikrotik. Il s'agit d'un subnet en remote.address.
Ainsi, quand les Leafs vont émettre une trame BGP avec en source IP, leur IP loopback (dans 2001:100:127::/64), le Spine va automatiquement les monter dans ce peering.
Et je ne sais pas si vous avez vu mais pas besoin de renseigner la remote AS dans Mikrotik. Ce dernier se base sur l'AS reçu dans le BGP open 😄
Et sur les Leafs, ca donne ça :
#LEAF1
/routing bgp instance
add as=65001 disabled=no name=Fabric router-id=100.127.0.11
/routing bgp connection
add afi=evpn instance=Fabric local.address=2001:100:127::11 .role=ebgp multihop=yes name=Overlay_Spine1 remote.address=2001:100:127::1
add afi=evpn instance=Fabric local.address=2001:100:127::11 .role=ebgp multihop=yes name=Overlay_Spine2 remote.address=2001:100:127::2
Mes sessions BGP EVPN sont bien montées :
#LEAF1
[admin@Leaf1] /routing/bgp/session> pr
Flags: E - established
0 E name="Overlay_Spine1-1" instance=Fabric
remote.address=2001:100:127::1 .as=65000 .id=100.127.0.1
.capabilities=mp,rr,gr,as4 .afi=evpn .messages=6 .bytes=345 .eor=""
local.address=2001:100:127::11 .as=65001 .id=100.127.0.11
.cluster-id=100.127.0.11 .capabilities=mp,rr,gr,as4 .afi=evpn
.messages=6 .bytes=345 .eor=""
output.procid=20
input.procid=20 ebgp
multihop=yes hold-time=3m keepalive-time=1m uptime=3m51s340ms
last-started=2025-06-15 20:56:32 prefix-count=1
1 E name="Overlay_Spine2-1" instance=Fabric
remote.address=2001:100:127::2 .as=65000 .id=100.127.0.2
.capabilities=mp,rr,gr,as4 .afi=evpn .messages=6 .bytes=345 .eor=""
local.address=2001:100:127::11 .as=65001 .id=100.127.0.11
.cluster-id=100.127.0.11 .capabilities=mp,rr,gr,as4 .afi=evpn
.messages=6 .bytes=345 .eor=""
output.procid=21
input.procid=21 ebgp
multihop=yes hold-time=3m keepalive-time=1m uptime=3m44s130ms
last-started=2025-06-15 20:56:39 prefix-count=0
Test du bon fonctionnement
Pour tester, on va placer nos LNS sur les Leafs 1 et 3. Le VLAN qui servira à l'interco des deux LNS est le 100.
#LEAF1
/interface bridge
add name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=ether7
/interface bridge vlan
add bridge=bridge tagged=ether7 vlan-ids=100
Et c'est là que j'ai eu un peu du mal : la configuration du switching sur mikrotik est assez ..... particulière !
On crée un bridge (un L2) où dedans on désigne le port ether7 (port d'interconnexion Leaf1/LNS1). Ensuite, on lui dit quels VLANs sont taggés sur ce port. En l'occurrence, seul le 100 dans notre cas.
L'EVPN a beau être configuré mais sans VXLAN et les annonces BGP de la VNI, il ne va pas servir à grand chose.
#LEAF1
add bridge=bridge bridge-pvid=100 learning=no local-address=2001:100:127::11 name=vxlan100 vni=1100 vteps-ip-version=ipv6
/routing bgp evpn
add disabled=no export.route-targets=1100:1100 import.route-targets=1100:1100 instance=Fabric name=VLAN100 vni=1100
#LNS1
/interface vlan
add interface=ether1 name=Interco_LNS2 vlan-id=100
/ip address
add address=100.125.0.1/30 interface=Interco_LNS2 network=100.125.0.0
[admin@PE-LNS1] > /ping 100.125.0.2
SEQ HOST SIZE TTL TIME STATUS
0 100.125.0.2 56 64 3ms411us
1 100.125.0.2 56 64 3ms508us
2 100.125.0.2 56 64 3ms519us
3 100.125.0.2 56 64 3ms540us
sent=4 received=4 packet-loss=0% min-rtt=3ms411us avg-rtt=3ms494us max-rtt=3ms540us
Mes deux LNS arrivent bien à communiquer sur le même niveau 2 à travers la fabric !
Sur les Leafsn pour voir les VTEPS qui émettent dans cette VNI :
#LEAF1
[admin@Leaf1] /routing/route> print where dst-address~"imet"
Flags: A - ACTIVE; b - BGP, e - EVPN; + - ECMP
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE, IMMEDIATE-GW
DST-ADDRESS GATEWAY AFI DISTANCE SCOPE TARGET-SCOPE IMMEDIATE-GW
e [100.127.0.11:512]imet:0|2001:100:127::11 2001:100:127::11 evpn 200 40 10
Ab+ [100.127.0.13:256]imet:0|2001:100:127::13 2001:100:127::13 evpn 20 40 30 fe80::5200:ff:fe24:0%ether1 fe80::5200:ff:fe25:0%ether2
Ab+ [100.127.0.13:512]imet:0|2001:100:127::13 2001:100:127::13 evpn 20 40 30 fe80::5200:ff:fe24:0%ether1 fe80::5200:ff:fe25:0%ether2
Et pour voir les MACs dans les VNI :
#LEAF1
[admin@Leaf1] /routing/route> print where dst-address~"macip"
Flags: A - ACTIVE; b - BGP, e - EVPN; + - ECMP
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE, IMMEDIATE-GW
DST-ADDRESS GATEWAY AFI DISTANCE SCOPE TARGET-SCOPE IMMEDIATE-GW
e [100.127.0.11:512]macip:0|50:00:00:3E:00:00 2001:100:127::11 evpn 200 40 10
Ab+ [100.127.0.13:256]macip:0|50:00:00:3F:00:00 2001:100:127::13 evpn 20 40 30 fe80::5200:ff:fe24:0%ether1 fe80::5200:ff:fe25:0%ether2
Ab+ [100.127.0.13:512]macip:0|50:00:00:3F:00:00 2001:100:127::13 evpn 20 40 30 fe80::5200:ff:fe24:0%ether1 fe80::5200:ff:fe25:0%ether2
Configuration PE LNS
IGP & BGP
Avant de configurer la partie PPPoE, on va s'attaquer à la mise en place de l'ISIS et du BGP. Tout d'abord, on place une IP sur une loopback :
#LNS1
/ip address
add address=100.124.0.1 interface=lo network=100.124.0.1
#LNS2
/ip address
add address=100.124.0.2 interface=lo network=100.124.0.0
Pour l'ISIS, c'est le même principe que l'OSPF (mais avec les particularités de ce protocole de routage : Area et le System-Id) :
#LNS1
/routing isis instance
add afi=ip areas=49.0001 disabled=no name=ISIS_BACKONE system-id=1000.1000.1001
/routing isis interface-template
add instance=ISIS_BACKONE interfaces=Interco_LNS2 levels=l2
add instance=ISIS_BACKONE interfaces=lo levels=l2
Le neighbor est bien monté et l'IP de la loopback est bien diffusée et apprise :
#LNS1
[admin@PE-LNS1] /routing/isis/neighbor> pr
Flags: D - dynamic
0 D instance=ISIS_BACKONE interface=Interco_LNS2 level-type=l2 snpa=50:00:00:3F:00:00 srcid="1000.1000.1002" state=up
[admin@PE-LNS1] /ip/route> pr
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC, r - RIP
Columns: DST-ADDRESS, GATEWAY, ROUTING-TABLE, DISTANCE
# DST-ADDRESS GATEWAY ROUTING-TABLE DISTANCE
DAc 100.125.0.0/30 Interco_LNS2 main 0
D r 100.125.0.0/30 100.125.0.2%Interco_LNS2 main 115
DAc 100.124.0.1/32 lo main 0
DAr 100.124.0.2/32 100.125.0.2%Interco_LNS2 main 115
Pour le BGP, rien de bien sorcier non plus :
#LNS1
/routing bgp instance
add as=64555 disabled=no name=BGP_BACKBONE
/routing bgp template
add hold-time=1m keepalive-time=30s name=TPL_BACKBONE nexthop-choice=force-self output.redistribute=connected,static
/routing bgp connection
add afi=ip,vpnv4 instance=BGP_BACKBONE local.address=100.124.0.1 .role=ibgp name=LNS2 remote.address=100.124.0.2 templates=TPL_BACKBONE
[admin@PE-LNS1] /routing/bgp/session> pr
Flags: E - established
0 E name="LNS2-1" instance=BGP_BACKBONE
remote.address=100.124.0.2 .as=64555 .id=100.124.0.2 .capabilities=mp,rr,gr,as4 .afi=ip .hold-time=1m .messages=2
.bytes=79 .eor=""
local.role=ibgp .address=100.124.0.1 .as=64555 .id=100.124.0.1 .cluster-id=100.124.0.1 .capabilities=mp,rr,gr,as4
.afi=ip .messages=2 .bytes=91 .eor=""
output.procid=20
input.procid=20 ibgp
nexthop-choice=force-self multihop=yes hold-time=1m keepalive-time=30s uptime=18s690ms
last-started=2025-06-16 20:21:25 last-stopped=2025-06-16 20:21:18 prefix-count=0
Le routage semble bien effective et fonctionnel pour accueillir les premiers liaisons PPPoE cliente.
Porte de collecte L2 PPPoE
Pour commencer, il faut placer le port en mode dot1q-tunnel (syntaxe arista). Sur mikrotik, cela donne ça :
#LEAF1
/interface bridge
add ether-type=0x88a8 name=Collecte_L2 protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge=Collecte_L2 interface=ether6
add bridge=Collecte_L2 interface=ether8 pvid=500
/interface bridge vlan
add bridge=Collecte_L2 tagged=ether6 untagged=ether8 vlan-ids=500
Je crée un bridge appelé Collecte_L2 en mode 0x88a8 (IEEE 802.1ad). Cela va permettre d'encaspuler tout le trafic venant de ce port dans un SVLAN (ici 500). Ensuite, je tag le port ether6 (interco vers LNS) et j'untag ether8 (port de la collecte).
Côté LNS, je crée mon interface VLAN 500 avec le use-service-tag=yes.
#LNS1
/interface vlan
add interface=ether3 name=SVLAN use-service-tag=yes vlan-id=500
Cela sert à utiliser le SVLAN et non le CVLAN (de ce que j'ai compris). Donc ca équivaudrait à la commande encapsulation dot1q 500 second-dot1q any de Cisco sauf qu'on utilise du 802.1ad et non du 802.1q in 802.1q.
Le SVLAN arrive bien sur le LNS. Maintenant, il ne reste plus qu'à configurer le PPPoE et le radius (100.100.101.1)
#LNS1
/ppp profile
add change-tcp-mss=yes local-address=100.100.100.2 name=ppp-profile-default only-one=yes use-compression=no use-encryption=no use-ipv6=no use-mpls=no
/ppp aaa
set interim-update=10m use-radius=yes
/radius
add address=100.100.101.1 secret=naruto service=ppp src-address=100.100.100.2 timeout=3s
/radius incoming
set accept=yes
/interface pppoe-server server
add authentication=pap,chap default-profile=ppp-profile-default disabled=no interface=SVLAN pppoe-over-vlan-range=10-4090 service-name=Internet
Je pense que les 4 premiers éléments sont assez simple à comprendre. Il faut juste faire attention à un point sur la configuration du serveur PPPoE : l'utilisation du pppoe-over-vlan-range. On a beau mettre l'interface SVLAN mais il faut lui préciser quel CVLAN peut l'"utiliser".
On est à peu près OK sauf sur un élément ! Par défaut, Mikrotik va attendre un message authenticator du Radius sauf que ..... mon freeradius n'en envoyait pas ...
#LNS1
[admin@PE-LNS1] /radius> print detail
Flags: X - disabled
0 service=ppp called-id="" domain="" address=100.100.101.1 secret="naruto" authentication-port=1812 accounting-port=1813 timeout=3s accounting-backup=no realm="" src-address=100.100.100.2 protocol=udp certificate=none require-message-auth=yes-for-request-resp
Après ajout sur mon freeradius de cette foutue réponse avec ce message, mes premières sessions clientes montent !
#LNS1
[admin@PE-LNS1] /ppp/active> pr
Flags: R - RADIUS
Columns: NAME, SERVICE, CALLER-ID, ADDRESS, UPTIME
# NAME SERVICE CALLER-ID ADDRESS UPTIME
0 R test1@naruto.ninja pppoe 50:00:00:47:00:00 100.64.0.1 11m46s
1 R test@naruto.ninja pppoe 50:00:00:48:00:00 100.64.0.2 9min14s
On a donc remplacé les Cisco par des Mikrotiks !
Suites
Avis mitigé sur la fabric EVPN/VXLAN, notamment, avec le bug qu'un seule VNI est disponible, pas de MAC-VRF (vlan-aware-bundle service), pas de route type 5.
Bon après c'est de la beta, rien ne peut être parfait (sauf Naruto) ! Hâte que Mikrotik développe leur VXLAN. Une fois bien implémenté, peut-être que le SR verra le jour, qui sait ? Inshallah
Côté PPPoE, je trouve que la configuration est beaucoup plus simple et intuitive sur Mikrotik que sur Cisco. Les premiers clients sont produits. Le prochain épisode va être de tester le MPLS sur ces PE 😄
Je termine sur un mot de fin : Isramerde arrive à frapper des haut dirigeants iranniens dans leur appartement à Téhéran. Le Mossad est le meilleur service de renseignement au monde. N’osez pas me dire qu’ils n’étaient pas au courant pour le 7 octobre. Un attentat terroristes commis par des mecs en claquettes arrivés en parachute ..... Utiliser la mort son peuple pour justifier un génocide à Gaza me fait à un certain attentat terroriste mais pour ce coup ci justifier l'envahissement de l'Irak.