From: Thomas Renzy (threnzy) (threnzy@cisco.com)
Date: Thu Jan 15 2009 - 15:00:43 ARST
Hello Wes,
We did indeed see the DSCP settings marked on WAN probes at both spokes. Let me also say that, at that time, we were not running voice through the DMVPN network, so your experience is probably very different than what mine was(I had no experience!). I was addressing the statement around the DSCP bits not being copied to the new headers.
I can tell you though, there are a lot of customers out there who are indeed running DMVPN with voice without any issues, though I'm not sure of any specifics (shaping on an interface, queuing, etc.) around how they are using QoS. Most of these customers use an overlay model on top of MPLS though there are some who also use this over the Internet.
Thanks,
Thomas
Thomas Renzy
Network Consulting Engineer
Cisco Systems
Office: (408)526-8248
Mobile: (650)248-1099
E-mail: threnzy@cisco.com
-----Original Message-----
From: Wes Stevens [mailto:wrsteve33-gsccie@yahoo.com]
Sent: Thursday, January 15, 2009 5:57 AM
To: Thomas Renzy (threnzy)
Cc: ccielab@groupstudy.com
Subject: Re: DMVPN question
Hi Thomas,
Did you check this for the dynamic spoke to spoke tunnels? It has always worked for the spoke to hub main tunnel. It was a while ago so It may be fixed. But there is also another issue. If you allow spoke to spoke dynamic tunnels you cannot control the traffic in the different queues inbound or outbound to a spoke. Lets say there are two dynamic tunnels up and the primary to the hub. Inbound the two spokes transmitting on the dynamic tunnels do now know how much voice traffic is being sent in the voice queue by the other tunnels. There is no way to guarentee that the voice queue is not being overrun. Out bound is the same issue or was the last time that I checked. There was no way to do qos over multiple tunnels and make them cooperate so that the total voice traffic outbound on the tunnels does not go beyond what is allowed.
Dynamic spoke to spoke just does not work for voice and has issues with qos in general.
----- Original Message ----
From: Thomas Renzy (threnzy) <threnzy@cisco.com>
To: Wes Stevens <wrsteve33-gsccie@yahoo.com>
Sent: Wednesday, January 14, 2009 9:14:28 PM
Subject: RE: DMVPN question
Hello Wes,
It might have been a while, because I ran a large DMVPN network (before my employment at Cisco) and while testing with probe, we were able to see the DSCP settings copied to the new header. This was about two years ago, but wasn't sure if it was around the same time you were looking at it as well.
Though this is only for "classification", which I probably should have mentioned in my previous e-mail. I have not tried shaping with respect to DMVPN.
Thomas
Thomas Renzy
Network Consulting Engineer
Cisco Systems
Office: (408)526-8248
Mobile: (650)248-1099
E-mail: threnzy@cisco.com
-----Original Message-----
From: Wes Stevens [mailto:wrsteve33-gsccie@yahoo.com]
Sent: Wednesday, January 14, 2009 7:11 PM
To: Thomas Renzy (threnzy)
Subject: Re: DMVPN question
It dos not work on spoke to spoke at least in P2, not sure if it was fixed later phases, have not looked at it in a while.
----- Original Message ----
From: Thomas Renzy (threnzy) <threnzy@cisco.com>
To: Wes Stevens <wrsteve33-gsccie@yahoo.com>; Dale Shaw <dale.shaw@gmail.com>
Cc: Roman Rodichev <roman@iementor.com>; Fake Name <fname84@gmail.com>; Cisco certification <ccielab@groupstudy.com>
Sent: Wednesday, January 14, 2009 8:53:46 PM
Subject: RE: DMVPN question
Hello Wes,
"When you allow the direct spoke to spoke connections to come it does not rewrite the qos headers so basically you have no qos."
What about qos pre-classify?
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a
008017405e.shtml#qoscomm
Specifically...
"Apply the policy to a physical interface and enable qos-preclassify on a tunnel interface when you want to classify packets based on the pre-tunnel header."
Not sure if you had used this previously, but wanted to make you aware of it.
Thanks,
Thomas
Thomas Renzy
Network Consulting Engineer
Cisco Systems
Office: (408)526-8248
Mobile: (650)248-1099
E-mail: threnzy@cisco.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Wes Stevens
Sent: Wednesday, January 14, 2009 6:04 PM
To: Dale Shaw
Cc: Roman Rodichev; Fake Name; Cisco certification
Subject: Re: DMVPN question
When you allow the direct spoke to spoke connections to come it does not rewrite the qos headers so basically you have no qos. Not good for voice. At least it was that way the last time we looked into this, not sure if they have 'fixed' this.
----- Original Message ----
From: Dale Shaw <dale.shaw@gmail.com>
To: Wes Stevens <wrsteve33-gsccie@yahoo.com>
Cc: Roman Rodichev <roman@iementor.com>; Fake Name <fname84@gmail.com>; Cisco certification <ccielab@groupstudy.com>
Sent: Wednesday, January 14, 2009 7:26:52 PM
Subject: Re: DMVPN question
Hi Wes,
On Thu, Jan 15, 2009 at 12:12 PM, Wes Stevens <wrsteve33-gsccie@yahoo.com> wrote:
> If you are going to do voice this is very useful for CAC. If you
overlay the dmvpn you are back to hub and spoke and CAC gets real tricky.
Huh?
Direct spoke-to-spoke communication is possible with DMVPN. I realise the spokes initially learn about other spokes via the hub(s), but can you clarify what you meant by your statement above?
cheers,
Dale
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:38 ARST