Skip to content →

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 !

Published in Cisco Internet Réseau

3 Comments

  1. Nicolas Nicolas

    Hello !

    Donc d’après toi, le ‘else pass’ dans les RPL imbriquées n’est pas nécessaire comme utilisé par certains (ex :http://comeroutewithme.com/2014/03/03/ios-xr-route-policy/) tant qu’il y a un pass ou un set dans la dernière règle si on veut un pass/set default à la fin ?

    • Nicolas Nicolas

      Je répond à ma propre question. En réalité, le defautl deny n’est fait qu’au niveau de la RPL parent. Donc pas besoin du else pass en théorie au niveau des RPL imbriquée
      Vu dans le guide suivant : IP Routing on Cisco IOS, IOS XE, and IOS XR: An Essential Guide to Understanding and Implementing IP Routing Protocols => partie 11-66

    • Fabien Vincent Fabien Vincent

      Hey ca va, tu t’amuses bien avec tes nouveaux joujous ?

      Le else pass, c’était plutôt pour l’exemple. En fait, on a leaké a cause d’un truc du genre le jour ou on a mis en place une RPL qu’on avait converti d’une route-map.

Comments are closed.

fr_FRFR