Découverte
29 November 2006
Récemment, j’ai découvert un daemon de routage nommé OpenBGPD, je connaissais de nom, de reputation, mais je n’avais franchement pas mis les mains dans le camboui.
J’ai donc decidé de me coller à ca, et mes premieres impressions sont bonnes. L’outil est bien pratique quand on est un petit reseau et qu’on a pas toujours la possibilitée de deployer des Cisco ou des Junipers.
Le but du projet est :
Securité optimum ( sa conception est faite pour)
Faible emprunte memoire ( contrairement à Quagga)
Rapidité.
Configuration très souple et claire.
Supporté la majorité des fonctionnalités.
Ce que j’aime surtout particulièrement dans cet outil c’est son système de filtre. Simple et puissant, avec la possibilitée de définir des groupes et donc de definir une hierarchie et appliquer ces filtres sur ces groupes.
J’ai eu un peu de mal au début, car il existe un systeme de filtre très simple qui consiste a annoncer a son voisin
announce (all|none|self|default-route)
Dans le cas ou l’on fournit pas du tout de transit, on peut simplement utilisé self. Mais dans le cas ou on fournit du transit à un autre AS, on ne peut pas. En lisant les posts sur openbgpd j’ai pu trouver ma solution simplement et rapidement.
On annonce tout et on filtre
Exemple rapide.
Notre client s’appelle “lambda” et possède 2 blocs d’ips a lui qui sont 192.168.1.0/24 et 172.22.1.0/24, OpenBGPD nous permet par exemple d’ecrire ca rapidement
lambda_prefix =” { 192.168.1.0/24, 172.22.1.0/24 } “
ensuite on peut ecrire une acl très rapidement pour ce client, la règle en général c’est :
On envoit toute notre table de routage
On Interdit qu’il nous envoit sa table de routage complete
et on debloque ses prefixes.
En language de filtres OpenBGPd cela donne ca
allow to group lambda
deny from group lambda
allow from group lambda prefix $lambda_prefix
(Simple non )
Puis on debloque notre acl transit/peering, ici la règle c’est :
deny to { group transit, group peering}
allow to { group transit, group peering} prefix { $our_prefix $lambda}
