Re: [c-nsp] Issue with port-channel hashing

[Mack McBride]

With some traffic patterns there isn't much you can do.
If there are very few source and destination addresses then you may not be able 
to
Distribute the traffic.  Especially for long lived flows.

Try 'port-channel load-balance src-dst-mixed-ip-port' if you are on code that 
supports it.
Also ensure you have 'port-channel load-balance per-module'.
You already found the adaptive knob.
Adaptive is more difficult to troubleshoot when there are issues.

You may also want to set 'mls ip cef load-sharing full'.

Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of james 
list
Sent: Friday, July 22, 2016 1:45 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Issue with port-channel hashing

Dear experts,

I need help.


On my C6500 sup720 (12.2(33)SXI5) I’ve a port channel 4 x 1Gbs with 1 Gbs full 
and hashing fixed.

On the port-channel I’m trunking with few L2 vlans and on top of one of those 
I’ve L3 (with OSPF).


Since hashing is fixed all the traffic that 6500 Asic has decided to send on 
that link is experiencing problems.


My questions:


1)  Which is the faster and safer way to detect the “guilty” (src/des
tip) ? I see accounting seems not working

2)  What if I would change hashing from fixed to adaptive ? any detail
on that ? I'm not able to find how it works in detail on cisco.com


An help is appreciated,


Cheers

James
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Router ASR1k ACL count question

[Mack McBride]

On the older 3550 and 3560 there were no hardware counters for ACLs.
I am assuming that is true with the 3850 as well.
On the ASR1006, you have a massively parallel software processor that handles 
all forwarding (the Cisco FP).
So technically it is software but it acts more like reprogrammable hardware.
Each FP has a large number of multi threaded cores.
The ESP 200 has around 248 cores, which can each handle multiple (four each) 
threads.
This means that you effectively handle 992 threads simultaneously.
That translates to 5+ CPU cycles per bit at 64 byte packets.
Meaning even with minimum sized packets the processors get about 2500 cycles 
for each packet.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Satish 
Patel
Sent: Thursday, July 21, 2016 8:37 AM
To: Cisco Network Service Providers
Subject: Re: [c-nsp] Router ASR1k ACL count question

Any input?

On Wed, Jul 20, 2016 at 11:52 AM, Satish Patel  wrote:
> I have C3850 (L3) switch and Cisco ASR1006 Router, I am running ACL on
> both device but if i rung "show ip access-lists" on both then i can
> see c3850 hit counter not increasing but on ASR1006 router it is
> increasing.
>
> What does that mean? I heard from people C3850 using hardware ACL
> because of that its counter doesn't increase. Does that means ASR1006
> using software ACL because its counter increasing every single hit.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ASR-1k 10g Licenses

[Mack McBride]

Throughput is output direction only.
As for licensing, there is a certification in that.
It is that complicated.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick 
Cutting
Sent: Tuesday, July 19, 2016 12:45 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ASR-1k 10g Licenses

Good afternoon esteemed industry giants,

I'm trying to make some kind of head or tail out of the ASR licensing 
documents, I do not want to buy too much or not enough licensing.

I would like to connect an ASR-1001-X to a 10gig  handoff, and down to a 10 gig 
switch.  I will be doing some basic policing for a few different classes.

I need to enable both of the onboard SFP+'s

Do I need:

2 x interface_10g licenses and a 20 Gig throughput license (FLSA1-1X-2.5-20G)

Or

2 x interface_10g licenses and a 10 Gig throughput license (FLSA1-1X-2.5-10G)

I.e. are the licenses bi-directional ?
Also - the QoS in the IP base license, is it in anyway limited? (for basic IP 
traffic)

Thanks!
Nick
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ASR9000/IOS-XR NAT/PAT

[Mack McBride]

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-2/cg-nat/configuration/guide/b_cgnat_cg52xasr9k/b_cgnat_cg52xasr9k_chapter_011.pdf

Documentation is also helpful.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick 
Hilliard
Sent: Monday, July 18, 2016 11:06 AM
To: Curtis Piehler
Cc: Cisco Network Service Providers
Subject: Re: [c-nsp] ASR9000/IOS-XR NAT/PAT

Curtis Piehler wrote:
> I've been reading documentation online about NAT/PAT on an ASR9k Router.
> Is it a requirement to have a VSM/ISM in the chassis to perform
> regular
> IPv4 PAT and/or IPv4 to IPv6 translations?

yes.

Nick

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] mystery pseudowire interfaces?

[Mack McBride]

Another explanation is that pseudowires were previously created on the device 
and deleted and then
When MPLS was re-enabled, the interfaces reappeared.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Saku 
Ytti
Sent: Monday, July 18, 2016 6:20 AM
To: Mike
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] mystery pseudowire interfaces?

Interesting. The most obvious solutions is that this is bug, some 
corruption/memory leak interpreted as configured pseudowires. I couldn't find 
anything in quick search in cisco bug tool. I'd engage CTAC.
You could also try to correlate appearance/disappearance of these to a 
operational work. Perhaps these happen when to (de)provision circuits?

The tinfoil hat explanation is that someone is extracting data from your 
network. I know one network which had TCAM poked ERSPAN extraction configured, 
i.e. not visible in config, and based on data being extracted it was deemed 
intentional action by 3rd party.

At least two of those IP addresses are not advertised in global table, but that 
does not prove anything really. Trying look at the bits of the IP addresses and 
VC_ID and no obvious pattern at least.

On 18 July 2016 at 12:55, Mike  wrote:
>
>
> Hi,
>
> I have a metro-ethernet connection between two sites - an asr920
> and an me3600x and am running mpls over it. I have just noticed some
> mystery pseudowire interfaces that have shown up and I strongly think
> it's my metro-e provider leaking data into my circuit. Is this
> possible? Some
> examples:
>
>
> pseudowire100012 is up
> MTU 1500 bytes, BW 1000 Kbit
> Encapsulation l2tpv2
> Peer IP 107.118.108.50, VC ID 1634955825
> RX
>   0 packets 0 bytes 0 drops
> TX
>   0 packets 0 bytes 0 drops
>
>
> pseudowire100013 is up
> MTU 1500 bytes, BW 1000 Kbit
> Encapsulation unknown
> Peer IP 104.100.115.108, VC ID 1969973601
> RX
>   0 packets 0 bytes 0 drops
> TX
>   0 packets 0 bytes 0 drops
> pseudowire100016 is up
> MTU 1500 bytes, BW 1000 Kbit
> Encapsulation unknown
> Peer IP 48.109.103.109, VC ID 1986802480
> RX
>   0 packets 0 bytes 0 drops
> TX
>   0 packets 0 bytes 0 drops
> pseudowire100023 is up
> MTU 1500 bytes, BW 1000 Kbit
> Encapsulation unknown
> Peer IP 98.52.48.49, VC ID 2003399541
> RX
>   0 packets 0 bytes 0 drops
> TX
>   0 packets 0 bytes 0 drops
>
> None of these IPs are me - I have only rfc1918 addresses in my mpls network.
> How is it possible these have been created? I don't understand the
> mechanisam. There are no log entries...
>
> Mike-
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



--
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Router 6504E - SUP 720 3B XL

[Mack McBride]

It does if you enable Selective Route Download.
With Selective Route Download enabled we are able to keep the
Memory below 85% (which is safe).  Above 90% is a real danger.
Selective Route Download is a good tool but there are lots of
Caveats with implementing it.  Such as you cannot be default free
And all routes and longer prefixes that you are advertising must be accepted 
back.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick 
Hilliard
Sent: Friday, July 15, 2016 6:19 AM
To: Estagiario
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Router 6504E - SUP 720 3B XL

Estagiario wrote:
> I get 3 full ebgp for WAN

this won't work.  The RP doesn't have enough RAM to reliably handle a full DFZ.

Nick

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ATT ASE Madness - one way ethernet

[Mack McBride]

You may want to hit up the Ciena mailing list, most people here are cisco 
oriented.
If storm control or multicast filtering is turned on/misconfigured, you could 
see that behavior.
It could be on any of the devices in the path, yours or theirs.
No clue how to tell on their side but on the cisco side the interface configs 
should be pretty obvious.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mike
Sent: Friday, July 08, 2016 12:03 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ATT ASE Madness - one way ethernet

Hi,

 I have a new ATT ASE circuit and they have been troubleshooting now for 
two weeks. The symptom simply is that I appear to have one-way connectivity; 
Packets go from 'site a' to 'site b', but Broadcast/Multicast does not go back 
from 'site b' to 'site a'. For example, I can put static arp entries in both 
peices of my gear at either end, and have ping connectivity. But if I remove 
these, then arp doesn't complete and thus ping does not work. Stranger still, 
the 'site b' can see the CDP neighbor announcements from 'site a', but that 
site doesn't see the announcements from 'site b'.

 Naturally ATT thinks it's me and wants me to replace / test / etc, but I 
think it's misconfiguration on their end since its clearly broadcast/multicast 
not being forwarded. On ATT end they have a Ciena
3960 if that helps anyone. On my side, 'site a' is a ME3600x while 'site b' is 
an ASR920, if that helps. Does anyone have a better idea as to what to look at 
here?

Mike-

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] SUP720's memory, looking at options..

[Mack McBride]

XR code is friendlier to BGP traffic engineering.
The ASR9K also has better MPLS support.
You should be able to do most things on both.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: Peter Kranz [mailto:pkr...@unwiredltd.com]
Sent: Thursday, July 07, 2016 3:06 PM
To: Mack McBride
Cc: 'cisco-nsp'
Subject: RE: [c-nsp] SUP720's memory, looking at options..

Ah.. I've not been able to convince myself that the port density hit on the 9k 
was worth it yet.

Since the nexus 77k supports 2M IPv4 routes in its FIB and has pretty epic 
density, we are trying to figure out what that would be a bad choice.

Peter Kranz
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com

This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] SUP720's memory, looking at options..

[Mack McBride]

ASR9Ks, we do primarily IP across our core.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: Peter Kranz [mailto:pkr...@unwiredltd.com]
Sent: Thursday, July 07, 2016 2:50 PM
To: Mack McBride
Cc: 'cisco-nsp'
Subject: RE: [c-nsp] SUP720's memory, looking at options..

What are you replacing your converged core with Mack? Nexus 7700's?

Peter Kranz
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com

This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] SUP720's memory, looking at options..

[Mack McBride]

We figure 768 gives us two more years and we are replacing the boxes at the 
core as fast as possible.
Those that are using SRD feature, we can tune tables and still provide clients 
with a full table.
These devices generally only have two paths to the core anyway and don't
Directly connect to the internet.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of James 
Jun
Sent: Thursday, July 07, 2016 9:08 AM
To: Howard Leadmon
Cc: 'cisco-nsp'
Subject: Re: [c-nsp] SUP720's memory, looking at options..

On Thu, Jul 07, 2016 at 12:20:47AM -0400, Howard Leadmon wrote:
>
> Has anybody come up with a good guess as to what is a good division of the 
> TCAM for BGP routing?I have had mine at 640K for IPv4 for a while, but 
> looking at the v4 to v6 ratios, I am thinking maybe 768 for v4 may be a 
> better guess..
>
>

Yes, we use the following on 7600/6500 platforms:

mls cef maximum-routes ipv6 90
mls cef maximum-routes ip-multicast 1

This should allocate most of your TCAM into IPv4/MPLS -- 832k for IPv4 + MPLS, 
90k for IPv6, 1k for multicast.


James
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] SUP720's memory, looking at options..

[Mack McBride]

4 million routes dynamically allocated.



Sent from my Verizon, Samsung Galaxy smartphone


 Original message 
From: Howard Leadmon 
Date: 7/6/16 12:54 AM (GMT-07:00)
To: Mack McBride , 'Gert Doering' 
, 'Peter Kranz' 
Cc: 'Jon Lewis' , 'cisco-nsp' 
Subject: RE: [c-nsp] SUP720's memory, looking at options..

Is there any place where they list how many routes the ASR9K will handle,
granted most of the current goodness is too rich for my blood, but stuff
like the RSP4G and RSP8G are pretty easy to come by.   I thought I saw
something saying they were limited to say 512K routes, but I may be thinking
of something else.

 Nice to hear the ASR1K worked well, even with netflow..


---
Howard Leadmon - how...@leadmon.net
PBW Communications, LLC
http://www.pbwcomm.com

> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Mack McBride
> Sent: Tuesday, July 5, 2016 4:16 PM
> To: Gert Doering ; Peter Kranz
> 
> Cc: 'Jon Lewis' ; 'cisco-nsp'

> Subject: Re: [c-nsp] SUP720's memory, looking at options..
>
> The Sup6T is still TCAM limited.
> We are moving to ASR9Ks.
> But we have used the ASR1Ks where we need full netflow capture with great
> success.
> The port density and total throughput is not as high as the 6500 though.
>
>
> Mack McBride | Senior Network Architect | ViaWest, Inc.
> O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com |
> www.viawest.com<http://www.viawest.com>
>
>
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Gert Doering
> Sent: Tuesday, July 05, 2016 1:03 PM
> To: Peter Kranz
> Cc: 'cisco-nsp'; 'Jon Lewis'
> Subject: Re: [c-nsp] SUP720's memory, looking at options..
>
> hi,
>
> On Tue, Jul 05, 2016 at 10:54:47AM -0700, Peter Kranz wrote:
> > There is also the option of jumping to a used SUP2T or a SUP6T in your
> > 6500 chassis. Depending on the line cards you have, you might have to
> > replace some of them.
>
> Has anyone tried 6T yet?  Does it do useful netflow?
>
> 2T had great promises, but vastly underdelivered, so we're halfway ready
to
> just leave the platform completely...
>
> gert
>
> --
> USENET is *not* the non-clickable part of WWW!
>
//www.muc.de/~gert/
> Gert Doering - Munich, Germany
g...@greenie.muc.de
> fax: +49-89-35655025
g...@net.informatik.tu-muenchen.de
> This message contains information that may be confidential, privileged or
> otherwise protected by law from disclosure. It is intended for the
exclusive
> use of the addressee(s). Unless you are the addressee or authorized agent
> of the addressee, you may not review, copy, distribute or disclose to
anyone
> the message or any information contained within. If you have received this
> message in error, please contact the sender by electronic reply and
> immediately delete all copies of the message.
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] SUP720's memory, looking at options..

[Mack McBride]

Don't get me started on Cisco versioning. It drives me nuts.

The documentation on the ASR1K seems to be better than the ASR9K.
A lot of the 9K documentation is posting on the support forum by ASR9K team 
members.
As for mac accounting on the ASR1K, I haven't had any use for it myself so I 
can't say.
I think it is 512 mac addresses per interface, not sure how sub interfaces are 
counted.
But I think that code is shared across multiple cisco platforms.
For an IX, you might be better off with something like a white box switch 
running custom code.

Here is a cisco reference on the accounting:
http://www.ciscopress.com/articles/article.asp?p=764234&seqNum=3

Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: Gert Doering [mailto:g...@greenie.muc.de]
Sent: Tuesday, July 05, 2016 2:39 PM
To: Mack McBride
Cc: Gert Doering; Peter Kranz; 'cisco-nsp'; 'Jon Lewis'
Subject: Re: [c-nsp] SUP720's memory, looking at options..

Hi,

On Tue, Jul 05, 2016 at 08:15:41PM +, Mack McBride wrote:
> The Sup6T is still TCAM limited.
> We are moving to ASR9Ks.

This was our plan, but right now the platform annoys me somewhat (MAC 
accounting is not reliable, and no MAC addresses in netflow whatsoever - you 
want at least one of them if you peer at IXPs... - and IOS XR train planning 
seems to be totally secret lore, like, why is XR 6.0 for ASR9k totally 
different from XR 6.0 for NCS6k, but still given the same version number [not 
mentioning the two releases of 6.0.1])

> But we have used the ASR1Ks where we need full netflow capture with great 
> success.

Does ASR1k do netflow with src MAC?

I know it does MAC accounting, but limited to 512 entries - which is too 
limited for larger IXPs (like DECIX).  I wonder how it would cope with "more 
MACs" - like, do the first 512 addresses that show up correctly, and ignore the 
rest, whether it can be tweaked to expire entries after  minutes without 
traffic, or whether it's as bad and ill-documented as ASR9k...

> The port density and total throughput is not as high as the 6500 though.

Understood.  This is the problem with the 6500 - it's just too reliable, too 
many ports, and so small money - hard to justify getting boxes with less ports, 
less throughput for much more money.

gert

--
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] SUP720's memory, looking at options..

[Mack McBride]

The spec sheet isn't really clear.
On the 2T it is 1M which is quite constraining.
If it is actually 2M then it would be fine as eventually IPv4 will die and IPv6 
is going to have less prefixes.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: Peter Kranz [mailto:pkr...@unwiredltd.com]
Sent: Tuesday, July 05, 2016 2:27 PM
To: Mack McBride; 'Gert Doering'
Cc: 'cisco-nsp'; 'Jon Lewis'
Subject: RE: [c-nsp] SUP720's memory, looking at options..

Regarding TCAM ... Data sheets are a little confusing in this regard, some 
parts indicate "2M FIB TCAM Entries" some imply a 1M FIB limit. If it is a 2M 
FIB limit, It seems unlikely you would exhaust that limit in the next 10 years.

Peter Kranz
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com

This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] SUP720's memory, looking at options..

[Mack McBride]

The Sup6T is still TCAM limited.
We are moving to ASR9Ks.
But we have used the ASR1Ks where we need full netflow capture with great 
success.
The port density and total throughput is not as high as the 6500 though.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert 
Doering
Sent: Tuesday, July 05, 2016 1:03 PM
To: Peter Kranz
Cc: 'cisco-nsp'; 'Jon Lewis'
Subject: Re: [c-nsp] SUP720's memory, looking at options..

hi,

On Tue, Jul 05, 2016 at 10:54:47AM -0700, Peter Kranz wrote:
> There is also the option of jumping to a used SUP2T or a SUP6T in your
> 6500 chassis. Depending on the line cards you have, you might have to
> replace some of them.

Has anyone tried 6T yet?  Does it do useful netflow?

2T had great promises, but vastly underdelivered, so we're halfway ready to 
just leave the platform completely...

gert

--
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] SUP720's memory, looking at options..

[Mack McBride]

That code is definitely subject to memory leaks.
Specifically if you have a shut down BGP session.
That is also in some revs of SXI.
Later revs tend to have fewer bugs since they are mostly patching bugs.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Howard 
Leadmon
Sent: Monday, July 04, 2016 11:37 AM
To: 'Jon Lewis'
Cc: 'cisco-nsp'
Subject: Re: [c-nsp] SUP720's memory, looking at options..

 FYI, the version I am currently running is 12.2(33)SXJ1, and though I know 
it's not the newest thing going, it for sure has served us well with an
uptime of 4 years, 51 weeks, 4 days, 19 minutes as of this message.I
have little doubt that a reboot may free up some memory, if nothing else some 
more contiguous chunks, but from all I have read here recently, with taking 
full routes this is a short term stop gap measure at best.

 So what I am trying to figure out, is what is a good path forward that will
last more than a couple months at best.   As mentioned below,  I have looked
at just using the RSP720-3CXL as it will take a lot more RAM reduce running on 
the edge of a memory allocation failure (plus the faster CPU is good for BGP).  
I have looked at using something like the ASR1004/6 as with a full load of RAM 
it says it will easily do 4 million routes.  Finally I know someone that has a 
GSR12404 that suggested I use it, and though I know it's not new platform, I 
can't for the life of me figure out what routing limits
it has.   I for sure need 1G and 10G interfaces (not a lot), also need 32bit
ASN support as we already use it at the IX

 The reboot of the current switch would be easy, but if I need to take the time 
to haul around big switches/routers, and changing the network around, I figure 
it just makes good sense to learn what I can to make an informed choice as much 
as possible.


 Happy 4th to any that celebrate it..


---
Howard Leadmon - how...@leadmon.net
PBW Communications, LLC
http://www.pbwcomm.com

> -Original Message-
> From: Jon Lewis [mailto:jle...@lewis.org]
> Sent: Monday, July 4, 2016 9:34 AM
> To: Howard Leadmon 
> Cc: 'cisco-nsp' 
> Subject: Re: [c-nsp] SUP720's memory, looking at options..
>
> On Mon, 4 Jul 2016, Howard Leadmon wrote:
>
> >  I knew with the 720-3BXL's I was running, that eventually the TCAM
> > would become an issue, but it seemed like I still had a little bit
> > of
breathing
> > room left.   Then I saw the chatter here about the RAM on the RP
> exhausting
> > before the TCAM, so went peeking at the switch after reading an earlier
> > thread. Sure enough, though TCAM was starting to get full, to my
> > surprise when I looked at memory, it was at 92%, so even closer than
> > the TCAM by far to exhaustion.
> >
> > I know I can't just up the RAM on the board, so that now leads me to
> > wonder what are reasonable options to resolve this before it becomes
> > a
> very real
> > and big problem.   First let me say, compared to many here we are small
> > guys, we have a limited budget, and our 6509 has served us well for
> > a
great
> > many years, I think it's about to pass the 5yr uptime mark.   We have
2-3
> > full feeds as uptime is important, and we also peer at the Equinix
> > IX, so have a bunch of additional peering sessions.
>
> Some of the software versions for the 6500 have had BGP related memory
> leaks, and if you've got an uptime of 5yrs, that means you're not
> exactly running recent code, and have had a lot of time for memory to
> get misplaced.  I no longer have access to a 6500 with full feeds, so
> I don't
know if
> 3 full feeds + an IX should be running you out of memory.  An
> upgrade/reboot might be worth a try though.  I'd stay in whatever
> major version you're in though...not try jumping to a much later
> version that
might
> be even more memory hungry.
>
> --
>   Jon Lewis, MCP :)   |  I route
>   |  therefore you are _
> http://www.lewis.org/~jlewis/pgp for PGP public key_

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy

Re: [c-nsp] c6500 process memory

[Mack McBride]

Depending on specific code revision it may require a reboot.
Some code revs are worse than others.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of james 
list
Sent: Friday, July 01, 2016 2:15 AM
To: Paul
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] c6500 process memory

Correct, it's SUP720, in my idea I'd like to offload the bgp prefixes received 
by my upstream, in this way I expect BGP process should release some memory, 
right ?

Cheers
James

2016-07-01 0:47 GMT+02:00 Paul :

