Mailing List Archive

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

=====
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@staff.netspace.net.au> wrote:

> From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> Subject: [cisco-bba] Help with VPDN Group config
> To: cisco-bba@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

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@yahoo.com]
Sent: Tuesday, 7 April 2009 3:17 PM
To: cisco-bba@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@staff.netspace.net.au>
wrote:

> From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> Subject: [cisco-bba] Help with VPDN Group config
> To: cisco-bba@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.

_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Hi Tony,

Been digging around and looks like it can't be done according to
oli@cisco.

Take a look at this thread.

http://www.gossamer-threads.com/lists/cisco/bba/40421


vpdn-group collecte
! Default L2TP VPDN group
accept-dialin
protocol l2tp
virtual-template 1
source-ip aaa.bbb.lo0.1
local name tunnel-l
lcp renegotiation always
no l2tp tunnel authentication
!
vpdn-group vcollecte
accept-dialin
protocol l2tp
virtual-template 2
source-ip aaa.bbb.fa0.1
local name tunnel-l2
lcp renegotiation always
no l2tp tunnel authentication

Like us, this guy wants LAC request for the vcollecte group to terminate
using the vpdn-group vcollacte.

Here is Oli@Cisco's reply:

Since you use default vpdn-groups (no "terminate-from" in the vpdn-group
config), all your
sessions will terminate within the group "collecte", the 2nd group is
not used at all.
The destination IP address is not used to select vpdn-groups..

Cheers.

Andy


-----Original Message-----
From: Tony [mailto:td_miles@yahoo.com]
Sent: Tuesday, 7 April 2009 3:17 PM
To: cisco-bba@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.

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.

_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

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@staff.netspace.net.au> wrote:

> From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> Subject: RE: [cisco-bba] Help with VPDN Group config
> To: "Tony" <td_miles@yahoo.com>, cisco-bba@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@yahoo.com]
>
> Sent: Tuesday, 7 April 2009 3:17 PM
> To: cisco-bba@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@staff.netspace.net.au>
> wrote:
>
> > From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> > Subject: [cisco-bba] Help with VPDN Group config
> > To: cisco-bba@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

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@yahoo.com]
Sent: Tuesday, 7 April 2009 4:51 PM
To: cisco-bba@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@staff.netspace.net.au>
wrote:

> From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> Subject: RE: [cisco-bba] Help with VPDN Group config
> To: "Tony" <td_miles@yahoo.com>, cisco-bba@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@yahoo.com]
>
> Sent: Tuesday, 7 April 2009 3:17 PM
> To: cisco-bba@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@staff.netspace.net.au>
> wrote:
>
> > From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> > Subject: [cisco-bba] Help with VPDN Group config
> > To: cisco-bba@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.

_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

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@staff.netspace.net.au>
> wrote:
>
>> From: Andy Saykao <andy.saykao@staff.netspace.net.au>
>> Subject: [cisco-bba] Help with VPDN Group config
>> To: cisco-bba@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

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@cisco.com]
Sent: Tuesday, 7 April 2009 5:56 PM
To: Tony; cisco-bba@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@staff.netspace.net.au>
> wrote:
>
>> From: Andy Saykao <andy.saykao@staff.netspace.net.au>
>> Subject: [cisco-bba] Help with VPDN Group config
>> To: cisco-bba@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@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.

_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Thanks for clearing that up Oli.

I reserve the right to be both correct and incorrect, depending on IOS version in use :)


regards,
Tony.

--- On Tue, 7/4/09, Andy Saykao <andy.saykao@staff.netspace.net.au> wrote:

> From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> Subject: RE: [cisco-bba] Help with VPDN Group config
> To: "Oliver Boehmer (oboehmer)" <oboehmer@cisco.com>, "Tony" <td_miles@yahoo.com>, cisco-bba@puck.nether.net
> Date: Tuesday, 7 April, 2009, 6:32 PM
> 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@cisco.com]
>
> Sent: Tuesday, 7 April 2009 5:56 PM
> To: Tony; cisco-bba@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@staff.netspace.net.au>
> > wrote:
> >
> >> From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> >> Subject: [cisco-bba] Help with VPDN Group config
> >> To: cisco-bba@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@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.
>
>



_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Any ideas how to determine if the IOS uses the source-ip under the
vpdn-group config as an additional criteria for handling incoming LAC
requests. Reading the docos it appears that the command "show vpdn
group-select" is only available with the 12.4(20)T release.

