RE: [FRnOG] [TECH] VRRP et priorité 0

2018-06-07 Par sujet Michel Py 
> David Ponzone a écrit :
> Pour mon ping inter-Cisco, c’était un petit PBR bien pourri qui avait 
> besoin d’un petit deny plus spécifique, je ne m’enfoncerais pas plus.

David, au piquet.

J'ai eu un coup comme çà avec HSRP il y a pas longtemps, pourtant je 
connaissais le truc mais j'avais l'esprit ailleurs.
Les deux routeurs HSRP sont tous les deux "active". Pourquoi ?

Je corrige les copies demain trolldi :-)

Michel.


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

Re: [FRnOG] [TECH] VRRP et priorité 0

2018-06-07 Par sujet David Ponzone 
Ah bien vu.
Je m’auto-déclare Gros Con d’avoir pris un cas particulier pareil en faisant la 
configuration.

Clairement, ça semble aller mieux avec une prio de 254 (54 après le decrement).
Pour mon ping inter-Cisco, c’était un petit PBR bien pourri qui avait besoin 
d’un petit deny plus spécifique, je ne m’enfoncerais pas plus.

Merci à tous :)




> Le 7 juin 2018 à 15:39, Servan Jouan  a écrit :
> 
> Bonjour,
> 
> En creusant un peu dans les docs et le forum, j'ai cru comprendre que le 
> "priority 0" permet de désactiver le VRRP sur des membres du groupe (ce qui 
> explique l'absence de réponse au ping).
> Très certainement utilisé pour les périodes de maintenances.
> 
> Extrait du forum :
> "The priority value zero (0) has special meaning indicating that the current 
> Master has stopped participating in VRRP.  This is used to trigger Backup 
> routers to quickly transition to Master without having to wait for the 
> current Master to timeout."
> 
> 
> Concernant l'usage, je ne peux rien promettre, ça vient du forum 
> (https://learningnetwork.cisco.com/thread/56855 
> ) ... Mais je retrouve cette 
> même notion de "désactivation" du VRRP dans les docs Juniper, et toujours 
> pour une priorité de zéro.
> 
> Juniper 
> (https://www.juniper.net/documentation/en_US/junos/topics/topic-map/configuring-virtual-router-redundancy-protocol-vrrp-tm.html
>  
> )
>  :
> "Prior to Junos OS Release 15.1, an adjusted priority could not be zero. If 
> the difference between the priority costs and the configured priority of the 
> VRRP group was zero, the adjusted priority would become 1.
> 
>   
> Note: In Junos OS Release 15.1 and later, an adjusted priority can be zero.
> 
> The priority value zero (0) indicates that the current master router has 
> stopped participating in VRRP. Such a priority value is used to trigger one 
> of the backup routers to quickly transition to the master router without 
> having to wait for the current master to time out."
> 
> 
> 
> En tout cas, Cisco a bien imaginé des cas où la priorité tombe à 0 :
> https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-0/addr_serv/configuration/guide/ic40asr9kbook_chapter10.html
>  
> 
> 
> RP/0/RSP0/CPU0:router# show vrrp statistics
> show vrrp statistics
> Invalid packets:
>  Invalid checksum:  0
>  Unknown/unsupported versions:  0
>  Invalid vrID:  10
>  Too short: 0
> Protocol:
>  Transitions to Master  6
> Packets:
>  Total received:155
>  Bad TTL:   0
>  Failed authentication: 0
>  Unknown authentication:0
>  Conflicting authentication:0
>  Unknown Type field:0
>  Conflicting Advertise time:0
>  Conflicting Addresses: 0
>  Received with zero priority:   3
>  Sent with zero priority:   3
> Cordialement,
> Servan.
> 
> Le 7 juin 2018 à 12:02, David Ponzone  > a écrit :
> Je me pose une petite question sur un cas, pas documenté chez Cisco.
> 
> Sur une interface VRRP, on peut définir une priorité entre 1 et 254 (doc 
> Cisco).
> Que se passe-t-il si on a défini une priorité 200, et qu’on track un IP SLA 
> (ping vers la gateway WAN) avec réduction de la priorité de 200 si le IP SLA 
> est down ?
> La nouvelle priorité étant 0, ça peut être un cas de figure non prévu par 
> Cisco avec un effet de bord bizarre, ou alors le Cisco s’en fout tant que la 
> nouvelle priorité est inférieure à la priorité sur l’autre Cisco (100 par 
> défaut)….
> Ce qui est étrange c’est que slave devient master, mais impossible de pinger 
> le nouveau slave depuis le nouveau master.
> 
> Vous avez 4h :)
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ 
> 


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

Re: [FRnOG] [TECH] VRRP et priorité 0

2018-06-07 Par sujet Servan Jouan 
Bonjour,

