Envoyer un message aux utilisateurs connectés sur Juniper

Vous avez besoin de communiquer un message aux utilisateurs connectés sur un switch ou un routeur Juniper ? Par exemple que vous allez redémarrer un équipement d’ici quelques minutes.

Il existe, comme sur Linux ou FreeBSD puisque Junos est basé dessus, une commande qui permet de faire ça. Cette commande c’est request message avec les utilisateurs à contacter.

Par exemple pour contacter tous les utilisateurs :

 request message all message "Redémarrage du routeur dans 1 minute" 

Pour contacter l’utilisateur operateur2 :

request message user operateur2 message "Redémarrage du routeur dans 1 minute"

BGP route dampening

BGP route dampening est un mécanisme qui permet de réduire la propagation des effets de routes instables. Lorsqu’un réseau – un préfixe – flap, il se verra attribuer un penalty de 1000 qui sera placé dans l’historique de l’état dampening. Chaque flap supplémentaire ajoutera un nouveau penalty d’une valeur de 1000, qui s’additionnera aux autres.

Si le score des penaltys atteint la valeur de suppress limit (la valeur par défaut est 2000), la route est dampened (affaiblie), ce qui signifie qu’elle n’est plus annoncée à aucun peer.

Les valeurs par défaut des différents critères sont :

  • Penalty : 1000
  • Suppress limit : 2000
  • Reuse limit : 750
  • Half-life : 15 minutes
  • Maximum suppress-limit : 60 minutes

Lorsque qu’une route est dampened, le penalty doit être réduit à une valeur inférieure à celle définie par la reuse limit pour que celle-ci puisse à nouveau être annoncée aux peers.

Le half-life timer s’en occupe automatiquement. Après avoir reçu un penalty, lorsqu’un préfixe devient à nouveau stable, le half-life timer démarre. Lorsque la valeur du half-life est atteinte, la valeur du penalty va être réduite de moitié de manière exponentielle toutes les 15 minutes. Lorsque la valeur du penalty passe sous la valeure de reuse limit, le penalty est retiré.

Exemple :

  1. Une route instable se voit attribuer un penalty de 5000
  2. Elle redevient stable
  3. Après 15 minutes son score penalty passe de 5000 à 2500
  4. Après 30 minutes son score penalty passe de 2500 à 1250
  5. Après 45 minutes son score penalty passe de 1250 à 625
  6. Après 45 minutes, la route est donc à nouveau annoncée aux peers

Le paramètre maximum suppress-limit est renseigné afin de s’assurer qu’un préfixe n’est pas dampened indéfiniment. Dans le cas d’une configuration par défaut, un préfixe est à nouveau autorisé au bout de 60 minutes, indépendamment du score de penalty.

Formule

Afin de vous assurer que votre valeur de max-penalty est plausible, la formule de calcul suivante vous indiquera si celle-ci est correcte :

 max-penalty = reuse-limit * 2^( max-suppress-time / half-life ) 

En se basant sur ces valeurs :

  • Penalty : 1000
  • Suppress limit : 30000
  • Reuse limit : 500
  • Half-life : 5 minutes
  • Maximum suppress-limit : 30 minutes
max-penalty = 500 * 2^( 30 / 5 ) : soit 32000

Dans ce cas, un penalty représente 1000. Lorsque le penalty atteint 32000, la route est dampened. Dans ce cas, cela est possible, car la suppress limit est de 30000, soit moins que la valeur maximale de penalty de 32000. Si la suppress limit était de 40000, cela ne serait pas possible, car la suppress limit ne serait jamais atteinte.

Dois-je bloquer ICMP ?

Dois-je bloquer ICMP pour des raisons de sécurité ou de performance ?

Beaucoup de personnes pensent, à tort, qu’ICMP présente un risque de sécurité pour le réseau. Dès lors, ICMP est bloqué sur les firewalls et parfois même sur les routeurs et autres équipements réseau. C’est peut-être vrai si on autorise tout ICMP, mais c’est certainement faux si on autorise uniquement les bonnes choses de manière restrictive.

Comme nous allons le voir, ICMP est essentiel au bon fonctionnement du réseau. De plus, il simplifie grandement le dépannage de problèmes réseau complexes.

1. Ping ou echo request et echo reply

Nous connaissons tous « ping » et nous l’utilisons beaucoup. À l’intérieur du réseau, il n’y aucune bonne raison de bloquer le ping et les réponses. Certaines personnes prétendent que d’autoriser le ping permet de rendre les équipements découvrables par le réseau. Si vous êtes vraiment soucieux du risque de découvrabilité de votre réseau, utilisez de la micro-segmentation et souvenez-vous que votre serveur écoute certainement déjà sur un port, par exemple le port 443 pour votre serveur web intranet.

Nous avons déjà tous entendu la phrase plutôt triste « de toute manière, la passerelle n’a jamais répondu » en essayant de dépanner un problème de réseau, sans savoir si nous faisons face à un problème de connectivité physique, d’isolation L2, ou de règles d’un firewall.