> I assume it's a sup720, there's nothing you can do. Make sure you stay
> on the old code train SXI or SXJ and that's about it.
>
> Eventually it will run out of ram before it runs out of tcam space
> (bad design on their part i guess)
>
> Cisco could work around this by implementing compression or offloading
> some more processes to the SP but I doubt they have interest in
> reviving the old platform.
>
> 70% is nothing really, I wouldn't worry about it until it's over 95%
>
> On 6/30/2016 12:18 PM, james list wrote:
>
>> Dear experts,
>> just to ask if there are any guidance or best practice about process
>> memory utilization, currently on my C6500 I'm at 70% usage and would
>> like to know if I need to be alterted or not...
>>
>> I use this box for full routing table (BGP process is the higher
>> memory user)...
>>
>> Kind regards
>> James
>> ___
>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
> --
> GloboTech Communications
> Phone: 1-514-907-0050 x 215
> Toll Free: 1-(888)-GTCOMM1
> Fax: 1-(514)-907-0750
> p...@gtcomm.net
> http://www.gtcomm.net
>
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 7600 67xx DOM support

[Mack McBride]

The 10G blades (67xx) support it in 7600 code and 6500 code.
The following link indicates it works on the SFP blades but no idea
On code rev. or hardware required:

http://www.pskl.us/wp/?p=549

>From a 10G module:

#sh int transceiver mod 1
Transceiver monitoring is disabled for all interfaces.

If device is externally calibrated, only calibrated values are printed.
++ : high alarm, +  : high warning, -  : low warning, -- : low alarm.
NA or N/A: not applicable, Tx: transmit, Rx: receive.
mA: milliamperes, dBm: decibels (milliwatts).

   Optical   Optical
   Temperature  Voltage  Current   Tx Power  Rx Power
Port   (Celsius)(Volts)  (mA)  (dBm) (dBm)
-  ---  ---      
Te1/228.5   0.00   6.9  -2.6  -3.3
Te1/429.3   0.00  37.8  -2.3  -2.1
Te1/529.4   0.00   6.0  -2.7  -2.6
Te1/627.2   0.00   5.9  -2.7  -2.1


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick 
Hilliard
Sent: Wednesday, June 22, 2016 1:37 PM
To: Jason Lixfeld
Cc: Cisco Network Service Providers
Subject: Re: [c-nsp] 7600 67xx DOM support

Jason Lixfeld wrote:
> Is the lack of DOM on 67xx series 7600 cards still a thing?

there was a brief period around SXF4 to SXF11 or so where it worked on hw 3.0 
cards.  Other than that, it was disabled in software.

Nick
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] PBR two default gateway

[Mack McBride]

There is one use case where PBR is useful and not much else will work.
This is specific to monitoring.  Where you want a specific IP to only use a 
specific carrier for egress.
This usually involve getting a block from that carrier and then using PBR to 
ensure that ip segment
gets routed out the specified carrier.
This is a very narrow use case and generally other routing methods are 
preferred for practically
anything else.  This is the only use case where I would recommend PBR.

Another very critical thing to note is that PBR will cause a ACL explosions 
under some circumstance.
This can cause the router to crash.

Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick 
Cutting
Sent: Thursday, June 23, 2016 3:06 PM
To: Paul; Satish Patel; Cisco Network Service Providers
Subject: Re: [c-nsp] PBR two default gateway

The old saying goes, if you have to implement PBR, either you need more money 
(BGP), or your design is wrong (use VRFs)

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul
Sent: Thursday, June 23, 2016 4:31 PM
To: Satish Patel; Cisco Network Service Providers
Subject: Re: [c-nsp] PBR two default gateway

PBR is a huge PITA, I prefer using VRF and leaking between the VRF's to adjust 
what i want. it's much safer than PBR imo :)


On 6/23/2016 1:46 PM, Satish Patel wrote:
> I have router with two subnet A & B connected on related physical
> interface. and we have two ISP link so i want to send subnet A to
> ISP-A and subnet B to ISP-B.
>
> is it enough if i do this or do i need to use match interface F1/1?
> Because i want to do whatever coming from my source interface go to
> ISP-A and rest will use ip route 0.0.0.0 0.0.0.0 ISP-B
>
> !
> interface FastEthernet1/1
>   description subnet-A
>   ip address x.x.x.x 255.255.255.0
>   ip policy route-map FOO
> !
> !
> route-map FOO permit 10
>   set ip next-hop x.x.x.x
> !
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Route processor memory at 99% on 720-3bxl

[Mack McBride]

If you can use Selective Route Download, it frees a good bit of space.
We are running BGP with two full tables and we run fairly high mem utilization
but aren't running into the memory leaks that we did on SXJ.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul
Sent: Thursday, June 23, 2016 2:09 PM
To: chiel; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Route processor memory at 99% on 720-3bxl

The new code allocates a lot more resources per BGP prefix. The only option for 
a full table is to go back to the SXJ10 or thereabouts code which will free up 
about 150M of ram due to how it allocates for the BGP database..  You'd think 
it would be more efficient on the new code or use some sort of compression but 
it does not.  Can't use the 15.x code for any devices with full BGP, or even 
cut-down BGP filtering /24's with multiple peers.


On 6/21/2016 6:01 PM, chiel wrote:
> Hi,
>
> We got a 6500 with a 720-3bxl running
> s72033-advipservicesk9-mz.151-2.SY7.bin.
>
> Devices is has to do some basic routing/switching with full BGP.
> - 1x IPv4 full ebgp router with 585172 prefixes and a ibgp with 216827
> prefixes.
> - 1x IPv6 full ebgp with 28013 prefixes and ibgp with 30104 prefixes.
>
> We have already relocated the CEF so tcam can can hold more ipv4
> routes. But the problem the last couple of weeks has been the RP
> memory. At this moment its on 99% utilization  of the max 1GB that the
> 720-3bxl can hold! On short term we can downgrade back to 12.*
> version, or to "ip base" or "ip service" branch, that might give us
> some room to breath. Or are we missing something that could free up
> lots of memory on a 720-3bxl? I heard BGP Soft Reset might free up
> some memory? Is this true and will it be significant?
>
> #show mls cef summary
> Total routes:621171
> IPv4 unicast routes: 590424
> IPv4 non-vrf routes: 590310
> IPv4 vrf routes: 114
> IPv4 Multicast routes:   107
> MPLS routes: 0
> IPv6 unicast routes: 30637
> IPv6 non-vrf routes: 30637
> IPv6 vrf routes: 0
> IPv6 multicast routes:   3
> EoM routes:  0
>
>
> #show mls cef maximum-routes
> FIB TCAM maximum routes :
> ===
> Current :-
> ---
>  IPv4 + MPLS - 832k (default)
>  IPv6- 90k
>  IP multicast- 1k
>
>
> #show ip route summary
> IP routing table name is default (0x0) IP routing table maximum-paths
> is 32
> Route SourceNetworksSubnets Replicates  Overhead Memory
> (bytes)
> connected   0   27  0   1720 4860
> static  1   6   0   648 1260
> ospf 10 4   146 0   9000 27600
>   Intra-area: 13 Inter-area: 80 External-1: 0 External-2: 57
>   NSSA External-1: 0 NSSA External-2: 0
> bgp 16281   178650  411418  0   35404080 106212240
>   External: 537410 Internal: 52658 Local: 0
> internal6527 23798440
> Total   185182  411597  0   35415448 130044400
>
>
> #show processes memory sorted
> Processor Pool Total:  885604800 Used:  873661740 Free:   11943060
>   I/O Pool Total:   67108864 Used:   21605592 Free:   45503272
>
>  PID TTY  Allocated  FreedHoldingGetbufsRetbufs Process
>  648   0  509215580   57367348  508116264  0  0 BGP
> Router
>  380   0  215107608  40228  215035168  0  0 IP RIB
> Update
>0   0  168613476  12296  152776588  0  0 *Init*
>
>
>
> Chiel
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone

Re: [c-nsp] Route processor memory at 99% on 720-3bxl

[Mack McBride]

The memory cost savings of Selective Route Download is still substantial.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: Mark Tinka [mailto:mark.ti...@seacom.mu]
Sent: Thursday, June 23, 2016 12:04 AM
To: Mack McBride; chiel; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Route processor memory at 99% on 720-3bxl



On 22/Jun/16 23:23, Mack McBride wrote:

> The BGP process does receive the updates.  It also has its own version of the 
> RIB.
> The IP RIB Update process handles the 'installed routes' and pushes things 
> out to the CEF.

Yes, but by that time, they have already consumed control plane memory.

Mark.
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Route processor memory at 99% on 720-3bxl

[Mack McBride]

The BGP process does receive the updates.  It also has its own version of the 
RIB.
The IP RIB Update process handles the 'installed routes' and pushes things out 
to the CEF.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: Mark Tinka [mailto:mark.ti...@seacom.mu]
Sent: Wednesday, June 22, 2016 1:35 PM
To: Mack McBride; chiel; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Route processor memory at 99% on 720-3bxl



On 22/Jun/16 19:32, Mack McBride wrote:

> My understanding is that on the 6500/7600 series the IP RIB Update process 
> also contains the prebuilt FIB to be pushed into CEF.
> I may be wrong on that but I don't think so.  BGP-SD definitely does not push 
> the routes into the IP RIB Update process.

You can't stop the control plane from receiving the routes once they have 
arrived. But you can stop the data plane from doing so.

Mark.
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Route processor memory at 99% on 720-3bxl

[Mack McBride]

My understanding is that on the 6500/7600 series the IP RIB Update process also 
contains the prebuilt FIB to be pushed into CEF.
I may be wrong on that but I don't think so.  BGP-SD definitely does not push 
the routes into the IP RIB Update process.

Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: Mark Tinka [mailto:mark.ti...@seacom.mu]
Sent: Wednesday, June 22, 2016 11:15 AM
To: Mack McBride; chiel; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Route processor memory at 99% on 720-3bxl



On 22/Jun/16 19:07, Mack McBride wrote:

>
> You may also want to put in Selective Route Download and rely on
> defaults for routes that are fairly distant from you network wise.  Or just 
> prune your table if that is an option.

BGP-SD won't reduce the RIB memory tax, but it will certainly help to trim the 
FIB if there is pressure there.

Mark.
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Route processor memory at 99% on 720-3bxl

[Mack McBride]

If BGP is holding that much memory I would verify 'soft-reconfiguration 
inbound' is not configured.
It stores the update messages and is not efficient at deleting them.
Then do a 'clear ip bgp *' to restart the process.
A reboot may be in order.

You may also want to put in Selective Route Download and rely on defaults for 
routes that are fairly
distant from you network wise.  Or just prune your table if that is an option.

We are running the same code and not seeing that kind of memory usage on BGP 
router or IP RIB Update.
We have two larger iBGP tables for ipv4 and two ipv6 iBGP table of about the 
same size.
And two downstream customers with full BGP tables.

It is also possible there is some kind of memory leak.
These have previously been associated with 'inactive' bgp sessions.
Even ones that were admin down.

Our utilization of the BGP process:

PID TTY  Allocated  FreedHoldingGetbufsRetbufs Process
 641   0 1219766648 1120578988  396258488  0  0 BGP Router
   0   0  174776148  11120  159003332  0  0 *Init*
 380   0  230882752  145539804   62344120  0      0 IP RIB Update


Mack McBride | Senior Network Architect | ViaWest, Inc.

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of chiel
Sent: Tuesday, June 21, 2016 4:01 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Route processor memory at 99% on 720-3bxl

Hi,

We got a 6500 with a 720-3bxl running
s72033-advipservicesk9-mz.151-2.SY7.bin.

Devices is has to do some basic routing/switching with full BGP.
- 1x IPv4 full ebgp router with 585172 prefixes and a ibgp with 216827 prefixes.
- 1x IPv6 full ebgp with 28013 prefixes and ibgp with 30104 prefixes.

We have already relocated the CEF so tcam can can hold more ipv4 routes.
But the problem the last couple of weeks has been the RP memory. At this moment 
its on 99% utilization  of the max 1GB that the 720-3bxl can hold! On short 
term we can downgrade back to 12.* version, or to "ip base" or "ip service" 
branch, that might give us some room to breath. Or are we missing something 
that could free up lots of memory on a 720-3bxl? I heard BGP Soft Reset might 
free up some memory? Is this true and will it be significant?

#show mls cef summary
Total routes:621171
 IPv4 unicast routes: 590424
 IPv4 non-vrf routes: 590310
 IPv4 vrf routes: 114
 IPv4 Multicast routes:   107
 MPLS routes: 0
 IPv6 unicast routes: 30637
 IPv6 non-vrf routes: 30637
 IPv6 vrf routes: 0
 IPv6 multicast routes:   3
 EoM routes:  0


#show mls cef maximum-routes
FIB TCAM maximum routes :
===
Current :-
---
  IPv4 + MPLS - 832k (default)
  IPv6- 90k
  IP multicast- 1k


#show ip route summary
IP routing table name is default (0x0)
IP routing table maximum-paths is 32
Route SourceNetworksSubnets Replicates  Overhead Memory (bytes)
connected   0   27  0   17204860
static  1   6   0   648 1260
ospf 10 4   146 0   9000 27600
   Intra-area: 13 Inter-area: 80 External-1: 0 External-2: 57
   NSSA External-1: 0 NSSA External-2: 0
bgp 16281   178650  411418  0   35404080 106212240
   External: 537410 Internal: 52658 Local: 0
internal6527 23798440
Total   185182  411597  0   35415448 130044400


#show processes memory sorted
Processor Pool Total:  885604800 Used:  873661740 Free:   11943060
   I/O Pool Total:   67108864 Used:   21605592 Free:   45503272

  PID TTY  Allocated  FreedHoldingGetbufsRetbufs Process
  648   0  509215580   57367348  508116264  0  0 BGP Router
  380   0  215107608  40228  215035168  0  0 IP RIB
Update
0   0  168613476  12296  152776588  0  0 *Init*



Chiel
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply

Re: [c-nsp] 6500/7600 TCAM Usage

[Mack McBride]

I don't think we are going to get there.
Current growth is about 1K prefixes per week for IPv4 and has been for 2 years.
So about 25 years to hit 2 million.

IPv6 will max out somewhere around 3 or 4x ASN count.
Active ASN count is still less than 100K.
Probably also around 20 years to reach 1 million.

Not saying never but the 9K will likely be in the same
position the 6500 is by then.
I also expect table pruning and compression to be a
Bigger part of the routing piece by then.
Maybe an extension to BGP to request specific
Deaggregates or LISP or some other routing
Technology to reduce convergence time.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert 
Doering
Sent: Tuesday, June 07, 2016 12:44 AM
To: Tom Hill
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 6500/7600 TCAM Usage

Hi,

On Tue, Jun 07, 2016 at 12:30:40AM +0100, Tom Hill wrote:
> And, I recalled this from the last BRKARC-2003 - Tomahawk has:
>
>  "4M(v4) / 2M(v6) - XR
>  "10M(v4) / 5M(v6) possible in future release"
>
> So I guess you'll get your full scale Tomahawk-based RSP-880 when
> Cisco are good n' ready!

"XXL license", per line card?

gert
--
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6509 weird pps value

[Mack McBride]

There is no way to check the load directly.
You simply calculate the combined bw of the two ports and that will give you 
the amount of traffic.
Divide by 16G and that will give you the decimal version of percent.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: Ben Hammadi, Kayssar (Nokia - TN/Tunis) 
[mailto:kayssar.ben_hamm...@nokia.com]
Sent: Monday, June 06, 2016 6:01 AM
To: Mack McBride; Saku Ytti
Cc: cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] 6509 weird pps value

Thanks Mack,

 I already check this post , do you confirm that there is no way to check the 
load on the FPGA that connect port pairs as SAKU said ?

 Br.

  KAYSSAR BEN HAMMADI
  IP Technical Manager
  CCIE (#48406), JNCIE-M (#471), JNCIE-SP (#1147)
  Mobile :  +216 29 349 952  /  +216 98 349 952



This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6509 weird pps value

[Mack McBride]

One added note is that there are port pairs on the 6708 line card and those 
port pairs are 16G to connect to the next layer ASIC.
That means that a pair of ports can only handle 16G of traffic where they could 
receive or send 20G.

See my post from 2011.

http://www.gossamer-threads.com/lists/cisco/nsp/145906


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Saku 
Ytti
Sent: Thursday, June 02, 2016 10:26 AM
To: Ben Hammadi, Kayssar (Nokia - TN/Tunis)
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 6509 weird pps value

On 2 June 2016 at 17:43, Ben Hammadi, Kayssar (Nokia - TN/Tunis) 
 wrote:

Hey,

>On the 6708 linecard The fabric asic has 20G and these combine two 
> pairs: 1,4,5,7 and 2,4,6,8 Traffic between ports in these groups does not go 
> over the fabric and is not counted against that BW, what about traffic 
> between groups exemple from port 1 to port 2  in same linecard does go over 
> the fabric ?

Exactly. Inside fabric channel they use local switching and never leave 
linecard. Between fabric channels (Same card or not) they use fabric.

--
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6500/7600 TCAM Usage

[Mack McBride]

One solution that is available on 6500s and 7600s in newer code is Selective 
Route Download.
There are a lot of deaggregates in the table.  Depending on the location of the 
device in the
Routing path and where those routes point you can remove a lot of deaggregates.
This helps with RAM utilization as well.  We are in the process of deploying it 
to devices where
We have downstreams with full tables but only symmetric upstream devices.  Ie. 
Traffic all
goes one direction upstream across multiple identical devices.  This allows us 
to prune a lot.
Where routers actually need to make a decision the amount of pruning is going 
to be a lot less
And you need to have some kind of default.  This works best for deaggregates 
that are far away
Network wise.  Think China for US based or Comcast for Chinese based.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-15-s-book/irg-selective-download.html

That link is for S code but it is also available in SY.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of James 
Bensley
Sent: Friday, June 03, 2016 9:35 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 6500/7600 TCAM Usage

On 3 June 2016 at 07:50, Patrick M. Hausen  wrote:
> Is it possible to e.g. have a TCAM with timestamps associated to
> entries, so one can employ a TCAM as a route cache in LRU fashion and
> process-switch everything new/unknown?

This will penalise stable prefixes.

Cheers,
James.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6500/7600 TCAM Usage

[Mack McBride]

>From prior experience, using 100% and bad things happen.
As the device approaches a full tcam convergence will get much slower.
Additionally the table is not static so you can get bursts of routes associated 
with leaks.
Don't forget there are routes that are not in the BGP and OSPF tables that get 
inserted.
Connecteds, Statics, next hops and vlans and only cisco knows what else.  Most 
people
forget there is a route for every vlan even if no IPs are associated with it on 
the 6500 platform.

I usually use a margin of 10K above what "show ip route summary" is producing 
as a 'safety net'.
Once you get into that range, 'Bad things happen'.

'show mls cef summary' actually shows about 5K less on my devices but those 
routes are still in there.
So don't use that as what is actually getting inserted.



Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Pete 
Templin
Sent: Tuesday, May 31, 2016 2:53 PM
To: Gert Doering; James Bensley
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 6500/7600 TCAM Usage

+1 on what Gert said. You'll get log entries at the 90% threshold within
a region, but the badness only happens when you tickle the 100% threshold.


On 5/31/2016 11:45 AM, Gert Doering wrote:
> Hi,
>
> On Tue, May 31, 2016 at 07:19:22PM +0100, James Bensley wrote:
>> I have asked TAC and they said the TCAM can be 100% used, not until we
>> have 1,024,000 entries in TCAM will we start of see the syslog
>> messages for failing to install a prefix. I am certain that one CAN
>> NOT use 100% of the TCAM space, I'm sure I read somewhere that at
>> around 90% utilisation we start so process switch / drop packets /
>> fail to install routes.
> You can use 100% of what you have partitoned for - so if you partion for
> 512k IPv4, you'll blow up at 512*1024 IPv4 routes (minus a few, I'd
> assume).  Been there, done that - not at 512k but at something like 200k
> on non-XLs, years ago.
>
> That "at 90% utilization bad things will happen" sounds like an urban
> legend from the BNC ethernet times...  it's TCAM, there is nothing magic
> about 90% - either a route can be poked in there, then it will work,
> or not, then all excess routes will be process switch (and subject to
> rate-limiting)
>

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Output drops on 2960

[Mack McBride]

4948Es are pretty good if you need 10/100/1000.
They are also relatively cheap and can be bought used at a good discount.
If you don't need 10/100 then the Nexus 9300 series has a shared 50Mbyte buffer.
But they are relatively pricey and new so used is not really available.


Mack McBride | Senior Network Architect | ViaWest, Inc.
O: 720.891.2502 | C: 303.720.2711 | mack.mcbr...@viawest.com | www.viawest.com


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of John 
Gaffney
Sent: Friday, February 05, 2016 10:46 AM
To: Nick Cutting; Tom Hill
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Output drops on 2960

This looks like a great guide.

Looks like I'll be working to replace the switch with something with more 
power. Any body have a recommendation for a switch with some bigger buffers and 
2x 10G uplinks? Need at least 12 Gig ports.

Thanks,

John


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick 
Cutting
Sent: Friday, February 5, 2016 11:00 AM
To: Tom Hill 
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Output drops on 2960

I use this list for switch buffers - seems pretty accurate to me:

http://people.ucsc.edu/~warner/buffer.html


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tom Hill
Sent: 05 February 2016 15:54
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Output drops on 2960

On 05/02/16 15:45, Nikolay Shopik wrote:
>> > Though, I've not seen anything mentioned in regards to the newer 3650/3850.
> These have double amount of shared memory compare to what 2960S/3560X
> have

Good to know!


--
Tom
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



NAN Cloud Services, powered by McAfee, has scanned and cleared this message 
of any viruses. ___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] C6509 Fabric Switch Capacity

[Mack McBride]

For general internet traffic I have pushed the 6704 to 9+Gbps.
This DFC has almost line rate down to about 64 byte packets.
If you are using a CFC the forwarding bottlenecks at the Sup.
Mixing other non-fabric blades in the chassis has a negative impact as well.
But that is true on the 6708 as well, the difference being the 6708 can't use a 
CFC.
One caveat on the 6500 platform in general is bad things happen if you saturate 
the bus.
Up to and including reload.

