cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3300
Views
0
Helpful
16
Replies

BNG AAA attribute format string

smeftahi
Level 1
Level 1

Dear all,

 

I am looking at a scenario where I receive frames triple tagged. Wholesaler S-Tag and C-Tag, then our own Service TAG.

To terminate traffic on a a BNG configured node, I am rewriting top 2 tags to 1 tag on a POI, then layer 2 handoff to an ASR BNG, where I end up with a "Rewritten S-tag" and our service tag. There will be several unique S-Tag, but C-Tags are only unique per S-Tag.

 

Challenge I am facing is how to construct authentication attribute format for BNG ? Option 82 is not feasible in this scenario, so I have to make due with Tags, Sub-IF ids and perhaps a remote ID based on POI where tag rewriting is taking place.

 

Any suggestions, or pointers will be appreciated.

 

TIA

 

/Sam

2 Accepted Solutions

Accepted Solutions

xthuijs
Cisco Employee
Cisco Employee

hi sam, another option is to use PWHE. this way you instead of bundling 2 tags into a single tag on the adj pre-agg node, you'll make a PW there.

and you map your S-tag as a PW say, and use the inner/outer that is originally there.

 

so basically if you have a frame that looks like:

ur(S-tag) - their(S-tag) - their(C-tag) 

then do: rewrite ingress tag pop 1 symmetric on the EFP side

and xconnect it into a pw with VCid ur(S-tag)

you can build multiple PW's between pre-agg and bng.

 

for now using PWHE eliminates the use of GEORED, but that is coming, but you can also use PW redundancy in the interim.

also PWHE binds you to RP based session scale.

 

xander

View solution in original post

hi sam,

I think you're mixing a few things here that can't work together.

What works is, or what goes together is:

- BNG, amb vlan and dhcp profile (proxy).

- PWHE means xconnect between PW on one leg and a pwhe interface on the other leg.

 

OR

- bridge domain, vfi's (or not), pseudo wire, attachment circuits

- if you add dhcp snooping to the BD, you must have explicit vlan configuration

 snooping does not track the vlan combo for hte incoming session like a BNG access interface does. so while you can take the discover and RELAY it, the return path doesnt exist since dhcp relay doesnt know what vlan combo to inject the packet into the BD with.

 

so your findings are consistent with the operations of the protocols/device implementation.

xander

View solution in original post

16 Replies 16

xthuijs
Cisco Employee
Cisco Employee

hi sam, another option is to use PWHE. this way you instead of bundling 2 tags into a single tag on the adj pre-agg node, you'll make a PW there.

and you map your S-tag as a PW say, and use the inner/outer that is originally there.

 

so basically if you have a frame that looks like:

ur(S-tag) - their(S-tag) - their(C-tag) 

then do: rewrite ingress tag pop 1 symmetric on the EFP side

and xconnect it into a pw with VCid ur(S-tag)

you can build multiple PW's between pre-agg and bng.

 

for now using PWHE eliminates the use of GEORED, but that is coming, but you can also use PW redundancy in the interim.

also PWHE binds you to RP based session scale.

 

xander

Thanks for the clarification Xander,

 

I stalled PWHE due to lack for GeoRed support, but I will test it this week.

 

Once again, many thanks !

 

/Sam

 

 

Hi Xander,

Finally tested PWHE both BNG and DHCP relay with few issues I am hoping you could shed some light on.

 

PWHE BNG, works as expected when both ends are configured with xconnect group syntax. Also works when remote end is configured with xconnect defined under bridge group, bridge domain and vfi. For latter, traffic drops as soon as I insert "dhcp ipv4 snoop profile" under either vfi or bridge domain.

 

For non BNG DHCP relay, ambiguous VLAN does not seem to work on PWHE, a lease is only obtained when encapsulation is set to match both VLANs.

 

Are there any caveats I should be aware of and how to mitigate them ?

 

TIA

 

/Sam

hi sam,

I think you're mixing a few things here that can't work together.

What works is, or what goes together is:

- BNG, amb vlan and dhcp profile (proxy).

