Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Raphael Mazelier]

Le 03/11/15 09:58, Jérôme BERTHIER a écrit :


BFD ne serait pas plus adapté pour faire ça ?



BFD aide a une détection ultra rapide, mais en général ta session IBGP 
doit tomber car ta loopback a disparu de ton IGP. Donc un IGP bien tuné 
est le premier truc à faire.


--
Raphael Mazelier


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Jérôme BERTHIER]

Bonjour,

Le 02/11/2015 21:05, Fabien H a écrit :

la session iBGP tombe rapidement (j'ai mis un SLA icmp qui
ping le loopback d'en face),


BFD ne serait pas plus adapté pour faire ça ?

Cdt,

--
Jérôme BERTHIER


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

Bonjour,

merci, si j'ai bien compris, cette solution s'approche un peu du
redistribute en EIGRP mais en BGP. C'est effectivement à tester.

Mais je bloque toujours sur le besoin de failover Routeur BGP.

Si R1 tombe, ses routes disparaissent de la table de R2, et du coup R2 ne
pourra pas assurer le failover de R1 pour les routes en /32...

Le 3 novembre 2015 14:16, Montgomery SIMONPIETRI  a écrit :

> Bonjour,
>
> Est-ce que vous avez pensé à mettre une solution avec du "redistribute
> static route-map" pour éviter d'annoncer les /32 et du prepend sur les
> prefix a backuper ?
>
>
>
> Du style :
>
> ip route 1.2.3.4 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R1 tag 999
> ip route 5.6.7.8 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R2 tag 999
>
> access-list 70 permit 5.6.7.8 0.0.0.255 #SUR R1
>
> access-list 70 permit 1.2.3.4 0.0.0.255 #SUR R2
>
> route-map BACKUP-PREPEND permit 10
>  match ip address 70
>  set as-path prepend 1234
>
> route-map BACKUP-PREPEND permit 20
>
> route-map TAGGED-STATIC permit 10
>  match tag 999
>
> router bgp 1234
>  redistribute static route-map TAGGED-STATIC
>  neighbor PEER_ADDRESS route-map BACKUP-PREPEND out
>
>
>
>
>
> 2015-11-02 9:16 GMT+01:00 Fabien H :
>
>> Bonjour la liste,
>>
>> J'ai une question BGP à vous soumettre :
>>
>> En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
>> avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
>> Sur chaque routeur BGP, nous avons au moins un transitaire.
>>
>> Tout fonctionne parfaitement !
>>
>> Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
>> utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
>> route Null0).
>> Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
>> sur le routeur BGP concerné.
>>
>> - Ma question : Nous aimerions mettre en place un failover BGP automatique
>> en cas de défaillance matérielle totale d'un des routeurs BGP.
>>
>> La solution que j'imaginais est de mettre en place, pour un même prefixe,
>> une route Null0 sur les 2 routeurs en même temps.
>>
>> Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
>> les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
>> => Si un routeur BGP tombe, l'autre va normalement prendre le relais sans
>> problème.
>>
>> Le seul cas qui pose problème, c'est si les 2 routeurs BGP fonctionnement
>> mais que le L2L tombe.
>>
>> Dans ce cas, un paquet va continuer à arriver par le transit sur le
>> routeur
>> BGP concerné, puis la route statique correspondant à l'IP sera appliquée,
>> mais l'IP de GW étant normalement accessible via le L2L sur un VLAN donné,
>> le routage ne fonctionnera pas car le L2L est tombé.
>>
>> Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une solution
>> à
>> ce problème ?
>>
>> Merci,
>> Bonne journée,
>> Fabien
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Gestion boucle L2

[Pavel Lunin]

2015-11-02 18:15 GMT+01:00 Nicolas V :

> Bonjour,
>
> Je cherche à interconnecter plusieurs sites (3 au minima) via une boucle
> (de 1 à x*10G entre chaque site avec possibilité éventuelle d'ajout de
> liens 1G). Le but étant de pouvoir faire transiter du L2 de manière
> transparente.
>
> J'ai suivi le mail de Jérémy Martin "Design réseau L2", mais j'ai quelques
> contraintes / une architecture un peu différente :
> - Des routeurs ASR9k sur chaque POP => evpn / mpls possible
> - Des nexus sur chaque POP => fabricpath possible (mais licence nécessaire)
>
>
Ça dépend du type de service tu vas prêter.

- Si c'est bridged multipoint L2 VPN pour les clients B2B, un solution en
base de « vrai MPLS » est vraiment désirable. En ce cas tu as besoin d'un
vrai routeur MPLS comme Cisco ASR ou Juniper MX dans chaque PoP.
Normalement ayant un vrais réseau MPLS tu peux prêter différent types des
services pour différents types des clients : L2 p2p ou full-mesh des p2p
avec Martini/Kompella l2circuit/v2vpn aka pseudowire aka VPWS aka PWE3,
multipoint bridged ethernet avec VPLS ou EVPN, L3VPN, NG-MVPN, si t'en as
besoin, hub-and-spoke L3VPN etc etc, par-dessus la même infrastructure du
coeur.

Les vrais routeurs comme ASR/MX sont désirables ici parce que en dehors de
forwarding et protection ce type d’application aussi demande les choses
comme policers pour limiter le débit, filtres ACL, conteurs pour billing,
peut-être NetFlow pour la statistique etc etc. Le scaling (comment on dit
scaling en français ? graduation ?) est une grande considération aussi dans
ce cas : normalement tu veux être capable de servir des milliers des
clients, avoir les tableaux full BGP etc etc.

- Pour interconnexion des DCs (les vrai DCs avec des serveurs, à la
différence de SP POPs) je préférerais EVPN/VPLS et plus ou moins le même
type de design comme dans le cas précédent, mais les autres options comme
Cisco fabricpath sont possibles aussi. Moi personnellement je déteste
toutes les variations de MAC-in-MAC et toutes les technologies qui essayent
de cacher la complexité en façon « Ethernet over MPLS over GRE over IP over
Ethernet over n’importe quoi » (Cisco OTV) avec le control-plane
propriétaire, mais pour les gars du monde des serveurs c'est souvent un
avantage puisque la modèle des applications MPLS demande un certain niveau
de connaissance et expertise. Normalement ce type de solution prétende
d'être plug-and-play, assez facile à configurer, et réalisée par
utilisation des commutateurs « optimisés pour DC », comme Cisco Nexus.

- Si ça va être un réseau d'infrastructure, c'est à dire tu as besoin de
certain nombre des service fixes et tu es sûre que tu n'as besoin ni des
milliers des instances des services (VPNs, VRF, vlans, policers,
interfaces) ni des millions des adresses MAC, IP-routes etc, tu peux
choisir une solution MPLS au base des commutateurs qui supportent MPLS,
comme, par exemple, Extreme X460/670 ou anagogiques. Ce type de solution va
bien pour MPLS in the access, quand tu as besoin d'agréger des
DSLAMs/MSANs, ou faire une extension d'une lien de peering en utilisant des
pseudo-wires, etc. Et c'est, sans doute, beaucoup moi cher que les
solutions au base des « vrais routeurs ». Une mis en garde importante ici
c'est les fonctions MPLS supportées par les commutateurs. Normalement ce
type d'équipement a plein des limitations, trucs insupportés et mal
documentés et doit être bien testé avant être mis en production.

(Pardon pour mon mauvais français :)
--
Pavel

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Montgomery SIMONPIETRI]

Bonjour,

Est-ce que vous avez pensé à mettre une solution avec du "redistribute
static route-map" pour éviter d'annoncer les /32 et du prepend sur les
prefix a backuper ?



Du style :

ip route 1.2.3.4 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R1 tag 999
ip route 5.6.7.8 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R2 tag 999

access-list 70 permit 5.6.7.8 0.0.0.255 #SUR R1

access-list 70 permit 1.2.3.4 0.0.0.255 #SUR R2

route-map BACKUP-PREPEND permit 10
 match ip address 70
 set as-path prepend 1234

route-map BACKUP-PREPEND permit 20

route-map TAGGED-STATIC permit 10
 match tag 999

router bgp 1234
 redistribute static route-map TAGGED-STATIC
 neighbor PEER_ADDRESS route-map BACKUP-PREPEND out





2015-11-02 9:16 GMT+01:00 Fabien H :

> Bonjour la liste,
>
> J'ai une question BGP à vous soumettre :
>
> En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
> avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
> Sur chaque routeur BGP, nous avons au moins un transitaire.
>
> Tout fonctionne parfaitement !
>
> Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
> utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
> route Null0).
> Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
> sur le routeur BGP concerné.
>
> - Ma question : Nous aimerions mettre en place un failover BGP automatique
> en cas de défaillance matérielle totale d'un des routeurs BGP.
>
> La solution que j'imaginais est de mettre en place, pour un même prefixe,
> une route Null0 sur les 2 routeurs en même temps.
>
> Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
> les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
> => Si un routeur BGP tombe, l'autre va normalement prendre le relais sans
> problème.
>
> Le seul cas qui pose problème, c'est si les 2 routeurs BGP fonctionnement
> mais que le L2L tombe.
>
> Dans ce cas, un paquet va continuer à arriver par le transit sur le routeur
> BGP concerné, puis la route statique correspondant à l'IP sera appliquée,
> mais l'IP de GW étant normalement accessible via le L2L sur un VLAN donné,
> le routage ne fonctionnera pas car le L2L est tombé.
>
> Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une solution à
> ce problème ?
>
> Merci,
> Bonne journée,
> Fabien
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Jérôme BERTHIER]