Mack McBride
Senior Network Architect

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Azher 
Mughal
Sent: Wednesday, January 13, 2016 8:31 AM
To: Simon Lockhart
Cc: cisco-nsp
Subject: Re: [c-nsp] C6509 Fabric Switch Capacity

:)  I agree, performance will vary for smaller packet sizes.

-Azher

On 1/13/2016 7:24 AM, Simon Lockhart wrote:
> On Wed Jan 13, 2016 at 07:10:09AM -0800, Azher Mughal wrote:
>> For WS 6704 (with DFC3B), I was able to go close to 9Gbps per port
>> across the bus when using Iperf and jumbo frames. Single port on each
>> of the bus gives you line rate of 9.9Gbps.
> Sounds like you come from the Cisco camp of performance testing :)
>
> Yes, under ideal conditions you can probably get close to linerate on
> them, but stick general Internet traffic through them, and you won't.
> I believe it's a limitation on PPS, so jumbo frames are what let you fill the 
> ports.
>
> Simon
>

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Equipment for a large-ish LAN event

[Mack McBride]

If you are getting free loaner gear, I would suggest trying the new Nexus 9300 
series with Nexus 2000 edge.
This creates a single switching infrastructure that appears as a single switch 
and better manageability than the stackables.
If you are going with a nexus 7004 as the core, you can do the same thing with 
the Nexus 2000 edge.
The latency with either one is still going to be well below measurable for 
gaming applications.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Frank 
Bulk
Sent: Saturday, December 26, 2015 10:19 AM
To: 'Laurent Dumont'; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Equipment for a large-ish LAN event

This thread and the video might be interesting and relevant:
http://markmail.org/thread/crgxdtqsbegf72ah

Frank

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Laurent 
Dumont
Sent: Tuesday, December 08, 2015 2:08 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Equipment for a large-ish LAN event

Hi gents,

This email might seem a bit strange but bear with me. I am a member of a 
student club in Montreal named "Lan ETS". Every year, we organize on the 
biggest LAN event in North-America. We have an amazing partnership with Cisco 
where they allow us to request a fair amount of equipment so that we can create 
the best experience for our players.

This year, we are looking into some equipment that slightly out of our usual 
expertise. Usually, we target high-density stackable switches like a 
3650/3750/3850 with 48 GigE and 4 SFP for our 10G core. We design our network 
around small "islands" of players all linked with each other through a 2x10G 
fiber network. Everyone is assigned a public address and we route everyone out 
through our core switch.

We were looking at either the Nexus 7004 chassis or the ASR 9004/9006 chassis 
as the core "switch". We would then use 48xGigE and 1x24 SFP+ line cards. Our 
actual port requirements and somewhat flexible but we do need at least 4x10G 
Fiber ports. And at least 48 GigE ports for players or access switches.

I'm also open to any suggestion within Cisco portfolio. Our needs are pretty 
standard and nothing extraordinary but we would like to use this opportunity in 
order to try new equipment and technologies that are usually only seem within 
ISP and large networks.

I appreciate any input on the matter!

Thank you

--
Laurent Dumont
https://coldnorthadmin.com

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] CoPP on 7600s

[Mack McBride]

This is essentially correct.
Some traffic will hit the mls policers if for example no adjacency is found.
If something matches an mls policer then the hardware CoPP will not apply.
Each blade with a DFC will police separately then it will forward to the 
software policer on the RP.
The PFC will handle blades with CFCs but the same logic applies.

With BGP in particular you want to be careful.
You should make at least three groups.
One for packets with flags, one for packets with just ack that matches expected 
traffic,
And one for packets with just ack from unexpected sources.  You can divide flag 
packets
Up with expected and unexpected sources as well.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Brian 
Turnbow
Sent: Friday, November 27, 2015 1:37 AM
To: 'James Bensley'; 'cisco-nsp@puck.nether.net'
Subject: Re: [c-nsp] CoPP on 7600s

HI James


>
> I'm not sure why traffic like BGP would match into both the hardware
> and software policiers, when its such a simple match statement (I am
> assuming that because the packet count under the software counters is
> much lower than the ACL match, so the rest were policied by
> hardware?):
>
>
> abr1#show access-lists CoPP-Limit-and-Permit-BGP Extended IP access
> list CoPP-Limit-and-Permit-BGP
> 10 permit tcp any eq bgp any (271268749 matches)
> 20 permit tcp any any eq bgp (265404502 matches)
>
>
> Can anyony explain this? And what one can do to stop this?

My understanding is that the 6500/7600 copp passes first through the hardware 
limits and then through  software.
So if it is limited by the hardware it will not reach the software policing.
The hardware limit is done on the pfc/dfc and then the traffic is forwarded to 
the cpu  where software limits are applied.
There is also a relationship to hardware copp and mls rate limiters. The mls 
limiters bypass the hardware copp as they are special treatment.
There was a diagram of it in one of the copp configuration guides.


HTH
Brian


>
> This isn't causing any major issue, CPU usage averages 14% however I
> don't see much point on software based CoPP, seems like an oxymoron to me.
>
> Cheers,
> James.
>
>
>
> abr1#show run | s policy-map Control-Plane-Filter-In policy-map
> Control- Plane-Filter-In  class CoPP-Limit-and-Permit-Critical
>   police cir 1000 bc 312500 be 312500
>conform-action transmit
>exceed-action transmit
>violate-action drop
>
> abr1#show run | s class-map match-any CoPP-Limit-and-Permit-Critical
> class- map match-any CoPP-Limit-and-Permit-Critical  match
> access-group name CoPP-Limit-and-Permit-BGP  match access-group name
> CoPP-Limit-and-Permit-
> BGPv6  match access-group name CoPP-Limit-and-Permit-RSVP  match
> access- group name CoPP-Limit-and-Permit-LDP  match access-group name
> CoPP- Limit-and-Permit-OSPF  match access-group name
> CoPP-Limit-and-Permit-
> OSPFv3  match access-group name CoPP-Limit-and-Permit-HSRP  match
> access-group name CoPP-Limit-and-Permit-BFD
>
> abr1#show access-lists CoPP-Limit-and-Permit-BGP Extended IP access
> list CoPP-Limit-and-Permit-BGP
> 10 permit tcp any eq bgp any (271268749 matches)
> 20 permit tcp any any eq bgp (265404502 matches)
>
> abr1#show access-list CoPP-Limit-and-Permit-BGPv6
> IPv6 access list CoPP-Limit-and-Permit-BGPv6
> permit tcp any  eq bgp any (289479 matches) sequence 10
> permit tcp any any  eq bgp (3 matches) sequence 20
>
> abr1#show access-list CoPP-Limit-and-Permit-RSVP Extended IP access
> list CoPP-Limit-and-Permit-RSVP
> 10 permit 46 any any (16834 matches)
>
> abr1#show access-list CoPP-Limit-and-Permit-LDP Extended IP access
> list CoPP- Limit-and-Permit-LDP
> 10 permit tcp any any eq 646 (319014 matches)
> 20 permit tcp any eq 646 any (2210932 matches)
> 30 permit udp any any eq 646 (21460077 matches)
> 40 permit udp any eq 646 any (230 matches)
>
> abr1#show access-list CoPP-Limit-and-Permit-OSPF Extended IP access
> list CoPP-Limit-and-Permit-OSPF
> 10 permit ospf any any (10542225 matches)
>
> abr1#show access-list CoPP-Limit-and-Permit-OSPFv3
> IPv6 access list CoPP-Limit-and-Permit-OSPFv3
> permit 89 any any sequence 10
>
> abr1#show access-list CoPP-Limit-and-Permit-HSRP Extended IP access
> list CoPP-Limit-and-Permit-HSRP
> 10 permit udp host 224.0.0.2 eq 1985 any
> 20 permit udp any host 224.0.0.2 eq 1985 (48840573 matches)
> 30 permit udp host 224.0.0.102 eq 1985 any
> 40 permit udp any host 224.0.0.102 eq 1985
>
> abr1#show access-list CoPP-Limit-and

Re: [c-nsp] GRE tunnel 8000kbit (8Mbit) limit issue

[Mack McBride]

I have seen this problem on various cisco switches (3550, 3560, 3750, 4948).
They don't support GRE in hardware.
The rest of the 49xx series and 45xx doesn't do it in hardware either
As far as I know.

Under certain circumstances software handling even happens on the 6500.
GRE tunnels can eat the cpu even if It is done partially in hardware.
Enabling certain features will cause it to be done partially or completely in 
software
on the 6500.

Frankly a software router is better for GRE termination.
The ASR1K series is great for it but it is technically still done in software.
It just has a huge number of cores to do the encapsulation.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert 
Doering
Sent: Wednesday, July 15, 2015 3:24 PM
To: a.l.m.bu...@lboro.ac.uk
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] GRE tunnel 8000kbit (8Mbit) limit issue

Hi,

On Wed, Jul 15, 2015 at 06:55:57PM +, a.l.m.bu...@lboro.ac.uk wrote:
> (though more googling finds statement of no official support for GRE
> even on 3750-X or that it cannot terminate GRE... well, the commands are 
> there and the tunnel works..

Classic IOS misfeature - "if the hardware cannot do it, just pretend everything 
is all right and try to do it in software".  At least a word of warning would 
have been nice...

(Sometimes it's handy to have a feature-in-software for management purposes, if 
you *know* there is not going to be much traffic over it, but the box need to 
tell you so)

gert


--
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] SFPs (Third party) - ordered "standard" LH, but got "ZX"

[Mack McBride]

If they are 1310nm then they definitely are not ZX which are 1550nm.
EX are also 1310nm which are generally 40km.
I am guessing it is just a bug in the ASR.
As others have said, cisco doesn't always work right even with their own
Optics.  If you didn't have to resort to transceiver permit pid all or 
transceiver unsupported
When placing them in equipment then consider it a win.

The light levels are consistent with LX/LH.
EX transmit levels are above -1 db
And ZX transmit levels are above 0 db.


Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jared 
Mauch
Sent: Monday, July 06, 2015 1:16 PM
To: CiscoNSP List
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] SFPs (Third party) - ordered "standard" LH, but got "ZX"


> On Jul 6, 2015, at 4:50 AM, CiscoNSP List  wrote:
>
>
> Hi Everyone,
>
>
>
> As per titleordered a bunch of our usual single mode SFP's. and
> they are badged as LH, but when inserted into router/switch, they
> report as ZX.can I connect our LH to the new ZX ones (I dont have
> a router/switch handy to test), and have to ship them
> interstate.but obviously dont want to if they are no compatible
> with our existing LH SFP's

Oh one more thing:  I’ve noticed that some 10KM SFPs come as 20km capable:

Date Code: 150213
1000Base-LX
extended compliance_code 0
Distances:
SMF - 20 km
SMF - 2 meters
OM4 - 320 meters
Wavelength: 1310.00nm

It’s possible that the router interprets >10km as ZX.

- Jared
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] CoPP on 7600s

[Mack McBride]

Ah, that explains it.
It works unless there is more than one match statement.
All of our classes just have one match statement.
Interesting to know.  The older code (6500 code) didn't support multiple
match statements at all so we never added them when we upgraded.

I would evaluate what you can move from HWRL to CoPP.
And yes if you have no icmp redirect everywhere then you can disable the HWRL 
that corresponds.
Just remember to put it on the Loopback interfaces otherwise you can still have 
issues.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Saku 
Ytti
Sent: Wednesday, July 01, 2015 12:44 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] CoPP on 7600s

On (2015-06-30 22:06 +0000), Mack McBride wrote:

Hey,

> I have never run into a problem with using deny in a CoPP ACL.
> It ends that specific class processing if the deny matches.
> The next class will still be processed properly (or at least I have never run 
> into a problem).

In 2006-06-20 I opened CSCse90832 titled 'explicit deny in a CoPP ACL allows 
traffic to skip later match statemets'. It has this:

--
Workaround:
Use only one match statement per class-map and create multiple class-maps.

Do not use the deny statement in an ACL that will be used as a part of a 
class-map that has more than one match statement.
--

It's terminated with no fixed versions.


I recall also discussion how it's not supported. And at any rate, there is no 
use case for it. As self-documenting policy I too like to explicitly add 
implicit ultimate rules, but in this case it bit me.
I had to open about dozen DDTS's on CoPP when I deployed it in 2006. But I am 
extremely happy how Cisco handled it, I had access to clued people in 
escalation TAC and issues were resolved in timely manner.

> We break out classes for pretty much everything we can.
> Complex CoPP tends to work better and need fewer major changes.

We've not changed the design since 2006 and it's ran on hundreds of 7600. I 
know it's not bullet proof, as some compromises are made for simplicity but I 
accept that, as 7600 cannot be protected perfectly from directly connected 
attackers.

> As for HWRL, we use glean and mtu-failure.
> Use of other rate limiters can cause the CoPP to be bypassed on
> ingress And all CoPP to be done in software on the RP.

Our HWRL are full, and I'd like to use more:

mls rate-limit multicast ipv4 fib-miss 2000 10 mls rate-limit multicast ipv4 
non-rpf 10 10 mls rate-limit multicast ipv4 igmp 2000 10 mls rate-limit 
multicast ipv4 partial 2000 10 mls rate-limit unicast cef glean 200 50 mls 
rate-limit unicast ip options 10 10 mls rate-limit unicast ip rpf-failure 10 10 
mls rate-limit unicast ip icmp redirect 0 mls rate-limit unicast ip icmp 
unreachable no-route 10 10 mls rate-limit unicast ip icmp unreachable acl-drop 
10 10 mls rate-limit unicast ip errors 10 10 mls rate-limit all ttl-failure 200 
50 mls rate-limit all mtu-failure 10 10 mls rate-limit layer2 pdu 20 20

I could probably get rid of 'icmp redirect' as all interfaces have redirects 
disabled, that would free me another slot for things I need.

> One important thing to remember with CoPP is to baseline before you
> implement dropping traffic.  That way you can verify what you are
> doing will not affect normal operations.

You can also redirect dropped traffic out to an analyzer port, just to monitor 
early on what exactly is being dropped, so you can react.

--
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] CoPP on 7600s

[Mack McBride]

I have never run into a problem with using deny in a CoPP ACL.
It ends that specific class processing if the deny matches.
The next class will still be processed properly (or at least I have never run 
into a problem).

We use separate BGP and BGP flags groups in our network.
So BGP is one and any port 179 source or destination with SYN, FIN, or RST set 
is another.
We also have a default BGP class so all BGP works but if it isn't specifically 
allowed it can be slow
To converge.  We make updating the ACL part of the BGP provisioning process.
Since we have to update prefix-lists as well, this isn't extraordinarily 
difficult.

We break out classes for pretty much everything we can.
Complex CoPP tends to work better and need fewer major changes.

As for HWRL, we use glean and mtu-failure.
Use of other rate limiters can cause the CoPP to be bypassed on ingress
And all CoPP to be done in software on the RP.

One important thing to remember with CoPP is to baseline before you
implement dropping traffic.  That way you can verify what you are doing
will not affect normal operations.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Saku 
Ytti
Sent: Monday, June 29, 2015 6:03 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] CoPP on 7600s

On (2015-06-29 10:00 +0100), James Bensley wrote:

Hey,

> Using MLS I can choose any of the following protocols...
> 7606(config)#mls qos protocol ?

These are not control-plane, they apply to transit as well. You don't want to 
use them, unless you must (neigh-disco, arp)

> I can knock up a quick script to generate ACLs for CoPP but then every
> time a peer is added the ACL needs updating. Since this is a PE box
> BGP adds/moves/changes are fairly frequent. This will quickly reach
> the point where someone forgets to remove a peer or add them to the
> script etc. The KISS approach is always best but "any any eq 179" is
> just too simple IMO, perhaps a policer for connections with SYN flag
> set on TCP 179 and then another policer for all other traffic on TCP
> 179.

We've not had problems with it. It's just one line to add, to already quite 
many lines when provisioning BGP peer. And no one forgets, because peer won't 
come up without.
Forgetting extra lines there, does not appear catastrophic to me.

> OK I had read about it potentially stopping the evaluation against
> remaining ACLs so noted. Perhaps a better method here is to make
> another ACL that matches the traffic I definatly want to drop and in
> there have "permit icmp any any" which is less specific and then under
> my CoPP policy just have the drop action.

Let unwanted just to flow to last class of 'IP' which matches ACL 'any any'
and drops even conforming traffic.
Then leave class-default as last, and allow traffic there (non IP will hit it, 
like CLNS)

--
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Sup720 -> Sup2T migration and CoPP

[Mack McBride]

Since the processor is faster you may want to open up policies a bit more as 
well.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul
Sent: Sunday, May 31, 2015 1:03 PM
To: Robert Hass; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Sup720 -> Sup2T migration and CoPP

The 2T adds a lot more things that you can match with your CoPP , but it will 
work fine just copying your existing CoPP setup from the sup720 (you just won't 
be taking advantage of the new class maps for matching).


On 5/31/2015 7:20 AM, Robert Hass wrote:
> Hi
> I'll have of migration older Cat6500 boxes to new 6807 chassis plus
> Sup2T Supervisors.
>
> I'm only not sure about migration of CoPP configuration ? Anything
> changed between PFC3 (Sup720) and PFC4/DFC4 (Sup2T) regarding this or
> I can just re-apply my current CoPP configuration ?
>
> Any other hint regarding this kind of technology upgrade migration ?
>
> Rob
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

--
GloboTech Communications
Phone: 1-514-907-0050 x 215
Toll Free: 1-(888)-GTCOMM1
Fax: 1-(514)-907-0750
p...@gtcomm.net
http://www.gtcomm.net

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] outdoor rating

[Mack McBride]

We use the IE-3000 series which is smaller than the IE-3010 and probably cost 
less.
The temp ratings are similar, noting that your temp is governed by enclosure 
type.
A vented or fan equipped enclosure is needed to get maximum temperature rating.
The IE-3000 is rated for higher altitude than the IE-3010.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
harbor235
Sent: Wednesday, May 27, 2015 1:45 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] outdoor rating

Anybody have experience with network devices in covered areas not directly 
exposed to the elements but exposed to external temperature variations?

Do I need an enclosure or is there exterior models that cam withstand the 
elements?
 Google-fu revealed Cisco 3010.


Mike
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] "New" IOS release time frame, when bug is identified

[Mack McBride]

If you only use links and loopbacks in your network the table should be pretty 
small.
Eliminating links is necessary once you get to a certain size but we are in 30 
something locations in numerous states and two countries
and we haven't had to remove links yet.  BGP links to eBGP sessions should 
probably be the last links removed.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mark 
Tinka
Sent: Friday, May 22, 2015 10:36 AM
To: Daniel Dib; 'CiscoNSP List'; alum...@gmail.com; 'Phil Mayers'
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] "New" IOS release time frame, when bug is identified



On 22/May/15 17:40, Daniel Dib wrote:
>
> The networks I've been involved with only assign labels to loopbacks.
> Wouldn't it be a huge waste to assign labels to all IGP prefixes?
> They're not your next-hops (hopefully).

One would think so - but that's how Cisco do it by default.

>
> Anyway, I guess it would take a quite large network to run out of
> labels or a lot of change in the network.

That too - which is why it seems like a bug re: this thread, and not the normal 
way things should go.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Sup2T MPLS-TE - Strange issue with MTU selection

[Mack McBride]

The only two options I can think of are reboot the box and see if it fixes it
Or open a tac case with cisco (which I am guessing you can't do because you 
don't have
a service contract).

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: James Jun [mailto:ja...@towardex.com]
Sent: Sunday, May 17, 2015 6:11 PM
To: Mack McBride
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Sup2T MPLS-TE - Strange issue with MTU selection

Hi Mark,

> Sounds like there is a link somewhere in the path with 1500 MTU.
> I would check everything in the path.

Yes, I have tested fully in both directions -- I can definitely guarantee that 
all interfaces throughout the entire path is 9216-clean and I am able to ping 
between all routers with s
ize=9000 and df-bit set.

> And verify the path is what you think it is.
> Remember tunnel paths are not necessarily symmetrical.
>

The problem is definitely with this box; if I spawn another TE tunnel to a 
directly adjacent neighbor (thus there is no other link somewhere that could 
have 1500 in the path, it's directly attached interface to the router next to 
it), it too shows up as MTU=1500 in 'sh mpls interface detail' output.  The 
problem here is any tunnels originated by Sup2t thinks transport mtu is 1500 on 
any TE tunnels originated by it, even to directly neighboring router with 
mtu=9216 interface.  Now, if you look at the return-path (the 'other' 
unidirectional LSP) coming back to Sup2T from the other router, they all see 
MTU=9216 on their 'show mpls interface' output.

I think I'm hitting a bug somewhere.. Like I said, this wasn't a problem before 
until very recently where the only change that was made was an addition of 
6704-10g card into the chassis.

Best,
James
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 7600 upgrade recommendations?

[Mack McBride]

This often depends on what your vendors have in stock that they are trying to 
get rid of.
Especially on the used market where 9001s are practically non-existent.
Either will make an excellent border, or use one of each to protect against
code specific bugs. We use different models in our environment to protect 
against
code bugs because we got bit when we were running 6500s as borders years back.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: Nick Hilliard [mailto:n...@foobar.org]
Sent: Monday, May 18, 2015 9:18 AM
To: Mack McBride; Bill Buhlman; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 7600 upgrade recommendations?

On 17/05/2015 20:04, Mack McBride wrote:
> The ASR1006, should give you good service as a border with ESP40 and SIP40 
> cards.

good service, but the cost per port of asr9001 is often a good deal better.

Nick

This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Sup2T MPLS-TE - Strange issue with MTU selection

[Mack McBride]

Sounds like there is a link somewhere in the path with 1500 MTU.
I would check everything in the path.
And verify the path is what you think it is.
Remember tunnel paths are not necessarily symmetrical.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of James 
Jun
Sent: Sunday, May 17, 2015 5:50 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Sup2T MPLS-TE - Strange issue with MTU selection

Greetings!

I'm having a really strange problem with Sup2T running RSVP-TE over MPLS that's 
making me scratch my head.  The problem is, Sup2T on this box thinks that 
underlying transport MTU for the LSP TE tunnels is 1500, even though it's 9216 
all the way across everywhere (wtf!).  It used to work perfectly fine until 
recently, about a day after we inserted a WS-X6704-10GE card with 6700 CFC.  
Anybody had similar problems before?

