Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

RADIUS Attributes Used for Subscriber Secure Policy

Table 1 lists the RADIUS VSAs that are associated with subscriber secure policy. If these VSAs are present in the RADIUS Access-Accept message for a subscriber, the action specified in the LI-Action attribute takes effect.

Mirroring VSAs that the RADIUS server sends to the router are salt-encrypted. Salt encryption is a random string of data used to modify a password hash.

Table 1: RADIUS-Based Mirroring Attributes

Attribute Number

Attribute Name

Description

Value

[26-58]

LI-Action

Traffic mirroring action

Salt-encrypted integer

  • 0 = stop mirroring

  • 1 = start mirroring

  • 2 = no action

[26-59]

Med-Dev-Handle

Identifier that associates mirrored traffic with a specific subscriber

Med-Dev-Handle includes:

  • Intercept-Identifier

  • Acct-Session-ID (optional)

Salt-encrypted string

[26-60]

Med-Ip-Address

IP address of mediation device to which mirrored traffic is forwarded

Salt-encrypted IP address

[26-61]

Med-Port-Number

UDP port in the mediation device to which mirrored traffic is forwarded

Salt-encrypted integer
Note:

CoA-Request messages that include any of the RADIUS-based mirroring attributes (VSAs 26-58, 26-59, 26-60, or 26-61) must always include all four VSAs. If the CoA action is to stop mirroring (VSA 26-58 value is 0), then the values of the other three attributes in the CoA message must match the existing attribute values; otherwise, the action fails.

If a subscriber is already logged in, Table 2 lists the RADIUS attributes that can be present in RADIUS CoA messages to identify the subscriber whose traffic is to have a mirroring action applied (activation or deactivation).

Table 2: RADIUS Attributes Used in CoA Messages to Identify Subscribers for Traffic Mirroring

Attribute Number

Attribute Name

[1]

User-Name

[44]

Acct-Session-ID

Triggering Subscriber Secure Policy for Subscribers on Dynamic Authenticated VLANs

Best Practice:

When you have DHCPv4/DHCPv6 subscribers over VLANs, two sessions are created for each subscriber—one for the Layer 2 VLAN, and one for DHCP. In this case, we recommend that you use one trigger that matches both the DHCP and the VLAN session.

If authentication is performed on both the VLAN session and the DHCP session, we recommend that you use a separate, unique username for the VLAN and DHCP sessions to allow RADIUS to distinguish on which of the sessions to trigger subscriber secure policy traffic mirroring. Otherwise, traffic mirroring fails when the DHCP session is authenticated and activated.

Related Documentation