I work for French ISP . I worked on the VRRPv 3 protocol more precisely on the dscp fields of this protocol. (I use an ipv4 address plan)
I noticed that the dscp field in VRRP v2 is CS6 which is normal. My question is the following. Why in VRRP v3 the DSCP field is CS0?
I know that version 3 was made for the arrival of ipv6. vrrp V3 can be V2 compatible (announcement in v2 and announcement in V3 to the backup router)
Even when using V2 compatibility, the dscp Field remains at CS0.
The problem that the following, in case of congestion of the client LAN, it is possible that the VRRP announcements is dropped because they are marked in CS0.
what is the best method? should we go back to VRRP V2? rather use HSRP? mark vrrp packets ??
thank you for your help..!!
Nobody to answer my questions? I think it’s a bug. I have tried different routers with different iOS versions and I always notice the same problem. In vrrpv3 with ipv4 the dscp field is cs0. it should be cs6. I've tried this protocol with another manufacturer and I do not see this problem. I would like to have the answer of a cisco expert on this subject. Thanks in advance for your answer
after the lab testing.
this is clear for me There is a "BUG" Cisco has to work on the subject.
when you work with fhrp version vrrp v3 and
with the interface vlan or the physical interface configured with
this command applied " vrrp 91 address-family ipv4"
the dscp value of the vrrp packet is not CS6 but "strangly" CS0 .
when the traffic is very high and the qos is working .
the vrrp packets are dropped and the backup router becom the master .
we are faced off two master vrrp router on the network . (This is split-brain scenario)
I find for that a workround. you have to match multicast vrrp ip and set the correct value of the dscp .
on others company like HPE or Extreme Networks or huawei.
natively the dscp filed is cs6 or on CS7 the maximum priority of traffic
if you need more details you can contact: me email@example.com
i think all ios router version are concerned
i checked on cisco bug tool but nothing talk about this problem.