Re: [c-nsp] C8200/Spitfire/Pacific

On 18.03.22 10:08, Saku Ytti wrote: > Thank you, I appreciate this. Are you focusing on Q200 because it > ships, or did you look at Q100 but decided against it? > > I also similarly view it as a direct J competitor, and of course a lot > of the same people were involved designing both (J1 and

Re: [c-nsp] C8200/Spitfire/Pacific

Can't report from production, but we have a 8201-32FH (Q200/Gibraltar) in the lab right now. Currently considering it as a successor for 400G deployments where we had NCS55A1-24H for 100G before. So far so good for our use case as a basic PE. (unicast/multicast v4/v6, OSPFv2/v3, BGP, MPLS for

Re: [c-nsp] Netflow/Sflow for "irrelevant" traffic?

Exactly. For example, we do all our netflow 1:1 off a fiber tap on external appliances, so we see all the traffic on the wire even those packets that are not forwarded or dropped locally. That sometimes is a bit confusing as well :) -- Chris On 30.07.20 18:18, Saku Ytti wrote: On Thu, 30

Re: [c-nsp] NCS500 series

Hi Adam, The NCS540 has a Broadcom Qumran AX chipset with 3GB deep buffers. Smaller brother of the Qumran MX used in the NCS5501-SE. There should be a model coming with 4x100G around Q3 this year, which will make it a great successor for the ASR920, especially since it has deep buffers. (The

Re: [c-nsp] IPv6 uRPF broken on NCS5500 XR 6.2.3?

Hi David, uRPF on the NCS5500 is a mess due to limitations of the Jericho chipset. It has to do with the TCAM optimizations and twice the number of route lookups needed for uRPF (src/dst) From what I understand: On SE-models for uRPF to work you need to disable double-capacity mode (you

Re: [c-nsp] cisco-nsp Digest, Vol 180, Issue 1

Considering that the MX10003 is a worthy alternative to many current ASR9k 100G deployments that is way cheaper, I think it's still of interest to many Cisco users. Even if it is just a good reason for demanding higher discounts on your next purchase of 100G ASR9k gear ;-) Chris On 01.11.17

Re: [c-nsp] Juniper MX240 & MX480

The 3rd-Gen (EA) Trio chip is actually rated at 480G, has been rate-limited to 240G in MPC7e and MPC8e linecards and is currently rate-limited to 400G in the MPC9e cards and the 10003 MPC. I have no idea why it is rate-limited but suspect thermal issues? See the book Juniper MX Series, 2nd

Re: [c-nsp] Juniper MX240 & MX480

Regarding CWDM/DWDM, you could always add a QFX5110-48SH as a port extender box to the MX204 with Junos Fusion Provider Edge and sacrifice one or two 100G QSFP28 ports on the MX204. That way you'd have 2x100G and 48x 1/10G SFP+ ports with a bit of oversubscription in 2RU. Does anyone know if

Re: [c-nsp] ASR920 Image

Hi Dino, there are release notes available as usual: http://www.cisco.com/c/en/us/td/docs/routers/asr920/release/notes/ASR920_rel_notes.html Lists new features as well as caveats. Regards, Chris On 09.02.17 11:20, Dino Sosic wrote: Hi guys, I got a bunch of ASR-920-24SZ-M. They are running

Re: [c-nsp] ASR 920 firmware bugs in 03.18.00.S / 15.6(2)S

On 06/07/16 17:44, Adrian Minta wrote: On 07/04/2016 04:29 PM, Chris Welti wrote: Hi all, I can confirm that the bug has been fixed in 03.18.01.S / 15.6(2)S1 which is now out on CCO. Caution, after the first reload when you upgrade from a previous version, there will be a FPGA upgrade

Re: [c-nsp] ASR 920 firmware bugs in 03.18.00.S / 15.6(2)S

On 04/07/16 23:00, Mark Tinka wrote: On 4/Jul/16 15:29, Chris Welti wrote: I can confirm that the bug has been fixed in 03.18.01.S / 15.6(2)S1 which is now out on CCO. Caution, after the first reload when you upgrade from a previous version, there will be a FPGA upgrade and thus a second

Re: [c-nsp] ASR 920 firmware bugs in 03.18.00.S / 15.6(2)S

takes its times on these devices :) Best regards, Chris On 30/05/16 16:12, Chris Welti wrote: Hi all, The bug has now finally been made public. There should be a fix coming soon. https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuz13418/ Best regards, Chris On 25/04/16 20:34, Chris Welti

Re: [c-nsp] ASR920 experiences

On 13/06/16 23:36, James Jun wrote: Hi, On Mon, Jun 13, 2016 at 09:37:04AM +0200, Chris Welti wrote: I think Adrian was referring to the new flexi licensing implementation in 03.18.00.S.156-2.S, which is a total screw-up and can't be disabled. Keep away from that release and you should

Re: [c-nsp] ASR920 experiences

On 12/06/16 11:43, Mark Tinka wrote: On 12/Jun/16 10:38, Adrian Minta wrote: The software is very buggy right now. It's early days, but I disagree that it's very buggy. 15.5(3)S2a is reasonably stable. The license system is complex and confusing. Even the C software engineers don't fully

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

On 01/06/16 18:28, Saku Ytti wrote: On 1 June 2016 at 12:40, Phil Mayers wrote: That was always the documented behaviour on sup720. I never got an explanation when I asked as to why it was irreversible. You can configure 'freeze', 'reset', or 'recover' for exception

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

On 01/06/16 16:28, Marian Ďurkovič wrote: On Wed, Jun 01, 2016 at 11:03:05AM +0200, Chris Welti wrote: On 01/06/16 10:24, Mikael Abrahamsson wrote: On Tue, 31 May 2016, Pete Templin wrote: +1 on what Gert said. You'll get log entries at the 90% threshold within a region, but the badness only

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

On 01/06/16 10:24, Mikael Abrahamsson wrote: On Tue, 31 May 2016, Pete Templin wrote: +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. In my 5 year old experience, the badness would continue

Re: [c-nsp] ASR 920 firmware bugs in 03.18.00.S / 15.6(2)S

Hi all, The bug has now finally been made public. There should be a fix coming soon. https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuz13418/ Best regards, Chris On 25/04/16 20:34, Chris Welti wrote: I haven't found any matching public bugs on bugsearch. I guess I'll have to open a TAC case

Re: [c-nsp] ASR9001 Vs ASR1006

I'm running XR 6.0.1 on a ASR9001 right now. Am 15.05.16 um 03:26 schrieb Brandon Ewing: On Sun, May 15, 2016 at 12:50:46AM +0300, Saku Ytti wrote: I would be hesitant investing on ASR9001 right now, it's 32b control-plane. I'd worry if this means it's not getting Linux based IOS-XR, and I

Re: [c-nsp] ASR 920 firmware bugs in 03.18.00.S / 15.6(2)S

should just fix the behaviour of the non-dual-rate 10GE ports so that they are not put into admin down state when there is no license. Regards, Chris On 28/04/16 14:40, Mark Tinka wrote: On 28/Apr/16 14:28, Chris Welti wrote: Hi Mark, there is no option of not using the Flexi license. It i

Re: [c-nsp] ASR 920 firmware bugs in 03.18.00.S / 15.6(2)S

Hi Mark, there is no option of not using the Flexi license. It is a mandatory feature that can not be disabled. -- Chris On 27/04/16 23:05, Mark Tinka wrote: On 27/Apr/16 17:44, Chris Welti wrote: Quote: "This is happening due to the Flexi license feature introduced to XE

Re: [c-nsp] ASR 920 firmware bugs in 03.18.00.S / 15.6(2)S

On 27/04/16 18:52, Lukas Tribus wrote: Quote: "This is happening due to the Flexi license feature introduced to XE 3.18. This is an expected behavior. Please refer to the document below for more details on this. Well that's clearly wrong, because Flex licensing was introduced in XE 3.13

Re: [c-nsp] ASR 920 firmware bugs in 03.18.00.S / 15.6(2)S

r-920-book_chapter_0110.html; Although I couldn't find a single sentence in there that would explain the behaviour. Of course I've replied accordingly... Chris On 27/04/16 17:39, Gert Doering wrote: Hi, On Wed, Apr 27, 2016 at 05:35:44PM +0200, Chris Welti wrote: Oh gee, TAC c

Re: [c-nsp] ASR 920 firmware bugs in 03.18.00.S / 15.6(2)S

Oh gee, TAC claims that this is expected behaviour :-) On 25/04/16 20:34, Chris Welti wrote: I haven't found any matching public bugs on bugsearch. I guess I'll have to open a TAC case soon. Chris Am 25.04.16 um 19:07 schrieb Jason Lixfeld: BugID? On Apr 25, 2016, at 11:49 AM, Chris Welti

