Managing Interchassis Redundancy; 1:1 Subscriber Redundancy In A 4-Node Icr Cluster; Interaction With Radius For Icr; Figure 10: Sample 1:1 Subscriber Redundancy In A 4-Node Icr Cluster - Juniper JUNOSE SOFTWARE FOR E SERIES 11.3.X - SERVICE AVAILABILITY CONFIGURATION GUIDE 2010-10-08 Configuration Manual

1:1 Subscriber Redundancy in a 4–Node ICR Cluster
Before failover
75%
36,000 subscribers
12,000 spare capacity
75%
36,000 subscribers
12,000 spare capacity
Related
Documentation

Interaction with RADIUS for ICR

Copyright © 2010, Juniper Networks, Inc.
NOTE: Remember to consider parameters such as link bandwidth, QoS, and
line module scaling limitations when you plan the deployment of the ICR
cluster.
Consider a 4–node ICR cluster that consists of four ERX1440 routers, as shown in Figure
10 on page 173. Each of the four routers is capable of supporting 48,000 PPP/PPPoE
subscribers. The degree of redundancy that you can achieve in this cluster is 1:1. For every
subscriber, you have a backup destination within the cluster. If one router fails, subscriber
load is equally distributed to the other three routers. Thus, no single router serves as a
dedicated backup. Instead, each router can be loaded with around 75 percent of its
capacity while the remaining 25 percent is available to accommodate subscribers from
the failing router. Failure of any one router causes all routers in the cluster to become
fully loaded with no spare capacity to accommodate further failures. This is the minimum
degree of redundancy in a 4–node ICR cluster.
Figure 10 on page 173 illustrates an example of a typical ICR configuration.
Figure 10: Sample 1:1 Subscriber Redundancy in a 4–Node ICR Cluster
75%
36,000 subscribers
12,000 spare capacity
75%
36,000 subscribers
12,000 spare capacity
Configuring an ICR Partition on page 175
Authorization and authentication access messages identify subscribers before the RADIUS
server grants or denies those subscribers access to the network or network services.
When an application requests user authentication, the request must have certain
authenticating attributes, such as a user's name, password, and the particular type of
service the user is requesting. This information is sent in the authentication request via
the RADIUS protocol to the RADIUS server. In response, the RADIUS server grants or
denies the request.
Chapter 7: Managing Interchassis Redundancy
Single chassis failure - spare capacity reduced to zero
100% 100%
48,000 subscribers 48,000 subscribers
No spare capacity No spare capacity
100%
Chassis failure
48,000 subscribers
No spare capacity
173