The underlying transport (core-facing) interfaces are Ten1/4 & Ten2/1, each set 
with MTU=9216.  But, when TE tunnels come up, the output of 'show mpls 
interface detail' lists the tunnel as having only 1500 bytes MTU.  However, 
other PE routers pointing back at this 6500 properly show MTU=9216 on their 
LSPs, as they should.

This problem is causing LSPs to fail at times and the overlayed LDP-over-TE 
sessions to bounce repeatedly due to hold-timer expiration.  Additionally, I 
can't even ping the remote side PE's loopback at any size greater than 1500 w/ 
df-bit set.

And yes, I've verified that jumboframe actually works -- not only could I ping 
adjacent neighbor IPs at full 9100+ size with df set, OSPF also works without 
any retransmissions.  Likewise, if I take the remote side PE's loopback IP and 
static-route it (so it goes over native IP instead of MPLS), it will ping at 
size 9000.  But anytime it encapsulates over the TE tunnel, it can't transmit 
at sizes bigger than 1500 bytes.

Any ideas on why Sup2T is fooled into thinking that underlying transport tunnel 
MTU is only 1500 for the MPLS-TE tunnels?


The box is running s2t54-adventk9-m 15.1(2)SY4, with following:

Slot 1:  VS-S2T-10G
Slot 2:  WS-X6704-10GE w/ F6700-CFC version 4.1 Slot 3:  WS-X6724-SFP w/ 
F6700-CFC version 3.0 System PFC operating mode is: PFC4 (both legacy X6700 LCs 
have CFC)

This is a standalone E chassis, without VSS.

Many thanks in advance.

Best,
james

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 7600 upgrade recommendations?

[Mack McBride]

I would upgrade the Sup720-3BXLs to RSP720-3CXL with additional ram at the 
location you are going to take full tables.
If you aren't running 7609S then you would need chassis upgrades which might 
push you a different direction.

Honestly I would upgrade you border connected routers and leave 7600s at other 
sites.
I am assuming that you have a single site that actually receives transit.
The ASR1006, should give you good service as a border with ESP40 and SIP40 
cards.
The core functionality where you connect to the border routers (I assume you 
have 2 for redundancy),
Should be capable of doing full tables if you are going to be running full 
tables.
Honestly you may be better off just accepting customer routes and pruning a lot 
of the routes out.
Unless your customers are insisting on full tables you could survive quite a 
while on the 7600 series.

There are really too many ways to skin this to do it without a consultant.

The questions you need to ask are:
1) Do you need full tables (I mean really), if you do then prepare for 9010s.
2) How resilient is your current design (do you need to install redundancy).
3) How many 10G circuits will you be supporting in 18 to 36 months.
4) Do you need full tables everywhere (sites that don't are probably fine with 
7600s).

For point four, remember that full table sites cannot transit non-full table 
sites without
some serious risks unless you use MPLS or some other tunneling protocol so that 
they never
see the non-full table sites.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Bill 
Buhlman
Sent: Friday, May 15, 2015 3:20 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] 7600 upgrade recommendations?

Hi,
I've been a lurker for a long time and just listening and learning but now I'd 
like some help please.

I'd like some recommendations, we are running a 7609 with dual Sup720-3BXL's 
and 22 Metro Ethernet connections ranging from 10Mbs up to 10G. We are a 
service provider for school districts in our county. Our transit traffic is 
usually 3Gbs ~6Gbs but peaked at 9Gbs yesterday out to our provider.

I have one WS-6708 with two agg circuits (ATT and Comcast) that need to be line 
rate and also a SIP-400 with a 1x10GE to the provider router which is on site 
here. I also have one ES-20 (not ES20+) LC with 10 ports active. I still have a 
channelized DS3 with only 7 DS1's so I can use an 8-port serial if I need to.

I am running BGP with just a default route to our provider but will need to run 
at least one full table (v4 and v6) in the future. I am running EIGRP to the 
schools that we provide Internet access for.

ISSUES - We have districts now that are buying point to point 10G circuits and 
I estimate I will need three 10G ports at line rate (agg circuits) and three 
that can be oversubscribed in the next year with at least two ports reserve or 
the ability to add another line card. (So an additional three 10G ports). I 
need at least ten 1G SFP based ports (I am ready to give up the ES20 and buy 
the "+" version). I also need shaping, policing and HQoS that doesn't tax the 
supervisor CPU's. I think the ES20+ LC will do this?

Cisco of course wants to sell me an ASR9K but I am not apposed to staying with 
the 7600 if it can hang with a few new or used parts

Thanks in advance!

-Bill


Bill Buhlman
Network Engineer
Contra Costa County Office of Education
77 Santa Barbara Road
Pleasant Hill, CA 94523
925-942-5362 - Office
925-296-1469 - Fax
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] One Cat6k/Sup2T is software switching, its identical partner is not

[Mack McBride]

Are all of the acls the same on both boxes?
It almost sounds like one box had a tcam explosion due to differing ACLs.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeroen 
van Ingen
Sent: Saturday, April 18, 2015 9:34 AM
To: Łukasz Bromirski
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] One Cat6k/Sup2T is software switching, its identical 
partner is not

Hi Łukasz,

>> We have two Cat6k's with Sup2T in our network, both running IOS 15.1(1)SY3.
>
> Are they really identical, down to Sw/Hw revisions and ROMMON
> versions?

You got me there. PFC4 versions differ: the one doing everything in hw has hw 
rev 2.0, the one partially software switching currently has a
PFC4 hw v1.1 and previous sup had PFC4 hw 1.6 iirc. Line cards do have the same 
HW rev and ROMMON versions are identical too.

I mentioned this to TAC but the response was that that couldn't be related. My 
question about what sort of changes were made or could have been made in those 
revisions wasn't answered though. Did you ever hear details about differences 
in hw revisions?

> It seems that something on the device side either interprets the
> configuration in different order and this hits some rare bug, or
> there’s something other at the software/hardware border that you’re
> hitting.

Yeah, that was what I thought. Guess there's not much more to do than hope that 
our TAC case will eventually go to the right people. I heard it's on its way to 
the Cat6k BU and a friendly TME + our account managers are now tracking the 
case, so hopefully we'll see some progress next week.

Thanks,

Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands 
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Storm-control Issue

[Mack McBride]

A link to the article/web page would be helpful because the current first hit 
on page three really doesn't relate to the issue.
Remember the order can change based on someone's search history as well as the 
number of people visiting a link
And additional links being added.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick 
Hilliard
Sent: Wednesday, April 15, 2015 6:04 AM
To: M K; Chuck Church; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Storm-control Issue

On 15/04/2015 13:02, M K wrote:
> The output tells me I have the ability , and I compared it to another
> module and the same appeared
>
>   2   48  48 port 10/100 mb RJ45 WS-X6348-RJ-45 
> SAL06313RHP

http://goo.gl/I2GlGA

First hit, page 3.

Nick


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 3850?

[Mack McBride]

To get flexible netflow via nbar you are probably going to have to go to much 
more expensive box.
The 72xx series might do it as Gert mentioned.  But nothing with hardware 
forwarding is really going to do that.
You probably need a separate switch and router to achieve what you need unless 
you go up to a ASR1000 series.
The ASR1001 would be a good fit depending on the port count you need.  But 
again you might need a router and
A switch to achieve what you need.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert 
Doering
Sent: Thursday, April 09, 2015 12:52 PM
To: Adam Greene
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 3850?

Hi,

On Thu, Apr 09, 2015 at 11:17:17AM -0400, Adam Greene wrote:
> -  Flexible NetFlow with NBAR

*this*

I'm pretty sure the 3750 cannot do netflow in hardware (even less NBAR) - so 
it's going up to software, and its tiny CPU is not up to the job.

I have no experience with 3850, but I bet a beer that it is not capable of 
doing "netflow with NBAR" in hardware either - and I would doubt even "basic 
netflow", but maybe things improved there in recent years.

NBAR is hard for anything "in hardware".

What traffic levels do you realistically need on the routing side of things?  
If you do switching on a switch (a 3750 is fairly good for that) and offload 
routing to something with a faster CPU and vlan subinterfaces, it might work 
out - depending on traffic.  Like, a used 7201, for up to
200-300 Mbit/s ...

gert

--
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] CSR1000v as an IPSLA probe

[Mack McBride]

Virtualized environments are not ideal for this unless they are dedicated to 
the task.
Ie. one VM on one physical box.
Other issues related to SLA are jitter and latency.
These can be a serious problem in a virtualized environment.
You would be much better served by getting a 2911.

http://www.cisco.com/c/en/us/products/routers/2911-integrated-services-router-isr/index.html

If you are only concerned about reachability then a VM might work ok.
It would require tuning so that the VM associated with the CSR1000v is getting 
priority on
The resources, particularly network buffers.  And adjusting QoS so the ping 
packets
Have preference on the upstream switch.
But again, this isn't ideal.  Getting a 2911 would probably still be a better 
option.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Dan 
Peachey
Sent: Thursday, April 09, 2015 10:24 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] CSR1000v as an IPSLA probe

Hi,

Is anyone using a CSR1000v VM as an IPSLA probe? If so I would like to hear 
your experiences with it.

I'm currently evaluating it and have come out with some poor test results so 
far, with the main issue being tail dropped packets when CPU utilisation is 
above ~30%.

Regards,

Dan
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 3850?

[Mack McBride]

The input queue is the software side of things.
Things that are handled in hardware should be on the no buffer line.
Why are you getting so much software bound traffic?
Things that are getting dropped due to output queueing are going to show as 
output drops.

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series-switches/116089-technote-switches-output-drops-qos-00.html

Another place they will show up is the QoS command: sh mls qos interface 
 statistics

On these model switches things tend to get dropped due to lack of buffers or 
output dropped.
If you are having input queue drops it is usually due to things getting sent to 
software.
Usual suspects are multicast traffic, broadcasts, or routing protocols.
You can also get direct attacks against the switch if it is operating in routed 
mode.

And in that situation upgrading the switch isn't going to solve the problem.
If it is actually traffic based considering upgrading to a 4948E.
It is a much more capable switch.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Adam 
Greene
Sent: Thursday, April 09, 2015 9:17 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] 3850?

Hi all,



We're looking to upgrade some old 3750's and 3750G's whose input queues don't 
seem to be able to pass 75Mbps without choking:



(on a 3750G)

Last clearing of "show interface" counters 21w5d

Input queue: 1/75/5870052/0 (size/max/drops/flushes); Total output drops:
0).



We need the switches to support:

-  basic QoS policies (mainly, VoIP and routing protocol
prioritization)

-  Flexible NetFlow with NBAR

-  125Mbps aggregate throughput via any given interface now, and
more in the future. If I had to guess, 450Mbps aggregate within 3 years

-  OSPF & BGP



We don't anticipate stacking these.



We're considering:

-  WS-C3850-24T-E (modular)

-  WS-C3650-24TD-E (fixed; 2x10G uplinks)

-  WS-C3650-24TS-E (fixed; 4x1G uplinks)

-  WS-C3560X-24T-E (modular)



I like the idea of the switch being modular, in case we want to put in 10G 
modules later on, but realistically, can any of these switches even push 1Gbps 
reliably? After seeing "gigabit" 3750s balk at such low traffic levels, I 
wonder how much we can really expect any of these switches to push.



Of all the options, the WS-C3850-24T-E seems the most flexible and probably 
most powerful. I was feeling enthusiastic about the 3560X until someone told me 
that Flexible NetFlow is supported, but only if you buy the 10G module, which 
costs as much as the switch itself.



Do you think we're on the right track? Is the WS-C3850-24T-E probably the best 
fit? How much traffic have you all seen it push in the real world?



Thanks for sharing your experience.



Adam





___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 7600 high cpu due to BGP process

[Mack McBride]

The usual response with code that old is to upgrade code.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
thiyagarajan b
Sent: Tuesday, April 07, 2015 2:26 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] 7600 high cpu due to BGP process

Hi

7606 router with 3CXL runs 12.2(33)SRC4 version has high CPU due to BGP router 
and BGP scanner, when checked , there are no session flaps or route flaps and 
memory is 2GB with nearly 800MB free in it.

Any reason for this cause?

Warm Regards.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] RR Client in different AS?

[Mack McBride]

If the next-hop is not accessible from the 'new' network, the routes will not 
be learned.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
CiscoNSP List
Sent: Tuesday, March 31, 2015 5:19 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] RR Client in different AS?

Hi Everyone,

Quick question (I hope!) - A customer has an RR that successfully 
peers/distributes routes to RR-clients in the same AS...they have added another 
"network", running a different AS, and have successfully peered to the RR(So 
added the new networks router as an RR-client, but with a different AS)the 
RR is advertising all learned routes from the "original" network to the "new" 
network(sh ip bgp nei x.x.x.x advertised-routes), but the "new" network(With 
the different AS) is only accepting the default route? (There are no inbound 
policies on the new networks RR-client router).

Is this expected behaviour? (I've googled, but havent found anything definitive)

Cheers.







___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] cisco regex puzzle of the day

[Mack McBride]

Yes agreed.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Saku 
Ytti
Sent: Thursday, March 12, 2015 3:50 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] cisco regex puzzle of the day

On (2015-03-12 01:12 +), Mack McBride wrote:

Hey,

> The junos expression in question DOES NOT involve backtracking.
> After a match there is no need to backtrack.
>
> The expression in question goes character by character excluding the 64500.
> Note the last part matches 6 digit ASNs that start with 64500.

I think we miscommunicated. Originally I explained IOS does not work, because 
it does backtracking, not talking about JunOS at all.
Then you mentioned that particular JunOS example does not do backtracking, 
which I understood you claiming JunOS does not support backtracking at all

So to summarize, both IOS and JunOS do backtracking, and it cannot be turned 
off. But indeed, ^64500+ [^64500] does not require backtracking, 64500+ never 
needs to be unconsumed to satisfy the [^64500]

--
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] cisco regex puzzle of the day

[Mack McBride]

The junos expression in question DOES NOT involve backtracking.
After a match there is no need to backtrack.

The expression in question goes character by character excluding the 64500.
Note the last part matches 6 digit ASNs that start with 64500.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Saku 
Ytti
Sent: Wednesday, March 11, 2015 11:54 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] cisco regex puzzle of the day

On (2015-03-11 17:28 +), Mack McBride wrote:

Hey,

> There is no back tracking in the junos regex nor would backtracking really 
> help.
> Doing this is complicated on cisco due to the lack of negating a full as.

There definitely is backtracking, the reason (64500_)+.+ doesn't work, and 
matches 64500 64500 is that after the (64500_)+ has chomped up both of them, it 
backtracks, trying to see if by going back, it can further satisfy the .+, and 
it'll notice that by going back whole 64500 it can satisfy both.

If it wouldn't backtrack, '64500 64500' wouldn't match, but 64500 64501 would 
match, and we would in simple and clear regexp achieve what we want.

However, disabling backtracking globally would break common use-case such as 
^.*_64500$

Turns out, some regexp engines allow turning off backtracking conditionally 
either by adding '+' after +*, or by adding ?> to group. In which case 
(64500_)++.+ and (?>64500_)+.+ would work.
Unfortunately neither regexp engine IOS has supports either of these.


> I haven't tested this but it should work:
>
> (65400_)+([1-57-9][0-9]*_|6[01-35-9][0-9]*_|64[01-46-9][0-9]*_|645[1-9
> ][0-9]*_|6450[1-9][0-9]*_|64500[0-9]+_)+

Thanks, I was afraid it'll be something terrible, I don't dare to try  :)

--
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] cisco regex puzzle of the day

[Mack McBride]

There is no back tracking in the junos regex nor would backtracking really help.
Doing this is complicated on cisco due to the lack of negating a full as.

However loop avoidance should prevent 64500 from occurring twice with an 
intervening AS.
If you have turned off loop avoidance with allowas-in then you have a lot
More complexity to worry about.

I haven't tested this but it should work:

(65400_)+([1-57-9][0-9]*_|6[01-35-9][0-9]*_|64[01-46-9][0-9]*_|645[1-9][0-9]*_|6450[1-9][0-9]*_|64500[0-9]+_)+

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Saku 
Ytti
Sent: Wednesday, March 11, 2015 10:38 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] cisco regex puzzle of the day

On (2015-03-10 20:29 +0100), Job Snijders wrote:

> "^64500+ [^64500]"
>
> This junos beauty will match for example: "64500 64500 123 123 444",
> but not "64500 64500" or "64500".
>
> Can any of you come up with a single line regex that works on IOS or
> XR
> (ios-regex) to mimick the above described behaviour?

Follow-up question. Is there use-case for regular expression backtracking in 
AS_PATH?
It would be simpler to implement without backtracking and it would fix this 
specific use-case, as simple '(64500_)+.+' would work. But perhaps it's still 
stupid idea, perhaps it'll break lot of really common use-cases.

--
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Max-Prefix - Notification Data Decode Options ?

[Mack McBride]

What is the value you are expecting?
The last four digits indicate 400 (190 is hex obviously).
I mean, how many prefixes are you expecting to send to your provider?

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Darin 
Herteen
Sent: Tuesday, March 10, 2015 1:38 PM
To: Nick Hilliard; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] BGP Max-Prefix - Notification Data Decode Options ?



> Date: Tue, 10 Mar 2015 17:24:36 +
> From: n...@foobar.org
> To: syn...@live.com; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] BGP Max-Prefix - Notification Data Decode Options ?
>
> On 10/03/2015 17:13, Darin Herteen wrote:
> > which the provider states should fall within their allowed
> > max-prefix range for our session [...]
>
> then, your provider is lying.
>
> Nick

Agreed, especially after reading RFC 4486. Assuming I'm understanding "Subcode 
Usage" correctly...

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ASR1000 IOS Version

[Mack McBride]

Personally we don't use the web interface at all.
Frankly, SSL v3.0 is about the same security as http.
Learning to use the command line via ssh is not that hard.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: Lukas Tribus [mailto:luky...@hotmail.com]
Sent: Wednesday, February 18, 2015 5:47 PM
To: Gert Doering; Mack McBride
Cc: cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] ASR1000 IOS Version

> On Wed, Feb 18, 2015 at 09:15:51PM +0000, Mack McBride wrote:
> This is probably the correct action.
> Disable the insecure protocol and force people to use command line
> until they upgrade.

Disabling all crypto protocols in the code without providing alternatives and 
forcing people to do use HTTP instead of HTTPS doesn't seem neither correct nor 
secure to me. Its not like TLS support is in that branch, thats the point.

What they should have done is not wait until 15.4 to implement TLS. Now still, 
in very recent code there is only TLSv1.0 support, no TLSv1.1, no 1.2, missing 
all the recent cipher suites.

So how long till we have to deprecate TLSv1.0 for an urgent security matter and 
we will have the very same issue all over again?

TLSv1.0 was defined in the late 90's and OpenSSL introduced support for it 
shortly afterwards. So it took them 15 years to implement TLSv1.0, thats not 
particularly impressive (from standard definition to a M or S release).

*TLSv1.0 is already in deprecation phase in 2014* [1], so how long will it 
last? Probably not until Cisco merges TLSv1.1/2 support (at it makes its way 
into a usable release).

Clearly, there is no BU responsible for the SSL code, a part from PSIRT.



> (I could care less about https, nobody uses that anyway on IOS,
> right?)

I do, I use it to push the configs from the box (at every "write mem") to a 
central HTTPS server that tracks those configs in a git repository.

I understand thats a pretty specific use case, but I had hoped that VPNSSL 
would be a strong enough driver to not let the SSL stack rot in the code for 
decades.



> force people to use command line until they upgrade.

This is not about the configuring the router through HTTPS instead of SSH. Its 
about VPNSSL, its about the HTTPS filesystem and the features relying on the 
internal SSL stack for operation that are now completely broken, in a 
maintenance IOS branch without any notes or warning in the release notes.

But no, this was clearly not intended. They just cherry-picked this CVE-fix and 
applied it to the old branches without thinking (and without testing, of 
course).


-lukas


