[cisco-bba] Help with VPDN Group config

Tue Apr 7 02:11:02 EDT 2009

Hi Tony,

Up to a week ago, we did it the way you are doing it where each VPDN
group referenced a single LAC. We spoke to another ISP whose doing it
the new way where one VPDN group can service any number of LACs.  We're
doing this on a number of LNS in other States and it works fine (and it
certainly makes the LNS config much cleaner and shorter). The only
difference with the other LNS is that they terminate L2TP tunnels within
the same state. The problem we're having with this particular LNS is
that we're trying to terminate L2TP tunnels from two different states
but from the same Upstream Provider. How we've overcome this is to leave
the default VPDN group in to service StateX (which has 20+ LACS) and
reconfigure each VPND group individually for StateY (which only has like
5-6 LACs). This seems to have fixed the problem. But we would like to
move the individual VPDN groups for StateY to a single VPDN group. When
we do this, L2TP connections from StateY somehow reference the default
VPDN group set up for StateX.

Thanks.

Andy

-----Original Message-----
From: Tony [mailto:td_miles at yahoo.com] 
Sent: Tuesday, 7 April 2009 3:17 PM
To: cisco-bba at puck.nether.net; Andy Saykao
Subject: Re: [cisco-bba] Help with VPDN Group config

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
>  
>  
>  
>  

______________________________________________________________________
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.