Blog

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 !

Rsyslog : Dériver les messages syslog dans un fichier particulier

Depuis pas mal de temps, je me casse les dents sur la dérivation des logs envoyés au démon rsyslog, utilisés pas défaut dans Ubuntu. En effet, j’ai installé un tvheadend sur mon serveur / media center pour avoir à la TV dans tous mes XBMC/Kodi, et le mode debug est un peu trop verbeux à mon goût.

La configuration de base de rsyslog est fait par défaut dans “/etc/rsyslog.d/50-default.conf”. Pour qu’un fichier particulier soit traité en premier, comme dans Apache, il faut en créer un nouveau.

Par exemple, j’ai créer les fichiers suivants :

[19:54 user@home ~] > ll /etc/rsyslog.d/*
-rw-r--r-- 1 root root  483 Apr  9 21:40 /etc/rsyslog.d/10-tvheadend.conf
-rw-r--r-- 1 root root  465 Apr  9 21:40 /etc/rsyslog.d/11-dhcpd.conf
-rw-r--r-- 1 root root  469 Apr  9 21:50 /etc/rsyslog.d/12-postfix.conf
-rw-r--r-- 1 root root  311 Mar 17  2012 /etc/rsyslog.d/20-ufw.conf
-rw-r--r-- 1 root root 1.7K Apr  9 21:52 /etc/rsyslog.d/50-default.conf

Ces fichiers contiennent les dérivations suivantes :

[19:54 user@home ~] > cat /etc/rsyslog.d/10-tvheadend.conf
# Put tvheadend log in a specific log file
if $programname == 'tvheadend' then /var/log/tvheadend/tvheadend.log
& stop

[19:54 user@home ~] > cat /etc/rsyslog.d/11-dhcpd.conf
# Put isc-dhcpd-server log in a specific log file
if $programname == 'tvheadend' then /var/log/dhpcd.log
& stop

[19:54 user@home ~] > cat /etc/rsyslog.d/12-postfix.conf
# Put postfix log in a specific log file
if $programname == 'tvheadend' then /var/log/postfix.log
& stop

Il faut ensuite simplement reloader/restarter le service rsyslog pour prendre en compte ces changements, et vérifiez que vos fichiers sont bien crées (il peut subsister des problèmes de droits, surtout lorsque vous avez créer un dossier spécifique comme dans le cas de tvheadend).

A noter qu’il existe beaucoup d’options pour filtrer par programname, severity, ou de manière plus puissante par regex. Dans le cas ou vous souhaiteriez faire ceci, RFTM !

Ensuite, il ne faut oublier de configurer la rotation des logs (dans mon cas, j’ajoute un restart du process, car je n’ai pas de ‘status‘ pour le démon tvheadend dans mon init.d) :

[20:05 user@home ~] > cat /etc/logrotate.d/tvheadend
/var/log/tvheadend/*.log {
        daily
        missingok
        rotate 7
        compress
        delaycompress
        notifempty
        create 640 syslog adm
        sharedscripts
        postrotate
                /etc/init.d/tvheadend restart
        endscript
}

Puis forcer la rotation (-f) ou débuguer (-d)

[20:09 user@home ~] > sudo logrotate -d /etc/logrotate.conf
reading config file /etc/logrotate.conf
[...]
reading config file tvheadend
[...]

rotating pattern: /var/log/tvheadend/*.log  after 1 days (7 rotations)
empty log files are not rotated, old logs are removed
switching euid to 0 and egid to 104
considering log /var/log/tvheadend/tvheadend.log
  log does not need rotating
not running postrotate script, since no logs were rotated
switching euid to 0 and egid to 0

Vous trouvez alors la rotation des logs :

[20:11 user@home ~] > ll /var/log/tvheadend/
 
-rw-r----- 1 syslog adm  12K Apr 11 20:11 tvheadend.log
-rw-r----- 1 syslog adm  48K Apr 11 09:50 tvheadend.log.1

Bon amusement !

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 😉

Laverna, une application web de Notes

En cherchant une application pour auto-héberger mes notes et remplacer EverNote, j’ai été séduit par l’application Laverna.

Les fonctionnalités qui m’ont attirées sont les suivantes :

  • Gérer vos notes, même lorsque vous êtes déconnecté
  • Cryptage sécurisé côté client (AES)
  • Possibilité de synchroniser avec DropBox – ce que je ne ferais pas bien entendu 🙂
  • Boutons de contrôle WYSIWYG
  • Coloration syntaxique 
  • Raccourcis clavier

Pour une démonstration : https://laverna.cc/

Pour l’installation, il suffit de faire un git clone du repository dans un Virtual Host sécurisé : https://github.com/Laverna/laverna

Bref, une application web de plus auto-hébergée !

Perfect Forward Secrecy pour Postfix/Dovecot

Après mon article sur PFS pour Apache, j’ai mis également en place PFS sur mon serveur de messagerie Postfix/Dovecot, le client K9-Mail pour Android supportant désormais des versions plus récentes de TLS, TLSv1.1 et v1.2.

Voici ici quelques éléments pour réaliser cette configuration et augmenter la sécurisation des flux chiffrés.

Continue reading Perfect Forward Secrecy pour Postfix/Dovecot