Wireless Access

last person joined: an hour ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

VRRP Config Recommendations

This thread has been viewed 3 times
  • 1.  VRRP Config Recommendations

    Posted Dec 19, 2013 10:53 AM

    Hello,

     

    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>
    vlan <vlan>
    no shutdown

     

    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.

     

    vrrp 20
    vlan MGMT_VLAN
    ip address LOC_A_VIP
    priority 110
    preempt
    description Preferred-Local-A1
    no shutdown
    !
    vrrp 25
    vlan MGMT_VLAN
    ip address LOC_B_VIP
    priority 100
    preempt
    description Backup-Local-B2
    no shutdown
    !

     

    And its cousin would have the config :

     

    vrrp 25
    vlan MGMT_VLAN
    ip address LOC_B_VIP
    priority 110
    preempt
    description Preferred-Local-B1
    no shutdown
    !
    vrrp 20
    vlan MGMT_VLAN
    ip address LOC_A_VIP
    priority 100
    preempt
    description Backup-Local-A2
    no shutdown
    !

     

    Is this all making sense?  Am I on the right track?

     

    Ah, found this KB Article : https://arubanetworkskb.secure.force.com/pkb/articles/HowTo/R-1633 & that pretty much confirms my initial configuration parameters.

     

    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?

     

    Thanks,

     


    #7210
    #7240


  • 2.  RE: VRRP Config Recommendations

    Posted Dec 19, 2013 12:04 PM

    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!



  • 3.  RE: VRRP Config Recommendations

    Posted Jan 08, 2014 10:42 AM

    Hello again, 

     

    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.  

     

    was able to apply the config but for whatever reasonboth 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 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 airheads regarding VRRP and I found one regarding VRRP & HSRP.  Wondering if this is similar to VSS or if the VSS configuration might be causing our issue?  

     

    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?  

     

     

    Thanks, 

     



  • 4.  RE: VRRP Config Recommendations

    Posted Jan 09, 2014 02:58 PM

    Nevermind, 

     

    It was an ACL issue.