Security

 View Only
last person joined: yesterday 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Back to discussions
Expand all | Collapse all

ClearPass Publisher-Subscriber HA Best Practice

This thread has been viewed 51 times

  • 1.  ClearPass Publisher-Subscriber HA Best Practice

    Posted Nov 10, 2022 01:41 PM
    My current architecture is as follows:
    • Publisher in AWS US-East VPC
    • Subscriber in Boston, MA
    • Subscriber in Dublin, Ireland
    • (new) Subscriber in Singapore


    We have additional plans for subscribers in various regions, and a standby Publisher somewhere else in the world.  However, upon adding the Singapore appliance to the cluster I've noticed that it's consistently "Out of Sync".  I opened a TAC case and they've pointed to the following documentation:


    The cluster diagnostics between publisher and subscriber in question are as follows:
    Throughput: 91.357 Kbps/sec
    Configured MTU: 1500
    Ping Latency : 275.806666667 ms
    Publisher database connection check: [OK]
    Publisher database connection time(HH:MM:SS.µs): 0:00:02.167797

    This leads me to a few questions...

    • What is the impact of a subscriber being out of sync with the publisher?  Does this have any impact on dot1x auth (assuming the publisher is not fielding any of those request directly)?  Does this impact endpoint sync between subscribers (ie. a newly profiled endpoint in Singapore isn't "shared" with a subscriber in Dublin until a successful sync)? etc..
    • Is this a hard setting, or does it only lead to potentially degraded performance?
    • Is there any way to tune or optimize this?
    • And, generally, what are the best practices for a global deployment?  Based on some quick RTT testing, a US-West Publisher is the only location in my environment that could reach all sites in <200ms.  This would mean there are no locations to even add a standby Publisher to if I wanted to.

    Do most deployments even use HA publishers, or is it overkill if I'm expecting near 100% uptime in my environment? Any other info/suggestions would be appreciated!


  • 2.  RE: ClearPass Publisher-Subscriber HA Best Practice

    Posted Nov 11, 2022 08:13 AM
    1. Most likely due to latency.  200ms is the maximum supported RTT time between ClearPass nodes.  This means that any policy changes on the publisher may not be properly replicated to the subscriber.  Logging is also likely to be impacted
    2. See above. https://www.arubanetworks.com/techdocs/ClearPass/6.10/PolicyManager/Content/Deploy/Cluster%20Deployment/Design_guidelines.htm#Geo
    3. Decrease latency by moving publisher to a more central location or deploying multiple ClearPass clusters.

    I never deploy standby publisher as I want to know why/if a real issue occurs before I choose to failover.   The only environments I deploy standby publisher in are those that actually use the features that require an active publisher in the deployment (guest self-registration, MDM integration, etc.):

    Functions Lost When the Publisher Is Down

    When the active Publisher goes out of service, the following ClearPass Policy Manager functions are temporarily lost:

    AirGroup and MACTrac enrollment

    Certificate creation and revocation

    Certificate revocation list updates

    ClearPass Exchange outbound enforcement

    General ClearPass Policy Manager and ClearPass Guest configuration changes

    ClearPass Guest account creation

    Mobile device management endpoint polling and ingestion

    Onboarding functionality


    Original Message


  • 3.  RE: ClearPass Publisher-Subscriber HA Best Practice

    Posted Nov 11, 2022 11:07 AM
    Hi

    I agree with the answers from ahollifield, your problem is related to the latency.
    A few years ago I had a customer with cluster nodes in London and New York. Due to VPN tunnels we had an issue with latency between the sites and sometimes got really poor performance. If the subscriber is out of sync for a long time, more than 24 hours, the syncronization will not re-establish automatically.
    In that case you have to drop the subscriber from the cluster and join again.

    The subscriber will continue to authenticate clients locally, but will not get any new configuration. As mentioned in this situation the function will be limited in the same way as if the Publisher is down.

    For global deployments of ClearPass multiple clusters are usually the best solution.
    You have an option to utilize the ClearPass Syncronization Service to replicate configuration data between multiple clusters. But this service have a quite high price tag, so I would only use it in very special cases.
    I evaluated this service for one of my customers with multiple ClearPass clusters and in total about 15 servers, but found the price tag to high.

    ------------------------------
    Best Regards
    Jonas Hammarbäck
    ACCX #1335, ACMP, ACDP, ACNSP, ACEP, ACSA
    Aranya AB
    If you find my answer useful, consider giving kudos and/or mark as solution
    ------------------------------

    Original Message


  • 4.  RE: ClearPass Publisher-Subscriber HA Best Practice

    Posted Nov 15, 2022 09:22 AM

    Thank you both - these answers were extremely helpful!

    Scott


    Original Message


  • 5.  RE: ClearPass Publisher-Subscriber HA Best Practice

    Posted Nov 23, 2022 01:32 PM
    We had the same issue when we installed a subscriber node in Singapore as well. Publisher is in the Chicago area.  Had constant out of sync issues.  Someone at TAC told me to try changing one parameter to see if it helps. Resolved my issues, SG hasn't been out of sync since, 4+ years and no issues.

    Administration > Server Configuration > Cluster-Wide Parameters > Database > Change Replication Batch Interval from the default 5 to 15. 

    Original Message


  • 6.  RE: ClearPass Publisher-Subscriber HA Best Practice

    Posted Nov 23, 2022 03:57 PM
    Well, it was that simple. Thank you!



    Original Message