Uptime is about 2 weeks. Yes on the code and licensing
Sent from my iPhone
On Apr 19, 2013, at 8:32 PM, Tony Singh <mothafungla_at_gmail.com> wrote:
yeh without further tests it's hard to say what the issue is, what's the
uptime? is the code/license identical to your other working router ;)
-- BR Tony Sent from my iPhone on 3 On 20 Apr 2013, at 00:50, Joe Astorino <joeastorino1982_at_gmail.com> wrote: CPU and memory seem to be OK. sh proc cpu shows it sitting about 7-10% when the problem occurs. sh proc cpu history does not show any really bad spikes. sho proc mem seems to show I have plenty of free RAM as well. On Fri, Apr 19, 2013 at 7:43 PM, Joe Astorino <joeastorino1982_at_gmail.com>wrote: > Sorry, 2GB of RAM is what it has > > > On Fri, Apr 19, 2013 at 7:41 PM, Matt Bentley <mattdbentley_at_gmail.com>wrote: > >> Interesting. I've done testing with Spirent and other traffic-gen >> platforms. I never saw shaping add to the latency - until I actually got >> up close to the CIR - maybe slightly with a lower-end platform. But I >> don't think shaping even activates until it senses backpressure and >> activates "itself". >> >> >> On Fri, Apr 19, 2013 at 4:17 PM, Tony Singh <mothafungla_at_gmail.com>wrote: >> >>> The reason why you get the extra delay when the policy is applied is >>> down to the extra work the CPU has to do on top of inbound congestion, >>> what's your memory/free? >>> >>> I would also raise a TAC to get the definitive answer "show >>> tech-support" & pass to them >>> >>> -- >>> BR >>> >>> Sent from my iPhone on 3 >>> >>> On 19 Apr 2013, at 23:13, Joe Astorino <joeastorino1982_at_gmail.com> >>> wrote: >>> >>> > Another interesting fact - When the policy is applied as shown above, >>> the >>> > problem only occurs when the inbound RX is congested. >>> > >>> > So basically, if the service-policy is applied outbound towards the >>> WAN as >>> > shown, and the output utilization of the WAN link (TX) is low, and the >>> > inbound (RX) utilization is low, everything is fine. >>> > >>> > In the event that the inbound utilization of the interface (RX) is >>> > significant, and the policy is applied outbound as usual, the policy is >>> > adding the 200-400ms extra delay. If I remove the policy, the extra >>> delay >>> > goes away. >>> > >>> > I guess I don't understand why inbound congestion would change how the >>> > outbound queue / shaping works. >>> > >>> > input is low, output is low, policy applied: fine >>> > input is high, output is low, policy not applied: expected poor >>> response >>> > times >>> > input is high, output is low, policy is applied: expected poor response >>> > time PLUS an additional 200-400ms of delay >>> > >>> > >>> > On Fri, Apr 19, 2013 at 5:49 PM, Joe Astorino < >>> joeastorino1982_at_gmail.com>wrote: >>> > >>> >> I have a 3945 ISR router connected via a GigabitEthernet link to a >>> service >>> >> provider that is providing 10Mbps WAN access. I wish to use CBWFQ >>> and the >>> >> service provider requires dot1q tagging. As such, I must shape my >>> >> sub-interface and use a hierarchical type QoS policy...no big deal >>> >> >>> >> policy-map WAN-EDGE >>> >> class VOICE >>> >> priority percent 20 >>> >> ! >>> >> class VIDEO >>> >> bandwidth remaining percent 60 >>> >> queue-limit 128 packets >>> >> ! >>> >> class APPS_SIGNALING >>> >> set dscp af21 >>> >> bandwidth remaining percent 30 >>> >> ! >>> >> class class-default >>> >> bandwidth remaining percent 10 >>> >> ! >>> >> ! >>> >> policy-map SHAPE-OUT >>> >> class class-default >>> >> shape average 10000000 >>> >> service-policy WAN-EDGE >>> >> ! >>> >> ! >>> >> int gi0/1.2 >>> >> encapsulation dot1q 2 >>> >> ip address ... >>> >> service-policy output SHAPE-OUT >>> >> >>> >> >>> >> Here is the very strange thing. Even when the TX of this WAN >>> interface is >>> >> barely being used, when and only when the service-policy is applied, >>> the >>> >> response in pings to anything behind this router increase immediately >>> by >>> >> 200-400ms. Immediately after removing the service-policy things >>> return to >>> >> normal. >>> >> >>> >> Investigating the output of "show policy-map interface" reveals a >>> large >>> >> number of output drops in the shaper class-default. So far I have >>> tried >>> >> >>> >> - increasing the queue-limit to many different combinations >>> >> - increasing the burst size >>> >> >>> >> I also have the exact same configuration on another remote site router >>> >> running the same version of IOS with the same setup (10Mbps Ethernet >>> WAN >>> >> link) on the same platform. >>> >> >>> >> I'm really baffled as to what would cause this. Any insight >>> appreciated. >>> >> >>> >> >>> >> >>> >> -- >>> >> Regards, >>> >> >>> >> Joe Astorino >>> >> CCIE #24347 >>> >> http://astorinonetworks.com >>> >> >>> >> "He not busy being born is busy dying" - Dylan >>> >> >>> > >>> > >>> > >>> > -- >>> > Regards, >>> > >>> > Joe Astorino >>> > CCIE #24347 >>> > http://astorinonetworks.com >>> > >>> > "He not busy being born is busy dying" - Dylan >>> > >>> > >>> > Blogs and organic groups at http://www.ccie.net >>> > >>> > _______________________________________________________________________ >>> > Subscription information may be found at: >>> > http://www.groupstudy.com/list/CCIELab.html >>> >>> >>> Blogs and organic groups at http://www.ccie.net >>> >>> _______________________________________________________________________ >>> Subscription information may be found at: >>> http://www.groupstudy.com/list/CCIELab.html >>> >>> >>> >>> >>> >>> >>> >>> >> > > > -- > Regards, > > Joe Astorino > CCIE #24347 > http://astorinonetworks.com > > "He not busy being born is busy dying" - Dylan > -- Regards, Joe Astorino CCIE #24347 http://astorinonetworks.com "He not busy being born is busy dying" - Dylan Blogs and organic groups at http://www.ccie.netReceived on Fri Apr 19 2013 - 22:19:35 ART
This archive was generated by hypermail 2.2.0 : Wed May 01 2013 - 06:47:40 ART