Bonjour,
Je peux vous proposer une solution qui consiste à mettre à jour les
prefix-list via cisco EEM. (je suppose que vous utilisez du cisco)
La solution est spécifique certes, mais c'est pour répondre à un besoin non
standard.
Topogie :
CPE : R1
f0/0 : *192.168.12.1* -> To ISP1
f0/1 : *192.168.13.1* -> To ISP2
PE1: R2
f0/0 : 192.168.12.2 -> To R1
PE2: R3
f0/0 : *192.168.13.3 *-> To R1
*Config BGP* :
!
* router bgp 1
neighbor 192.168.12.2 remote-as 2*
* neighbor 192.168.12.2 route-map TO-ISP1 out
neighbor 192.168.12.2 soft-reconfiguration inbound
neighbor 192.168.13.3 remote-as 3*
* neighbor 192.168.13.3 route-map TO-ISP2 out
neighbor 192.168.13.3 soft-reconfiguration inbound*
*exit*
!
*ip prefix-list ISP1 permit 10.10.10.0/24*
*ip prefix-list ISP2 permit 11.11.11.0/24
*!*
*!*
route-map TO-ISP1 permit 10
match ip address prefix-list ISP1
*!*
**route-map TO-ISP2 permit 10
match ip address prefix-list ISP2
*!
*Mise en situation *:
A ce stade, supposons que CPE1 ait dans sa table BGP les prefix :
10.10.10.0/24 et 11.11.11.0/24. Avec la config ci-dessus, ISP1 recevra le
prefix *10* et ISP2 le prefix *11* : on est en situation nominale.
Maintenant supposons qu'on perde le lien vers ISP1. Ce que vous souhaitez
c'est d'annoncer 10 et 11 à l'ISP2.
*Code EEM* :
*event manager applet DOWN
event syslog pattern "%BGP-5-ADJCHANGE: neighbor 192.168.12.2 Down
Interface flap"
action 1.0 syslog msg "Interface Down : Modifying Prefix-list" **=>
message qui va apparaitre dans les logs
action 1.1 cli command "enable"
action 1.2 cli command "configure terminal"
action 2.0 cli command "ip prefix-list ISP2 permit 10.10.10.0/24"
action 3.0 cli command "end"
action 4.0 cli command "write"
action 5.0 "clear ip bgp 192.168.13.3 soft"*
!
*event manager applet UP
event syslog pattern "%BGP-5-ADJCHANGE: neighbor 192.168.12.2 Up"
action 1.0 syslog msg "BGP Session UP : Modifying
Prefix-list" => message qui va apparaitre dans les logs
action 1.1 cli command "enable"
action 1.2 cli command "configure terminal"
action 2.0 cli command "no ip prefix-list ISP2 permit 10.10.10.0/24"
action 3.0 cli command "end"
action 4.0 cli command "write"
action 5.0 "clear ip bgp 192.168.13.3 soft"*
!
*Explications* :
Principe : Si* évenement* alors *action*.
L'événement peut-être choisi parmi une liste définie par le constructeur
(présence d'un préfixe dans la table de routage, interface down, ipsla
...). Ici je traque le message *%BGP-5-ADJCHANGE: neighbor 192.168.12.2
Down Interface flap *dans syslog. Un autre peut-être choisi bien entendu.
Lorsque cette condition est satisfaite, je modifie à la volée ma
prefix-list vers ISP2.
*!
enable
configure terminal
ip prefix-list ISP2 permit 10.10.10.0/24
end
*!
Dans le meme principe, si la session devient UP à nouveau, je retire le
prefix. A chaque fois un clear soft sera necessaire pour prendre en compte
la route-map au niveau du process BGP.
NB : A toute fin utile, il faudrait surveiller la charge CPU avant de
mettre en production.
Cordialement
Mohamed Touré
2013/3/4 jehan procaccia INT <jehan.procac...@int-evry.fr>
> bonjour,
>
> la methode suivante fonctionne partiellement mieux:
>
>
> router bgp ASNUM
> neighbor x.x.x.x advertise-map QQ-PREFIX exist-map 1ST-ISP-UP
> neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP
> neighbor x.x.x.x route-map MY-PREFIXES out
>
> en mode nominal (ISP primaire UP) j'annonce bien mes QQ-PREFIX à l'ISP
> secondaire
> en cas de perte de l'ISP primaire j'annonce bien dynamiquement tous mes
> prefixes MY-PREFIXES à l'ISP secondaire
> mais malheureusement je n'annonce plus les prefix QQ-PREFIX dans cette
> situation, en effet "exist-map 1ST-ISP-UP" n'est plus vrai, donc je
> suppose qu'il élimine les prefix QQ-PREFIX qui sont inclus dans MY-PREFIXES
> et n’annonce que le reste des MY-PREFIXES .
>
> Bref c'est mieux, mais ce n'est pas encore satisfaisant pour assurer le
> trafic engineering attendu , en effet quand l'ISP primaire est tombé, les
> QQ-PREFIX qui profitaient d'un trafic engineering via les 2eme ISP se
> retrouvent coupé du monde car ils ne sont plus annoncés au secondaire,
> alors même que ce dernier (ISP 2) n'a subit aucune perte !
>
> J'ai bien entendu les differentes suggestions concernant l'AS-Prepend,
> j'avais commencé par ça, mais malheureusement ce n'est pas déterministe, il
> y aura toujours qq-part sur le chemin un ISP qui se foutra de la longueur
> de l'AS-PATH et favorisera son peering gratuit plutôt qu'un transit $$$
> c'est du vecu, j'avais au moins 30% du trafic qui ne prenait pas le chemin
> retour attendu pas l'as-prepend :-( .
>
> Si qq'un a encore une meilleur idée, je reste a l’écoute, je suis surpris
> que BGP ne sache pas gérer ça !?
>
>
> Le 01/03/2013 20:05, Ccde Cissp a écrit :
>
> Bonjour,
>
> Effectivement, vue cette "histoire" de AND Logique entre les différentes
> maps définies. Vous pouvez par exemple tester:
>
> 1. Et là (je pense que) ce notre dernier espoir avec les annonces
> conditionnelles :-)
>
> router bgp ASNUM
> neighbor x.x.x.x advertise-map QQ-PREFIX exist-map 1ST-ISP-UP
> neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP
> neighbor x.x.x.x route-map MY-PREFIXES out
>
> 2. Sinon, il faut jouer avec l'AS PATH PREPENDING ou toute autre
> chose influençant le trafic INBOUND autre que les annonces conditionnelles
> via des "advertise map"...
>
>
> Bien cordialement,
> Fethi
>
> ------------------------------
> *De :* "touremoha...@gmail.com" <touremoha...@gmail.com>
> <touremoha...@gmail.com> <touremoha...@gmail.com>
> *À :* jehan.procac...@int-evry.fr; frnog-t...@frnog.org
> *Cc :* ccdeci...@yahoo.fr
> *Envoyé le :* Vendredi 1 mars 2013 15h38
> *Objet :* RE : Re: [FRnOG] [TECH] multihome BGP avec annonces
> conditionnelles et statiques
>
> Bonjour,
>
> Une piste peut eventuellement etre testee. Il s'agit de voir si on peut
> cumuler une exist-map et une non-exist-map pour le meme peer bgp.
>
> Si on note A la liste des 55 prefixes annonces a l'ISP1 et B la liste des
> 5 prefixes annonces a l'ISP2.
>
> On annonce inconditionnellement A a l'ISP1. On annonce B a l'ISP2 si
> exist-map XXX (a definir).
> On annonce A et B si non-exist-map YYY (a definir). De sorte que si ISP1
> down les 60 prefixes sont annonces a l'ISP2.
>
> Une autre piste : utiliser as-path prepend.
> On annonce A vers ISP1 sans modification.
> On annonce B vers ISP2 sans modification.
> On annonce A vers ISP2 avec un as-path prepend.
> Internet recevra les prefixes (s'il nya pas d'alteration des ISP :
> summarization, modif ...) et l'ISP1 sera prefere pour la liste A et ISP2
> pour la liste B. Si la session vers ISP1 est down alors l'ISP2 sera
> prefere.
>
> Bien sur, il ya d'autres pistes :).
>
> Cordialement
> Mohamed Toure
>
>
>
> ----------
> Envoyé de mon téléphone Nokia
>
> ------Message original------
> De : jehan procaccia INT <jehan.procac...@int-evry.fr>
> To: "frnog-t...@frnog.org" <frnog-t...@frnog.org>
> Cc: "Ccde Cissp" <ccdeci...@yahoo.fr>
> Date: vendredi 1 mars 2013 12:25:54 GMT+0100
> Subject: Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et
> statiques
>
> Le 28/02/2013 22:45, Ccde Cissp a écrit :
> > Hello,
> >
> > Je n'ai pas très bien compris votre question et je souhaite vous
> > demander quelques informations:
> >
> >
> > 1. Concernant votre conf: Pourquoi vous annoncer la même chose
> > (MY-PREFIXES) au même neighbor (x.x.x.x) avec deux façon différentes
> > alors que votre but ultime c'est d'annoncer " MY-PREFIXES" si et
> > seulement si la condition "non-exist-map est vérifiée et donc la ligne :
> > "neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP"
> > suffira pour satisfaire votre 1ère condition.
> > ! La ligne de conf: "neighbor x.x.x.x route-map MY-PREFIXES out": je
> > ne vois pas son intérêt ici elle n'apporte rien vis à vis de vos 2
> > conditions que vous souhaitez mettre en oeuvre.
> cette deuxième ligne est nécessaire, car sans elle je n'annonce pas
> MY-PREFIXES quand la condition est vraie (1st ISP is down)
> c'est du vecu , certes empirique car je trouve ça aussi apparemment
> redondant, mais je constate que je n'annonce tj rien sans cette ligne
> meme si l'ISP primaire est down :-( .
> >
> > 2. Je vous conseille de faire un test/LAB avec seulement: "neighbor
> > x.x.x.x route-map QQ-PREFIX out" et voir si l'interaction avec
> > " neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map
> > 1ST-ISP-UP" est un AND LOGIC ou pas càd si le résultat de deux types
> > d'annonce utilisés simultanément est l'annonce de l'intersection entre
> > les deux ensemble "QQ-PREFIX" et "MY-PREFIXES" qui sera dans ce cas
> > l'ensemble "QQ-PREFIX".
> apparement c'est plutot un AND
> j'ai mis en 2eme ligne "neighbor x.x.x.x route-map QQ-PREFIX out", tout
> en gardant en 1er ligne
> "neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP"
> quand l'ISP primaire est UP, rien n'est annoncée (j'aurai esperé voir
> QQ-PREFIX)
> et quand l'ISP primaire est Down alors seulement QQ-PREFIX est annoncé:
>
> Edge2#show ip bgp neighbors x.x.x.x advertised-routes
> Network Next Hop Metric LocPrf Weight Path
> *> X.X.21.0/24 p.p.p.p 2 32768 i
>
> Edge2#show ip route X.X.21.0
> Routing entry for X.X.21.0/24
> Known via "ospf 1", distance 110, metric 2, type extern 1
> Redistributing via bgp BBBB
> Advertised by bgp BBBB match internal external 1 & 2
>
> ce n'est pas le resultat attendu, je voulais voir MY-PREFIXES annoncés
> au minimum et au mieux MY-PREFIXES + QQ-PREFIX (ps: l'unique /24
> QQ-PREFIX actuellement dans mon test/lab est contenu dans MY-PREFIXES,
> cela a peut-etre une incidence ?).
> >
> > 3. Remarque: Le résultat que vous avez pu voir et que vous avez décrit
> > dans:
> > "neighbor x.x.x.x route-map QQ-PREFIX out
> > cette ligne écrase alors "neighbor x.x.x.x route-map MY-PREFIXES out"
> >
> > serait du à un AND LOGIC entre les deux lignes de conf qui sont ici
> > équivalentes de point de vue syntaxe. A vérifier, donc, que cet AND
> > LOGIC n'existe pas entre deux syntaxes d'annonces différentes:
> >
> > "neighbor x.x.x.x route-map QQ-PREFIX out"
> > et
> > " neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP"
> malheureusement cet apparent "AND logic" semble exister dans ce cas
> d'apres l'experience ci-dessus
>
> comment cumuler ces 2 lignes !?
>
> Merci .
> >
> > a mon avis le AND logic persistera, à confirmer car cela dépend du
> > code constructeur.
> > Please ;) dites nous les résultats de vos tests. Si vos deux
> > conditions ne seront pas vérifiées (fort probable), il faut intervenir
> > des nouveaux ingrédients :)
> >
> > Cordialement,
> > Fethi
> >
> > ------------------------------------------------------------------------
> > *De :* jehan PRocaccia <jehan.procac...@int-evry.fr>
> > *À :* frnog-t...@frnog.org
> > *Envoyé le :* Jeudi 28 février 2013 13h09
> > *Objet :* [FRnOG] [TECH] multihome BGP avec annonces conditionnelles
> > et statiques
> >
> > Bonjour,
> >
> > je suis "end user" avec 2 FAI, je souhaite annoncer quelques prefixes
> > (5) au second FAI afin de favoriser le trafic entrant pour ces qq
> > prefixes via le 2nd FAI (plutot que le FAI primaire) , tout en
> > bénéficiant d'un mécanisme automatique d'annonce de tous mes prefixes
> > (60) au secondaire en cas de défaillance totale du FAI primaire .
> > Je n'annonce pas tous mes préfixes aux 2 FAI en parallèle car je ne me
> > sert du 2em FAI qu'en cas de backup et/ou de trafic engineering sur
> > certains prefixes sélectionnés suivant les besoins du moment.
> > j'ai bien réussi dans le cadre de ce dual homing BGP a annoncer de
> > manière conditionnelle tous mes prefixes au second FAI seulement quand
> > le primaire est défaillant => annonce bgp au 2eme FAI conditionnée
> > sur la présence ou non d'une route venant du FAI primaire.
> > En termes technique:
> >
> > router bgp ASNUM
> > neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP
> > neighbor x.x.x.x route-map MY-PREFIXES out
> > show route-map 1ST-ISP-UP
> > Match clauses:
> > ip address (access-lists): 3
> > Standard IP access list 3
> > 10 permit Y.Y.Y.Y, wildcard bits 0.0.0.7 log (4604 matches)
> >
> > Y.Y.Y.Y = reseau interco avec FAI primaire et route-map MY-PREFIXES
> > contiens tous mes prefix
> >
> > Cette solution est satisfaisante, sauf que dans cette configuration,
> > je n'arrive pas a annoncer au 2em FAI en complément mes qq prefixes
> > que je juge non conditionnés par la présence du FAI primaire, bref que
> > je souhaite annoncer à ma convenance, sans attendre que le primaire tombe
> > j'ai bien peur de rentrer à tous les coups dans la condition
> > "advertise-map if non-exist-map", et comme la route du FAI primaire
> > est présente la condition est fausse et ainsi je n'annonce rien au 2em
> > FAI .
> >
> > En résumer, comment cumuler les 2 ? =>
> > 1) annoncer automatiquement et de manière conditionnelle (perte du 1er
> > FAI) tous mes prefix,
> > 2) tout en annonçant à ma convenance (non dependante de l'etat du 1er
> > FAI) qq prefixes que j'aurai selectionné "manuellement" .
> >
> > j'ai beau ajouter aux lignes "router BGP ASNUM" ci-dessus pour ce peer
> > neighbor x.x.x.x route-map QQ-PREFIX out
> > cette ligne écrase alors "neighbor x.x.x.x route-map MY-PREFIXES out",
> > comment les cumuler ?
> >
> > Merci pour vos conseils .
> >
> >
> > ---------------------------
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
> >
>
>
>
> ---------------------------
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>
>
>
>
--
Mohamed Touré
06 38 62 99 07
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
