12-19-2013 07:52 AM
I'm writing to ask for some VRRP recommendations. I'm looking to setup 3 pairs of controllers with VRRP redundancy.
An active-backup pair of 7210 masters
An active-active pair of 7240 locals
A 2nd pair active-active 7240 locals
My first question regards the "authentication" parameter in the VRRP configuration; the other questions will manifest themselves at some point.
The 6.2 CLI specifies :
"Configureanoptionalpasswordofupto8characterstobeusedtoauthenticationVRRPpeersintheiradvertisements. Thepasswordmustbethesameonbothmembersoftheredundantpair. Thepasswordissentinplain-textandthereforeshouldnotbetreatedasasecuritymeasure. Rather, thepurposeofthepasswordistoguardagainstmisconfigurationsintheeventthatotherVRRPdevicesexistonthesamenetwork."
So, doIneedtobewaryofmy5VRRPinstancessuchthatIshouldspecifydistinctpasswordsforeachVRRPinstanceinordertoavoidmisconfigurations? ShouldItakethisintoconsiderationsinceallofmyVRRPswillliveonthesameVLAN?
I imagine these misconfiguration, the docs mention, would occur if I (or someone else) mistakenly configures the same vrrp ID in a set of these configs that wasn't meant to be there. Additionally, one would have to also mistakenly issue the same peer-ip-address in the master-redundancy config?
Ah, and does the above only apply for master redundancy? The 6.2 User Guide only specifies issuing the following for local redundancy.
(host) (config) #vvrrp <id>
ip address <ipaddr>
I'm assuming that the "vvrrp" command is a typo. I'm also going to assume that the ip address is actually going to be my local VIP.
This means that for my active-active local controller redundancy, each controller will have 2 VRRP IDs.
ip address LOC_A_VIP
ip address LOC_B_VIP
And its cousin would have the config :
ip address LOC_B_VIP
ip address LOC_A_VIP
Is this all making sense? Am I on the right track?
Ah, found this KB Article : https://arubanetworkskb.secure.force.com/pkb/artic
So, I guess my only question then regards the authentication password? The KB Article doesn't specify if the passwords in the active-active config need to be distinct, nor does it go into additional configs, so my question still is should I specify distinct passwords for each VRRP instance in order to avoid misconfigurations?
12-19-2013 09:04 AM
You're pretty much right with all of that.
In terms of the passwords, they're not passwords in a true sense no. The point of it as you suspect if to prevent mal-operation, should another network guy mistakenly use the same VRRP ID (on another device) on the same VLAN.
I have a bit of a personal issue with the concept of this. Just in terms of, if somebody did do that, they should not be setting up VRRPs in the first place without undertaking due-diligence!
01-08-2014 07:42 AM - edited 01-08-2014 07:47 AM
So, the recommendation from my SE was to also use some simple passwd authentication, which I've done. Our VRRP looks good & was given the greenlight.
I was able to apply the config but for whatever reason, both of the controllers think of themselves as the master.
VRRP Advertisements aren't being seen on the backup.
I've gone through the configs w/ my SE, opened a ticket w/ TAC & have performed some basic troubleshooting w/ TAC regarding the VRRP config. We were able to establish a temporary VRRP on another VLAN (non-management, for guest wifi client access) for testing purposes, however the VRRP fails to come up properly on what is our native management VLAN (as specified on the controllers).
We're looking at the uplink port & VLAN configs to try and observe any obvious differences in their configs. My network engineer tells me they're exactly the same, however the VLANs we've tested are configured on 2 separate routers. The only thing I know about the Cisco that has our management VLAN is that it is configured in a VSS; not sure if that would have anything to do w/ it.
I have read through some of the conversations on a
Does anyone have any recommendations on the switch end, regarding configs to avoid or use regarding VRRP? These controllers are connected to a pair of Cisco 6509's (which act as one in VSS) in two separate locations.
I was using a port-channel as an uplink on one of the controllers, however I've sinced backed that out, since TAC recommended it for troubleshooting purposes.
Any ideas on where to begin?
Has anyone experienced this sort of thing?