[1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf


This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ASR1000 IOS Version

[Mack McBride]

This is probably the correct action.
Disable the insecure protocol and force people to use command line until they 
upgrade.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert 
Doering
Sent: Wednesday, February 18, 2015 9:25 AM
To: Lukas Tribus
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ASR1000 IOS Version

Hi,

On Wed, Feb 18, 2015 at 04:59:44PM +0100, Lukas Tribus wrote:
> FYI:
> 15.3(3)S5/15.3(3)M5 broke SSL/TLS completely (all platforms).
>
> They tried to fix the poodle vuln in CSCur23656 by disabling SSLv3,
> but it appears they forgot they don't support TLS in the 15.3 branch,
> so there is now (in the fifth rebuild) no SSL/TLS protocol left to use ...

I'm so amazed at Cisco QA at times...

(And I'm so happy that I do not use anything that needs Cisco SSL)

gert
--
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
This message contains information that may be confidential, privileged or 
otherwise protected by law from disclosure. It is intended for the exclusive 
use of the addressee(s). Unless you are the addressee or authorized agent of 
the addressee, you may not review, copy, distribute or disclose to anyone the 
message or any information contained within. If you have received this message 
in error, please contact the sender by electronic reply and immediately delete 
all copies of the message.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Understanding ASR1k / ESP40 capacity

[Mack McBride]

According to cisco's literature the 40G capacity is outbound direction only.
This includes traffic replication so you could have 1G in and 40G out or
50G in and 40G out but you should be able to get 40G out unless you are
using features that are causing core congestion on the QFP (which is possible).

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Simon 
Lockhart
Sent: Monday, October 06, 2014 9:25 AM
To: Pete Lumbis
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Understanding ASR1k / ESP40 capacity

Pete,

Thanks for this - I'll watch that preso and see if it adds anything useful.

You seem to be supporting my viewpoint, and I've also had an off-list reply 
supporting TAC's viewpoint - so I'm not sure I'm any further forwards.

I'm currently working on a plan to replace the ESP40 with an ESP100 - but as 
the ESP100 isn't supported in the ASR1004, I'll also have to do a chassis swap 
to an ASR1006. My only remaining concern with this plan is whether the SIP40 
can really do 40Gbps. If I stick 4 * 10G SPA's into a SIP40, can I run those 
10G ports at line-rate (assuming sufficient ESP capacity)?

Many thanks,

Simon



On Sat Oct 04, 2014 at 11:56:45AM -0400, Pete Lumbis wrote:
> It would be a single pass through the QFP. The SIP could also be a 
> limiting factor, but since you are split between SIPs that shouldn't be an 
> issue.
> The SIP 40 has 2x 40Gig lanes on the backplane. Are you doing crypto 
> or anything like that which would impact performance?
> 
> There is a great Cisco Live preso on the ASR1k architecture that might 
> help you get some ammo to go back to TAC with.
> http://d2zmdbbm9feqrf.cloudfront.net/2014/usa/pdf/BRKARC-2001.pdf
> 
> -Pete
> 
> On Sat, Oct 4, 2014 at 4:56 AM, Simon Lockhart  wrote:
> 
> > All,
> >
> > I'm banging my head against a brick wall trying to get sensible 
> > answers from Cisco TAC, so thought I'd ask the educated masses who 
> > may have come across this before...
> >
> > I've got a Cisco ASR1004 with RP2, ESP40, 2 * SIP40's, and 8 * 10GE ports.
> >
> > A snapshot of usage on these ports at peak is:
> >
> > Interface RxBps RxPps  TxBps TxPps
> > Te0/0/0   4,385,563,000   515,508906,118,000   339,997
> > Te0/1/0   3,942,338,000   419,696984,150,000   358,436
> > Te0/2/0   3,949,993,000   425,192933,257,000   349,145
> > Te0/3/0   4,375,526,000   512,858873,284,000   334,751
> > Te1/0/0   1,186,440,000   454,714  5,474,029,000   630,916
> > Te1/1/0 622,154,000   244,056  3,181,689,000   338,190
> > Te1/2/0 711,493,000   253,275  3,211,560,000   340,950
> > Te1/3/0   1,218,873,000   437,195  4,831,708,000   568,488
> >
> > TOTAL20,392,380,000 3,262,494 20,395,795,000 3,260,873
> >
> > I'm seeing throughput issues on a portchannel consisting of Te0/0/0 
> > and
> > Te0/3/0
> > (it won't go over 10Gbps aggregate)
> >
> > Cisco TAC are telling me if I add TxBps and RxBps totals together, I 
> > get 40Gbps, so I've reached capacity of the QFP (i.e. ESP40).
> >
> > My arguement against this is that a packet which enters the router 
> > on Te0/0/0, goes through the SIP40 in slot 0, through the ESP40, 
> > through the SIP40 in slot 1, and out through Te1/0/0 is still just 
> > one packet, so should only need to be counted once through the ESP, 
> > and once for each SIP. Hence, the throughput on the ESP is only 
> > 20.3Gbps on those numbers above.
> >
> > If I poll ceqfpUtilProcessingLoad by SNMP, I see peaks of around 
> > 65%, which would correlate with this level of throughput.
> >
> > I'm assuming there are others of you using this platform. What sort 
> > of throughput are you seeing? Am I right, or is the Cisco TAC engineer?
> >
> > TIA,
> >
> > Simon
> > ___
> > cisco-nsp mailing list  cisco-nsp@puck.nether.net 
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ASR1K upgrade

[Mack McBride]

Do you have a link for that.
This seems to totally contradict a number of other statements.
FLS-ASR1001-5G is specifically to upgrade a 2.5G to 5G.

https://supportforums.cisco.com/discussion/11348506/asr-1001-licence-activation
http://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/guide/chassis/asrswcfg/csa_rtu.html#pgfId-1057870
http://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/guide-c07-731639.html#_Toc386508999


Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeff 
Bacon
Sent: Friday, August 29, 2014 7:08 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ASR1K upgrade

The ASR1001 bundles have this little proviso that says "if you buy the 2.5G 
bundle, you cannot upgrade to the 5G  license". 

this seems silly on the face of it. 

Has anyone done this in practice? 


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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

[Mack McBride]

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.
Some carriers are using private addressing on their backbone devices which 
effectively
makes them invisible to traceroute and you get * * * for them.
The solution is really education and dedicated tools not opening up ddos 
potential.

I might add that some (who shall remain nameless) carriers prioritize icmp 
packets ahead of other traffic to hide congestion.
Ie. regular traffic gets QOS 0 and icmp gets QOS 4.  You can be losing 
substantial TCP packets
but your ICMP trace and ping will be totally clean.

Mack McBride | Network Architect | ViaWest, Inc.


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
Rimestad, Steinar
Sent: Thursday, August 07, 2014 8:14 AM
To: cisco-nsp@puck.nether.net
Subject: 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-limiting and increased this from the default 100/10 
to 1000/25 just to shut up the customer.

from
mls rate-limit all ttl-failure 100 10
to
mls rate-limit all ttl-failure 1000 25

Assuming you are on a Cisco platform and if you have a similar configuration 
setup you might be able to increase this without actually prioritizing this 
traffic to the control-plane.

Check if you are hitting any limits with:
show mls rate-limit usage
show ip icmp rate-limit




// Steinar




On 07/08/14 11:24, "Dumitru Ciobarcianu"  wrote:

>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 around the network, 
>>and tell them to point whatever they're using at that.
>> 
>
>The customer is pointing the tool to a remote server they have, we 
>cannot just tell them to test a node they do not care about. The 
>problem is not the tool or where they test, the problem is the way the 
>customer is interpreting the data.
>
>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...
>
>Dumitru
>
>___
>cisco-nsp mailing list  cisco-nsp@puck.nether.net 
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>



___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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

[Mack McBride]

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.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: Rod James Bio [mailto:rju...@gmail.com] 
Sent: Thursday, August 07, 2014 4:38 AM
To: Antonio Soares; Mack McBride; cisco-nsp@puck.nether.net
Subject: 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 wrote:
> 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-
> From: Rod James Bio [mailto:rju...@gmail.com]
> Sent: quinta-feira, 7 de Agosto de 2014 03:18
> To: Mack McBride; Antonio Soares; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Adjusting TCAM allocation weird behavior on 7600
>
> On my OP, I mentioned that I have two supervising engine on SSO mode 
> which
> is:
> 15  Route Switch Processor 720 10GE (Activ RSP720-3CXL-10GE
> 25  Route Switch Processor 720 10GE (Hot)  RSP720-3CXL-10GE
>
> Though, the second one was added much later. I was running 
> c7600rsp72043-adventerprisek9-mz.153-1.S1.bin before but now I updated 
> it to c7600rsp72043-adventerprisek9-mz.153-3.S3.bin.
>
> Running "sh mls cef max", I see:
> #sh mls cef maximum-routes
> FIB TCAM maximum routes :
> ===
> Current :-
> ---
>IPv4 + MPLS - 512k (default)
>IPv6 + IP Multicast - 256k (default)
>
> User configured :-
> ---
>IPv4- 768k
>MPLS- 24k
>IPv6 + IP Multicast - 112k (default)
>
> Upon reboot :-
> ---
>IPv4- 768k
>MPLS- 24k
>IPv6 + IP Multicast - 112k (default)
>
>
> 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 is the output of 
> show redundancy states:
>
> #sh redundancy states
>  my state = 13 -ACTIVE
>peer state = 8  -STANDBY HOT
>  Mode = Duplex
>  Unit = Primary
>   Unit ID = 1
>
> Redundancy Mode (Operational) = sso
> Redundancy Mode (Configured)  = sso
> Redundancy State  = sso
>Maintenance Mode = Disabled
>Communications = Up
>
>      client count = 169
>client_notification_TMR = 3 milliseconds
> keep_alive TMR = 9000 milliseconds
>   keep_alive count = 1
>   keep_alive threshold = 18
>  RF debug mask = 0x0
>
>
> Regards,
>
> On 8/6/14, 23:51, Mack McBride wrote:
>> This is a silly question but do you have dual sups?
>> That could be causing the issue.
>>
>> Also what code revision are you running?
>> Finally, what line cards are installed?
>> The message you are getting indicates the config is not working For 
>> whatever reason, one of the reasons could be line card incompatibility.
>>
>> A show module should list the line cards.
>>
>> Also once you configure the routes on the supervisor and save the 
>> config Execute the following command:
>>
>> remote command switch show mls cef max
>>
>> That will determine if the max routes command is getting properly 
>> Pushed to the switch processor.
>>
>> And a side note multicast and ipv6 both use two entries.
>> The other poster that said you were 28 short was incorrect.
>> Those settings should have worked.
>>
>> Mack McBride | Network Architect | ViaWest, Inc.
>> O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | 
>> LinkedIn | Twitter | YouTube
>>
>>
>>
>> -Original Message-
>> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf 
>> Of Rod James Bio
>> S

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

[Mack McBride]

One other thought, try the following settings:

Ipv6: 128
Multicast: 32
Ip and mpls as default

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rod 
James Bio
Sent: Tuesday, August 05, 2014 1:38 PM
To: Antonio Soares; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Adjusting TCAM allocation weird behavior on 7600

Hmm I somewhat tried that with these,

sh mls cef maximum-routes
FIB TCAM maximum routes :
===
Current :-
---
  IPv4 + MPLS - 512k (default)
  IPv6 + IP Multicast - 256k (default)

User configured :-
---
  IPv4- 768k
  MPLS- 16k
  IPv6 + IP Multicast - 120k (default)

Upon reboot :-
---
  IPv4- 768k
  MPLS- 16k
  IPv6 + IP Multicast - 120k (default)

but still no dice. IOS bug?

Regards,

On 8/6/14, 3:27, Antonio Soares wrote:
> Maybe IPv6 and IP Multicast must share the same region of the TCAM.
>
> Just try to remove all the "mls cef maximum-routes" commands then just 
> add this one:
>
> mls cef maximum-routes ip 768
>
>
>
>
> Regards,
>
> Antonio Soares, CCIE #18473 (RS/SP)
> amsoa...@netcabo.pt
> http://www.ccie18473.net
>
>
> -Original Message-
> From: Rod James Bio [mailto:rju...@gmail.com]
> Sent: terça-feira, 5 de Agosto de 2014 19:41
> To: Antonio Soares; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Adjusting TCAM allocation weird behavior on 7600
>
> This is what I tried,
>
> #sh mls cef maximum-routes
> FIB TCAM maximum routes :
> ===
> Current :-
> ---
>IPv4 + MPLS - 512k (default)
>IPv6 + IP Multicast - 256k (default)
>
> User configured :-
> ---
>IPv4 + MPLS - 768k (default)
>IPv6- 100k
>IP Multicast- 28k
>
> After a wr mem and reboot this is what I got:
> *Aug  6 02:15:46.975 PHT: %MLSCEF-SP-1-MAX_ROUTE_MISMATCH: Maximum 
> routes config mismatch. Reconfigure the maximum routes values and reload the 
> box.
>
> As you will see the max routes adds to 1024k but still It resets to 
> the default values.
>
> Regards,
>
> On 8/6/14, 1:28, Antonio Soares wrote:
>> As already mentioned, the sum should be 1024k, for example, I have 
>> this on a
>> SUP720-3BXL:
>>
>> 
>> sup720-3bxl#show mls cef maximum-routes FIB TCAM maximum routes :
>> ===
>> Current :-
>> ---
>>IPv4- 1007k
>>MPLS- 1k (default)
>>IPv6 + IP Multicast - 8k (default)
>> 
>>
>>
>> 1007+1+(2x8) = 1024
>>
>>
>> Regards,
>>
>> Antonio Soares, CCIE #18473 (RS/SP)
>> amsoa...@netcabo.pt
>> http://www.ccie18473.net
>>
>>
>> -Original Message-
>> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf 
>> Of
> Rod
>> James Bio
>> Sent: terça-feira, 5 de Agosto de 2014 16:13
>> To: cisco-nsp@puck.nether.net
>> Subject: Re: [c-nsp] Adjusting TCAM allocation weird behavior on 7600
>>
>> I read before the link you sent.
>>
>> BTW, Here is the output of "sh mls cef max":
>>
>> #sh mls cef maximum-routes
>> FIB TCAM maximum routes :
>> ===
>> Current :-
>> ---
>> IPv4 + MPLS - 512k (default)
>> IPv6 + IP Multicast - 256k (default)
>>
>> User configured :-
>> ---
>> IPv4- 600k
>> MPLS- 10k
>> IPv6- 100k
>> IP Multicast- 28k
>>
>> Upon reboot :-
>> IPv4- 600k
>> MPLS- 10k
>> IPv6- 100k
>> IP Multicast- 28k
>>
>> Regards,
>>
>> On 8/5/14, 22:15, Antonio Soares wrote:
>>> Check this document, maybe it can help you:
>>>
>>> http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-ser
>>> ie s-swit ches/117712-problemsolution-cat6500-00.html
>>>
>>> Can you share the "show mls cef max" output ?
>>>
>>>
>>>
>>> Regards,
>>>
>>> Antonio Soares, CCIE #18473 (RS/SP)
>>> amsoa...@netcabo.pt
>>> http://www.ccie18473.net
>>>
>>>
>>> 

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

[Mack McBride]

This is a silly question but do you have dual sups?
That could be causing the issue.

Also what code revision are you running?
Finally, what line cards are installed?
The message you are getting indicates the config is not working
For whatever reason, one of the reasons could be line card incompatibility.

A show module should list the line cards.

Also once you configure the routes on the supervisor and save the config
Execute the following command:

remote command switch show mls cef max

That will determine if the max routes command is getting properly
Pushed to the switch processor.

And a side note multicast and ipv6 both use two entries.
The other poster that said you were 28 short was incorrect.
Those settings should have worked.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rod 
James Bio
Sent: Tuesday, August 05, 2014 1:38 PM
To: Antonio Soares; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Adjusting TCAM allocation weird behavior on 7600

Hmm I somewhat tried that with these,

sh mls cef maximum-routes
FIB TCAM maximum routes :
===
Current :-
---
  IPv4 + MPLS - 512k (default)
  IPv6 + IP Multicast - 256k (default)

User configured :-
---
  IPv4- 768k
  MPLS- 16k
  IPv6 + IP Multicast - 120k (default)

Upon reboot :-
---
  IPv4- 768k
  MPLS- 16k
  IPv6 + IP Multicast - 120k (default)

but still no dice. IOS bug?

Regards,

On 8/6/14, 3:27, Antonio Soares wrote:
> Maybe IPv6 and IP Multicast must share the same region of the TCAM.
>
> Just try to remove all the "mls cef maximum-routes" commands then just 
> add this one:
>
> mls cef maximum-routes ip 768
>
>
>
>
> Regards,
>
> Antonio Soares, CCIE #18473 (RS/SP)
> amsoa...@netcabo.pt
> http://www.ccie18473.net
>
>
> -Original Message-
> From: Rod James Bio [mailto:rju...@gmail.com]
> Sent: terça-feira, 5 de Agosto de 2014 19:41
> To: Antonio Soares; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Adjusting TCAM allocation weird behavior on 7600
>
> This is what I tried,
>
> #sh mls cef maximum-routes
> FIB TCAM maximum routes :
> ===
> Current :-
> ---
>IPv4 + MPLS - 512k (default)
>IPv6 + IP Multicast - 256k (default)
>
> User configured :-
> ---
>IPv4 + MPLS - 768k (default)
>IPv6- 100k
>IP Multicast- 28k
>
> After a wr mem and reboot this is what I got:
> *Aug  6 02:15:46.975 PHT: %MLSCEF-SP-1-MAX_ROUTE_MISMATCH: Maximum 
> routes config mismatch. Reconfigure the maximum routes values and reload the 
> box.
>
> As you will see the max routes adds to 1024k but still It resets to 
> the default values.
>
> Regards,
>
> On 8/6/14, 1:28, Antonio Soares wrote:
>> As already mentioned, the sum should be 1024k, for example, I have 
>> this on a
>> SUP720-3BXL:
>>
>> 
>> sup720-3bxl#show mls cef maximum-routes FIB TCAM maximum routes :
>> ===
>> Current :-
>> ---
>>IPv4- 1007k
>>MPLS- 1k (default)
>>IPv6 + IP Multicast - 8k (default)
>> 
>>
>>
>> 1007+1+(2x8) = 1024
>>
>>
>> Regards,
>>
>> Antonio Soares, CCIE #18473 (RS/SP)
>> amsoa...@netcabo.pt
>> http://www.ccie18473.net
>>
>>
>> -Original Message-
>> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf 
>> Of
> Rod
>> James Bio
>> Sent: terça-feira, 5 de Agosto de 2014 16:13
>> To: cisco-nsp@puck.nether.net
>> Subject: Re: [c-nsp] Adjusting TCAM allocation weird behavior on 7600
>>
>> I read before the link you sent.
>>
>> BTW, Here is the output of "sh mls cef max":
>>
>> #sh mls cef maximum-routes
>> FIB TCAM maximum routes :
>> ===
>> Current :-
>> ---
>> IPv4 + MPLS - 512k (default)
>> IPv6 + IP Multicast - 256k (default)
>>
>> User configured :-
>> ---
>> IPv4- 600k
>> MPLS- 10k
>> IPv6- 100k
>> IP Multicast- 28k
>>
>> Upon reboot :-
>> IPv4- 600k
>> MPLS- 10k
>> IPv6- 100k
>> IP 

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

[Mack McBride]

Your maximum must add up correctly.
The current settings do not equal 1024.
Multicast and IPv6 count for two each.

The easiest way to ensure this is working properly is to not set ip and mpls.

Our configuration is:

mls cef maximum-routes ipv6 192
mls cef maximum-routes ip-multicast 1

For what you want, you would do:

mls cef maximum-routes ipv6 100
mls cef maximum-routes ip-multicast 28
no mls cef maximum-routes ip 750
no mls cef maximum-routes mpls 10

The MPLS and ip will be shared and equal.

Mack McBride | Network Architect | ViaWest, Inc.

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rod 
James Bio
Sent: Tuesday, August 05, 2014 5:03 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Adjusting TCAM allocation weird behavior on 7600

Hi, I'd like to ask anyone in the group who owns cisco 7600 if they had 
experience when they adjusted the allocation to increase the maximum routes for 
ipv4 etc. We are near the 512K ipv4 limit (~509K) for the
7600 (default size) and I tried adjusting the tcam allocation by running:

mls cef maximum-routes ip 750
mls cef maximum-routes ipv6 100
mls cef maximum-routes mpls 10
mls cef maximum-routes ip-multicast 28

But after rebooting the whole box I got an error, "Maximum routes config 
mismatch. reconfigure the maximum routes values and reload the box" (Sorry this 
is all I copied from the console) and the tcam was back to the default values.

I have a dual RSP720-3CXL-10GE sups on sso mode and 
c7600rsp72043-adventerprisek9-mz.153-1.S1.bin if those info help.

Thanks,
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 512K routes approaching - have you adjusted your tcam settings

[Mack McBride]

I forgot about that.
The tcam settings on the Sup2T are dynamic.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube


-Original Message-
From: "Rolf Hanßen" [mailto:n...@rhanssen.de] 
Sent: Saturday, July 26, 2014 6:16 AM
To: Mack McBride
Cc: cisco-nsp
Subject: Re: [c-nsp] 512K routes approaching - have you adjusted your tcam 
settings

Hi Mack,

I am wondering about "including sup 2T"?
As far as I see Sup2T has no static CAM partition anymore and therefore needs 
no specific maximums set.

kind regards
Rolf

> As many readers on this list know the routing table is approaching 
> 512K routes.
> For some it has already passed this threshold.
> For those that aren't familiar with the issues associated with passing 
> this threshold, I suggest the following two documents:
>
> http://www.ipv4depletion.com/?p=672
>
> http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-serie
> s-switches/117712-problemsolution-cat6500-00.html
>
> Effected devices include 6500s (including sup 2T), 7600s, nexus 7Ks 
> and many devices by other vendors.
> This problem will likely impact us in some way over the next month 
> even if we fixed our devices because We connect to other services that 
> have not prepared.
>
> So be on the lookout for MLSCEF-SP-7-FIB_EXCEPTION messages in your logs.
>
> Mack McBride | Network Architect | ViaWest, Inc.
>
>
>
>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] 512K routes approaching - have you adjusted your tcam settings

[Mack McBride]

As many readers on this list know the routing table is approaching 512K routes.
For some it has already passed this threshold.
For those that aren't familiar with the issues associated with passing this 
threshold,
I suggest the following two documents:

http://www.ipv4depletion.com/?p=672

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html

Effected devices include 6500s (including sup 2T), 7600s, nexus 7Ks and many 
devices by other vendors.
This problem will likely impact us in some way over the next month even if we 
fixed our devices because
We connect to other services that have not prepared.

So be on the lookout for MLSCEF-SP-7-FIB_EXCEPTION messages in your logs.

Mack McBride | Network Architect | ViaWest, Inc.




___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco 7600 pseudowire ping

[Mack McBride]

Given the patterned packet loss, I would suspect some kind of rate limiting.
Where it is happening I cannot say.  It could be built in to the pseudowire 
code.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ivan
Sent: Tuesday, July 22, 2014 4:16 AM
To: cisco-nsp
Subject: Re: [c-nsp] Cisco 7600 pseudowire ping

Interesting enough regular mpls ping has no issue:

PE1#ping mpls ipv4 172.16.14.1/32 repeat 100 Sending 100, 100-byte MPLS Echos 
to 172.16.14.1/32,
  timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
   'L' - labeled output interface, 'B' - unlabeled output interface,
   'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
   'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
   'P' - no rx intf label prot, 'p' - premature termination of LSP,
   'R' - transit router, 'I' - unknown upstream index,
   'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.
!!
!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/4 ms

PE1#ping mpls pseudowire 172.16.14.1 440 repeat 100 Sending 100, 100-byte MPLS 
Echos to 172.16.14.1,
  timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
   'L' - labeled output interface, 'B' - unlabeled output interface,
   'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
   'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
   'P' - no rx intf label prot, 'p' - premature termination of LSP,
   'R' - transit router, 'I' - unknown upstream index,
   'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.
!!.!.!!.!!.!!!
!!!.!.
Success rate is 94 percent (94/100), round-trip min/avg/max = 1/2/4 ms PE1#

And the rate-limit output on the destination:

PE2#show mls rate-limit | in Rate|On|UCAST
Rate Limiter Type   Status Packets/s   Burst  Sharing
 MCAST DFLT ADJ   On  10 100  Not sharing
   ACL VACL LOG   On2000   1  Not sharing
   MCAST PARTIAL SC   On  10 100  Not sharing
 IP RPF FAILURE   On 100  10  Group:0 S
TTL FAILURE   On  97  10  Not sharing
  ICMP UNREAC. NO-ROUTE   On 100  10  Group:0 S
  ICMP UNREAC. ACL-DROP   On 100  10  Group:0 S
MTU FAILURE   On 997  10  Not sharing
UCAST IP OPTION   Off  -   - -
  IP ERRORS   On 100  10  Group:0 S

As mentioned before we are only seeing this on devices where we are running 
15.2(4)S4a

Thanks

Ivan

On 21/Jul/2014 7:56 p.m., Vitkovský Adam wrote:
> And how about the regular mpls ping does that perform right?
>
> I'd check the rate limiters:
>
> show mls rate-limit
> and look for UCAST IP OPTION -is it ON or OFF though it should be off 
> by default
>
> adam
>
>> -Original Message-
>> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf 
>> Of Ivan
>> Sent: Sunday, July 20, 2014 12:58 AM
>> To: Peter Persson
>> Cc: cisco-nsp
>> Subject: Re: [c-nsp] Cisco 7600 pseudowire ping
>>
>> No CoPP. Direct ping is fine.  Just the PW ping having issues.
>>
>> On 20/Jul/2014 2:13 a.m., Peter Persson wrote:
>>> Do you have any Control-plane policing?
>>> As i understand your email, you are pinging between two 7600's 
>>> directly and not anything behind it?
>>>
>>>
>>>
>>>
>>> 2014-07-19 13:47 GMT+02:00 Ivan >> <mailto:cisco-...@itpro.co.nz>>:
>>>
>>>  I have found that mpls pseudowire pings to some 7600s running
>>>  15.2(4)S4a go missing - I see about 95/100 success rate.  On other
>>>  devices with older software I have no loss.  The problem is not seen
>>>  if the ping interval is increased to 100ms.  Also pinging over the
>>>  VC shows no loss.
>>>
>>>  Given the above I suspect some rate-limiting may be ta

Re: [c-nsp] Sup720 (6k/7600) FIB_EXCEPTION_THRESHOLD warnings

[Mack McBride]

Recommended settings have been discussed on Nanog and IPv6 meetings for the 
last couple of years.
We are currently using 640 for IPv4 and 192 for IPv6.

Mack McBride
Network Architect

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Pete 
Templin
Sent: Monday, June 09, 2014 1:17 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Sup720 (6k/7600) FIB_EXCEPTION_THRESHOLD warnings


On 6/9/2014 11:37 AM, Pete Lumbis wrote:
> If you have a Sup720 pulling a full BGP feed you've probably seen 
> error messages like this:
>
> *%MLSCEF-SP-4-FIB_EXCEPTION_THRESHOLD: Hardware CEF entry usage is at 
> 95% capacity for IPv4 unicast protocol*
>
> A document was just published on Cisco.com describing the issue and 
> how to correct it.
>
> http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-serie
> s-switches/117712-problemsolution-cat6500-00.html
>
Do 'remote command switch show bootvar' and ensure that the SP config register 
is what you expect.  If not, reset the config register and copy run start, then 
recheck.  Otherwise, you'll set yourself up for auto-reboots every five minutes 
of uptime.

pt

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP funny in SXI

[Mack McBride]

That sounds like the bug I mentioned.
Eliminating the shutdown peer fixes the issue in the bug I mentioned.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: Gert Doering [mailto:g...@greenie.muc.de] 
Sent: Friday, May 30, 2014 1:32 PM
To: Mack McBride
Cc: Tim Kleefass; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] BGP funny in SXI

Hi,

On Fri, May 30, 2014 at 06:08:08PM +, Mack McBride wrote:
> There are a couple of bugs.
> Not sure of the bug ID but there is one that only happens if you have a shut 
> down peer.
> It causes a memory leak.

Yeah, this one I know.  Very funny.  (But supposedly fixed quite a while ago in 
all still-maintained SX* trains).

The other one was news to me - and indeed, first thing I did was check whether 
there are any "down" peers, and I had one that was shutdown.

Since my original mail, the prefixes in "pending" went down to only 2, so it 
might have helped.  Or it just took a while to find a "quiet" time with no 
updates between two scanner runs, or whatever...

gert
--
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP funny in SXI

[Mack McBride]

There are a couple of bugs.
Not sure of the bug ID but there is one that only happens if you have a shut 
down peer.
It causes a memory leak.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tim 
Kleefass
Sent: Friday, May 30, 2014 11:47 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] BGP funny in SXI

