Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques
Je n'ai pas suivi tout le thread donc peut être que la finalité m'échappe, mais pourquoi faire compliqué lorsqu'on peut faire simple avec du prepend ? rouer bgp monas network x.x.x.x ip prefix-list penalise seq 10 permit x.x.x.x/n route-map PROVIDER-OUT permit 10 match ip address prefix-list penalise set as-path prepend monas monas route-map PROVIDER-OUT deny 100 Naturellement le trafic viendra par l'as-path le plus court, si le fai1 disparait, l'as-path existe déjà sur le fai2 donc ça converge plus vite qu'une annonce conditionnelle. Sinon ton approche est intéressante techniquement, même si cela me parait loin des best practice. Cédric Le 29 mars 2013 14:29, jehan PRocaccia jehan.procac...@int-evry.fr a écrit : Bonjour, 3 semaines plus tard ... j'en enfin eu l'occasion de tester cette configuration, qui permet d'annoncer en mode nominal quelques prefixes à l'ISP secondaire et de manière conditionnelles tous mes prefixes au secondaire quand l'ISP primaire est tombé, le tout sans oublier de conserver l'annonce des qq prefixes annoncés au secondaire (en mode nominal) dans ce mode dégradé (ISP primaire down) en terme IOS cela donne: router bgp ASNUM neighbor x.x.x.x advertise-map QQ-PREFIX exist-map LOOPBACK-ALLWAYS-TRUE 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 et cela marche :-) quelques remarques cependant, car cela n'a pas marché du premier coup La formulation Router(config)# route-map 1ST-ISP-UP-OR-2ND-ISP-UP permit 10 Router(config-route-map)# match ip address 1 2 ! là on a un OR entre ACL 1 et ACL 2. a échouée, ACL 1 vérifié la présence d'une route ISP 1 et ACL 2 ISP2, quand ISP1 etait Down, je n'ai plus annoncé a ISP2 QQ-PREFIX :-( j'ai donc adopté la solution avec une route-map toujours vraie: show route-map LOOPBACK-ALLWAYS-TRUE Match clauses: ip address (access-lists): 7 #show access-lists 7 Standard IP access list 7 10 permit x.x.x.x (93 matches) qui match l'adresse IP de mon interface loopback autre remarque, l'odre d'annonce des directives dans la config est importante ! 1. neighbor x.x.x.x advertise-map QQ-PREFIX exist-map LOOPBACK-ALLWAYS-TRUE 2. neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP 3. neighbor x.x.x.x route-map MY-PREFIXES out l'inversion 2 et 1 a un autre comportement . Merci pour vos conseils. PS: je n'ai pas testé l'alternative suggérée sur la liste avec les prefix-list via cisco EEM , mais je garde ça sous le coude au cas ou ... Le 05/03/2013 10:02, orf fethi a écrit : Bonjour, Je vous propose aussi de changer dans neighbor x.x.x.x advertise-map QQ-PREFIX exist-map 1ST-ISP-UP le map 1ST-ISP-UP par un nouveau map 1ST-ISP-UP-OR-2ND-ISP-UP qui sera toujours VRAI. neighbor x.x.x.x advertise-map QQ-PREFIX exist-map 1ST-ISP-UP-OR-2ND-ISP-UP 2 Solutions: 1. Router(config)# route-map 1ST-ISP-UP-OR-2ND-ISP-UP permit 10 Router(config-route-map)# match ip address 1 2 ! là on a un OR entre ACL 1 et ACL 2. Par exemple ACL1 pointe vers une annonce de ISP1 et ACL2 vers une annonce d'ISP2. 2. Définir une condition toujours vrai qui sera toujours matchée pour pouvoir toujours annoncerQQ-PREFIX Cdt, Fethi *De :* jehan procaccia INT jehan.procac...@int-evry.fr *À :* Ccde Cissp ccdeci...@yahoo.fr; frnog-t...@frnog.org frnog-t...@frnog.org *Cc :* touremoha...@gmail.com touremoha...@gmail.com *Envoyé le :* Lundi 4 mars 2013 13h46 *Objet :* Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques 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
Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques
Naturellement le trafic viendra par l'as-path le plus court, si le fai1 disparait, l'as-path existe déjà sur le fai2 donc ça converge plus vite qu'une annonce conditionnelle. ... sur le chemin le plus court a toute autre condition identique. Ce qui n'est pas forcement le cas dans tous les situations. N'oublions pas qu'en general un AS prefere en ordre (avec modification de weight ou localpref a la carte) : clients, peers, upstreams Pour des raisons specifiques, les tres grands preferent certaines peers aux autres (pareil, avec localpref en consequence). Dans des telles conditions tu peux faire prepend autant de fois que tu veux, ca n'aide pas. Tout à fait, je parlais du cas général. D'ailleurs même avec du prepend massif j'ai toujours vu un peu de trafic résiduel sur le transit de backup. Sinon ton approche est intéressante techniquement, même si cela me parait loin des best practice. Presente comme ca, c'est effectivement contre-nature, mais il peut y avoir d'autres applications: par exemple essayer de cacher a un certain peer potentiel la presence d'un de tes upstreams, tout en se gardant la possibilite d'utiliser l'upstream en question si les choses tournent vraiment mal (et meme dans ce cas-la, on est un peu contre-nature). Après réflexion, il y a peut être aussi un intérêt aux annonces conditionnelles sur du peering, la où pour sûr il y a un localpref en face, pour forcer tel peer à envoyer le trafic par tel point d'échange en gardant l'autre en backup. Cédric --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques
Bonjour, 3 semaines plus tard ... j'en enfin eu l'occasion de tester cette configuration, qui permet d'annoncer en mode nominal quelques prefixes à l'ISP secondaire et de manière conditionnelles tous mes prefixes au secondaire quand l'ISP primaire est tombé, le tout sans oublier de conserver l'annonce des qq prefixes annoncés au secondaire (en mode nominal) dans ce mode dégradé (ISP primaire down) en terme IOS cela donne: router bgp ASNUM neighbor x.x.x.x advertise-map QQ-PREFIX exist-map LOOPBACK-ALLWAYS-TRUE 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 et cela marche :-) quelques remarques cependant, car cela n'a pas marché du premier coup La formulation Router(config)# route-map 1ST-ISP-UP-OR-2ND-ISP-UP permit 10 Router(config-route-map)# match ip address 1 2 ! là on a un OR entre ACL 1 et ACL 2. a échouée, ACL 1 vérifié la présence d'une route ISP 1 et ACL 2 ISP2, quand ISP1 etait Down, je n'ai plus annoncé a ISP2 QQ-PREFIX :-( j'ai donc adopté la solution avec une route-map toujours vraie: show route-map LOOPBACK-ALLWAYS-TRUE Match clauses: ip address (access-lists): 7 #show access-lists 7 Standard IP access list 7 10 permit x.x.x.x (93 matches) qui match l'adresse IP de mon interface loopback autre remarque, l'odre d'annonce des directives dans la config est importante ! 1. neighbor x.x.x.x advertise-map QQ-PREFIX exist-map LOOPBACK-ALLWAYS-TRUE 2. neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP 3. neighbor x.x.x.x route-map MY-PREFIXES out l'inversion 2 et 1 a un autre comportement . Merci pour vos conseils. PS: je n'ai pas testé l'alternative suggérée sur la liste avec les prefix-list via cisco EEM , mais je garde ça sous le coude au cas ou ... Le 05/03/2013 10:02, orf fethi a écrit : Bonjour, Je vous propose aussi de changer dans neighbor x.x.x.x advertise-map QQ-PREFIX exist-map 1ST-ISP-UP le map 1ST-ISP-UP par un nouveau map 1ST-ISP-UP-OR-2ND-ISP-UP qui sera toujours VRAI. neighbor x.x.x.x advertise-map QQ-PREFIX exist-map 1ST-ISP-UP-OR-2ND-ISP-UP 2 Solutions: 1. Router(config)# route-map 1ST-ISP-UP-OR-2ND-ISP-UP permit 10 Router(config-route-map)# match ip address 1 2 ! là on a un OR entre ACL 1 et ACL 2. Par exemple ACL1 pointe vers une annonce de ISP1 et ACL2 vers une annonce d'ISP2. 2. Définir une condition toujours vrai qui sera toujours matchée pour pouvoir toujours annoncerQQ-PREFIX Cdt, Fethi *De :* jehan procaccia INT jehan.procac...@int-evry.fr *À :* Ccde Cissp ccdeci...@yahoo.fr; frnog-t...@frnog.org frnog-t...@frnog.org *Cc :* touremoha...@gmail.com touremoha...@gmail.com *Envoyé le :* Lundi 4 mars 2013 13h46 *Objet :* Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques 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
Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques
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 HopMetric LocPrf Weight Path * X.X.21.0/24 p.p.p.p232768 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 Advertised by bgp 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
Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques
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é mohamed.to...@secresys.com À : jehan procaccia INT jehan.procac...@int-evry.fr Cc : Ccde Cissp ccdeci...@yahoo.fr; frnog-t...@frnog.org frnog-t...@frnog.org 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 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
Tr : [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques
Hello, Apparemment, cette solution est satisfaisante. Cdt, Fethi ORF - Mail transféré - De : orf fethi orffe...@yahoo.fr À : jehan procaccia INT jehan.procac...@int-evry.fr Envoyé le : Mardi 5 mars 2013 10h02 Objet : Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques Bonjour, Je vous propose aussi de changer dans neighbor x.x.x.x advertise-map QQ-PREFIX exist-map 1ST-ISP-UP le map 1ST-ISP-UP par un nouveau map 1ST-ISP-UP-OR-2ND-ISP-UP qui sera toujours VRAI. neighbor x.x.x.x advertise-map QQ-PREFIX exist-map 1ST-ISP-UP-OR-2ND-ISP-UP 2 Solutions: 1. Router(config)# route-map 1ST-ISP-UP-OR-2ND-ISP-UP permit 10 Router(config-route-map)# match ip address 1 2 ! là on a un OR entre ACL 1 et ACL 2. Par exemple ACL1 pointe vers une annonce de ISP1 et ACL2 vers une annonce d'ISP2. 2. Définir une condition toujours vrai qui sera toujours matchée pour pouvoir toujours annoncer QQ-PREFIX Cdt, Fethi De : jehan procaccia INT jehan.procac...@int-evry.fr À : Ccde Cissp ccdeci...@yahoo.fr; frnog-t...@frnog.org frnog-t...@frnog.org Cc : touremoha...@gmail.com touremoha...@gmail.com Envoyé le : Lundi 4 mars 2013 13h46 Objet : Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques 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 *À :* 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
Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques
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 *À :* 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 mailto:jehan.procac...@int-evry.fr To: frnog-t...@frnog.org mailto:frnog-t...@frnog.org frnog-t...@frnog.org mailto:frnog-t...@frnog.org Cc: Ccde Cissp ccdeci...@yahoo.fr mailto: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
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 HopMetric LocPrf Weight Path * X.X.21.0/24 p.p.p.p2 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 Advertised by bgp 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
Re: RE : Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques
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 À : 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 Advertised by bgp 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
[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/
Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques
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. 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. 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 outcette 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 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/
