Re: [c-nsp] FIB scale on ASR9001

2021-11-22 Thread Perrin Richardson via cisco-nsp 
--- Begin Message ---
+1 on the performance of Amsterdam, shocking. MPLS + jumbo frames absolutely 
useless. Went with 16.3.6 to get around all said issues and seems stable as a 
ibgp RR with the couple of licenses I need to run that contact the cisco smart 
system. 



On 22 Nov 2021, at 11:43 pm, Mark Tinka  wrote:



On 11/22/21 14:10, Robert Hass wrote:

> We will keep our ASR 9001 until support will expire, but for small Edge nodes.
> 
> Well it is hard to trust Cisco currently.
> 
> I can recall our CSR 1000V story (permament licenses). CSR 1000V
> permament licenses are EoL/EoS. But subscription CSR 1000V are not, so
> you need to pay again for something you already paid for.
> Next move was Catalyst 8000V which is CSR 1000V but with just new name,
> 
> How to deceive a customer who bought licenses?
> 1. Release a newer version under a newer name (Catalyst 8000V).
> 2. Retiring the previous product/version - EoS/EoL - CSR 1000V.
> 3. By that you simply stop discussion regarding perpetual ->
> subscrption model change
> 4. Done. Dear customers - pay again for same piece of software!

Oh dear, sorry to hear that. But that's exactly the kind of nonsense we are 
running away from Cisco for.

We love the CSR1000v, but we are not running the latest & greatest. We use them 
primarily for iBGP route reflection, and have settled on 15.5(3)S9 - a.k.a. 
3.16(09)S - for some time now, even though it shipped in March of 2019. It has 
all the relevant BGP features we need now, and into the future, so we aren't 
worried about running old code.

We did attempt upgrading them to Amsterdam - 17.3(4a) - but that was as 
cluster-f* of note. First, due to some issue between later versions of CSR1000v 
(16.x and higher) and how VMware identifies interface drivers, you lose the 
ability to set Jumbo frames, even if the host supports it. This totally broke 
iBGP sessions because IS-IS was confused, without looking confused.

Secondly, the license drama went to hell, same way you describe. But what I 
didn't know is that Cisco make you pay again for it; what horror! I just 
assumed they'd honour your previous permanent license, and port you over. 
Thanks for that!

Anyway, we downgraded back to what we are running today, and are happy. Our 
perpetual licenses are still valid, for the code we run.

If you need the newer code, I'd recommend taking a hard look at vMX or vSR, 
just for a better account management situation, if nothing else.

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/

--- End 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] ASR9010 fan tray upgrade

2021-06-28 Thread Perrin Richardson via cisco-nsp 
--- Begin Message ---
Hi Lee,

This can be done, the chassis will go into an alarm state due to the 
incompatible fan versions, however it is cosmetic and as soon as you replace 
the second tray with v2, the alarms will clear. Example logs;

 
%PLATFORM-ENVMON-4-FANTRAY_VER_MISMATCH : Fan tray version mismatch warning on 
slot 0/FT0/SP  
%PLATFORM-ENVMON-2-ENV_CONDITION : Outstanding environmental condition exists 
in the chassis 
%PLATFORM-ENVMON-4-FANTRAY_VER_MISMATCH_CLEAR : Fan tray version mismatch 
warning cleared on slot 0/FT0/SP
%PLATFORM-ENVMON-2-ENV_CONDITION : Outstanding environmental condition cleared 
in the chassis 

Perrin

On 29 Jun 2021, at 8:13 am, Lee Starnes  wrote:

Hello everyone,

I have some ASK9010 chassis that are getting upgraded fan trays from v1 to
v2. My question is to upgrade these, is it possible to pull one and replace
it and then pull the other and replace or will the system have issues with
mixed fan trays during that short period?

If it can't be swapped 1 at a time, will the chassis need to shutdown to
swap both or will the chassis continue to run for the 30 - 60 seconds it
takes to swap the new ones in?

Best,

-Lee
___
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/

--- End 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] ASR1002 -- interface stops passing IPv4 traffic?

2017-05-19 Thread Perrin Richardson 
I've hit this 

CSCva35619 so that matches up. Upgraded at the time to 03.16.04a extended 
support release. Worked perfectly! Forwarding correctly ever since 


Sent from my portable email sender
Please excuse shorter messages

> On 19/05/2017, at 21:09, Paul Sherratt  wrote:
> 
> Hi John,
> 
> This sounds like it may be an input queue wedge on the interface, which is
> only fixed with a reload.
> 
> I've seen CVE-2016-1478 / CSCva35619 hit a few people.  If you're running
> an affected version you'll need to upgrade or workaround.  To verify, check
> queue size in "show interface" output - if it's a queue wedge you can issue
> "show buffers old [dump]" to confirm it is indeed the NTP bug causing your
> issues.
> 
> https://bst.cloudapps.cisco.com/bugsearch/bug/CSCva35619
> 
> 
> Cheers,
> 
> Paul
> 
>> On 19 May 2017 at 05:43, John Osmon  wrote:
>> 
>> I've never found an IOS device I couldn't tame with the help of Usenet
>> and then google.  However, I'm new to the ASR1000 and IOS-XE, and I'm
>> running into something I've never seen before.
>> 
>> I've got GigE ports that will pass traffic, and then suddenly stop.
>> The interface still shows up/up, but you can't even ping the local
>> interface from the router itself.
>> 
>> We've can restore traffic by moving the config to another port, but the
>> "dead" port stays dead.  We've tried shut/no shut, new SFPs, and new
>> configs -- but the port still won't work.
>> 
>> Interestingly, the port *DOES* work with IPv6 -- but not IPv4.  This
>> router doesn't use IPv6, but when I put an address on the interface, it
>> is pingable.
>> 
>> If you apply an IPv4 /24 to the dead interface, the routing table shows
>> the /24 as a "connected" network, and shows a "local" /32 for the
>> address in use -- but is not pingable.
>> 
>> The only thing we've found in common between the ports is that they
>> were connected to eBGP peers.  We've had three events, on ports
>> connected to two different providers.
>> 
>> My next step is to get to the colo and move one of the "dead" ports to
>> a spanned port switch and start sniffing the line.
>> 
>> Any suggestions would be appreciated.  Hardware in use includes:
>>   ASR1000-ESP10
>>   ASR1002-RP1
>>   SPA-8X1GE-V2
>> 
>> Problem has occurred in both built-in and SPA-8X1GE-V2 ports, with
>> multi-mode, and GE-T transceivers.
>> 
>> ___
>> 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/