Le 03/11/2015 10:12, Raphael Mazelier a écrit :



Le 03/11/15 09:58, Jérôme BERTHIER a écrit :


BFD ne serait pas plus adapté pour faire ça ?



BFD aide a une détection ultra rapide, mais en général ta session IBGP 
doit tomber car ta loopback a disparu de ton IGP. Donc un IGP bien 
tuné est le premier truc à faire.




Tuner l'IGP ne suffit pas forcément si ?
Quand la loopback disparait, du coup, tu attends l'expiration du timer 
BGP hold pour flusher la table de routage ? donc 180s par défaut ?


Il me semble que bfd permet de converger en dessous de la seconde 
puisque tu accroches la session BGP à l'état bfd.
Côté CPU, ça peut être plus light si traité par le data plane (en mode 
echo).


Après il y a surement des cas d'usage plus pertinents que d'autres... et 
surtout que je ne connais pas :-)


Cdt,

--
Jérôme BERTHIER


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Gestion boucle L2

[Nicolas V]

Merci à tous pour vos contributions.

Si j'essaie de résumer les principales technologies qui ont été citées, en
essayant de ne pas dire trop de bêtises :

=> L2 natif
- Fabricpath
- STP / MSTP possible mais à éviter
(MLAG me semble similaire au vPC, donc pas de gestion native d'une boucle à
ma connaissance)

=> L2 sur L3
- VPLS-MPLS
- EVPN-MPLS // EVPN-PBB
- autres techno reposant sur MPLS
- OTV (ou autre techno propriétaire)

Points d'attention à avoir :
- broadcast/multicast
- nombre max d'@mac
- redondance des nPE

Je regarde un peu toutes ces techno.. Si vous remarques des erreurs /
manques, n'hésitez pas


@Guillaume, merci pour la référence du livre, je vais y jeter un œil
prochainement


Nicolas

Le 3 novembre 2015 12:20, Pavel Lunin  a écrit :

>
>
> 2015-11-02 18:15 GMT+01:00 Nicolas V :
>
>> Bonjour,
>>
>> Je cherche à interconnecter plusieurs sites (3 au minima) via une boucle
>> (de 1 à x*10G entre chaque site avec possibilité éventuelle d'ajout de
>> liens 1G). Le but étant de pouvoir faire transiter du L2 de manière
>> transparente.
>>
>> J'ai suivi le mail de Jérémy Martin "Design réseau L2", mais j'ai quelques
>> contraintes / une architecture un peu différente :
>> - Des routeurs ASR9k sur chaque POP => evpn / mpls possible
>> - Des nexus sur chaque POP => fabricpath possible (mais licence
>> nécessaire)
>>
>>
> Ça dépend du type de service tu vas prêter.
>
> - Si c'est bridged multipoint L2 VPN pour les clients B2B, un solution en
> base de « vrai MPLS » est vraiment désirable. En ce cas tu as besoin d'un
> vrai routeur MPLS comme Cisco ASR ou Juniper MX dans chaque PoP.
> Normalement ayant un vrais réseau MPLS tu peux prêter différent types des
> services pour différents types des clients : L2 p2p ou full-mesh des p2p
> avec Martini/Kompella l2circuit/v2vpn aka pseudowire aka VPWS aka PWE3,
> multipoint bridged ethernet avec VPLS ou EVPN, L3VPN, NG-MVPN, si t'en as
> besoin, hub-and-spoke L3VPN etc etc, par-dessus la même infrastructure du
> coeur.
>
> Les vrais routeurs comme ASR/MX sont désirables ici parce que en dehors de
> forwarding et protection ce type d’application aussi demande les choses
> comme policers pour limiter le débit, filtres ACL, conteurs pour billing,
> peut-être NetFlow pour la statistique etc etc. Le scaling (comment on dit
> scaling en français ? graduation ?) est une grande considération aussi dans
> ce cas : normalement tu veux être capable de servir des milliers des
> clients, avoir les tableaux full BGP etc etc.
>
> - Pour interconnexion des DCs (les vrai DCs avec des serveurs, à la
> différence de SP POPs) je préférerais EVPN/VPLS et plus ou moins le même
> type de design comme dans le cas précédent, mais les autres options comme
> Cisco fabricpath sont possibles aussi. Moi personnellement je déteste
> toutes les variations de MAC-in-MAC et toutes les technologies qui essayent
> de cacher la complexité en façon « Ethernet over MPLS over GRE over IP over
> Ethernet over n’importe quoi » (Cisco OTV) avec le control-plane
> propriétaire, mais pour les gars du monde des serveurs c'est souvent un
> avantage puisque la modèle des applications MPLS demande un certain niveau
> de connaissance et expertise. Normalement ce type de solution prétende
> d'être plug-and-play, assez facile à configurer, et réalisée par
> utilisation des commutateurs « optimisés pour DC », comme Cisco Nexus.
>
> - Si ça va être un réseau d'infrastructure, c'est à dire tu as besoin de
> certain nombre des service fixes et tu es sûre que tu n'as besoin ni des
> milliers des instances des services (VPNs, VRF, vlans, policers,
> interfaces) ni des millions des adresses MAC, IP-routes etc, tu peux
> choisir une solution MPLS au base des commutateurs qui supportent MPLS,
> comme, par exemple, Extreme X460/670 ou anagogiques. Ce type de solution va
> bien pour MPLS in the access, quand tu as besoin d'agréger des
> DSLAMs/MSANs, ou faire une extension d'une lien de peering en utilisant des
> pseudo-wires, etc. Et c'est, sans doute, beaucoup moi cher que les
> solutions au base des « vrais routeurs ». Une mis en garde importante ici
> c'est les fonctions MPLS supportées par les commutateurs. Normalement ce
> type d'équipement a plein des limitations, trucs insupportés et mal
> documentés et doit être bien testé avant être mis en production.
>
> (Pardon pour mon mauvais français :)
> --
> Pavel
>



-- 
Nicolas V

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Raphael Mazelier]

Le 03/11/15 15:18, Fabien H a écrit :


@Raphael

Oui c'est ça, les /32 sont envoyés sur différents équipements : LNS, FW
puis par exemple sur le LNS, il y'a une interface avec un masque en /31





Dans ce cas le mieux c'est que tes équipements FW/LNS annoncent leurs 
préfixes aux deux routeurs via le protocole de ton choix (BGP est 
souvent un bon choix).



--
Raphael Mazelier


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] QOS voix switch cisco

[David Ponzone]

Sur le switch, je pense que je me contenterais de faire du trust cos sur tous 
les postes, si bien entendu les flux SIGNALING et AUDIO sont correctement 
taggés par tes endpoints.
Ensuite sur le routeur, je ferais du « shape average » de la data en output sur 
le lien WAN afin de garder X% pour la voix, et de même sur le port qui va vers 
le switch (ce qui correspond à l’INPUT du WAN).
Ca ne résistera pas à un bombardement massif en UDP (Torrent par exemple).
Pour ça, il faut que tu contrôles le routeur de l’autre côté du WAN pour mettre 
la même règle, ou que le FAI te le fasse.


> Le 3 nov. 2015 à 19:20, Antoine Durant  a écrit :
> 
> "-tu fais du policy en INPUT, alors que c’est là que c’est le plus délicat, 
> voir impossible sur du trafic UDP"
> Parceque sur le switch il n'est pas possible de faire en OUPUT...
> 
> "-tu « polices »  l’AUDIO ? Généralement, l’idée est plutôt de « policer »  
> le reste pour être sur que l’audio ait de la place"
> Oui, j'ai lu cela à plusieurs reprise sur des configurations Donc à la 
> place de POLICE il faut utiliser quoi alors ? une réservation de bande 
> passante ?
> 
> De : David Ponzone 
> À : Antoine Durant  
> Cc : frnog-tech  
> Envoyé le : Mardi 3 novembre 2015 19h15
> Objet : Re: [FRnOG] [TECH] QOS voix switch cisco
> 
> 2 commentaires:
> -tu fais du policy en INPUT, alors que c’est là que c’est le plus délicat, 
> voir impossible sur du trafic UDP
> -tu « polices »  l’AUDIO ? Généralement, l’idée est plutôt de « policer »  le 
> reste pour être sur que l’audio ait de la place
> 
> 
> 
> > Le 3 nov. 2015 à 19:06, Antoine Durant  > > a écrit :
> > 
> > Bonsoir :)
> > Voici la configuration que je pense être "bonne", est-ce que pour vous cela 
> > semble OK pour la QOS VOIX ??
> > Le port fa0/1 est un uplink connecté à un switch non managable (sur 
> > celui-ci il ya des postes + téléphone IP non cisco)le port fa0/10 est 
> > l'uplink vers le routeur internet
> > 
> > !mls qos
> > !
> > class-map match-all SIGNALING
> >  match access-group name SIGNALING
> > class-map match-all AUDIO
> >  match access-group name AUDIO
> > !
> > policy-map QOS
> > class AUDIO
> >set ip dscp ef
> >police 48000 8000 exceed-action drop
> > class SIGNALING
> >set ip dscp af31
> >police 1 8000 exceed-action drop
> > !
> > interface FastEthernet0/1
> > description * uplink sous-switch *
> > switchport access vlan 10
> > switchport mode access
> > switchport nonegotiate
> > mls qos trust cos
> > spanning-tree portfast
> > service-policy input QOS
> > !
> > interface FastEthernet0/10
> > description * uplink vers ROUTEUR WAN *
> > switchport trunk allowed vlan 10,11
> > switchport mode trunk
> > mls qos trust cos ??
> > spanning-tree portfast
> > service-policy input QOS
> > !
> > ip access-list extended AUDIO
> > permit udp any any range 16384 32767
> > ip access-list extended SIGNALING
> > permit tcp any any range 2000 2002
> > permit tcp any any range 5060 5061
> > !
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/ 
> 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] QOS voix switch cisco

