Est ce vraiment important ?
La réponse est oui !
Je ne connais pas d'entreprises qui ne souhaitent pas avoir de backup de leur liaison principale.
Cependant, peu de société font le choix d'en avoir une. La réponse est, je pense, simple à comprendre : ca coute deux fois plus cher !
Qu'est ce qu'on doit backuper ?
- Internet
- L'IP Publique
Configuration
Côté LNS, on a rien à faire (c'est pas beau ça ?). Toute la configuration se fait côté Radius et CPE.
Je vais détailler le secours de l'IP publique car c'est le plus compliqué (si vous comprenez ça, vous comprendrez le secours d'Internet).
On va utiliser le VRRP (c'est le standard, on retrouve l'HSRP chez Cisco).
Le VRRP va permettre la création d'une IP virtuelle qui sera partagé entre deux routeurs. Ainsi, cette IP va pouvoir être portée sur un routeur plutôt que sur un autre grâce au principe de la priorité.
Routeur Principal
/interface vrrp
add interface=ether2 name=vrrp1 priority=110
/ip address
add address=192.168.1.252/24 interface=ether2 network=192.168.1.0
add address=192.168.1.254 interface=vrrp1 network=192.168.1.254
/ip firewall nat
add action=src-nat chain=srcnat src-address=192.168.1.0/24 to-addresses= 109.205.64.1
Routeur Secondaire
/interface vrrp
add interface=ether2 name=vrrp1 priority=90
/ip address
add address=192.168.1.253/24 interface=ether2 network=192.168.1.0
add address=192.168.1.254 interface=vrrp1 network=192.168.1.254
/ip firewall nat
add action=src-nat chain=srcnat src-address=192.168.1.0/24 to-addresses= 109.205.64.1
La seule chose qui change est la priorité du VRRP, et aussi, l'IP physique de l'interface (pour éviter les doublons).
Mais comment l'IP va basculer sur le routeur de secours ? Avec l'HSRP, on peut track un SLA (qui lui ping une IP par exemple). Ainsi, si le SLA est down alors le track diminue la priorité de l'HSRP et ca bascule !
Super ! Comment on fait ça sur mikrotik ?
Avec /tool netwatch !
/tool netwatch
add down-script="/interface vrrp set 0 priority=50" host=100.127.0.1 \
interval=30s type=simple up-script="/interface vrrp set 0 priority=110"
On a besoin de faire cela uniquement sur le routeur principal ! J'ai mis l'IP 100.127.0.1 (IP de LNS1) en track host. Si le routeur n'arrive plus à ping cette IP alors il diminue la priorité à 50 donc plus petit que 90 ! Si c'est UP, il garde la priorité à 110.
Ainsi, si la liaison principal tombe, la priorité de 90 sera la plus grande !
Bon ça c'est fait ! Mais vu qu'on NAT avec la même IP publique, il faut bien que cette IP soit routée sur les deux logins ?
Ca se passe dans le fichier users du radius :
root@radius:~# cat /etc/freeradius/3.0/users
nathan@naruto.ninja Cleartext-Password := "nathan"
Service-Type := Framed-User,
Framed-Protocol := PPP,
Framed-MTU := 1492,
Framed-IP-Address := 100.125.0.0,
Framed-IP-Netmask := 255.255.255.255,
Framed-Route := "109.205.64.1/32 100.125.0.0"
sasuke@naruto.ninja Cleartext-Password := "sasuke"
Service-Type := Framed-User,
Framed-Protocol := PPP,
Framed-MTU := 1492,
Framed-IP-Address := 100.125.0.1,
Framed-IP-Netmask := 255.255.255.255,
Framed-Route := "109.205.64.1/32 100.125.0.1 201"
On utilise le principe des framed-route. C'est un attribut radius qui permet d'attribuer une route à un login. Ici, on route 109.205.64.1 sur les deux logins. Et comment dire quel login est prioritaire ? Avec l'ajout du 201 sur la route de secours.
Dans le cas que les deux logins soient montés sur le même LNS, il faut que la route de secours ait une distance administrative supérieur à 1 (car les framed routes sont apprises en statique sur l'IOS XE).
Dans le cas que les deux logins soient montés sur deux différents LNS, il faut que la route de secours ait une distance administrative supérieur à 200 car les LNS s'échangent les routes en iBGP. Si le principal monte sur le LNS1, ce dernier annonce la route 109.205.64.1 avec un AD égale à 200.
Je me suis fait pas chier, j'ai mis à 201, ca règle les deux cas !
LNS1#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 100.65.0.6 to network 0.0.0.0
B* 0.0.0.0/0 [20/0] via 100.65.0.6, 00:14:48
100.0.0.0/8 is variably subnetted, 11 subnets, 3 masks
C 100.64.0.0/29 is directly connected, Port-channel10.10
L 100.64.0.1/32 is directly connected, Port-channel10.10
C 100.65.0.0/29 is directly connected, Port-channel10.11
L 100.65.0.1/32 is directly connected, Port-channel10.11
C 100.100.100.0/24 is directly connected, Port-channel10.3999
L 100.100.100.10/32 is directly connected, Port-channel10.3999
S 100.100.101.0/24 [1/0] via 100.100.100.1, Port-channel10.3999
C 100.125.0.0/32 is directly connected, Virtual-Access2.2
C 100.125.0.1/32 is directly connected, Virtual-Access2.1
C 100.127.0.1/32 is directly connected, Loopback1
i L2 100.127.0.2/32 [115/20] via 100.64.0.2, 00:02:05, Port-channel10.10
109.0.0.0/32 is subnetted, 3 subnets
U 109.205.64.1 [1/0] via 100.125.0.0
C 109.205.66.127 is directly connected, Loopback55
B 109.205.66.128 [200/0] via 100.127.0.2, 00:14:48
LNS2#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 100.65.0.6 to network 0.0.0.0
B* 0.0.0.0/0 [20/0] via 100.65.0.6, 00:16:07
100.0.0.0/8 is variably subnetted, 11 subnets, 3 masks
C 100.64.0.0/29 is directly connected, Port-channel10.10
L 100.64.0.2/32 is directly connected, Port-channel10.10
C 100.65.0.0/29 is directly connected, Port-channel10.11
L 100.65.0.2/32 is directly connected, Port-channel10.11
C 100.100.100.0/24 is directly connected, Port-channel10.3999
L 100.100.100.11/32 is directly connected, Port-channel10.3999
S 100.100.101.0/24 [1/0] via 100.100.100.1, Port-channel10.3999
B 100.125.0.0/32 [200/0] via 100.127.0.1, 00:16:07
B 100.125.0.1/32 [200/0] via 100.127.0.1, 00:16:07
i L2 100.127.0.1/32 [115/20] via 100.64.0.1, 00:03:20, Port-channel10.10
C 100.127.0.2/32 is directly connected, Loopback1
109.0.0.0/32 is subnetted, 3 subnets
B 109.205.64.1 [200/0] via 100.127.0.1, 00:16:07
B 109.205.66.127 [200/0] via 100.127.0.1, 00:16:07
C 109.205.66.128 is directly connected, Loopback55
109.205.64.1/32 est bien appris via 100.125.0.0 sur LNS1 et LNS2 apprend bien la route via 100.127.0.1 qui est LNS1.
Tests
Les deux mikrotik doivent se voir pour échanger les informations VRRP donc branché via du L2 donc un switch.
J'ai branché un VPC pour faire le test de bascule :
VPCS> ip 192.168.1.1/24 192.168.1.254
Checking for duplicate address...
VPCS : 192.168.1.1 255.255.255.0 gateway 192.168.1.254
VPCS> ping 1.1.1.1
84 bytes from 1.1.1.1 icmp_seq=1 ttl=252 time=234.993 ms
84 bytes from 1.1.1.1 icmp_seq=2 ttl=252 time=28.129 ms
84 bytes from 1.1.1.1 icmp_seq=3 ttl=252 time=30.428 ms
84 bytes from 1.1.1.1 icmp_seq=4 ttl=252 time=26.355 ms
84 bytes from 1.1.1.1 icmp_seq=5 ttl=252 time=28.573 ms
VPCS> trace 1.1.1.1
trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop
1 192.168.1.252 1.783 ms 1.261 ms 1.220 ms
2 100.127.0.1 6.981 ms 7.846 ms 5.446 ms
3 100.65.0.6 28.567 ms 18.666 ms 20.376 ms
4 *140.150.160.2 27.597 ms (ICMP type:3, code:3, Destination port unreachable) *
On coupe la session PPP du routeur principal :
Routeur principal
/interface/pppoe-client> set 0 disabled=yes
VPCS> ping 1.1.1.1
84 bytes from 1.1.1.1 icmp_seq=1 ttl=252 time=29.081 ms
84 bytes from 1.1.1.1 icmp_seq=2 ttl=252 time=26.113 ms
*192.168.1.252 icmp_seq=3 ttl=64 time=1.586 ms (ICMP type:3, code:0, Destination network unreachable)
*192.168.1.252 icmp_seq=4 ttl=64 time=1.295 ms (ICMP type:3, code:0, Destination network unreachable)
*192.168.1.252 icmp_seq=5 ttl=64 time=1.486 ms (ICMP type:3, code:0, Destination network unreachable)
VPCS> ping 1.1.1.1
84 bytes from 1.1.1.1 icmp_seq=1 ttl=252 time=31.368 ms
84 bytes from 1.1.1.1 icmp_seq=2 ttl=252 time=35.059 ms
84 bytes from 1.1.1.1 icmp_seq=3 ttl=252 time=25.670 ms
84 bytes from 1.1.1.1 icmp_seq=4 ttl=252 time=27.686 ms
84 bytes from 1.1.1.1 icmp_seq=5 ttl=252 time=25.940 ms
VPCS> trace 1.1.1.1
trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop
1 192.168.1.253 1.676 ms 1.245 ms 1.255 ms
2 100.127.0.1 25.479 ms 6.014 ms 5.937 ms
3 100.65.0.6 26.005 ms 17.578 ms 20.178 ms
4 *140.150.160.2 143.382 ms (ICMP type:3, code:3, Destination port unreachable) *
Un petit temps de coupure le temps que le routeur principal sache qu'il arrive plus à ping 100.127.0.1 et hop la virtual IP (VIP) bascule sur le routeur secondaire.
Dans un traceroute, on voit toujours l'IP physique de l'interface et non la VIP ! Il faut bien faire attention sinon quelle perte de temps en débug 😄
Conclusion
Le backbone étant fini, on configure maintenant les différentes demandes des clients. Cet épisode était centré sur le backup des liaisons.
J'ai détaillé la méthode où on secours l'IP publique. C'est une bonne méthode pour économiser des IPs ! C'est de plus en plus cher et demandé donc si on peut éviter des les gaspiller, c'est top !
Prochain épisode sur la configuration des clients : premier MPLS et sortie sécurisé via un firewall.
Je termine sur un petit mot de fin : Kawaki la victime sah