CCNP SPCOR 350-501 · Chapitre 4 : politiques de routage avec les route-maps, RPL et les prefix-lists

Filtrer, marquer, préférer, redistribuer : tout ce qu’un ingénieur opérateur fait avec ses politiques de routage, sur IOS XE (route-maps, prefix-lists, community-lists) et sur IOS XR (RPL, prefix-sets, as-path-sets, community-sets). Avec la logique exacte de chaque outil, les pièges qui tombent à l’examen et un lab PNETLab complet de 6 routeurs.

1. Test d’entrée (10 minutes, sans notes)

1. Une route-map a deux séquences : permit 10 (match prefix-list A) et deny 20 (match prefix-list B). Que devient une route qui ne figure ni dans A ni dans B ?
2. Dans match ip address prefix-list A B, la route doit-elle être dans A et B, ou dans A ou B ?
3. La prefix-list 10.0.0.0/8 ge 24 laisse-t-elle passer 10.1.2.0/23 ? Et 10.1.2.0/24 ?
4. La prefix-list 172.16.0.0/16 (sans ge ni le) laisse-t-elle passer 172.16.5.0/24 ?
5. Dans une route-map permit, que se passe-t-il pour une route qui correspond à une ligne deny de l’ACL référencée ?
6. Sur IOS XR, une session eBGP est établie mais aucune route n’est échangée. Cause la plus probable ?
7. En RPL, quelle est la différence entre pass et done ?
8. Une politique RPL contient seulement if destination in (10.0.0.0/8 le 32) then set local-preference 200 endif. Que devient une route 192.168.1.0/24 ?
9. Sur IOS XE, redistribute ospf 1 dans BGP, sans autre option : les routes externes OSPF (E1/E2) sont-elles redistribuées ?
10. Un distribute-list … in dans OSPF retire-t-il la LSA de la base de données OSPF ?

2. Pourquoi des politiques de routage, et où les applique-t-on ?

Un protocole de routage, laissé à lui-même, annonce tout ce qu’il connaît et choisit ses chemins selon ses règles « naturelles » (plus court chemin pour un IGP, algorithme de sélection pour BGP). Chez un opérateur, ce comportement par défaut est insuffisant et parfois dangereux : un client qui annonce par erreur une route par défaut ou les préfixes d’un autre, un transitaire qui envoie des préfixes privés, une redistribution qui crée une boucle… Les politiques de routage servent à quatre choses :

2.1 Les points d’application

Une politique ne fait rien tant qu’elle n’est pas attachée quelque part. C’est la source d’erreur numéro un en lab : une route-map parfaite… jamais appliquée.

3. Les prefix-lists

Une prefix-list est une liste de règles qui compare un préfixe (réseau + longueur de masque). C’est l’outil standard pour sélectionner des routes : plus lisible et plus précis qu’une ACL, puisqu’il tient compte de la longueur du masque.

3.1 Les quatre éléments d’une entrée

ip prefix-list NOM [seq N] permit|deny RÉSEAU/LONGUEUR [ge MIN] [le MAX]

1. Le réseau (motif de bits de poids fort).
2. La longueur : combien de bits de ce motif doivent être identiques.
3. ge (greater or equal) : longueur de masque minimale acceptée.
4. le (less or equal) : longueur de masque maximale acceptée.

3.2 Les règles à connaître par cœur

Contrainte de cohérence : longueur < ge ≤ le ≤ 32 (128 en IPv6). Sinon la commande est refusée.

• Les entrées sont évaluées de haut en bas, la première qui correspond décide (permit ou deny).
• Il y a un deny implicite à la fin.
• Sans seq, IOS numérote automatiquement par pas de 5. On peut ajouter ou supprimer une entrée par son numéro.
• Syntaxe : ip prefix-list / ipv6 prefix-list sur IOS XE ; ipv4 prefix-list / ipv6 prefix-list sur IOS XR (où l’on utilise plutôt des prefix-sets dans RPL).

3.3 S’entraîner en binaire

La méthode qui ne trompe jamais : écrire en binaire uniquement l’octet où se trouve la frontière du masque.

Exercice 1 : permit 10.48.0.0/14 ge 24. 48 = 0011 0000 ; avec /14, les 6 premiers bits du deuxième octet comptent : 001100. Le deuxième octet d’une route doit donc valoir entre 48 (00110000) et 51 (00110011).

Exercice 2 (à faire seul, réponses dans le quiz) : permit 192.168.32.0/19 ge 22 le 24. Que donnent 192.168.40.0/22, 192.168.64.0/24, 192.168.33.0/24, 192.168.32.0/19 et 192.168.63.128/25 ?

3.4 Prefix-list contre ACL

