Residential gateway replacement

Residential gateway (RG) replacements are performed for a variety of reasons such as upgrading hardware, replacing broken equipment, or relocating to a new home. However, the BNG’s anti-spoof filter and host-limit features can sometime prevent immediate RG replacement. In some cases, a subscriber must wait for an old DHCP lease to expire before a new RG can connect to the BNG. For example, some service providers assign an IP address and prefix based on physical line, sap-id, circuit-id, or interface-id. Therefore, a home is always assigned the same IP address and prefix. On the BNG, an anti-spoof mechanism prevents different MAC addresses from using the same IP address. As a result, the new RG fails the anti-spoof filter and is denied an IP address and/or prefix. The subscriber in this case must wait for the DHCP lease of the RG to time out for the anti-spoof filter to remove its entry.

Two features, lease-override and shcv-policy, may help improve the RG replacement process. These features focus on minimizing service interruption and enhancing the end subscriber experience. RGs, in general, have no mechanisms to inform the BNG or the DHCP server that they have been disconnected from the network. Even if the BNG has periodic SHCV enabled, the detection may take some time. Often, when a subscriber plugs in a new RG, the BNG still has the old RG registered as a host. This has two consequences. First, if the new RG is assigned the same IP address as the old RG, then an IP-conflict occurs and fails the anti-spoof filter. Second, if the SAP has a host limit or a session limit provisioned, then exceeding the limit prevents the new RG from receiving an IP address or prefix.

Starting in Release 13.0R4, if an IP conflict occurs on the same SAP, then by default the new RG (MAC) immediately overrides the DHCP lease of the old device. This is known as lease-override. This is applicable to DHCP relay and proxy for both IPv4 and IPv6 hosts. Before Release 13.0.R4, lease-override only occurred for DHCPv4 relay. The lease-override is performed only when an IP conflict occurs within the same SAP.

The other option is to use trigger SHCV to check the connectivity status of the old RG before removing it and its lease. This is known as the ip-conflict-triggered SHCV under the SHCV policy. The SHCV is sent only when the BNG detects an IP address conflict on DHCP discovery. If the host does not respond within the configured timeout, both the host and lease are removed from the BNG. The new RG is required to perform a subsequent DHCP discovery or request to install a host. SHCV can help prevent malicious RGs from spoofing another RG IP address. Trigger SHCV for IP-conflict is available for DHCPv4/v6 relay and proxy, as well as ARP hosts. The following table specifies when the SHCV is sent for IP-conflict.

Table: IP-conflict SHCV triggering points
Configuration on group interface Triggered on

DHCPv4 proxy

DHCP Discovery

DHCPv4 relay

DHCP Request

DHCPv6 proxy

DHCP Advertisement

DHCPv6 relay

DHCP Advertisement

ARP-host

Host’s initial ARP

It is also possible that new RGs are denied service as a consequence of a set of host limits against the subscriber including sla-profile host-limits and session-limits, sub-profile host-limits and session-limits, ipoe session-limit, and ipoe sap-session limits. For example, setting a host limit of overall 1 can ensure that each home only takes one IP address. As mentioned before, RGs do not inform the BNG of a disconnect. If SHCV is enabled, it may take some time before the BNG is informed of the disconnect. Therefore, when a new RG connects to the BNG, the BNG performs a host-limit check (if configured) against the subscriber. If the old host still has an entry on the BNG and there is a host-limit of overall 1, the new RG is denied an IP address and prefix assignment because it has exceeded the host limit. A trigger SHCV, ‟host-limit-exceeded” inside the SHCV policy can be configured against a group interface. This SHCV is triggered when an over limit is detected. If the existing host registered on the BNG does not respond within the configured timeout, both the host and its lease are removed from the BNG. The SHCV can only remove hosts from the BNG and the new RG is still required to perform a subsequent DHCP discoveries or requests to obtain an IP address.

By providing lease-override and various SHCV triggers in the SHCV policy, service providers have a variety of options to allow subscribers to perform quick and seamless RG replacements.

It is possible to use the host-connectivity check without the SHCV policy. The main function of the host-connectivity check is for periodic check. The trigger functions are performed through the SHCV policy.