Re: [c-nsp] ASR 920 firmware bugs in 03.18.00.S / 15.6(2)S

I haven't found any matching public bugs on bugsearch. I guess I'll have to open a TAC case soon. Chris Am 25.04.16 um 19:07 schrieb Jason Lixfeld: BugID? On Apr 25, 2016, at 11:49 AM, Chris Welti <chris.we...@switch.ch> wrote: Hi all, since a few of you seem to have ASR 920 de

Re: [c-nsp] ASR 920 firmware bugs in 03.18.00.S / 15.6(2)S

I've tested the following releases for upgrades: 03.16.01a.S/03.16.02a.S/03.17.00.S, all have the same bad behaviour when upgrading to 03.18.00.S. I guess the problem really is with 03.18.00.S itself, because it will also shut down some 10GE ports when you erase the startup-config starting

[c-nsp] ASR 920 firmware bugs in 03.18.00.S / 15.6(2)S

Hi all, since a few of you seem to have ASR 920 deployed, a word of warning about upgrading to 03.18.00.S/15.6(2)S: - upgrading from a previous image might lead to some or all of your four 10GE uplink ports being put in admin shut down state which is reflected in running-config as well as

Re: [c-nsp] ASR vs 6807

Hi Brian, no ES/SIP cards needed. This is on a simple WS-X6704-10GE card. It has been working for years already, lowest version tested was on 12.2(33)SRE6. Please note that you can not do VPLS with the Sup720, this is just for simple P2P tunnels (EoMPLS). Regards, Chris On 28/11/14 09:24,

