Skip to content →

Tag: RPL

Passer de Cisco IOS à IOS-XR, une nouvelle façon de penser !

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 ūüėČ

Comments closed
en_USEN