Skip to content →

Tag: IOS

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