M H D E X P E R T S

Chargement

Contactez-Nous

3 moyens de surclasser les routes directly connected

Home Articles3 moyens de surclasser les routes directly connected

Une route directement connectée possède une distance de 0 et donc la plus grande priorité.

Impossible de faire mieux ? Pas pour nous ! Voici trois astuces tactiques pour qu’un routeur puisse n’utiliser son interface connectée qu’en cas de backup – astuces 100% garanties sans tunneling, scripting, translation d’adresse ou magie noire !

Pourquoi éviter ce routage implicite ?

Notre use case est le remplacement d’un routeur par un firewall, pour arriver à la topologie suivante (topologie Christophe™) :

La topologie Christophe™

En nominal, le flux en provenance du LAN passe par le FW, le lien rocade, le CE puis le MPLS opérateur. En backup, on utilise un lien IPSec établi par le FW vers le DC client. Le routage direct par le CE opérateur est utilisé en dernier recours (sur perte du firewall ou coupure de sa patte LAN), grâce à une dérogation donnée par l’équipe sécurité.

Schéma complet et parcours de flux

La difficulté de cette architecture consiste à rendre le chemin de flux nominal 1 symétrique pour s’assurer que le Firewall autorise correctement le trafic. Ou en d’autres termes, à court-circuiter, pour les flux MPLS vers LAN, la route implicite du LAN sur le CE opérateur.

Il n’est bien sûr pas question de demander à l’opérateur de créer un tunnel entre le PE MPLS et le Firewall, et nous allons donc seulement lui demander de configurer le CE opérateur pour rendre le flux symétrique avec l’adressage et le peering BGP suivant :

Adressage et sessions BGP

A supposer que le CE est un routeur d’un équipementier courant (Cisco, Juniper, …), je vous propose 3 méthodes pour que les routes en provenance du PE à destination du LAN soit routées sur la rocade plutôt que par l’interface LAN du routeur, sans recours à des procédés externes tels que translation d’adresse, tracking ou scripting (EEM).

Les plus courageux peuvent arrêter la lecture de cet article ici et prendre cet exercice comme devoir de vacances. Bien sûr, tout procédé auquel je n’ai pas pensé est le bienvenu dans les commentaires.

Spoiler : les procédés utilisés

Je vois 3 moyens de battre une interface connected :

  • Le subnetting
  • La virtualisation
  • Le passage par le niveau 2

Procédé 1 : Le subnetting

Avant de comparer la distance entre plusieurs routes, IP recherche la route avec le masque le plus fin. Ainsi, créer 2 routes en /25 vers la rocade permet d’être plus précis que la route /24 directly connected.

Toutefois cette astuce, seule, n’est pas suffisante, car nous ne savons pas détecter simplement la perte de la panne LAN du firewall. Il faut aller un peu plus loin et utiliser l’entrée BGP émise par le Firewall correspondant à cette route LAN.

Cette fonction existe dans BGP sous le nom de BGP Conditional Advertisement chez Cisco comme chez Juniper. On prendra également la précaution de tagger les routes plus spécifiques avec la communauté BGP no-advertise pour que ces 2 routes fines restent locales au CE.

Procédé 2 : La virtualisation

Pour raisonner comme monsieur de la Palice, un bon moyen de résoudre notre problème de route directly connected est de sortir l’interface de la table de routage. Par exemple, en créant une VRF dans laquelle on place l’interface LAN et en la connectant via une rocade interface (interface VASI ou interface de service) à la table de routage globale.

On arrive à l’architecture suivante :

Solution VRF

Il suffit que la route provenant de la VRF soit émise avec une local preference minimale pour que la configuration soit conforme à nos requirements.

Procédé 3 : Utilisation du niveau 2

On peut également résoudre un problème de niveau N par les niveaux inférieurs. Ici, vu que nous nous sommes interdit une modification physique, seul le niveau 2 peut nous être utile.

Pour utiliser le niveau 2, il faut ramener le PE, le CE et le FW sur un même LAN, comme dans le schéma ci-dessous :

Solution Niveau 2

Ainsi, le PE peut envoyer directement les trames vers le FW, sans qu’elles ne soient interceptées par le CE.

Notons que le CE ne va pas modifier le next-hop sur les routes redistribuées en eBGP, car il sait que le Firewall et le PE appartiennent au même subnet et doivent pouvoir communiquer directement entre eux. Cette fonction est connue sous le nom third party next-hop processing. Corollaire: Si on vous a dit que eBGP modifiait systématiquement le next-hop, c’est faux (enfin, ce n’est vrai que dans 99% des cas).

Ainsi, il reste seulement à faire une configuration de type Integrated Routing and Bridging (IRB) sur le CE, configuration naturelle sur un switch de niveau 3 mais plus laborieuse sur un routeur de type IOS-XE.

Les configurations Cisco

Voici pour chaque procédé, les configurations de notre LAB Cisco.

Notre maquette se limite au cas nominal, et la connexion IPSec au-dessus d’Internet n’est pas mise en œuvre.

Configuration fixe du PE

interface Loopback172
 description -- TEST --
 ip address 172.20.20.20 255.255.255.255