The ASR's I mention (122-33.XNB3) that have individual vpdn-group
configs without the "terminate-from hostname" are terminating L2TP
sessions properly from their respective LACs - but the command "show
vpdn group-select" is not enabled with this IOS release either. So in
this scenario, is the ASR using the source-ip to determine which
vpdn-group handles the incoming LAC request (scenario 2) or could it be
that because the default vpdn-group has the wrong l2tp tunnel password
set (because it's for a different provider) that the incoming LAC
request tries another vpdn-group that also does not "terminate-from
hostname" set (scenario 1)???

Scenario 1/

- LAC request comes in - is there a hostname configured on the LNS in
the vpdn-group that matches my hostname, if so use this vpdn-group.
- No hostname exists, use the default vpdn-group.
- The LAC can't establish a tunnel with the default vpdn-group (eg:
mismatch l2tp tunnel password), then try another vpdn-group which does
not have any "terminate-from hostname" configured.

Scenario 2/

- LAC request comes in - is there a hostname configured on the LNS in
the vpdn-group that matches my hostname, if so use this vpdn-group.
- Is there a vpdn-group that has the source-ip that matches the
destination IP that the LAC is trying to initiate a tunnel with, if so
use this vpdn-group.
- No hostname match, no source-ip match, use default vpdn-group then.




-----Original Message-----
From: Tony [mailto:td_miles@yahoo.com]
Sent: Tuesday, 7 April 2009 7:48 PM
To: Oliver Boehmer (oboehmer); cisco-bba@puck.nether.net; Andy Saykao
Subject: RE: [cisco-bba] Help with VPDN Group config


Thanks for clearing that up Oli.

I reserve the right to be both correct and incorrect, depending on IOS
version in use :)


regards,
Tony.

--- On Tue, 7/4/09, Andy Saykao <andy.saykao@staff.netspace.net.au>
wrote:

> From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> Subject: RE: [cisco-bba] Help with VPDN Group config
> To: "Oliver Boehmer (oboehmer)" <oboehmer@cisco.com>, "Tony"
> <td_miles@yahoo.com>, cisco-bba@puck.nether.net
> Date: Tuesday, 7 April, 2009, 6:32 PM
> 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@cisco.com]
>
> Sent: Tuesday, 7 April 2009 5:56 PM
> To: Tony; cisco-bba@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@staff.netspace.net.au>
> > wrote:
> >
> >> From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> >> Subject: [cisco-bba] Help with VPDN Group config
> >> To: cisco-bba@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@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.
>
>




______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Hi Andy,

I'd suggest you wait for a better/official answer, but my best bet would be scenario2 (ie. it is matching the source IP address even though the command to check doesn't exist).

I don't think it would try another group simply because it failed authentication. If auth failed, then I would expect it to retry a couple of times on the default group and then fail the L2TP setup.

This is just a guess though based on the logic you would normally see in Cisco IOS about what happens if a connection fails auth (think ISDN or dialer interfaces).


regards,
Tony.

--- On Wed, 8/4/09, Andy Saykao <andy.saykao@staff.netspace.net.au> wrote:

