Skip to content →

Category: Cisco

Imbrication des RPL avec apply sous Cisco IOS-XR

Suite Ă  mon article sur les RPL , je suis tombĂ© sur un comportement pas forcĂ©ment clair au premier abord dans les documentations citĂ©es dans ce mĂȘme article.

Lors de l’usage de ‘apply’ permettant d’imbriquer une route-policy dans une route-policy, nous avons rencontrĂ© un cas pas terrible 🙁

Lorsque l’on appelle une autre route-policy dans une route-policy, le retour n’est pas vraiment un “pass ticket until drop” ou deny implicite. En fait, il faut plutĂŽt le voir comme un return (0|1) d’une fonction programmatique.

Par exemple, une RPL permettant de filtrer un as-path vide et un prefix-set des réseaux IP de son AS (équivalent à filter-list et prefix-list sous IOS) :

route-policy announce_asXXXXX
   if ((as-path in (ios-regex '^$')) and (destination in PREFIX_IPV4_ASXXXXX)) then
      pass
   endif
end-policy

Cette RPL n’autorisera que les as-path vides et les prĂ©fixes qui matchent la prefix-set si elle est appliquĂ©e telle quelle (deny implicite) sur un neighbor BGP.

Mais, si on l’utilise pour forcer des communities BGP ou des med (metric sous IOS) comme ceci :

route-policy announce_tier123
   apply announce_asXXXXX
   set med 0
   set community 666:666
end-policy

Le rĂ©sultat est assez violent, puisque on va appliquer la route-policy announce_asXXXXX et ensuite, pour tout ce qui ne passe dans cette route-policy imbriquĂ©e, on va appliquer un pass avec les set med / set community. Dans le cas de cette route-policy announce_tier1, on va donc leaker et faire le set med et set community sur tous les prĂ©fixes autres que PREFIX_IPV4_ASXXXXX et les as-path non-vides :-[ Tout l’inverse de ce qu’on souhaitait faire !

Pour Ă©viter ce comportement (bien documentĂ© chez Cisco pourtant – RTFM), il faut donc mieux utiliser les imbrications de RPL avec un if (apply RPL) . Dans notre cas, cela donne :

route-policy announce_tier1
   if (apply announce_asXXXXX) then
      set med 0
      set community 666:666
    end-if
end-policy

Dans cette derniĂšre RPL, on va donc appliquer le med et le community uniquement Ă  ce qui est retournĂ© comme vrai par la route-policy imbriquĂ©e announce_asXXXXX, c’est Ă  dire si l’as-path est vide et les prĂ©fixes dans le prefix-set PREFIX_IPV4_ASXXXXX.

Un comportement qui en perturbera sĂ»rement bien d’autres que moi et qu’il est nĂ©cessaire d’assimiler pour Ă©viter les comportements liĂ©s aux rayons cosmiques et autres trous noirs !

3 Comments

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