Re: RSVP Split-Horizon and DMVPN Phase 3

Thanks everyone for your replies. After doing more research I found out a
way to run RSVP over DMVPN without keeping the tunnels up all of the time.
It solves the RSVP loop prevention problem with a nice workaround.

My solution is changing the next hop and using reliable RSVP. For those
interested I wrote a detailed explanation at
http://kemot-net.com/blog/making-rsvp-work-over-dvmpn

Thanks

Tom KacprzyEski
CCIE#36159

On Thursday, July 11, 2013, Jay McMickle wrote:

> Tom-
> I've quickly skimmed through this thread, and while I do not have
> experience with RSVP, I agree with keeping the tunnels up. We typically
> control this with DPD (crypto keepalives). We've got about 40 tunnels with
> this setup. We actually use EIGRP (best practice with DMVPN) stub, stub
> summary, or some tweak of it as needed (for back door routes).
>
> In short, I would recommend keeping the the tunnels up with keepalives,
> but by default they are not on and the timeout is 1 day.
>
> Hit me up if you want to talk further. To state you are using phase 3,
> that states you are using redirects, shortcuts, and no EIGRP split-horizon.
>
> HTH.
>
> Regards,
> Jay McMickle- 2x CCIE #35355 (R/S,Sec)
> Sent from my iPhone 5
>
> On Jul 11, 2013, at 5:15 PM, "Joseph L. Brunner"
<joe_at_affirmedsystems.com<javascript:;>>
> wrote:
>
> > Its a good idea to keep spoke to spoke tunnels up at all times - are you
> bandwidth constrained?
> >
> > I had about 50 sites when dmvpn phase 3 came out (now only client still
> on dmvpn has 6 sites).
> >
> > We used no summaries and each spoke had the 45+ neighbors in eigrp on
> tun1 and tun2
> >
> > That's why we use eigrp - no concept of dr/bdr to keep spokes (or
> drothers) quiet.
> >
> > Another way to keep spoke to spoke up with 50 sites is a painful sla
> config of pings I guess on what? 25 of them? Lol
> >
> > I would do that in a second through to stop one annoying user calling me
> :)
> >
> > Joe
> >
> >
> > From: Tom Kacprzynski [mailto:tom.kac_at_gmail.com <javascript:;>]
> > Sent: Thursday, July 11, 2013 06:09 PM
> > To: Joseph L. Brunner
> > Cc: Cisco certification <ccielab_at_groupstudy.com <javascript:;>>
> > Subject: Re: RSVP Split-Horizon and DMVPN Phase 3
> >
> > I'm running EIGRP. What is it about EIGRP that you think would be
> beneficial in this case?
> >
> > I don't think keeping up the spoke tunnels up is a very scalable
> solution for me since I have about 50+ sites.
> >
> > How many sites did you have? What did you use to keep the tunnels up?
> >
> > I just started testing a solution with disabling the EIGRP next hop
> override and not using summary routes but detailed spoke prefixes on the
> hubs interface. I think that might work but still have to test it with
> voice. I had some RSVP drops but eventually got the reservation working. I
> am afraid that might not work for voice, but have to test it tomorrow. I
> think DMVPN phase 2 would work for sure, but I can't change that.
> >
> > Thanks
> >
> > Tom
> >
> >
> >
> >
> >
> >
> >
> > On Thursday, July 11, 2013, Joseph L. Brunner wrote:
> > You should Endeavor to keep the spoke to spoke tunnels up at all times
> then...
> >
> > That's what I used to do -
> >
> > Best way to do that - is just put the tunnel interfaces (which are ALL
> on the same subnet anyway) into Eigrp.
> >
> > You are running EIGRP, right?
> >
> > Or did you get fooled into running OSPF by one of the workbooks?
> >
> > LOL
> >
> > -----Original Message-----
> > From: nobody_at_groupstudy.com <javascript:;><javascript:;> [mailto:
> nobody_at_groupstudy.com <javascript:;><javascript:;>] On Behalf Of Tom
> Kacprzynski
> > Sent: Thursday, July 11, 2013 4:08 PM
> > To: Cisco certification
> > Subject: RSVP Split-Horizon and DMVPN Phase 3
> >
> > Hello,
> > I'm running DMVPN with Phase 3 with RSVP enabled on tunnel interfaces.
> In phase 3 everything is initially routed through the hub, then redirected
> to spoke-to-spoke . The problem is that my DMVPN Hub will not forward the
> RSVP packets out the same tunnel interface it received the original message
> because of the RSVP split-horizon rule. If the spoke-to-spoke tunnel gets
> triggered by another traffic type, then RSVP works. The problem is that
> RSVP messages are send first before sending any voice RTP packets. If the
> RSVP reservation fails (cause of the split horizon rule) then there are no
> additional packets sent and spoke-to-spoke tunnels aren't dynamically
> created.
> >
> > Has anyone else see something similar or would be able to help me
> resolve this issue?
> >
> > Thank you,
> >
> > Tom Kacprzynski
> > CCIE#36159
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Thu Aug 15 2013 - 08:12:16 ART