Also if you guys have any further questions about it I finally feel pretty
comfortable with it.  I know I had some misunderstands with it early on too.

 

But we run MPLS L2 and L3 VPN over DMVPN over the internet.  We run remote
CCIE Voice classes over it.  It works great.  Multicast can saturate our
internet connection if we aren't careful but I can say it definitely works.
We are also running SSM to allow our Multicast VPN tunnels over it as well.
So we have a very in depth implementation of DMVPN.  Phase 3 fixed a lot of
our early problems.  This is also all done using lowly 2811's as well so it
doesn't take big beefy routers to run a fairly large or complex scenario.

 

Regards,

 

Tyson Scott - CCIE #13513 R&S, Security, and SP

Managing Partner / Sr. Instructor - IPexpert, Inc.

Mailto:  <mailto:[email protected]> [email protected]

Telephone: +1.810.326.1444, ext. 208

Live Assistance, Please visit:  <http://www.ipexpert.com/chat>
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
<http://www.ipexpert.com/communities> www.ipexpert.com/communities and our
public website at  <http://www.ipexpert.com/> www.ipexpert.com

 

From: Tyson Scott [mailto:[email protected]] 
Sent: Friday, July 30, 2010 8:26 PM
To: 'Rogelio Gamino'
Cc: 'Aaron Moreck'; '[email protected]'
Subject: RE: [OSL | CCIE_RS] PIM-SM on DMVPN

 

Rogelio,

 

I wasn't correcting you I was correcting the reference :)

 

Here is a good introduction to phase 3

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6660/ps6
808/prod_white_paper0900aecd8055c34e_ps6658_Products_White_Paper.html

 

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
<http://www.ipexpert.com/> 

 

From: Rogelio Gamino [mailto:[email protected]] 
Sent: Friday, July 30, 2010 7:04 PM
To: Tyson Scott
Cc: 'Aaron Moreck'; [email protected]
Subject: Re: [OSL | CCIE_RS] PIM-SM on DMVPN

 

Where did all that come from? I just copied and pasted the whole section
where it stated multicast does not work between sites and specifically
pointed to a specific line so he can find the info on the link I included
and do more research.

 

I've implemented DMVPN before but that was a little over 3.5 years ago. That
implementation is still running over an MPLS network but there is not
multicast traffic on the network. Never had to touch it after that.

 

Also, a couple of years ago I did some research on multicast over DMVP and
remember running into some issues. Most of the documents I read at the time
stated that multicast did work but I remember running into some issues.
Can't remember the details. Now you're making me do some research...
Grrrrr!!!  ;)

 

 

Thanks,

Rogelio Gamino

 

 

 

 

On Jul 30, 2010, at 5:24 PM, Tyson Scott wrote:

 

Rogelio,

 

Some of this is out of date.

 

As of DMVPN phase 3 OSPF using network type point-to-multipoint IS the
recommended protocol to use.

ODR can be used with phase 3 for spoke-to-spoke topologies but OSPF is the
recommended method.  phase 3 doesn't rely on the RIB for deciding where to
send traffic.

Multi-head end-point limitation is no longer applicable with phase 3

QoS is dependent on the service you have from the provider.  If you are
doing DMVPN over a MPLS network then you can rely on the service SLA's of
the provider and QoS will function accordingly.  Over the internet the QoS
limitations are not guaranteed whether it is a spoke-to-spoke or
spoke-to-hub communication.

Phase 3 relies on NHRP shortcut switching.  All mapping is maintained by the
Hub.  If the hub looses the route then the shortcut switching will not
occur.  Thus the reason for the recommended OSPF point-to-multipoint
solution.

Not sure about Multicast not working between spokes.  I am surprised by
that.  I do not believe that to be the case.

The Virus problem is pointless as any inter-site communication would have
that concern.  Thus the reason to use MQC and Access-lists to control
traffic.

I don't understand the point of IKE Call Admission Control.  The purpose of
CAC is to limit the number of SPI's that can be established per device.
Each device can support different amounts based on the performance
capability of the router.  This would be something you take into account as
you consider the design to decide which hardware platforms you need to use.
But in real deployment scenarios with the right platform Cisco routers can
support hundreds even thousands, with a very high end router, dynamic
tunnels.

 

Rogelio it seems you are not very familiar with DMVPN?  The information
below is old information that is no longer applicable.

 

To sum up my statements above, make sure you are using phase 3.

 

 

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
<http://www.ipexpert.com/> 

 

From: Rogelio Gamino [mailto:[email protected]] 
Sent: Friday, July 30, 2010 2:39 PM
To: Tyson Scott
Cc: 'Aaron Moreck'; [email protected]
Subject: Re: [OSL | CCIE_RS] PIM-SM on DMVPN

 

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:

.<image001.gif>ODR cannot be used in spoke-to-spoke topologies.

.<image001.gif>OSPF is not recommended as a routing protocol in a
spoke-to-spoke deployment model because of scaling limitations. For more
information, see
<http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/DMVPN_3.ht
ml#wpxref91566> Chapter 3, "Scalability Considerations."

The following is a headend limitation:

.<image001.gif>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:

.<image001.gif>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.

.<image001.gif>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.

.<image001.gif>Spokes behind a pNAT device cannot establish spoke-to-spoke
tunnels.

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

.<image001.gif>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.

.<image001.gif>IKE CAC has limitations as well as the maximum number of
ISAKMP SA per branch platform. For more information, see
<http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/DMVPN_2_Ph
ase2.html#wpxref18498> IKE Call Admission Control, page 2-10.

 

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/DMVPN_1.htm
l#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
<http://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
atwww.ipexpert.com/communities and our public website at www.ipexpert.com
<http://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