<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16809" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009>Hi
All,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009><STRONG>Old Way
- VPDN groups configured to terminate each individual
LAC.</STRONG></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009><SPAN
class=470575002-07042009> </DIV>
<DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009>vpdn-group
PROVIDER1-NAB1 <-- Terminate a LAC in StateX<BR> accept-dialin<BR>
protocol l2tp<BR> virtual-template 2<BR> terminate-from hostname
provider1-nab1<BR> lcp renegotiation on-mismatch<BR> l2tp tunnel
password AAABBBCCCDDD</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009> l2tp tunnel
receive-window 100<BR> l2tp tunnel retransmit timeout min
2</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009>!</SPAN></FONT></DIV></SPAN></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009>vpdn-group
PROVIDER1-ABC1 <--- Terminate a LAC in
StateY<BR> accept-dialin<BR> protocol l2tp<BR> virtual-template
3<BR> terminate-from hostname provider1-abc1<BR> lcp renegotiation
on-mismatch<BR> l2tp tunnel password AAABBBCCCDDD</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009> l2tp tunnel
receive-window 100<BR> l2tp tunnel retransmit timeout min
2</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009><STRONG>New Way -
One VPDN group configured to terminate all LACs.</STRONG></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009>vpdn-group
PROVIDER1-VPDN-1 <-- Terminate LACs in StateX<BR>! Default L2TP VPDN
group<BR> accept-dialin<BR> protocol l2tp<BR>
virtual-template 2<BR> source-ip 203.17.101.x<BR> lcp
renegotiation on-mismatch<BR> l2tp tunnel
password AAABBBCCCDDD</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009> l2tp tunnel
receive-window 100<BR> l2tp tunnel retransmit timeout min
2</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009>!</SPAN></FONT></DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009>vpdn-group
PROVIDER1-VPDN-2 <--- Terminate LACs in
StateY<BR> accept-dialin<BR> protocol l2tp<BR>
virtual-template 3<BR> source-ip 203.17.101.y<BR> lcp
renegotiation on-mismatch<BR> l2tp tunnel
password AAABBBCCCDDD</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009> l2tp tunnel
receive-window 100<BR> l2tp tunnel retransmit timeout min
2</SPAN></FONT></DIV>
<DIV><BR></SPAN></FONT><FONT face=Arial size=2><SPAN
class=470575002-07042009>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009>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 <SPAN
class=470575002-07042009>vpdn-group PROVIDER1-VPDN-1 which terminates LACs in
StateX the default VPDN group. There</SPAN>fore, LAC requests from StateY were
not being terminated using the proper <SPAN class=470575002-07042009>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. </SPAN></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009><SPAN
class=470575002-07042009></SPAN></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009><SPAN
class=470575002-07042009>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". </SPAN></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009><SPAN
class=470575002-07042009></SPAN></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009><SPAN
class=470575002-07042009>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???</SPAN></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009><SPAN
class=470575002-07042009></SPAN></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009><SPAN
class=470575002-07042009>Thanks.</SPAN></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009><SPAN
class=470575002-07042009></SPAN></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009><SPAN
class=470575002-07042009>Andy</SPAN></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009> </DIV></SPAN></FONT>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009>The odd thing is
that we have two POPS in different states but the LAC requests come into our
core router.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=470575002-07042009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=470575002-07042009>[core router] ---
[STATE1]</SPAN></FONT></DIV></BODY><!--[object_id=#staff.netspace.net.au#]--><P align=left><FONT face=Arial size=1>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.</FONT></P></HTML>