interface GigabitEthernet2.24
 description -- To CE --
 encapsulation dot1Q 24
 ip address 172.20.0.14 255.255.255.240
!
router bgp 10
 network 172.20.20.20 mask 255.255.255.255
 neighbor 172.20.0.1 remote-as 65000

Configuration de base du “Firewall”

Notre Firewall est simulé un autre routeur Cisco, ce qui ne doit pas géner car nous voulons seulement tester le comportement du CE.

Sa configuration de base est :

interface GigabitEthernet2
 description -- Rocade --
 ip address 10.10.10.0 255.255.255.254

interface GigabitEthernet3.100
 description -- LAN --
 encapsulation dot1Q 100
 ip address 192.168.100.1 255.255.255.0
 standby 0 ip 192.168.100.254
 standby 0 priority 150
 standby 0 preempt

router bgp 65000
 bgp log-neighbor-changes
 network 192.168.100.0
 neighbor 10.10.10.1 remote-as 65000

Configuration de base du CE

Cette configuration de base fonctionne, à l’exception que le routage retour est direct alors que les flux doivent emprunter la rocade.

interface GigabitEthernet2
 description -- Rocade --
 ip address 10.10.10.1 255.255.255.254

interface GigabitEthernet3.100
 description -- LAN --
 encapsulation dot1Q 100
 ip address 192.168.100.2 255.255.255.0
 standby 0 ip 192.168.100.254

interface GigabitEthernet4.24
 description -- To PE --
 encapsulation dot1Q 24
 ip address 172.20.0.1 255.255.255.240

router bgp 65000
 bgp log-neighbor-changes
 neighbor 10.10.10.0 remote-as 65000
 neighbor 10.10.10.0 next-hop-self
 neighbor 172.20.0.14 remote-as 10

Le ping depuis notre host de test

Depuis notre station en 192.168.100.10, nous pinguons notre loopback de test sur le PE en enregistrant les chemins aller et retour pour vérifier la symétrie. Ici nous n’avons pas encore appliqué les configurations envisagées, donc nous vérifions l’asymétrie :

Comme attendu, le CE envoie les paquets directement vers le host sans repasser par le Firewall :

alp-ep-10:~# ping -R 172.20.20.20
PING 172.20.20.20 (172.20.20.20) 56(124) bytes of data.
64 bytes from 172.20.20.20: icmp_seq=3 ttl=254 time=1.06 ms
NOP
RR:     192.168.100.10
        10.10.10.0
        172.20.0.1
        172.20.20.20   --> Loopback de test sur le PE
        192.168.100.2  --> Adresse LAN du CE
        192.168.100.10 --> le Host de test

Subnetting via BGP conditionnal advertisment

Ce procédé est purement local au CE.

Configuration CE

router bgp 65000
 bgp log-neighbor-changes
 bgp inject-map SplitLAN exist-map LAN_FROM_FW

 network 192.168.100.0 route-map ->BACKUP
 neighbor 10.10.10.0 remote-as 65000
 neighbor 10.10.10.0 next-hop-self
 neighbor 172.20.0.14 remote-as 10

ip prefix-list LAN seq 5 permit 192.168.100.0/24

ip prefix-list ORIGINATED_BY_FW seq 5 permit 10.10.10.0/32

ip prefix-list SplitLAN seq 10 permit 192.168.100.0/25
ip prefix-list SplitLAN seq 20 permit 192.168.100.128/25


route-map SplitLAN permit 10
 set ip address prefix-list SplitLAN

 set community no-advertise

route-map LAN_FROM_FW permit 10
 match ip address prefix-list LAN

 match ip route-source prefix-list ORIGINATED_BY_FW


route-map ->BACKUP permit 10
 set local-preference 50
 set weight 0

Le show bgp depuis le CE

Ping depuis le host de test

alp-ep-10:~# ping -R 172.20.20.20
64 bytes from 172.20.20.20: icmp_seq=324 ttl=253 time=1.31 ms
NOP
RR:     192.168.100.10
        10.10.10.0
        172.20.0.1
        172.20.20.20
        10.10.10.1     --> Adresse de la rocade sur CE
        192.168.100.1  --> LAN du Firewall
        192.168.100.10

VRF et interface VASI

A nouveau ce procédé ne nécessite qu’une configuration locale au CE :

Configuration CE

vrf definition LAN
 rd 65000:1
 address-family ipv4
 exit-address-family
!
interface GigabitEthernet2
 description -- Rocade --
 ip address 10.10.10.1 255.255.255.254

interface GigabitEthernet3.100
 description -- LAN --
 encapsulation dot1Q 100
 vrf forwarding LAN
 ip address 192.168.100.2 255.255.255.0
 standby 0 ip 192.168.100.254

interface vasileft20
 description -- CE GRT->LAN --
 ip address 10.10.20.1 255.255.255.254
 no keepalive
!
interface vasiright20
 description -- CE LAN->GRT --
 vrf forwarding LAN
 ip address 10.10.20.0 255.255.255.254
 no keepalive

