ASR9K - 4.2.3 to 4.3.4 Upgrade - VRRP Issue

Question

Hello all,
After upgrading 4.2.3 to 4.3.4, when checking the failing config, I found the following issue regarding VRRP:
RP/0/RSP0/CPU0:A9K-LAB02#sh configuration failed startup
Mon May  5 16:24:19.094 WEST
!!15:13:09 UTC Mon May 05 2014
!! SEMANTIC ERRORS: This configuration was rejected by
!! the system due to semantic errors. The individual
!! errors with each failed configuration command can be
!! found below.
router vrrp
interface TenGigE0/0/0/0.3701
  address-family ipv4
   vrrp 1
    priority 200
!!% 'vrrp' detected the 'warning' condition 'Virtual MAC already in use on this port'
    timer 1
!!% 'vrrp' detected the 'warning' condition 'Virtual MAC already in use on this port'
    address 200.100.1.100
!!% 'vrrp' detected the 'warning' condition 'Virtual MAC already in use on this port'
End
According to bug CSCed75140, I expect this issue to be solved starting in 4.3.0...
Any idea?
Thx,
Pedro

Answer 1

Pedro,
There must be a missunderstand the bug you quote is to improve the error notification with this unsupported config, it doesn't make the config supported. Some details on this issue from the Release notes of the bug:
<B>Problem Symptom:</B>
In a router running IOS-XR, configuring the same virtual router id(VRID) on
multiple sub-interfaces of the same physical interfaces is <B>NOT</B> supported
for HSRP/ VRRP
<B>Workaround:</B>
Use different virtual router id for the different sub-interfaces of same
physical interface
<B>Further Problem Description:</B>
Example of unsupported config:
<B>
router vrrp
interface GigabitEthernet0/5/0/38.175
vrrp 1 ipv4 10.186.0.1
interface GigabitEthernet0/5/0/38.176
vrrp 1 ipv4 10.186.0.9
</B>
If you have two groups configured with the same virtual router id, this means
that they have the same virtual MAC address (as this is derived from the
virtual router ID). When VRRP is in Master state, it installs an entry for
it's virtual MAC in to the MAC filter for the interface over which it is
running. However, it is not possible to program the MAC filter per
sub-interface. Therefore if VRRP is running over a sub-interface it is the MAC
filter of the underlying physical interface which is actually programmed
(although VRRP has no way of being aware of this). If using the unsupported
configuration, you have two Master groups with the same virtual MAC address on
sub-interfaces of the same physical interface. In this case there will only be
one MAC address installed in the filter of the physical interface. When one of
these groups is removed by configuration or it transitions out of Master
state, it removes its virtual MAC address from the MAC filter of the
underlying physical interface meaning there is now no MAC address installed at
all and the VRRP feature for the remaining Master group will no longer
work. The root cause of the problem is that the MAC filter cannot be
programmed per sub-interface.