Pour cette raison, autorisez les messages suivants :

IPv4

Echo request (type 8, code 0)
Echo reply (type 0, code 0)

IPv6

Echo Request (Type 128, Code 0)
Echo Reply (Type 129, Code 0)

2. Fragmentation requise

Indispensable au bon fonctionnement du protocole TCP, Path MTU Discovery est une technique qui permet de déterminer la taille MTU du chemin entre la source et la destination. On admettra que l’équipement présentant le plus petit MTU définira la taille maximale du MTU à utiliser.

Si deux hôtes distants on un MTU plus faible que celui communiqué localement, il y a de fortes probabilités pour que la communication ne fonctionne pas correctement de bout en bout et que votre trafic finisse discrètement dans un trou noir.

En IPv4, on utilise un drapeau « DF » (don’t fragment) qui retournera « fragmentation required », alors qu’en IPv6, les paquets ne sont pas fragmentés par le routeur et retourne un « packet too big » comprenant la taille MTU à honorer. Sans cette réponse, la source effectuera une retransmission, qui continuera en boucle d’essayer de transmettre sur le lien, comme si celui-ci présentait une perte de paquets. Cette erreur est particulièrement pernicieuse à dépanner, car la communication TCP est bel et bien établie.

Dans les systèmes d’exploitation modernes, une solution a été imaginée autour de la RFC 4821 pour régler ce problème en se reposant sur la technique de PLPTUD, qui découvre le MTU du chemin en augmentant progressivement le MSS jusqu’à trouver la bonne valeure pour le chemin. Mais autoriser ICMP permet de s’affranchir de beaucoup de problèmes.

IPv4

Fragmentation required (Type 3, Code 4)

IPv6

Packet too big (Type 2, Code 0)

3. Traceroute

Traceroute est un outil permettant de faire du dépannage réseau avancé. Il permet de savoir beaucoup de choses et fonctionne de manière assez spéciale en envoyant un paquet avec un TTL de 1 au premier routeur qui répondra avec un message Time exceed et son adresse IP, puis la source incrémentera le TTL ainsi de suite afin de construire une vue d’ensemble du chemin.

Lorsque vous faites un traceroute et que chaque saut répond avec trois étoiles * * * cela signifie que les messages ICMP time exceeded sont bloqués.

Si vous désirez en savoir plus sur traceroute, voici une vidéo qui vous en dira plus que vous pouvez souhaiter en savoir sur le sujet (en anglais) :

Explication du fonctionnement de traceroute

Dès lors, autorisez les messages ICMP suivants :

IPv4

Time exceeded (Type 11, Code 0)

IPv6

Time exceeded (Type 3, Code 0) 

Photo d’illustration par Giuseppe Milo

BGP avec Windows Server

Dans cet article, nous allons voir la configuration du protocole BGP avec la version Windows Server 2016 (également disponible sur Windows Server 2019) de Microsoft.

Ainsi, il est possible de configurer du routage BGP sur votre serveur et de partager des routes par le protocole de routage dynamique Border Gateway Protocol 4 (BGP4).

Ceci permet notamment de faire du routage sur l’hôte « routing on the host », ou sur les machines virtuelles installées sur votre hyperviseur Windows. Ceci permet d’ouvrir des horizons très intéressants pour vos topologies réseau.

À noter enfin que, selon mes recherches, Windows ne supporte pas le MD5 sur les sessions BGP.

Installation

Pour commencer, il faut installer les fonctionnalitées Remote Access, RSAT Remote Access Powershell et Routing en Powershell. Faites une élévation de privilège puis passez la commande Powershell suivante

Install-WindowsFeature RemoteAccess,RSAT-RemoteAccess-PowerShell,Routing

Activez le routage sur le serveur avec la commande suivante :

Install-RemoteAccess -VpnType RoutingOnly
Votre routeur BGP est prêt !

Configuration

Puis on créer un routeur BGP avec la commande suclivante

Add-BgpRouter -BgpIdentifier 172.16.30.11 -LocalASN 65534

Puis on ajoute un peer iBGP avec la commande suivante

Add-BgpPeer -LocalIPAddress 172.16.30.10 -PeerIPAddress 172.16.30.11 -PeerASN 65534 -Name SRV02
L’état est « Connecting » car l’autre serveur n’est pas encore configuré

Lorsque l’on configure le routeur et on ajoute la session BGP sur l’autre serveur la connexion s’établie

Add-BgpRouter -BgpIdentifier 172.16.30.11 -LocalASN 65534

Add-BgpPeer -LocalIPAddress 172.16.30.11 -PeerIPAddress 172.16.30.10 -PeerASN 65534 -Name SRV01
Connexion établie (depuis SRV02)
Connexion établie (depuis SRV01)

On peut ensuite ajouter des routes à annoncer. Contrairement à ce que vous connaissez certainement du BGP, il n’y a pas besoin de créer de null route dummy route pour que Windows annonce une route. Il annonce toutes les routes souhaitées sans même que celles-ci ne soient présentent dans sa table de routage.

