Bonsoir, Piste intéressante que je qualifie aussi "out of the box". En effet, j'avais pensé à ça aussi. Par contre, il faudrait s'assurer que l'EEM est supportée par la version d'IOS et que le script est bien customisé pour traduire l’ingénierie cible et se méfier de CPU surtout en cas de Flapping.
J'ai proposé aussi une solution qui semble, à priori, répondre au besoin indiqué. Je vais la transmettre. Bien cordialement, Fethi ________________________________ De : Mohamed Touré <[email protected]> À : jehan procaccia INT <[email protected]> Cc : Ccde Cissp <[email protected]>; "[email protected]" <[email protected]> Envoyé le : Mardi 5 mars 2013 14h49 Objet : Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques 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 <[email protected]> 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 : "[email protected]" <[email protected]> >>À : [email protected]; [email protected] >>Cc : [email protected] >>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 <[email protected]> >>To: "[email protected]" <[email protected]> >>Cc: "Ccde Cissp" <[email protected]> >>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 <[email protected]> >>> *À :* [email protected] >>> *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/
