About Configuring Dynamic Interfaces over Static ATM

To create dynamic interfaces over ATM, you create the static layers of the interface first, and then configure them to support a dynamic interface by means of autodetection. Figure 46 shows an example of the interface stack for a dynamic IP over ATM 1483 interface.

Figure 46: Configuring an ATM 1483 Interface to Support Dynamic Interfaces

On receipt of a packet, the router creates all dynamic layers above the ATM 1483 layer, starting with the lowest dynamic layer. For example, in the case of a dynamic PPPoE interface, the router creates the PPPoE interface first, then the PPP interface, and then the IP interface.

If any layer of the dynamic portion of the interface column fails to be created, then the interface creation fails and the connection is denied. All dynamic layers above the ATM 1483 subinterface are destroyed, starting with the highest dynamic layer.

When you configure a dynamic interface, you must assign (or create and assign) a profile to the interface. Profile creation and assignment topics are discussed in depth in Configuring a Dynamic Interface from a Profile .

About Configuring RADIUS for Dynamic Interfaces

Dynamic interfaces can be configured automatically through authentication and authorization by the RADIUS server.

On ATM interfaces, you initially create the static portion of the interface column by creating an ATM interface, ATM 1483 subinterface, and underlying ATM permanent virtual circuit (PVC).

subscriber Command

For dynamic interfaces that do not have a PPP layer, such as IPoA, you can use the subscriber command to configure an ATM 1483 subinterface to be authenticated automatically by the RADIUS server. The subscriber command uses a RADIUS username and optional password for identification and is available only for bridged Ethernet and IPoA configurations. This command is used for dynamic encapsulations that do not provide the authentication information remotely, as PPP does.

For dynamic interfaces with a PPP layer, the RADIUS username and password are obtained from the remote client, and authentication is performed with the RADIUS server. The attributes obtained from RADIUS can then be used to configure any higher-layer dynamic interfaces, such as IP, that are built over PPP.

For more information about using the subscriber command, see subscriber.

Authenticating Subscribers on Dynamic Bridged Ethernet over Static ATM Interfaces

You can use either of the following methods to configure and manage RADIUS authentication for IP subscribers on dynamic bridged Ethernet over static ATM interfaces:

The subscriber command
The subscriber management application

The subscriber command does not support running stateful SRP switchover (high availability) on the router. Therefore, the configuration method you choose depends on whether stateful SRP switchover is or is not running on your router.

Configuration Method Using subscriber Command

When you use the subscriber command to configure IP subscribers on dynamic bridged Ethernet over static ATM 1483 interface columns to support RADIUS authentication, the subscriber command provides the subscriber’s authentication parameters. The static ATM 1483 subinterface acts as the authenticating layer that establishes a session with RADIUS and passes the subscriber’s locally configured username and password information to the RADIUS server.

However, if your router is running stateful SRP switchover (high availability), the use of the subscriber command in this configuration might suspend stateful SRP switchover on the router or prevent stateful SRP switchover from becoming active. To bypass this limitation, you can use the subscriber management application to configure IP subscribers on dynamic bridged Ethernet interfaces.

Configuration Method Using Subscriber Management Application

You can use the JunosE subscriber management application to configure and manage IP subscribers associated with a dynamic bridged Ethernet interface column. The subscriber management application uses an IP service profile to manage and authenticate IP subscribers with RADIUS. An IP service profile contains user and password information, and is used in a route map for subscriber management and to authenticate subscribers with RADIUS.

In this configuration, the IP service profile provides the subscriber’s authentication parameters, and the subscriber management application acts as the authenticating layer to obtain information from RADIUS for configuration of dynamic IP subscribers. To assign the IP service profile to the interface profile from which the dynamic bridged Ethernet interface is created, you use the bridge1483 service-profile command in Profile Configuration mode.

If stateful SRP switchover is disabled or not running on your router, you can continue to use the subscriber command to configure IP subscribers on dynamic bridged Ethernet interfaces to support RADIUS authentication.

