Re: [c-nsp] Adjusting TCAM allocation weird behavior on 7600

On 8/7/14, 23:51, Pete Templin wrote: On 8/6/2014 7:18 PM, Rod James Bio wrote: BUT "remote command switch show mls cef max", I see: FIB TCAM maximum routes : === Current :- --- IPv4 + MPLS - 512k (default) IPv6 + IP Multicast - 256k (default) Could this mean

Re: [c-nsp] Adjusting TCAM allocation weird behavior on 7600

I think I read somewhere online something similar to what you are suggesting. My first thought was, that was unusual, but looks like this is the last option for me. Regards, Rod On 8/7/14, 23:19, Mack McBride wrote: This does look like an issue with the dual sup configuration :(. You may need

[c-nsp] ipv6 tacacs source-interface issue

Hello, The command 'ipv6 tacacs source-interface Loopback0' for select IPv6 address source for Tacacs have no effect on Cisco 6500 12.2(33)SXJ7. Is it a know issue ? The command is accepted by the CLI but the packets are sourced with the IPv6 address of outgoing interface and not the loopback.

Re: [c-nsp] Securing IAD control plane / RTP not hitting CoPP?

> > If these devices are all on networks under your administrative control, > it's generally far better to drop undesirable packets at the edge, and far > easier to get an iACL and/or tACL right and deploy on edge interfaces, than > to get CoPP right. > I completely agree, the problem is that I h

Re: [c-nsp] Prioritize PING traffic to control plane

On Aug 7, 2014, at 9:27 PM, Justin M. Streiner wrote: > That becomes a much worse idea if/when IPv6 is involved. It's a terrible idea for IPv4, too - it breaks PMTU-D. -- Roland Dobbins //

Re: [c-nsp] Prioritize PING traffic to control plane

On Thu, 7 Aug 2014, Dumitru Ciobarcianu wrote: I know someone who at some point filtered icmp entirely from the customer's networks because of this and convinced the troublemakers that "they are more secure that way". The customer was happy because he was getting a consistent graph... That bec

Re: [c-nsp] Securing IAD control plane / RTP not hitting CoPP?

On Aug 7, 2014, at 11:11 PM, randal k wrote: > So, we have deployed a demo control-plane based policer/dropper to make sure > that the WAN interface ACL doesn't have to be perfect (or even be > there, which is the goal). If these devices are all on networks under your administrative control, i

Re: [c-nsp] Adjusting TCAM allocation weird behavior on 7600

On Thu, Aug 7, 2014 at 3:51 PM, Pete Templin wrote: > Regardless of the outcome of the above, I'd truly recommend you do this > regardless: > > > conf t > config-register 0x2102 > end > copy run start Maybe it has been "fixed", but I found that if you set the config-register the same as what

[c-nsp] Securing IAD control plane / RTP not hitting CoPP?

I posted this message over on Cisco-VoIP and had very little traction, so I thought I'd try here. I have a bunch of Cisco IAD24xx models out in the field all running SIP talking to our softswitch, and I thought I'd get the collectives input on the best method to secure them. Up until a few weeks

Re: [c-nsp] Prioritize PING traffic to control plane

A better solution is to set up a perfsonar node for customers to ping and speed test against. http://psps.perfsonar.net/toolkit/ And then educate them on traceroute and other available tools. We severely rate limit ping and ttl expired to (not through) our core devices as do many major carriers.

Re: [c-nsp] Adjusting TCAM allocation weird behavior on 7600

On 8/6/2014 7:18 PM, Rod James Bio wrote: BUT "remote command switch show mls cef max", I see: FIB TCAM maximum routes : === Current :- --- IPv4 + MPLS - 512k (default) IPv6 + IP Multicast - 256k (default) Could this mean that the two sups are not sync? Here i

Re: [c-nsp] Adjusting TCAM allocation weird behavior on 7600

This does look like an issue with the dual sup configuration :(. You may need cisco support to sort it out. One solution may be to remove the second sup while configuring And then reinserting it once the box is booted with the desired configuration. Mack McBride | Network Architect | ViaWest, Inc.

Re: [c-nsp] Prioritize PING traffic to control plane

We had one of our customers complaining about a similar issue using pingplotter/mtr to check for congestion and we tried educating him regarding this issue as has been mentioned here. We are using mls rate-limiting for ttl-failures and saw that one of our 7600/PE routers had reached it rate-limiti

Re: [c-nsp] Adjusting TCAM allocation weird behavior on 7600

Issuing just "reload" should have been fine, no? I've always done it like that multiple times trying different values. I suspect, as Mack pointed earlier, the new values are not copied to the slave-sup after a write mem, but it never gets copied. Regards, On 8/7/14, 18:27, Antonio Soares wro

Re: [c-nsp] Adjusting TCAM allocation weird behavior on 7600

When you changed the settings, you rebooted the all box, right ? Check this: https://supportforums.cisco.com/discussion/1156/cisco-7609-rsp720-3cxl-g e-mls-cef-maximum-routes Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message--

Re: [c-nsp] Prioritize PING traffic to control plane

On 07-Aug-14 11:23 AM, Roland Dobbins wrote: > > On Aug 7, 2014, at 3:15 PM, Dumitru Ciobarcianu wrote: > >> Yes, I agree, I was just saying that I think I know his X [1] :) > > Sure - the best way to deal with this is to set up some anycasted ping target > nodes numbered out of TEST-NET space

Re: [c-nsp] Prioritize PING traffic to control plane

On Aug 7, 2014, at 3:48 PM, Saku Ytti wrote: > If you're not filtering them, customer may say 'we filter them, as per RFC > and they do not work'. You're right - it's probably best just to burn an address out of an existing routable netblock instead of trying to get fancy. Good point! -

Re: [c-nsp] Prioritize PING traffic to control plane

On (2014-08-07 15:23 +0700), Roland Dobbins wrote: > Sure - the best way to deal with this is to set up some anycasted ping target > nodes numbered out of TEST-NET space around the network, and tell them to > point whatever they're using at that. Does not appear to be RFC conforming use of TEST

[c-nsp] ASR1001 L2 protocol forwarding

Hello, Does anyone know if this feature is actually supported on the ASR1001 (running 15.2(4)S/03.07.00.S), please? I can see that 'l2protocol forward stp' is available and accepted within a service instance configuration however it doesn't seem to work i.e. BPDUs are being dropped. Thanks,

Re: [c-nsp] Prioritize PING traffic to control plane

On Aug 7, 2014, at 3:15 PM, Dumitru Ciobarcianu wrote: > Yes, I agree, I was just saying that I think I know his X [1] :) Sure - the best way to deal with this is to set up some anycasted ping target nodes numbered out of TEST-NET space around the network, and tell them to point whatever they

