td_miles at yahoo
Apr 7, 2009, 5:38 PM
Post #11 of 12
(4219 views)
Permalink
|
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 [at] staff> wrote:
> From: Andy Saykao <andy.saykao [at] staff>
> Subject: RE: [cisco-bba] Help with VPDN Group config
> To: "Tony" <td_miles [at] yahoo>, "Oliver Boehmer (oboehmer)" <oboehmer [at] cisco>, cisco-bba [at] puck
> 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 [at] yahoo]
>
> Sent: Tuesday, 7 April 2009 7:48 PM
> To: Oliver Boehmer (oboehmer); cisco-bba [at] puck;
> 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 [at] staff>
> wrote:
>
> > From: Andy Saykao <andy.saykao [at] staff>
> > Subject: RE: [cisco-bba] Help with VPDN Group config
> > To: "Oliver Boehmer (oboehmer)" <oboehmer [at] cisco>,
> "Tony"
> > <td_miles [at] yahoo>,
> cisco-bba [at] puck
> > 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 [at] cisco]
> >
> > Sent: Tuesday, 7 April 2009 5:56 PM
> > To: Tony; cisco-bba [at] puck;
> > 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 [at] staff>
> > > wrote:
> > >
> > >> From: Andy Saykao <andy.saykao [at] staff>
> > >> Subject: [cisco-bba] Help with VPDN Group
> config
> > >> To: cisco-bba [at] puck
> > >> 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 [at] puck
> > > 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 [at] puck
https://puck.nether.net/mailman/listinfo/cisco-bba
|