En creusant un peu dans les docs et le forum, j'ai cru comprendre que le
"priority 0" permet de désactiver le VRRP sur des membres du groupe (ce qui
explique l'absence de réponse au ping).
Très certainement utilisé pour les périodes de maintenances.

Extrait du forum :
"The priority value zero (0) has special meaning indicating that the
current Master has stopped participating in VRRP.  This is used to trigger
Backup routers to quickly transition to Master without having to wait for
the current Master to timeout."


Concernant l'usage, je ne peux rien promettre, ça vient du forum (
https://learningnetwork.cisco.com/thread/56855) ... Mais je retrouve cette
même notion de "désactivation" du VRRP dans les docs Juniper, et toujours
pour une priorité de zéro.

Juniper (
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/configuring-virtual-router-redundancy-protocol-vrrp-tm.html)
:

"Prior to Junos OS Release 15.1, an adjusted priority could not be zero. If
the difference between the priority costs and the configured priority of
the VRRP group was zero, the adjusted priority would become 1.

*Note: *In Junos OS Release 15.1 and later, an adjusted priority can be
zero.

The priority value zero (0) indicates that the current master router has
stopped participating in VRRP. Such a priority value is used to trigger one
of the backup routers to quickly transition to the master router without
having to wait for the current master to time out."


En tout cas, Cisco a bien imaginé des cas où la priorité tombe à 0 :
https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-0/addr_serv/configuration/guide/ic40asr9kbook_chapter10.html

RP/0/RSP0/CPU0:router# *show vrrp statistics*
show vrrp statistics
Invalid packets:
 Invalid checksum:  0
 Unknown/unsupported versions:  0
 Invalid vrID:  10
 Too short: 0
Protocol:
 Transitions to Master  6
Packets:
 Total received:155
 Bad TTL:   0
 Failed authentication: 0
 Unknown authentication:0
 Conflicting authentication:0
 Unknown Type field:0
 Conflicting Advertise time:0
 Conflicting Addresses: 0* Received with zero priority:   3
 Sent with zero priority:   3*

Cordialement,
Servan.

Le 7 juin 2018 à 12:02, David Ponzone  a écrit :

> Je me pose une petite question sur un cas, pas documenté chez Cisco.
>
> Sur une interface VRRP, on peut définir une priorité entre 1 et 254 (doc
> Cisco).
> Que se passe-t-il si on a défini une priorité 200, et qu’on track un IP
> SLA (ping vers la gateway WAN) avec réduction de la priorité de 200 si le
> IP SLA est down ?
> La nouvelle priorité étant 0, ça peut être un cas de figure non prévu par
> Cisco avec un effet de bord bizarre, ou alors le Cisco s’en fout tant que
> la nouvelle priorité est inférieure à la priorité sur l’autre Cisco (100
> par défaut)….
> Ce qui est étrange c’est que slave devient master, mais impossible de
> pinger le nouveau slave depuis le nouveau master.
>
> Vous avez 4h :)
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

RE: [FRnOG] [TECH] VRRP et priorité 0

2018-06-07 Par sujet VAHE Thomas 
Bonjour,

On est pas vendredi ! 

Cdt,

T.V.


-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
David Ponzone
Envoyé : jeudi 7 juin 2018 12:03
À : frnog-tech 
Objet : [FRnOG] [TECH] VRRP et priorité 0

Je me pose une petite question sur un cas, pas documenté chez Cisco.

Sur une interface VRRP, on peut définir une priorité entre 1 et 254 (doc Cisco).
Que se passe-t-il si on a défini une priorité 200, et qu’on track un IP SLA 
(ping vers la gateway WAN) avec réduction de la priorité de 200 si le IP SLA 
est down ?
La nouvelle priorité étant 0, ça peut être un cas de figure non prévu par Cisco 
avec un effet de bord bizarre, ou alors le Cisco s’en fout tant que la nouvelle 
priorité est inférieure à la priorité sur l’autre Cisco (100 par défaut)….
Ce qui est étrange c’est que slave devient master, mais impossible de pinger le 
nouveau slave depuis le nouveau master.

Vous avez 4h :)


---
Liste de diffusion du FRnOG
http://www.frnog.org/
__
Ce message contient des informations dont le contenu est susceptible d' etre 
confidentiel. Il est destine au(x) destinataire(s) indique(s) exclusivement.
A moins que vous ne fassiez partie de la liste des destinataires, ou que vous 
soyez habilite a recevoir le mail a leur place, il vous est interdit de le 
copier, de l'utiliser ou de devoiler son contenu a un tiers.
Si vous avez recu cet email par erreur, merci de prendre contact avec 
l'emetteur.
Les opinions exprimees dans cet e-mail sont celles de l'emetteur et ne 
refletent pas necessairement celles de l'entreprise.
Ce e-mail peut contenir des pieces jointes dont certaines pourraient contenir 
des virus qui pourraient endommager votre systeme informatique.
La compagnie a pris toutes dispositions afin de minimiser ce risque et decline 
toute responsabilite pour toute perte ou dommage resultant directement ou 
indirectement de l'utilisation de cet email ou de son contenu.
Il vous appartient d'effectuer vos propres controles anti-virus avant d'ouvrir 
la ou les pieces jointes.
__

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

Re: [FRnOG] [TECH] VRRP et priorité 0

2018-06-07 Par sujet Paul Rolland (ポール・ロラン) 
Bonjour,

On Thu, 7 Jun 2018 12:02:42 +0200
David Ponzone  wrote:

> Je me pose une petite question sur un cas, pas documenté chez Cisco.
> 
> Sur une interface VRRP, on peut définir une priorité entre 1 et 254 (doc
> Cisco). Que se passe-t-il si on a défini une priorité 200, et qu’on track
> un IP SLA (ping vers la gateway WAN) avec réduction de la priorité de 200
> si le IP SLA est down ? La nouvelle priorité étant 0, ça peut être un cas
> de figure non prévu par Cisco avec un effet de bord bizarre, ou alors le
> Cisco s’en fout tant que la nouvelle priorité est inférieure à la
> priorité sur l’autre Cisco (100 par défaut)…. Ce qui est étrange c’est
> que slave devient master, mais impossible de pinger le nouveau slave
> depuis le nouveau master.

Est-ce que si tu pars de 201, retires 200 pour arriver a 1, ton
comportement est celui attendu ?

Parce que les bascules VRRP qui marchent pas tres bien, ca arrive avec les
propagation des MAC qui ne se font pas toujours comme on le pense...

Paul


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