[David Ponzone]

> Le 3 nov. 2015 à 19:57, Antoine Durant  a écrit :
> 
> "Sur le switch, je pense que je me contenterais de faire du trust cos sur 
> tous les postes, si bien entendu les flux SIGNALING et AUDIO sont 
> correctement taggés par tes endpoints."
> Donc si je comprend ton avis, il faut que j'active *mls qos trust cos* sur 
> tout les ports du switch à conditions que mes téléphones taguent bien le 
> COS/SDCP ??

Ouais, à priori, sinon voir doc chez Cisco, il y a peut-être des subtilités.

> "Ensuite sur le routeur, je ferais du « shape average » de la data en output 
> sur le lien WAN afin de garder X% pour la voix, et de même sur le port qui va 
> vers le switch (ce qui correspond à l’INPUT du WAN)."
> Comment tu réalise le shape average sur le routeur ?? 
> 
> !
> mls qos
> !
> class-map match-all SIGNALING
>   match access-group name SIGNALING
> class-map match-all AUDIO
>   match access-group name AUDIO
> !
> policy-map QOS
> class AUDIO
>set ip dscp ef  
>shape average 200
> class SIGNALING
>set ip dscp af31
>shape average 200
> !
> ip access-list extended AUDIO
> permit udp any any range 16384 32767
> ip access-list extended SIGNALING
> permit tcp any any range 2000 2002
> permit tcp any any range 5060 5061
> !
> interface WAN
>  mls qos trust cos
>  service-policy output QOS
> !
> 

Presque ça, sauf que là, tu shapes le trafic voix à 2Mbps :)
Ce que tu veux, c’est shaper ta data à 200*0.9 par exemple, donc 1.8Mbps, 
pour laisser 200Kbps minimum pour la voix.
Les Service Policy de Cisco, c’est quand même un gros gros bordel, il y a X 
manières de faire les choses, dont un certain nombre qui ne marchent pas sur 
tel ou tel hardware et/ou IOS.
Personnellement, je vais au plus simple.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] QOS voix switch cisco

[David Ponzone]

> Le 3 nov. 2015 à 20:31, Antoine Durant  a écrit :
> 
> J'ai pas tout compris :\
> 
> "Presque ça, sauf que là, tu shapes le trafic voix à 2Mbps :)
> Ce que tu veux, c’est shaper ta data à 200*0.9 par exemple, donc 1.8Mbps, 
> pour laisser 200Kbps minimum pour la voix."
> Oui je veux limiter la data pour laisser place à la voix. par exemple sur un 
> lien 4M je veux laisser 2M pour la voix. Comment tu fais le shape pour 
> exclure la data pour laisser prio la voix ?

Tu fais une ACL basée sur des deny, plutôt que des permit.

> A quoi correspond le 0.9 ?

J’ai pris une valeur d’exemple, qui consisterait à limiter la data à 90% du 
lien.
Là c’est à toi de voir.

> "Les Service Policy de Cisco, c’est quand même un gros gros bordel, il y a X 
> manières de faire les choses, dont un certain nombre qui ne marchent pas sur 
> tel ou tel hardware et/ou IOS."
> Oui la je m'arrache le peu de cheveux qui me reste
> 
> "Personnellement, je vais au plus simple."
> C'est quoi alors le plus simple selon toi?

Ben ce que je viens de dire.
Certains diraient qu’on perd de la capa max pour la data, même quand il n’y a 
pas d’appels VoIP.
Perso, je préfère ça plutôt que de chercher à comprendre lequel des algos 
obscurs de Cisco pour faire de la prioritisation n’est pas buggué sur mon 
HW/IOS.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] QOS voix switch cisco

[Antoine Durant]

"-tu fais du policy en INPUT, alors que c’est là que c’est le plus délicat, 
voir impossible sur du trafic UDP"Parceque sur le switch il n'est pas possible 
de faire en OUPUT...
"-tu « polices »  l’AUDIO ? Généralement, l’idée est plutôt de « policer »  le 
reste pour être sur que l’audio ait de la place"Oui, j'ai lu cela à plusieurs 
reprise sur des configurations Donc à la place de POLICE il faut utiliser 
quoi alors ? une réservation de bande passante ?

  De : David Ponzone 
 À : Antoine Durant  
Cc : frnog-tech  
 Envoyé le : Mardi 3 novembre 2015 19h15
 Objet : Re: [FRnOG] [TECH] QOS voix switch cisco
   
2 commentaires:
-tu fais du policy en INPUT, alors que c’est là que c’est le plus délicat, voir 
impossible sur du trafic UDP-tu « polices »  l’AUDIO ? Généralement, l’idée est 
plutôt de « policer »  le reste pour être sur que l’audio ait de la place


> Le 3 nov. 2015 à 19:06, Antoine Durant  a écrit :
> 
> Bonsoir :)
> Voici la configuration que je pense être "bonne", est-ce que pour vous cela 
> semble OK pour la QOS VOIX ??
> Le port fa0/1 est un uplink connecté à un switch non managable (sur celui-ci 
> il ya des postes + téléphone IP non cisco)le port fa0/10 est l'uplink vers le 
> routeur internet
> 
> !mls qos
> !
> class-map match-all SIGNALING
>  match access-group name SIGNALING
> class-map match-all AUDIO
>  match access-group name AUDIO
> !
> policy-map QOS
> class AUDIO
>    set ip dscp ef
>    police 48000 8000 exceed-action drop
> class SIGNALING
>    set ip dscp af31
>    police 1 8000 exceed-action drop
> !
> interface FastEthernet0/1
> description * uplink sous-switch *
> switchport access vlan 10
> switchport mode access
> switchport nonegotiate
> mls qos trust cos
> spanning-tree portfast
> service-policy input QOS
> !
> interface FastEthernet0/10
> description * uplink vers ROUTEUR WAN *
> switchport trunk allowed vlan 10,11
> switchport mode trunk
> mls qos trust cos ??
> spanning-tree portfast
> service-policy input QOS
> !
> ip access-list extended AUDIO
> permit udp any any range 16384 32767
> ip access-list extended SIGNALING
> permit tcp any any range 2000 2002
> permit tcp any any range 5060 5061
> !
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


  
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] QOS voix switch cisco

[Antoine Durant]

J'ai pas tout compris :\
"Presque ça, sauf que là, tu shapes le trafic voix à 2Mbps :)Ce que tu veux, 
c’est shaper ta data à 200*0.9 par exemple, donc 1.8Mbps, pour laisser 
200Kbps minimum pour la voix."Oui je veux limiter la data pour laisser place à 
la voix. par exemple sur un lien 4M je veux laisser 2M pour la voix. Comment tu 
fais le shape pour exclure la data pour laisser prio la voix ?
A quoi correspond le 0.9 ?

"Les Service Policy de Cisco, c’est quand même un gros gros bordel, il y a X 
manières de faire les choses, dont un certain nombre qui ne marchent pas sur 
tel ou tel hardware et/ou IOS."Oui la je m'arrache le peu de cheveux qui me 
reste

"Personnellement, je vais au plus simple."C'est quoi alors le plus simple selon 
toi?


  
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] QOS voix switch cisco

[Antoine Durant]

"Sur le switch, je pense que je me contenterais de faire du trust cos sur tous 
les postes, si bien entendu les flux SIGNALING et AUDIO sont correctement 
taggés par tes endpoints."Donc si je comprend ton avis, il faut que j'active 
*mls qos trust cos* sur tout les ports du switch à conditions que mes 
téléphones taguent bien le COS/SDCP ??
"Ensuite sur le routeur, je ferais du « shape average » de la data en output 
sur le lien WAN afin de garder X% pour la voix, et de même sur le port qui va 
vers le switch (ce qui correspond à l’INPUT du WAN)."Comment tu réalise le 
shape average sur le routeur ?? 

!
mls qos
!
class-map match-all SIGNALING
  match access-group name SIGNALING
class-map match-all AUDIO
  match access-group name AUDIO
!
policy-map QOS
class AUDIO
   set ip dscp ef  
   shape average 200
class SIGNALING
   set ip dscp af31
   shape average 200
!
ip access-list extended AUDIO
permit udp any any range 16384 32767
ip access-list extended SIGNALING
permit tcp any any range 2000 2002
permit tcp any any range 5060 5061
!
interface WAN
 mls qos trust cos
 service-policy output QOS
!



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Jérôme Nicolle]

Le 03/11/2015 17:38, Raphael Mazelier a écrit :
> Oui ça va mieux en le disant :)

Ou en suggérant que ces routeurs soient en plus configurés comme
route-reflectors, pourvu que plusieurs FW s'y mettent ;)

-- 
Jérôme Nicolle
06 19 31 27 14


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] QOS voix switch cisco

[David Ponzone]

2 commentaires:
-tu fais du policy en INPUT, alors que c’est là que c’est le plus délicat, voir 
impossible sur du trafic UDP
-tu « polices »  l’AUDIO ? Généralement, l’idée est plutôt de « policer »  le 
reste pour être sur que l’audio ait de la place

