ASR9k IPoE static IP subscribers

[joshuacmoore]

Hello all, I would like to bring in double tagged traffic into a PWHE configuration where end subscribers can simply configure their IPs as static and the BNG allows them without the need for DHCP server or AAA. Is this possible? This would be similar to l2vpn bridge domain setup. I normally would do a bridge domain but these subscribers are already on a PWHE xconnect that is running PPPoE on a different VLAN. Is this a supported feature and if so is there any benefit IPoE/BNG provides over normal l2vpn bridge domain services?

thanks in advance!

[xthuijs]

yeah the dot1q any kills you here on the static subscriber.

on the return path we have no clue what inner vlan to put back.

this *is* learned and captured in the dynamic subscriber scenario using packet trigger, but is not set for the static subscriber because when the static subscriber is created we have no idea which inner vlan the remote may be using.

Either you want to fix the static subscriber config with the defined inner vlan 100 OR, as you found use dynamic packet trigger subs allowing you to use "any" on the inner (aka ambigious vlans), and that will create subscr interfaces for every remote source individually and every new vlan it sees.

cheers

xander

[joshuacmoore]

Xander, you have been great and I really appreciate you hanging in here working through this learning experience with me.

Is there any way to make the dynamic learning behavior "sticky"? Where once a subscriber is "learned" it is then considered static and the session never gets tore down? This is probably asking too much but I thought I would ask.

[xthuijs]

hey really no prob josh, I love this BNG stuff so I could talk for hours about it :). What you could do is once the packet triggered sub is created, refrain from using an idle timer or absolute timer on it, that way the sub should never get torn down.

the only thing is that if the session disconnects and gets recreated the interface for the sub will change from say interface bundle-e100.30.ip10 to bundle-e100.30.ip20 this is on itself not an issue, unless you use management tools that "assume" a particular interface number. The simple solution would be to leverage a COA session-query based on say a ip address so we get all the detail back from that session structure so the mgmt back end knows what and whom to monitor.

Session Query is available in XR 531 (not released yet).

xander

[joshuacmoore]

Good deal, so does the BNG by default allow a dynamically learned IPoE session to stay as an active subscriber permanently? Is there any idle/timeout mechanism by default?

[xthuijs · Accepted solution]

hey josh,

I am not aware of any condition that would trash a static or packet subscriber other then a triggered event in the control policy (eg timer event or disconnect operation from COA, account-logoff etc). If you do see that happen, do let me know as that should NOT be the desired standard operation and defeats the purpose of static/packet trigger subs.

Although I dont think it is an issue, in fact I had some cases with users using packet trigger not being able to get rid of the subs :) (solution was an idle timer which did the trick) so I think you're fine here :)

cheers!

xander

[joshuacmoore]

You the man Xander!

Now on to developing a migration plan and implementation.

thanks again!

[xthuijs]

sweet!! good luck, but I am sure you will succeed!! stay in touch if you have things going on!

cheers

xander

[joshuacmoore]

xander,

I have had great success with IPoE subscriber but now I am facing a new challenge!

We have a DSLAM model that does not support VLAN tagging at all. So the management IP is forced to be untagged into the same VLAN as the customer traffic. How would you recommend terminating the DSLAM to the BRAS if we need both static IP for management (not PPPoE) and PPPoE supported in the same VLAN?

[xthuijs]

hey josh, very cool!! :)

yeah so hey there are a few options that you can think of here:

note1: ~ reminder that all traffic arriving at an access interface, eg bundle-e100.2, that can't be mapped to a subscriber context will be forwarded or processed against the features configured of the access interface ~

note2: ~ the access interface needs to be ip enabled (that is have an address configured) in order to process the incoming subscriber dhcp discovers ~

with that note in mind, you could either choose to enble the access interface for forwarding, BUT with an ACL that restricts the communication to say telnet or whatever else mgmt you need towards that particular ip address of the subscriber.

the address of the access interface could be the same subnet as the dslam mgmt interfaces, but with the ACL we prevent people spoofing and using the access interface for their forwarding.

another option is to create a static subscriber session just for the dslam management, this may be more beneficial if you have vlan tagging and can isolate the dslam mgmt to that particular vlan.

Short:

use private addressing or dslam mgmt addresses OUTSIDE the subnet of what subscribers will be getting. this way the ACL control will be easier to manage the incoming subscriber connects and dslam mgmt.

The ACL should contain:

permits from dslam-source with the proto L4 ports of how you're managing it (eg snmp, telnet, ssh, etc).

permits udp dhcp boot-ps/pc from any source

denies everything else.

that way you're secure and able to manage the dslam same way.

cheers

xander

ps. alternatively if the dslam can do it, you can also have it act as a DHCP subscriber, but with the mac-addr it has, you assign a static addr from radius, so it is alwyas managable via a subscriber context.

[joshuacmoore]

Awesome. See my current PWHE PPPoE config below:

