Not sure if this helps:

Known Limitations Summary for Spoke-to-Spoke Deployment Model

This section describes at a high level the known limitations for a dual DMVPN cloud topology with the spoke-to-spoke deployment. These known limitations should be considered in addition to the known limitations for hub-and-spoke deployments.

The following are general limitations:

ODR cannot be used in spoke-to-spoke topologies.

OSPF is not recommended as a routing protocol in a spoke-to-spoke deployment model because of scaling limitations. For more information, see Chapter 3, "Scalability Considerations."

The following is a headend limitation:

mGRE and IPsec source and destination IP addresses must be identical for spoke-to-spoke mode to function, which is not possible with a Dual Tier Headend Architecture.

The following are branch office limitations:

Very limited QoS can be provided between spokes. Therefore, latency-sensitive applications such as VoIP and video are considered "best effort" in spoke-to-spoke DMVPN deployments.

Dynamic routing is not exchanged between spokes over a spoke-to-spoke tunnel. As a result, communication can be lost without knowing the tunnel is down.

Spokes behind a pNAT device cannot establish spoke-to-spoke tunnels.

No IP multicast traffic can be exchanged between spokes. <--- ????

In a spoke-to-spoke topology, any traffic can bring an IPsec tunnel to another branch in that DMVPN cloud. Because this is done at the L3 (routing) level, any IP unicast traffic can then transit over that spoke-to-spoke tunnel. This may be a security issue for some deployments because viruses, worms, or attack software may spread branch-to-branch without the headend as a check point. Other protection mechanisms such as IPS should be implemented at every branch that is spoke-to-spoke capable.

IKE CAC has limitations as well as the maximum number of ISAKMP SA per branch platform. For more information, seeIKE Call Admission Control, page 2-10.






On Jul 30, 2010, at 2:22 PM, Tyson Scott wrote:

Aaron,
 
You would have to re-establish flows but not neighbors.  In a hub and spoke environment you have to run sparse mode.  Dense mode isn't an option as well, in regards to your first email.
 
There are times you will see timeouts when just doing testing in a normal Ethernet network.  I would recommend getting a real stream going and see if it works for you.  I believe based on your comments so far, it should work.
 
Regards,
 
Tyson Scott - CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor - IPexpert, Inc.
Telephone: +1.810.326.1444, ext. 208
Live Assistance, Please visit: www.ipexpert.com/chat
eFax: +1.810.454.0130
 
IPexpert is a premier provider of Self-Study Workbooks, Video on Demand, Audio Tools, Online Hardware Rental and Classroom Training for the Cisco CCIE (R&S, Voice, Security & Service Provider) certification(s) with training locations throughout the United States, Europe, South Asia and Australia. Be sure to visit our online communities at www.ipexpert.com/communities and our public website at www.ipexpert.com
 
From: Aaron Moreck [mailto:[email protected]] 
Sent: Friday, July 30, 2010 2:11 PM
To: Tyson Scott
Cc: [email protected]
Subject: Re: [OSL | CCIE_RS] PIM-SM on DMVPN
 
I tried with and without that with the same results.  Do you have to re-establish pim neighbor relationships after changing that?


 
On Fri, Jul 30, 2010 at 2:03 PM, Tyson Scott <[email protected]> wrote:
Do you have ip pim nbma-mode on the hub interface.
 
Regards,
 
Tyson Scott - CCIE #13513 R&S, Security, and SP
Managing Partner / Sr. Instructor - IPexpert, Inc.
Telephone: +1.810.326.1444, ext. 208
Live Assistance, Please visit: www.ipexpert.com/chat
eFax: +1.810.454.0130
 
IPexpert is a premier provider of Self-Study Workbooks, Video on Demand, Audio Tools, Online Hardware Rental and Classroom Training for the Cisco CCIE (R&S, Voice, Security & Service Provider) certification(s) with training locations throughout the United States, Europe, South Asia and Australia. Be sure to visit our online communities atwww.ipexpert.com/communities and our public website at www.ipexpert.com
 
From: [email protected] [mailto:[email protected]] On Behalf Of Aaron Moreck
Sent: Friday, July 30, 2010 1:44 PM
To: [email protected]
Subject: [OSL | CCIE_RS] PIM-SM on DMVPN
 
Hello i am configuring PIM-SM on a DMVPN.  We also have an ASA5510 in the mix. 
The topology is as follows:
 
 
 
 
 
DMVPN Spokes (Remotes)--------------------       DMVPN Hub Router-------------Cisco ASA 5510-----------Cat3560
 
 
Most of the Multicast traffic would be sourced from a server attached to a vlan on the Cat3560 and destined to members on the DMVPN remote sites.
 
I used static RP assignement on all devices making the RP the DMVPN Hub router.    I chose this because the ASA does not support Auto RP or BSR.  Also a note that the ASA does not support Dense-Mode.
 
One of the issues i am having that i am most interested about is that if i use the "ip igmp join "  on one of the DMVPN Spokes (remote sites)  and i try to ping the multicast group from the network on the 3560 it works like a charm.  However if i ping that same address from a DMVPN spoke the ping ususall succedes two times then fails.     I am assuming this is tied to when the dynamic tunnel is brought up between the spokes. 
 
Does anyone have any ideas of the top of their heads regarding this before i need to post configurations?
 
Thanks
 
Aaron
 
 
 
 
 
 
 
 
 
 
_______________________________________________
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

Reply via email to