> Le 3 nov. 2015 à 19:06, Antoine Durant  a écrit :
> 
> Bonsoir :)
> Voici la configuration que je pense être "bonne", est-ce que pour vous cela 
> semble OK pour la QOS VOIX ??
> Le port fa0/1 est un uplink connecté à un switch non managable (sur celui-ci 
> il ya des postes + téléphone IP non cisco)le port fa0/10 est l'uplink vers le 
> routeur internet
> 
> !mls qos
> !
> class-map match-all SIGNALING
>   match access-group name SIGNALING
> class-map match-all AUDIO
>   match access-group name AUDIO
> !
> policy-map QOS
> class AUDIO
>set ip dscp ef
>police 48000 8000 exceed-action drop
> class SIGNALING
>set ip dscp af31
>police 1 8000 exceed-action drop
> !
> interface FastEthernet0/1
> description * uplink sous-switch *
> switchport access vlan 10
> switchport mode access
> switchport nonegotiate
> mls qos trust cos
> spanning-tree portfast
> service-policy input QOS
> !
> interface FastEthernet0/10
> description * uplink vers ROUTEUR WAN *
> switchport trunk allowed vlan 10,11
> switchport mode trunk
> mls qos trust cos ??
> spanning-tree portfast
> service-policy input QOS
> !
> ip access-list extended AUDIO
> permit udp any any range 16384 32767
> ip access-list extended SIGNALING
> permit tcp any any range 2000 2002
> permit tcp any any range 5060 5061
> !
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Gestion boucle L2

[Jérôme Nicolle]

Le 03/11/2015 16:48, Nicolas V a écrit :
> => L2 sur L3
> - VPLS-MPLS
> - EVPN-MPLS // EVPN-PBB
> - autres techno reposant sur MPLS
> - OTV (ou autre techno propriétaire)

+ Mix/mesh de tunnels EoIP / * sur un réseau de transport IPv4 ou IPv6
simple, entre des routeurs sur lesquels tu instancies des bridges.

C'est la méthode applicable à du Mikrotik sans avoir à dégainer MPLS.

C'est moins cher, plus flexible, et ça permet de migrer progressivement
et sereinement du L2 au L3.

@+

-- 
Jérôme Nicolle
06 19 31 27 14


---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] QOS voix switch cisco

[Michel Py]

> Antoine Durant
> Voici la configuration que je pense être "bonne", est-ce que pour vous cela 
> semble OK pour la QOS VOIX ??

C'est compliqué. Pour la voix en local, c'est bien plus simple de faire un VLAN 
pour la voix et un autre pour les données et mettre la priorité sur la voix, 
que de se faire chier à faire du QOS en L3.

Michel.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] QOS voix switch cisco

[Jean-Edouard Babin]

J'en profite puisqu'on parle de shape average et voix..
Est-ce que quelqu'un à déjà testé la difference d'effet entre les deux config 
ci dessous.
C'est à dire:
Si on a un lien 40M
 - faire un priority 3M et shaper le reste a 37M 
ou
 - shaper tout à 40M et reserver 3M dedans.

On pourrait se dire que le fait d'avoir un priority 3M "permanent" rend un 
meilleurs service que l'activer uniquement en cas de congestion.
Notament en cas de micro burst créant du queuing en sortie, les paquets voice 
sortirait plus vite que les autres.
En pratique avec après quelques test, j'ai jamais réussi à faire une simulation 
qui montre une difference.
Je suis donc preneur de vos avis et experience!


policy-map QoS_Shaping_T40M
 class QoS_Voice
  priority 3000
 class class-default
  shape average 3700
   service-policy QoS_Queuing

policy-map QoS_Queuing
 class QoS_...
  bandwidth percent 60
...

et

policy-map QoS_Shaping_T40M
 class class-default
  shape average 4000
  service-policy QoS_Queuing

policy-map QoS_Queuing
 class QoS_Voice
  priority 3000
 class QoS_...
  bandwidth remaining percent 60
.


> On 03 Nov 2015, at 19:42, David Ponzone  wrote:
> 
> Sur le switch, je pense que je me contenterais de faire du trust cos sur tous 
> les postes, si bien entendu les flux SIGNALING et AUDIO sont correctement 
> taggés par tes endpoints.
> Ensuite sur le routeur, je ferais du « shape average » de la data en output 
> sur le lien WAN afin de garder X% pour la voix, et de même sur le port qui va 
> vers le switch (ce qui correspond à l’INPUT du WAN).
> Ca ne résistera pas à un bombardement massif en UDP (Torrent par exemple).
> Pour ça, il faut que tu contrôles le routeur de l’autre côté du WAN pour 
> mettre la même règle, ou que le FAI te le fasse.
> 
> 
>> Le 3 nov. 2015 à 19:20, Antoine Durant  a écrit :
>> 
>> "-tu fais du policy en INPUT, alors que c’est là que c’est le plus délicat, 
>> voir impossible sur du trafic UDP"
>> Parceque sur le switch il n'est pas possible de faire en OUPUT...
>> 
>> "-tu « polices »  l’AUDIO ? Généralement, l’idée est plutôt de « policer »  
>> le reste pour être sur que l’audio ait de la place"
>> Oui, j'ai lu cela à plusieurs reprise sur des configurations Donc à la 
>> place de POLICE il faut utiliser quoi alors ? une réservation de bande 
>> passante ?
>> 
>> De : David Ponzone 
>> À : Antoine Durant  
>> Cc : frnog-tech  
>> Envoyé le : Mardi 3 novembre 2015 19h15
>> Objet : Re: [FRnOG] [TECH] QOS voix switch cisco
>> 
>> 2 commentaires:
>> -tu fais du policy en INPUT, alors que c’est là que c’est le plus délicat, 
>> voir impossible sur du trafic UDP
>> -tu « polices »  l’AUDIO ? Généralement, l’idée est plutôt de « policer »  
>> le reste pour être sur que l’audio ait de la place
>> 
>> 
>> 
>>> Le 3 nov. 2015 à 19:06, Antoine Durant >> > a écrit :
>>> 
>>> Bonsoir :)
>>> Voici la configuration que je pense être "bonne", est-ce que pour vous cela 
>>> semble OK pour la QOS VOIX ??
>>> Le port fa0/1 est un uplink connecté à un switch non managable (sur 
>>> celui-ci il ya des postes + téléphone IP non cisco)le port fa0/10 est 
>>> l'uplink vers le routeur internet
>>> 
>>> !mls qos
>>> !
>>> class-map match-all SIGNALING
>>> match access-group name SIGNALING
>>> class-map match-all AUDIO
>>> match access-group name AUDIO
>>> !
>>> policy-map QOS
>>> class AUDIO
>>>   set ip dscp ef
>>>   police 48000 8000 exceed-action drop
>>> class SIGNALING
>>>   set ip dscp af31
>>>   police 1 8000 exceed-action drop
>>> !
>>> interface FastEthernet0/1
>>> description * uplink sous-switch *
>>> switchport access vlan 10
>>> switchport mode access
>>> switchport nonegotiate
>>> mls qos trust cos
>>> spanning-tree portfast
>>> service-policy input QOS
>>> !
>>> interface FastEthernet0/10
>>> description * uplink vers ROUTEUR WAN *
>>> switchport trunk allowed vlan 10,11
>>> switchport mode trunk
>>> mls qos trust cos ??
>>> spanning-tree portfast
>>> service-policy input QOS
>>> !
>>> ip access-list extended AUDIO
>>> permit udp any any range 16384 32767
>>> ip access-list extended SIGNALING
>>> permit tcp any any range 2000 2002
>>> permit tcp any any range 5060 5061
>>> !
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/ 
>> 
>> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] QOS voix switch cisco

[Antoine Durant]

"Tu fais une ACL basée sur des deny, plutôt que des permit."OK... Je vois ! 
Quelque chose comme ça alors ??
!
mls qos
!
class-map match-all VOIP
  match access-group name SIGNALING
  match access-group name AUDIO
!
ip access-list extended AUDIO
permit udp any any range 16384 32767
ip access-list extended SIGNALING
permit tcp any any range 2000 2002
permit tcp any any range 5060 5061
!
policy-map wan-queue-policy
 class VOIP
  priority 180
 class class-default
  fair-queue
  random-detect
!
policy-map wan-shape-policy
 class class-default
  shape average 200
   service-policy wan-queue-policy
!
interface WAN
 service-policy out wan-shape-policy
!

"J’ai pris une valeur d’exemple, qui consisterait à limiter la data à 90% du 
lien."D'accord oui c'est fonction du nombre d'appel que je veux pouvoir assurer 
sur le lien.


"Certains diraient qu’on perd de la capa max pour la data, même quand il n’y a 
pas d’appels VoIP."Ha ha je savais pas !? Donc en fait la QOS n'est pas 
dynamique, c'est à dire que à un instant X si pas de VOIP il ne sera pas 
possible d'utiliser toute la capacité du tuyau ?





  
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re : Re: [FRnOG] [TECH] QOS voix switch cisco

[Antoine Durant]

Quel soft existe pour tester si la réservation de la QOS VOIX est fonctionnelle 
??

Je pensai lancer un iperf pour monopoliser le lien en data mais ensuite je ne 
sais pas comment lancer le test pour la VOIX  Je suis en test je ne touche 
pas encore au matos de production!
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] QOS voix switch cisco

[David Ponzone]

