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 thoughts on “Imbrication des RPL avec apply sous Cisco IOS-XR”

    1. 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

    2. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.