Hi Gert,

On 26.05.2014 10:06 AM, Gert Doering wrote:
> There is a bit of BGP churn on this router, but all BGP peers are "up"
> (so no "updates to some members of an update-group are stuck") and all 
> BGP table versions in "show ip b su" are much higher than 681600139 - 
> OTOH, one or the other peer is always slow enough so that not all of 
> the peers seem to reach the exact same table version...
> 
> This particular prefix would have never been announced to the "slow" 
> eBGP peers anyway, as it was learned from upstream - and the iBGP 
> update group actually *is* in sync.
> 
> The box in question is at SXI8a, so maybe it's a bug in there and I 
> really should be updating now...

Someone with SXI3 has the same issue:

  http://web.archiveorange.com/archive/v/yqqaaUV2wXXdBdVt3Qo7

referring to CSCsr62529.


BTW: On our ASR 9000, RSP-4G boxes the IPv4 Internet never converges...

show bgp ipv4 uni convergence
Fri May 30 19:44:08.785 CEST
Not converged.
Received routes may not be entered in RIB.
One or more neighbors may need updating.

Cheers,
Tim
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Stuck route issues on 7600 and ASR1000

[Mack McBride]

Cisco found the bug.  It is bug id: CSCuh43027.
It effects 15.2 and some 15.3 code as well as the corresponding ASR code 
releases.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mack 
McBride
Sent: Wednesday, May 14, 2014 5:48 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Stuck route issues on 7600 and ASR1000

Has anyone else seen stuck route issues on the 7600 and ASR 1000 platforms 
Running 15.3(1)S2 and 03.07.03.S(15.2(4)S3) respectively.
It appears both platforms are affected in the same way.
The route appears in a show ip route command as learned from BGP but the route 
does not appear in the BGP table.
The only solutions are clear ip route   or the more Intrusive 
clear ip route *.  clear ip bgp * does not work since the route has vanished 
from the global routing table.
I am trying to get a feel for how wide spread this issue is.
So far Cisco TAC has not been able to positively identify a bug that matches 
this.  BGP withdrawals are getting received since the route is removed from the 
bgp rib but not getting forwarded to the device rib from the protocol rib.  
Routes adds and changes seem to be unaffected.  Any feedback on this problem 
would be helpful.

Mack McBride
Sr. Network Architect

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Stuck route issues on 7600 and ASR1000

[Mack McBride]

Has anyone else seen stuck route issues on the 7600 and ASR 1000 platforms
Running 15.3(1)S2 and 03.07.03.S(15.2(4)S3) respectively.
It appears both platforms are affected in the same way.
The route appears in a show ip route command as learned from BGP
but the route does not appear in the BGP table.
The only solutions are clear ip route   or the more
Intrusive clear ip route *.  clear ip bgp * does not work since the route
has vanished from the global routing table.
I am trying to get a feel for how wide spread this issue is.
So far Cisco TAC has not been able to positively identify a bug
that matches this.  BGP withdrawals are getting received since
the route is removed from the bgp rib but not getting forwarded
to the device rib from the protocol rib.  Routes adds and changes
seem to be unaffected.  Any feedback on this problem would be helpful.

Mack McBride
Sr. Network Architect

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ACL TCAM LOU exhaustion on 7600 running 15.1 code

[Mack McBride]

When LOUs are exhausted some ACLs with LOUs will get processed as if the port 
specific portion did not exist.
This can cause all kinds of weirdness.  Often it requires a router reboot to 
fully correct TCAM and LOU overflows.
The solution is to pick a minimum set of port ranges that works for your 
configuration and don't use other port
ranges.  As Saku Ytti stated it is more than the range command.
Specifically lt, gt, neq, range, established

One other note is that the acl compiler will attempt to expand acls for range 
commands provided there aren't
too many ports in the range.  This can cause TCAM exhaustion rather than LOU 
exhaustion.

The following document applies to all sup720 and rsp720 variants:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp43500

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of John 
Neiberger
Sent: Monday, May 05, 2014 10:50 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ACL TCAM LOU exhaustion on 7600 running 15.1 code

We had an interesting issue arise on Friday and I'm still wrestling with it. 
The short story is that we have a 7600 with a lot of ACLs on it, some of which 
are very long and most ACEs are port specific. This uses up a lot of ACL TCAM 
LOUs, or logical objects. I didn't discover that until later, though.

An ACL was updated on this 7600. Four lines were added. That ACL is applied to 
a single interface. It appears that after those lines were added, traffic that 
is NOT traversing that interface was affected. The symptoms were intermittent 
connectivity in some cases. When we removed the ACL, the traffic in question 
apparently began functioning. When we added the ACL back to the interface, the 
traffic began to break again. Remember, this ACL is NOT in the transit path for 
the traffic in question.

My first thought was TCAM. I checked "show platform hardware capacity acl"
and saw that LOUdst was at 100% with the ACL applied, but it was at 81% with 
the ACL removed.

I've heard that if TCAM is overloaded, some ACLs will be processed by the CPU, 
which clearly could cause problems. However, I did not see any rise in CPU 
usage during this period.

Also, if we just remove the four new lines that were added, the LOUdst value is 
still at 100%. I remain unconvinced that this was actually the root cause for 
the issue.

Do any of you have any experience with this? What would be the expected outcome 
of running out of LOU space in the ACL TCAM?

Thanks,
John
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BFD bypassing CoPP on 6500

[Mack McBride]

You didn't mention which line card models you were using and if dfcs are 
installed.
One disadvantage of CoPP on the sup720 family is that it is dependent on the 
incoming
line cards to rate limit in hardware.  Once it hits the RP it is handled in 
software.
So if the traffic is coming in multiple ports, each port will rate limit to the 
specified
value independently.  If you have x ports and your rate limit is y, you are 
actually open
to x*y traffic.  I haven't had a chance to play with the sup2T family but my 
understanding
is this was fixed in the sup2T.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube


-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Robert 
Williams
Sent: Sunday, May 04, 2014 10:20 AM
To: 'cisco-nsp@puck.nether.net'
Subject: [c-nsp] BFD bypassing CoPP on 6500

Hi,

I can’t seem to find any relevant documentation on this so I’m hoping someone 
may know. I’ve identified that BFD traffic appears to bypass the CoPP in some 
respects (platform is 6500/Sup720/15.1SY).

The relevant test config is:

class-map match-any CoPP-bfd
  match access-group name V4-CoPP-bfd

ip access-list extended V4-CoPP-bfd
permit udp 10.10.0.0 0.0.255.255 gt 49151 any eq 3784 permit udp 10.10.0.0 
0.0.255.255 gt 49151 any eq 3785


  class CoPP-bfd
   police 32000 10 10   conform-action transmit   exceed-action drop

So for example, if you send 50mbit/s of BFD traffic to it, then the output of 
“show policy-map control-plane input class CoPP-bfd” correctly shows that there 
is 50mbit/s of traffic being matched (in hardware) and that only 32,000bps of 
it is being forwarded. All looks fine, however, the CPU grinds to a halt, even 
though the exceed-action is set to ‘drop’ so nothing more than a tiny 32,000 
should get through. I’ve confirmed it is indeed all getting through as you can 
see it in a CPU span session.

Also, the class-default in the control-plane policy is set to conform-action 
drop as well. So how is it even getting through?

Interestingly, if you set the conform-action to drop on class CoPP-bfd then it 
still hits 100% CPU. Although strangely if you _do_ set CoPP-bfd to 
conform-drop then also the genuine BFD ‘real’ sessions suddenly stop working. 
So the ‘drop’ feature does have some impact still, somehow…

This is in a lab setup with little else running on the boxes and I’m able to 
test anything if anyone has any ideas why this is occurring.

#remote command switch show tcam interface vlan 1013 qos type2 ip

* Global Defaults shared

--
QOS Results:
A - Aggregate Policing   F - Microflow Policing
M - Mark T - Trust
U - Untrust
--
MAUudp 10.10.0.0 0.0.255.255 gt 49151 any eq 3784
MAUudp 10.10.0.0 0.0.255.255 gt 49151 any eq 3785


#remote command switch show tcam interface vlan 1013 qos type2 ip detail

Interface: 1013   label: 3   lookup_type: 2
protocol: IP   packet-type: 0

+-+-+---+---+---+---+---+---++-+---+--+---+---+
|T|Index|  Dest Ip Addr | Source Ip Addr| DPort | SPort | TCP-F 
|Pro|MRFM|X|TOS|TN|COD|F-P|
+-+-+---+---+---+---+---+---++-+---+--+---+---+
V 35925 0.0.0.0   10.10.0.0   P=3784  P>49151-- 
 17  1   0 -- --- 0-0  <-
M 35927 0.0.0.0 255.255.0.0 65535-- 
255 --X- 1   0 <-
R rslt: 503   <-

V 35926 0.0.0.0   10.10.0.0   P=3785  P>49151-- 
 17  1   0 -- --- 0-0  <-
M 35927 0.0.0.0 255.255.0.0 65535-- 
255 --X- 1   0 <-
R rslt: 503   <-


Since it’s just UDP on a certain port I don’t see how/why this would be treated 
any differently from any other type of traffic going to the CPU. I know there 
are various restrictions and limitations (like ARP, IP Options etc.) but this 
is nothing ‘special’ – just UDP traffic - or at least I thought so?

So what am I missing here? Cheers!

Robert Williams
Custodian Data Centre
Email: rob...@custodiandc.com
http://www.CustodianDC.com
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] rate limit dns

[Mack McBride]

Even our consumer customers tend to be businesses with an alternate connection 
in their office.
We specialize in B2B.  But we do have a number of home DSL customers.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
Dobbins, Roland
Sent: Tuesday, December 31, 2013 3:30 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] rate limit dns


On Jan 1, 2014, at 5:26 AM, Mack McBride  wrote:

> Why would a company that requires maximum uptime want to depend on our DNS 
> servers when they have bandwidth from a number of other companies?

The recommendation in question is intended for consumer broadband access 
operators only, not for transit operators.

---
Roland Dobbins  // <http://www.arbornetworks.com>

  Luck is the residue of opportunity and design.

   -- John Milton


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] rate limit dns

[Mack McBride]

'Other mechanisms' is a beautiful catch phrase for hire a DDoS mitigation 
vendor.

Many reflection attacks do use authoritative servers because of the amount of 
throughput
those servers have.  Most are quite capable of a full gig of traffic.  I know 
ours certainly are.
SPF records (ie. TXT) are a favorite target since they can be fairly large.
And with signed records it is even worse.

And I agree that open resolvers are a major issue.
However, I think limiting my customer's choices of resolvers is bad as well.

I am aware of your credentials, however, I disagree with blocking DNS choice to 
customers.
For example many of our BGP customers are also customers of other companies.
Why would a company that requires maximum uptime want to depend on our DNS 
servers
when they have bandwidth from a number of other companies?

I would say this is getting way off topic and we will have to agree to disagree 
on this point.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
Dobbins, Roland
Sent: Tuesday, December 31, 2013 2:34 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] rate limit dns


On Jan 1, 2014, at 4:13 AM, Mack McBride  wrote:

> Recursive servers have to be able to receive responses from anywhere on the 
> internet.

Hence 'external resolvers', mentioned in my post.

<https://app.box.com/s/72bccbac1636714eb611>

> Nor can RTBH stop a true DDoS.

S/RTBH can, up to the point that the number of sources becomes unmanageable.  
Hence, 'other mechanisms', mentioned in my post.

>  That is the 'distributed' part that is the first D. Nor will it stop a 
> reflection attack, which is even more damaging because then you are blocking 
> important authoritative DNS servers.

Again, hence 'other mechanisms', mentioned in my post.

Also, if you're on the designated-target leg of a DNS reflection/amplification 
attack, in most (not all; directly-spoofed ANY attacks and the like, which 
don't involve open recursors, are the exception) cases, you're receiving 
traffic from open recursors, not authoritative severs, and the sources you end 
up blocking are open recursors, not authoritative servers.

If your external resolvers are open recursors and are being abused, then you 
need to remediate them.

> As an ISP operator, I can tell you that your solution will only work for 
> someone whose customers can't leave for another provider.

As someone who's worked with many ISPs to successfully mitigated many extremely 
large-scale and complex DNS-related DDoS attacks, including 100gb/sec+ 
reflection/amplification attacks, I can assure you that I do in fact understand 
the issues involved and how to deal with them.

---
Roland Dobbins  // <http://www.arbornetworks.com>

  Luck is the residue of opportunity and design.

   -- John Milton


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] rate limit dns

[Mack McBride]

Recursive servers have to be able to receive responses from anywhere on the 
internet.
There is no way to configure that so it can't be flooded off of the internet.

Nor can RTBH stop a true DDoS.  That is the 'distributed' part that is the 
first D.
Nor will it stop a reflection attack, which is even more damaging because then 
you are
blocking important authoritative DNS servers.

Using teirs of recursive resolvers doesn't help.  Using distributed resolvers 
might depending on the
nature of the attack.

As an ISP operator, I can tell you that your solution will only work for 
someone whose customers
can't leave for another provider.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
Dobbins, Roland
Sent: Monday, December 30, 2013 7:13 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] rate limit dns


On Dec 31, 2013, at 1:27 AM, Mack McBride  wrote:

> Phishing has little to do with DNS per se.

Some does, actually.

> BUT, forcing customers to use your DNS results in the possibility of all of 
> your customers suffering in a DDoS situation where your DNS servers are 
> targeted.

If your first-line recursive DNS servers are configured correctly, then they 
can't be DDoSed directly from outside your network, and it's easy enough to 
squelch attacks originating from within your network via S/RTBH or other 
mitigation mechanisms.  There are mitigation mechanisms to protect the upper 
tier of external resolvers which feed the first-tier resolvers, as well.

What part of allowing Google DNS and OpenDNS by default wasn't clear?

Also, note that policies can be altered, if circumstances warrant.  But any 
network operator which doesn't have the capability defend its own recursive DNS 
servers from DDoS attacks should take steps to implement S/RTBH, et. al.

---
Roland Dobbins  // <http://www.arbornetworks.com>

  Luck is the residue of opportunity and design.

   -- John Milton


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] rate limit dns

[Mack McBride]

Now you are using the straw man argument.
Phishing has little to do with DNS per se.
If a known address is doing phishing a provider can certainly falsify that DNS 
to protect their customers.
BUT, forcing customers to use your DNS results in the possibility of all of 
your customers suffering in a DDoS
situation where your DNS servers are targeted.

DDoS attacks on DNS servers are particularly devastating for both resolvers and 
authoritative.
You can't simply block the traffic to those boxes as that takes sites off line,
effectively completing the attack. Simply rate limiting can achieve the same 
result.

As an ISP, how many of my customers are going to stick around if their service 
is down for 3 days or even a week?
I mean for Comcast that might work because many customers don't have any other 
choice.
I currently live in an area where I can only get Comcast, no DSL available.
DSL is another arena as you still have a choice of providers available as the 
phone companies are still required
to provide other providers access to their customers.

I would advise against limiting DNS choices.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
Dobbins, Roland
Sent: Sunday, December 29, 2013 5:32 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] rate limit dns


On Dec 29, 2013, at 7:21 PM, Gert Doering  wrote:

> And that is where we differ.  You find it OK to limit the protocol du 
> jour to "what users do not need", I do not agree to it.  Even if I agree with 
> you that "most users would not notice".

I'm not proposing blocking DNS.  I'm proposing a default policy for consumer 
broadband users which assumes that they'll use the DNS recursors provided by 
the broadband network operator, unless the use chooses to opt-out.

> in reasonable countries, ISPs are protected from charges for traffic 
> they transport *unless* they start messing with it - if you start filtering 
> traffic for "protocol X", but leave through the evil packets for "protocol 
> Z", you're *way* more likely to be made liable for it.

Again, this isn't the same thing.  Nobody's talking about blocking the DNS.

Here's the risk that I see for network operators, moving forward, if they don't 
implement sensible, low-impact default (with the ability to opt-out, which 
would include indemnification) policies of this nature to protect their user 
bases:

1.  Consumer user X ends up getting phished/compromised, attacker empties 
his bank account, maxes his credit cards, applies for new credit cards in the 
user's name but delivered to another mailing address under the control of the 
attacker or his minions, etc.

2.  User X ends up suing the bank(s) and credit card issuer(s) in question, 
alleging that those entities didn't take reasonable security precautions, and 
are now liable for all the actual and punitive damages claimed by user X as he 
struggles to get his money back, clear his credit history, etc.

3.  Liability insurance companies for the bank(s) and credit card issuer(s) 
in question turn around and sue the network operator for damages based upon 
negligence, alleging that reasonable and practical security policies which 
could've potentially prevented this fraud from being possible weren't 
implemented.  They might sue software vendors - OS vendors, foundations 
providing open-source Web browsers, and so forth, as well.

4.  Politicians/regulators get wind of this, and pile on.

A little bit of prudence now could obviate a whole lot of financial hurt and 
heavy-handed legislation/regulation, later.

---
Roland Dobbins  // <http://www.arbornetworks.com>

  Luck is the residue of opportunity and design.

   -- John Milton


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] IPv6 in the lab......

[Mack McBride]

You should try a link local ping across.
If that works then something is blocking the ICMP.
You need to make sure your ACLs are not blocking link local,
ND, ICMP echo, multicast, path MTU discovery or any of the
other critical ICMP messages.

You also need to make sure both end points have IPv6 fully enabled.

Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn | 
Twitter | YouTube



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Scott 
Voll
Sent: Wednesday, November 27, 2013 11:07 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] IPv6 in the lab..

So I may be dense or something, but if I have two devices on a Vlan with
IPv6 addresses in the same network, why would I not be able to ping them?

Is there something I have to do on layer 2 switches in order to allow the
icmpv6 to flow?

Switches are 3560's and nexus 5500/2k's

TIA

Scott
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best practice, MPLS and MTU settings

[Mack McBride]

I concur with 9100.
Which providers have you run into problems with 9100?
I know certain cisco gear doesn't support packets that big for certain links.
The 3750/3560 series for example only support 9000 on gigabit interfaces and 
much smaller on 10/100 ports.

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick 
Hilliard
Sent: Thursday, October 24, 2013 8:40 PM
To: Eric A Louie; Cisco NSP
Subject: Re: [c-nsp] Best practice, MPLS and MTU settings