Re: [c-nsp] ASR vs 6807

Hi Simon, you can also do port-to-subint on the Sup720 using ethernet interworking: one end: interface TenGigabitEthernet3/2 xconnect y.y.y.y 1 encapsulation mpls end the other: interface TenGigabitEthernet4/2.2010 encapsulation dot1Q 2010 xconnect x.x.x.x 1 pw-class atom-eth-iw end The

Re: [c-nsp] WS-X6904-40G + FourX: Some SPF+ cause err-disable

Hi Matti, What type of SFP+ do you use? show idprom int Te4/13 | i Product the service unsupported-tranceiver only helps with the vendor protection, but not with the transceiver type (Product ID). E.g. the FourX adapter supports the following SFP+ types: SFP-H10GB-CU1M SFP-H10GB-CU3M

Re: [c-nsp] why there are no plans for A903-RSP2B-240 please?????

Hi Gert, Am 23/07/14 um 09:58 schrieb Gert Doering: On Tue, Jul 22, 2014 at 11:03:46PM +0200, Mark Tinka wrote: We're deploying quite a bunch of the C6880's in core switch roles. So very simple, pure Layer 2 switching, no fancy IP or MPLS features enabled. It's a good box, based on the SUP2T,

Re: [c-nsp] X6708-10G-3C compatible with 7604 chassis?

When you insert a card that needs more than 75cfm, the fan will be switched from restricted-power to full-power by the IOS software. I'm starting to believe there are different FAN-MOD-4HS out there, and some of them only support 75cfm per slot (300cfm in total) vs. those that also support 94cfm

Re: [c-nsp] Reply:R: mpls forwarding and ip forwarding

Hi, What Brian hinted to is how we do it in our network. MPLS is only used for EoMPLS/VPLS traffic, the rest is routed via normal IP. We have dedicated /32s Loopbacks for the EoMPLS/VPLS endpoints and only traffic to those /32s are labeled and MPLS switched. example config for /32 MPLS

Re: [c-nsp] Sup2T netflow problems

192.168.75.2Am 06/02/14 10:41, schrieb Peter Rathlev: On Wed, 2014-02-05 at 14:28 +0200, Henri Grönroos wrote: I think you are encountering CSCui17732 which is present in 15.1.2-SY1 too. Thank you for the pointer! According to the bug toolkit the 15.0SY versions are not affected. Can anybody

Re: [c-nsp] Sup2T netflow problems

Hi Phil, Am 05/02/14 12:58, schrieb Phil Mayers: On 05/02/14 11:47, Peter Rathlev wrote: We've started seeing some problems with our netflow collection and export from Sup2T's running 15.1(1)SY AIS. That can't be. Sup2T has operationally useful netflow. I read it somewhere... I like the

Re: [c-nsp] Sup2T netflow problems

Hi Henri, Hi Peter, I think you are encountering CSCui17732 which is present in 15.1.2-SY1 too. Sup2T: show tech-support hangs VTY session on Netflow TCAM interrupt In our Sup2Ts when that occurs they print syslog message %EARL_L3_ASIC-3-INTR_FATAL: EARL L3 ASIC 0: fatal interrupt

