[j-nsp] Subscriber Management with RADIUS authentication question

[Alex D.]

Hi,

i have a running Subscriber Management setup in my testlab with Juniper MX5 running JUNOS15.1R6.7. MX is functioning as DHCP proxy and forwards all DHCP requests to an external DHCP server after successful authentication against a RADIUS server based on DHCP Option 82 remote-id. RADIUS server send Juniper VSA #1 (Virtual-Router) to put different subscribers in service-specific VRFs.
This works fine so far....

Let's come to my problem now:
I change an user profile on my RADIUS server, e.g. adjust the respective RADIUS attribute to map him into another VRF. After that, I reset the particular DSL port so that his CPE resynchronize and send a new DHCP request. Unexpectedly, MX5 doesn't send a new authentication request to the RADIUS server but relays the DHCP request to the DHCP server only. So that I don't get the previously updated RADIUS attributes. I have to mention, that the Juniper box doesn't "know" that I forced the subscriber CPE to resynchronize and therefore the subscriber is still listed in the output of "show subscribers".

On the other hand, when I do a "clear dhcp relay binding routing-instance VRF_XYZ all" before resynchronize a customer CPE, the MX5 sends a RADIUS authentication request again after receiving the DHCP discover from the client.

Because of this behavior, it seems that my MX5 does some "caching" and doesn't send subsequent requests to the RADIUS server as long as there is a dhcp relay binding. Does anybody knows this problem and is there a configuration option to "fix" it ?

Regards,
Alex

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Alex D.]

Hello Alex,
You use the delete-binding-on-renegotiation statement to override the default action, and to specify that DHCP tear down the existing matching client entry and to process the message as a new client entry.
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/delete-binding-on-renegotiation-edit-dhcp.html

Thanks for your hint. I did *not* set this option in my dhcp-relay
override settings. After configuring delete-binding-on-renegotiation, it
works as expected.
But curious is the following fact:
- renegotiation in master routing instance doesn't work without
configuring under [edit forwarding-options dhcp-relay overrides]
- renogiation in VRF works out of the box without configuring under
[edit routing-instances routing-instance-name forwarding-options
dhcp-relay overrides]
All dhcp-relay configuration was the same in master routing-instance
just like in specific routing-instances...

Do you know, if there's a difference in default behaviour between master
and specific routing-instances ?

Regards
Alex
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp