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 <sejo...@gmail.com> 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 > <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 > > <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 > > <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 <david.ponz...@gmail.com > <mailto:david.ponz...@gmail.com>> 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/ <http://www.frnog.org/> > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
