Re: [c-nsp] ISP / MPLS "POP" design

>IS-IS can scale to a larger number of devices in a single "area" and >overall network. Really depends on how many devices you are talking >about. For smaller deployments it usually comes down to who is supporting >the network and what they are more familiar with. I didn't want to chime into

Re: [c-nsp] ISP / MPLS "POP" design

IS-IS can scale to a larger number of devices in a single "area" and overall network. Really depends on how many devices you are talking about. For smaller deployments it usually comes down to who is supporting the network and what they are more familiar with. So you are backhauling most of your

Re: [c-nsp] %PLATFORM-CIH-5-ASIC_ERROR_SCRUB_THRESH

Hi Antonio, I had a similar issue and decided to reload the linecard. pse_pogo_driver[281]: %PLATFORM-CIH-5-ASIC_ERROR_SPECIAL_HANDLE : pse[1]: A sbe error has occurred causing data corrected. 0x12470007 I don't like to see any messages regarding single bit error (SBE) and even less when it's

Re: [c-nsp] ISP / MPLS "POP" design

Hi, Have a couple more questions on this :) 1. I notice that a number of people use IS-IS rather than OSPF - Is there benefits to using one vs the other? 2. Majority of customer tails will be supplied via vlans (On Carrier AGG's) - Typically we would have two AGG's from two different carriers

Re: [c-nsp] cisco 2901 qos

I don't see that my link every really goes over 7mbps.  Thats what has me baffled.  If there is still room on the link then why are we getting output drops on that one queue? On Tuesday, November 5, 2013 12:18 PM, Tony wrote: If you are getting that many drops and it is unacceptable then

Re: [c-nsp] cisco 2901 qos

I just increased polling on that interface to see if maybe we are getting bursty traffic that is filling the queues.  It might be that we are filling the interface and not knowing it because polling was set to 30 seconds.(LOL) On Tuesday, November 5, 2013 12:24 PM, Michael Sprouffske wrote

Re: [c-nsp] cisco 2901 qos

If you are getting that many drops and it is unacceptable then you need to seriously think about increasing the amount of bandwidth you have available. Changing queue-depth may help, it will mean packets will sit in the queue for longer before being potentially dropped. This would only help if t

Re: [c-nsp] ME3600x-cx 153-3.S any major pitfalls?

There was an issue with the image file naming so it is being fixed and reposted on CCO. Best Regards, [http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg] Waris Sagheer Technical Marketing Manager Service Provider Access Group (SPAG) wa...@cisco.com

Re: [c-nsp] ip tcp adjust-mss

Good catch! Looks like this was done through the work of CSCuc36988 and is on track for 15.4.1S still On Tue, Nov 5, 2013 at 8:24 AM, wrote: > > On ASR1k the MSS adjustment is done on the QFP (the ESP or "in > hardware"). > > Again, this behavior varies from platform to platform. > > Note: IPv4

Re: [c-nsp] 2901 output drops

This is how traffic shaping works; by dropping packets. I would also add fair-queueing to each of your classes, as this would allow you to tune queues: policy-map WAN-OUT class Network-Control bandwidth percent 10 fair-queue queue-limit 128 packets class class-default random-detect dscp-

Re: [c-nsp] cisco 2901 qos

I get 1 millions drops per day from the best-effort.  Is there anything that can fix this?  Do I need to adjust queue depth and if so , what would you recommend. On Tuesday, November 5, 2013 11:20 AM, Alex Pressé wrote: You are doing it right; all traffic will be shaped to a max of 10M;

Re: [c-nsp] cisco 2901 qos

You are doing it right; all traffic will be shaped to a max of 10M; with best effort getting at least 2M (or more, if there is no congestion). class-default just matches everything that hasn't been matched already. In this case you're matching everything and then applying child policies. Within EL

[c-nsp] 2901 output drops

I am seeing over a million outputs drops per day.  This is a 100Mb mpls connection that is shaping down to 10.  Is there any way to improve on my drops ?  Do I need to up my queue limit on this interface and if so, what would be a good number to use.  I’m not sure how to tweak this without breaking

[c-nsp] cisco 2901 qos

class-map match-any Best-effort  match ip precedence 0  1 class-map match-any Priority-Three  match ip precedence 2  3 class-map match-any Priority-Two  match ip precedence 4  6  7 class-map match-any Priority-One  match ip precedence 5 ! ! policy-map ELA_QUEUING_POLICY  class Priority-One     band

Re: [c-nsp] Sup2T-XL vs Sup720BXL FIB TCAM

Thanks for the information about the shared pool of TCAM which explains everything. Sup2T-XL --> show platform hardware cef maximum-routes Fib-size: 1024k (1048576),shared-size: 1016k (1040384), shared-usage: 482k(493974) Protocol Max-routes Use-shared-region Dedicated

Re: [c-nsp] Sup2T-XL vs Sup720BXL FIB TCAM

Sorry for the screwy formatting, here should be a better output: Sup2T-XL output of "sh platform hardware capacity": CAT6500-RC2TXL#sh platform hardware capacity | begin L3 Forwarding Res L3 Forwarding Resources FIB TCAM usage: TotalUsed %Use 72 bits (IPv4, MPLS, E

Re: [c-nsp] Sup2T-XL vs Sup720BXL FIB TCAM

As Rinse Kloek already mentioned, the Sup2T has only 1M entries, but a shared pool of TCAM space. Sup2T#show platform hardware cef maximum-routes Fib-size: 1024k (1048576), shared-size: 1016k (1040384), shared-usage: 151k(155130) Protocol Max-routes Use-shared-region Dedica

Re: [c-nsp] Sup2T-XL vs Sup720BXL FIB TCAM

Your paste formatting got all screwy, but it looks like the Sup2TXL claims it can do both 1M v4 routes _and_ half a million v6 routes simultaneously. I've heard that from others, but also read the specs to be the same as the 3BXL. I wonder if anyone from cisco can shed some light on this? On

Re: [c-nsp] ip tcp adjust-mss

It's not *necessarily* a buggy device. I meant to explain why could the problem be anywhere. That said, if negotiation is being kept at 1460, you possibly have a link (like DSLs do) that has a lower MTU but the router doesn't know. Just follow Juergen's advice: set MSS to conservative values on a

Re: [c-nsp] Sup2T-XL vs Sup720BXL FIB TCAM

Christian, The SUP2T-XL and Sup720BXL have the same FIB TCAM size. However the SUP2T-XL has one shared pool of TCAM for IPv4/IPv6. The Sup720BXL has a fixed pool TCAM for Ipv4 and one fixed pool for IPv6. If you want to change this allocation, you have to do a config change and a reload afterw

[c-nsp] Sup2T-XL vs Sup720BXL FIB TCAM

Today I tested a Sup2T-XL and a Sup720BXL in the lab with full bgp feeds for ipv4 and ipv6. To my understanding the hardware capacity for the FIB TCAM is the same for Sup720-BXL and Sup2T-XL. Sup2T-XL output of "sh platform hardware capacity":CAT6500-RC2TXL#sh platform hardware capacity | begin

Re: [c-nsp] ME3600x-cx 153-3.S any major pitfalls?

Hi! > It's now November but AFAICS there is no S1 release available yet. Do > you have an updated release date? Looks like S1 was removed again from CCO, because I downloaded it a week ago and upgraded 4 (less important) boxes. So, should I panic and downgrade? ME3600#show ver | inc Version 1

Re: [c-nsp] ip tcp adjust-mss

> On ASR1k the MSS adjustment is done on the QFP (the ESP or "in hardware"). > Again, this behavior varies from platform to platform. Note: IPv4 only, for now. IPv6 may be in 15.4(1)S. See http://www.gossamer-threads.com/lists/nsp/ipv6/45433 /JF ___ ci

Re: [c-nsp] ME3600x-cx 153-3.S any major pitfalls?

Hi Waris. On 2 October 2013 17:51, Waris Sagheer (waris) wrote: > Hi Nick, > It would be 10/30/2013. > > > From: Nick Hilliard mailto:n...@foobar.org>> > Date: Wednesday, October 2, 2013 4:38 AM > To: "cisco-nsp@puck.nether.net" > mailto:cisco-nsp@puck.nether.ne

Re: [c-nsp] DFC bootflash?

I liked your email address. Very creative :) DFC bootflash is used for the crash files. In the event of a crash the file is written to it.. Do "show platform hardware capacity flash” and check if you can see a bootflash on the linecard.. You may need to raise a TAC case if there is no bootflash

Re: [c-nsp] vs Netscaler loadbalancer

Hi, On Tue, Nov 05, 2013 at 05:57:56AM +, Arne Larsen / Region Nordjylland wrote: > We have bought to new load balancers Netscaler SDX11500 from Citrix In addition to what Roland said - if I remember right, this box is Xen based, so you need to configure "physical LACP channels" on the Xen