Solved: ASR9000 IPv4 Pools & CGN - BNG Policies

victor.lyapunov · ‎06-14-2016

Hello all

We have a setup of ASR9K offering PPPoE termination services. For the bulk of our subscribers we offer public IPv4 but due to the lack of available address space we also start giving private IPs / CGN (and placing corresponding subscribers in a VRF that ensures forwarding to the CGNAT device).

We are looking for an ASR9K config to do the following:

Use the public pool and when it is depleted start giving the private ipv4 pools / placing subscribers in CGN vrf. Using two address ranges is not a problem, the difficult part is the second placing the subscribers in the CGN vrf.

Ideally we would have two dynamic templates and possible actions

- One for public that places the subscribers in the default VRF and references the public pool

- One for CGNAT that places the subscribers in the CGN VRF and references the private pool

Is there a way to make sure that 1)initially the first dynamic template is used and 2) when public pool is depleted the subsequent subscribers will use the second dynamic template (that will place them in the VRF and assign private addresses)?

I have tried to use the subscriber control policies to achieve this, without any luck so far.

The other alternative would be to move all the logic of address assignment to a Radius server but first we would like to exhaust are config options for the ASR9k

has anyone tried anything similar?

Thanx for your input

Aleksandar Vidakovic · ‎06-14-2016

hi Victor,

The cleanest solution would be to completely separate the private from public, based on access-interface and associated dynamic template. This would mean the config is clean and traffic flows easy to understand.

If this is not an option, one approach you could test in the lab is to have the private and public range in the same pool and use ABF on subscriber access interfaces to redirect traffic from specific source IPv4 addresses to the ServiceApp. You could apply the same ACL to all subscriber subinterfaces. In ABF you can specify the nexthop and the target VRF. Scale might be an issue in BNG deployment, so please pay attention to TCAM utilisation when you run the test.

ABF: https://supportforums.cisco.com/document/145271/abf-acl-based-forwarding-asr9k

This way you can mix the private and public address ranges in the single pool that is associated with the dynamic template. ABF will make sure that only private addresses are redirected to ServiceApp.

On the Outside-2-Inside path you would have to use static route with a nexthop in a default VRF.

Hope this helps,

Aleksandar

View solution in original post

Aleksandar Vidakovic · ‎06-14-2016

hi Victor,

The cleanest solution would be to completely separate the private from public, based on access-interface and associated dynamic template. This would mean the config is clean and traffic flows easy to understand.

If this is not an option, one approach you could test in the lab is to have the private and public range in the same pool and use ABF on subscriber access interfaces to redirect traffic from specific source IPv4 addresses to the ServiceApp. You could apply the same ACL to all subscriber subinterfaces. In ABF you can specify the nexthop and the target VRF. Scale might be an issue in BNG deployment, so please pay attention to TCAM utilisation when you run the test.

ABF: https://supportforums.cisco.com/document/145271/abf-acl-based-forwarding-asr9k

This way you can mix the private and public address ranges in the single pool that is associated with the dynamic template. ABF will make sure that only private addresses are redirected to ServiceApp.

On the Outside-2-Inside path you would have to use static route with a nexthop in a default VRF.

Hope this helps,

Aleksandar

victor.lyapunov · ‎06-14-2016

Thnx Aleksandar ABF seems to a promising option to achieve the behavior we need

Aleksandar Vidakovic · ‎06-15-2016

hi Victor,

I have given some more thought to this. To make the solution with ABF work, the subscriber interfaces and the inside ServiceApp interface must be in the same VRF.

Otherwise when the traffic comes back from the Internet (outside o inside) you have to route it somehow from the 'inside' VRF into the default VRF (presuming subscribers are in default), but there's no next-hop IP that you can use for that purpose (static route per every subscriber interface doesn't scale as solution).

With that change, you have to take care of the subscribers with public IPv4 by leaking the public subscriber routes to default VRF.

This is interesting as an exercise, but I would be in favour of a simpler solution with a separate dynamic-template for the private and public.

Whichever solution you go for, please use IOS XR release 5.3.3 for your testing with the latest SMUs. For the VSM it's important to have asr9k-px-5.3.3.CSCuy67366 and asr9k-px-5.3.3.CSCuz66236.

regards,

Aleksandar