Une ACL standard utilisée dans une route-map ne regarde que l’adresse réseau, pas la longueur du masque : access-list 10 permit 10.1.0.0 0.0.255.255 laisse passer 10.1.0.0/16, 10.1.5.0/24 et 10.1.5.1/32 sans distinction. Une ACL étendue peut tester le masque (le champ « destination » de l’ACL sert alors à comparer le masque), mais c’est illisible. La prefix-list est faite pour ça : utilise-la systématiquement pour sélectionner des routes.

! Vérifications utiles (IOS XE)
PE2# show ip prefix-list detail BOGONS       ! entrées + compteurs de correspondances (hit count)
PE2# show ip bgp prefix-list BOGONS          ! routes BGP qui correspondent à la liste
PE2# clear ip prefix-list BOGONS            ! remise à zéro des compteurs

4. Les route-maps (IOS / IOS XE)

Une route-map est une suite d’instructions numérotées, appelées séquences. Chaque séquence a une action (permit ou deny), des conditions (match) et éventuellement des modifications (set). On la retrouve sur IOS, IOS XE et NX-OS ; IOS XR la remplace par RPL.

4.1 L’algorithme de lecture

4.2 Les dix règles qui font la différence

1. Ordre : les séquences sont lues par numéro croissant. Prévois des trous (10, 20, 30…) pour insérer plus tard.
2. Première correspondance : dès qu’une séquence correspond, la décision est prise et la lecture s’arrête.
3. Deny implicite : une route qui ne correspond à aucune séquence est rejetée. Pour « tout le reste passe », termine par une séquence permit sans match.
4. Séquence sans match : elle correspond à toutes les routes.
5. Séquence sans numéro : route-map X permit crée ou réécrit la séquence 10. Taper deux fois la commande sans numéro écrase la séquence 10.
6. Suppression : no route-map X efface toute la route-map ; no route-map X permit 20 n’efface que la séquence 20.
7. OU dans une ligne : plusieurs valeurs du même type sur la même ligne (match ip address prefix-list A B) = A ou B.
8. ET entre les lignes : plusieurs lignes match de types différents (match ip address … + match community …) = toutes doivent être vraies.
9. Deny dans une ACL ou une prefix-list : une route refusée par la liste référencée « ne correspond pas » à la séquence. Dans une séquence permit, elle n’est pas rejetée : elle passe à la séquence suivante. C’est l’action de la route-map qui rejette, pas celle de la liste.
10. continue (BGP uniquement) : après une séquence permit qui correspond, au lieu de s’arrêter, on saute à la séquence indiquée (ou à la suivante) pour cumuler d’autres set. Une séquence deny qui correspond termine tout, même après un continue.

! Lis cette route-map et prédis le sort de chaque route avant de regarder les commentaires
route-map DEMO permit 10
 match ip address prefix-list CLIENT-A CLIENT-B     ! A OU B
 match community GOLD                                ! ET communauté GOLD
 set local-preference 300
!
route-map DEMO deny 20
 match ip address prefix-list BOGONS                 ! bogons : rejetés
!
route-map DEMO permit 30
 match as-path 10
 set local-preference 150
 continue 50                                         ! on ne s'arrête pas : direction séquence 50
!
route-map DEMO permit 40
 set local-preference 120                            ! jamais lue pour une route qui a matché 30
!
route-map DEMO permit 50
 set community 65000:999 additive                    ! s'ajoute aux communautés existantes

4.3 Les match et set les plus utiles

4.4 Les objets associés : as-path et community-lists

! Expressions régulières d'AS-path (IOS)
ip as-path access-list 10 permit ^$            ! routes locales (AS-path vide)
ip as-path access-list 20 permit ^65101_       ! reçues directement de l'AS 65101
ip as-path access-list 30 permit _65300$       ! créées (originées) par l'AS 65300
ip as-path access-list 40 permit _65300_       ! qui traversent l'AS 65300
ip as-path access-list 50 permit ^65101(_65101)*$   ! 65101 seul, avec ou sans prepend
! _ = séparateur (espace, début, fin) · ^ = début · $ = fin · . = un caractère · * = 0 ou plus · + = 1 ou plus

! Community-lists
ip bgp-community new-format                    ! affiche les communautés en ASN:valeur
ip community-list standard CLIENT permit 65000:1001
ip community-list expanded CLIENT-ALL permit ^65101:[0-9]+$

Rappel des communautés « bien connues » : no-export (ne pas annoncer hors de l’AS ou de la confédération), no-advertise (n’annoncer à aucun voisin), local-as (ne pas sortir du sous-AS de confédération), internet. Sur IOS XE, les communautés ne sont envoyées à un voisin que s’il y a neighbor X send-community (y compris en iBGP).

4.5 Trois pièges classiques, illustrés

Piège 1 : le distribute-list qui « efface » tout

router isis CORE
 distribute-list route-map PREFERER-P1 in
!
route-map PREFERER-P1 permit 10
 match ip address prefix-list LOOPBACK-PE2
 match ip next-hop prefix-list VIA-P1

