De retour !
Après 4 mois d'absence, je me replonge dans mon blog et mes tutos. Cet épisode (court) sera centré sur la configuration du VXLAN entre deux routerOS v7.17.
Je veux faire comprendre que ce n'est pas un protocole uniquement réservé dans un environnement backbone opérateur/hébergeur ! Il est très utile notamment pour de la migration de on-premise vers cloud ! Au lieu de répliquer les données des VMs (ce qui peut prendre des jours/semaines) et de provoquer un arrêt de la prod, il suffirait de migrer en live si les deux hyperviseurs sont en cluster !
Allez on regarde comment on configure ça dans un réseau simple (du moment qu'on a un routage IP entre les deux mikrotiks, le tunnel VXLAN montera).
Configuration
Pas besoin d'EVPN ici ! On fait du VXLAN "static", cela veut dire qu'on monte un peer manuellement 😄
Pour commencer, on set un name à notre mikrotik :
/system identity
set name=VTEP1
Ensuite, on crée notre interface VXLAN.
/interface vxlan
add group=239.0.0.1 interface=ether1 mtu=1450 name=vxlan-vni-14000 port=4789 vni=14000
Tout d'abord, on précise le groupe (IP Multicast) et l'interface WAN. Ensuite, on set la MTU (j'ai mis 1450 car interco IP entre mes deux routeurs donc 1500 octets de MTU. L'entête IPv4 de VXLAN prend 50 octets !). Ensuite, on set le port et la VNI.
Pour le multicast, je me suis basé sur la catégorie "Administratively scoped" sur https://en.wikipedia.org/wiki/Multicast_address. Le pool 239.0.0.0/8 est pour des utilisations personnelles. D'ailleurs, je ne comprends pas trop pourquoi je suis obligé de préciser ça.
On crée deux bridge : une Loopback (pour le peer static VXLAN) et un bridge pour lier l'interface LAN et l'interface VXLAN.
/interface bridge
add name=bridge-vxlan-vni-14000
add name=Lo0
/interface bridge port
add bridge=bridge-vxlan-vni-14000 interface=ether2
add bridge=bridge-vxlan-vni-14000 interface=vxlan-vni-14000
Ici, l'interface LAN ether2 sera dans le même bridge que l'interface VXLAN donc le domaine de diffusion de ce port sera étendu aussi dans le tunnel VXLAN.
La configuration réseau :
/ip address
add address=100.127.0.1 interface=Lo0 network=100.127.0.1
add address=100.100.100.1/24 interface=ether1 network=100.100.100.0
/ip route
add gateway=100.100.100.2
Et pour finir la déclaration du VTEP :
/interface vxlan vteps
add interface=vxlan-vni-14000 remote-ip=100.127.0.2
Au final, la configuration ressemble à ça :
[admin@VTEP1] > export
# 2025-02-13 19:34:58 by RouterOS 7.17
# system id = 7pTW9LGK98N
#
/interface bridge
add name=Lo0
add name=bridge-vxlan-vni-14000
/interface vxlan
add group=239.0.0.1 interface=ether1 mac-address=8E:47:2A:FC:73:1D mtu=1450 \
name=vxlan-vni-14000 port=4789 vni=14000 vrf=main vteps-ip-version=ipv4
/port
set 0 name=serial0
/interface bridge port
add bridge=bridge-vxlan-vni-14000 interface=ether2
add bridge=bridge-vxlan-vni-14000 interface=vxlan-vni-14000
/interface vxlan vteps
add interface=vxlan-vni-14000 remote-ip=100.127.0.2
/ip address
add address=100.127.0.1 interface=Lo0 network=100.127.0.1
add address=100.100.100.1/24 interface=ether1 network=100.100.100.0
/ip route
add gateway=100.100.100.2
/system identity
set name=VTEP1
/system note
set show-at-login=no
Bien sûr, on adapte la configuration (les IPs) sur VTEP2 😄
Tests
On met une IP sur les VPC.
192.168.14.10 = VPC branché sur VTEP1
192.168.14.11 = VPC branché sur VTEP2
VPCS> ping 192.168.14.11
84 bytes from 192.168.14.11 icmp_seq=1 ttl=64 time=1.861 ms
84 bytes from 192.168.14.11 icmp_seq=2 ttl=64 time=1.879 ms
84 bytes from 192.168.14.11 icmp_seq=3 ttl=64 time=1.853 ms
84 bytes from 192.168.14.11 icmp_seq=4 ttl=64 time=1.980 ms
84 bytes from 192.168.14.11 icmp_seq=5 ttl=64 time=1.758 ms
Le ping est opérationnel !
On peut aussi tester la MTU :
VPCS> ping 192.168.14.11 -l 1422 -D
1450 bytes from 192.168.14.11 icmp_seq=1 ttl=64 time=2.042 ms
1450 bytes from 192.168.14.11 icmp_seq=2 ttl=64 time=1.865 ms
1450 bytes from 192.168.14.11 icmp_seq=3 ttl=64 time=1.721 ms
1450 bytes from 192.168.14.11 icmp_seq=4 ttl=64 time=1.918 ms
1450 bytes from 192.168.14.11 icmp_seq=5 ttl=64 time=1.886 ms
VPCS> ping 192.168.14.11 -l 1423 -D
192.168.14.11 icmp_seq=1 timeout
192.168.14.11 icmp_seq=2 timeout
192.168.14.11 icmp_seq=3 timeout
192.168.14.11 icmp_seq=4 timeout
192.168.14.11 icmp_seq=5 timeout
On a set la MTU à 1450. Donc les paquets avec une size > 1422 ne passent pas. Pourquoi 1422 ? 20 pour l'entête IP et 8 pour l'entête ICMP donc 1422+20+8=1450.
On peut voir les entêtes dans le wireshark. Et on voit aussi que VXLAN n'est pas chiffré ! Si on veut chiffrer le trafic, on peut monter un wireguard/ipsec par exemple.
Suite
Petit épisode pour se remettre dans le bain du blog 😀
On a crée une interface VXLAN pour le VNI 14000. Si on veut étendre un autre VLAN, il suffit de procéder de la même façon. On sent quand même les limites comparé à un Arista mais c'est logique ! Le but est juste d'étendre un ou deux VLANs et encore ! C'est pour des besoins de migrations de VM.
Le VXLAN n'est pas réservé à des besoins purement infrastructure. De simples mikrotiks posés en tant que CPE peuvent faire du VXLAN ! Au lieu de tirer une FON pour faire du L2, on peut très bien passer par une FTTH/FTTO (en adaptant le MTU en fonction des collectes opérateurs) et procéder à la migration des VM vers le cloud.
La suite ? Du VXLAN entre mikrotik et fortigate !
Je termine sur un mot de fin : Vendre du SDWAN en full nominal/backup ne SERT A RIEN. Pitié je vous en supplie, arrêtez. Ca équivaut à du MPLS !!!!! Et le MPLS est plus simple à produire/débug que du PBR/BGP/IPSEC.