On 25/10/2013 09:32, Eric A Louie wrote:
> If you used the method of increasing the MTU, what value did you use?

I aim towards a 9100 byte ip mtu, in order to guarantee a 9000 byte MTU for 
customers with plenty of overhead on our side.  Sometimes this isn't possible 
due to third party provider core link restrictions.

Nick

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] IPv6 bug back for the 7600

[Mack McBride]

Previously there was a bug that effected the 6500s.
In this bug if you had a route that covered 0::/96, it would cause the 
TestFibDevices fail.
This bug is back in the 15.2 code for the 7600.
Specifically: 15.2(4)S3a
I am guessing this is a result of the re-merge of the 7600/6500 code trains.

Mack McBride
Network Architect





___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] RESOLVED: Weird IPv6 problem passing Layer3 traffic

[Mack McBride]

People running CoPP usually think of CoPP.
People that have run GSRs will also think of receive access lists.
Most right thinking ISPs should have rules that rate limit rather than drop the 
connection.
CoPP is not a receive access list and should not be treated like one.

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of John 
Neiberger
Sent: Friday, June 28, 2013 10:15 AM
To: Matthew Huff
Cc: ipv6-...@lists.cluenet.de; cisco-nsp (cisco-nsp@puck.nether.net)
Subject: Re: [c-nsp] RESOLVED: Weird IPv6 problem passing Layer3 traffic

Sweet! I've had CoPP filters bite me many times. Everything else will look 
right but the dang thing just won't work. It can be pretty frustrating to 
troubleshoot since CoPP usually isn't the first thing people think of.

John


On Fri, Jun 28, 2013 at 9:20 AM, Matthew Huff  wrote:

> The issue was a CoPP filter on the ISP side. The session is up now.
>
> Been working on them with them for 3 days, and each engineer kept 
> coming back to our BGP configuration.
>
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039
>
>
> > -Original Message-
> > From: Matthew Huff
> > Sent: Friday, June 28, 2013 10:34 AM
> > To: 'cisco-nsp (cisco-nsp@puck.nether.net)'; 'ipv6-...@lists.cluenet.de'
> > Subject: Weird IPv6 problem passing Layer3 traffic
> >
> > Trying to bring up a new BGP peering session with a ISP. IPv4 
> > peering is
> working fine on the same
> > interface. The BGP peering fails early in trying to go active. Using
> "debug tcp transactions", I see
> > the SYN going out, but no ACK ever returning. I can't telnet to 
> > their
> box on port 179 either (debug
> > packet shows it doing the same, SYN begin sent, but no packets,
> including ACK). However, I can ping
> > their interface.
> >
> > The interface config has been stripped, and still doesn't work. I've
> reset the interface, and even
> > rebooted our router, with no change in behavior.
> >
> > We have a Cisco 7204VXR with NPE-G2, running 15.2(4)S1. I have an
> identical router with same version
> > connected to another ISP and a tunnel to HE.net. It's not my first 
> > time
> at the rodeo. We are connected
> > via metro Ethernet to a sub-interface on a JunOS box (model and 
> > version
> unknown). My suspicion is that
> > either they have an ACL that's blocking it, or their BGP process 
> > isn't
> listening on that sub-
> > interface. But they claim that it isn't their problem. I have zero 
> > JunOS
> experience and they seem to
> > be flopping around.
> >
> > Anyone have any idea what else the problem might be?
> >
> > From our side (simplied config to test):
> >
> >
> > interface FastEthernet2/1
> >  ip address 162.211.110.2 255.255.255.252  speed auto  duplex auto
> >  ipv6 address 2607:F518:15F::2/126
> >  ipv6 enable
> > end
> >
> > rtr-inet2#show ipv6 cef 2607:F518:15F::1
> > 2607:F518:15F::1/128
> >   attached to FastEthernet2/1
> >
> > rtr-inet2#show ipv6 cef exact-route 2607:F518:15F::2 
> > 2607:F518:15F::1
> > 2607:F518:15F::2 -> 2607:F518:15F::1 => IPV6 adj out of 
> > FastEthernet2/1,
> addr 2607:F518:15F::1
> >
> > rtr-inet2#show ipv6 neighbors
> > IPv6 Address  Age Link-layer Addr State
> Interface
> > 2607:F518:15F::10 0021.5903.1367  REACH Fa2/1
> >
> > rtr-inet2#ping  2607:F518:15F::1
> > Type escape sequence to abort.
> > Sending 5, 100-byte ICMP Echos to 2607:F518:15F::1, timeout is 2 seconds:
> > !
> > Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
> >
> > 
> > Matthew Huff | 1 Manhattanville Rd
> > Director of Operations   | Purchase, NY 10577
> > OTA Management LLC   | Phone: 914-460-4039
>
>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Drop rule at the end of CoPP conflicts with MAC learning

[Mack McBride]

I would try switching code versions.
It sounds like you are hitting a bug.
Given the fact that other boxes running different code are behaving normally,
The only conclusion is that it is a software issue.
Keep in mind that TAC may not have it listed as a known bug even though it was 
fixed.

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of "Rolf 
Hanßen"
Sent: Monday, July 01, 2013 6:44 AM
To: Nick Hilliard
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Drop rule at the end of CoPP conflicts with MAC learning

Hi,

If I had a support contract for that box I would open a tac case now. ;)

kind regards
Rolf

> On 28/06/2013 17:55, "Rolf Hanßen" wrote:
>> does not look like this is a general hardware version issue.
>
> mmm, ok.  I would:
>
> - run a context diff on the configuration on each of these machines to 
> ensure that there are no syntactic differences
>
> - disable and then re-enable copp on the affected box to ensure that 
> it's reprogrammed correctly into the hardware (sometimes things get 
> messed up on the way down to the line cards)
>
> - compare the output of "show mls rate-limit" on all machines
>
> - check your platform acl tcam capacity using "show platform hardware 
> capacity acl", to ensure that you still have some acl tcam space 
> available for your copp config.
>
> If this doesn't point towards a resolution, I'd open up a tac case.
>
> Nick
>
>
>> But I found a box with the same hardware versions:
>>
>> Mod  Port Model  Serial #Versions
>>   -- ---
>> -
>>   52  WS-SUP720-3B   ### Hw : 5.3
>>  Fw : 8.4(2)
>>  Sw : 12.2(33)SXJ
>>  Sw1: 20.1(1)SXJ
>>   WS-SUP720  ### Hw : 2.6
>>  Fw : 12.2(17r)SX7
>>  Sw : 12.2(33)SXJ
>>   WS-F6K-PFC3B   ### Hw : 2.3
>>
>> This box also works as soon as I enter "mls rate-limit unicast cef 
>> glean 500".
>>
>> kind regards
>> Rolf
>>
>>>> Any further ideas except hardware failure, buggy software or "try 
>>>> rebooting it" ?
>>>
>>> Could be a hardware issue.  As someone else mentioned (Phil?), this 
>>> particular feature is hardware revision dependent.
>>>
>>> What hardware versions are each of your SUP720s (show module)?
>>>
>>> Nick
>>>
>>>
>>>
>>
>>
>
>


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Sup-720 fabric failures

[Mack McBride]

This is actually a common fault in electronics (not just routers).
As the device cools, improper solder connections separate causing issues (ie. 
Something isn't making good contact).
As the device heats up the components expand and restore contact and everything 
works fine.
This is in fact a fault.  Under normal conditions the device should be able to 
function as long as you don't get
condensation and you don't freeze the capacitors (which freeze somewhere below 
0C).
Obviously fluctuating the temperature will make the situation worse as the poor 
connection eventually becomes
no connect from shrinking and expanding.

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil 
Mayers
Sent: Friday, July 05, 2013 5:25 AM
To: Robert Williams
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Sup-720 fabric failures

On 05/07/13 12:22, Robert Williams wrote:
> Slightly warmer than that, a cosy 15 degrees Celsius I'm afraid...

That's really weird. We have operated sup720 in places that cool.

> Any ideas?

None spring to mind, beyond a really odd hardware fault.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] How to CoPP (Control Plane Policing) configuration?

[Mack McBride]

First step is determining what is actually hitting your control plane and
what the maximum traffic levels for that traffic should be.

For some platforms like the 6500 you have to deal with traffic requiring ARP
And ICMP responses as well as what should be hitting the cpu for control and
routing protocols.  There are also spanning-tree packets and other things that
have to be accounted for.

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
PlaWanSai RMUTT CPE IX
Sent: Thursday, June 13, 2013 3:03 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] How to CoPP (Control Plane Policing) configuration?

Could you please how to CoPP (Control Plane Policing) configuration?

It has a best practice for each model?

Now, I want configuration for ME-3600x.

 

Thank you very much.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ASR 1002-X FIB scalability (was: Re: ASR-100x intro)

[Mack McBride]

You aren't actually looking at the fib information, just CEF (which is not the 
same).
The CEF table in the RP is not the same as the CEF table on the ESP.
Routes that aren't processed on the QFP get processed on the RP.
Ie. SLOWLY.

The command you are looking for is:

sh plat hard qfp active infra exmem statistics

If the FIB overflows the DRAM, it will start using IRAM.
If the IRAM fills the ESP may become unstable and traffic is offloaded to the 
RP.
I have not found a command to actually show the CEF information on the ESP.

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Beck, 
Andre
Sent: Tuesday, May 28, 2013 3:45 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ASR 1002-X FIB scalability (was: Re: ASR-100x intro)

Re,

On Thu, Apr 11, 2013 at 11:59:03AM +0200, Beck, Andre wrote:
> 
> When my 1002-X box with 16GB hits the lab, before anything else, I'll 
> set it up to push BGP tables into it using bgpsimple (I also tried 
> exabgp but it gets slow as molasses as soon as you try to push some 
> 100k prefixes) and see where it goes through the roof.

For starters, here is the ASR 1002-X with 16GB (atm still running 3.7.0 
consolidated as it came), flooded with a BGP table of 3.1M prefixes.
I had to change my prefix generator to allow for prefix lengths of up to /27 in 
order to get there (trivial stateless randomized generator, the pigeonhole 
principle and all that), so it stresses the 8-8-8-8 mtrie even more badly. 
Here's some output from the ASR which took that size of table and FIB without a 
hitch:

1. The RIB side of the game

asr1002-x#sh ip bgp summary
BGP router identifier 192.168.127.12, local AS number 65533 BGP table version 
is 31438353, main routing table version 31438353
3114278 network entries using 772340944 bytes of memory
3114278 path entries using 348799136 bytes of memory
1018812/1018812 BGP path/bestpath attribute entries using 228213888 bytes of 
memory
1018812 BGP AS-PATH entries using 153930440 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory BGP using 1503284408 
total bytes of memory BGP activity 1707/13919059 prefixes, 
17276315/14162037 paths, scan interval 60 secs

NeighborV   AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  
State/PfxRcd
192.168.111.254 465522 3114282   7 3143835300 00:42:06  
3114278

asr1002-x#sh ip route summary
IP routing table name is default (0x0)
IP routing table maximum-paths is 32
Route SourceNetworksSubnets Replicates  OverheadMemory (bytes)
connected   0   3   0   264 864
static  0   0   0   0   0
bgp 65533   360012  2754266 0   274056464   896912064
  External: 3114278 Internal: 0 Local: 0
internal97357   198402256
Total   457369  2754269 0   274056728   1095315184


2. And now for the FIB stuff

asr1002-x#sh ip cef summary   
IPv4 CEF is enabled for distributed and running
VRF Default
 3114292 prefixes (3114292/0 fwd/non-fwd)
 Table id 0x0
 Database epoch:2 (3114292 entries at this epoch)

asr1002-x#sh cef memory summary 
CEF has allocated 2136896276 bytes of memory (5919372 bytes overhead)

asr1002-x#sh cef memory 
  Memory  in use/allocated Count
  --
  ADJ: GSB  :468/560( 83%) [1]
  ADJ: NULL adjacency   :436/528( 82%) [1]
  ADJ: adj sev context  :232/416( 55%) [2]
  ADJ: adjacency:   3408/3776   ( 90%) [4]
  ADJ: mcprp_adj_inject_sb  :  16588/16680  ( 99%) [1]
  ADJ: request resolve  :   4688/4872   ( 96%) [2]
  ADJ: sevs :432/616( 70%) [2]
  CEF: Brkr Updat   :   9704/10440  ( 92%) [8]
  CEF: Brkr Update Rec  :312/496( 62%) [2]
  CEF: Brkr zone:988/2736   ( 36%) [19]
  CEF: Broker   :   5684/7432   ( 76%) [19]
  CEF: Brokers Array:180/272( 66%) [1]
  CEF: EVENT msg chunks :332/424( 78%) [1]
  CEF: FIB LC array :452/544( 83%) [1]
  CEF: FIB LC stats array   :   9860/9952   ( 99%) [1]
  CEF: FIB subtree context  :328/880( 37%) [6]
  CEF: FIBHWIDB :  15444/16640  ( 92%) [13]
  CEF: FIBIDB   :   6292/7488   ( 84%) [13]
  CEF: IPv4 ARP throttle:   2052/2144   ( 95%) [1]
  CEF: IPv4 process :   1128/1864   ( 60%) [8]
  CEF: OCE get hash callbac : 52/144( 36%) [1]
  CEF: TABLE msg chunks :804/896( 8

Re: [c-nsp] 7609 %CONST_DIAG-SP-3-HM_TEST_FAIL

[Mack McBride]

I would try a remove and reseat.
This module has a DFC so the problem COULD be the DFC rather than the line card.
You may want to try reseating the DFC while you are working on the card.
If reseating the DFC and the line card doesn't fix it then the card or DFC is 
toast.
Depending on your warranty or service contract, I would try to RMA if reseating 
doesn't help.

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Chris 
Lane
Sent: Friday, May 17, 2013 7:17 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] 7609 %CONST_DIAG-SP-3-HM_TEST_FAIL

New line card inserted about a week ago, along with a new 10g service. Last 
night the LC crashed with the following;

000504: May 17 03:41:24.011 CDT: %CONST_DIAG-SP-3-HM_TEST_FAIL: Module 4 
TestMacNotification consecutive failure count:5
000505: May 17 03:41:24.015 CDT: %CONST_DIAG-SP-6-HM_TEST_SP_INFO:
TestMacNotification[4]: last_busy_percent[13%], Tx_Rate[577], Rx_Rate[46]
000508: May 17 03:42:17.500 CDT: %LINK-3-UPDOWN: Interface 
TenGigabitEthernet4/1, changed state to down
000509: May 17 03:42:17.504 CDT: %LINEPROTO-5-UPDOWN: Line protocol on 
Interface TenGigabitEthernet4/1, changed state to down
000510: May 17 03:42:17.628 CDT: %SNMP-5-MODULETRAP: Module 4 [Down] Trap
000511: May 17 03:42:17.476 CDT: %CONST_DIAG-SP-2-HM_LC_CRSH: Module 4 crashed 
due to unrecoverable errors, Reason: Failed TestFabricCh1Health
000512: May 17 03:42:17.632 CDT: %C6KPWR-SP-4-DISABLED: power to module in slot 
4 set off (Diagnostic Failure)
000513: May 17 03:42:17.752 CDT: %LINK-SP-3-UPDOWN: Interface 
TenGigabitEthernet4/1, changed state to down
000514: May 17 03:42:17.876 CDT: %HA_EM-6-LOG: Mandatory.go_fabrich1.tcl:
GOLD EEM TCL policy for TestFabricCh1Health
000515: May 17 03:42:17.756 CDT: %LINEPROTO-SP-5-UPDOWN: Line protocol on 
Interface TenGigabitEthernet4/1, changed state to down

s72033-advipservicesk9_wan-mz.122-33.SXH7.bin

sh mod
Mod Ports Card Type  Model  Serial
No.
--- - -- --
---
  1   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX
SAL1405ACTW
  3   16  SFM-capable 16 port 1000mb GBICWS-X6516-GBIC
 SAD050603XM
  44  CEF720 4 port 10-Gigabit Ethernet  WS-X6704-10GE
 SAL1338Z6Z2
  52  Supervisor Engine 720 (Active) WS-SUP720-3BXL
SAD084805W5

Mod MAC addresses   HwFw   Sw
Status
--- -- --  
---
  1  8843.e1b6.f950 to 8843.e1b6.f97f   3.4   12.2(18r)S1  12.2(33)SXH7 Ok
  3  0001.63d0.e11e to 0001.63d0.e12d   2.0   6.1(3)   8.7(0.22)BUB Ok
  4  0027.0d34.f7bc to 0027.0d34.f7bf   3.0   12.2(14r)S5  12.2(33)SXH7
PwrDown
  5  0011.21a1.5680 to 0011.21a1.5683   4.1   8.1(3)   12.2(33)SXH7 Ok

Mod  Sub-Module  Model  Serial   Hw
Status
 --- -- --- ---
---
  1  Centralized Forwarding Card WS-F6700-CFC   SAL1406AS70  4.1Ok
  4  Distributed Forwarding Card WS-F6700-DFC3BXL   SAL1333W4UP  5.5
 PwrDown
  5  Policy Feature Card 3   WS-F6K-PFC3BXL SAD084806L7  1.4Ok
  5  MSFC3 Daughterboard WS-SUP720  SAD084307B8  2.2Ok

Mod  Online Diag Status
 ---
  1  Pass
  3  Pass
  4  Not Applicable
  5  Pass

I have read in many earlier threads it could be the SUP the chassis and just a 
simple reseating of the card.

Does anyone have the clear picture here?

 Thanks so much for looking



--
//CL
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Quick question regarding BGP route churn & PRP-2

[Mack McBride]

There is a bug in some of the PRP-2 code relating to the BGP process leaking 
memory and utilizing more and more CPU.
Two things you can do to help eliminate the bug, one is upgrade code, the 
second is to fully remove inactive BGP sessions.
It appears that the router process 'saves' updates for the inactive BGP 
sessions.
I encountered this problem on our PRP-2s.

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Drew Weaver
Sent: Thursday, March 07, 2013 6:21 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Quick question regarding BGP route churn & PRP-2

Howdy,

One of our routers in a smaller facility is still rocking a pair of PRP-2s and 
we've been getting notices lately that it has been failing to respond to SNMP 
queries.

Makes sense, as my cell phone likely has a better CPU than the PRP-2 but I 
wanted to see if there was any way to extend the life of this thing just a 
little longer.

I tracked the CPU usage and it appears that the BGP ROUTER process is what is 
eating all of the CPU time when this issue happens.

There seems to be a constant deadly drip of routing updates coming in from one 
of the upstream providers attached to this router:

The below were taken just 1 second apart:

NeighborV   AS MsgRcvd MsgSent   TblVerInQ OutQ 
Up/Down  State/PfxRcd
x.x.x.13  43356 164983466 1610722 334466344   130   
 4w2d   434626

NeighborV   AS MsgRcvd MsgSent   TblVerinQ OutQ 
Up/Down  State/PfxRcd
x.x.x.13  43356 164983671 1610725 3344668430 0  
   4w2d   434664

NeighborV   AS MsgRcvd MsgSent   TblVerInQ OutQ 
Up/Down  State/PfxRcd
x.x.x.13  43356 164983700 1610725 33446684300   
   4w2d   434674

We have only been getting the notices that SNMP is failing 2-3 times a day out 
of 480 pollings but it's enough to cause alerts and operational events to be 
created, etc.

Awhile back we had a problem with another upstream where it would take an hour 
sometimes to download the full table from them so we implemented PMTUD which 
helped in that scenario; the max data segment size on this particular neighbor 
appears to be 1460 bytes.

Does anyone have any tips or tricks on ways to lessen the impact of the 
constant route churn aside from either "Don't use a PRP-2 because it sucks" or 
"don't import a full table".

We're already scheduled to be upgrading to ASR9000s with RSP440s fairly soon 
but like I said I do need to squeeze out just a few more months on this beastie.

This particular router is still running IOS and hasn't been upgraded to XR.

Thanks!
-Drew

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] summary, but leak a couple

[Mack McBride]

You would put in aggregate summary-only for the ones you want to leak.
Each summary-only line will produce a route.

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Aaron
Sent: Tuesday, March 05, 2013 8:25 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] summary, but leak a couple

In ios xr how would I summarize all more specific's within this range, BUT leak 
a more specifics ?

 

router bgp 64512

vrf one

rd 1.1.1.1:1

address-family ipv4 unicast

  aggregate-address 10.0.0.0/8 summary-only

 

 

but I want to leak, 10.10.10.0/24

 

how would I do that ?

 

Aaron

 

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP advertisements more specific than IGP

[Mack McBride]

Most providers have a set of communities to set local pref and
Re-advertisement to peers that can be used to influence inbound
Traffic.

The short answer is there is not a 'good' way to influence inbound
Traffic.  Communities are your best bet.

-Original Message-
From: James Urwiller [mailto:jurwil...@americanbb.com] 
Sent: Friday, March 01, 2013 10:27 AM
To: Mack McBride; cisco-nsp@puck.nether.net
Subject: Re: BGP advertisements more specific than IGP

Community strings don't effect inbound traffic, right?
Is there really no good way to influence inbound traffic?

James Urwiller
Network Operations Manager
CCNA 11567125
American Broadband
402-426-6257 - Office
402-278-1875 - Cell
402-426-6273 - Fax




jurwil...@americanbb.com





On 3/1/13 11:25 AM, "Mack McBride"  wrote:

