[c-nsp] 7206 LNS/L2TP using HSRP

Sat May 12 19:22:45 EDT 2012

My personal experience revolves around using loopback IPs for
source/destination of L2TP sessions. So with HSRP you'd have to use
the source/dest as the virtual IP of HSRP, right? The upstream LAC/LTS
would then contact the active LNS based on where the HSRP virtual IP
is living, and when it fails and the standby one takes over as the
active HSRP box the upstream LAC then contacts it instead.

I dunno, but to me thats not my kind of redundancy. I'd rather load
balance sessions across the two LNS via built in mechanisms in the
upstream LAC/LTS than IP trickery. HSRP is more of a gateway
redundancy mechanism for the office or server LAN.

All IMO of course. :-)

If youre looking at this route, maybe GLBP would be better? If there
are multiple upstream LAC/LTS, then each one will theoretically land
on a different LNS, as opposed to one or the other. *IIRC* HSRP is
Active-Standby, whereas GLBP can do Active-Active. Or maybe that was
VRRP... Bah, its late and I want to go to bed. :-)

On 7 May 2012 08:56, ar <ar_djp at yahoo.com> wrote:
> Hi Tom.
> Yes, we'll surely do the LAC-LNS balancing.
> I'm just exploring in using HSRP for redundancy.
> Getting some ideas from you guys if this is advisable.
>
> ________________________________
> From: Tom Storey <tom at snnap.net>
> To: Christophe LUCAS <christophe at clucas.fr>
> Cc: ar <ar_djp at yahoo.com>; cisco-nsp <cisco-nsp at puck.nether.net>
> Sent: Monday, May 7, 2012 5:32 AM
>
> Subject: Re: [c-nsp] 7206 LNS/L2TP using HSRP
>
> You can/should be able to configure the upstream LAC/LTS to load
> balance sessions across the two LNSs. Is there a particular reason why
> you dont want to do this?
>
> In the case of one LNS failing, all sessions from that LNS would drop
> and be re-established onto the remaining LNS by the upstream device.
> When the failed LNS is restored, new sessions will be load balanced
> across the two again, and you can then even out the load by dropping
> sessions from the fully loaded LNS manually.
>
> At least in this scenario, you can minimise the amount of disruption
> to roughly 50% of your sessions, instead of all of them - and more
> specifically, only to those that actually "notice".
>
> Tom
>
>
> On 5 May 2012 16:33, Christophe LUCAS <christophe at clucas.fr> wrote:
>> Hi,
>>
>> Perhaps i Will Say a mistake, but why do not you use radius account type
>> to accure thé sécurity of your ppp sessions With two l2tp tunnels.
>>
>> Best regards,
>> --
>> Christophe
>>
>> Envoyé de mon téléphone, veuillez excuser ma brièveté.
>>
>> Le 4 mai 2012 à 11:09, ar <ar_djp at yahoo.com> a écrit :
>>
>>> Yeah right...good info.
>>> thanks.
>>>
>>> What if HSRP doesnt have preempt so it wont switch back after a failure?
>>>
>>> Im thinking of dual protection.
>>> LACs has two initiate-to commands for 2 LNS.
>>> Then LNS with HSRP without preempt.
>>>
>>> any thoughts?
>>>
>>>
>>>
>>>
>>> ________________________________
>>> From: Arie Vayner (avayner) <avayner at cisco.com>
>>> To: ar <ar_djp at yahoo.com>; cisco-nsp <cisco-nsp at puck.nether.net>
>>> Sent: Friday, May 4, 2012 12:42 AM
>>> Subject: RE: [c-nsp] 7206 LNS/L2TP using HSRP
>>>
>>>
>>> With HSRP, every time you do a failover, all sessions would drop, and
>>> have to be reestablished.
>>>
>>> Using the redundancy model, you can have graceful recovery and switchover
>>> if you want to control it.
>>>
>>> For example, if you had a failure, and one LNS went down, all sessions
>>> would reestablish on the 2nd one (that is the same as in HSRP), but now when
>>> the other box comes up it does not drop all the sessions again and switches
>>> them back.
>>> Only new sessions would be sent to the recovered LNS, and you can move
>>> the other sessions during a maintenance window…
>>>
>>> Actually, I would just suggest running them in active/active mode. This
>>> way you actually know they are both up and running and do not have to worry
>>> about making sure the backup is ready…
>>>
>>> Arie
>>>
>>> From:ar [mailto:ar_djp at yahoo.com]
>>> Sent: Thursday, May 03, 2012 07:27
>>> To: Arie Vayner (avayner); cisco-nsp
>>> Subject: Re: [c-nsp] 7206 LNS/L2TP using HSRP
>>>
>>> Thanks Arie.
>>>
>>> Any disadvantage of using HSRP compared to multiple initiate-to commands
>>> on the LAC?
>>> I want HSRP due to the reason i can control who is the active and standby
>>> LNS.
>>> LNS  is mine, while LAC is on the access provider side.
>>>
>>> thanks
>>>
>>>
>>> ________________________________
>>>
>>> From:Arie Vayner (avayner) <avayner at cisco.com>
>>> To: ar <ar_djp at yahoo.com>; cisco-nsp <cisco-nsp at puck.nether.net>
>>> Sent: Thursday, May 3, 2012 7:09 PM
>>> Subject: RE: [c-nsp] 7206 LNS/L2TP using HSRP
>>>
>>> Better use discrete IP addresses. Loopbacks are mostly recommended.
>>> On your LAC you can specify multiple IPs (that can come from RADIUS...).
>>>
>>> This would allow you to load share, running your LNSs in Act/Act mode...
>>>
>>> Look here:
>>>
>>> http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800a43e9.shtml#wp1002265
>>>
>>> Arie
>>>
>>> -----Original Message-----
>>> From: cisco-nsp-bounces at puck.nether.net
>>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of ar
>>> Sent: Thursday, May 03, 2012 00:37
>>> To: cisco-nsp
>>> Subject: [c-nsp] 7206 LNS/L2TP using HSRP
>>>
>>> Guys,
>>>
>>>
>>> I'm planning to terminate L2TP to LNS using HSRP.
>>> So there will be LNS redundancy.
>>> Is this possible?
>>> I've read that terminating L2TP to the HSRP address has some issues.
>>>
>>> Or better to use multiple initiate-to commands on the LAC?
>>> Any other options for fail-over/redundancy?
>>>
>>> thanks
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>