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