Le 3 nov. 2015 à 20:57, Antoine Durant  a écrit :
> 
> "Tu fais une ACL basée sur des deny, plutôt que des permit."
> OK... Je vois ! Quelque chose comme ça alors ??
> 
> !
> mls qos
> !
> class-map match-all VOIP
>   match access-group name SIGNALING
>   match access-group name AUDIO
> !
> ip access-list extended AUDIO
> permit udp any any range 16384 32767
> ip access-list extended SIGNALING
> permit tcp any any range 2000 2002
> permit tcp any any range 5060 5061
> !
> policy-map wan-queue-policy
>  class VOIP
>   priority 180
>  class class-default
>   fair-queue
>   random-detect
> !
> policy-map wan-shape-policy
>  class class-default
>   shape average 200
>service-policy wan-queue-policy
> !
> interface WAN
>  service-policy out wan-shape-policy
> !
> 

Pas tout à fait.
Là, tu shapes tout le trafic à 2Mbps (tu aurais dû mettre 4Mbps si ton lien 
fait 4) et tu as une sous-policymap qui met une priorité à la VOIP à 180Kbps.
C’est justement le genre de truc que je n’utilise pas, parce qu’en lisant de la 
doc chez Cisco et sur des forums, j’ai vu trop de « but…. » «  doesn’t work on 
…. » « is not compatible with…. » .
Mais ça ferait ce que tu veux: ne pas dédier de bande passante pour la voix, 
donc avoir le max dispo pour la data si possible.

> "J’ai pris une valeur d’exemple, qui consisterait à limiter la data à 90% du 
> lien."
> D'accord oui c'est fonction du nombre d'appel que je veux pouvoir assurer sur 
> le lien.

Voilà. Si tu es en G711 et que tu as besoin de 10 appels, tu dois prévoir 1Mbps.

> "Certains diraient qu’on perd de la capa max pour la data, même quand il n’y 
> a pas d’appels VoIP."
> Ha ha je savais pas !? Donc en fait la QOS n'est pas dynamique, c'est à dire 
> que à un instant X si pas de VOIP il ne sera pas possible d'utiliser toute la 
> capacité du tuyau ?

Ca dépend laquelle.
Celle que tu as mis plus haut est dynamique.
Moi, ma vision des choses pour ne pas être emmerdé, c’est une policy-map qui 
shape le trafic DATA seulement à X% de la bande passante max du lien, afin 
qu’il me reste (100-X)% dédié à la VOIX.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE:[FRnOG] [TECH] Gestion boucle L2

[Ville numérique]

Et EAPS G.8032 chez Xtreme networks ; apparemment pas seulement réseau d'accès
voir schéma 
https://community.extremenetworks.com/extreme/topics/compatibility-between-eaps-and-g-8032-erps


De : frnog-requ...@frnog.org [frnog-requ...@frnog.org] de la part de Denis 
Fondras [xx...@ledeuns.net]
Envoyé : mercredi 4 novembre 2015 08:13
À : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] Gestion boucle L2

> => L2 natif
> - Fabricpath
> - STP / MSTP possible mais à éviter
> (MLAG me semble similaire au vPC, donc pas de gestion native d'une boucle à
> ma connaissance)
>

Et des choses comme ERPS/G.8032 ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] QOS voix switch cisco

[David Ponzone]

Oui Michel, mais cela ne règle pas ton problème sur le WAN.

> Le 3 nov. 2015 à 23:07, Michel Py  a 
> écrit :
> 
>> Antoine Durant
>> Voici la configuration que je pense être "bonne", est-ce que pour vous cela 
>> semble OK pour la QOS VOIX ??
> 
> C'est compliqué. Pour la voix en local, c'est bien plus simple de faire un 
> VLAN pour la voix et un autre pour les données et mettre la priorité sur la 
> voix, que de se faire chier à faire du QOS en L3.
> 
> Michel.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Gestion boucle L2

[Denis Fondras]

> => L2 natif
> - Fabricpath
> - STP / MSTP possible mais à éviter
> (MLAG me semble similaire au vPC, donc pas de gestion native d'une boucle à
> ma connaissance)
> 

Et des choses comme ERPS/G.8032 ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] QOS voix switch cisco

[David Ponzone]

Tu prends ton téléphone IP et tu appelles.
Tu prends 10 téléphones IP et tu appelles.
En VOIP, l’important est le ressenti subjectif de l’utilisateur, donc soit tu 
testes à la main, soit tu fais appel à une produit qui mesure le MOSPESQ mais 
la plupart sont commerciaux.
Tu peux aussi probablement bricoler un truc pas trop mal avec SIPp.

> Le 4 nov. 2015 à 07:20, Antoine Durant  a écrit :
> 
> Quel soft existe pour tester si la réservation de la QOS VOIX est 
> fonctionnelle ??
> 
> Je pensai lancer un iperf pour monopoliser le lien en data mais ensuite je ne 
> sais pas comment lancer le test pour la VOIX  Je suis en test je ne 
> touche pas encore au matos de production!
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] coupure internet SFR

[Jhonny CASTILLO]

Bonjour à tous,
vous savez si il y a des problèmes sur sfr
merci de vos retour

Cordialement.

Jhonny CASTILLO



Administrateur Systèmes et Réseaux
Fondation WWF France
1 Carrefour de Longchamp
75116 Paris
Tel: 01 55 25 84 84
Port: 06 25 45 45 09
Ligne Directe: 01 55 25 84 50
Fax : 01 55 25 84 74

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] coupure internet SFR

[Clement Cavadore]

Bonjour,

On Tue, 2015-11-03 at 15:37 +0100, Jhonny CASTILLO wrote:
> vous savez si il y a des problèmes sur sfr

Sans informations complémentaires (au moins le type de service),
impossible de te répondre. Les services que j'utilise chez SFR sont up,
en ce moment.

-- 
Clément Cavadore


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Montgomery SIMONPIETRI]

Il faudra sans doute dupliquer les routes sur les deux routeurs, mais en
ajoutant du tracking ip sla pour etre sur de les mettre dans la table
uniquement en cas de failover.

Sur R1 :

ip sla 123
 icmp-echo IP_LAN_R2 source-ip IP_LAN_R1
 frequency 5
ip sla schedule 123 life forever start-time now

track 123 ip sla 123 reachability
 delay down 25

ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 track 123


Et vice-versa sur R2.
Est-ce que je suis à côté ?

Montgomery



2015-11-03 14:28 GMT+01:00 Fabien H :

> Bonjour,
>
> merci, si j'ai bien compris, cette solution s'approche un peu du
> redistribute en EIGRP mais en BGP. C'est effectivement à tester.
>
> Mais je bloque toujours sur le besoin de failover Routeur BGP.
>
> Si R1 tombe, ses routes disparaissent de la table de R2, et du coup R2 ne
> pourra pas assurer le failover de R1 pour les routes en /32...
>
> Le 3 novembre 2015 14:16, Montgomery SIMONPIETRI <
> montgom...@simonpietri.net> a écrit :
>
>> Bonjour,
>>
>> Est-ce que vous avez pensé à mettre une solution avec du "redistribute
>> static route-map" pour éviter d'annoncer les /32 et du prepend sur les
>> prefix a backuper ?
>>
>>
>>
>> Du style :
>>
>> ip route 1.2.3.4 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R1 tag 999
>> ip route 5.6.7.8 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R2 tag 999
>>
>> access-list 70 permit 5.6.7.8 0.0.0.255 #SUR R1
>>
>> access-list 70 permit 1.2.3.4 0.0.0.255 #SUR R2
>>
>> route-map BACKUP-PREPEND permit 10
>>  match ip address 70
>>  set as-path prepend 1234
>>
>> route-map BACKUP-PREPEND permit 20
>>
>> route-map TAGGED-STATIC permit 10
>>  match tag 999
>>
>> router bgp 1234
>>  redistribute static route-map TAGGED-STATIC
>>  neighbor PEER_ADDRESS route-map BACKUP-PREPEND out
>>
>>
>>
>>
>>
>> 2015-11-02 9:16 GMT+01:00 Fabien H :
>>
>>> Bonjour la liste,
>>>
>>> J'ai une question BGP à vous soumettre :
>>>
>>> En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
>>> avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
>>> Sur chaque routeur BGP, nous avons au moins un transitaire.
>>>
>>> Tout fonctionne parfaitement !
>>>
>>> Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
>>> utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
>>> route Null0).
>>> Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
>>> sur le routeur BGP concerné.
>>>
>>> - Ma question : Nous aimerions mettre en place un failover BGP
>>> automatique
>>> en cas de défaillance matérielle totale d'un des routeurs BGP.
>>>
>>> La solution que j'imaginais est de mettre en place, pour un même prefixe,
>>> une route Null0 sur les 2 routeurs en même temps.
>>>
>>> Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
>>> les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
>>> => Si un routeur BGP tombe, l'autre va normalement prendre le relais sans
>>> problème.
>>>
>>> Le seul cas qui pose problème, c'est si les 2 routeurs BGP fonctionnement
>>> mais que le L2L tombe.
>>>
>>> Dans ce cas, un paquet va continuer à arriver par le transit sur le
>>> routeur
>>> BGP concerné, puis la route statique correspondant à l'IP sera appliquée,
>>> mais l'IP de GW étant normalement accessible via le L2L sur un VLAN
>>> donné,
>>> le routage ne fonctionnera pas car le L2L est tombé.
>>>
>>> Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
>>> solution à
>>> ce problème ?
>>>
>>> Merci,
>>> Bonne journée,
>>> Fabien
>>>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>>
>>
>>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

Oui, c'est tout à fait ça !

Peut-être juste inverser la condition c'est à dire installer la route quand
R2 n'est pas reachable plutot que quand il est reachable mais apparemment
c'est faisable :

track 456 list boolean and
 object 123 not

Ca commence à être tiré par les cheveux .. ! A voir


