cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3420
Views
0
Helpful
19
Replies

How to Redirect and send subscriber name to URL

HI Community

I have radius config to accepts any connection to avoid attach PPPOE Session. How to config redirect url to:"http://xxxx.com/Response.aspx?username=%U" when subscriber use expire username. I need to sent username to aspx (username=%U) and get HTTP.

 

Thank you.

.

19 Replies 19

Hey Xander.

Thanks!

Yes, we can use leaking between vrfs and that was in our plans. And I agree, on the portal we can use the source ip and  "static mapping between pools and BNG" to find out the destination ip for BNG to which we have to send  account-status-querry after just to get account session id of that user. The main reason why I am planning to use the special  constructed url is that we have several BNGs and users with static /32 addresses. And the portal have to have the information about  dynamic mapping between user with static ip and BNG on which that user located. Is it possible on A9k BNG that users can have a dedicated ip and that ip address is assigned from radius and then redistributed by dynamic routing protocol? 

So, if we are not able to do vrf transfer (from global tabel to vrf) on asr9k platform,

what would you suggest how we can migrate from ISG to A9K if users on A1k platform have service that redirect them to Cisco SCE platform (parental control) for for further processing. And the user with parental control can be any user has subscribed to the service. Here we need to use some kind of dynamic routing for  /32 adresses and need to put that users in separate vrf on ISG. Use of ABF on a9k? No, because traffic to the subscriber should be got on the same path through the same sce box.

cheers

Petr

In the absence of vrf transfer Petr, you could use the functionality of ABF (access-list based forwarding) or PBR (policy based routing).

PBR can modify the source/dest ip and ABF can redirect the traffic (to a different vrf even).

so what we could do is define an ACL that sets a next hop and possibly in a different vrf and then apply that ACL as a service to the users needing parental control.

All users, regardless of their service are in the same vrf, but the service template application that either does HTTP-R, or ABF can then force the traffic/requests into a certain direction.

that might be a good option?

Also since if the parental control is no longer necessary, we can remove that service/ACL via a simple COA to deactivate that dynamic template that holds the ABF ACL.

cheers!

xander

Xander, I understand your idea and steering traffic toward the internet based on ABF is only right choce for now.  But in the same time we need to steer traffic from internet toward user on the same path (through  Parental control system -- Cisco SCE,  this system needs to  inspect all traffic to and from subscriber) and this path is different from general path for other users (Parental control device is not inline)

Are there some sort of means/functions(on a9k BNG) of tagging /32 routes of users that have ABF/ACL as a service and use that tags in dynamic routing (bgp/ospf) for advertising routers differently from  routes of general users even they are all in the same vrf? We need the option that helps us to selectively advertise routes with different tags based on set os services (if we are not able to do vrf transfer here). Do you see idea? May be you can suggest something we did not  notice.   

Thanks!

Petr

yeah (rpl) route tag is local between RIB and routing protocol and not transparent between different RP's...

you know, if such users of the SCE/parental service have a prviate address, are natted, we can "suck" the nat destinations, now source back in very easily.

if not that, then only per user structures on the core back down to the SCE will suffice, or providing those users that need parental controlSCE service with a specific subnet, so we can redirect that subnet on ingress.

not easy, but managable...

xander

Thanks for all your suggestions, Xander

Cheers, Petr