VRRP - separate VRIDs or single?

[EtherNation_Use]

Create Date: Feb 21 2013 9:35PM

Hi, I'm trying to optimize the implementation of VRRP on a pair of 480s at our network's core, and I'm wondering if the way it's set up now is optimal or not. Here's the current anonymized config (the switch has appropriate real IPs on each network):

create vrrp vlan client-net vrid 1
configure vrrp vlan client-net vrid 1 priority 90
configure vrrp vlan client-net vrid 1 authentication simplepassword pass1
create vrrp vlan client-net-2 vrid 20
configure vrrp vlan client-net-2 vrid 20 priority 90
configure vrrp vlan client-net-2 vrid 20 authentication simplepassword pass2
create vrrp vlan client-net-3 vrid 10
configure vrrp vlan client-net-3 vrid 10 priority 90
configure vrrp vlan client-net-3 vrid 10 authentication simplepassword pass3
configure vrrp vlan client-net vrid 1 add 192.168.1.1
configure vrrp vlan client-net-2 vrid 20 add 172.16.2.1
configure vrrp vlan client-net-3 vrid 10 add 10.200.150.1
enable vrrp vlan client-net vrid 1
enable vrrp vlan client-net-2 vrid 20
enable vrrp vlan client-net-3 vrid 10

What is best practice here? Should I roll all of the VRRP instances up into a single VRID, or keep them separate? These are networks we need to be resilient to failures and attacks - the separation of the VRIDs was intended to separate them so if one was knocked offline by a traffic storm or other problem the others would stay online, but I'm not sure that's a valid assumption. Any insight is appreciated. Thanks!

(from Ansley_Barnes)

[Ashish_Sahu]

Error: Max number of virtual MACs reached, cannot use vrid 4 to create another
Configuration failed on backup MSM, command execution aborted!

[EtherNation_Use]

Create Date: Mar 1 2013 10:05PM

Hello mrguga

There is a list of VRRP guidelines in the concepts guide on page 1103 for the 15_2 version. Please see below. I have highlighted the two that are based on this discussion. In the first you can reuse the same number on the same router as many times as you want up to 128 interfaces (VLANs using VRRP) the part that says not on the same IP interface is when using Secondary IP addresses. The main IP needs to be on one number like VRID1 and the other addresses need to be use a second number VRID2

VRRP Guidelines
The following guidelines apply to using VRRP:
● VRRP packets are encapsulated IP packets.
● The VRRP IPv4 multicast address is 224.0.0.18.
● The VRRP IPv6 multicast address is ff02::12.
● Duplicate VRIDs are allowed on the router but not on the same IP interface or VLAN.
● The maximum number of supported VRIDs per interface is seven.
● An interconnect link between VRRP routers should not be used, except when VRRP routers have
hosts directly attached.
● A maximum of 128 VRID instances are supported on the router.
● Up to seven unique VRIDs can be configured on the router. VRIDs can be re-used, but not on the
same interface.
● VRRP and the Spanning Tree Protocol (STP) can be simultaneously enabled on the same switch.
● When VRRP and BOOTP/DHCP relay are both enabled on the switch, the relayed BOOTP agent IP
address is the actual switch IP address, not the virtual IP address.
● Extreme Networks does not recommend simultaneously enabling VRRP and ESRP on the same
switch.
● Do not configure VRRP and ESRP on the same VLAN or port. This configuration is not allowed or
supported.

Hope this helps.

P (from Paul_Russo)

[EtherNation_Use]

Create Date: Mar 1 2013 9:50PM

Well, i just ran into this post after failing to create the 8th vrid on my BD8806:Error: Max number of virtual MACs reached, cannot use vrid 8 to create anotherSo it seems that using only one vrid for each virtual router pair is mandatory...This information should be added to the EXOS Concepts Manual, since I did'nt find anything there about vrid instances limit.Thanks. (from Luis_Coelho)

[EtherNation_Use]

Create Date: Feb 27 2013 8:30PM

I think I got your meaning, prusso. The advice is appreciated. I'll put it on my list to consolidate these routers into a single VRID for simplicity's sake and evaluate if tracking is necessary to prompt individual failovers. In this particular instance it probably won't be necessary, but I'll see. Thanks again for the help. (from Ansley_Barnes)