Yup you are correct, we started on a late 12.3 train of code (cant remember which) and must have gone through half a dozen upgrades of all the spokes up to the current 12.4 (11) in the process of getting to a stable DMVPN environment, we even managed to find numerous bugs in code that cisco was previously unaware of =) which is always nice.
These ranged from NHRP registration issues (as you suggested), cef adjaencies disappearing, incompatible NAT versions during the IKE process. Generally a whole lot of fun NOT!!! No matter what code we used we still see a number of tunnel drops, due to SA dropping at the spoke, but staying up at the hub, possibly due to the unstable WAN. We now use event manager to overcome this. Basically clearing the SAs whenever we see the EIGRP neighbor drop in the log. 2009/7/21 Pieter-Jan Nefkens <[email protected]> > Hi Stuart, > Ok. I use the stub connectivity in most of my endpoints. Timers, yes, with > WAN connections (specifically with DMVPNs over Internet) that is key. But I > wouldn't expect EIGRP flapping in a lab environment, that was why i was > thinking of the routing process. > > But most of my DMVPN's also allow spoke-spoke communication to allow on-net > IPT calls between the sites... It's mostly phase 2, but I'm working with > Phase 3. Problem is that if you use the DMVPN hub for site-to-site tunnels > (to partners, etc) as well, it's better to use certificates for the ISAKMP > authentication of the DMVPN's. > And that takes some time before you implement that in a live environment... > > But thanks for the update. As said, my main DMVPN's also allow spoke-spoke > communication. But I do remember that some IOS versions (around 12.4T.20 or > something around there) had some issues with NHRP registrations getting > lost, and therefore the EIGRP peers not seeing eachother. > > Could be a bug as well > > Pieter-Jan > > On 21 jul 2009, at 21:52, Stuart Hare wrote: > > I suppose it would depend on the scenario, but basically I would say no > these would not be an essential requirement. > > EIGRP Stub can be used to provide stability within the eigrp process, but > on the other hand my company is running a multi-hub redundant DMVPN phase 2 > environment with approx 20-25 spokes, no spoke to spoke traffic is used, and > we dont use any of the mentioned settings. > > With exception of EIGRP timers of course, which we had to increase due to > the BT WAN running like a dog at times =) > > Stu > > 2009/7/21 Pieter-Jan Nefkens <[email protected]> > >> Hello Stuart, >> Thanks for the update. I read some further (I almost always configure both >> timers as well), and indeed these options are needed for spoke-spoke >> communication. But now from the top of my head, if you don't want to have >> spoke-spoke communication (whether it's DMVPN Phase 3 with shortcut >> switching or via the hub), wouldn't you need to configure stub routing on >> the EIGRP spokes? >> Otherwise, the EIGRP process wants to setup full EIGRP routing and that >> might cause the EIGRP flapping as well? >> >> Just an idea that came to my mind... >> >> Pieter-Jan >> >> On 21 jul 2009, at 21:14, Stuart Hare wrote: >> >> Pieter, >> >> I would agree that these are required for certain DMVPN scenarios, but not >> necessarily important in Simons case. >> These settings are only required in DMVPN if you wish to allow direct >> spoke to spoke tunnels, i.e. to prevent spoke to hub to spoke traffic. If >> the task or scenario does not require spoke to spoke tunnels then these >> settings are not required in the configuration. >> Simon, you may need to adjust your eigrp timers if your DMVPN runs across >> some poor performance wan links for instance ( we have had to do just this >> in a production DMVPN environment ), but if this is a lab scenario then I >> would be surprised. >> >> Are you doing this in dynamips perhaps? >> >> Stu >> 2009/7/21 Pieter-Jan Nefkens <[email protected]> >> >>> Hi Simon, >>> >>> The hold-timers are not that important, yes, you need to change them, but >>> mainly in very large-scale deployments. >>> More important is to disable the split-horizon and the next-hop-self >>> option. >>> >>> Check the DMVPN Design guide at >>> >>> http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008075ea98.pdf >>> >>> Page 2-18, EIGRP configuration explains it all >>> >>> Kind regards >>> Pieter-Jan >>> >>> >>> >>> On 21 jul 2009, at 18:46, Simon Baumann wrote: >>> >>> I don't have it anymore, unfortunately. But I can rebuild it. Isakmp >>>> policy, Ipsec policy, >>>> eigrp process,tunnel + loopback interfaces are enough? >>>> >>>> Cheers >>>> Simon >>>> >>>> >>>> Am 21.07.2009 um 18:38 schrieb Tyson Scott: >>>> >>>> Simon can you post your configuration. >>>>> >>>>> Regards, >>>>> >>>>> Tyson Scott - CCIE #13513 R&S and Security >>>>> Technical Instructor - IPexpert, Inc. >>>>> >>>>> Telephone: +1.810.326.1444 >>>>> Cell: +1.248.504.7309 >>>>> Fax: +1.810.454.0130 >>>>> Mailto: [email protected] >>>>> >>>>> Join our free online support and peer group communities: >>>>> http://www.IPexpert.com/communities<http://www.ipexpert.com/communities> >>>>> >>>>> IPexpert - The Global Leader in Self-Study, Classroom-Based, Video >>>>> On Demand >>>>> and Audio Certification Training Tools for the Cisco CCIE R&S Lab, >>>>> CCIE >>>>> Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE >>>>> Storage >>>>> Lab Certifications. >>>>> >>>>> -----Original Message----- >>>>> From: [email protected] >>>>> [mailto:[email protected]] On Behalf Of Simon >>>>> Baumann >>>>> Sent: Tuesday, July 21, 2009 4:50 AM >>>>> To: [email protected] >>>>> Subject: [OSL | CCIE_Security] DMVPN: question about EIGRP holdtime. >>>>> >>>>> Hi, >>>>> I used OWLE Lab2 for testing an DMVPN setup. R5 was my hub, R4 and R6 >>>>> served as spokes. I added an loopback interface to every router, used >>>>> EIGRP for routing in the DMVPN. >>>>> Without manipulating the holdown timers, I had flipping EIGRP >>>>> adjacencies. I'm not 100% sure which holdown timers I have to >>>>> manipulate: only the EIGRP, the nhrp or both? >>>>> >>>>> Cheers >>>>> Simon >>>>> >>>>> _______________________________________________ >>>>> For more information regarding industry leading CCIE Lab training, >>>>> please >>>>> visit www.ipexpert.com >>>>> >>>>> >>>> _______________________________________________ >>>> For more information regarding industry leading CCIE Lab training, >>>> please visit www.ipexpert.com >>>> >>> >>> --- >>> Nefkens Advies >>> Enk 26 >>> 4214 DD Vuren >>> The Netherlands >>> >>> Tel: +31 183 634730 >>> Fax: +31 183 690113 >>> Cell: +31 654 323221 >>> Email: [email protected] >>> Web: http://www.nefkensadvies.nl/ >>> >>> >>> Think before you print. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> For more information regarding industry leading CCIE Lab training, please >>> visit www.ipexpert.com >>> >>> >> >> >> -- >> _________________________ >> >> Stuart Hare >> [email protected] >> _________________________ >> >> >> --- >> Nefkens Advies >> Enk 26 >> 4214 DD Vuren >> The Netherlands >> >> Tel: +31 183 634730 >> Fax: +31 183 690113 >> Cell: +31 654 323221 >> Email: [email protected] >> Web: http://www.nefkensadvies.nl/ >> >> <green.gif> Think before you print. >> >> >> >> > > > -- > _________________________ > > Stuart Hare > [email protected] > _________________________ > > > --- > > Nefkens Advies > > Enk 26 > > 4214 DD Vuren > > The Netherlands > > > Tel: +31 183 634730 > > Fax: +31 183 690113 > > Cell: +31 654 323221 > > Email: [email protected] > > Web: http://www.nefkensadvies.nl/ > > Think before you print. > > > > -- _________________________ Stuart Hare [email protected] _________________________
<<green.gif>>
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