Alternatively, you can use the subscriber management application to create and configure dynamic IP interfaces regardless of whether stateful SRP switchover is running on the router. In addition, using subscriber management enables you to take advantage of several useful features such as the IP inactivity timer.

In the event that an interface profile for a dynamic bridged Ethernet interface includes the subscriber command to configure a local subscriber as well as the bridge1483 service-profile command to reference an IP service profile, the values specified with the subscriber command take precedence. The router ignores the values in the IP service profile in this case.

For details about using the subscriber management application to configure RADIUS authentication for IP subscribers on dynamic bridged Ethernet interfaces, see Configuring Subscriber Management for IP Subscribers on Dynamic Bridged Ethernet Interfaces.

For more information about using the subscriber management application, see JunosE Broadband Access Configuration Guide.

Placing Dynamic IP Routes in the Routing Table

If you want to insert a dynamic IP route into the routing table of the relevant virtual router to point to the subscriber’s subinterface, you can use the Framed-Route [22] RADIUS attribute to do so. Defined by RFC 2865—Remote Authentication Dial In User Service (RADIUS) (June 2000), the Framed-Route attribute can be returned in Access-Accept messages to specify the route as follows:

Framed-Route = ipAddress/mask nextHop

For dynamic IP interfaces, the next hop might not be known when you create the user record. In this case, use the value 0.0.0.0 for the next hop; the E Series router then assigns the subinterface associated with the user as the next hop in the routing table.

auto-configure Command

You use the auto-configure command to configure an ATM 1483 subinterface to support a dynamic interface. After the subinterface is configured, it performs autodetection to identify the encapsulation, resulting in the dynamic creation of the higher protocol layers. This command specifies one or more types of next upper dynamic encapsulations that the static interfaces can detect or accept.

Note: On static ATM 1483 interfaces, dynamic encapsulation types can be bridged Ethernet, IP, IPv6, PPP, or PPPoE.

Encapsulation Type Lockout

You can configure E Series routers to support dynamic encapsulation type lockout. With this feature, you can temporarily prevent an ATM 1483 subinterface from autodetecting, accepting, and creating dynamic interface columns for a configurable time period.

On ATM 1483 subinterfaces, encapsulation type lockout is the default behavior for IPoA, bridged Ethernet, PPP, and PPPoE encapsulation types.

Benefits

Using dynamic encapsulation type lockout provides the following benefits:

Enables autodetection of other encapsulation types when a dynamic interface for a specified encapsulation type cannot be created.
For example, when running a PPPoE client, DSL modems might transmit bridged Ethernet frames among the PPPoE frames. When bridged Ethernet and PPPoE encapsulation types are configured for autodetection with the auto-configure command, and a subscriber is configured for the bridged Ethernet encapsulation type, RADIUS sends a deny response after the router attempts to authenticate a received bridged Ethernet frame. Receiving an authentication denial from RADIUS causes the router to lock out bridged Ethernet. By locking out bridged Ethernet frames, the router can receive PPPoE frames unimpeded, facilitating rapid creation of dynamic PPPoE interfaces.
Reduces loading on the RADIUS server.
In some cases, IP and bridged Ethernet interfaces configured with a local subscriber do not have a corresponding subscriber entry in the RADIUS database. This can occur inadvertently due to misconfiguration of the E Series router or RADIUS server, or intentionally as a way to prevent creation of dynamic IPoA or bridged Ethernet interfaces.
In previous releases, when the ATM 1483 interface received a deny response from RADIUS due to the missing subscriber entry, it performed continuous authentication retries every few seconds, which caused significant loading on the RADIUS server. Locking out autodetection of the IP or bridged Ethernet encapsulation type for a configurable time period prevents detection of dynamic IPoA or bridged Ethernet interfaces and reduces loading on the RADIUS server.
For PPP and PPPoE encapsulation types, incorrect logins coupled with clients configured to perform frequent authentication retries results in significant loading on the RADIUS server. When an incorrect login occurs, the process of autodetecting, creating partial dynamic interface columns, and tearing down the columns due to authentication failures consumes router bandwidth. Enabling temporary lockout of PPP and PPPoE encapsulation types reduces loading on the RADIUS server caused by incorrect logins and auto-retry clients.
Reduces loading on line modules.
The repeated creation of multiple short-cycle dynamic interfaces causes excessive loading on line modules. A short-cycle dynamic interface is one that is detected, partially or completely created, and torn down within 60 seconds.
Events that can cause short-cycle dynamic interfaces include:
- Authentication denials from RADIUS due to the absence of a corresponding entry in the RADIUS database or due to improper login attempts
- Misconfiguration within a dynamic interface profile or RADIUS record
- Insufficient memory resources to create a dynamic interface column
- Protocol failure or error that occurs within a dynamic interface column
- Client logout shortly after a successful login; this action creates a complete dynamic interface column before the column is torn down

