Wow Joseph, thanks for all of that. Yes, when running show policy-map, it does show the minumum bandwidth and it allocates it as I expected. Here is my question.  That there seems to be a lot of confusion on. If my priority queues are not using the minimum guaranteed bandwidth, will that "excess" be distrubuited to all of the "bandwidth remaining" classes. I am running IOS 15.1(4)M1 on a 3845 ISR, so it does support HQF. ... View more

Thanks! ... View more

So lets say there is no priority traffic on the link, and replication is taking all of the 10Mbps.  A VPN client connects and starts to download a large file from the network.  The VPN client should get 3000Kbps in that case, correct?  Since o priority traffic is on the link and VPN is allowed 30% of what remains (which is all 10Mbps). Worst case if all priorty classes are maxed out (video and voice),  VPN would get 2250Kbps (as indicated on "show policy-map int int" command), correct? I just want to make sure I get the most of out of this circuit and make sure my understanding on bandwidth remaining is accurate. ... View more

Oh, and I want higher rates when priority traffic is not in use, hense why I used "bandwidth remaining percent". ... View more

I did not think of L2 overhead, but are not running at 100% all of the time.  In fact we run around 60-70% (replication). I don't think right now it has to be spot on, since our ISP does allow bursting and some overages.  I just wanted some type of QoS in place to make sure we did not exceed 50 often so that we are not charged extra. Thanks to all for contributing! ... View more

Thanks guys!  This was just want I was looking for! ... View more

I figured it out from looking at the output that you provided!  Thanks! ... View more

p.bevilacqua wrote: Works for me CME#sh voice translation-rule 1 Translation-rule tag: 1         Rule 1:         Match pattern: \(555222555[1-3]\)         Replace pattern: \1         Match type: none                Replace type: none         Match plan: none                Replace plan: none CME#test voice translation-rule 1 5552225551 Matched with rule 1 Original number: 5552225551     Translated number: 5552225551 Original number type: none      Translated number type: none Original number plan: none      Translated number plan: none Likely there is another reason for fast-busy. I got it working!  I was missing some the \ and \ in the match pattern.  I do not understand how to write these AT ALL!  What did not make a lot of sense is that the first backslash is outside of the parentheses and the second backslash in inside the parentheses.  I've read the document explaining this from Cisco's website, but it still has not sunk in. What got it working: voice translation-rule 2 rule 1 /5552227564/ /\1/ rule 2 /\(555222555[1-3]\)/ /\1/ rule 3 /5552227610/ /6000/ rule 4 /\(.*\)/ /6001/ What I had before: voice translation-rule 2 rule 1 /5552227564/ /\1/ rule 2 /(555222555[1-3])/ /\1/ rule 3 /5552227610/ /6000/ rule 4 /\(.*\)/ /6001/ ... View more

p.bevilacqua wrote: You need round brackets (parenthesis mark) for pattern match recall. rule 3 /\(555222555[1-3]\)/ /\1/ Dec 17 16:34:27.772: //-1/599DDF6189B5/RXRULE/sed_subst: Successful substitution; pattern=5552225551 matchPattern=555222555[1-3] replacePattern=\1 replaced pattern= Here is the debug log.  I still got a fast busy. ... View more

Actually i was just thinking that myself ie. the HSRP thing but you would need to change the default-gateway on the colo DMZ servers as well to point to the HSRP address. Would this be a problem ? No it would be fine.  There are only a handful of DMZ hosts, so switching these and cleaning up the static routes wouldn't be too bad. There would be no problem configuring HSRP between the 1800 and 3845, as long as their is L2 adjacency which it looks like there is via your DMZ switches it will work fine. You are going to have to use HSRP track on your 3845 routers so that if the serial interface fails (i'm assuming it's serial, let me know if it's not), then the HSRP active gateway switches across to the 1800 routers at both sites. If it's serial a loss of one end should bring down the serial interface on the other end. OK, I wasn't sure if the routers needs to be similar or not.  Good to know.  Yes, the interface is actually a multilink interface made up of two serial interfaces. If you made the HSRP virtual IP the default-gateway in the colo site which you would have to do then you would need a default-route pointing to the colo ASA. - *** edit actually you wouldn't need to add one as the colo ASA is redistributing this into EIGRP already Yes, 0.0.0.0 is redistributed by the colo ASA into EIGRP. It's not a particularly clean solution ie. bouncing traffic around in the DMZ but it fits your topology and is much easier than either - 1) having static routes on the servers 2) running RIP purely for the servers and having to redistribute EIGRP into RIP Like i say the main stumbling block i could see would be changing the default-gateway on the colo DMZ servers, is this doable ? Edit - just to clarify the routing you would need to do - On the 3845 and 1800 on the corporate site you would either need to - 1) add routes to your internal corporate network 2) advertise them from your corporate ASA which you may or may not be doing already I agree with you.  The more I think about this, I think that I can live with the not so clean solution either of having something that wouldn't require advanced routing skills to configure new DMZ host (I.E installing and configuring Windows RRAS to run RIP). Time to read up on HSRP! Jon, thanks again for your time and effort!  I was betting my question was too complex for most people to even bother responding to! ... View more