[cisco-bba] Help with VPDN Group config
Andy Saykao
andy.saykao at staff.netspace.net.au
Tue Apr 7 04:32:13 EDT 2009
Thanks for the reply Oli.
We are currently using 12.2(31)SB14 on this LNS and the command "show
vpdn group-select" is not supported.
If the source-ip command is used as an additional criteria then this
might explain why it's working in another State where we've got three
different vpdn-groups set up (all of them not having the "terminate-from
hostname" in their vpdn-group config). These LNS's are ASR's running
122-33.XNB3 and they are properly terminating sessions correctly.
-----Original Message-----
From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com]
Sent: Tuesday, 7 April 2009 5:56 PM
To: Tony; cisco-bba at puck.nether.net; Andy Saykao
Subject: RE: [cisco-bba] Help with VPDN Group config
Actually, 12.4(20)T (and, I think, some future 12.2S*) will use the
source-ip as an addtl. criteria to select the vpdn-group. You can use
the command "show vpdn group-select { summary | keys ...}" to find out
which vpdn-group will be matched..
oli
Tony <> wrote on Tuesday, April 07, 2009 07:17:
> Unfortunately, I think the answer is not what you are hoping for.
>
> From:
>
http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/vpdngrp.h
tm
>
> =====
> Typically, you need one VPDN group for each LAC. For an LNS that
> services many LACs, the configuration can become cumbersome; however,
> you can use the default VPDN group configuration if all the LACs will
> share the same tunnel attributes. ===== Each VPDN group can only
> terminate from a single host name. If you enter a second
> terminate-from command on a VPDN group, it will replace the first
> terminate-from command. =====
>
>
>
> regards,
> Tony.
>
>
> --- On Tue, 7/4/09, Andy Saykao <andy.saykao at staff.netspace.net.au>
> wrote:
>
>> From: Andy Saykao <andy.saykao at staff.netspace.net.au>
>> Subject: [cisco-bba] Help with VPDN Group config
>> To: cisco-bba at puck.nether.net
>> Date: Tuesday, 7 April, 2009, 1:30 PM
>>
>>
>>
>>
>>
>> Hi
>> All,
>>
>> We've recently
>> changed the way we configure our VPDN groups on the LNS. In the past
>> we use to configure a VPDN group on our LNS for every LAC on the
>> Provider's end, but we have found out that we can use one VPDN group
>> to terminate all incoming LAC requests.
>>
>> Old Way
>> - VPDN groups configured to terminate each individual LAC.
>>
>>
>> vpdn-group
>> PROVIDER1-NAB1 <-- Terminate a LAC in StateX accept-dialin
>>
>> protocol l2tp
>> virtual-template 2
>> terminate-from hostname
>> provider1-nab1
>> lcp renegotiation on-mismatch
>> l2tp tunnel
>> password AAABBBCCCDDD
>> l2tp tunnel
>> receive-window 100
>> l2tp tunnel retransmit timeout min
>> 2
>> !
>> vpdn-group
>> PROVIDER1-ABC1 <--- Terminate a LAC in StateY accept-dialin
>> protocol l2tp
>> virtual-template
>> 3
>> terminate-from hostname provider1-abc1 lcp renegotiation
>> on-mismatch l2tp tunnel password AAABBBCCCDDD l2tp tunnel
>> receive-window 100 l2tp tunnel retransmit timeout min
>> 2
>>
>>
>> New Way -
>> One VPDN group configured to terminate all LACs.
>>
>> vpdn-group
>> PROVIDER1-VPDN-1 <-- Terminate LACs in StateX ! Default L2TP VPDN
>> group accept-dialin
>> protocol l2tp
>>
>> virtual-template 2
>> source-ip 203.17.101.x
>> lcp
>> renegotiation on-mismatch
>> l2tp tunnel
>> password AAABBBCCCDDD
>> l2tp tunnel
>> receive-window 100
>> l2tp tunnel retransmit timeout min
>> 2
>> !
>> vpdn-group
>> PROVIDER1-VPDN-2 <--- Terminate LACs in StateY accept-dialin
>> protocol l2tp
>>
>> virtual-template 3
>> source-ip 203.17.101.y
>> lcp
>> renegotiation on-mismatch
>> l2tp tunnel
>> password AAABBBCCCDDD
>> l2tp tunnel
>> receive-window 100
>> l2tp tunnel retransmit timeout min
>> 2
>>
>> Our LNS's actually
>> terminate LAC request from
>> two different states (but from the same Provider). We're using
>> Loopback0 as the VPDN source-ip for StateX and Loopback1 for the VPDN
>> source-ip for StateY as shown above. The LNS is physically located in
>> StateX.
>>
>> What we're finding
>> out while doing it this way is that the LNS automatically adds a
>> comment "!
>> Default L2TP VPDN group" to our config making one of the VPDN groups
>> the default VPDN group. In my example above, it has made vpdn-group
>> PROVIDER1-VPDN-1 which terminates LACs in StateX the default VPDN
>> group. Therefore, LAC requests from StateY were not being terminated
>> using the proper vpdn-group
>> PROVIDER1-VPDN-2 eventhough we had the correct VPDN source-ip set.
>> This caused our call centre to sky rocket with calls from customers
>> in StateY who were unable to establish a PPPoX connection.
>>
>>
>> We're not sure why the
>> config is behaving this way. I
>> would expect that given we've specified a VPDN source-ip for each
>> VPDN group that the LAC would source it's terminatation point from
>> the VPDN group with the correct source-ip that it's suppose to
>> initiate a L2TP tunnel with - but we're finding that it's trying to
>> establish a L2TP tunnel with whatever VPDN group has been set as the
>> "Default L2TP VPDN group".
>>
>> Is there a way to fix this so
>> that LAC requests from
>> StateX will use it''s corresponding VPDN group and likewise LAC
>> requests from StateY will use it's corresponding VPDN group???
>>
>> Thanks.
>>
>> Andy
>>
>>
>>
>>
>
>
>
>
> _______________________________________________
> cisco-bba mailing list
> cisco-bba at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
Please notify the sender immediately by email if you have received this
email by mistake and delete this email from your system. Please note that
any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of the organisation.
Finally, the recipient should check this email and any attachments for
the presence of viruses. The organisation accepts no liability for any
damage caused by any virus transmitted by this email.
More information about the cisco-bba
mailing list