Le 3 novembre 2015 14:47, Montgomery SIMONPIETRI  a écrit :

> Il faudra sans doute dupliquer les routes sur les deux routeurs, mais en
> ajoutant du tracking ip sla pour etre sur de les mettre dans la table
> uniquement en cas de failover.
>
> Sur R1 :
>
> ip sla 123
>  icmp-echo IP_LAN_R2 source-ip IP_LAN_R1
>  frequency 5
> ip sla schedule 123 life forever start-time now
>
> track 123 ip sla 123 reachability
>  delay down 25
>
> ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 track 123
>
>
> Et vice-versa sur R2.
> Est-ce que je suis à côté ?
>
> Montgomery
>
>
>
> 2015-11-03 14:28 GMT+01:00 Fabien H :
>
>> Bonjour,
>>
>> merci, si j'ai bien compris, cette solution s'approche un peu du
>> redistribute en EIGRP mais en BGP. C'est effectivement à tester.
>>
>> Mais je bloque toujours sur le besoin de failover Routeur BGP.
>>
>> Si R1 tombe, ses routes disparaissent de la table de R2, et du coup R2 ne
>> pourra pas assurer le failover de R1 pour les routes en /32...
>>
>> Le 3 novembre 2015 14:16, Montgomery SIMONPIETRI <
>> montgom...@simonpietri.net> a écrit :
>>
>>> Bonjour,
>>>
>>> Est-ce que vous avez pensé à mettre une solution avec du "redistribute
>>> static route-map" pour éviter d'annoncer les /32 et du prepend sur les
>>> prefix a backuper ?
>>>
>>>
>>>
>>> Du style :
>>>
>>> ip route 1.2.3.4 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R1 tag 999
>>> ip route 5.6.7.8 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R2 tag 999
>>>
>>> access-list 70 permit 5.6.7.8 0.0.0.255 #SUR R1
>>>
>>> access-list 70 permit 1.2.3.4 0.0.0.255 #SUR R2
>>>
>>> route-map BACKUP-PREPEND permit 10
>>>  match ip address 70
>>>  set as-path prepend 1234
>>>
>>> route-map BACKUP-PREPEND permit 20
>>>
>>> route-map TAGGED-STATIC permit 10
>>>  match tag 999
>>>
>>> router bgp 1234
>>>  redistribute static route-map TAGGED-STATIC
>>>  neighbor PEER_ADDRESS route-map BACKUP-PREPEND out
>>>
>>>
>>>
>>>
>>>
>>> 2015-11-02 9:16 GMT+01:00 Fabien H :
>>>
 Bonjour la liste,

 J'ai une question BGP à vous soumettre :

 En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
 avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
 Sur chaque routeur BGP, nous avons au moins un transitaire.

 Tout fonctionne parfaitement !

 Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
 utilisant une route Null0) et un préfixe localisé sur le routeur 2 (idem
 route Null0).
 Puis pour chaque IP /32 dans le prefixe, nous avons des routes statiques
 sur le routeur BGP concerné.

 - Ma question : Nous aimerions mettre en place un failover BGP
 automatique
 en cas de défaillance matérielle totale d'un des routeurs BGP.

 La solution que j'imaginais est de mettre en place, pour un même
 prefixe,
 une route Null0 sur les 2 routeurs en même temps.

 Sur les tests que j'ai fait, ça marche si on duplique la route Null0 sur
 les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
 => Si un routeur BGP tombe, l'autre va normalement prendre le relais
 sans
 problème.

 Le seul cas qui pose problème, c'est si les 2 routeurs BGP
 fonctionnement
 mais que le L2L tombe.

 Dans ce cas, un paquet va continuer à arriver par le transit sur le
 routeur
 BGP concerné, puis la route statique correspondant à l'IP sera
 appliquée,
 mais l'IP de GW étant normalement accessible via le L2L sur un VLAN
 donné,
 le routage ne fonctionnera pas car le L2L est tombé.

 Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
 solution à
 ce problème ?

 Merci,
 Bonne journée,
 Fabien

 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/

>>>
>>>
>>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Montgomery SIMONPIETRI]

Exact ! Il faut inverser la condition ;)

2015-11-03 15:01 GMT+01:00 Fabien H :

> Oui, c'est tout à fait ça !
>
> Peut-être juste inverser la condition c'est à dire installer la route
> quand R2 n'est pas reachable plutot que quand il est reachable mais
> apparemment c'est faisable :
>
> track 456 list boolean and
>  object 123 not
>
> Ca commence à être tiré par les cheveux .. ! A voir
>
>
> Le 3 novembre 2015 14:47, Montgomery SIMONPIETRI <
> montgom...@simonpietri.net> a écrit :
>
>> Il faudra sans doute dupliquer les routes sur les deux routeurs, mais en
>> ajoutant du tracking ip sla pour etre sur de les mettre dans la table
>> uniquement en cas de failover.
>>
>> Sur R1 :
>>
>> ip sla 123
>>  icmp-echo IP_LAN_R2 source-ip IP_LAN_R1
>>  frequency 5
>> ip sla schedule 123 life forever start-time now
>>
>> track 123 ip sla 123 reachability
>>  delay down 25
>>
>> ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 track 123
>>
>>
>> Et vice-versa sur R2.
>> Est-ce que je suis à côté ?
>>
>> Montgomery
>>
>>
>>
>> 2015-11-03 14:28 GMT+01:00 Fabien H :
>>
>>> Bonjour,
>>>
>>> merci, si j'ai bien compris, cette solution s'approche un peu du
>>> redistribute en EIGRP mais en BGP. C'est effectivement à tester.
>>>
>>> Mais je bloque toujours sur le besoin de failover Routeur BGP.
>>>
>>> Si R1 tombe, ses routes disparaissent de la table de R2, et du coup R2
>>> ne pourra pas assurer le failover de R1 pour les routes en /32...
>>>
>>> Le 3 novembre 2015 14:16, Montgomery SIMONPIETRI <
>>> montgom...@simonpietri.net> a écrit :
>>>
 Bonjour,

 Est-ce que vous avez pensé à mettre une solution avec du "redistribute
 static route-map" pour éviter d'annoncer les /32 et du prepend sur les
 prefix a backuper ?



 Du style :

 ip route 1.2.3.4 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R1 tag 999
 ip route 5.6.7.8 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R2 tag 999

 access-list 70 permit 5.6.7.8 0.0.0.255 #SUR R1

 access-list 70 permit 1.2.3.4 0.0.0.255 #SUR R2

 route-map BACKUP-PREPEND permit 10
  match ip address 70
  set as-path prepend 1234

 route-map BACKUP-PREPEND permit 20

 route-map TAGGED-STATIC permit 10
  match tag 999

 router bgp 1234
  redistribute static route-map TAGGED-STATIC
  neighbor PEER_ADDRESS route-map BACKUP-PREPEND out





 2015-11-02 9:16 GMT+01:00 Fabien H :

> Bonjour la liste,
>
> J'ai une question BGP à vous soumettre :
>
> En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
> avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
> Sur chaque routeur BGP, nous avons au moins un transitaire.
>
> Tout fonctionne parfaitement !
>
> Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
> utilisant une route Null0) et un préfixe localisé sur le routeur 2
> (idem
> route Null0).
> Puis pour chaque IP /32 dans le prefixe, nous avons des routes
> statiques
> sur le routeur BGP concerné.
>
> - Ma question : Nous aimerions mettre en place un failover BGP
> automatique
> en cas de défaillance matérielle totale d'un des routeurs BGP.
>
> La solution que j'imaginais est de mettre en place, pour un même
> prefixe,
> une route Null0 sur les 2 routeurs en même temps.
>
> Sur les tests que j'ai fait, ça marche si on duplique la route Null0
> sur
> les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
> => Si un routeur BGP tombe, l'autre va normalement prendre le relais
> sans
> problème.
>
> Le seul cas qui pose problème, c'est si les 2 routeurs BGP
> fonctionnement
> mais que le L2L tombe.
>
> Dans ce cas, un paquet va continuer à arriver par le transit sur le
> routeur
> BGP concerné, puis la route statique correspondant à l'IP sera
> appliquée,
> mais l'IP de GW étant normalement accessible via le L2L sur un VLAN
> donné,
> le routage ne fonctionnera pas car le L2L est tombé.
>
> Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
> solution à
> ce problème ?
>
> Merci,
> Bonne journée,
> Fabien
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


>>>
>>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Montgomery SIMONPIETRI]

Tout a fait d'accord avec Raphael !
BGP / OSPF  ... c'est pas les proto qui manquent ;)

2015-11-03 16:30 GMT+01:00 Raphael Mazelier :

>
>
> Le 03/11/15 15:18, Fabien H a écrit :
>
>>
>> @Raphael
>>
>> Oui c'est ça, les /32 sont envoyés sur différents équipements : LNS, FW
>> puis par exemple sur le LNS, il y'a une interface avec un masque en /31
>>
>>
>>
>
> Dans ce cas le mieux c'est que tes équipements FW/LNS annoncent leurs
> préfixes aux deux routeurs via le protocole de ton choix (BGP est souvent
> un bon choix).
>
>
> --
> Raphael Mazelier
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

OK d'où les redistribute des routes connected vs routes statiques etc etc
.. C'est très clair maintenant merci !

Le 3 novembre 2015 17:26, Montgomery SIMONPIETRI  a écrit :

