ON THIS PAGE
Instantiation of an ANCP-Triggered, Autosensed, Dynamic VLAN
Weighted Load Balancing for Subscriber Sessions over Eligible Core-Facing Physical Interfaces
Interactions Between In-Band and Out-of-Band VLAN Autosensing
Migration of Subscriber Ownership from Wholesaler to Retailer
Migration of Subscriber Ownership from Retailer to Wholesaler
Modification of the Access Line Identifier or Port VLAN Identifier
Disconnecting PPPoE Sessions and Automatically Attempting Reconnection as Layer 2 Wholesale Sessions
Consequences of a State Transition in the Access-Facing Physical Interface
Consequences of a State Transition from Up to Down in the Core-Facing Physical Interface
Consequences of a State Transition from Down to Up in the Core-Facing Physical Interface
Layer 2 Wholesale with ANCP-Triggered VLANs Overview
The conventional mechanism for triggering autosensed dynamic VLANs relies on access line attributes provided by PPPoE or DHCP traffic in upstream control packets. Packets of a specified type are exceptioned and authorization depends on fields extracted from the packet as specified in a dynamic profile assigned to the autosensed VLAN range. However, for some wholesale networks, the traffic might not be PPPoE or DHCP. In this case, a different mechanism is required.
Figure 1 shows a sample topology with direct connections between the wholesaler’s BNG and the NSP (network service provider) routers for the retailers. Each retailer’s network resides in a dedicated routing instance. The wholesaler uses Layer 2 cross-connects to implement the retail networks with 1:1 autosensed, dynamic VLANs and VLAN tag swapping. Core-facing physical interfaces are dedicated to forwarding subscriber connections to the retailer’s router. The traffic for an entire outer VLAN can be wholesaled this way. This direct-connect model supports any combination of wholesaler-owned and wholesaled connections for the entire access-facing VLAN range.
A wholesaler providing Layer 2 bitstream access to NSP partners might use this model. Bitstream access enables retailers to offer bidirectional transmission of broadband data and other high-speed services directly to customers across the wholesaler’s network. In this topology, the PPPoE residential and subscriber customers are retained by the wholesaler (access provider). The non-PPPoE connections (here multiple connections and subscribers are represented by a single line) can be wholesaled to retail NSPs.
In this model, dynamic VLAN detection and creation for the wholesaled connections do not use in-band control packets. Instead, they rely on an out-of-band protocol, ANCP. ANCP Port Up messages both announce to the ANCP agent on the BNG that new access lines are operational and provide updates about previously announced lines. The messages include ANCP DSL attributes that correspond to Juniper Networks DSL VSAs and DSL Forum VSAs.
Starting in Junos OS Release 16.1R4, you can configure the ANCP agent to trigger the creation of an autosensed VLAN when the ANCP agent receives a Port Up message where the DSL-Line-State attribute has a value of Showtime. The Showtime state indicates that ports are configured, the subscriber is connected, and the DSL modem is online and ready to transfer data. The other possible values of the attribute, Idle and Silent, are ignored for this purpose and are used by the ANCP agent only to update the ANCP session database (SDB).
During VLAN authorization, RADIUS determines which traffic belongs to the access provider’s own subscribers and which belongs to the wholesale customer (retail NSP) based on identification of the subscriber’s access line by the agent remote identifier.
When the ANCP agent receives the Port Up message, the agent triggers the autoconfiguration daemon, autoconfd, to initiate the VLAN detection, authorization, and creation processes. Those processes require the following information:
Three ANCP subscriber access loop attributes (TLVs) that identify the access line and are conveyed in the Port Up message:
Access-Loop-Circuit-ID—Access loop circuit identifier used by the ANCP agent to determine which logical interface or interface set corresponds to the subscriber; corresponds to the Juniper Networks Acc-Loop-Cir-ID VSA (26-110).
Access-Loop-Remote-ID—Unique identifier of the access line; corresponds to the Juniper Networks Acc-Loop-Remote-ID VSA (26-182).
Access-Aggregation-Circuit-ID-Binary—Identifier that represents the outer VLAN tag that the access node inserts on upstream traffic; corresponds to the Juniper Networks Acc-Aggr-Cir-Id-Bin VSA (26-111).
The name of the physical interface facing the subscriber. This name derives from the local mapping of an ANCP neighbor to the corresponding subscriber-facing access port.
The Access-Aggregation-Circuit-ID-Binary attribute and the access-facing interface name together provide information equivalent to that used for conventional autosensed VLAN detection.
ANCP Port Down messages indicate that the subscriber access loop is not present or at least is no longer operational. This message triggers the automatic destruction of the dynamic VLAN, regardless of the value of any other ANCP line attribute.
VLAN logical interfaces are created in the default routing-instance unless a nondefault routing instance is provided by local authorization (domain map) or external authorization (RADIUS). Multiple routing instances are required when both access-provider-owned and wholesaled connections are supported at the same time. One routing instance is required for the access provider’s own subscribers. An additional routing instance is required for each retail NSP. Consequently, the routing-instance has to be specified when the VLAN is authorized. The RADIUS-based VLAN authorization process determines whether the subscriber access-loop identified by the attributes in the Port Up message is wholesaled to a partner NSP—and therefore maintained as a unique routing-instance—or managed as a subscriber owned by the access provider.
RADIUS Authorization for ANCP-Triggered VLANs
When a subscriber logs in, the Access-Request message that is sent to the RADIUS server includes a username and optionally a password generated locally on the router. You can configure the router to create a unique username with the value of ANCP TLVs— Access-Loop-Circuit-ID, Access-Loop-Remote-Id, or both—as received in the ANCP Port Up message from the access node. Alternatively, if you configure the router to convey ANCP-sourced access loop attributes as Juniper Networks VSAs—in this case Acc-Loop-Cir-Id (26-110) and Acc-Loop-Remote-Id (26-182)—then the Access-Request message includes sufficient unique access line information for the RADIUS server to determine whether the access loop is wholesaled to a retailer or retained for the wholesaler.
The RADIUS server responds to the Access-Request with one of the following messages:
Access-Accept—In this case, the VLAN triggered by the Port Up message is wholesaled to a retail NSP. Authorization is similar to that for PPPoE sessions. The Access-Accept includes the Virtual-Router VSA (26-1) with a value that corresponds to the NSP’s unique, nondefault routing instance. The message can optionally include client services, such as attributes for parameterized CoS, firewall filters and policies for the logical interface, and Layer 2 service activations.
Access-Reject—In this case, either the VLAN triggered by the Port Up message is one of the wholesaler’s own subscribers or RADIUS refuses to grant access to the network. In either case, the VLAN entry is removed from the ANCP SDB. Unless a Port Down message is received first, the router ignores subsequent Port Up messages for this subscriber. However, conventional dynamic stacked VLAN autosensing may be initiated by access protocol negotiation, such as PPPoE.
Instantiation of an ANCP-Triggered, Autosensed, Dynamic VLAN
When the RADIUS server returns an Access-Accept message, the dynamic profile assigned to the autosensed VLAN range is instantiated with the following results:
The dynamic VLAN logical interface that represents the Layer 2 wholesale service within the NSP’s unique routing instance is created.
A core-facing physical interface is selected by a weighted load distribution method from the set of eligible interfaces assigned to the NSP’s routing instance. A physical interface is eligible when it is operationally up and has at least one VLAN tag that is available for assignment.
The access-facing, autosensed outer VLAN tag is mapped to a unique inner VLAN tag. The outer VLAN tag is derived from the Access-Aggregation-Circuit-ID-Binary TLV carried in the ANCP Port Up message. The inner VLAN tag is allocated from the VLAN range configured for the core-facing physical interface.
The inner VLAN tag is swapped with (replaces) the outer VLAN tag when the subscriber traffic is tunneled to the NSP. In the dynamic profile, the inner VLAN tag is provided by the predefined variable,
$junos-inner-vlan-map-id
.The autosensed outer VLAN tag is swapped with the inner VLAN tag when downstream packets from the NSP (which include the allocated inner VLAN tag) are forwarded to the subscriber.
You can configure each core-facing physical interface with a range of up to 4094 VLAN IDs. The inner VLAN swap range is assigned to the physical interface locally. This means that inner VLAN ranges for different physical interfaces can overlap each other completely, partially, or not at all.
Optionally, before the subscriber packets are forwarded to an NSP, the outer VLAN tag protocol identifier (TPID) in the subscriber packets can be swapped with a TPID to meet the requirements of an individual NSP. In this case, the original value is swapped with the NSP TPID for packets forwarded to the subscriber.
An additional VLAN tag, the Trunk VLAN ID, is used internally to identify the provisioned core-facing physical interface so that the subscriber traffic can be tunneled to the allocated interface. In the dynamic profile, this ID is provided by the predefined variable,
$junos-vlan-map-id
. This identifier differentiates among multiple core-facing trunk physical interfaces for the same NSP.Any client services, such as CoS or firewall filters, are applied to the subscriber session. These services are optionally specified in the RADIUS configuration and conveyed in the RADIUS message as Juniper Networks VSAs.
The VLAN session is activated after the logical interface is created and configured for the dynamic VLAN session. Session activation initiates a RADIUS Accounting-Start message. Any services that were received from RADIUS during authorization are now activated.
After the dynamic VLAN has been created, subsequent ANCP Port Up messages do not cause a re-authorization of the dynamic VLAN session. Instead, when the ANCP agent receives another Port Up message for the access loop, it updates the ANCP SDB with any changes in ANCP attributes.
Weighted Load Balancing for Subscriber Sessions over Eligible Core-Facing Physical Interfaces
Tthe router uses weighted load distribution instead of round-robin distribution to assign Layer 2 wholesale subscriber sessions across multiple core-facing physical interfaces according to the weight of the interface. The weight of an interface correlates with the number of VLAN tags available from the aggregate inner (core-facing) VLAN ID swap ranges on the interface.
How you configure the inner VLAN ID swap ranges determines the relative weights of the interfaces:
The interface with the highest number of available inner VLAN ID tags has the highest weight.
The interface with the next-highest number of tags has the next-highest weight, and so on.
The interface with the lowest number of available tags has the lowest weight.
Using the available inner VLAN ID tags from the swap ranges rather than the aggregate total VLAN tags means that the relative weights of the interfaces are more dynamic. The weighted load distribution mechanism can respond more quickly to subscriber logouts, migration of subscriber ownership from wholesaler to retailer and retailer to wholesaler, core-facing physical interface state transitions (including movement to the remaining eligible core-facing interfaces when an interface state transitions from Up to Down), and failures of any of the core-facing physical interfaces. When an interface recovers (transitions from Down to Up), weighted load distribution generally favors this interface for either pending sessions or for new Layer 2 wholesale sessions that subsequently occur.
Core-facing physical interface selection and session distribution are probability based; the load is not strictly distributed according to weight.
With weighted load distribution the router selects interfaces randomly, but the sessions are distributed across interfaces proportionally in relationship to the weight of the interfaces. The router generates a random number within a range equal to the aggregate total of all available inner VLAN ID tags from the swap ranges of all the core-facing physical interfaces. The router then associates part of the range—a pool of numbers—with each interface proportional to the interface’s weight. An interface with a higher weight is associated with a greater portion of the range—a larger pool—than an interface with a lower weight. An interface is selected when the random number is in its associated pool of numbers. The random number is more likely, on average, to be in a larger pool, so an interface with a higher weight (larger pool) is more likely to be selected than an interface with a lower weight (smaller pool).
For example, consider two core-facing physical interfaces, IFD1 and IFD2. Based on the inner VLAN ID swap ranges configured for these two interfaces, IFD1 has 1000 available VLAN tags and IFD2 has only 500 available tags. The subscriber sessions are randomly distributed across the two interfaces based on their relative weights; IFD1 has a higher weight than IFD2. Because IFD1 has twice as many available tags as IFD2, the pool of numbers associated with IFD1 is also twice as many as for IFD2. The random number generated by the router is twice as likely to be in the pool for IFD1 than for IFD2. Consequently, IFD1 is favored 2:1 over IFD2, and subscriber sessions are twice as likely to be assigned to IFD1 as IFD2.
RADIUS Interim Accounting Updates
Interim accounting reports sent to AAA for out-of-band triggered, autosensed dynamic VLANs are supported in the same manner as for conventional autosensed, dynamic, authorized VLANs or client sessions (such as PPPoE sessions). The ANCP agent sends a notification to AAA when it receives an update from the access node. By default, AAA only reports the update to the RADIUS server at the configured interval.
You can configure the ANCP agent so that when it notifies AAA, an interim update Accounting-Request message is immediately sent to the RADIUS server. Immediate interim accounting updates can be sent for an ANCP-triggered dynamic VLAN session only when a change occurs in certain key ANCP attributes for the associated access line that can influence system behavior. To prevent an additional load on the RADIUS server for changes to less critical ANCP attributes, changes to any other ANCP attributes do not trigger immediate accounting-interim-update messages. Instead, those changes are reported in the next scheduled Accounting-Interim-Update message.
Immediate interim accounting updates can be sent for changes to any of the following ANCP attributes for an existing session that corresponds to the access line (based on the Access-Loop-Circuit-ID TLV):
Actual-Net-Data-Rate-Upstream—When the calculated (adjusted) upstream rate results in a change to this attribute, the accounting message reports the attribute in the Juniper Networks Act-Data-Rate-Up VSA (26-113). The calculated speed change is reported in the Upstream-Calculated-QoS-Rate VSA (26-142).
Actual-Net-Data-Rate-Downstream—When the calculated (adjusted) downstream rate results in a change to this attribute , the accounting message reports the attribute in the Juniper Networks Act-Data-Rate-Dn VSA (26-114). The calculated speed change is reported in the Downstream-Calculated-QoS-Rate VSA (26-141).
When the ancp-speed-change-immediate-update
statement
is configured at the [edit access profile profile-name accounting]
hierarchy level, RADIUS immediate interim accounting
updates are sent for changes to the Actual-Net-Data-Rate-Upstream
and Actual-Net-Data-Rate-Downstream TLVs.
When in addition the auto-configure-trigger interface interface-name
statement is configured at the [edit protocols ancp neighbor ip-address]
hierarchy level, immediate interim accounting updates are
also sent for changes to the Access-Loop-Remote-ID and Access-Aggregation-Circuit-ID-Binary
TLVs.
For more information about RADIUS immediate interim accounting updates, see Configuring Immediate Interim Accounting Updates to RADIUS in Response to ANCP Notifications.
Removal of the Layer 2 Wholesale Service
Any of the following events can remove the logical interface for the dynamic VLAN that represents the access service provided by the Layer 2 wholesaler:
The receipt of an ANCP Port Down message for the corresponding access loop. The same ANCP attributes that initiate dynamic VLAN creation also initiate dynamic VLAN destruction.
No action is taken for an ANCP Port Down message for which any of the following is true:
No corresponding subscriber session exists.
A corresponding subscriber session is present, but is in the process of being deleted.
The message refers to a conventional autosensed session (which is removed by normal protocol processing).
An explicit reset of the connection between the ANCP agent and the access node, which triggers a mass logout of all affected dynamic VLAN sessions that support the wholesaled Layer 2 access connections. Sessions for the wholesaler’s own subscribers are not affected.
The deletion or transition to an operational down state of the subscriber-facing physical interface or the core-facing physical interface.
The loss of adjacency between the neighbor and the ANCP agent.
The issuance of the
clear auto-configuration interfaces
command to log out the VLAN or theclear ancp access-loop
command to force a subscriber reset.The receipt of a RADIUS-initiated disconnect message.
Any of these events also deactivates the subscriber session to prevent future service activations and issues a RADIUS Accounting-Stop message for related services and for the dynamic VLAN subscriber session. The dynamic profile is then de-instantiated to remove first the dynamic VLAN logical interface and then the corresponding session entry in the VLAN SDB.
You can monitor the number of Layer 2 cross-connected subscriber
sessions per port. Use the show subscribers summary port extensive
command to display the number of subscribers per port by client
type (VLAN-OOB) and connection type (Corss-connected). Additionally,
the object ID jnxSubscriberPortL2CrossConnectCounter in the jnxSubscriberPortCountTable
in the Juniper Networks enterprise-specific Subscriber MIB displays
the number of Layer 2 cross-connected subscriber sessions on ports
that have active sessions.
Interactions Between In-Band and Out-of-Band VLAN Autosensing
The ANCP-triggered Layer 2 wholesale implementation accommodates both subscribers wholesaled to a retailer and subscribers belonging to the wholesaler. Any subscriber session detected on the access-facing physical interface can be one or the other. This means that an overlap exists between the outer tag range for the out-of-band autosensed VLANs and that for in-band, autosensed, stacked VLANs.
Both a PPPoE session and a wholesaled session might be attempted for the same access loop. To avoid the undesirable load on the router and the RADIUS server that can ensue when that happens, the order of session negotiation is determined by the order in which packets (PPPoE PADI or ANCP Port Up message) are received for the same access-facing physical interface and VLAN outer tag.
The following sequences assume that the remove-when-no-subscribers
statement is included at the [edit interfaces interface-name auto-configure]
hierarchy level for the access-facing physical
interface.
The following sequence of events occurs when a PPPoE PADI packet is received on an in-band control channel before an ANCP Port Up message is received on an out-of-band control channel, for the same access loop:
The PADI receipt triggers creation of a dynamic stacked VLAN logical interface. PPPoE and PPP negotiation are in progress.
The ANCP Port-Up message is received for the access loop. Because the corresponding in-band VLAN logical interface already exists for the same access-facing physical interface and outer VLAN tag, the ANCP agent simply stores the ANCP access line attributes and the name of the physical interface in the session database. The agent takes no other action for the message as long as the PPP session (PPP logical interface and the underlying dynamic VLAN logical interface) is maintained.
PPP negotiation terminates due to authentication failure (RADIUS Access-Reject response) or a normal logout, which triggers clean-up of the PPP session and removal of the PPP logical interface.
Because the
remove-when-no-subscribers
statement is configured. deletion of the PPP logical interface results in deletion of the dynamic stacked VLAN.The next event depends on whether authorization of the ANCP Port Up message has been attempted before.
If authorization was not previously attempted:
A VLAN-OOB SDB session is created and authorization of the access-loop is initiated.
All exceptioned PPPoE PADI packets received by in-band VLAN auto-sensing are ignored until RADIUS responds to the authorization request.
The authorization result determines what happens next:
If the authorization succeeds (RADIUS returns an Access-Accept message), then a dynamic Layer 2 wholesale logical interface is created within the retailer NSP’s routing-instance.
If the authorization fails (RADIUS returns an Access-Reject message), then the VLAN-OOB session is cleaned up. Processing resumes for any exceptioned PPPoE PADI packets that are subsequently received by in-band VLAN autosensing.
If authorization was previously attempted, then no action is taken because the failure of the PPP session negotiation is assumed to be a login failure outside the Layer2 wholesale context. This behavior prevents unnecessary authorization in response to the ANCP Port-Up message every time a PPPoE session terminates and cleans up from a normal subscriber logout.
The following sequence of events occurs when an ANCP Port Up message is received on an out-of-band control channel before a PPPoE PADI packet for an access loop is received on an in-band control channel, both for the same access loop:
Receipt of the ANCP Port Up message triggers authorization of the access loop.
A PPPoE PADI packet is received. The packet is ignored because authorization is already in progress for the same access-facing physical interface and outer VLAN tag.
The authorization result determines what happens next:
If authorization succeeds (RADIUS returns an Access-Accept message)—represented by a VLAN-OOB session in the SDB—then dynamic creation of the VLAN logical interface is initiated for a Layer 2 wholesale session. When the interface is created, subsequent PPPoE PADI packets detected by in-band VLAN autosensing are ignored and no longer exceptioned.
If authorization fails (RADIUS returns an Access-Reject message), the VLAN-OOB session is cleaned up.
Receipt of a subsequent PPPoE PADI packet initiates creation of a dynamic stacked VLAN.
PPPoE and PPP negotiation takes place and events proceed as usual for a conventional, dynamic autosensed VLAN.
Migration of Subscriber Ownership from Wholesaler to Retailer
The wholesaler-owned subscribers are connected by means of dynamic PPPoE interfaces over dynamic VLANs. For each subscriber, the PPPoE session must be disconnected and the corresponding PPP logical interface deleted before ANCP Port Up messages for the same underlying physical interface and VLAN outer tag can serve as out-of-band triggers for dynamic VLAN autosensing.
One approach to migrating from wholesale to retail ownership is to do the following:
Update the RADIUS server database so that subscriber authentication for the relevant access lines results in a RADIUS Access-Reject response. This causes subsequent attempts to negotiate PPPoE for the access line to fail.
Initiate logout of the dynamic PPPoE sessions; for example, by issuing a RADIUS-initiated disconnect. This triggers cleanup of the PPPoE logical interface and associated services, which includes issuing RADIUS Accounting-Stop messages for the session and active services, as well as removing the dynamic PPPoE logical interface.
If the migration requires swapping out the current CPE device for another, and the PPPoE session is not otherwise gracefully logged out, then turning off the CPE results in a PPP keepalive failure on the router and triggers session logout.
Remove the underlying dynamic VLAN logical interface. This occurs automatically when the
remove-when-no-subscribers
statement is included at the[edit interfaces interface-name auto-configure]
hierarchy level for the access-facing physical interface. Otherwise, issue theclear auto-configuration interfaces interface-name
command to remove the dynamic VLAN logical interface.Trigger a Port Up notification to initiate dynamic VLAN detection, authorization, and creation by one of the following methods:
Power cycle the CPE, with a sufficient delay between turning off and turning back on the device so that a Port Down message is sent followed by a Port Up message and the router is given enough time to detect a keepalive failure indicating loss of the session.
Issue a
clear ancp access-loop
command.Issue a
request ancp oam port-up
command.
Migration of Subscriber Ownership from Retailer to Wholesaler
One approach to migrating from retail to wholesale ownership is to do the following:
Update the RADIUS server database so that dynamic VLAN authorization for the relevant access lines results in a RADIUS Access-Reject response. Doing this causes subsequent ANCP Port Up messages to be ignored.
Initiate logout of the dynamic VLAN sessions supporting the wholesale access service; for example, by issuing a RADIUS-initiated disconnect. Doing this triggers cleanup of the session, which includes issuing RADIUS Accounting-Stop messages for the session, removal of the dynamic VLAN logical interface and active services, and freeing the allocated inner VLAN tag associated with the core-facing physical interface for assignment to a different Layer 2 wholesale subscriber session.
If the migration requires swapping out the current CPE device for another, then turning off the CPE results in an ANCP Port Down message that triggers session logout and cleanup.
Allow subscribers to connect to the wholesaler’s network using conventional dynamic VLAN autosensing followed by PPPoE and PPP negotiation and creation of PPP logical interfaces.
Migration of Subscriber Ownership Between Retailers
Typically, you migrate access between NSP retailers by triggering a restart of the existing dynamic VLAN session. The restart initiates a logout from the session followed by immediate dynamic VLAN detection, authorization, and creation within the routing-instance corresponding to the new NSP. A restart is a logical Port Down and Port Up sequence for the VLAN’s corresponding access loop. You can use any of the following methods to restart a given dynamic VLAN logical interface:
Initiate a RADIUS Disconnect-Request message or configure your RADIUS server to send the message. The message must have the Acct-Terminate-Cause RADIUS attribute (49) set to a value of 16 (callback). This cause is processed as a disconnect (logout) followed immediately by a reconnect (login) only for dynamic VLANs created by an ANCP Port Up message. Other clients respond to this value with only a disconnect.
Include the
reconnect
option when you log out subscribers with theclear network-access aaa subscriber
command. You can specify subscribers by either the session identifier or the username. This option attempts to reconnect a cleared session as a Layer 2 wholesale session when the subscriber session has been fully logged out. This behavior is equivalent to issuing a RADIUS-initiated disconnect that is configured for reconnect; that is, when the message includes Acct-Terminate-Cause (RADIUS attribute 49) with a value of callback (16).Trigger a Port Down message followed by a Port UP message by one of the following methods:
Power cycle the CPE, with a sufficient delay between turning off and turning back on the device so that a Port Down message is sent followed by a Port Up message and the router is given enough time to detect a keepalive failure indicating loss of the session.
Issue a
clear ancp access-loop
command.
Modification of the Access Line Identifier or Port VLAN Identifier
When the line identifier or port VLAN identifier for an access loop is modified, the access node reports the change in a Port Up message to the ANCP agent. The message conveys the line ID in the Access-Loop-Remote-ID TLV and the port VLAN ID in the Access-Aggregation-Circuit-ID-Binary TLV.
The access node should send a Port Down message for the access loop before it modifies any of the identification attributes for an existing session. The Port Down message triggers clean up of the corresponding Layer 2 wholesale session. If the access node does not send a Port Down in this case, then the following behavior has the same effect as inserting the Port Down message that the access node failed to send:
For a line ID change, the ANCP agent treats the reconfiguration as a logical Port Down message for the access line identified by the previous Access-Loop-Remote-Id, followed by a Port Up message for the access line identified by the new Access-Loop-Remote-Id.
For a port VLAN ID change, the ANCP agent treats the reconfiguration as a logical Port Down message for the access line identified by the previous Access-Aggregation-Circuit-Id-Binary, followed by a Port Up message for the access line identified by the new Access-Aggregation-Circuit-Id-Binary.
In either case, the ANCP agent notifies the autoconfiguration daemon (autoconfd), which takes the following actions:
Logs out the corresponding Layer 2 wholesale session.
Sends a RADIUS Accounting-Stop message with the final statistics for the associated service sessions and client session.
Removes the dynamic VLAN logical interface.
Attempts to reestablish the Layer 2 wholesale session by means of a login sequence, including authentication, creation of the dynamic VLAN logical interface, activation of any services, and if successful, sending RADIUS Accounting-Start messages for the service and client sessions.
You must manually log out any PPPoE session corresponding to the access line with the previous identifiers, even if the access node sends the appropriate Port Down message when the values change.
In the case of a change in the port VLAN ID only, autoconfd
takes no action to reinitiate the session when a dynamic stacked VLAN
or a Layer 2 wholesale session exists with the same access-facing
physical interface and outer VLAN tag. You must manually intervene
in this case, such as by issuing a request ancp oam port-up
command to initiate the creation of the Layer 2 wholesale session.
Because an existing session is not automatically logged out, we recommend that the network operator disconnect the session—for example, by issuing a RADIUS Disconnect-Request message—before modifying any of the access line attributes. Depending on subsequent subscriber login and successful negotiation, a new session with the new identifier may then be created as usual.
Disconnecting PPPoE Sessions and Automatically Attempting Reconnection as Layer 2 Wholesale Sessions
You can use RADIUS-initiated disconnect messages to disconnect
and log out existing PPPoE sessions and attempt to reestablish them
as Layer 2 wholesale sessions. Use Access-Reject messages to prevent
PPPoE subscriber access and attempt a reconnect as a Layer 2 wholesale
session. Use this feature when you want to migrate sessions from PPPoE
to Layer 2 wholesale. Both the RADIUS-initiated disconnect and Access-Reject
message must include Acct-Terminate-Cause (RADIUS attribute 49) with
a value of callback (16); callback causes the reconnect attempt. The remove-when-no-subscribers
statement must be configured on
the underlying physical interface.
The initial behavior for the messages is the following:
Access-Reject message—When a PPPoE PADI is received and a new PPPoE session is requested, RADIUS responds to the Access-Request message with an Access-Reject message. The session is rejected, fully logged out, and the underlying dynamic VLAN logical interface is removed.
RADIUS-initiated disconnect message—When a RADIUS-initiated disconnect message is received for an existing PPPoE session, the dynamic PPPoE session is logged out and the underlying dynamic VLAN logical interface is removed.
The next action is the same for both messages:
If an ANCP Port Up message has been received for the corresponding access line, the router attempts to authorize the access line and create a dynamic Layer 2 wholesale VLAN logical interface in place of the underlying dynamic VLAN logical interface that was removed.
If a Port Up message has not been received, then this action is deferred until the message is received.
If a PPPoE PADI is received before an ANCP Port Up message, RADIUS responds to the Access-Request for a new PPPoE session with an Access-Reject message. The session is rejected, fully logged out, and the underlying dynamic VLAN logical interface is removed.
If the RADIUS-initiated disconnect or Access-Reject message is received for a non-PPPoE session, such as DHCP, the session is disconnected, but the reconnect request is ignored. No attempt is made to establish a Layer 2 wholesale session.
If the RADIUS-initiated disconnect does not include Acct-Terminate-Cause with a value of callback, PPPoE renegotiation after the disconnect can succeed, but if an ANCP Port Up message is received for the access line before a PPPoE session is established, then a Layer 2 wholesale session is attempted.
As an alternative to the RADIUS-initiated disconnect, you can
manually log out the PPPoE session with the clear network-access
aaa subscriber
command. Specify the subscriber by either username
or session ID. When you include the reconnect
option, it
attempts to reconnect thecleared session as a Layer 2 wholesale session
when the subscriber session has been fully logged out.
Consequences of a State Transition in the Access-Facing Physical Interface
The following behavior results when the access-facing physical interface state transitions from Up to Down:
Conventional in-band VLAN autosensing stops for the interface.
ANCP-sourced Port Up messages for the interface are ignored. Action on new or unprocessed Port Up messages is deferred until the interface transitions to the Up state. If the ANCP connection is in band with the subscriber traffic on the interface, then all ANCP traffic stops; if the outage lasts long enough, the ANCP adjacency is lost.
All Layer 2 wholesale sessions that are assigned to the interface are treated as if the ANCP agent received a Port Down message for the corresponding access line. Each session is subject to being logged out. Whether a session is logged out depends on the ANCP adjacency loss hold timer. The timer starts running when the ANCP agent detects the state transition to Down. The subscriber continues using the original session if all three of the following occur before the timer expires:
The physical interface comes back up.
The ANCP adjacency is restored.
A Port Up message is received on the interface.
Otherwise, autoconfd takes the following actions:
Logs out the session.
Sends a RADIUS Accounting-Stop message with the final statistics for the associated service sessions and client session.
Removes the dynamic VLAN logical interface.
These sessions can be reestablished when the physical interface recovers, unless an ANCP Port Down message is received.
The autoconfiguration daemon does not automatically delete dynamic, autosensed VLAN logical interfaces. The interfaces for the ANCP-triggered Layer 2 wholesale VLANs are maintained because the assumption is that an outage is short-lived. If the outage is not short-lived, then a subsequent Port Down message brings down the session and removes the interface.
For conventional autosensed dynamic VLANs, the interface is removed only when the
remove-when-no-subscribers
statement is configured on the access-facing physical interface and all references to the VLAN logical interface from a higher logical interface or session are removed. This mechanism does not apply to the ANCP-triggered Layer 2 wholesale VLANs because they do not have upper session references.
The following behavior results when the access-facing physical interface state transitions from Down to Up:
Conventional in-band VLAN autosensing resumes for the interface. PPPoE sessions owned by the access provider that were logged out due to the transition from Up to Down can renegotiate and undergo a full login sequence.
Appropriate actions are taken for all ANCP Port Up messages for the interface, including messages that were deferred because of the previous Down state for the interface. If the ANCP connection is in band with the subscriber traffic, then all ANCP traffic resumes.
Forwarding resumes for any dynamic, autosensed VLAN logical interfaces that were not deleted when the interface went down.
Deletion of an access-facing physical interface triggers logout and removal of all upper dynamic VLAN logical interfaces and their corresponding sessions.
Consequences of a State Transition from Up to Down in the Core-Facing Physical Interface
The following behavior results when the core-facing physical interface state transitions from Up to Down:
The core-facing physical interface is no longer eligible for assigning new or pending access lines in this routing instance as based on the original RADIUS authorization.
All Layer 2 wholesale sessions that are assigned to the interface are treated as if the ANCP agent received a Port Down/Port Up message sequence for the corresponding access line. Each session is subject to being logged out. Whether a session is logged out depends on the ANCP adjacency loss hold timer. The timer starts running when the ANCP agent detects the state transition to Down. The subscriber continues using the original session if all three of the following occur before the timer expires:
The physical interface comes back up.
The ANCP adjacency is restored.
A Port Up message is received on the interface.
Otherwise, autoconfd takes the following actions:
Logs out the session.
Removes the session entry from the SDB.
Sends a RADIUS Accounting-Stop message with the final statistics for the associated service sessions and client session.
Removes the dynamic VLAN logical interface.
Next, autoconfd attempts to migrate the sessions to available connections on any remaining eligible core-facing physical interfaces that are assigned to the same routing instance:
The original request is placed on a retry queue.
A login sequence is attempted for each session, including authentication, creation of dynamic VLAN logical interfaces, activation of any services, and sending RADIUS Accounting-Start messages for the service and client sessions.
If the login sequence is successful, then the request is removed from the retry queue.
If the login fails, then the session is logged out, the session entry is removed from the SDB, and the corresponding access line is set to a pending state.
When the available connections are all used—when there are no more available VLAN tags from the configured inner VLAN ID swap ranges—as a result of successful reconnections, no attempt is made to connect any remaining Layer 2 wholesale sessions. Although authentication can succeed, the creation of dynamic VLAN logical interfaces fails during profile instantiation. In this case, the session is out, the session entry is removed from the SDB, and the corresponding access line is set to a pending state.
The pending access lines that represent these non-migrated sessions can be reestablished if the interface recovers or if additional VLAN connections become available; for example, by a configuration change that either increases the inner VLAN ID swap range for one or more remaining core-facing physical interfaces or adds new core-facing physical interfaces. However, if the ANCP agent receives a Port Down message for a pending access line, the corresponding session is not reestablished.
You can use the show auto-configuration out-of-band pending
command to display a count of pending access lines per routing instance.
In addition to core-facing physical interface state transitions from Up to Down, these behaviors also apply in the following circumstances:
A core-facing physical interface is deleted.
More Layer 2 wholesale sessions are assigned to a routing instance than can be accommodated by the inner VLAN ID swap range configured on the interface assigned to the routing instance.
We recommend that you use aggregated Ethernet for the core-facing physical interfaces to provide link protection, bandwidth aggregation, or both.
Consequences of a State Transition from Down to Up in the Core-Facing Physical Interface
The following behavior results when the core-facing physical interface state transitions from Down to Up:
The physical interface is now eligible to assign new Layer 2 wholesale subscriber sessions.
The ANCP agent notifies the autoconfiguration daemon (autoconfd), which attempts to reestablish the Layer 2 wholesale sessions that correspond to pending access line by initiating a conventional login sequence. This sequence includes authentication, creation of dynamic VLAN logical interfaces, activation of any services, and sending RADIUS Accounting-Start messages for the service and client sessions.
Pending sessions continue to be reestablished until none are left or an error occurs, typically due to exhaustion of inner VLAN tags from the swap ranges on the interface. In the latter case, the sessions are logged out, the session entry is removed from the SDB, and the access line is set to a pending state.
You can use the show auto-configuration out-of-band pending
command to display a count of pending access lines per routing instance.
These behaviors also occur in the following cases:
Additional VLAN connection resources become available, by a configuration change that either increases the inner VLAN ID swap range for one or more remaining core-facing physical interfaces or adds new core-facing physical interfaces. The newly added physical interface must be in the Up state to assume any Layer 2 wholesale sessions.
A RADIUS-initiated disconnect is received for an existing Layer 2 wholesale session assigned to this routing instance is logged out (disconnect only). For a disconnect with a reconnect qualifier, the affected session is given preference to reconnect over pending access lines.
You issue the
request auto-configuration reconnect-pending
,clear ancp access-loop
, orrequest ancp oam port-up
command.
Loss of ANCP TCP Adjacency
The ANCP agent can lose its TCP adjacency with a neighbor in any of the following circumstances:
The access node renegotiates the connection; for example, as a result of losing synchronization. The renegotiation triggers the local state to change from established to not established. The state transitions back to established when the session is successfully renegotiated.
An end-of-file (EOF) message is received on the socket indicating the adjacency is closed. This can result when the ANCP configuration is deleted on the access node.
An adjacency keepalive failure occurs. When no response is received for three consecutive polls, the adjacency is declared to be lost.
The ANCP agent treats the loss of adjacency as if it has received a Port Down message for each access loop represented by the ANCP connection. The agent notifies autoconfd, which takes the following actions:
Logs out all Layer 2 wholesale sessions that were triggered by this ANCP connection.
Sends a RADIUS Accounting-Stop message with the final statistics for the associated service sessions and client session.
Removes the dynamic VLAN logical interface.
If the assigned access-facing or core-facing physical interface is in the Down state, any pending sessions that were triggered by this ANCP connection cannot be reestablished when the interface recovers to the Up state.
Dynamic, conventionally auto-sensed VLAN logical interfaces, such as those supporting PPPoE sessions, are not affected by the TCP adjacency loss.
If the adjacency is reestablished, the expected behavior is a complete replay of Port Down and Port Up messages for all associated configured access lines. The Layer 2 wholesale sessions for which the ANCP agent receives Port Up messages are reestablished.
You can mitigate the effects of short-term adjacency losses by configuring an adjacency loss hold time. The timer starts when adjacency is lost. Even though the adjacency is lost, established sessions are maintained while the timer runs unless a Port Down message is received for the corresponding access line.
Any access line that for which the ANCP agent has not received a Port Up message by the time the timer expires is treated as though the agent has received a Port Down message for the line. The ANCP Agent notifies autoconfd, which takes the following actions:
Logs out all Layer 2 wholesale sessions that correspond to the access line.
Sends a RADIUS Accounting-Stop message with the final statistics for the associated service sessions and client session.
Removes the dynamic VLAN logical interface.
Port Up messages received after the timer expires repopulate the SDB access line table and reestablish the Layer 2 wholesale sessions
The adjacency loss hold timer serves the following purposes:
Dampens the effect of adjacency loss of short duration thereby maintaining existing Layer 2 wholesale sessions.
Detects the removal of an access line configuration on the access node. For example, in some circumstances you may want to remove the configuration of an access line on a neighbor. You first disconnect the ANCP session between a neighbor and the BNG, remove the configuration on the neighbor, and then restore the ANCP connection with the BNG. The neighbor does not issue a Port Down message. if the adjacency-loss hold-timer is configured, the ANCP agent detects an access line for which it has not received a Port Up or Port Down message, and consequently triggers logout and removal of the corresponding Layer 2 wholesale session.
When you deactivate the ANCP protocol, the router does not perform a commit check to determine whether any ANCP or L2-BSA subscribers are present (active or inactive). Any subscribers that are active at the time of deactivation remain active.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.