- PWHE means xconnect between PW on one leg and a pwhe interface on the other leg.

 

OR

- bridge domain, vfi's (or not), pseudo wire, attachment circuits

- if you add dhcp snooping to the BD, you must have explicit vlan configuration

 snooping does not track the vlan combo for hte incoming session like a BNG access interface does. so while you can take the discover and RELAY it, the return path doesnt exist since dhcp relay doesnt know what vlan combo to inject the packet into the BD with.

 

so your findings are consistent with the operations of the protocols/device implementation.

xander

Thanks a million Xander, although I see these are limitations am glad they are consistent with my tests and expected.

 

Once again, thanks for taking time to reply and clarify !

 

/Sam

hi Sam,

 

In addition to Xander's reply, I wanted to confirm that PWHE with ambiguous encap works:

 

RP/0/RSP0/CPU0:our9001#show subscriber session all | i PE1300.1400
IP:DHCP PE1300.1400.ip2 AC 172.31.0.69 (default)
IP:DHCP PE1300.1400.ip1 AC 172.31.0.70 (default)
IP:DHCP PE1300.1400.ip3 AC 172.31.0.71 (default)
IP:DHCP PE1300.1400.ip4 AC 172.31.0.72 (default)
IP:DHCP PE1300.1400.ip5 AC 172.31.0.74 (default)
IP:DHCP PE1300.1400.ip6 AC 172.31.0.75 (default)

 

RP/0/RSP0/CPU0:our9001#sh run int PE1300.1400

interface PW-Ether1300.1400
 service-policy output SPD subscriber-parent resource-id 2
 ipv4 unnumbered Loopback100
 ipv6 enable
 service-policy type control subscriber IPoE_Auth
 load-interval 30
 ipsubscriber ipv4 l2-connected
  initiator dhcp
 !
 encapsulation ambiguous dot1q 1400 second-dot1q any

 

/Aleksandar

Thanks Aleksandar !

 

No doubt it works, it was just few variations which as confirmed by Xander do not work. Else I can also confirm BNG PWHE works fine on my test bed.

 

/Sam

Hi Xander

 

because of CRM and billing software, I would like to generate a AAA attribute format for IPOE session (exactly like for PTA session) as following: <number>@domain.com.

As DLSAM/OLT sent a remote-id-tag <number>-OLTX-ethX, I just need <number> which is 10 digits phone number, and append"@domain.com" (always the same domain).

 

I try with 

!
aaa attribute format RID_FORMAT
  format-string length 10 "%s@domain.com" remote-id-tag
!

 

But whatever it happen, RID_FORMAT attribute is always truncated to 10 first char (ie. 10 digit number).

 

Is it anyway possible to create a  IPOE attribute format same as PPPoE?

Thanks for your help.  

 

noruni

What happens if you omit the "length 10", i.e.:

 

aaa attribute format RID_FORMAT
 format-string "%s@domain.com" remote-id-tag

 

hi Alek

 

Normal remote-id value received by ASR9001 is "9999999999-OLT1-CUST1" with:

9999999999=Phone number (different  for each session). So i use phone number as username sent to radius (defined on policy-map): 9999999999@domain.com

Without lenght, and adding domain.com, il have following format string:

 

9999999999-OLT1-CUST1@domain.com

 

As it doesn't match with radius server user config, then, the authorization fail.

 

If you have any idea how to remove "-OLT1-CUST1", that's solve my problem.

Thanks

 

Noruni

you can only "strip" the username or format it.

if you dont care about the "@-domain" part then you can use the :

username-strip prefix-delimiter -

 

cheers

xander

Thanks Xander

 

I turned around my problem, and I think the only solution is to combine 2 "aaa attribute format":

* first attribute to get only phone number (ie. 1234567890)

* then second attribute which add "@domain" to first attribute.

 

is it possible to do it in the policy-map?

 

Noruni

Hi Noruni

 

BTW, as far as i know (but perhaps i am on the wrong way), your solution seems not possible.

Perhaps next major release...

 

Jacques

Have you tried using the "username-strip prefix-delimiter -" in combination with "format-string ..."?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: