Hi Stu,
Hi Pieter-Jan,
Hi Tyson,
I used ProctorLabs. I scheduled a session for tomorrow, so I'm going
to resetup my lab and post my configuration before/ater EIGRP tuning.
That's the easiest way. Thanks,
Cheers
Simon
Am 21.07.2009 um 22:34 schrieb Stuart Hare:
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
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/
<green.gif> Think before you print.
--
_________________________
Stuart Hare
[email protected]
_________________________
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
