I85PREP
⌘ K
Cisco 300-715 SISE study materials
Cisco 300-715 SISE study resources

Post-Change Replication, Certificates, and pxGrid Staleness

Cisco 300-715 SISE · Put your knowledge to work in context.

All case studies

Post-Change Replication, Certificates, and pxGrid Staleness

A university runs ISE 3.1 with a PAN, MnT, and two PSNs; a planned upgrade to 3.3 is underway. pxGrid integrates with Firepower Management Center for endpoint context. The deployment uses a wildcard certificate on the PAN and PSNs. After a change window, the secondary PSN shows 'Replication status: Out of sync' for 36 hours; pxGrid publishes stale session data; Firepower sees no new endpoints. The certificate on the secondary PSN was replaced with a certificate whose CN is ise2.university.example but the SAN lacks the PAN's FQDN. Administrators also report slow GUI response on the secondary PSN. The backup was taken before the upgrade.

1. What are the likely causes of the secondary PSN being out of sync for 36 hours, and what sequence would you use to restore replication?

Read the worked answer

Replication failure is usually a connectivity, time, certificate, or resource issue. Check in this order:

  1. NTP: all nodes must agree on time. Large clock skew breaks replication and certificate validation.
  2. Inter-node connectivity: confirm TCP 443 and the inter-node replication ports are open between PAN and secondary PSN. A change-window firewall rule is a common cause.
  3. Certificates: the secondary PSN certificate must be trusted by the PAN and include the correct FQDN in the SAN. A CN-only certificate can break TLS between nodes.
  4. Disk and CPU: slow GUI and 36-hour lag can indicate a full disk, high CPU, or a replication backlog. Check disk usage and node health.
  5. Manual sync: after fixing the cause, run a manual synchronization from the PAN's deployment page and watch the replication status.

Do not proceed with the 3.3 upgrade until replication is healthy. Upgrade the PAN first, then MnT, then PSNs, and take a fresh backup before each stage.

2. How does the secondary PSN certificate with a missing SAN affect pxGrid and Firepower integration, and what should the certificate contain?

Read the worked answer

pxGrid uses certificate-based mutual authentication. The FMC must trust ISE's pxGrid certificate, and ISE must trust the FMC client certificate. If the certificate is missing the correct SAN, hostname validation can fail even when the CN looks correct.

The replacement certificate should include:

  • The node FQDN ise2.university.example in the SAN.
  • The PAN's FQDN if that certificate is used for services that present the PAN identity.
  • The EKU appropriate for server/client authentication, depending on the service.
  • A complete CA chain imported into ISE Trusted Certificates and the FMC trust store.

Because pxGrid is publishing stale data, also verify which node is running the pxGrid service and whether the FMC is registered to that node's FQDN. If the FMC is connected to a PSN that is out of sync, re-register it to the healthy PAN/pxGrid node. Then check Operations > pxGrid Services > Clients for the FMC connection and re-establish it if needed.

3. What is the correct order for the 3.3 upgrade given the out-of-sync PSN and the pre-upgrade backup, and what checks should precede it?

Read the worked answer

The out-of-sync PSN is a blocker. Restore replication and node health first; upgrading an unhealthy node can make the deployment unrecoverable.

Recommended order:

  1. Take a fresh backup from the PAN and MnT and verify it. The older backup is only useful for a rollback to the pre-upgrade version, not for a 3.3 restore.
  2. Fix NTP, connectivity, disk, and the certificate SAN issue. Confirm replication is in sync.
  3. Upgrade the PAN, then MnT, then the PSNs, following the deployment's supported upgrade path.
  4. After each stage, verify replication, certificate trust, and pxGrid registration.
  5. Re-register Firepower with the pxGrid node and confirm new endpoint data appears.

Before the upgrade, also check the wildcard certificate's SAN coverage for all service FQDNs, because an upgrade can expose services that were not previously validated. Slow GUI on the secondary PSN should be resolved before the upgrade; otherwise it will be difficult to distinguish upgrade problems from pre-existing resource issues.