policy-map type control subscriber DSLAM
 event session-activate match-first
  class type control subscriber DSLAM do-until-failure
   1 authenticate aaa list default

interface PW-Ether1.31
 description LAB DSLAM INTERNET
 service-policy type control subscriber DSLAM
 pppoe enable bba-group 31
 encapsulation untagged

If I add an unnumbered interface to say lo66 will the native IP packets that don't come in PPPoE encapsulated simply bridge to lo66 and ARP like a normal interface? See conceptual config below:

int lo66
ipv4 address 192.168.0.1/24

policy-map type control subscriber DSLAM
 event session-activate match-first
  class type control subscriber DSLAM do-until-failure
   1 authenticate aaa list default

interface PW-Ether1.31
ipv4 unnumbered lo66
 description LAB DSLAM INTERNET
 service-policy type control subscriber DSLAM
 pppoe enable bba-group 31
 encapsulation untagged

[joshuacmoore]

Hmm. Doesn't seem that ARP is working properly when I add ipv4 unnumbered command to the PWHE subinterface. It does work though if I attach the subnet directly to the subinterface though. However, I don't want to have to create new subnets per DSLAM if at all possible.

Is there some specific magic to get ARP to work across ipv4 unnumbered? Maybe I should just statically nail down the subscriber? What is the config for a static subscriber look like?

[xthuijs]

yeah ethernet with unnumbered is a bit tricky due to the mpoint nature of ethernet right. also for regular ethernet interfaces like gigs you can make it unnumbered, but you will need to create static arp entries and tie it to the right interface, admin nightmare.

for ipsubs it works, because we create the p2p adjacency as part of the subscriber interface config.

so what you found is indeed the best way to configure it to tie the subnet directly to the interface.

regards

xander

[Adiyudha Aji]

Hi Xander,

I'm looking a reference for static session / static subs on BNG (since public documentation on Cisco portal are strictly limited), and turns out that I'm ended in this page. 

the objective is simply just to bring up a static session, see and analyse the behavior and then we'll do the fine tune based on what we need (currently I'm testing the feature on 5.3.0)

the issue I'm facing is, the packet always get stuck on radius authentication (always send access-request again after it gets access-accept from radius, over and over) so the session never established. radius authentication counter on BNG always increase from that particular static subscriber)

appreciate if you can give me a hint / feedback regarding this matter, whether there's something wrong (config wise) either from bng / from radius

these are my current config :

aaa group server radius AAA
 server 10.10.10.13 auth-port 1812 acct-port 1813
 source-interface Loopback0
!
dynamic-template
 type ipsubscriber static_DT
  accounting aaa list default type session
  ipv4 unnumbered Loopback111
 !
!
interface Bundle-Ether111.111
 aaa radius attribute nas-port-type Sync
 ipv4 point-to-point
 ipv4 unnumbered Loopback111
 service-policy type control subscriber static-subs
 encapsulation dot1q 111
 ipsubscriber interface
!

interface Loopback111
 ipv4 address 111.1.1.1 255.255.255.0

!

aaa attribute format intf_id_4
 format-string length 253 "BNG:%s/%s/%s/%s.%s" physical-chassis physical-slot physical-subslot physical-port outer-vlan-id
!
aaa radius attribute nas-port format e SSSSAAPPPPPVVVVVVVVVVVVVVVVVVVVV
aaa accounting subscriber default group AAA
aaa authorization subscriber default group AAA
aaa authentication subscriber default group AAA
!
policy-map type control subscriber static-subs
 event session-start match-first
  class type control subscriber class-default do-until-failure
   10 activate dynamic-template static_DT 
   20 authorize aaa list default format intf_id_4 password cisco
  !

 !
 end-policy-map

thanks

[xthuijs]

seems like there is a communication issue with the radius server.

one thing to do is, remove the action 20 to omit the radius interaction and see if the subscriber comes online and works fine like we expect.

then we can add the radius piece to it and at least eliminate one part from the problem.

then if this is a radius issue, it may be a good idea to ping the radius from the source loop0 that you have to make sure there is proper connectivity. I am suspecting that since you are seeing constant radius requests that the radius doesnt know how to get back to loop0.

a debug radius [detail] will probably get us somewhere and a ping from radius to loop0 will give another clue, a verification of theclient file in the adius and the matching secret key is important there also.

cheers!

xander

[Adiyudha Aji]

Hi Xander,

I really appreciate you prompt response on this matter. I already verify the connectivity (ping to radius from loo0 & vice versa), and check the trace from radius but got to clue (*sigh*).

Does it have anything to do with AVP attribute when radius inform back to BNG within the access-accept packet ? is there any AVP that I'm missing ? given the case that you didn't mention any configuration needed from BNG side (other than removing seq 20 - to distinguish the root cause)

while I'll try to debug, I'd like to share the trace from radius (attached), see if you can give another feedback.

thanks !