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 <[email protected]> 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 <[email protected]> > To: Christophe LUCAS <[email protected]> > Cc: ar <[email protected]>; cisco-nsp <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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) <[email protected]> >>> To: ar <[email protected]>; cisco-nsp <[email protected]> >>> 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:[email protected]] >>> 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) <[email protected]> >>> To: ar <[email protected]>; cisco-nsp <[email protected]> >>> 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: [email protected] >>> [mailto:[email protected]] 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 [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>> _______________________________________________ >>> cisco-nsp mailing list [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
