ASR9K - 4.2.3 to 4.3.4 Upgrade - VRRP Issue

[Pedro Morais]

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

[Eddie Chami]

Works for me? There is a VRRP bug, make sure that SMU or Service Pack2 for 4.3.4 is installed.

RP/0/RSP0/CPU0:ASR9K-PE1-R0#sh run  interface TenGigE0/0/0/0.3701
Thu May  8 00:39:44.352 UTC
interface TenGigE0/0/0/0.3701
 ipv4 address 200.100.1.1 255.255.255.0
 encapsulation dot1q 10
!

RP/0/RSP0/CPU0:ASR9K-PE1-R0#sh inst ac sum
Thu May  8 00:39:46.994 UTC
Default Profile:
  SDRs:
    Owner
  Active Packages:
    disk0:asr9k-mini-px-4.3.4
    disk0:asr9k-mgbl-px-4.3.4
    disk0:asr9k-mcast-px-4.3.4
    disk0:asr9k-fpd-px-4.3.4
    disk0:asr9k-mpls-px-4.3.4
    disk0:asr9k-px-4.3.4.sp2

RP/0/RSP0/CPU0:ASR9K-PE1-R0#
RP/0/RSP0/CPU0:ASR9K-PE1-R0#sh run router vrrp
Thu May  8 00:39:59.791 UTC
router vrrp
 interface TenGigE0/0/0/0.3701
  address-family ipv4
   vrrp 1
    priority 200
    timer 1
    address 200.100.1.100
   !
  !
 !
!

RP/0/RSP0/CPU0:ASR9K-PE1-R0#

[Pedro Morais]

Hi Eddie,

Sorry but I was not clear in my first post.

The idea is to have the same VRRP ID in different sub-interfaces in the same physical interface. According to CSCed75140 this should be supported starting in 4.3.0. However after upgrading to 4.3.4 the router returns the "Semantic Errors" I posted previously. The idea is to have the following config:

router vrrp
 interface TenGigE0/0/0/0.3700
  address-family ipv4
   vrrp 1
    priority 200
    timer 1
    address 200.100.1.100
 interface TenGigE0/0/0/0.3701
  address-family ipv4
   vrrp 1
    priority 200
    timer 1
    address 200.100.1.100

Is this a supported config in 4.3.4?

Thanks.

Regards,

Pedro

[Eddie Chami · Accepted solution]

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.

[Pedro Morais]

OK! So this is not a supported config? The information I got from TAC (back in 2012) is that this feature would be introduced in 4.3.0 (via CSCed75140 enhancement).

Thanks!

[Eddie Chami]

Yea sorry about that, it's not supported, the TAC engineer must have miss understood the changes. You need to keep your VRRP group unique on the same physical interface.

Shouldn't be too much of a problem..

Regards

Eddie.
 

[Pedro Morais]

Thx for the clarification Eddie!

The only problem we have is that the client will soon run out of VRRP IDs in the box, and they was expecting this feature to be introduced in 4.3.4 (it was one of the drivers to upgrade). 

Any idea if this feature will be available in a near future?

Thanks!

[Eddie Chami]

Perdo,

Thats all that is supported in this generation of LCs. Maybe they should consider during BVI and secondary addresses?

Regards

Eddie.

[Pedro Morais]

I'll check that.

Thanks for all your help Eddie!

Regards