Topologie:
Figure 1 – Numéros d'AS BGP
Notes relatives au TP
Le module précédent a permis de
s'initier à la configuration de BGP externe, sans toutefois expliquer comment
contrôler quels sont les réseaux annoncés à quels AS. Le but de ce module est
donc de vous présenter les types de politiques de routage disponibles en
utilisant BGP.
Dans les étapes 2 à 6, nous
allons configurer chaque AS pour en faire un “AS refusant le transit (non-transit
AS)”, c'est à dire que l'AS refusera aux AS auxquels il est connecté
d'acheminer du traffic de l'un vers l'autre. Cela signifie que la connectivité
dans la salle sera rompue - par exemple, AS3 ne sera plus capable de voir les
réseaux d'AS10, etc... C'est un choix délibéré ayant pour but de montrer
l'efficacité du filtrage BGP.
Ceci est réalisé lors de
l'étape 2, en configurant un filtre pour les routes sortantes (outgoing route
filter) permettant l'envoi des seuls préfixes locaux vers les peers eBGP. Nous
nous assurons également que les peers nous envoient seulement leurs préfixes
locaux, grâce à l'ajout d'un filtre entrant (incoming filter). En règle
générale, il est bon de configurer des filtres dans les deux sens, afin de
protéger contre les erreurs de configurations des deux côtés du peering. Lors
de l'étape 4, nous allons utiliser les filtres AS-PATH. Enfin dans l'étape 6,
nous arriverons au même résultat en utilisant les communautés BGP.
Important : chaque étape doit être suivie et terminée par
tous les participants avant que la
prochaine étape puisse démarrer, puisque les techniques utilisées changent
à chaque étape et qu'elles ne peuvent pas fonctionner dans un environnement
incohérent. Ne démarrez pas l'étape suivante sans avoir obtenu le feu vert de
vos instructeurs. Si vous démarrez sans attendre, il est très probable que le
routage cesse de fonctionner, empêchant ainsi les autres groupes de comprendre
les effets réels de leurs configurations.
Important : gardez la configuration utilisée pour le Module 6.
Étapes du TP
1.
Implémentation
des politiques BGP. Avant de faire la moindre configuration dans ce
module, il faut impérativement comprendre comment implémenter les politiques
BGP. Il est possible d'ajouter des listes de préfixes (prefix lists), des
filtres as-path (as-path filters) ou des route-maps directement depuis la CLI.
Cependant, ils ne seront pris en compte que pour les updates BGP reçues après
l'ajout de ces nouvelles politiques. Ceci s'explique par le fait que BGP envoie
des updates incrémentales décrivant les changements aux routes annoncées ou
retirées. Pour appliquer une politique de routage à l'intégralité de la table
de routage BGP reçue ou envoyée à un peer, la session BGP doit être "réinitialisée".
Dans les anciennes versions de l'IOS, cela signifiait détruire la session BGP
puis la redémarrer. Cependant, comment on peut l'imaginer, cela causait de
graves problèmes de stabilité sur le réseau du fournisseur. Ainsi, le RFC2918
(Route Refresh Capability / Fonction de rafraîchissement de route) a été ajouté
à la plupart des implémentations modernes de BGP pour permettre des mises à
jour correctes des sessions BGP lorsque des changements de politiques les rendaient
nécessaires.
Pour implémenter les changements de politiques
dans tous les exemples à venir, utilisez les commandes suivantes, par exemple
pour implémenter de nouvelles politiques entrantes et sortantes sur le peering
entre Routeur 1 et Routeur 13:
Router1# clear ip bgp 10.10.15.14 out
Router1# clear ip bgp 10.10.15.14 in
Note 1: N'oubliez pas les sous-commandes 'out' et 'in' dans les
commandes clear ci-dessus - si vous les oubliez, cela forcera une
réinitialisation complète de la session BGP. Relisez la présentation BGP si
vous n'êtes plus sûr de la raison pour laquelle c'est une mauvaise idée.
Note 2: Plutôt que d'utiliser l'adresse IP du voisin pour
rafraîchir la session BGP, il est également possible d'utiliser son numéro d'AS
(ASN). Puisque le routeur 13 est dans l'AS 40, l'autre jeu de commandes
possible serait :
Router1# clear ip bgp 40 out
Router1# clear ip bgp 40 in
Filtrage en
utilisant les listes de préfixes (prefix-lists)
2. Configuration des filtres de préfixes basés sur
les adresses réseau. Pour cette configuration, nous allons utiliser les
listes de préfixes, qui sont une méthode de contrôle des informations de
réseaux échangées au sein des peerings BGP. Le but de cette manoeuvre est de
configurer les peerings eBGP de sorte que seuls les réseaux des AS voisins soient échangés.
Exemple:
Routeur R13 (peering avec R1)
!
ip
prefix-list out-peer permit 10.40.0.0/20
ip
prefix-list out-peer deny 0.0.0.0/0 le 32
!
ip
prefix-list in-peer permit 10.10.0.0/20
ip
prefix-list in-peer deny 0.0.0.0/0 le 32
!
router
bgp 40
no synchronization
network 10.40.0.0 mask 255.255.240.0
neighbor 10.10.15.13 remote-as 10
neighbor 10.10.15.13 description eBGP peering avec
Routeur1
neighbor 10.10.15.13 prefix-list out-peer out
neighbor 10.10.15.13 prefix-list in-peer in
no auto-summary
!
Exemple: Routeur
R1 (peering avec R13)
!
ip
prefix-list out-peer permit 10.10.0.0/20
ip
prefix-list out-peer deny 0.0.0.0/0 le 32
!
ip
prefix-list in-peer permit 10.40.0.0/20
ip
prefix-list in-peer deny 0.0.0.0/0 le 32
!
router
bgp 10
no synchronization
network 10.10.0.0 mask 255.255.240.0
neighbor 10.10.15.14 remote-as 40
neighbor 10.10.15.14 description Peering avec
Routeur13
neighbor 10.10.15.14 prefix-list out-peer out
neighbor 10.10.15.14 prefix-list in-peer in
no auto-summary
!
Note : une
liste de préfixes IOS possède toujours une dernière entrée implicite deny any même si elle n'est pas mentionnée
dans la configuration. Certains FAIs ajoutent l'entrée implicite deny any parce qu'ils considèrent que
c'est une bonne habitude, et une mesure de sécurité.
Note : ces
listes de préfixes sont seulement appliquées aux peerings avec les autres AS.
On les appelle des peerings externes (utilisés par eBGP). Il n'y a généralement
pas besoin d'appliquer ce genre de filtres aux peerings iBGP.
ARRÊTEZ ET ATTENDEZ ICI
3. Retrait de la configuration précédente. Cette
étape illustre comment retirer la configuration définie à l'étape précédente. C'est
indispensable avant de passer à la suite.
Exemple:
Routeur R1
Router1#conf t
Router1(config)#router
bgp 10
!
! On enleve d’abord la liste de prefixes du peering BGP avec R13
!
Router1(config-router)#no
neighbor 10.10.15.14 prefix-list out-peer out
Router1(config-router)#no
neighbor 10.10.15.14 prefix-list in-peer in
!
! Maintenant on enleve les listes ells-memes
!
Router1(config)#no
ip prefix-list out-peer
Router1(config)#no
ip prefix-list in-peer
!
! Voila, la configuration est nettoyee, comme il faut.
!
Router1(config)#end
!
! Puis on rafraichit le peering BGP pour enlever l’ancienne politique
!
Router1#clear
ip bgp 40 out
Router1#clear
ip bgp 40 in
Router1#
Filtres AS-PATH
4. Configuration de filtres de préfixes basés sur
l'attribut AS path : Durant
cette étape nous allons utiliser les listes d'accès AS path, qui sont un autre
moyen de contrôler les réseaux échangés dans les peerings BGP.
Exemple :
Routeur R14 (peering avec R2)
ip
as-path access-list 2 permit ^$
ip
as-path access-list 3 permit ^10$
!
router
bgp 40
neighbor 10.40.15.18 remote-as 10
neighbor 10.40.15.18 filter-list 2 out
neighbor 10.40.15.18 filter-list 3 in
!
Exemple
: Routeur R2 (peering avec R14)
ip
as-path access-list 2 permit ^$
ip
as-path access-list 3 permit ^40$
!
router
bgp 10
neighbor 10.40.15.17 remote-as 40
neighbor 10.40.15.17 filter-list 2 out
neighbor 10.40.15.17 filter-list 3 in
!
Q. Pourquoi
est-ce que la liste de filtres sortants arrive à une correspondance pour
l'as-path null et non le numéro d'AS local, dans les exemples ci-dessus ?
A. Parce
que l'attribut AS-PATH est positionné après application des listes de préfixes,
filtres d'as-path et route-maps. Si l'AS local était inclus dans la
configuration des listes de filtres sortants, les préfixes seraient ignorés
parce que l'attribut AS-PATH n'est pas encore positionné à ce moment.
Pour
vérifier que l'expression régulière fonctionne comme prévu, utilisez la
commande exec
“show
ip bgp regexp
<expression-reguliere>” pour montrer tous les chemins qui
correspondent à l'expression régulière spécifiée. N'oubliez pas que la commande
“clear ip bgp <neighbour address>
[in|out]” est requise pour implémenter ce filtre.
Notez
bien que les filtres AS Path autorisent tous les préfixes émis par l'AS voisin
- dans l'exemple précédent
qui utilisait les filtres de préfixes, seuls les agrégés de l'AS voisin
pouvaient passer les filtres.
5. Retrait de la configuration précédente. Cette
étape illustre comment retirer la configuration définie à l'étape précédente. C'est
indispensable avant de passer à la suite.
Exemple : Routeur
2
Router1#conf t
Router1(config)#router bgp 10
!
! On enleve la liste de filtres du peering BGP avec R14
!
Router1(config-router)#no
neighbor 10.40.15.17 filter-list 2 out
Router1(config-router)#no
neighbor 10.40.15.17 filter-list 3 in
!
! Puis les listes de filtres elles-memes
!
Router1(config)#no
ip as-path access-list 2
Router1(config)#no
ip as-path access-list 3
!
! Voila, la configuration est nettoyee, comme il faut.
!
Router1(config)#end
!
! Puis on rafraichit le peering BGP pour enlever l’ancienne politique
!
Router1#clear ip bgp
10.40.15.17 in
Router1#clear ip bgp
10.40.15.17 out
Router1#
Communautés BGP pour le filtrage (et
route-maps)
6. Introduction aux concepts de communautés BGP
et route-maps. Cette étape explique comment utiliser ces concepts
pour le tagging, l'identification et finalement le filtrage de préfixes. Nous
obtiendrons des résultats similaires à ceux des étapes précédentes.
Sur chaque routeur, configurez BGP de sorte à ce
qu'il envoie à ses peers externes une communauté pour tous les préfixes appartenant à l'AS local. La communauté doit
suivre le format [Numéro d'AS]:[Numéro de
Routeur]. Par exemple, Routeur8 doit utiliser la communauté 30:8.
Exemple : Routeur R8
! Affiche les communautes en utilisant le format 16-bits:16-bits plutot que
! un seul entier de 32-bits.
!
ip
bgp-community new-format
!
ip
prefix-list out-match permit 10.30.0.0/20 le 26
!
route-map outfilter permit 10
match ip address prefix-list out-match
set community 30:8
!
router bgp 30
neighbor 10.20.15.17 remote-as 20
neighbor 10.20.15.17 route-map outfilter out
neighbor 10.20.15.17 send-community
!
Notes :
1)
La commande show
ip bgp <network> permet de voir l'attribut de communauté dans la
table BGP.
2)
L'attribut de communauté est un champ défini sur
32 bits. Par contention établie à l'IETF, ce champ est séparé en deux
sous-champs de 16 bits chacun pour une interprétation plus aisée. Les 16 bits
de poids fort contiennent le numéro d'AS tandis que les 16 bits de poids faible
représentent une valeur dont la signification est bien définie pour les deux AS
participant au peering. Les seules exceptions sont les chaînes de caractères
définies spécifiquement, telles que no-export et local-as.
Q: Pourquoi faut-il mettre send-community pour les peerings eBGP ?
A: Puisque les valeurs de
communauté ne sont pas propagées par défaut, vous devez le configure
explicitement sur le routeur.
7. Retrait de la configuration précédente. Cette
étape illustre comment retirer la configuration définie à l'étape précédente. C'est
indispensable avant de passer à la suite.
Exemple :
Routeur 9
Router8#conf t
Router8(config)#router bgp 30
!
! On enleve d’abord la route-map du peering eBGP
!
Router8(config-router)#no
neighbor x.x.x.x route-map outfilter out
!
! Puis la route-map elle-meme
!
Router8(config)#no
route-map outfilter
!
! Et maintenant la liste de prefixes utilise par la route-map
!
Router8(config)#no
ip prefix-list out-match
!
! Voila, la configuration est nettoyee, comme il faut.
!
Router8(config)#end
!
! Puis on rafraichit le peering BGP pour enlever l’ancienne politique
!
Router8#clear
ip bgp 10.20.15.17 out
Router9#
Communautés BGP
8. Configuration des communautés BGP. Lors
de l'étape 6, la communauté d'appartenance d'un réseau était générée au point
de peering où les deux routeurs BGP pouvaient communiquer. Malgré l'intérêt
pédagogique de cette technique, la façon de faire usuelle, est d'attacher
l'information de communauté à un réseau lorsque le réseau est injecté dans la
table de routage BGP.
Chaque
groupe doit assigner une communauté au bloc réseau client (le /26) dont il
est l'origine (originator) pour BGP. Relisez la documentation de BGP pour
trouver comment faire. Chaque routeur doit assigner une communauté de format [Numéro d'AS]:[Numéro de Routeur]
exactement comme à l'étape précédente.
Exemple : Routeur R3
ip bgp-community new-format
!
route-map
community-tag permit 10
set community 10:3
!
router
bgp 10
no synchronization
network 10.10.0.128 mask 255.255.255.192
route-map community-tag
neighbor 10.20.15.1 remote-as 20
neighbor 10.20.15.1 send-community
no auto-summary
!
ip
route 10.10.0.128 255.255.255.192 null0
Vérifiez que le routeur
apparaisse bien avec sa communauté dans la table de routage BGP.
Q: Pourquoi est-ce que les peers
externes, mais pas les internes, sont-ils les seuls à voir la communauté
configurée sur le réseau ?
A: Voir précédemment. Tous les
peerings nécessitent la sous-commande BGP send-community pour pouvoir propager
l'attribut de communauté à ses peers.
9. Communautés sur les peerings BGP internes. Comme pour l'étape précédente, paramétrez
maintenant les peerings internes pour que l'attribut de communauté de votre
réseau soit envoyé aux peers locaux.
Astuce : ajoutez simplement la ligne de
configuration neighbor x.x.x.x
send-community pour tous les peerings iBGP. N'oubliez pas de rafraîchir les
sessions de peering BGP pour que les changements de configuration soient
implémentés.
10. Configuration du filtre de préfixe entrant basé
sur l'attribut de communauté. L'objectif
ici est d'accepter seulement les réseaux reçus par le peering BGP externe du
voisin. (C'est similaire à ce qui était fait aux étapes 2 et 4 avec les
filtrages par préfixe ou AS path). Par exemple, R13 devrait seulement accepter
les réseaux dont R1 est origine, et devrait utiliser l'information de
communauté que R1 a ajouté au réseau pour y parvenir.
Exemple
: Routeur R13
ip
community-list 3 permit 10:1
!
route-map
infilter permit 10
match community 3
!
router
bgp 40
neighbor 10.10.15.13 route-map infilter in
!
Le
choix du numéro de liste de communauté (community-list) revient à chaque
groupe. En effet, il n'est annoncé dans aucun peering BGP ni utilisé de la
moindre façon à part pour identifier la liste de communauté (de façon similaire
au numéro d'access-list).
11. Mise en place de l'attribut local-preference sur
les routes eBGP reçues. Dans cet exemple, une préférence locale va être
mise en place pour les routes correspondant au filtre de communauté mis en
place à l'étape 10. Conservez la route-map utilisée à l'étape 10 - une ligne de
configuration supplémentaire va y être ajoutée. Il faut également permettre les
autres réseaux reçus par les filtres et dont la préférence locale a la valeur
par défaut.
Q. Pourquoi ?
A. Sans la seconde directive, la
route-map implémente une directive deny par défaut et aucun autre préfixe n'est
autorisé.
Exemple :
route-map infilter permit 10
match
community 3
set local-preference 120
!
route-map infilter permit 20
Souvenez-vous
qu'après la définition d'une nouvelle politique, la session BGP doit être
rafraichie pour que cette nouvelle politique puisse être mise en oeuvre. Comme
le routeur ne conserve pas systématiquement toutes les mises à jour reçues de
son peer, cette étape est nécessaire. Vous pouvez dans ce but utiliser la
commande exec “clear ip bgp <peer
address> in”.
Groupes de peering BGP (peer-groups)
12. Configuration de la fonctionnalité de groupes de
peering pour les peers iBGP. Les groupes de peering BGP
aident a réduire la charge machine du routeur en générant et propageant des
mises à jour vers les peers qui ont la même politique. Cette étape configure des
groupes de peering BGP for les peers iBGP dans chaque AS. Remplacez la
configuration individuelle de chaque peer iBGP par une configuration de groupe
de peering, comme dans l'exemple ci-dessous.
Exemple : Routeur R9
router bgp 30
neighbor
ibgp-peers peer-group
neighbor ibgp-peers description Groupe de
peering utilise pour iBGP
neighbor ibgp-peers remote-as 30
neighbor ibgp-peers update-source loopback 0
neighbor ibgp-peers send-community
neighbot ibgp-peers next-hop-self
neighbor ibgp-peers password cisco
!
Note : l'ancienne
configuration antérieure au groupe de peering doit être retirée avant de
convertir vers la configuration utilisant les groupes de peering.
router
bgp 30
no neighbor 10.30.15.224
no neighbor 10.30.15.226
!
neighbor 10.30.15.224 peer-group ibgp-peers
neighbor 10.30.15.226 peer-group ibgp-peers
!
Q: Quels sont les avantages
procurés par les groupes de peering ?
A: Les groupes de peering BGP
permettent d'utiliser une configuration commune sur plusieurs peers BGP.
L'application la plus courante est pour iBGP. Tous les peers BGP internes dans
un réseau d'un même FAI ont tendance à avoir la même relation les uns avec les
autres. Plutôt que de définir une configuration conséquente par peer, et
d'avoir à changer chaque peering quand il faut faire des modifications, la
configuration peut être définie dans un groupe de peering, et seul le groupe
doit être changé pour modifier la configuration de tous les peers iBGP. Cela
réduit considérablement la surcharge de travail induite par toute modification,
la charge processeur du routeur et simplifie grandement les configurations et
leur visualisation.
Il est
fortement recommandé d'utiliser la sous-commande peer-group de façon
systématique pour la configuration de peers BGP. Comme dit précédemment, la
plupart des peers iBGP ont la même configuration, il est donc très important de
simplifier les configurations pour tous les intervenants du réseau. De plus,
une configuration qui utilise beaucoup de groupes de peering est habituellement
plus lisible qu'une configuration ayant une section distincte par peer, en
particulier dans les réseaux ayant de nombreux peers.
Note : à
l'avenir dans ce workshop, toute configuration devra être faite avec des
groupes de peering autant que possible (surtout pour les configurations iBGP).
13. Résumé : Dans ce module, nous avons
découvert certaines des fonctionnalités de configuration des peerings BGP
disponibles dans l'IOS Cisco. Nous encourageons le lecteur à essayer toutes
sortes de permutations des exemples donnés au cours du TP. L'utilisation des
communautés est en train de gagner en popularité maintenant que la
fonctionnalité est reconnue pour son utilité dans le contrôle des politiques de
routage entre différents AS. Les rafraîchissements de route et les groupes de
peering sont également beaucoup utilisés dans les backbones de FAI car ils
facilitent énormément l'administration et la configuration d'un réseau
opérationnel.
Questions de revisions :
- Pourquoi l'utilisation des rafraichissements
de routes est-elle la meilleure méthode d'implémentation des nouvelles
politiques BGP ?
- Pourquoi l'utilisation des filtres AS-PATH
fournit-elle moins de granularité queles filtres de préfixes pour une
session BGP ? Quelle est la meilleure solution pour un réseau de FAI, et
pourquoi ?
- Quand faut-il mettre l'attribut de communauté
sur un préfixe BGP ?
- Est-ce que l'IOS envoie les communautés BGP
par défaut pour iBGP ? et pour eBGP ? Dans la négative, de quoi les
opérateurs doivent-ils se souvenir ?
