Cisco 300-730 SVPN: GET VPN Rekey Failure After Key Server Switchover in a Non-Multicast Region

GET VPN Rekey Failure After Key Server Switchover in a Non-Multicast Region

A GET VPN deployment has a primary key server (KS) and a secondary KS, plus 200 group members (GMs) across three regions. The GDOI group uses multicast address 239.1.1.1, TEK lifetime 3600 seconds, KEK lifetime 86400 seconds, and pre-shared rekey authentication. After the primary KS fails, the secondary takes over and GMs re-register, but GMs in region C stop receiving rekeys. show crypto gdoi on a region-C GM shows the KEK active and TEK remaining lifetime at 0; data traffic between region-C sites fails. Region C's provider does not support multicast; regions A and B do. The security team wants to keep GET VPN and avoid moving to a point-to-point overlay, while preserving rekey authentication and KS redundancy.

1. Why did region C fail only after the KS switchover, and what would you check first?

Read the worked answer

GET VPN rekey messages are normally sent from the KS to the group address, and GMs must receive them over multicast. Regions A and B had multicast working, so their GMs received rekeys from either KS. Region C's provider does not support multicast, so those GMs likely received the initial policy and registration through unicast or through a temporary path, but they could not receive the periodic multicast rekeys. After the primary KS failed, the secondary KS took over and the rekey behavior exposed the missing multicast path; the TEK expired with no replacement, so the GM kept the KEK but had no valid TEK for data encryption.

Check first:

On a region-C GM: show crypto gdoi and show crypto gdoi gm for TEK/KEK state and rekey receive counters.
show ip mroute and show ip pim on the region-C path to confirm multicast forwarding and RPF.
On the KS: show crypto gdoi ks rekey and the group configuration to confirm the rekey transport method and retransmit settings.
Whether the secondary KS is using the same group identity, rekey authentication key, and multicast group address as the primary.

2. What configuration change preserves GET VPN and KS redundancy for region C without requiring multicast?

Read the worked answer

Use GET VPN's unicast rekey transport for the group, or for the affected GMs if the platform supports per-GM rekey transport. On the KS, configure the GDOI group to send rekeys via unicast instead of multicast; the GMs then register to the KS and receive rekeys directly over UDP. This keeps the GET VPN any-to-any data plane and the KS/KEK architecture, while removing the dependency on provider multicast in region C.

Also:

Keep pre-shared rekey authentication so GMs only accept rekeys from an authorized KS.
Ensure both primary and secondary KS have identical group configuration, including the rekey transport setting and authentication key.
Increase rekey retransmit and retry values so a brief path failure does not let the TEK expire.
Verify with show crypto gdoi that region-C GMs show a nonzero TEK remaining lifetime and with show crypto gdoi ks rekey that the KS is sending unicast rekeys.

Do not disable rekey authentication or fall back to a static point-to-point overlay; either would weaken the security model or add significant operational complexity. Test a KS switchover in a maintenance window and confirm region C receives a new TEK before the old one expires.