Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

RADIUS-Sourced Connection Status Updates to CPE Devices

 

Starting in Junos OS Release 20.2R1, you can use RADIUS-sourced messages to convey information that the BNG transparently forwards to a CPE device, such as a home gateway. For example, this information might be upstream bandwidth or some other connection rate parameter that the CPE device needs. This capability is useful when you want to dynamically enforce traffic management as close to subscribers as possible.

Ordinarily, you might use the RADIUS standard attribute Reply-Message (18) to convey this information to the CPE device during PPP authentication. However, if you are already using that attribute for something else, you can also use the Juniper Networks Connection-Status-Message VSA (26-4874–218). This VSA is a logical extension to the Reply-Message attribute (18) and has the same format and semantics.

PPP uses a Juniper Networks vendor-specific extension to LCP to send the contents of the Connection-Status-Message VSA to the peer home gateway. PPP includes this information in the Connection-Status-Message option of an LCP Connection-Update-Request message.

RADIUS can send the Connection-Status-Message VSA to authd in the following ways:

  • In the RADIUS Access-Accept message during negotiation and authorization of a PPP session

  • In a RADIUS CoA request at any time for an active PPP session

You might use both of these methods for any given session for business or residential subscribers. The Access-Accept message provides the initial connection parameters. The CoA capability enables you to update connection rate parameters as needed throughout the life of a session. The information carried in the Connection-Status-Message VSA is typically traffic rates that are applied by local configuration such as a dynamic service profile or the corresponding ANCP Port Up message.

Note

If you do not include the lcp-connection-update PPP option in the dynamic client profile, PPP processes the notification from authd, but takes no action. If LCP on the router is not in the Opened state, then PPP takes no action on the VSA.

The following steps describe what happens when RADIUS sends the VSA in an Access-Accept message:

  1. The authd process receives the Connection-Status-Message VSA in an Access-Accept message from the RADIUS server.

  2. The authd process sends the Connection-Status-Message VSA to PPP (jpppd).

  3. PPP NCP negotiation takes place between the remote gateway PPP client and PPP on the router.

  4. Successful negotiation results in a family activation request. The PPP session enters the Session Up state when the family is activated.

  5. If the dynamic client profile includes the lcp-connection-update PPP option and LCP on the router is in the Opened state, PPP sends an LCP Connection-Update-Request message to the gateway. This message includes the VSA information in the Connection-Status-Message option.

    • If the gateway supports the LCP Connection-Update-Request, it returns an LCP Connection-Update-Ack message to the router. The home gateway LCP must be in the Opened state when it receives the request, otherwise it discards the request.

    • If the gateway does not support the LCP Connection-Update-Request, it returns an LCP Code-Reject message to the router.

    Note

    If the gateway does not respond, the router retries the update request. It uses the PPP default values of up to a maximum of 10 retries with an interval of 3 seconds between the attempts.

    Note

    If you do not include the lcp-connection-update PPP option in the dynamic client profile, PPP processes the notification from authd, but takes no action. If the option is present but LCP on the router is not in the Opened state, PPP takes no action regarding the VSA.

The following steps describe what happens when RADIUS sends the VSA in a CoA request. This assumes that NCP negotiation was already successful and the session is active.

  1. The authd process receives the Connection-Status-Message VSA in a CoA request from the RADIUS server.

  2. The authd process sends the Connection-Status-Message VSA to PPP (jpppd).

  3. If the dynamic client profile includes the lcp-connection-update PPP option and LCP on the router is in the Opened state, PPP sends an LCP Connection-Update-Request message to the gateway. This message includes the VSA information in the Connection-Status-Message option.

    • If the gateway supports the LCP Connection-Update-Request, it returns an LCP Connection-Update-Ack message to the router. The home gateway LCP must be in the Opened state when it receives the request, otherwise it discards the request.

    • If the gateway does not support the LCP Connection-Update-Request, it returns an LCP Code-Reject message to the router.

    Note

    If the gateway does not respond, the router retries the update request. It uses the PPP default values of up to a maximum of 10 retries with an interval of 3 seconds between the attempts.

