[Contents] [Prev] [Next] [Index] [Report an Error]

# Application Support

Applications are either supported or unsupported by high availability.

- Supported—You can configure supported applications without having any adverse impact to high availability. When a switchover occurs, supported applications can react to switchovers in one of two different ways:
  - Gracefully recover using mirrored static and dynamic information (for example, IP, PPP, and PPPoE)
  - Recover using static configuration only; that is, no runtime state is restored after a switchover. Dynamic configuration and state information are lost. (For example, CLI sessions are restarted, telnet sessions are dropped, multicast routes must be rebuilt, and so on.)
- Unsupported—We recommend that you not configure unsupported applications on a chassis running in high availability mode. Although configured unsupported applications suspend high availability or prevent high availability from becoming active, they do not cause any problems with the function of the router.

Table 45 indicates which applications support or do not support stateful SRP switchover.

Table 45: Application Support for Stateful SRP Switchover

Application | Supported | Unsupported | Notes
--- | --- | --- | ---
Physical Layer Protocols |  |  |
DS1 | ✓ | – | –
DS3 | ✓ | – | –
HDLC | ✓ | – | –
SONET/SDH | ✓ | – | –
SONET/SDH VT | ✓ | – | –
Link-Layer Protocols |  |  |
ATM | ✓ | – | Static and dynamic interfaces, with the exception of ATM subscribers, are supported. In this case, ATM subscribers refers to a technology on the E Series router where the ATM layer does authentication (that is, not PPP or IP subscriber manager).
ATM 1483 bulk configuration of dynamic interfaces | ✓ | – | –
Bridged Ethernet | ✓ | – | –
Cisco HDLC | ✓ | – | –
Ethernet (with and without VLANs) | ✓ | – | –
Frame Relay | ✓ | – | –
PPP | ✓ | – | –
PPPoE | ✓ | – | –
Transparent bridging | ✓ | – | –
Unicast Routing |  |  |
Access Routes | ✓ | – | –
BFD | ✓ | – | During a stateful SRP switchover, the BFD transmit interval is set to 1000 ms with a detection multiplier of 3. These values result in a liveness detection interval of 3000 ms. This longer interval helps prevent a BFD timeout during the switchover. BFD negotiates the interval with the remote peer before applying the temporary change. The BFD timers revert back to the configured values after 15 minutes (the maximum duration for graceful restart completion).
BGP | ✓ | – | Supported for IPv4 only when the graceful restart extension is enabled. Does not support graceful restart for IPv6 address families.
FTP | ✓ | – | Static recovery support only.
IP | ✓ | – | –
IPv6 | ✓ | – | –
IPv6 neighbor discovery | ✓ | – | IPv6 neighbor discovery characteristics are replayed during switchover. Line modules do not flush neighbor discovery information during the switchover.
IPSec Transport | – | ✓ | –
IPSec Tunnels | ✓ | – | Completed IKE phase 1 and phase 2 negotiations supported only.
IS-IS | ✓ | – | Supported only when the graceful restart extension is enabled.
IS-ISv6 | ✓ | – | Supported only when the graceful restart extension is enabled.
OSPFv2 |  | – | Supported only when the graceful restart extension is enabled.
OSPFv3 | ✓ | – | Supported only when the graceful restart extension is enabled.
RIP | ✓ | – | Static recovery support only.
Static Routes (IP and IPv6) | ✓ | – | After all high-priority interfaces have been replayed from NVS and mirrored storage, static routes are replayed from NVS, followed by replay of low-priority interfaces from NVS and mirrored storage. This behavior enables static routes that are dependent on high-priority interfaces to be resolved quickly and installed in the IP routing table.
Telnet | ✓ | – | Static recovery support only.
IPv4 Multicast Routing |  |  |
Multicast Routing | ✓ | – | Static recovery support only. During switchover, the system mirrors the multicast queue so that IP can use the same queue without needing to recreate a different connection.
DVMRP | ✓ | – | Static recovery support only. DVMRP gives the restart complete indication to the IP routing table after getting a peer update (60-second time-out).
IGMP | ✓ | – | IC IGMP deletes its interface and membership state on SRP failover (controller down). As part of SRP warm start, IGMP interfaces are reconfigured from NVS and dynamic IGMP interfaces are reconfigured from mirrored storage. IGMP hosts are queried as IP interfaces come back up, the join state is re-established, and SC IGMP state is created. After the maximum query response time (across all interfaces) expires to allow hosts to re-establish join state, IGMP notifies MGTM that graceful restart is complete.
MGTM | ✓ | – | On SRP failover, old mroutes are retained on the line module to preserve multicast forwarding; cache-misses to the SRP are disabled. When MGTM warm starts on the SRP, it reads the NVS configuration and enables multicast routing. When IGMP, DVMRP, and PIM have completed graceful restart and the IP route table multicast-view has completed graceful restart, old mroutes are deleted from the line module and cache-misses to the SRP are enabled. This triggers re-creation of mroutes and establishes the current multicast forwarding state. Although cache-misses to the SRP module are disabled, forwarding is preserved for old multicast joins to downstream routers and hosts. However, forwarding for new multicast joins requested by downstream routers and hosts after SRP module switchover is not provided until cache-misses are re-enabled.
PIM | ✓ | – | Static recovery support only. For warm start, PIM interfaces are reconfigured from NVS. A Hello message with a new Generation ID is issued as IP interfaces come up. A neighbor that receives this Hello determines that the upstream neighbor has lost state and needs to be refreshed. A VR-global configurable graceful restart timer is required for PIM to time out the re-establishment of the join state for sparse-mode interfaces. After this timer expires, PIM notifies MGTM that graceful restart is complete.
IPv6 Multicast Routing |  |  |
Multicast Routing | ✓ | – | Static recovery support only. During switchover, the system mirrors the multicast queue so that IPv6 can use the same queue without needing to recreate a different connection.
MGTM | ✓ | – | On SRP failover, old mroutes are retained on the line module to preserve multicast forwarding; cache-misses to the SRP are disabled. When MGTM warm starts on the SRP, it reads the NVS configuration and enables multicast routing. When MLD and PIM have completed graceful restart and the IPv6 route table multicast-view has completed graceful restart, old mroutes are deleted from the line module and cache-misses to the SRP are enabled. This triggers re-creation of mroutes and establishes the current multicast forwarding state. Although cache-misses to the SRP module are disabled, forwarding is preserved for old multicast joins to downstream routers and hosts. However, forwarding for new multicast joins requested by downstream routers and hosts after SRP module switchover is not provided until cache-misses are re-enabled.
MLD | ✓ | – | IC MLD deletes its interface and membership state on SRP failover (controller down). As part of SRP warm start, MLD interfaces are reconfigured from NVS and dynamic IMLD interfaces are reconfigured from mirrored storage. MLD hosts are queried as IPv6 interfaces come back, the join state is re-established, and SC MLD state is created. After the maximum query response time (across all interfaces) expires to allow hosts to re-establish join state, MLD notifies MGTMv6 that graceful restart is complete.
PIM | ✓ | – | Static recovery support only. For warm start, PIM interfaces are reconfigured from NVS and a Hello message with a new Generation ID is issued as IPv6 interfaces come up. A neighbor that receives this Hello determines that the upstream neighbor has lost state and needs to be refreshed. A VR-global configurable graceful restart timer is required for PIM to time out the re-establishment of the join state for sparse-mode interfaces. After this timer expires, PIM notifies MGTM that graceful restart is complete.
Multiprotocol Label Switching |  |  |
MPLS | ✓ | – | MPLS is HA-unsafe during a graceful restart. It is HA-unsafe until all the configured MPLS signaling protocols have completed their graceful restart procedures and any stale forwarding elements have been flushed from the line modules. If you force an SRP switchover while MPLS is HA-unsafe, the SRP module switches but the SRP module and the line modules undergo a cold restart. If the primary SRP module resets while MPLS is HA-unsafe, the router undergoes a cold restart. MPLS over IPv6 supports HA. This functionality enables BGP to support graceful restart for IPv6 labeled addresses.
BGP signaling | ✓ | – |
LDP signaling | ✓ | – | To provide uninterrupted service during an SRP switchover in a scaled configuration, such as one with 32,000 Martini circuits, set the LDP graceful restart reconnect time to the maximum 300 seconds and set the LDP graceful restart recovery timer to the maximum 600 seconds. This requirement is true for all SRP switchovers, including those in the context of a unified in-service software upgrade. LDP signaling does not support HA for IPv6.
RSVP signaling | ✓ | – |
Local cross-connects between layer 2 interfaces using MPLS | ✓ | – | –
Policies and QoS |  |  |
Policies | ✓ | – | –
QoS | ✓ | – | Static recovery support only.
Remote Access |  |  |
AAA | ✓ | – | –
DHCP External Server and Packet Trigger | ✓ | – | Following a switchover, the DHCP lease (that is, time remaining) is recalculated based on when the lease started. When the release timer for a client expires, the client is deleted and the access route is removed, along with the dynamic subscriber interface if it was created. If the client requests a new lease, DHCP external server resynchronizes with the new lease time.
DHCP Packet Capture | ✓ | – | –
DHCP Proxy Client | – | ✓ | –
DHCP Relay Proxy |  | – | –
DHCP Relay Server | ✓ | – | Before HA support, clients identified by the DHCP relay server were maintained on a switchover (their state was stored to NVS); DHCP relay server always had some level of HA support. Currently, following a switchover, the DHCP lease (that is, time remaining) is reset. When the release timer for a client expires, the client requests a new lease. The E Series router DHCP relay server then synchronizes with the new state.
DHCPv4 Local Server | ✓ | – | –
DHCPv6 Local Server | ✓ | – | DHCPv6 is stateful SRP switchover (high availability) safe. After the router receives the first renew or rebind request from the client, it re-creates the DHCPv6 bindings using mirrored AAAA information. It does not use the mirrored DHCPv6 information as it does for other applications that support stateful SRP switchover. The router also re-creates the client binding for any DHCPv6 client that was assigned IPV6 prefixes from RADIUS before an SRP switchover.
L2TP | ✓ | – |
L2TP Dialout | – | ✓ | –
Local Address Pools | ✓ | – | The internal local address server state supports only static recovery. However, the AAA application reallocates active addresses on a switchover. The resulting effect is the local address server having full HA support.
RADIUS Client | ✓ | – | Similar to local address server, AAA recovers disrupted RADIUS communication on a switchover. The resulting effect is the RADIUS client having full HA support.
RADIUS Dynamic-Request Server | ✓ | – | Static recovery support only.
RADIUS Initiated Disconnect | ✓ |  | –
RADIUS Relay Server | ✓ | – | –
RADIUS Route-Download Server | ✓ | – | –
Service Manager | ✓ | – | –
SRC Client | ✓ | – | –
TACACS+ | ✓ | – | Static recovery support only.
Miscellaneous |  |  |
DNS | ✓ | – |
DNSv6 | – | ✓ | If DNSv6 is configured, no warning or error is displayed during a warm start. DNSv6 is subsequently configured from NVS as it would be after a cold reboot.
J-Flow (IP flow statistics) | ✓ | – | –
Line Module Redundancy | ✓ | – | –
Network Address Translation | ✓ | – | –
NTP | ✓ | – | –
Resource Threshold Monitor | ✓ | – | –
Response Time Reporter | ✓ | – | –
Route Policy | ✓ | – | Static recovery support only.
Subscriber Interfaces | ✓ | – | IPv4 only. Subscriber interfaces are not applicable to IPv6
Tunnels (GRE and DVMRP) | ✓ | – | –
VRRP | ✓ | – | Static recovery support only.

| Caution: When IP tunnels are configured on an HA-enabled router and the Service Module (SM) carrying these tunnels is reloaded, HA transitions to the pending state. HA remains in the pending state for 5 minutes after the successful reloading of the SM. This amount of time allows for IP tunnel relocation and for the tunnels to become operational again on the SM. If an SRP switchover occurs while HA is in the pending state, the router performs a cold restart.

[Contents] [Prev] [Next] [Index] [Report an Error]