Objectif : n’installer la loopback de PE2 que via P1. Résultat : c’est bien le cas… mais toutes les autres routes IS-IS ont disparu de la table de routage. Le deny implicite rejette tout ce qui ne correspond pas à la séquence 10. Correction : ajouter une séquence qui rejette la loopback de PE2 par les autres chemins, puis un permit final sans match.

route-map PREFERER-P1 permit 10
 match ip address prefix-list LOOPBACK-PE2
 match ip next-hop prefix-list VIA-P1
route-map PREFERER-P1 deny 20
 match ip address prefix-list LOOPBACK-PE2            ! les autres chemins vers PE2
route-map PREFERER-P1 permit 30                       ! tout le reste passe

Piège 2 : le OU au lieu du ET

match ip address prefix-list LOOPBACK-PE2 VIA-P1 sur une seule ligne veut dire « dans LOOPBACK-PE2 ou dans VIA-P1 » : ce n’est pas ce qu’on veut. Pour combiner un préfixe et un next-hop, il faut deux lignes de types différents (match ip address et match ip next-hop).

Piège 3 : le filtre qui ne filtre que le RIB

Un distribute-list … in sous OSPF ou IS-IS n’empêche pas les LSA/LSP d’exister ni d’être propagées : il empêche seulement l’installation des routes dans la table de routage du routeur où il est configuré. Les voisins, eux, calculent toujours avec la base complète. Pour réellement filtrer en OSPF, il faut agir aux frontières (filtrage de LSA de type 3 sur un ABR avec area X filter-list, ou à la redistribution).

5. RPL, le langage de politiques d’IOS XR

Sur IOS XR, les route-maps sont remplacées par RPL (Routing Policy Language). Au lieu d’une liste de séquences, on écrit un petit programme avec des conditions if / elseif / else, des opérateurs logiques, des ensembles nommés réutilisables, et des politiques qui en appellent d’autres, éventuellement avec des paramètres. Les politiques sont compilées, ce qui permet d’en exécuter un très grand nombre rapidement.

5.1 Le modèle du « ticket »

Chaque route qui entre dans une politique RPL commence sans ticket. À la fin de la politique, une route sans ticket est rejetée : c’est le drop implicite. Pour passer, une route doit avoir reçu un ticket en chemin.

5.2 Syntaxe de base

! Les deux politiques que tout le monde écrit en premier
route-policy PASS-ALL
  pass
end-policy
!
route-policy DROP-ALL
  drop                      ! inutile techniquement (drop implicite), mais lisible
end-policy
!
! Conditions et branches
route-policy FROM-PEER
  if destination in (203.0.113.0/24) then
    pass
  elseif destination in (198.51.100.0/24 le 24) then
    set local-preference 200
  elseif as-path originates-from '65300' then
    drop
  else
    set med 50
  endif
end-policy

• Opérateurs logiques : not, and, or ; utilise des parenthèses pour lever toute ambiguïté (not est prioritaire sur and, lui-même prioritaire sur or).
• Comparaisons : in (appartenance à un ensemble), is, eq, ge, le (par exemple med eq 0, as-path length ge 5, local-preference le 100).
• Une politique se termine par end-policy, un ensemble par end-set.

5.3 Les ensembles (sets)

prefix-set CLIENT-A
  172.16.0.0/16 le 24,          ! virgule entre les entrées
  2001:db8:100::/40 le 48
end-set
!
as-path-set ORIGINE-CLIENT
  originates-from '65101',
  ios-regex '^65101(_65101)*$'
end-set
!
community-set GOLD
  65101:100,
  65101:[100..149]               ! plage de valeurs
end-set
!
! Ensembles « en ligne » : pratique pour un cas unique
if destination in (10.0.0.0/8 le 32, 192.168.0.0/16 le 32) then
  drop
endif

Les prefix-sets acceptent aussi eq : 10.0.6.0/24 eq 27 = tous les /27 contenus dans 10.0.6.0/24. Une adresse sans longueur (10.0.1.1) vaut /32. Si tu écris une entrée incohérente (par exemple 10.0.1.1/24), le parseur l’ignore avec un message d’avertissement : relis toujours ton ensemble après commit.

5.4 Modifier des attributs

Les attributs disponibles dépendent du point d’attache : un set local-preference n’a pas de sens dans une redistribution vers IS-IS, et le commit est refusé si la politique attachée contient un attribut incompatible. Dans le doute, utilise ? après set.

5.5 Politiques imbriquées et paramétrées

C’est là que RPL dépasse vraiment les route-maps : on écrit des briques réutilisables et on les assemble.

! Une brique commune à toutes les sessions clients
route-policy DROP-BOGONS
  if destination in BOGONS then
    drop                       ! drop dans une politique appelée = rejet définitif
  endif
end-policy
!
! Une brique paramétrée
route-policy SET-LP($lp)
  set local-preference $lp
