# Redundancy and Interface Distribution of Tunnel-Service Interfaces

The redundancy and distribution mechanisms supported for tunnel-service ports configured on ISMs differ from those supported for SMs, the ES2-S1 Service IOA, and shared tunnel-server ports.

This section describes the redundancy and interface distribution mechanisms for all tunnel-server ports.

## SMs, ES2-S1 Service IOA, and Shared Tunnel-Server Modules

You can install multiple modules to provide redundancy. If you install multiple modules at the same time, the router automatically distributes the tunnel-service interfaces over the modules in proportion to the available tunnel-service interfaces. Both the primary and the redundant line modules must provide identical functionality. For instance, if the primary line module provides forwarding functionality, you cannot configure the redundant line module to provide shared tunnel-server functionality. Similarly, if the primary line module provides shared tunnel-server functionality, you cannot configure the redundant line module to provide forwarding functionality.

| Note: Shared tunnel server on the ES2 10G ADV LM supports line module redundancy.

Even distribution of tunnel-service interfaces is not critical to router performance. However, the number of modules that you install must be able to support the extra tunnel if one of the modules becomes unavailable.

| Note: When both dedicated tunnel-server ports (on SMs) and shared tunnel-server ports (on shared tunnel-server modules) are configured on ERX7xx models, ERX14xx models, the ERX310 router, the E120 router, and the E320 router, the router performs load balancing across all available server ports of the same type. For this purpose, dedicated tunnel-server ports (on SMs) and shared tunnel-server ports (on shared tunnel-server modules) are considered one type of server port, whereas server ports on ISMs are considered a different type.

Interface allocation depends on the types of tunnel-service interface created on the router. For more information about the types of tunnel-service interfaces, see Types of Tunnel-Service Interfaces .

### Static IP Tunnel-Service Interfaces

You can configure and delete static IP tunnel-service interfaces.

When you configure a static tunnel-service interface, the router automatically assigns that interface to a particular module. If that module becomes unavailable, the router attempts to reassign the interface to an available module. If no module is currently available, the router keeps track of the interface and assigns it to a module when one become available.

Consequently, if you reinstall a module that was formerly unavailable or removed, the distribution of static tunnel-service interfaces over the modules might be uneven. Because users create and remove static tunnels, the distribution might remain uneven indefinitely.

### Dynamic Tunnel-Service Interfaces

The router dynamically creates and deletes dynamic tunnel-service interfaces as dictated by the operation of the relevant protocols. Currently, L2TP sessions are the only dynamic tunnel-service interfaces available.

When the router creates a dynamic tunnel-service interface, it assigns that interface to a particular module. If that module becomes unavailable, the router removes the interface. If the initiator of the dynamic interface requests its reestablishment, the router recreates the dynamic tunnel service interface and assigns it to an available module.

Going forward, if you reinstall a module that was formerly unavailable or removed, the router deletes unwanted dynamic tunnel-service interfaces and creates new ones for applications on other modules. Gradually, the distribution of dynamic tunnel-service interfaces on the modules becomes even.

### Interface Allocation for Shared Tunnel-Server Modules

When determining how to distribute interfaces across tunnel-server ports, the E Series router does not perform interface policing to prevent the access services of a shared tunnel-server module from depriving the tunnel services of the requisite interface resources (and vice-versa). We recommend that when provisioning shared tunnel-server ports, you restrict the number of interfaces configured for both access and tunnel services to prevent competition between them.

For example, when paired with the ES2-S1 OC3-8/STM1 IOA or the ES2-S1 GE-4 IOA, the ES2 4G LM on the E320 router can support a maximum of 16,000 access interfaces and 8,000 shared tunnel-server interfaces, both of which must compete for the overall supported maximum of 16,000 interface columns.

For tunneling, PPP, and IP maximums, see JunosE Release Notes, Appendix A, System Maximums.

## ISMs

You can install multiple ISMs to provide redundancy. If you install multiple ISMs at the same time, the router automatically distributes ISM interfaces over the modules in proportion to the available ISM interfaces.

Even distribution of ISM interfaces is not critical to router performance. However, the number of ISMs that you install must be able to support the extra tunnels if one of the modules becomes unavailable.

When you configure a static IPSec interface, the router automatically assigns that interface to a particular ISM. If that ISM becomes unavailable, the interface becomes not present (operational state down).

The router then manages the interface as follows:

- If the interface’s local IP address (tunnel source) is less than the remote IP address (tunnel destination), the router attempts to reassign the interface to an available ISM. If the reassignment is successful, the router immediately initiates an IPSec negotiation, also known as rekeying the interface.
- If the interface’s local IP address is greater than the remote IP address, the router attempts to reassign the interface to an available ISM. If the reassignment is successful, the router waits 3 minutes before initiating an IPSec negotiation.

In either case, the interface becomes available (operational state up) when the rekeying operation is completed successfully. If the rekeying operation fails for reasons such as an unreachable remote end or a policy mismatch, the router waits a certain number of minutes and then tries again.

The wait time increases after each unsuccessful rekeying attempt, and follows a progressive pattern. This pattern gradually increases in intervals, starting at 1 minute and reaching a maximum interval of 60 minutes. The 60-minute interval repeats indefinitely. When the rekeying operation is completed successfully, the pattern starts again.

If no ISM is available to which the router can reassign the interface, the interface remains in the not present state until an ISM becomes available. As a result, the distribution of dedicated ISM interfaces over the modules might become uneven.