{"id":2546,"date":"2015-04-28T23:18:40","date_gmt":"2015-04-28T22:18:40","guid":{"rendered":"https:\/\/beufa.net\/?p=2546"},"modified":"2015-04-28T23:18:40","modified_gmt":"2015-04-28T22:18:40","slug":"imbrication-route-policy-language-avec-apply-cisco-ios-xr","status":"publish","type":"post","link":"https:\/\/beufa.net\/fr\/blog\/imbrication-route-policy-language-avec-apply-cisco-ios-xr\/","title":{"rendered":"Imbrication des RPL avec apply sous Cisco IOS-XR"},"content":{"rendered":"

Suite \u00e0 mon article sur les RPL<\/a> , je suis tomb\u00e9 sur un comportement pas forc\u00e9ment clair au premier abord dans les documentations cit\u00e9es dans ce m\u00eame article.<\/p>\n

Lors de l’usage de ‘apply’ permettant d’imbriquer une route-policy dans une route-policy, nous avons rencontr\u00e9 un cas pas terrible<\/a> \ud83d\ude41<\/p>\n

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

Par exemple, une RPL permettant de filtrer un as-path<\/em> vide et un prefix-set<\/em> des r\u00e9seaux IP de son AS (\u00e9quivalent \u00e0 filter-list et prefix-list sous IOS) :<\/p>\n

route-policy announce_asXXXXX\r\n   if ((as-path in (ios-regex '^$')) and (destination in PREFIX_IPV4_ASXXXXX)) then\r\n      pass\r\n   endif\r\nend-policy<\/pre>\n
Cette RPL n’autorisera que les as-path<\/em> vides et les pr\u00e9fixes qui matchent la prefix-set<\/em> si elle est appliqu\u00e9e telle quelle (deny implicite) sur un neighbor BGP.<\/p>\n
Mais, si on l’utilise pour forcer des communities<\/em> BGP ou des med<\/em> (metric<\/em> sous IOS) comme ceci :<\/p>\n
route-policy announce_tier123\r\n   apply announce_asXXXXX\r\n   set med 0\r\n   set community 666:666\r\nend-policy<\/pre>\n
Le r\u00e9sultat est assez violent, puisque on va appliquer la route-policy announce_asXXXXX<\/em> et ensuite, pour tout ce qui ne passe dans cette route-policy imbriqu\u00e9e, on va appliquer un pass<\/em> avec les set med<\/em> \/ set community<\/em>. Dans le cas de cette route-policy announce_tier1<\/em>, on va donc leaker et faire le set med<\/em> et set community<\/em> sur tous les pr\u00e9fixes autres que PREFIX_IPV4_ASXXXXX<\/em> et les as-path<\/em> non-vides :-[ Tout l’inverse de ce qu’on souhaitait faire !<\/p>\n
Pour \u00e9viter ce comportement (bien document\u00e9 chez Cisco pourtant – RTFM<\/em>), il faut donc mieux utiliser les imbrications de RPL avec un if (apply RPL)<\/em> . Dans notre cas, cela donne :<\/p>\n
route-policy announce_tier1\r\n   if (apply announce_asXXXXX) then\r\n      set med 0\r\n      set community 666:666\r\n    end-if\r\nend-policy<\/pre>\n
Dans cette derni\u00e8re RPL, on va donc appliquer le med<\/em> et le community<\/em> uniquement \u00e0 ce qui est retourn\u00e9 comme vrai par la route-policy imbriqu\u00e9e announce_asXXXXX<\/em>, c’est \u00e0 dire si l’as-path est vide et les pr\u00e9fixes dans le prefix-set PREFIX_IPV4_ASXXXXX.<\/p>\n
Un comportement qui en perturbera s\u00fbrement bien d’autres que moi et qu’il est n\u00e9cessaire d\u2019assimiler pour \u00e9viter les comportements li\u00e9s aux rayons cosmiques et autres trous noirs !<\/p>","protected":false},"excerpt":{"rendered":"
Suite \u00e0 mon article sur les RPL , je suis tomb\u00e9 sur un comportement pas forc\u00e9ment clair au premier abord dans les documentations cit\u00e9es dans…<\/p>\n
Continue readingImbrication des RPL avec apply sous Cisco IOS-XR<\/span><\/a><\/div>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16,29,24],"tags":[93,42,102,103,73,108,107],"class_list":["post-2546","post","type-post","status-publish","format-standard","hentry","category-cisco","category-internet","category-reseau","tag-bgp","tag-cisco-2","tag-ios","tag-ios-xr","tag-network","tag-route-map","tag-route-policy","entry"],"_links":{"self":[{"href":"https:\/\/beufa.net\/fr\/wp-json\/wp\/v2\/posts\/2546","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/beufa.net\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/beufa.net\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/beufa.net\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/beufa.net\/fr\/wp-json\/wp\/v2\/comments?post=2546"}],"version-history":[{"count":1,"href":"https:\/\/beufa.net\/fr\/wp-json\/wp\/v2\/posts\/2546\/revisions"}],"predecessor-version":[{"id":2547,"href":"https:\/\/beufa.net\/fr\/wp-json\/wp\/v2\/posts\/2546\/revisions\/2547"}],"wp:attachment":[{"href":"https:\/\/beufa.net\/fr\/wp-json\/wp\/v2\/media?parent=2546"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/beufa.net\/fr\/wp-json\/wp\/v2\/categories?post=2546"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/beufa.net\/fr\/wp-json\/wp\/v2\/tags?post=2546"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}