> Tout a fait d'accord avec Raphael !
> BGP / OSPF  ... c'est pas les proto qui manquent ;)
>
> 2015-11-03 16:30 GMT+01:00 Raphael Mazelier :
>
>>
>>
>> Le 03/11/15 15:18, Fabien H a écrit :
>>
>>>
>>> @Raphael
>>>
>>> Oui c'est ça, les /32 sont envoyés sur différents équipements : LNS, FW
>>> puis par exemple sur le LNS, il y'a une interface avec un masque en /31
>>>
>>>
>>>
>>
>> Dans ce cas le mieux c'est que tes équipements FW/LNS annoncent leurs
>> préfixes aux deux routeurs via le protocole de ton choix (BGP est souvent
>> un bon choix).
>>
>>
>> --
>> Raphael Mazelier
>>
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Montgomery SIMONPIETRI]

Hmmm l'autre option peut être encore plus simple serait simplement de
mettre un poids supérieur à BGP dans la route.


Sur R1 :

ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 250


Si la route BGP disparait (poids de 20 par défaut je crois) alors cest la
statique qui prendrait le relais...

2015-11-03 15:03 GMT+01:00 Montgomery SIMONPIETRI <
montgom...@simonpietri.net>:

> Exact ! Il faut inverser la condition ;)
>
> 2015-11-03 15:01 GMT+01:00 Fabien H :
>
>> Oui, c'est tout à fait ça !
>>
>> Peut-être juste inverser la condition c'est à dire installer la route
>> quand R2 n'est pas reachable plutot que quand il est reachable mais
>> apparemment c'est faisable :
>>
>> track 456 list boolean and
>>  object 123 not
>>
>> Ca commence à être tiré par les cheveux .. ! A voir
>>
>>
>> Le 3 novembre 2015 14:47, Montgomery SIMONPIETRI <
>> montgom...@simonpietri.net> a écrit :
>>
>>> Il faudra sans doute dupliquer les routes sur les deux routeurs, mais en
>>> ajoutant du tracking ip sla pour etre sur de les mettre dans la table
>>> uniquement en cas de failover.
>>>
>>> Sur R1 :
>>>
>>> ip sla 123
>>>  icmp-echo IP_LAN_R2 source-ip IP_LAN_R1
>>>  frequency 5
>>> ip sla schedule 123 life forever start-time now
>>>
>>> track 123 ip sla 123 reachability
>>>  delay down 25
>>>
>>> ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 track 123
>>>
>>>
>>> Et vice-versa sur R2.
>>> Est-ce que je suis à côté ?
>>>
>>> Montgomery
>>>
>>>
>>>
>>> 2015-11-03 14:28 GMT+01:00 Fabien H :
>>>
 Bonjour,

 merci, si j'ai bien compris, cette solution s'approche un peu du
 redistribute en EIGRP mais en BGP. C'est effectivement à tester.

 Mais je bloque toujours sur le besoin de failover Routeur BGP.

 Si R1 tombe, ses routes disparaissent de la table de R2, et du coup R2
 ne pourra pas assurer le failover de R1 pour les routes en /32...

 Le 3 novembre 2015 14:16, Montgomery SIMONPIETRI <
 montgom...@simonpietri.net> a écrit :

> Bonjour,
>
> Est-ce que vous avez pensé à mettre une solution avec du "redistribute
> static route-map" pour éviter d'annoncer les /32 et du prepend sur les
> prefix a backuper ?
>
>
>
> Du style :
>
> ip route 1.2.3.4 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R1 tag 999
> ip route 5.6.7.8 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R2 tag 999
>
> access-list 70 permit 5.6.7.8 0.0.0.255 #SUR R1
>
> access-list 70 permit 1.2.3.4 0.0.0.255 #SUR R2
>
> route-map BACKUP-PREPEND permit 10
>  match ip address 70
>  set as-path prepend 1234
>
> route-map BACKUP-PREPEND permit 20
>
> route-map TAGGED-STATIC permit 10
>  match tag 999
>
> router bgp 1234
>  redistribute static route-map TAGGED-STATIC
>  neighbor PEER_ADDRESS route-map BACKUP-PREPEND out
>
>
>
>
>
> 2015-11-02 9:16 GMT+01:00 Fabien H :
>
>> Bonjour la liste,
>>
>> J'ai une question BGP à vous soumettre :
>>
>> En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
>> avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
>> Sur chaque routeur BGP, nous avons au moins un transitaire.
>>
>> Tout fonctionne parfaitement !
>>
>> Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
>> utilisant une route Null0) et un préfixe localisé sur le routeur 2
>> (idem
>> route Null0).
>> Puis pour chaque IP /32 dans le prefixe, nous avons des routes
>> statiques
>> sur le routeur BGP concerné.
>>
>> - Ma question : Nous aimerions mettre en place un failover BGP
>> automatique
>> en cas de défaillance matérielle totale d'un des routeurs BGP.
>>
>> La solution que j'imaginais est de mettre en place, pour un même
>> prefixe,
>> une route Null0 sur les 2 routeurs en même temps.
>>
>> Sur les tests que j'ai fait, ça marche si on duplique la route Null0
>> sur
>> les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
>> => Si un routeur BGP tombe, l'autre va normalement prendre le relais
>> sans
>> problème.
>>
>> Le seul cas qui pose problème, c'est si les 2 routeurs BGP
>> fonctionnement
>> mais que le L2L tombe.
>>
>> Dans ce cas, un paquet va continuer à arriver par le transit sur le
>> routeur
>> BGP concerné, puis la route statique correspondant à l'IP sera
>> appliquée,
>> mais l'IP de GW étant normalement accessible via le L2L sur un VLAN
>> donné,
>> le routage ne fonctionnera pas car le L2L est tombé.
>>
>> Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
>> solution à
>> ce problème ?
>>
>> Merci,
>> Bonne journée,
>> Fabien
>>
>> ---
>> Liste de diffusion du FRnOG
>> 

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Raphael Mazelier]

Question : tes /32 correspondent a quoi ? des IPs de services sur des 
serveurs ?


Et sinon oui tu mes les /32 sur tes deux routeurs avec des poids différents.



Le 03/11/15 15:06, Montgomery SIMONPIETRI a écrit :

Hmmm l'autre option peut être encore plus simple serait simplement de
mettre un poids supérieur à BGP dans la route.


Sur R1 :

ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 250


Si la route BGP disparait (poids de 20 par défaut je crois) alors cest la
statique qui prendrait le relais...

2015-11-03 15:03 GMT+01:00 Montgomery SIMONPIETRI <
montgom...@simonpietri.net>:


Exact ! Il faut inverser la condition ;)

2015-11-03 15:01 GMT+01:00 Fabien H :


Oui, c'est tout à fait ça !

Peut-être juste inverser la condition c'est à dire installer la route
quand R2 n'est pas reachable plutot que quand il est reachable mais
apparemment c'est faisable :

track 456 list boolean and
  object 123 not

Ca commence à être tiré par les cheveux .. ! A voir


Le 3 novembre 2015 14:47, Montgomery SIMONPIETRI <
montgom...@simonpietri.net> a écrit :


Il faudra sans doute dupliquer les routes sur les deux routeurs, mais en
ajoutant du tracking ip sla pour etre sur de les mettre dans la table
uniquement en cas de failover.

Sur R1 :

ip sla 123
  icmp-echo IP_LAN_R2 source-ip IP_LAN_R1
  frequency 5
ip sla schedule 123 life forever start-time now

track 123 ip sla 123 reachability
  delay down 25

ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 track 123


Et vice-versa sur R2.
Est-ce que je suis à côté ?

Montgomery



2015-11-03 14:28 GMT+01:00 Fabien H :


Bonjour,

merci, si j'ai bien compris, cette solution s'approche un peu du
redistribute en EIGRP mais en BGP. C'est effectivement à tester.

Mais je bloque toujours sur le besoin de failover Routeur BGP.

Si R1 tombe, ses routes disparaissent de la table de R2, et du coup R2
ne pourra pas assurer le failover de R1 pour les routes en /32...

Le 3 novembre 2015 14:16, Montgomery SIMONPIETRI <
montgom...@simonpietri.net> a écrit :


Bonjour,

Est-ce que vous avez pensé à mettre une solution avec du "redistribute
static route-map" pour éviter d'annoncer les /32 et du prepend sur les
prefix a backuper ?



Du style :

ip route 1.2.3.4 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R1 tag 999
ip route 5.6.7.8 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R2 tag 999

access-list 70 permit 5.6.7.8 0.0.0.255 #SUR R1

access-list 70 permit 1.2.3.4 0.0.0.255 #SUR R2

route-map BACKUP-PREPEND permit 10
  match ip address 70
  set as-path prepend 1234

route-map BACKUP-PREPEND permit 20

route-map TAGGED-STATIC permit 10
  match tag 999

router bgp 1234
  redistribute static route-map TAGGED-STATIC
  neighbor PEER_ADDRESS route-map BACKUP-PREPEND out





2015-11-02 9:16 GMT+01:00 Fabien H :


Bonjour la liste,

J'ai une question BGP à vous soumettre :

En 2 mots : Nous sommes opérateur internet avec 2 localisations : Nous
avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
Sur chaque routeur BGP, nous avons au moins un transitaire.

Tout fonctionne parfaitement !

Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
utilisant une route Null0) et un préfixe localisé sur le routeur 2
(idem
route Null0).
Puis pour chaque IP /32 dans le prefixe, nous avons des routes
statiques
sur le routeur BGP concerné.

- Ma question : Nous aimerions mettre en place un failover BGP
automatique
en cas de défaillance matérielle totale d'un des routeurs BGP.

La solution que j'imaginais est de mettre en place, pour un même
prefixe,
une route Null0 sur les 2 routeurs en même temps.