If the home gateway fails to receive a Connection-Update-Request message, the router retries sending the message. The router also retries the request when it does not receive either a Connection-Update-Ack or an LCP Code-Reject back from the gateway, or when something is wrong with the Ack message. The default retry interval is 3 seconds. The router will retry the message up to the default 10 times before it quits. If the router exhausts all the retry attempts without receiving an appropriate Connection-Update-Ack message, it logs the message as if it had received a PPP Code-Reject message.

Note

RADIUS can include multiple instances of the Connection-Status-Message VSA in either the Access-Accept message or a CoA request. If this occurs, authd uses only the first instance and ignores any others.

The Access-Accept or CoA requests might contain other attributes besides the Connection-Status-Message VSA, but there is no interdependency between the VSA and any other attributes. This is true even when the message includes the Activate-Service (26–65) or Deactivate-Service (26–66) VSAs. The lack of dependency means that even if authd does not successfully apply the other attributes, it still sends the connection info to PPP, which in turn sends the VSA contents to the home gateway.

Similarly, authd applies any other attributes and returns a CoA response regardless of whether PPP successfully communicates the content of the Connection-Status-Message VSA to the remote gateway. This is true even when the CoA contains only the Connection-Status-Message VSA. This capability is necessary because not all gateways will accept the LCP extension used in this feature.

Message and Option Formats

Figure 1 shows the format for Connection-Update-Request and Connection-Update-Ack messages. The formats are the same, but Table 1shows that some field values are different for the two messages.

Figure 1: Connection-Update-Request and Connection-Update-Ack Message Format
Connection-Update-Request
and Connection-Update-Ack Message Format

Table 1: Field Values for Connection-Update-Request and Connection-Update-Ack messages

Field

Connection-Update-Request

Connection-Update-Ack

Code

0 for vendor-specific

0 for vendor-specific

Identifier

Identifier for vendor-specific packet

Same identifier as in the Connection-Update-Request message. If this value does not match, the router logs the error and discards the packet. This enables the request message to be retried, just as if the gateway had not received it.

Length

Number of bytes in the packet: 12 plus the length of the Connection-Status-Message option

Number of bytes in the Connection-Update-Ack packet: 12

Magic Number

Negotiated value for the local PPP magic number

Negotiated value for the local PPP magic number

Organizationally Unique Identifier (OUI)

00-21-59 for Juniper Networks

00-21-59 for Juniper Networks

Kind

1 for Session-Update

2 for Session-Ack. For any other value, the router logs the error and the discards the packet. This enables the request message to be retried, just as if the gateway had not received it.

Values

Connection-Status-Message option in TLV format

No values are supported

You can configure how the PPP magic numbers are used.

  • If you configure ignore-magic-number-mismatch PPP option, you are preventing the magic numbers from being validated. PPP ignores a mismatch between the magic numbers in the request and Ack messages. If there are no other validation errors, PPP accepts the Connection-Update-Ack message.

  • If you do not configure ignore-magic-number-mismatch PPP option, the magic numbers go through validation. If the magic number in the Ack message does not match the gateway’s magic number established during LCP negotiation, the router logs the error and discards the Connection-Update-Ack message as an invalid response. This enables the request message to be retried, just as if the gateway had not received it.

See Preventing the Validation of PPP Magic Numbers During PPP Keepalive Exchanges for more information about magic numbers.

Figure 2 shows the format for the Connection-Status-Message options. Table 2 lists the field values.

Figure 2: Connection-Status-Message Option Format
Connection-Status-Message
Option Format

Table 2: Field Values for the Connection-Status-Message Option

Field

Value

Type

1

Length

Number of bytes in the option; 2 plus the length of the message. The message length can be from 1 through 247 bytes.

Status Message

Contents of the Connection-Status-Message VSA

Release History Table
Release
Description
Starting in Junos OS Release 20.2R1, you can use RADIUS-sourced messages to convey information that the BNG transparently forwards to a CPE device, such as a home gateway.