end-policy
!
! La politique attachée au voisin assemble les briques
route-policy CLIENT-IN
  apply DROP-BOGONS
  if destination in CLIENT-A and as-path in ORIGINE-CLIENT then
    if community matches-any GOLD then
      apply SET-LP(200)
    endif
    set community (65000:1001) additive
  else
    drop
  endif
end-policy

• apply exécute la politique appelée comme si son contenu était inséré à cet endroit. Un drop ou un done dans la politique appelée termine toute l’évaluation, y compris celle de la politique appelante.
• Les paramètres commencent par $. Un même modèle (par exemple CLIENT-IN($prefixes, $asn)) peut servir à des centaines de clients avec des valeurs différentes.
• Avantage d’exploitation : on corrige une brique une seule fois et toutes les politiques qui l’appellent en profitent.

5.6 Éditer, vérifier, appliquer

! Éditer une politique existante sans tout retaper (mode EXEC)
RP/0/RP0/CPU0:PE1# edit route-policy CLIENT-IN          ! éditeur (vim ou nano selon la version)
! À la sortie de l'éditeur, XR vérifie la syntaxe et propose le commit.

! Attention : en mode config, redéfinir une politique la REMPLACE entièrement
RP/0/RP0/CPU0:PE1(config)# route-policy CLIENT-IN
% WARNING: Policy object route-policy CLIENT-IN' exists! Reconfiguring it via CLI will replace current definition. Use 'abort' to cancel.

! Vérifications
show rpl                                         ! toutes les politiques et tous les ensembles
show rpl route-policy CLIENT-IN detail           ! la politique + les ensembles et politiques qu'elle utilise
show rpl route-policy CLIENT-IN attachpoints     ! où elle est attachée (voisin, AF, sens)
show rpl route-policy states                     ! ACTIVE / INACTIVE / UNUSED
show rpl prefix-set BOGONS
show bgp ipv4 unicast neighbors 10.11.1.2 routes            ! routes acceptées après politique
show bgp ipv4 unicast neighbors 10.11.1.2 advertised-routes

6. Route-map ou RPL : tableau de correspondance

Le même besoin écrit deux fois

Besoin : depuis l’ISP, rejeter les bogons et les préfixes plus longs que /24, rejeter ce qui est originé par l’AS 65300, mettre la local-preference à 80 et marquer le reste avec 65000:3000.

! IOS XE
route-map ISP-IN deny 10
 match ip address prefix-list BOGONS
route-map ISP-IN deny 20
 match ip address prefix-list TOO-SPECIFIC
route-map ISP-IN deny 30
 match as-path 30
route-map ISP-IN permit 40
 set local-preference 80
 set community 65000:3000 additive

! IOS XR
prefix-set TOO-SPECIFIC
  0.0.0.0/0 ge 25
end-set
!
route-policy ISP-IN
  if destination in BOGONS or destination in TOO-SPECIFIC or as-path originates-from '65300' then
    drop
  endif
  set local-preference 80
  set community (65000:3000) additive
end-policy

7. Lab PNETLab : « SP Policy Lab »

Un lab de 6 routeurs qui reproduit les situations réelles d’un opérateur : un client BGP qui envoie un peu n’importe quoi, un transitaire Internet qui envoie des bogons et des préfixes trop spécifiques, un client OSPF à redistribuer, et un cœur IS-IS. Tu vas tout traiter avec des route-maps sur IOS XE et du RPL sur IOS XR. Compte 4 à 5 heures, découpables en sessions (les parties sont indépendantes une fois la partie 1 faite).

7.1 Topologie

Adapte les noms d’interfaces à tes images. Les configurations ci-dessous sont un point de départ : elles montent l’adressage, IS-IS, OSPF et les sessions BGP, sans aucune politique.

7.2 Configurations initiales

hostname PE1
interface Loopback0
 ipv4 address 10.0.0.1 255.255.255.255
interface Loopback100
 ipv4 address 10.100.1.1 255.255.255.0
interface Loopback101
 ipv4 address 10.100.2.1 255.255.255.0
interface GigabitEthernet0/0/0/0
 description vers-CE1
 ipv4 address 10.11.1.1 255.255.255.252
 no shutdown
interface GigabitEthernet0/0/0/1
 description vers-P1
 ipv4 address 10.12.0.1 255.255.255.252
 no shutdown
!
router isis CORE
 is-type level-2-only
 net 49.0000.0000.0000.0001.00
 address-family ipv4 unicast
  metric-style wide
 interface Loopback0
  passive
  address-family ipv4 unicast
 interface GigabitEthernet0/0/0/1
  point-to-point
  address-family ipv4 unicast
!
router bgp 65000
 bgp router-id 10.0.0.1
 address-family ipv4 unicast
 neighbor 10.0.0.3
  remote-as 65000
  update-source Loopback0
  address-family ipv4 unicast
   next-hop-self
 neighbor 10.11.1.2
  remote-as 65101
  description CE1
  address-family ipv4 unicast
   send-community-ebgp
   soft-reconfiguration inbound always
!
commit