router bgp 65000
 bgp log-neighbor-changes
 neighbor 10.10.10.0 remote-as 65000
 neighbor 10.10.10.0 next-hop-self
 neighbor 10.10.20.0 remote-as 65000
 neighbor 10.10.20.0 next-hop-self
 neighbor 172.20.0.14 remote-as 10
 !
 address-family ipv4 vrf LAN
  bgp router-id 10.10.20.0
  network 192.168.100.0 route-map ->BACKUP
  neighbor 10.10.20.1 remote-as 65000
  neighbor 10.10.20.1 activate
 exit-address-family

route-map ->BACKUP permit 10
 set local-preference 50

Le show bgp sur le CE

Dans la table de routage par défaut, le show bgp montre bien les routes reçues via la rocade et via la VRF LAN : tout se passe vraiment comme si les routes LAN provenaient d’un 3ème routeur :

Ping depuis host de test, puis après coupure LAN FW

Ici nous voyons les interfaces VASI dans le chemin de backup, conformément au schéma logique à 2 routeurs.

alp-ep-10:~# ping -R 172.20.20.20
PING 172.20.20.20 (172.20.20.20) 56(124) bytes of data.
64 bytes from 172.20.20.20: icmp_seq=2 ttl=253 time=1.26 ms
NOP
RR:     192.168.100.10
        10.10.10.0
        172.20.0.1
        172.20.20.20
        10.10.10.1     --> Adresse de la rocade sur CE
        192.168.100.1  --> LAN du Firewall
        192.168.100.10

64 bytes from 172.20.20.20: icmp_seq=3 ttl=253 time=0.981 ms
NOP     (same route)
64 bytes from 172.20.20.20: icmp_seq=4 ttl=253 time=1.37 ms
NOP     (same route)
64 bytes from 172.20.20.20: icmp_seq=5 ttl=253 time=1.32 ms
NOP     (same route)
From 192.168.100.10 icmp_seq=10 Destination Host Unreachable
From 192.168.100.10 icmp_seq=11 Destination Host Unreachable
From 192.168.100.10 icmp_seq=12 Destination Host Unreachable
64 bytes from 172.20.20.20: icmp_seq=13 ttl=253 time=2707 ms
NOP
RR:     192.168.100.10
        10.10.20.0
        172.20.0.1
        172.20.20.20
        10.10.20.1
        192.168.100.2
        192.168.100.10

64 bytes from 172.20.20.20: icmp_seq=15 ttl=253 time=682 ms
NOP     (same route)

IRB et third party next-hop processing

Cette solution modifie l’adressage de la rocade. Il faut légèrement mettre à jour la configuration du Firewall, puis pour être didactique, nous découpons la configuration du CE en 2 parties :

  • La configuration IRB plutôt lourde
  • La configuration BGP beaucoup plus digeste

Modification Firewall

interface GigabitEthernet2
 ip address 172.20.0.2 255.255.255.240

router bgp 65000
 no neighbor 10.10.10.1
 neighbor 172.20.0.1 remote-as 65000

Configuration CE: IRB

interface GigabitEthernet2
 no ip address
 description – Rocade --
 service instance 24 ethernet
  encapsulation untagged

no interface GigabitEthernet4.24
interface GigabitEthernet4
 description -- WAN to PE --
 service instance 24 ethernet
  description -- To PE --
  encapsulation dot1q 24
  rewrite ingress tag pop 1 symmetric
 exit
bridge-domain 24
 member GigabitEthernet2 service-instance 24
 member GigabitEthernet4 service-instance 24

interface BDI24
 description -- common subnet for FW, CE and PE --
 ip address 172.20.0.1 255.255.255.240
 no shutdown

Configuration CE: BGP

router bgp 65000
 bgp log-neighbor-changes
 network 192.168.100.0 route-map ->BACKUP
 neighbor 172.20.0.2 remote-as 65000
 neighbor 172.20.0.14 remote-as 10

route-map ->BACKUP permit 10
 set local-preference 50
 set weight 0

Show bgp depuis le PE

Le PE route bien les paquets directement vers le Firewall. La route de backup vers le CE n’apparaît pas car le CE n’annonce que la meilleure route, celle annoncée par le Firewall.

Ping depuis host de test

alp-ep-10:~# ping -R 172.20.20.20
PING 172.20.20.20 (172.20.20.20) 56(124) bytes of data.
64 bytes from 172.20.20.20: icmp_seq=1 ttl=254 time=0.885 ms
NOP
RR:     192.168.100.10
        172.20.0.2
        172.20.20.20
        192.168.100.1  --> LAN du Firewall
        192.168.100.10
Tags:
Partager:

Philippe Jounin

Philippe est architecte réseau chez un opérateur depuis 20 ans. Il a le double rôle de concevoir des réseaux pour les clients, puis de les faire fonctionner. Bien que passionné par l'innovation, il reste un fervent supporter de la RFC 1925 et garde tout son sens critique par rapport au hype et aux promesses féeriques des constructeurs.

Ancien développeur, il tente de garder la main en programmant des Arduino en C ou des utilitaires opensource en Ruby. On peut également le croiser en randonnée dans les collines ou dans un club de bridge.

Commentaires

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Article récents