> From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> Subject: RE: [cisco-bba] Help with VPDN Group config
> To: "Tony" <td_miles@yahoo.com>, "Oliver Boehmer (oboehmer)" <oboehmer@cisco.com>, cisco-bba@puck.nether.net
> Date: Wednesday, 8 April, 2009, 10:07 AM
> Any ideas how to determine if the IOS
> uses the source-ip under the
> vpdn-group config as an additional criteria for handling
> incoming LAC
> requests. Reading the docos it appears that the command
> "show vpdn
> group-select" is only available with the 12.4(20)T
> release.
>
> The ASR's I mention (122-33.XNB3) that have individual
> vpdn-group
> configs without the "terminate-from hostname" are
> terminating L2TP
> sessions properly from their respective LACs - but the
> command "show
> vpdn group-select" is not enabled with this IOS release
> either. So in
> this scenario, is the ASR using the source-ip to determine
> which
> vpdn-group handles the incoming LAC request (scenario 2) or
> could it be
> that because the default vpdn-group has the wrong l2tp
> tunnel password
> set (because it's for a different provider) that the
> incoming LAC
> request tries another vpdn-group that also does not
> "terminate-from
> hostname" set (scenario 1)???
>
> Scenario 1/
>
> - LAC request comes in - is there a hostname configured on
> the LNS in
> the vpdn-group that matches my hostname, if so use this
> vpdn-group.
> - No hostname exists, use the default vpdn-group.
> - The LAC can't establish a tunnel with the default
> vpdn-group (eg:
> mismatch l2tp tunnel password), then try another vpdn-group
> which does
> not have any "terminate-from hostname" configured.
>
> Scenario 2/
>
> - LAC request comes in - is there a hostname configured on
> the LNS in
> the vpdn-group that matches my hostname, if so use this
> vpdn-group.
> - Is there a vpdn-group that has the source-ip that matches
> the
> destination IP that the LAC is trying to initiate a tunnel
> with, if so
> use this vpdn-group.
> - No hostname match, no source-ip match, use default
> vpdn-group then.
>
>
>
>
> -----Original Message-----
> From: Tony [mailto:td_miles@yahoo.com]
>
> Sent: Tuesday, 7 April 2009 7:48 PM
> To: Oliver Boehmer (oboehmer); cisco-bba@puck.nether.net;
> Andy Saykao
> Subject: RE: [cisco-bba] Help with VPDN Group config
>
>
> Thanks for clearing that up Oli.
>
> I reserve the right to be both correct and incorrect,
> depending on IOS
> version in use :)
>
>
> regards,
> Tony.
>
> --- On Tue, 7/4/09, Andy Saykao <andy.saykao@staff.netspace.net.au>
> wrote:
>
> > From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> > Subject: RE: [cisco-bba] Help with VPDN Group config
> > To: "Oliver Boehmer (oboehmer)" <oboehmer@cisco.com>,
> "Tony"
> > <td_miles@yahoo.com>,
> cisco-bba@puck.nether.net
> > Date: Tuesday, 7 April, 2009, 6:32 PM
> > 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@cisco.com]
> >
> > Sent: Tuesday, 7 April 2009 5:56 PM
> > To: Tony; cisco-bba@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@staff.netspace.net.au>
> > > wrote:
> > >
> > >> From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> > >> Subject: [cisco-bba] Help with VPDN Group
> config
> > >> To: cisco-bba@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@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.
> >
> >
>
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email
> Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>




_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

For those interested, on our ASR running 12.2(33)XNB3, no default
vpdn-group is selected when all the vpdn-groups have a source-ip
configured.

This is my original vpdn-group config on the ASR. Notice how vpdn-group
nsdial has no source-ip set, and has been selected as the default
vpdn-group.

vpdn-group PROVIDER1-VPDN-GROUP-1
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 nsdial
! 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

When I add a source-ip to vpdn-group nsdial, the IOS no longer elects a
default vpdn-group. See how it's taken off the description "! Default
L2TP VPDN group" from vpdn-group nsdial.

vpdn-group PROVIDER1-VPDN-GROUP-1
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 nsdial
description Soul Dialup Connections
accept-dialin
protocol l2tp
virtual-template 3
source-ip 203.17.101.y
lcp renegotiation on-mismatch
l2tp tunnel password WWWXXXYYYZZZ
l2tp tunnel receive-window 100
l2tp tunnel retransmit timeout min 2

Cheers.

Andy


-----Original Message-----
From: Tony [mailto:td_miles@yahoo.com]
Sent: Tuesday, 7 April 2009 7:48 PM
To: Oliver Boehmer (oboehmer); cisco-bba@puck.nether.net; Andy Saykao
Subject: RE: [cisco-bba] Help with VPDN Group config


Thanks for clearing that up Oli.

I reserve the right to be both correct and incorrect, depending on IOS
version in use :)


regards,
Tony.

--- On Tue, 7/4/09, Andy Saykao <andy.saykao@staff.netspace.net.au>
wrote:

> From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> Subject: RE: [cisco-bba] Help with VPDN Group config
> To: "Oliver Boehmer (oboehmer)" <oboehmer@cisco.com>, "Tony"
> <td_miles@yahoo.com>, cisco-bba@puck.nether.net
> Date: Tuesday, 7 April, 2009, 6:32 PM
> 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@cisco.com]
>
> Sent: Tuesday, 7 April 2009 5:56 PM
> To: Tony; cisco-bba@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@staff.netspace.net.au>
> > wrote:
> >
> >> From: Andy Saykao <andy.saykao@staff.netspace.net.au>
> >> Subject: [cisco-bba] Help with VPDN Group config
> >> To: cisco-bba@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@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.
>
>




______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba