As an alternative to creating static subscriber interfaces, you can configure E-series routers to create subscriber interfaces dynamically.
When you create a static subscriber interface, as described in Configuring Static Subscriber Interfaces, each layer in the interface stack is created through an existing configuration mechanism such as command-line interface (CLI) or Simple Network Management Protocol (SNMP).
By contrast, the router creates dynamic subscriber interfaces on demand, in response to an external event. Two types of external events can cause dynamic creation of subscriber interfaces: when an Dynamic Host Configuration Protocol (DHCP) event occurs or when the router detects a packet.
The DHCP event that triggers dynamic creation of subscriber interfaces occurs when either a local DHCP server or external DHCP server assigns an IP address to a subscriber that has issued a DHCP request. After the DHCP server assigns the IP address and the router creates the associated dynamic subscriber interface, the subscriber can access required network services.
You can configure the DHCP local server to operate in either equal-access mode or standalone mode.
In standalone mode, the DHCP local server provides a basic DHCP service. The server receives a client request for an IP address and immediately allocates the subscriber an IP address from one of the local address pools.
In equal-access mode, the DHCP local server works with Juniper Networks Session and Resource Control (SRC) software and the authorization, accounting, and address assignment utility to provide an advanced subscriber configuration and management service. After the subscriber is authenticated through RADIUS, the DHCP server assigns the subscriber an IP address with a long lease time. This assignment of an IP address triggers the creation of dynamic subscriber interfaces.
For more information about the DHCP servers and the SRC software, see the following chapters:
With DHCP external server, all communication between the subscriber and the DHCP server is monitored by the E-series router. The subscriber requests an address from the DHCP server through the E-series router. After the subscriber receives an IP address, the subscriber can access the Internet and use the value-added services provided by the E-series router and by the SRC software. The edge network must be using a DHCP relay function.
The services provided by integrating the E-series router’s DHCP external server application with SRC software are similar to those provided when the DHCP local server is integrated with SRC software. For more information, see SRC-PE Getting Started Guide, Chapter 1, SRC Product Overview.
When you are configuring dynamic subscriber interface support, and you configure DHCP relay in the same virtual router as the dynamic subscriber interfaces, you must use the set dhcp relay inhibit-access-route-creation command to ensure that DHCP replay does not install access internal routes. Otherwise, DHCP relay will overwrite the access internal routes that are originally created for the subscriber interface.
E-series routers currently support dynamic creation of subscriber interfaces with DHCP servers in the following configurations:
For example, Figure 19 shows the interface stacking in an IP over Ethernet dynamic subscriber interface configuration. The illustration indicates which layers in the stack are static and dynamic, and identifies the CLI commands typically used to create the configuration.
Figure 19: IP over Ethernet Dynamic Subscriber Interface Configuration

