[c-nsp] VPDN multihop/forwarding not working

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Mon Feb 4 08:50:13 EST 2013

>> Well, have you defined any of these other realms on the Radius server
>> (with the static "cisco" password)? If you don't, and if you don't have
>> vpdn-group with a "request-dialin" matching their realm, nothing will
>> break, adding the "vpdn authorization .." on those vtemplates will just
>> make sure the LNS no longer sends these Radius requests (with the
>> domain).. have you checked the Radius traces since you enabled vpdn
>> multihop? If you have users with "@" or "/" on other vpdn-groups, you
>> see those?
>Our current setup is - We have multiple realms all configured on our
>radius server (no cisco password, just each DSL account i.e. FNN at realm
>and a random system generated password), and approx
> 15 vpdn-groups on our LNS that connect to the carriers LACs all
>accept-dialin and all using virtual-template7 eg:

well, if all are referencing virtual-template 7, this is where you can put
"vpdn authorization LOCAL_AUTH". And as you are currently not providing
any VPDN multihop, this configuration shouldn't break anything as the only
thing it would affect would be radius-based tunnel authorization.

>So, we are adding a new dsl realm, connection requests for the new realm
>will be coming from the same LAC's, but we want to not auth the new realm
>via our existing radius server - We want
> our LNS to create an L2TP tunnel to another LNS for this new realm (And
>then this other LNS will authenticate the DSL tails via another radius

Right. So I would just add a new vpdn-group with a "request-dialin"
section with an appropriate "domain", just as you configured in your
"vpdn-group TEST" you provided earlier.. the vpdn authorization LOCAL_AUTH
will ensure the LNS will look for it.


More information about the cisco-nsp mailing list