hostname P1
interface Loopback0
 ipv4 address 10.0.0.2 255.255.255.255
interface GigabitEthernet0/0/0/0
 ipv4 address 10.12.0.2 255.255.255.252
 no shutdown
interface GigabitEthernet0/0/0/1
 ipv4 address 10.23.0.1 255.255.255.252
 no shutdown
!
router isis CORE
 is-type level-2-only
 net 49.0000.0000.0000.0002.00
 address-family ipv4 unicast
  metric-style wide
 interface Loopback0
  passive
  address-family ipv4 unicast
 interface GigabitEthernet0/0/0/0
  point-to-point
  address-family ipv4 unicast
 interface GigabitEthernet0/0/0/1
  point-to-point
  address-family ipv4 unicast
!
commit

hostname PE2
ip bgp-community new-format
!
interface Loopback0
 ip address 10.0.0.3 255.255.255.255
 ip router isis CORE
interface GigabitEthernet1
 description vers-P1
 ip address 10.23.0.2 255.255.255.252
 ip router isis CORE
 isis network point-to-point
 no shutdown
interface GigabitEthernet2
 description vers-ISP
 ip address 10.200.0.1 255.255.255.252
 no shutdown
interface GigabitEthernet3
 description vers-CE2
 ip address 10.22.1.1 255.255.255.252
 no shutdown
!
router isis CORE
 net 49.0000.0000.0000.0003.00
 is-type level-2-only
 metric-style wide
 passive-interface Loopback0
!
router ospf 1
 router-id 10.0.0.3
 network 10.22.1.0 0.0.0.3 area 0
!
router bgp 65000
 bgp router-id 10.0.0.3
 bgp log-neighbor-changes
 neighbor 10.0.0.1 remote-as 65000
 neighbor 10.0.0.1 update-source Loopback0
 neighbor 10.0.0.1 next-hop-self
 neighbor 10.0.0.1 send-community both
 neighbor 10.200.0.2 remote-as 65200
 neighbor 10.200.0.2 description ISP
 neighbor 10.200.0.2 soft-reconfiguration inbound
 neighbor 10.200.0.2 send-community

hostname CE1
ip bgp-community new-format
!
interface Ethernet0/0
 ip address 10.11.1.2 255.255.255.252
 no shutdown
interface Loopback1
 ip address 172.16.0.1 255.255.255.0
interface Loopback2
 ip address 172.16.1.1 255.255.255.0
interface Loopback3
 ip address 172.16.2.1 255.255.255.0
interface Loopback4
 ip address 172.16.10.1 255.255.255.128
interface Loopback5
 ip address 192.168.50.1 255.255.255.0
interface Loopback6
 ip address 10.99.99.99 255.255.255.255
!
router bgp 65101
 bgp router-id 172.16.0.1
 neighbor 10.11.1.1 remote-as 65000
 neighbor 10.11.1.1 send-community
 network 172.16.0.0 mask 255.255.255.0
 network 172.16.1.0 mask 255.255.255.0
 network 172.16.2.0 mask 255.255.255.0
 network 172.16.10.0 mask 255.255.255.128
 network 192.168.50.0 mask 255.255.255.0
 network 10.99.99.99 mask 255.255.255.255

hostname ISP
!
interface Ethernet0/0
 ip address 10.200.0.2 255.255.255.252
 no shutdown
interface Loopback1
 ip address 8.8.8.1 255.255.255.0
interface Loopback2
 ip address 1.1.1.1 255.255.255.0
interface Loopback3
 ip address 203.0.113.1 255.255.255.0
interface Loopback4
 ip address 198.51.100.129 255.255.255.128
interface Loopback5
 ip address 10.66.0.1 255.255.0.0
interface Loopback6
 ip address 192.168.77.1 255.255.255.0
!
ip prefix-list P-1111 seq 5 permit 1.1.1.0/24
route-map TO-SP permit 10
 match ip address prefix-list P-1111
 set as-path prepend 65300          ! simule un préfixe originé par l'AS 65300
route-map TO-SP permit 20
!
router bgp 65200
 bgp router-id 8.8.8.1
 neighbor 10.200.0.1 remote-as 65000
 neighbor 10.200.0.1 default-originate
 neighbor 10.200.0.1 route-map TO-SP out
 network 8.8.8.0 mask 255.255.255.0
 network 1.1.1.0 mask 255.255.255.0
 network 203.0.113.0 mask 255.255.255.0
 network 198.51.100.128 mask 255.255.255.128
 network 10.66.0.0 mask 255.255.0.0
 network 192.168.77.0 mask 255.255.255.0

hostname CE2
!
interface Ethernet0/0
 ip address 10.22.1.2 255.255.255.252
 no shutdown
interface Loopback1
 ip address 172.20.0.1 255.255.255.0
 ip ospf network point-to-point
interface Loopback2
 ip address 172.20.1.1 255.255.255.0
 ip ospf network point-to-point