>You can use conditional advertisement to do what you are wanting to do.
>But as Randy mentioned you should really use communities with your 
>upstreams to influence traffic.
>If communities don't work then consider conditional advertisement.
>http://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/1cbgp.
>htm
>l#wp9071
>If you advertise your deaggregates you should still advertise your 
>aggregate block.
>That allows those of us who don't care about your traffic engineering 
>desires  but do care about the routing table size to drop your 
>deaggregates.
>At some point a lot of providers are going to be dropping deaggregates.
>
>LR Mack McBride
>Network Architect
>
>-Original Message-
>From: cisco-nsp-boun...@puck.nether.net 
>[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of James Urwiller
>Sent: Thursday, February 28, 2013 8:12 PM
>To: cisco-nsp@puck.nether.net
>Subject: [c-nsp] BGP advertisements more specific than IGP
>
>I have a BGP multi-homed invironment that I am having problems 
>balancing inbound traffic, besides prepends which don't seem to be 
>helping anymore, I have heard that announcing my networks more 
>specifically could also influence inbound traffic.  My question is, for 
>example... If I have a
>/23 that I am using as a /23 in OSPF, can I announce that in BGP more 
>specifically (2, /24's)  without having to them break it up internally 
>as well?  What I foresee happening is this..
>
>Example:
>BGP:
>Network 192.168.0.0/24
>Network 192.168.1.0/24
>
>OSPF:
>Network 192.168.0.0/23
>
>I would think in this scenario, the IP addresses 192.168.1.0 and
>192.168.0.255 would not have a route in BGP, even though they are valid 
>addresses for use when used as a /23.  Since I would be multi-homed, I 
>would still advertise the network as the aggregate /23 on the circuit I 
>don't want to take as much traffic, so would those IP addresses in this 
>scenario still work, but only through the circuit I advertise as the 
>aggregate??
>
>James Urwiller
>Network Operations Manager
>CCNA 11567125
>American Broadband
>402-426-6257 - Office
>402-278-1875 - Cell
>402-426-6273 - Fax
>jurwil...@americanbb.com<mailto:jurwil...@americanbb.com>
>
>___
>cisco-nsp mailing list  cisco-nsp@puck.nether.net 
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP advertisements more specific than IGP

[Mack McBride]

You can use conditional advertisement to do what you are wanting to do.
But as Randy mentioned you should really use communities with your upstreams to 
influence traffic.
If communities don't work then consider conditional advertisement.
http://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/1cbgp.html#wp9071
If you advertise your deaggregates you should still advertise your aggregate 
block.
That allows those of us who don't care about your traffic engineering desires  
but
do care about the routing table size to drop your deaggregates.
At some point a lot of providers are going to be dropping deaggregates.

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of James Urwiller
Sent: Thursday, February 28, 2013 8:12 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] BGP advertisements more specific than IGP

I have a BGP multi-homed invironment that I am having problems balancing 
inbound traffic, besides prepends which don't seem to be helping anymore, I 
have heard that announcing my networks more specifically could also influence 
inbound traffic.  My question is, for example... If I have a /23 that I am 
using as a /23 in OSPF, can I announce that in BGP more specifically (2, /24's) 
 without having to them break it up internally as well?  What I foresee 
happening is this..

Example:
BGP:
Network 192.168.0.0/24
Network 192.168.1.0/24

OSPF:
Network 192.168.0.0/23

I would think in this scenario, the IP addresses 192.168.1.0 and 192.168.0.255 
would not have a route in BGP, even though they are valid addresses for use 
when used as a /23.  Since I would be multi-homed, I would still advertise the 
network as the aggregate /23 on the circuit I don't want to take as much 
traffic, so would those IP addresses in this scenario still work, but only 
through the circuit I advertise as the aggregate??

James Urwiller
Network Operations Manager
CCNA 11567125
American Broadband
402-426-6257 - Office
402-278-1875 - Cell
402-426-6273 - Fax
jurwil...@americanbb.com<mailto:jurwil...@americanbb.com>

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] HSRP/VRRP/GLBP Dual Stack on Cat6500/Sup720 3BXL?

[Mack McBride]

HSRP and GLPB requires setting up different groups for the dual stack.
The same groups can be used on different vlans but the IPv6 has to be in a 
separate group from IPv4.

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of vinny_abe...@dell.com
Sent: Thursday, February 28, 2013 11:30 AM
To: jle...@lewis.org
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] HSRP/VRRP/GLBP Dual Stack on Cat6500/Sup720 3BXL?

Well, in SXI4a, GLBP complains if I try and configure IPv6 in the same GLBP 
group number:

"IPv4 address already configured"

I'm not clear if I'm supposed to use a different group number or if it's just 
not supported. All the configuration examples I found show *just* IPv6, not a 
dual stack example which is what triggered my inquiry.

-Vinny

-Original Message-
From: Jon Lewis [mailto:jle...@lewis.org]
Sent: Thursday, February 28, 2013 1:19 PM
To: Abello, Vinny
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] HSRP/VRRP/GLBP Dual Stack on Cat6500/Sup720 3BXL?

On Thu, 28 Feb 2013 vinny_abe...@dell.com wrote:

> Hello,
>
> Is there dual stack support in any redundancy protocol 
> (HSRP/VRRP/GLBP) on the Catalyst 6500 with a Sup720 3BXL? If so, which 
> protocols are supported and beginning in what IOS releases?

I haven't utilized it in v6, but SXI appears to have v6 capable HSRP and GLBP.  
VRRP doesn't appear to have any v6 support.

--
  Jon Lewis, MCP :)   |  I route
  Senior Network Engineer |  therefore you are
  Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 802.1Q-in-Q VLAN Tag Termination on 7600/6500 OSN modules

[Mack McBride]

7600 will do EoMPLS with lan cards (best bet is pseudowire mode) but there are 
caveats with vlan rewrite and things like that.
And of course the lack of support for Q in Q.

Mack

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Benny Amorsen
Sent: Thursday, February 28, 2013 5:52 AM
To: Davide Ambrosi
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 802.1Q-in-Q VLAN Tag Termination on 7600/6500 OSN modules

Davide Ambrosi  writes:

> I see that 7600 catalyst modules doesn't support QinQ VLAN termination 
> (the command "encapsulation dot1q outer-vlan second-dot1q inner-vlan) 
> because they are "LAN" modules.

The only cheap way to do what you want is to use some other box to either do 
VLAN translation or place the traffic into EoMPLS tunnels. I am not actually 
sure whether the 7600 will do routed EoMPLS with LAN-cards, I have only tried 
that with a SIP-600.

ES+ will obviously do what you want as you mention, and ASR1k and ASR9k
can do the same.


/Benny
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 802.1Q-in-Q VLAN Tag Termination on 7600/6500 OSN modules

[Mack McBride]

The ES+ cards are the way to go.
The OSM modules aren't going to do what you want.
In addition they aren't properly supported in newer code.

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Davide Ambrosi
Sent: Wednesday, February 27, 2013 9:32 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] 802.1Q-in-Q VLAN Tag Termination on 7600/6500 OSN modules

Hello,

We have some 7603 boxes with SUP720/SUP2 installed as main supervisor in our 
MPLS Edge sites.

Now we need to terminate QinQ VLAN directly on one or more GE interfaces of the 
7603 routers because we are planning to introduce metro ethernet tecnologies 
(ME3400E/ME3600X) in our fiber and microwave access network for reducing the 
VLAN configured between the switches located in the access network (now we have 
1 VLAN = 1 Customer).

I see that 7600 catalyst modules doesn't support QinQ VLAN termination (the 
command "encapsulation dot1q outer-vlan second-dot1q inner-vlan) because they 
are "LAN" modules.

Is there anyone who tested QinQ termination on old 7600 OSN GE modules like the 
OSM-2+4GE-WAN+ ? If not supported the only way to support QinQ is to buy new 
(expensive) 7600-S chassis + ES cards or SIP-400 and SPAs V2 ?

In out network environment we have also some 7609-S(RSP720) with ES+ card 
located into the core an large aggregation sites and with this equipment we 
don't have problems because the QinQ Termination is supported on ES+ card.


Davide
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] low cost reliable optics

[Mack McBride]

OSI is another good source.

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of harbor235
Sent: Saturday, February 23, 2013 7:48 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] low cost reliable optics

Anyone know of any low cost reliable alternatives to the Cisco-WS-G5483-GBIC?


thanks,

Mike
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Next step-up from 7206VXR

[Mack McBride]

I believe amazon ran into this not too long ago.

At 768k you are effectively limiting your IPv6 table to 128k (you can't really 
go more than that if you expect to use IPv6).
I recommend a 640k/192k split.

As for an article:

http://www.ipv4depletion.com/?p=672

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mikael Abrahamsson
Sent: Tuesday, February 19, 2013 10:52 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Next step-up from 7206VXR

On Tue, 19 Feb 2013, Jon Lewis wrote:

> Some will tune (or already have tuned) the split to buy another year 
> or so, others will do so only after some head scratching when their 
> 6500s fall over.

I believe the -XL version will last longer than 1-2 years. Getting number of 
IPv4 DFZ routes into the 700-800k on that platform is doable (especially if 
it's mostly just used as L3 device and nothing else).

Otoh getting the word out that people need to tune their routers is an 
interesting problem, how do we do that best? I concur that a lot of people are 
going to run into problems during 2013 when we're most likely to go over the 
default split.

What is the error message when this happens, perhaps an article could be 
created that is easily found using the most common search engines?

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Next step-up from 7206VXR

[Mack McBride]

Sup720 handles the average churn fine.  Spikes in churn can be an issue, but 
for the average use they are fine.
The usual cause of spikes are full feed failures and re-convergence.
The RSP720 and Sup2T obviously have superior CPUs that can handle the spikes as 
well.

The 1 million routes is default 500k ipv4 and 250k ipv6.
Most providers have changed their setups to 640k ipv4 and 192k ipv6.
At some point service providers will stop allowing /24 de-aggregates when a 
shorter prefix exists.

All of the Sups and DFCs basically use the same FIB TCAM so no there is no 
difference in how they handle
the routes.  The only difference is between v4 and v6, 2 x v4 = 1 x v6.

There is a difference in the ACL TCAM but it mainly effects IPv6 ACLs.

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Pete Lumbis
Sent: Tuesday, February 19, 2013 10:34 PM
To: Jon Lewis
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Next step-up from 7206VXR

There are two pieces: control plane processing power and TCAM.

Sup720 CPU can't really keep up with the average churn of the internet anymore. 
RSP720's and Sup2T CPUs can still keep up.

Both RSP720-3CXL and Sup2T-XL can support 1 million routes*

*hardware implementation is different on these cards and how v4/v6 routes are 
shared in hardware storage is not the same.


On Tue, Feb 19, 2013 at 11:39 PM, Jon Lewis  wrote:

> The Sup720-3bxl (and Sup2T and RSP720) will run out of tcam before the 
> "churn of [a couple of] full feeds" makes them non-viable.
>
> We're getting close to a repeat of 2008, where lots of 6500s (those 
> still running Sup2s) were inching up against their maximum supported 
> routes when dealing with full views.  Sometime in the next year or so, 
> the default
> IPv4/IPv6 split on the best Sups you can get today are going run out 
> of
> IPv4 FIB TCAM.  Some will tune (or already have tuned) the split to 
> buy another year or so, others will do so only after some head 
> scratching when their 6500s fall over.
>
> The question is, will cisco release a bigger FIB TCAM sup for the 
> 6500, or will they allow this product line to end its useful life as a 
> full view internet router in order to push people into ASRs or competitors' 
> products?
>
>
>  On Tue, 19 Feb 2013, Pete Lumbis wrote:
>
>  Both Sup2t and RSP720 (to a lesser extent but still much better than
>> Sup720) can handle the churn of full feeds.
>>
>>
>> On Tue, Feb 19, 2013 at 5:10 PM, Tony Varriale > >wrote:
>>
>>  On 2/19/2013 2:57 PM, Jon Lewis wrote:
>>>
>>>  On Tue, 19 Feb 2013, Eric A Louie wrote:
>>>>
>>>>  I've run out of port capacity on my 7206VXR and need to go to "the 
>>>> next
>>>>
>>>>> router"
>>>>> or put in another 7206VXR side-by-side.
>>>>>
>>>>> Any recommendations on what to use if I were to replace my 
>>>>> existing 7206VXR with another chassis?  (it's limited to 5 GB 
>>>>> interfaces, and we need 7 or 8)
>>>>>
>>>>>
>>>> You've got to say more about what the router is doing and what you 
>>>> need from it.  If it's routing for 8 1gb ethernets and doing full 
>>>> BGP routes, and nothing special, then a 6500 is an attractive 
>>>> option bang for your buck-wise.  They're made for ethernet and 
>>>> comparitively cheap to keep adding ports to.
>>>>
>>>>  Except when said 6500 sup CPU is asked to do BGP intensive stuff 
>>>> :)
>>>>
>>>
>>> tv
>>>
>>>
>>> ___
>>> cisco-nsp mailing list  cisco-nsp@puck.nether.net 
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp<https://puck.
>>> nether.net/**mailman/listinfo/cisco-nsp>
>>> https://puck
>>> .nether.net/mailman/listinfo/cisco-nsp>
>>> >
>>> archive at 
>>> http://puck.nether.net/pipermail/cisco-nsp/<http://puck.nether.n
>>> et/**pipermail/cisco-nsp/> 
>>> <http://**puck.nether.net/pipermail/**cisco-nsp/<http://puck.nether.
>>> net/pipermail/cisco-nsp/>
>>> >
>>>
>>>  __**_
>> cisco-nsp mailing list  cisco-nsp@puck.nether.net 
>> https://puck.nether.net/**mailman/listinfo/cisco-nsp<https://puck.net
>> her.net/mailman/listinfo/cisco-nsp>
>> archive at 
>> http://puck.nether.net/**pipermail/cisco-nsp/<http://puck.nether

Re: [c-nsp] ASR-100x intro

[Mack McBride]

The shared RAM is kind of a misnomer.
On systems with an separate ESP and RP/RP2 there are two linux processors that 
control the cards.
On the combined systems there is only one processor, so it doesn't really share 
RAM there is just one processor.

The route limit on the RP/RP2 is kind of a misnomer as well.
All of the FIB space lives on the ESP portion of the board on shared systems and
Solely on the ESP in the separate cards.
The RAM for the QFP is separate from the control processor RAM.
The QFP has IRAM and DRAM, IRAM is instruction space, DRAM is data space.
In theory the IRAM can be used for FIB space (I am told that is bad).
Of course in theory the control processor can also do routing for punted 
packets.

How this thing handles running out of FIB DRAM (data ram) on the QFP is still 
an open question.

Having said all of that, the control processor ram does limit how many and how 
large of a BGP table
you can hold.  The FIB only holds one CEF adjacency for each route.  Each CEF 
adjacency can have up to
16 load sharing interfaces (in theory).

Final answer on how long 1M routes will work for is variable.
At least 18 months, possibly as long as 3 or 4 years.  Beyond that and there is 
going to be table pruning if
growth continues.

LR Mack McBride
Network Architect

-Original Message-
From: Charles Sprickman [mailto:sp...@bway.net] 
Sent: Tuesday, February 19, 2013 9:03 PM
To: Lukasz Bromirski
Cc: Mack McBride; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ASR-100x intro


On Feb 16, 2013, at 1:29 PM, Lukasz Bromirski wrote:

> 
> On Feb 16, 2013, at 10:34 AM, Charles Sprickman  wrote:
> 
>> On Feb 8, 2013, at 12:27 PM, Mack McBride wrote:
>> 
>>> One of the questions I haven't gotten a good answer to.
>>> The ESP actually has the hardware for the route table.
>>> The ESP20 and ESP40 handle 4 million routes.
>>> The others handle less (the 5G for examples handles 500k v4 or 125k v6).
>> 
>> And the ASR-1002-X with the "integrated" ESP-?? handles "1M IPv4 or 
>> 1M IPv6 routes" according to 
>> http://www.cisco.com/en/US/prod/collateral/routers/ps9343/data_sheet_
>> c78-450070.html
>> 
>> But the ESP-20 and ESP-40, which share many specs with the mystery embedded 
>> ESP in the 1002-X claims "4M IPv4 or 4M IPv6".
>> 
>> I don't know what the "OR" means, I can have 1M v4 OR 1M v6 but not some mix 
>> of the two?  The use of the word "or" there is strange.
> 
> It's either 1M for IPv4, 1M for IPv6 or some mix of it, depending on your 
> requirements.

Thanks.  The wording is odd.

> 
>> And the RP side is clear as mud as well.  The RP2 also claims "4M IPv4 or 4M 
>> IPv6" with the 16GB RAM option, but then the 1002-X "embedded" RP2 is back 
>> at the "1M IPv4 or 1M IPv6" number even though it's possible to order the 
>> 1002-X with 16GB RAM.
> 
> For the RR role (when the entries are not downloaded to FIB) it'll be 
> around 22-24M depending on the config and the requirements with 16GB of RAM.

Specifically on the 1002-X or the RP2 when loaded in another chassis?

Seriously, it would be really helpful if Cisco could answer these questions - 
the rest of the line seems pretty clear, but the 1002-X due to the combined 
RP2/ESP seems to be a bit of an oddball.

Anyone on-list have an ASR-1002-X?

> 
>> Am I understanding the architecture of this correctly?  I mean, if my RP2 
>> can hold 4M routes, which today would be what, about 9 full views, are ALL 
>> those routes shoved down to the forwarding plane, or just the "best" routes? 
>>  If so, why can't a lesser-spec'd ESP be limited to 1M routes even if the 
>> RP2 has 4M "possible" paths?
> 
> Only best entries are programmed into FIB (unless you enable BGP PIC, 
> or additional-paths extensions). That's for typical usage. For RR, you 
> use table-map to stop programming entries into FIB (typical for RR 
> scenario), and you can max-out the RAM with the entries.

With today's IPv4 table at around 450K, would anyone with multiple views like 
to share how many entries they end up with in the FIB?

In general, anyone feel like commenting on how long one could live with a FIB 
that maxes out at 1M routes?

> 
>>> What happens to the other routes?
>> Maybe we're asking the same question.  I hope so.
> 
> They fail to fit into available RAM, and process responsible for 
> 'getting them' will complain.
> 
>>> It seems they could get handled in software but the ESP is basically 
>>> software anyway.
>>> So the situation is clearly opaque.
>> The 1002-X makes it even more opaque.  Someone said earlier in the thr

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

[Mack McBride]

Reality is UDP matters.

LR Mack McBride
Network Architect

-Original Message-
From: Randy [mailto:randy_94...@yahoo.com] 
Sent: Wednesday, February 13, 2013 11:14 PM
To: Mack McBride
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ip tcp adjust-mss

HUH!

What corner cases??
This thread was about TCP:(ip tcp adjust-mss)not UDP!
As, has been already pointed out:

To OP:

Put in the little-effort required to UP MTU's on your physical-interfaces to 
support your services and as already-mentioned, design/re-design your network 
accordingly.

"ip-mtu and mtu(physical-int) are two very different things.
./Randy





--- On Tue, 2/12/13, Mack McBride  wrote:

> From: Mack McBride 
> Subject: Re: [c-nsp] ip tcp adjust-mss
> To: "Alexander Arseniev" , "moua0...@umn.edu" 
> , "cisco-nsp@puck.nether.net" 
> 
> Date: Tuesday, February 12, 2013, 9:31 AM There are always corner 
> cases.
> That's why I said most.
> 
> LR Mack McBride
> Network Architect
> 
> From: Alexander Arseniev [mailto:ecra...@hotmail.com]
> Sent: Tuesday, February 12, 2013 9:03 AM
> To: Mack McBride; moua0...@umn.edu;
> cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] ip tcp adjust-mss
> 
> 
> > From: mack.mcbr...@viawest.com<mailto:mack.mcbr...@viawest.com>
> > To: moua0...@umn.edu<mailto:moua0...@umn.edu>;
> cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> > Date: Mon, 11 Feb 2013 16:19:35 -0800
> > Subject: Re: [c-nsp] ip tcp adjust-mss
> >
> > Most UDP should not hit the MTU limitation.
> > The common ones that come to mind are streaming
> audio/video and DNS.
> >
> > LR Mack McBride
> > Network Architect
> >
> Wrt "streaming audio/video" - it depends on client/server combo.
> I recently saw an issue with RTSP video streaming from repubblica.it 
> website using Samsung Galaxy RSTP client.
> If UDP video packets are fragmented due to too small MTU in the path, 
> video does not play at all.
> And DNS is somewhat invalid example since when DNS reply does not fit 
> into 512 bytes, then DNS server will set a Truncated bit in the 
> packet, forcing client to use TCP.
> http://serverfault.com/questions/348399/force-forwarder-dns-requests-t
> o-tcp-mode No one uses 512B MTU (apart from miltary who use even 
> smaller MTU) and DNS over UDP would not be experiencing issues due to 
> too small MTU because own DNS payload limit is smaller than smallest 
> real MTUs out there (except military as I mentioned).
> Thanks
> Alex
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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

[Mack McBride]

There are always corner cases.
That's why I said most.

LR Mack McBride
Network Architect

From: Alexander Arseniev [mailto:ecra...@hotmail.com]
Sent: Tuesday, February 12, 2013 9:03 AM
To: Mack McBride; moua0...@umn.edu; cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] ip tcp adjust-mss


> From: mack.mcbr...@viawest.com<mailto:mack.mcbr...@viawest.com>
> To: moua0...@umn.edu<mailto:moua0...@umn.edu>; 
> cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
> Date: Mon, 11 Feb 2013 16:19:35 -0800
> Subject: Re: [c-nsp] ip tcp adjust-mss
>
> Most UDP should not hit the MTU limitation.
> The common ones that come to mind are streaming audio/video and DNS.
>
> LR Mack McBride
> Network Architect
>
Wrt "streaming audio/video" - it depends on client/server combo.
I recently saw an issue with RTSP video streaming from repubblica.it website 
using Samsung Galaxy RSTP client.
If UDP video packets are fragmented due to too small MTU in the path, video 
does not play at all.
And DNS is somewhat invalid example since when DNS reply does not fit into 512 
bytes, then DNS server will set a Truncated bit in the packet, forcing client 
to use TCP.
http://serverfault.com/questions/348399/force-forwarder-dns-requests-to-tcp-mode
No one uses 512B MTU (apart from miltary who use even smaller MTU) and DNS over 
UDP would not be experiencing issues due to too small MTU because own DNS 
payload limit is smaller than smallest real MTUs out there (except military as 
I mentioned).
Thanks
Alex
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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

[Mack McBride]

Most UDP should not hit the MTU limitation.
The common ones that come to mind are streaming audio/video and DNS.

LR Mack McBride
Network Architect

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ge Moua
Sent: Monday, February 11, 2013 5:03 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ip tcp adjust-mss

For UDP, one would have to do something like touch the end-hosts and adjust mtu 
size on the ip_stack itself.  Not very scalable and may require too much 
touch-points (also would be somewhat permanent).

Some client vpn shims do this to end-hosts after installations of said software.

--
Regards,
Ge Moua
Univ of Minn Alumnus
--


On 02/11/2013 02:25 PM, Peter Rathlev wrote:
> TCP MSS adjusting only works for TCP and probably puts an extra load 
> on the CPU of the router.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/