[cisco-bba] Help with VPDN Group config

Andy Saykao andy.saykao at staff.netspace.net.au
Mon Apr 6 23:30:37 EDT 2009


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
 
 
 
 
 
The odd thing is that we have two POPS in different states but the LAC
requests come into our core router.
 
[core router] --- [STATE1]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-bba/attachments/20090407/decb0d90/attachment.html>


More information about the cisco-bba mailing list