Sur les tests que j'ai fait, ça marche si on duplique la route Null0
sur
les 2 routeurs et si on duplique aussi les routes statiques des IP/32.
=> Si un routeur BGP tombe, l'autre va normalement prendre le relais
sans
problème.

Le seul cas qui pose problème, c'est si les 2 routeurs BGP
fonctionnement
mais que le L2L tombe.

Dans ce cas, un paquet va continuer à arriver par le transit sur le
routeur
BGP concerné, puis la route statique correspondant à l'IP sera
appliquée,
mais l'IP de GW étant normalement accessible via le L2L sur un VLAN
donné,
le routage ne fonctionnera pas car le L2L est tombé.

Ca avait l'air d'être pourtant la bonne méthode .. Avez-vous une
solution à
ce problème ?

Merci,
Bonne journée,
Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/














---
Liste de diffusion du FRnOG
http://www.frnog.org/




---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Fabien H]

@Montgomery

Oui, c'est beaucoup plus propre et c'est compatible avec le redistribute,
merci !

@Raphael

Oui c'est ça, les /32 sont envoyés sur différents équipements : LNS, FW
puis par exemple sur le LNS, il y'a une interface avec un masque en /31



Le 3 novembre 2015 15:09, Raphael Mazelier  a écrit :

> Question : tes /32 correspondent a quoi ? des IPs de services sur des
> serveurs ?
>
> Et sinon oui tu mes les /32 sur tes deux routeurs avec des poids
> différents.
>
>
>
> Le 03/11/15 15:06, Montgomery SIMONPIETRI a écrit :
>
> Hmmm l'autre option peut être encore plus simple serait simplement de
>> mettre un poids supérieur à BGP dans la route.
>>
>>
>> Sur R1 :
>>
>> ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 250
>>
>>
>> Si la route BGP disparait (poids de 20 par défaut je crois) alors cest la
>> statique qui prendrait le relais...
>>
>> 2015-11-03 15:03 GMT+01:00 Montgomery SIMONPIETRI <
>> montgom...@simonpietri.net>:
>>
>> Exact ! Il faut inverser la condition ;)
>>>
>>> 2015-11-03 15:01 GMT+01:00 Fabien H :
>>>
>>> Oui, c'est tout à fait ça !

 Peut-être juste inverser la condition c'est à dire installer la route
 quand R2 n'est pas reachable plutot que quand il est reachable mais
 apparemment c'est faisable :

 track 456 list boolean and
   object 123 not

 Ca commence à être tiré par les cheveux .. ! A voir


 Le 3 novembre 2015 14:47, Montgomery SIMONPIETRI <
 montgom...@simonpietri.net> a écrit :

 Il faudra sans doute dupliquer les routes sur les deux routeurs, mais en
> ajoutant du tracking ip sla pour etre sur de les mettre dans la table
> uniquement en cas de failover.
>
> Sur R1 :
>
> ip sla 123
>   icmp-echo IP_LAN_R2 source-ip IP_LAN_R1
>   frequency 5
> ip sla schedule 123 life forever start-time now
>
> track 123 ip sla 123 reachability
>   delay down 25
>
> ip route 5.6.7.1 255.255.255.555 4.4.4.4 name ROUTE_32_R2 track 123
>
>
> Et vice-versa sur R2.
> Est-ce que je suis à côté ?
>
> Montgomery
>
>
>
> 2015-11-03 14:28 GMT+01:00 Fabien H :
>
> Bonjour,
>>
>> merci, si j'ai bien compris, cette solution s'approche un peu du
>> redistribute en EIGRP mais en BGP. C'est effectivement à tester.
>>
>> Mais je bloque toujours sur le besoin de failover Routeur BGP.
>>
>> Si R1 tombe, ses routes disparaissent de la table de R2, et du coup R2
>> ne pourra pas assurer le failover de R1 pour les routes en /32...
>>
>> Le 3 novembre 2015 14:16, Montgomery SIMONPIETRI <
>> montgom...@simonpietri.net> a écrit :
>>
>> Bonjour,
>>>
>>> Est-ce que vous avez pensé à mettre une solution avec du
>>> "redistribute
>>> static route-map" pour éviter d'annoncer les /32 et du prepend sur
>>> les
>>> prefix a backuper ?
>>>
>>>
>>>
>>> Du style :
>>>
>>> ip route 1.2.3.4 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R1 tag 999
>>> ip route 5.6.7.8 255.255.255.0 4.4.4.4 name ROUTE_PRIM_R2 tag 999
>>>
>>> access-list 70 permit 5.6.7.8 0.0.0.255 #SUR R1
>>>
>>> access-list 70 permit 1.2.3.4 0.0.0.255 #SUR R2
>>>
>>> route-map BACKUP-PREPEND permit 10
>>>   match ip address 70
>>>   set as-path prepend 1234
>>>
>>> route-map BACKUP-PREPEND permit 20
>>>
>>> route-map TAGGED-STATIC permit 10
>>>   match tag 999
>>>
>>> router bgp 1234
>>>   redistribute static route-map TAGGED-STATIC
>>>   neighbor PEER_ADDRESS route-map BACKUP-PREPEND out
>>>
>>>
>>>
>>>
>>>
>>> 2015-11-02 9:16 GMT+01:00 Fabien H :
>>>
>>> Bonjour la liste,

 J'ai une question BGP à vous soumettre :

 En 2 mots : Nous sommes opérateur internet avec 2 localisations :
 Nous
 avons 2 routeurs BGP de bordure reliés en IBGP via un L2L.
 Sur chaque routeur BGP, nous avons au moins un transitaire.

 Tout fonctionne parfaitement !

 Actuellement, nous avons un prefixe "localisé" sur le routeur 1 (en
 utilisant une route Null0) et un préfixe localisé sur le routeur 2
 (idem
 route Null0).
 Puis pour chaque IP /32 dans le prefixe, nous avons des routes
 statiques
 sur le routeur BGP concerné.

 - Ma question : Nous aimerions mettre en place un failover BGP
 automatique
 en cas de défaillance matérielle totale d'un des routeurs BGP.

 La solution que j'imaginais est de mettre en place, pour un même
 prefixe,
 une route Null0 sur les 2 routeurs en même temps.

 Sur les tests que j'ai fait, ça marche si on duplique la route Null0
 sur
 les 2 routeurs et si on duplique 

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[David Ramahefason]

Il vaut mieux que  tes équipmentsLNS and Co i annoncent dynamiquement leurs
IP/prefix plutot que de redist des connected du routeur, car tu ne resouds
pas ton probleme d'annonce si un service tombe sur ton LAN

Le mar. 3 nov. 2015 à 17:31, Fabien H  a écrit :

> OK d'où les redistribute des routes connected vs routes statiques etc etc
> .. C'est très clair maintenant merci !
>
> Le 3 novembre 2015 17:26, Montgomery SIMONPIETRI <
> montgom...@simonpietri.net
> > a écrit :
>
> > Tout a fait d'accord avec Raphael !
> > BGP / OSPF  ... c'est pas les proto qui manquent ;)
> >
> > 2015-11-03 16:30 GMT+01:00 Raphael Mazelier :
> >
> >>
> >>
> >> Le 03/11/15 15:18, Fabien H a écrit :
> >>
> >>>
> >>> @Raphael
> >>>
> >>> Oui c'est ça, les /32 sont envoyés sur différents équipements : LNS, FW
> >>> puis par exemple sur le LNS, il y'a une interface avec un masque en /31
> >>>
> >>>
> >>>
> >>
> >> Dans ce cas le mieux c'est que tes équipements FW/LNS annoncent leurs
> >> préfixes aux deux routeurs via le protocole de ton choix (BGP est
> souvent
> >> un bon choix).
> >>
> >>
> >> --
> >> Raphael Mazelier
> >>
> >>
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >>
> >
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[David Ponzone]

Si tu optes pour iBGP, oublie pas de bien monter tes sessions de tous tes 
LNS/FW/… vers tes 2 routeurs!


> Le 3 nov. 2015 à 17:30, Fabien H  a écrit :
> 
> OK d'où les redistribute des routes connected vs routes statiques etc etc
> .. C'est très clair maintenant merci !
> 
> Le 3 novembre 2015 17:26, Montgomery SIMONPIETRI > a écrit :
> 
>> Tout a fait d'accord avec Raphael !
>> BGP / OSPF  ... c'est pas les proto qui manquent ;)
>> 
>> 2015-11-03 16:30 GMT+01:00 Raphael Mazelier :
>> 
>>> 
>>> 
>>> Le 03/11/15 15:18, Fabien H a écrit :
>>> 
 
 @Raphael
 
 Oui c'est ça, les /32 sont envoyés sur différents équipements : LNS, FW
 puis par exemple sur le LNS, il y'a une interface avec un masque en /31
 
 
 
>>> 
>>> Dans ce cas le mieux c'est que tes équipements FW/LNS annoncent leurs
>>> préfixes aux deux routeurs via le protocole de ton choix (BGP est souvent
>>> un bon choix).
>>> 
>>> 
>>> --
>>> Raphael Mazelier
>>> 
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>> 
>> 
>> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP

[Raphael Mazelier]

Le 03/11/15 17:35, David Ponzone a écrit :

Si tu optes pour iBGP, oublie pas de bien monter tes sessions de tous tes 
LNS/FW/… vers tes 2 routeurs!



Oui ça va mieux en le disant :)

--
Raphael Mazelier


---
Liste de diffusion du FRnOG
http://www.frnog.org/