!
ip route 172.21.0.0 255.255.0.0 Null0
ip route 172.22.0.0 255.255.0.0 Null0
ip prefix-list S-E1 seq 5 permit 172.21.0.0/16
route-map STATIC-TO-OSPF permit 10
 match ip address prefix-list S-E1
 set metric-type type-1
route-map STATIC-TO-OSPF permit 20
 set metric-type type-2
!
router ospf 1
 router-id 10.0.0.12
 network 10.22.1.0 0.0.0.3 area 0
 network 172.20.0.0 0.0.1.255 area 0
 redistribute static subnets route-map STATIC-TO-OSPF

7.3 Partie 1 : état des lieux (20 min)

1. Vérifie le cœur : show isis adjacency (PE1, P1), show isis neighbors (PE2), puis un ping 10.0.0.3 source 10.0.0.1 depuis PE1.
2. Vérifie les sessions BGP : show bgp ipv4 unicast summary sur PE1, show ip bgp summary sur PE2.
3. Observe la différence XR / XE : sur PE2, la session avec l’ISP reçoit tout (6 préfixes + la route par défaut), bogons compris. Sur PE1, la session avec CE1 est établie mais aucun préfixe n’est accepté. Compare show bgp ipv4 unicast neighbors 10.11.1.2 received routes (avant politique, grâce à la soft-reconfiguration) et show bgp ipv4 unicast neighbors 10.11.1.2 routes (après politique).

7.4 Partie 2 : prefix-lists et marquage côté client (30 min)

Sur papier d’abord. Parmi les six préfixes de CE1, lesquels correspondent à : (a) 172.16.0.0/16 le 24 ; (b) 172.16.0.0/16 ge 24 ; (c) 172.16.0.0/22 le 24 ; (d) 0.0.0.0/0 ge 25 ?

Sur CE1, crée une route-map TO-SP appliquée en sortie vers PE1 qui :

• pose la communauté 65101:100 sur 172.16.0.0/24 (lien principal) ;
• pose 65101:200 sur 172.16.1.0/24 (lien de secours) ;
• pose no-export sur 172.16.2.0/24 (service interne, ne doit jamais sortir sur Internet) ;
• laisse passer tout le reste sans modification (pour tester les filtres de PE1).

Vérifie avec show ip bgp neighbors 10.11.1.1 advertised-routes puis show route-map TO-SP (compteurs). N’oublie pas clear ip bgp 10.11.1.1 soft out.

7.5 Partie 3 : RPL d’entrée client sur PE1 (45 min)

Écris sur PE1 la politique CE1-IN, construite avec des briques réutilisables :

1. Un prefix-set BOGONS (0.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/3, tous en le 32). Attention : les préfixes de CE1 sont dans 172.16.0.0/12. Que faire ? (Indice : un client utilisant de l’adressage privé est courant dans un VPN ; ici, considère que 172.16.0.0/16 est son allocation et teste d’abord ses préfixes autorisés.)
2. Un prefix-set CLIENT-CE1 : 172.16.0.0/16 le 24.
3. Un as-path-set ORIGINE-CE1 : routes originées par 65101, prepends de 65101 autorisés.
4. Deux community-set : CE1-PRIMARY (65101:100) et CE1-BACKUP (65101:200).
5. Une politique paramétrée SET-LP($lp).
6. CE1-IN : n’accepte que les préfixes de CLIENT-CE1 originés par CE1 ; local-preference 200 pour PRIMARY, 50 pour BACKUP ; ajoute la communauté 65000:1001 (« route client ») sans effacer les autres ; rejette tout le reste. Les bogons hors allocation client sont rejetés.

Résultat attendu sur PE1 (show bgp ipv4 unicast et show bgp ipv4 unicast 172.16.2.0/24) :

7.6 Partie 4 : RPL de sortie vers CE1 (15 min)

CE1 ne doit recevoir que la route par défaut. Écris CE1-OUT et attache-la. Vérifie sur CE1 : show ip bgp ne doit contenir que 0.0.0.0/0 en plus de ses propres préfixes. Bonus : transforme-la en politique paramétrée réutilisable DEFAULT-ONLY.

7.7 Partie 5 : route-map d’entrée Internet sur PE2 (45 min)

Sur PE2, écris ISP-IN avec des prefix-lists et une as-path access-list :

• rejette les bogons (même liste que BOGONS) ;
• rejette tout préfixe plus spécifique que /24 ;
• rejette les routes originées par l’AS 65300 ;
• accepte le reste (route par défaut comprise) avec local-preference 80 et la communauté 65000:3000 ajoutée.

Applique, puis clear ip bgp 10.200.0.2 soft in. Compare show ip bgp neighbors 10.200.0.2 received-routes et show ip bgp neighbors 10.200.0.2 routes. Lis les compteurs avec show route-map ISP-IN.

7.8 Partie 6 : route-map de sortie Internet sur PE2 (30 min)