Re: [c-nsp] Sup720 - FIB full, software switching

Simple answer: No. One of the major design errors of the FIB in the Sup720. Unfortunately, once the FIB is full, the only way to get it back to normal is to restart the whole box. CFIB-SP-STBY-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched

Re: [c-nsp] C6K, PFC3B/BXL/C/CXL, 15.1(2)SY, NDE using IPv6 transport?

Not supported, IPv4 only: 15.1(2)SY(config-flow-exporter)#destination ? Hostname or A.B.C.D Destination IPv4 address or hostname Regards, Chris Am 15.12.13 01:45, schrieb Tim Durack: C6K, PFC3B/C/XL, 15.1(2)SY, NDE using IPv6 transport? Yes/no/don't know?

Re: [c-nsp] Sup2T - poor netflow performance

Am 18/10/13 16:57, schrieb Roland Dobbins: Chris Welti chris.we...@switch.ch wrote: ingress and egress on the same interface is a configuration officially supported by Cisco for the Sup2T. Escpecially for the Sup2T-XL/DFC4-XL which has separate netflow tables for ingress and egress

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

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

Re: [c-nsp] 6500 IOS recommendation?

Hi Ross, We actively noticed the issue when our connection to the AMS-IX routeservers flapped. Roughly 65000 prefixes out of which around 3000 were not correctly removed. No idea if VPNv4 prefixes are also affected, but note that this only happens to withdrawn prefixes under certain conditions

Re: [c-nsp] 6500 IOS recommendation?

A little word of advice for those that use BGP: Don't use 15.1(1)SY and 15.1(1)SY1. They have a nasty little BGP bug that can create black holes or loops for random prefixes due to stale RIB entries of withdrawals that are not processed correctly (CSCuh43027). Some withdrawn prefixes are being

Re: [c-nsp] Sup2T - poor netflow performance

Am 18.10.13 14:05, schrieb Dobbins, Roland: On Oct 18, 2013, at 12:13 PM, Rolf Hanßen n...@rhanssen.de wrote: ip flow monitor monitorname input ip flow monitor monitorname output If you're collecting both ingress and egress NetFlow on the same interface, this could be contributing to your

Re: [c-nsp] Problems with Netflow records creation on 6513/SUP2T-10G + WS-X6716-10GE/WS-F6K-DFC4-E

Hi Chad, Have you tried to reboot the whole chassis (not just failovers)? We noticed that on one of our Sup2T ingress netflow suddenly stopped working on one interface (that was on a WS-X6908-10GE though) and nothing helped but a clean reboot. Until about 15 days later when it stopped working

Re: [c-nsp] 6500, 7600 or ASR

Well, the C6880-X features a slightly modified version of the Sup2T as a new base-board, which actually has a larger FIB TCAM with 2M IPv4 entries (if the data from BRKARC-3468 is correct). So that might qualify as a new Sup, even if it's just for the semi-fixed chassis as of now :) I assume a

Re: [c-nsp] ASR9k IPv6 interface stats in 64bit

Am 7/23/13 12:39 AM, schrieb Justin M. Streiner: On Tue, 23 Jul 2013, Tassos Chatzithomaoglou wrote: ...which is indeed the case... achatz$ snmpwalk -v2c -c xxx router3 .1.3.6.1.2.1.4.31.3.1.6.2 ip.31.3.1.6.2.68 = Counter64: 40795287767 ip.31.3.1.6.2.69 = Counter64: 1638113009435 This OID

Re: [c-nsp] New Catalyst 6k chassis

For those interested in the technical details, the slides for BRKARC-3486 are up at: http://t.co/ZncyGrhHX9 Slide 24 seems to indicate that the current Sup2T can support 440G/slot using higher clock frequencies for the fabric connections and 4 instead of 2 fabric connections per linecard. I

Re: [c-nsp] New Catalyst 6k chassis

Am 6/27/13 12:36 PM, schrieb Tom Hill: I've been told that 880G will need a new Supervisor. 440G will be like RSP440 in the ASR9K: you will need dual SUP2T to take advantage of it. With a single Supervisor the other changes, you'll have 220G per slot. (My understanding -- correct me if

Re: [c-nsp] Sup2T / EARL8 Netflow oddities

Dear Jiri, we have similar netflow issues with our Sup2T-XL upgrades from the Sup720-3CXL. In general, all show platform flow commands are incredibly slow and tend to take minutes. Yes, I have waited longer than 10 minutes for certain show commands to complete, which were almost instant on the