How Encapsulation Type Lockout Works

For a given encapsulation type, such as bridged Ethernet, lockout occurs when a dynamic interface of this type cannot be created. For example, an authentication denial from RADIUS causes a lockout. When lockout occurs, the router applies the lockout time range. If you do not configure a lockout-time range, the router uses the default time range.

Encapsulation type lockout is performed by default. You can configure the lockout time range by issuing the auto-configure command with the optional lockout-time keyword.

The following guidelines describe lockout behavior:

Any encapsulation type that you do not configure for autodetection with the auto-configure command is automatically locked out.
You can permanently lock out a specified encapsulation type from autodetection and prevent dynamic interface creation by issuing a no auto-configure command for the specified encapsulation type, if previously configured.
When an encapsulation type is locked out, the router continues to autodetect the remaining encapsulation types and create the dynamic interfaces.

For the IP and bridged Ethernet encapsulation types, temporary lockout occurs automatically on receipt of an authentication deny response from RADIUS when you attempt to create and configure a dynamic IPoA or dynamic bridged Ethernet interface.

The lockout time range comprises two values: a minimum lockout time and a maximum lockout time. The initial lockout time begins with the minimum lockout time. From this point, the lockout time increases exponentially for every successive lockout event within the greater of 15 minutes or the maximum configured lockout time. The lockout time never exceeds the maximum value of the time range.

For example, using the default lockout time range of 1–300 seconds, the increasing lockout time sequence is: 1 second, 2 seconds, 4 seconds, 8 seconds, 16 seconds, 32 seconds, 64 seconds, 128 seconds, 256 seconds, and finally, 300 seconds (5 minutes).

Encapsulation Type Lockout Based on DSL Forum VSAs for IWF PPPoE Sessions

JunosE Software supports the dynamic encapsulation type lockout functionality for PPPoE sessions that contain the IWF-Session DSL Forum VSA (26-254) in the PPPoE active discovery request (PADR) packets. For interworking function (IWF) sessions that involve a set of functions to be processed to interconnect two networks of different technologies (such as PPPoE over ATM to PPPoE), the encapsulation type lockout for the PPPoE clients associated with the dynamic PPPoE subinterface column on the PPPoE major interface is determined using a combination of the Agent-Circuit-Id (26-1) and Agent-Remote-Id (26-2) DSL Forum VSAs, in addition to the MAC address.

The DSL Forum VSAs used in the encapsulation type lockout process for IWF PPPoE sessions comprise Agent-Circuit-Id (26-1) and Agent-Remote-Id (26-2). The Agent-Circuit-Id VSA is the identifier for the subscriber agent circuit that corresponds to the DSLAM interface from which subscriber requests are initiated. The Agent-Remote-Id VSA is the unique identifier for the subscriber associated with the DSLAM interface from which requests are initiated. For PPPoE sessions with the IWF-Session VSA, if you configured the pppoe auto-configure lockout-time command in Interface Configuration mode or Subinterface Configuration mode, the MAC address, Agent-Circuit-Id, and Agent-Remote-Id values are used together to identify a subscriber to implement PPPoE lockout.

