[cisco-bba] Help with VPDN Group config
Andy Saykao
andy.saykao at staff.netspace.net.au
Tue Apr 7 03:19:35 EDT 2009
I understand that you can only have one default vpdn-group and this is
the one use by those LAC's which do not have a match in any of the
vpnd-group configs where the "terminate-from" has been configured. These
LACs are then to use the default vpdn-group.
Below we have a default vpdn-group selected as being vpdn-group
PROVIDER2-VPDN-GROUP-1 - but we are seeing that PROVIDER1 can land
sessions on our LNS eventhough they use a different l2tp tunnell
password. If the above paragraph was true, then we would expect that
L2TP sessions from PROVIDER1 will be initated by using the default
vpdn-group PROVIDER2-VPDN-GROUP-1 and fail due to the l2tp tunnel
password mismatch. That begs the question, does it jump to another
vpdn-group based on the l2tp tunnel password failing???
vpdn-group PROVIDER1-VPDN-GROUP-1
accept-dialin
protocol l2tp
virtual-template 2
source-ip 203.17.101.aaa
lcp renegotiation on-mismatch
l2tp tunnel password AAABBBCCCDDD
l2tp tunnel receive-window 100
l2tp tunnel retransmit timeout min 2
!
vpdn-group PROVIDER1-VPDN-GROUP-2
accept-dialin
protocol l2tp
virtual-template 2
source-ip 203.17.101.bbb
lcp renegotiation on-mismatch
l2tp tunnel password AAABBBCCCDDD
l2tp tunnel receive-window 100
l2tp tunnel retransmit timeout min 2
!
vpdn-group PROVIDER2-VPDN-GROUP-1
! Default L2TP VPDN group
accept-dialin
protocol l2tp
virtual-template 3
lcp renegotiation on-mismatch
l2tp tunnel password WWWXXXYYYZZZ
l2tp tunnel receive-window 100
l2tp tunnel retransmit timeout min 2
1. Check to see if it has a specific match for that LAC. If so, use that
specific VPDN group.
2. If no matches found, use default VPDN group.
3. If l2tp password fail, try a different vpdn-group??? <--- is this the
next step???
-----Original Message-----
From: Tony [mailto:td_miles at yahoo.com]
Sent: Tuesday, 7 April 2009 4:51 PM
To: cisco-bba at puck.nether.net; Andy Saykao
Subject: RE: [cisco-bba] Help with VPDN Group config
Hi Andy,
The way I understand that the LNS decides which VPDN group to land the
connection on is as follows:
1. Check to see if it has a specific match for that LAC. If so, use that
specific VPDN group.
2. If no matches found, use default VPDN group.
This is why the confige you've got now is working with default group for
one state and specific groups for each LAC from other state.
The "source-ip" setting simply allows you to specify the address the LNS
uses for it's end of the tunnel.
> 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.
You can one specify a single "terminate-from" in the VPND group and you
can only have one "default group".
It would seem the only difference (that I can see) between your VPDN
groups is the virtual-template command ? Maybe you can use RADIUS to
supply this dynamically instead of having it in the VPDN group config ?
We terminate connections from multiple states on our LNS's and each VPDN
group uses the same virtual-template command. Our virtual-template
interface has nothing in the config on the Cisco router, it's all
supplied from RADIUS.
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: RE: [cisco-bba] Help with VPDN Group config
> To: "Tony" <td_miles at yahoo.com>, cisco-bba at puck.nether.net
> Date: Tuesday, 7 April, 2009, 4:11 PM
> 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.
More information about the cisco-bba
mailing list