Support Support Downloads Knowledge Base Apex Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[Subscriber Management] Sending CoA request for VRF subscriber when Radius server is not in VRF

0

0

Article ID: KB36589 KB Last Updated: 22 Mar 2021Version: 1.0
Summary:

This article explains the possibility of dynamically modification active sessions based on attributes using Change of Authorization (CoA) for the VRF subscribers, while CoA Request is coming from the Radius server which is not configured under VRF.

Symptoms:

When the Radius server is located in Global Routing Table (GRT) and the subscriber in Virtual Routing and Forwarding (VRF) table, CoA request will not succeed.

In the following example Radius server is getting CoA NAK from BNG:

root@bras-radius:/etc/radius$ echo "User-Name='aaaa.dd92.e442',ERX-Service-Activate:1='sWIFI(1024000)',ERX-Service-Timeout:1='6000'" | radclient -x 10.34.128.4:3799 coa testing123
Sending CoA-Request of id 79 to 10.34.128.4 port 3799
User-Name = "aaaa.dd92.e442"
ERX-Service-Activate:1 = "sWIFI(1024000)"
ERX-Service-Timeout:1 = 6000
rad_recv: CoA-NAK packet from host 10.34.128.4 port 3799, id=79, length=26
Error-Cause = Administratively-Prohibited <<<<<<

General-authentication-service traceoptions indicate the following error:

============ CoA/Disconnect Callback =================
 
Apr 12 14:15:37.542492 dyn_req_disconnect_cb attributes remote_addr:(10.34.131.52) remote_port:(36728), rtbl_idx:(0)
Apr 12 14:15:37.542507 authd_extract_identifier_avps received AVP type:1 val:aaaa.dd92.e442 len:14
Apr 12 14:15:37.542517 authd_extract_identifier_avps: User-Name=aaaa.dd92.e442
Apr 12 14:15:37.542526 authd_extract_identifier_avps received AVP type:26 val: len:21
Apr 12 14:15:37.542537 authd_extract_identifier_avps received AVP type:26 val: len:10
Apr 12 14:15:37.542572 Looked up subscriber session-id:209 access-profile-name <WiFi>
Apr 12 14:15:37.542583 nak_error_cause 501 ret_val -1 <<<<<<
 
Apr 12 14:15:37.542641 authd_auth_aaa_msg_destructauth_aaa_msg: 0x99fa06c
Apr 12 14:16:13.172768 jnp_radius_disconnect_udp_callback parse AVP in disconnect req datagram_len 49 req_attributes_len 29 current_offset 0


DHCP subscriber is located in VRF 'mx_wifi':

BRAS> show subscribers extensive
Type: DHCP
User Name: aaaa.dd92.e442
IP Address: 10.66.1.10
Logical System: default
Routing Instance: mx_wifi <---
Interface: demux0.3221225773
Interface type: Dynamic
Underlying Interface: xe-3/1/1.3300
Dynamic Profile Name: IPoE
Dynamic Profile Version: 1
MAC Address: aa:aa:dd:92:e4:42
State: Active
DHCP Relay IP Address: 10.66.1.1
Radius Accounting ID: jnpr xe-3/1/1.3300:403
Session ID: 209
PFE Flow ID: 359
VLAN Id: 3300
Agent Circuit ID: xe-3/1/1:3300
Login Time: 2019-04-16 14:36:00 GMT-3
DHCP Options: len 79
35 01 01 3d 07 01 aa aa dd 92 e4 42 39 02 05 dc 3c 12 61 6e
64 72 6f 69 64 2d 64 68 63 70 2d 38 2e 30 2e 30 0c 0c 4d 49
35 2d 56 69 72 75 73 4e 65 74 37 0a 01 03 06 0f 1a 1c 33 3a
3b 2b 52 0f 01 0d 78 65 2d 33 2f 31 2f 31 3a 33 33 30 30
IPv4 Input Filter Name: FW_WIFI-DEF_IN-demux0.3221225773-in
IPv4 Output Filter Name: FW_WIFI-DEF_OUT-demux0.3221225773-out
Accounting interval: 3600

BRAS> show network-access aaa subscribers session-id 209
Logical system/Routing instance   Client type    Session-ID     Session uptime    Accounting
default:mx_wifi                   dhcp           209            00:07:31          on/volume+time

However, Radius server is configured under GRT:

access {
     radius-server {
        10.34.131.52 {
            port 3799;
            accounting-port 3799;
            source-address 10.34.128.4;
        }
    }
}

Solution:
From the example above, DHCP subscriber is in VRF 'mx_wifi', while Radius server is in GRT. The solution is to make sure that CoA request arrives in the Virtual Router (VR) context that is configured for the Radius server. In other words, either both subscriber and Radius server should be located under VRF, or both subscriber and Radius server should be configured under GRT. In this scenario, Radius server is placed under VRF v3762-wifi-control (any VRF is possible), then CoA is works as expected:
root@bras-radius:/etc/radius$ echo "User-Name='aaaa.dd92.e442',ERX-Service-Activate:1='sWIFI(1024000)',ERX-Service-Timeout:1='6000'" | radclient -x 10.34.128.4:3799 coa testing123
Sending CoA-Request of id 94 to 10.34.128.4 port 3799
User-Name = "aaaa.dd92.e442"
ERX-Service-Activate:1 = "sWIFI(1024000)"
ERX-Service-Timeout:1 = 6000
rad_recv: CoA-ACK packet from host 10.34.128.4 port 3799, id=94, length=20 <--- succeeded

root@bras-radius:/etc/radius$

Corresponding configuration:

access {
     radius-server {
        10.34.131.52 {
            port 3799;
            accounting-port 3799;
            source-address 10.34.128.4;
            routing-instance v3762-wifi-control; <---
        }
    }
}

routing-instances {
    v3762-wifi-control {
        instance-type vrf;
        interface lo0.3;
        route-distinguisher 12389:3762;
        vrf-target {
            import target:12389:3762;
            export target:12389:3762;
        }
        vrf-table-label;
    }
}

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search