Pour industrialiser des nouveaux Ă©quipements ASR 99xx sous Cisco IOS-XR, j’ai Ă©crit un script pour convertir rapidement la configuration des interfaces L3 IPv4 / IPv6, l’IGP OSPF/OSPFv3 et ses costs, ainsi que le routage BGP depuis une configuration de Cisco 6K sous IOS. Ceci afin principalement d’Ă©viter les erreurs de ctrl+c / ctrl+v (ou l ‘effet PEBKAC) .
La majoritĂ© des changements est facile Ă apprĂ©hender entre IOS et IOS-XR, mĂȘme si parfois les choix technologiques entrainent de changer sa maniĂšre de corrĂ©ler la technique rĂ©seau et la configuration des Ă©quipements. Exemple : la MTU n’est plus considĂ©rĂ©e au niveau 3 sur un IOS-XR, mais comme la MTU niveau 2, voir ASR9000/XR: Understanding MTU calculations ou
MTU Behavior on Cisco IOS XR and Cisco IOS Routers).
Mais le changement majeur de IOS-XR, c’est l’arrivĂ©e des route-policies. Pour ceux qui ont l’habitude des SUP720 / SUP2T, lorsque l’on configure une session BGP, on configure 3 Ă©lĂ©ments communs en IN / OUT :
- filter-list [AS_PATH] (in|out) : On configure ici la liste des AS / AS_PATH BGP autorisés ou interdits en in et out
- prefix-list [PFX_LIST] (in|out) : On configure ici la liste des préfixes annoncés ou interdits en in et out
- route-map [ROUTEMAP] (in|out) : On configure ici la route-map in et out qui permettra de modifier les attributs BGP, les next-hop …. Tout un ensemble dâĂ©lĂ©ments nĂ©cessaires pour maitriser la rĂ©partition de trafic, les commits en fonction des transitaires, l’acceptation des default routes ou de la DFZ, etc ….
Sur Cisco IOS-XR, plus besoin de lire 1000 lignes Ă©parpillĂ©es dans la configuration pour comprendre la logique de tel ou tel neighbor BGP ! On peut avoir le tableau d’Ă©quivalences suivant:
|
Cisco IOS |
Cisco IOS-XR |
Sets d’AS Paths |
ip as-path access-list |
as-path-set |
Sets de préfixes |
ip prefix-list |
prefix-set |
Configuration neighbor BGP |
filter-list
prefix-list
route-map |
route-policy |
DĂ©sormais, les annonces, les filtres et la modification des attributs BGP se rĂ©alisent dans un seul et mĂȘme endroit : la route-policy.
Ces route-policies sont un peu dĂ©routantes au dĂ©but, car il fait penser Ă tout. Plus possible de changer les annonces avec la modification rapide d’un prefix-list en out avec un clear ip bgp soft.
La logique de ces routes policies est beaucoup plus “programmatique” qu’avant :
- Par dĂ©faut, on interdit tout (deny / drop implicite). Il n’y a donc plus de deny non plus dans les prefix-set ou les as-path-set, car il faut utiliser le mot clĂ© “not” avant un test.
- Les conditions sont faites par des conditions “if then” > “elseif then” > “else” > “endif”, comme en bash. L’ordre des conditions remplace les numĂ©ros de sĂ©quences bien connues des route-maps.
- L’exĂ©cution d’une route-policy se fait Ă l’aide d’un “ticket” qui peut changer de valeur en fonction des conditions :
- mot clĂ© “PASS” : L’exĂ©cution continue et on autorise, tant que le reste de la RPL ne drop pas (le deny implicite ne s’applique pas)
- mot clĂ© “SET” : MĂȘme usage que “PASS”, mais on ajoute la modification des attributs BGP
- mot clĂ© “DONE” : L’exĂ©cution s’arrĂȘte avec un “PASS”
- mot clĂ© “DROP”: L’exĂ©cution s’arrĂȘte avec un deny explicite.
Exemple simple et stupide !
route-policy example
# On autorise les AS_PATH dans allowed-ases
# On évite la default route dans default-route
if (as-path in allowed-ases and not destination in default-route) then
pass
# On set le local-pref Ă 20 si on tombe sur la default-route
elseif (destination in default-route) then
set local-preference 20
# Sinon on laisse passer le reste avec un local-preference a 10
else
set local-preference 10
endif
# Ici, on a un drop implicite, d'oĂč le dernier set
end-policy
On peut aussi faire un appel à des routes-policies de maniÚre imbriqué, en passant des variables :
route-policy set_localpref($pref)
set local-pref $pref
end-policy
Dans la route-policy précédente, il nous suffit donc de faire
else
apply set_localpref(10)
endif
L’exemple ci-dessus n’est pas forcĂ©ment le plus intelligent, mais en Ă©largissant Ă des exemples concrets, on prend conscience de la puissance des route-policies sous IOS-XR. Il est mĂȘme possible Ă priori d’appeler une route-policy avec un argument dans la configuration d’un neighbor BGP.
Cette nouvelle maniĂšre de penser / Ă©crire les optimisations et actions sur le routage est trĂšs percutante, mĂȘme si le changement est difficile Ă apprĂ©hender et nĂ©cessite de la rĂ©flexion.
En effet, dans la rĂ©alisation de mon script de migration, j’ai pu convertir les as-path access-list, les prefix-list, et les route-maps, mais le nombre de combinaisons possibles pour les neighbors BGP m’a empĂȘcher d’automatiser leur conversion de maniĂšre simple. Le changement dans l’application des paramĂštres de configuration du neighbor BGP nĂ©cessite une revue complĂšte et manuelle des paramĂštres de configuration du neighbor BGP.
Pour en savoir plus, je vous engage Ă lire ce trĂšs bon article sur le supportforums cisco, qui m’a permis de dĂ©marrer et automatiser la conversion des routes-maps : ASR9000/XR: Understanding and using RPL (Route Policy Language)
De nombreux articles sont disponibles sur le net, et la pratique vaut forcĂ©ment mieux que l’exemple.
Bon courage Ă ceux qui doivent migrer des milliers de lignes Ă la main đ