Hmm thats a bummer.. I could think of a few ways to get that to work in a lab environment but nothing that woudl be scalable for production use. Anyone have any ideas for a solution for a production environment?
On Fri, Jul 30, 2010 at 2:38 PM, Rogelio Gamino <[email protected]> wrote: > 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."<http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/DMVPN_3.html#wpxref91566> > > 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<http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/DMVPN_2_Phase2.html#wpxref18498> > . > > > http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/DMVPN_1.html#wp37232 > > > > > 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. > Mailto: [email protected] > 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. > Mailto: [email protected] > 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:* [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 > > >
<<blank.gif>>
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