As shown in Figure 19, issuing the ip auto-configure ip-subscriber command configures the primary IP interface to enable dynamic creation of subscriber interfaces. However, the router does not actually create the dynamic subscriber interface until the DHCP server assigns an IP address to the associated subscriber.
To configure each supported configuration, see Configuring Dynamic Subscriber Interfaces.
For GRE tunnel interfaces, the event that triggers dynamic creation of subscriber interfaces occurs when the router receives a packet with a source IP address that is not in the demultiplexer table. In this case, the primary IP interface must be in autoconfiguration mode.
Packet detection is the only method of dynamically creating subscriber interfaces on GRE tunnel interfaces; you cannot use DHCP local server or DHCP external server.
Issuing the ip auto-configure ip-subscriber command configures the primary IP address to enable dynamic configuration of subscriber interfaces. Unlike DHCP configurations, the router creates the dynamic subscriber interface when it receives the first packet that contains the subscriber’s IP address as the source address.
In addition, a dynamic subscriber interface becomes inactive after a period of time in which the router receives no packets that contain the subscriber’s IP address as the source address. You can configure the period of time by issuing the ip inactivity-timer command.
To configure dynamic creation of subscriber interfaces on GRE tunnel interfaces, see Configuring Dynamic Subscriber Interfaces.
When dynamic creation of subscriber interfaces is enabled on the primary IP interface (by means of the ip auto-configure ip-subscriber command), you can use the ip source-prefix command to specify the source address of traffic that is destined for the primary IP interface instead of the subscriber interface. If the DHCP server (for DHCP server configurations) or the router (for packet detection configurations) then assigns a subscriber an IP address matching this source prefix, the router does not create a dynamic subscriber interface for that address.
You can use the ip use-framed-routes ip-subscriber command to enable a primary IP interface to use framed routes as source IP addresses when creating dynamic subscriber interfaces. The framed routes are applied to the dynamic subscriber interface during configuration so traffic from the subsets can traverse the interface. By applying framed routes in this fashion, you can extend the per-subscriber interface management to any subnetworks behind the dynamic subscriber interface. RADIUS includes the Framed-Route attribute [22] in Access-Accept messages to specify the route in the following format:
- Framed-Route = ipAddress/mask nextHop
A dynamic IP subscriber interface inherits the MAC address validation state (enabled or disabled) configured for its parent static primary IP interface.
MAC address validation binds a MAC source address for an interface to a given IP source address. When the IP-MAC binding is established, the router forwards ingress packets on the interface when the packet’s MAC source address and IP source address match, and drops ingress packets when the packet’s MAC source address and IP source address do not match. MAC address validation thereby prevents spoofing on IP-based Ethernet interfaces, and is very useful in subscriber management applications.
When MAC address validation is enabled on an interface, the router checks the entry in the MAC validation table that corresponds to the IP source address of an incoming packet. The MAC source address of the packet must match the MAC source address of the table entry for the router to forward the packet.
To enable MAC address validation for the static primary IP interface, you must use the existing ip mac-validate command with either the strict keyword or the loose keyword. The strict keyword prevents transmission of IP packets that do not reside in the MAC validation table. The loose keyword, which is the default setting, enables IP packets to pass through even when the packets do not have entries in the MAC validation table; only packets that have matching IP-MAC pair entries in the table are validated.
When a dynamic IP subscriber interface is created with the MAC address validation state inherited from the static primary IP interface, an entry for the MAC source address is installed in the MAC validation table when MAC address validation is enabled (either loose or strict) on the static primary IP interface. For each packet received on this interface, the router compares the packet’s MAC source address to the value in the MAC validation table. If these values match, the router forwards the packet; otherwise, the packet is discarded.
In addition, creation of the dynamic IP subscriber interface adds a static MAC address validation entry in the router’s Address Resolution Protocol (ARP) table. This occurs regardless of whether you configure MAC address validation on the static primary IP interface with the ip mac-validate strict command or the ip mac-validate loose command.
No special configuration is required to enable inheritance of the MAC address validation state on dynamic IP subscriber interfaces; this occurs automatically provided that MAC address validation is properly enabled on the parent static primary IP interface with the ip mac-validate command. If MAC address validation is disabled on the static primary IP interface, the dynamic subscriber interface inherits the disabled state for MAC address validation.
Keep the following guidelines in mind for using dynamic IP subscriber interfaces that inherit the MAC address validation state from their parent static primary IP interface:
To verify inheritance of the MAC address validation state on a dynamic subscriber interface, you can use the show ip mac-validate interface command and the show arp command.
The following sample output from the show ip mac-validate interface command displays the MAC address validation state (strict) inherited by the dynamic subscriber interface ip74.39.64.3 from its parent static primary IP interface.
host1#show ip mac-validate interface ip74.39.64.3 ip74.39.64.3: Strict
Address Hardware Addr 74.39.64.3 0090.1a40.f4f6
Building on this example, the following sample output from the show arp command displays a static MAC address validation entry (74.39.64.3) in the ARP table for the dynamic subscriber interface when it is created with the MAC address validation state inherited from its parent static primary IP interface. The asterisk (*) indicates that the ARP entry was added as the result of issuing an arp validate command rather than an arp command.
host1#show arp
Address Age Hardware Addr Interface
10.13.10.1 21600 0090.6939.751b FastEthernet6/0
74.39.64.3 - 0090.1a40.f4f6 ip74.39.64.3 *
192.168.1.2 20700 0090.1a40.280d FastEthernet8/2