Hide Navigation Pane
Show Navigation Pane
Download
SHA1
DHCP Client Bindings and Duplicate MAC Addresses for Subinterfaces Overview
In certain network scenarios, active VLAN subinterfaces of subscribers might be transferred from one virtual router to another, and later retransitioned to the original virtual router for correct computation of subscription and billing costs for customers being serviced by an enterprise provider. Also, addition and removal of active VLAN subinterfaces might be performed during troubleshooting with the customer premises equipment (CPE) devices. Such changes in the configuration of active VLAN subinterfaces causes differences in the subscriber entries displayed in the output of the show dhcp bindings (and other commands used to monitor DHCP bindings) and show subscribers commands.
When the DHCP client is bound to an IP address, deletion of the active VLAN subinterface causes the subscriber entry to be removed from the AAA database and the access-internal route for that client to be deleted. In such a scenario, if the client binding was still retained in the DHCP database, the entries for that subscriber for which the binding is removed from the AAA database are not displayed in the output of the show subscribers (under the User Name field) and show ip route access-internal (under the Prefix/Length field) commands.
When the VLAN subinterface associated with a DHCP client, which was previously deleted when the client binding was removed, is reconfigured, the entries for that subscriber are not displayed in the output of the following show commands until the DHCP client sends a discover or renew request to the DHCP server for an IP address to be allocated to it:
- show ip dhcp-local binding interface (under the Address field)
- show ip route access-internal (under the Prefix/Length field)
- show subscribers (under the User Name field)
When some DHCP packets flow between the subscriber and the router, the following events take place:
- During the process of allocating IP addresses to the DHCP client, which involves the discovery, offer, request, and acknowledgment messages between the server and the client, the client binding already exists in the database and the DHCP server does not contact AAA for authentication. At this point, the subscriber entry is not present in the AAA database. The access-internal route is created for the client and the subscriber connection becomes active. The client does not receive Acct-Request packets because the entry for this subscriber is not available in the AAA database.
- When the client sends a renew request to renew its address, the request does not reach the interface on the DHCP server. The DHCP server sends a NAK message to the client, forcing the client to begin the DHCP connection process again.
- When the client sends a rebind request for the IP address to be bound again to it, the existing binding for this client is deleted and re-created during the next discovery process. All the databases are synchronized and the entry for the client is correctly displayed in the output of the show subscribers and show dhcp bindings commands.
In this scenario, the subscriber session might be established and active without accounting records for Acct-Stop and Interim-Acct messages sent to the RADIUS server during the process of allocating addresses to DHCP clients in JunosE releases numbered lower than 9.3.x.
Beginning with JunosE Release 9.3.x, support for configuring DHCP external server to uniquely identify clients with duplicate MAC addresses is available. This functionality causes a new IP address to be assigned to a client during the process of DHCP address allocation by the DHCP server using the discovery, offer, request, and acknowledgment sequence. The previously configured binding for the same client is deleted from the database before the lease period expires for that address, immediately after the VLAN subinterface for that client is deleted. Because the DHCP bindings are stored in a server management table that includes the VLAN subinterface user ID (UID), when the server queries the management table to check whether a binding for a client already exists, no match is found and a fresh client binding is created when the VLAN subinterface is reconfigured.
To prevent the problem of incorrect and inconsistent parameters being displayed in the show commands used to monitor subscriber information and DHCP binding attributes, the client binding is removed from the DHCP database after the VLAN subinterface associated with that subscriber is deleted. Retaining the client binding is not effective after the primary interface is deleted because when the client logs in again, it is assigned a different user ID unless a rollover of the user ID occurs. This rollover causes the user ID assigned to the client prior to the logout to be reassigned to it upon logging in again and a fresh IP address is bound to the client. When a stateful SRP switchover operation is performed before the transaction is posted to the standby SRP module, the client binding remains in the database because it is added again when the configuration data is restored from the mirrored containers. The client binding stays in the database until its lease expires.
