Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    ICR Overview

    A broadband services router (BSR) aggregates many subscribers and services such as video on demand (VOD), voice over IP (VoIP), Internet Protocol television (IPTV), and the Internet, simultaneously. If the router fails because of hardware failures, subscriber downtime can result.

    Interchassis redundancy (ICR) enables you to minimize subscriber downtime when the router or access interface on the edge router fails. ICR accomplishes this by re-creating subscriber sessions on the backup router that were originally terminated on the failed router. In this way, ICR enables you to completely recover from router failure. ICR uses Virtual Router Redundancy Protocol (VRRP) to detect failures. ICR also enables you to track the failure of uplink interfaces. ICR currently supports only PPPoE subscribers.

    Figure 1 illustrates ICR deployment.

    Figure 1: ICR Deployment

    ICR Deployment

    The subscriber broadcasts a PPPoE Active Discovery Initiation (PADI) packet to both the master and backup router. Only the master router processes the packet and creates the subscriber session. When the master router fails, VRRP switchover occurs and the backup router becomes the new master router. When receiving traffic for non-existent PPPoE sessions, the new master router sends early termination requests by sending PPPoE Active Discovery Termination (PADT) packets to the clients instead of waiting for the client to reconnect after the PPPoE session expires. The clients respond by sending requests to log in again. Then, the new master router creates new sessions for the PPPoE subscribers.

    In lower-numbered releases, the new master router dropped the PPPoE packets because a session did not exist for the PPPoE subscribers and did not send PADT packets.

    ICR achieves load balancing in case of failures on a per physical port basis by enabling you to create partitions. An ICR partition is a set of S-VLANs (and CVLANs) associated with a unique VRRP instance. There can be multiple partitions per physical port. A partition is the basic unit of redundancy. A partition cannot span multiple physical ports.

    You can also create ICR clusters. An ICR cluster consists of a group of routers participating in ICR. You can use different E Series routers to configure a heterogeneous ICR cluster. For example, you can use an E120 or E320 router with an ES2 4G LM as a backup for subscribers on an ERX1440 router, or use an ERX1440 router with a GE-HDE LM as a backup for subscribers on an E120 or E320 router. However, you must keep in mind the hardware scaling limitations when you configure an ICR cluster containing both E320 routers and ERX routers.

    Note: While deploying ICR, service providers must ensure that the aggregation layer between the E Series router and access node (DSLAM) provides a broadcast domain per VLAN or per S-VLAN between active and backup routers. In the case of a direct connect model the access node must provide the broadcast domain per VLAN or per S-VLAN between the active and backup routers or instead provide an Ethernet switch such as EX Series Ethernet Switch between the access node and E Series router.

    Note: In JunosE Release 11.1.x through Release 11.2.x, when you configured an ICR partition on a static VLAN subinterface with a VLAN ID and traffic from a PPPoE subscriber arrived on a static VLAN subinterface with a VLAN ID not configured on the router, the forwarding controller sent PPPoE Active Discovery Termination (PADT) packets to the subscriber, even though the VLAN ID was not configured on the router.

    Beginning with JunosE Release 11.3.x, when a PPPoE subscriber sends a PPPoE Active Discovery Initiation (PADI) packet on a static VLAN interface with a VLAN ID that is not present on the router and configured with an ICR partition, the router drops the PADI packet in the incoming Ethernet interface and does not send a PADT packet. For example, if you configure a VLAN subinterface with a VLAN ID of 100 and if the PADI packet from the client arrives with a VLAN ID of 200, the router does not generate a PADT packet and drops the PADI packet. For dynamic VLAN subinterfaces with an ICR partition configured, PADT packets are sent to subscribers whose requests arrive with a VLAN ID that is not configured on the router and sessions are terminated. This behavior of processing PADI packets for nonexistent VLAN IDs occurs because the dynamic VLAN subinterfaces might not have been configured on the newly active master router after a VRRP switchover.

    Published: 2014-08-12