If subscriber PPP sessions are transported on PPPoE, the PPPoE intermediate agent on the DSLAM adds the Agent-Circuit-Id and Agent-Remote-Id VSAs to the PPPoE PADI and PADR packets. The PPPoE implementation technique captures both the Agent-Circuit-Id and the Agent-Remote-Id sub-options from every PADR packet for every PPPoE session. Dynamic encapsulation type lockout is enabled by default for all IWF PPPoE sessions.

Guidelines for Configuring Encapsulation Type Lockout for PPPoE sessions

The following rules apply when you configure the lockout time for dynamic encapsulation type lockout:

The lockout time value is defined as
(minimum lockout time) * (2 ^ n-1)
where n represents the number of consecutive lockout events.
The router increments the value of n when the time between lockout events is either within 15 minutes or the maximum lockout time, whichever is greater.
When the time between lockout events is greater than either 15 minutes or the maximum lockout time, the value of n reverts to 1. This condition is referred to as a grace period.
The lockout time never exceeds the maximum configured lockout time. For example, for a configured lockout time in the range 20–120 seconds, the increasing lockout time sequence is 20 seconds, 40 seconds, 80 seconds, and finally, 120 seconds.

A short-cycle event is a dynamic interface that is created and torn down within 60 seconds. The router tracks the time between short-cycle events to determine whether to increase the lockout time for a subsequent short-cycle event.

Note: When the calculated lockout time is equal to or exceeds the maximum lockout time, the router uses the maximum lockout time value until the time to the next event exceeds the greater of 15 minutes or the maximum lockout time value. At that point, the lockout time reverts to the minimum lockout time value.

The minimum lockout time value cannot exceed the maximum lockout time value. When the minimum and maximum values are equal, the encapsulation type lockout time becomes fixed.

Guidelines for Configuring Encapsulation Type Lockout for IWF PPPoE Sessions

Keep the following points in mind while configuring dynamic encapsulation type lockout for IWF PPPoE sessions:

If the digital subscriber line access multiplexer (DSLAM) network does not add the DSL Forum VSAs (Agent-Circuit-Id and Agent-Remote-Id) that are required to accurately and uniquely identify the subscriber access loop, dynamic encapsulation type lockout for PPPoE clients is performed using MAC address as the only criterion to identify subscribers.
In such conditions, the mode of working of encapsulation type lockout for PPPoE clients is the same as the behavior that existed when lockout of PPPoE clients was performed using the MAC address of the client as the only matching parameter.
If the Agent-Circuit-Id DSL Forum VSA (26-1) is not contained in the PADR packet sent from the PPPoE client or is not unique for each IWF PPPoE session that originates from the client, the Agent-Remote-Id DSL VSA (26-2) is used along with the MAC address as the filter criteria to uniquely identify the subscriber session that needs to be locked out.
When you enter the pppoe auto-configure lockout-time command in Interface Configuration mode or Subinterface Configuration mode to configure dynamic encapsulation type lockout, even if PPPoE sessions associated with a particular MAC address are locked out, other PPPoE sessions that originated with the same MAC address are not terminated (continue to remain logged in) if they are IWF sessions from different access loops (PPPoE clients) and this information is available to the B-RAS application.

atm pvc Command

You use the atm pvc command to define the underlying circuit supporting an ATM 1483 subinterface. When you define a circuit with this command by using the aal5autoconfig option, it causes the ATM 1483 encapsulation (LLC/SNAP encapsulation or VC multiplexed) to be autodetected. Alternatively, if you use the aal5snap or aal5mux ip option, the ATM 1483 encapsulation becomes fixed, but higher layers can be dynamic.

For example, the following command configures a circuit for autodetection of the ATM 1483 encapsulation and all higher layers.

host1(config-subif)#atm pvc 100 0 100 aal5autoconfig 0 0 0

You can also include the atm pvc command in a base profile assigned to a dynamic ATM 1483 interface to apply encapsulation and traffic-shaping parameters to a bulk-configured range of PVCs. For information, see Configuring Dynamic Interfaces Using Bulk Configuration.