Écris ISP-OUT : n’annonce à l’ISP que les routes portant la communauté 65000:1001 (routes clients) ; pour 172.16.1.0/24 (secours), ajoute deux prepends de 65000. Tout le reste est filtré (ne jamais réannoncer un transitaire à un autre !).

Résultat attendu sur l’ISP (show ip bgp) :

7.9 Partie 7 : IGP et redistribution (45 min)

7a. Filtrer le RIB OSPF sur PE2

1. Sur PE2, observe show ip route ospf : routes O (172.20.x), O E1 172.21.0.0/16 et O E2 172.22.0.0/16.
2. Crée la route-map NO-E1 (rejette route-type external type-1, laisse passer le reste) et applique-la avec distribute-list route-map NO-E1 in sous router ospf 1.
3. Constate que 172.21.0.0/16 a disparu de show ip route mais est toujours présente dans show ip ospf database external 172.21.0.0. Tu viens de vérifier que le distribute-list filtre le RIB, pas la LSDB.

7b. Redistribuer OSPF dans BGP

1. Sous router bgp 65000 de PE2, ajoute simplement redistribute ospf 1. Regarde ce qui arrive sur PE1 : seules les routes OSPF internes sont redistribuées (172.20.0.0/24, 172.20.1.0/24…), pas 172.22.0.0/16.
2. Remplace par redistribute ospf 1 match internal external 2 route-map OSPF-TO-BGP, avec une route-map qui pose la communauté 65000:2002 et origin igp.
3. Question : pourquoi 172.21.0.0/16 (E1) n’apparaît-elle jamais dans BGP, même avec external 1 ? (Réponse : la redistribution prend ses routes dans le RIB, et le distribute-list de l’étape 7a l’en a retirée.)

7c. Redistribuer des connected dans IS-IS avec RPL (PE1)

1. Écris CONN-TO-ISIS : 10.100.1.0/24 avec métrique IS-IS 11 et tag 100 ; 10.100.2.0/24 avec métrique 22 et tag 200 ; tout le reste rejeté (les loopbacks et liens déjà dans IS-IS ne doivent pas être redistribués).
2. Applique : router isis CORE / address-family ipv4 unicast / redistribute connected route-policy CONN-TO-ISIS.
3. Sur PE2, show ip route 10.100.1.0 : métrique attendue 31 (11 + 10 + 10) et « Route tag 100 » ; pour 10.100.2.0/24, métrique 42 et tag 200.

7.10 Partie 8 : RPL avancé (45 min)

8a. pass contre done

Attache temporairement à CE1 (en entrée) la politique suivante, puis remplace le premier pass par done. Note la local-preference de 172.16.0.0/24 dans les deux cas.

route-policy EXP-1
  if destination in (172.16.0.0/24) then
    pass
  endif
  if destination in (172.16.0.0/16 le 24) then
    set local-preference 10
  endif
end-policy

8b. Longueur d’AS-path

Sur CE1, ajoute 5 prepends (65101) sur 172.16.1.0/24. Modifie CE1-IN avec edit route-policy CE1-IN pour rejeter toute route dont l’AS-path est plus long que 4 (as-path length ge 5). Vérifie que XR réévalue la route sans clear. Retire ensuite les prepends sur CE1.

8c. Outils de vérification

Passe en revue show rpl route-policy states, show rpl route-policy CE1-IN detail, show rpl route-policy SET-LP attachpoints (rien : elle n’est attachée qu’indirectement) et show rpl route-policy CE1-IN attachpoints. Supprime EXP-1 : elle doit apparaître en UNUSED avant.

7.11 Partie 9 : break / fix (45 min)

Provoque chaque panne, observe le symptôme, explique la cause, répare. Fais-les dans l’ordre que tu veux.

7.12 Partie 10 : grille de validation finale

7.13 Solutions

ip prefix-list C-PRIMARY seq 5 permit 172.16.0.0/24
ip prefix-list C-BACKUP seq 5 permit 172.16.1.0/24
ip prefix-list C-LOCAL seq 5 permit 172.16.2.0/24
!
route-map TO-SP permit 10
 match ip address prefix-list C-PRIMARY
 set community 65101:100
route-map TO-SP permit 20
 match ip address prefix-list C-BACKUP
 set community 65101:200
route-map TO-SP permit 30
 match ip address prefix-list C-LOCAL
 set community no-export
route-map TO-SP permit 40
!
router bgp 65101
 neighbor 10.11.1.1 route-map TO-SP out
!
! puis : clear ip bgp 10.11.1.1 soft out

prefix-set BOGONS
  0.0.0.0/8 le 32,
  10.0.0.0/8 le 32,
  100.64.0.0/10 le 32,
  127.0.0.0/8 le 32,
  169.254.0.0/16 le 32,
  172.16.0.0/12 le 32,
  192.168.0.0/16 le 32,
  224.0.0.0/3 le 32
end-set
!
prefix-set CLIENT-CE1
  172.16.0.0/16 le 24