Re: [c-nsp] Prioritize PING traffic to control plane

On 07-Aug-14 10:41 AM, Roland Dobbins wrote: > > On Aug 7, 2014, at 2:24 PM, Dumitru Ciobarcianu wrote: > >> I guess because he has some customers (like mine) who use tools like mtr or >> pingplotter who yell at him that they have latency and/or packet loss >> and they present a screenshot with

Re: [c-nsp] Prioritize PING traffic to control plane

> I found out that PING to control plane of the router/switch can result with > spike Latency and this is normal since ICMP packet is low priority in the > CPU processing. I'm wondering if there is any way that we can prioritize it > so that I can get no spike latency when pinging to control Plane,

Re: [c-nsp] Prioritize PING traffic to control plane

On Aug 7, 2014, at 2:24 PM, Dumitru Ciobarcianu wrote: > I guess because he has some customers (like mine) who use tools like mtr or > pingplotter who yell at him that they have latency and/or packet loss > and they present a screenshot with only his routers showing this behaviour > (the last

Re: [c-nsp] Prioritize PING traffic to control plane

On 07-Aug-14 9:30 AM, Roland Dobbins wrote: > > On Aug 7, 2014, at 12:49 PM, Samol wrote: > >> I'm wondering if there is any way that we can prioritize it so that I can >> get no spike latency when pinging to control Plane, I know it's not >> necessary to do so, somehow want to see if this can