Depuis SRV01, nous allons ajouter 8 routes /24, de 192.168.96.0 à 192.168.103.0/24

Add-BgpCustomRoute -Network 192.168.96.0/24
Add-BgpCustomRoute -Network 192.168.97.0/24
Add-BgpCustomRoute -Network 192.168.98.0/24
Add-BgpCustomRoute -Network 192.168.99.0/24
Add-BgpCustomRoute -Network 192.168.100.0/24
Add-BgpCustomRoute -Network 192.168.101.0/24
Add-BgpCustomRoute -Network 192.168.102.0/24
Add-BgpCustomRoute -Network 192.168.103.0/24

Nous allons vérifier depuis SRV02 si celles-ci sont bien reçues

Vérifications des routes depuis SRV02

Nous pouvons également résumer les routes ci-dessous avec cette commande et annoncer 192.168.96.0/21 plutôt que d’annoncer les 8 routes en /24 pour alléger la table de routage

Add-BgpRouteAggregate -Prefix 192.168.96.0/21 -SummaryOnly Enabled
SRV01 demande une confirmation

Vérifications de l’aggrégation de nos routes depuis SRV02

Vérifications de l’aggrégation depuis SRV02

Pour obtenir des informations sur votre routeur

Get-BgpRouter

Pour affichier vos peers BGP

Get-BgpPeer

Pour afficher les routes BGP

Get-BgpRouteInformation

Vous pouvez également créer des policy que vous pouvez appliquer sur des peers en ingress ou en egress en deux étapes selon l’exemple.

Pour illustrer cette policy, nous allons d’abord ajouter une route BGP, vérifier la table de routage BGP sur SRV02, puis ajouter un filtre de sortie sur la session BGP du côté SRV01 et vérifier à nouveau la table de routage côté SRV02

Ajout d’une route sur SRV01

Add-BgpCustomRoute -Network 10.10.10.10/32
Ajout d’une route sur SRV01

Vérification de la table de routage sur SRV02

Vérification de la table de routage sur SRV02

Ajout d’une policy (règle) de filtrage pour n’autoriser que le préfixe 192.168.96.0/21 à être communiqué

Add-BgpRoutingPolicy -Name SRV01_IP -MatchPrefix 192.168.96.0/21 -PolicyType Allow

Et appliquation de cette policy (règle) au peer SRV02

Add-BgpRoutingPolicyForPeer -PeerName SRV02 -PolicyName SRV01_IP -Direction Egress
Ajout de la policy (règle) et appliquation de la règle sur le peer

Vérification avant et après appliquations de la policy

Avant / après appliquations la policy

Exemple

Imaginons que nous ajoutons l’adresse IP 192.168.96.5/32 sur notre serveur SRV01 et que nous essayons de le joindre par le serveur SRV02.

Adresse IP 192.168.96.5/32 ajoutée
Vérification de la table de routage et de connectivité

Conclusion

Pouvoir faire du routage directement sur votre serveur, ou sur un serveur virtuel permet de complètement repenser votre réseau et vous affranchir d’un domaine de broadcast, risqué et contraignant à maintenir.

Imaginez un réseau ou votre serveur peer et échange ses routes directement avec votre firewall ou un routeur, sans passer par une configuration contraignante de switchs. C’est sans doute, une grande avancée pour le réseau avec Windows Server, Hyper-V et pour vos futurs utilisations dans le Cloud.

La flexibilité de pouvoir annoncer des routes en /32 vous permet une mobilité quasi infinie de votre infrastructure. Vous pouvez, par exemple, mettre en place un système de anycast BGP pour vos DNS ou pour d’autres services assurant de la haute disponibilité.

Toutes les commandes

Pour aller plus loin, voici toutes les commandes BGP existantes sur Windows Server

Add-BgpCustomRoute
Add-BgpPeer
Add-BgpRouteAggregate
Add-BgpRouter
Add-BgpRoutingPolicy
Add-BgpRoutingPolicyForPeer
Clear-BgpRouteFlapDampening
Disable-BgpRouteFlapDampening
Enable-BgpRouteFlapDampening
Get-BgpCustomRoute
Get-BgpPeer
Get-BgpRouteAggregate
Get-BgpRouteFlapDampening
Get-BgpRouteInformation
Get-BgpRouter
Get-BgpRoutingPolicy
Get-BgpStatistics
Remove-BgpCustomRoute
Remove-BgpPeer
Remove-BgpRouteAggregate
Remove-BgpRouter
Remove-BgpRoutingPolicy
Remove-BgpRoutingPolicyForPeer
Set-BgpPeer
Set-BgpRouteAggregate
Set-BgpRouteFlapDampening
Set-BgpRouter
Set-BgpRoutingPolicy
Set-BgpRoutingPolicyForPeer
Start-BgpPeer
Stop-BgpPeer

Photo d’illustration par serzhile