end-set
!
as-path-set ORIGINE-CE1
  ios-regex '^65101(_65101)*$'
end-set
!
community-set CE1-PRIMARY
  65101:100
end-set
!
community-set CE1-BACKUP
  65101:200
end-set
!
route-policy SET-LP($lp)
  set local-preference $lp
end-policy
!
route-policy DROP-BOGONS
  if destination in BOGONS then
    drop
  endif
end-policy
!
route-policy CE1-IN
  if destination in CLIENT-CE1 and as-path in ORIGINE-CE1 then
    if community matches-any CE1-PRIMARY then
      apply SET-LP(200)
    elseif community matches-any CE1-BACKUP then
      apply SET-LP(50)
    endif
    set community (65000:1001) additive
    done                                  ! préfixe client valide : accepté, on s'arrête là
  endif
  apply DROP-BOGONS                       ! le reste : bogons rejetés…
  drop                                    ! …et tout ce qui n'est pas un préfixe client aussi
end-policy
!
route-policy CE1-OUT
  if destination in (0.0.0.0/0) then
    pass
  else
    drop
  endif
end-policy
!
route-policy CONN-TO-ISIS
  if destination in (10.100.1.0/24) then
    set isis-metric 11
    set tag 100
  elseif destination in (10.100.2.0/24) then
    set isis-metric 22
    set tag 200
  else
    drop
  endif
end-policy
!
router bgp 65000
 neighbor 10.11.1.2
  address-family ipv4 unicast
   route-policy CE1-IN in
   route-policy CE1-OUT out
!
router isis CORE
 address-family ipv4 unicast
  redistribute connected route-policy CONN-TO-ISIS
!
commit

ip prefix-list BOGONS seq 5 permit 0.0.0.0/8 le 32
ip prefix-list BOGONS seq 10 permit 10.0.0.0/8 le 32
ip prefix-list BOGONS seq 15 permit 100.64.0.0/10 le 32
ip prefix-list BOGONS seq 20 permit 127.0.0.0/8 le 32
ip prefix-list BOGONS seq 25 permit 169.254.0.0/16 le 32
ip prefix-list BOGONS seq 30 permit 172.16.0.0/12 le 32
ip prefix-list BOGONS seq 35 permit 192.168.0.0/16 le 32
ip prefix-list BOGONS seq 40 permit 224.0.0.0/3 le 32
ip prefix-list TOO-SPECIFIC seq 5 permit 0.0.0.0/0 ge 25
ip prefix-list CE1-BACKUP seq 5 permit 172.16.1.0/24
ip as-path access-list 30 permit _65300$
ip community-list standard CUST-ROUTES permit 65000:1001
!
route-map ISP-IN deny 10
 match ip address prefix-list BOGONS
route-map ISP-IN deny 20
 match ip address prefix-list TOO-SPECIFIC
route-map ISP-IN deny 30
 match as-path 30
route-map ISP-IN permit 40
 set local-preference 80
 set community 65000:3000 additive
!
route-map ISP-OUT permit 10
 match community CUST-ROUTES
 match ip address prefix-list CE1-BACKUP       ! ET : route client ET préfixe de secours
 set as-path prepend 65000 65000
route-map ISP-OUT permit 20
 match community CUST-ROUTES
! (deny implicite pour tout le reste)
!
route-map NO-E1 deny 10
 match route-type external type-1
route-map NO-E1 permit 20
!
route-map OSPF-TO-BGP permit 10
 set community 65000:2002 additive
 set origin igp
!
router ospf 1
 distribute-list route-map NO-E1 in
!
router bgp 65000
 redistribute ospf 1 match internal external 2 route-map OSPF-TO-BGP
 neighbor 10.200.0.2 route-map ISP-IN in
 neighbor 10.200.0.2 route-map ISP-OUT out
!
! puis : clear ip bgp 10.200.0.2 soft

8. Fiche de révision

9. Quiz

10. Glossaire

11. Sources et pour aller plus loin

• Programme officiel de l’examen Cisco 350-501 SPCOR (objectif 2.5).
• CCNP SPCOR 350-501 Official Cert Guide, Cisco Press, chapitre 4 (référence de révision ; article et lab rédigés indépendamment).
• Cisco : « Implementing Routing Policy » (guides de configuration IOS XR) ; documentation des route-maps et prefix-lists IOS XE.
• RFC 8212 (comportement par défaut de l’eBGP sans politique), RFC 1997 (communautés BGP), RFC 6996 et RFC 5398 (ASN privés et de documentation), RFC 5737 (préfixes de documentation utilisés dans le lab).
• IP Routing on Cisco IOS, IOS XE, and IOS XR, Cisco Press, pour approfondir la logique des prefix-lists.

Article rédigé pour Les Z’héros du Réseau dans le cadre de la série de préparation au CCNP Service Provider (350-501 SPCOR). Chapitres liés : IS-IS, OSPF et BGP.