Re: [c-nsp] How can one escalate within Cisco TAC?

[Eli Kagan via cisco-nsp]

 Hi Hank,I had similar experience with Cisco TAC in the past. I managed to 
escalate it via my Cisco account rep. That landed the case on the desk of 
someone who actually knows a thing or two and we were able to at least have an 
intelligent conversation about the issue. 
Realistically though, I understand that Cisco is not going to fix my issues 
anytime soon so I just learnt to live with it.
-- ek





On Wednesday, February 8, 2023 at 02:48:50 AM EST, Hank Nussbacher via 
cisco-nsp  wrote:  
 
 We opened a case on Jan 22 (Case #694936467).  Since then we have 
exchanged countless email, countless logs and countless command output 
captures.


On Jan 31 we requested transfer to a more senior IOS-XR team. The case 
was transferred to Mexico TAC on Jan 31 and was assigned an engineer, 
yet after 9 days we have not heard from anyone inside Cisco TAC.  The 
case is listed as moderate - we requested that the case be moved to 
Amsterdam on Feb 5 and as of today no Cisco engineer is assigned to the 
case, no engineer manager is listed and it would appear that after 9 
days in TAC limbo, no one wants to touch this TAC case since they have 
run out of ideas of how to solve it.


So how does one escalate such an issue within TAC?  Is there some secret 
email like escalati...@cisco.com or vp-...@cisco.com that one can contact?


Thanks,

Hank

___
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] Cisco Cat4500 Quad Sup VSS ISSU IOS Upgrade

[Eli Kagan via cisco-nsp]

--- Begin Message ---
Thanks! I would really appreciate it! I am running 3.8.8e right now. Most 
likely going to 3.8.10e or 3.11.3ae


-- ek 
 
  On Sat., 13 Mar. 2021 at 7:52 p.m., Garrett Skjelstad 
wrote:   I'm not sure. Can you tell me the version you're currently working 
with and trying to move to? I'll try and carve out some time next week and try 
it for you, if you'd like.
I'm not sure if ISSU unlocks some compatibility for differing versions to work 
with VSS, or if it will take a version match with ISSU compatible versions 
without grumpy catting.
Obviously it won't tell you if services continue to work gracefully, but I can 
least tell you if it pairs and returns to # successfully.
-Garrett
On Fri, Mar 12, 2021 at 7:16 PM Eli Kagan  wrote:

Thanks Garrett!

Unfortunately I cannot afford a 30 minutes outage.

What doesn't make sense to me is the "issu loadversion" step. If I understand 
correctly, it would load the current hot standby with the new version. But 
wouldn't a cold standby take over if I reloaded the hot standby CPU, 
effectively bringing me back to the same state?

Is there a reason why I shouldn't do the upgrade the old fashion way? That is, 
change the boot variable, reload hot standby manually, failover and then reload 
the other three supervisor engines. 
I mean, is there a benefit to using "issu 
loadverion/runversion/acceptversion/commitversion" process vs just loading the 
software and reloading manually?

Thanks,
Eli 






On Friday, March 12, 2021, 04:08:25 PM EST, Garrett Skjelstad 
 wrote: 





I know this is an awful answer, but just don't do ISSU on them. 

Most of my experiences come from quad Sup8s in the same chassis. We have been 
running 3.11.1 for the past 49 weeks, since our last cycle, which is 12/18 
months.

The biggest ISSUe (lol) with it, is just the sheer number of jumps back and 
forth as you climb the ISSU ladder from a historic release. We have also found 
it to be beneficial to do a pre-ISSU supervisor restarts for each supervisor 
prior to actually doing the upgrade so as to lessen the chance of getting 
'stuck' in a ISSU-loop with a hung Supervisor. The fact that 4500 sups sit in a 
'cold' mode when doing the jumps just adds to the delay, 6500s/6800s are MUCH 
nicer for this action in the fact they are 'warm(hot?)' and already booted.

A full cold restart of the shelves takes approximately 23 minutes per our lab 
units. We have found in some locations that have tolerable maintenance windows, 
to load/prep and simply cold start the shelves, instead of a weeklong of ISSU 
maintenance windows. Of course, if you patch every 60-120 days as the cadence 
of each release, perhaps it's more manageable. I read there are some additional 
protections and time optimizations in later rommon versions, but for our use, 
we just haven't seen the need for a seperate out of cycle ROMMON patches. We 
are currently looking at simply replacing them with Catalyst 9k models.

The 4500-Xs run the same supervisor set and are just as friendly, although 
contending with only duals vs quads.

Obviously out-of-band management on all supervisors is a necessity.

YMMV, good luck!
-Garrett

On Fri, Mar 12, 2021 at 12:27 PM Eli Kagan via cisco-nsp 
 wrote:
> 
> 
> 
> -- Forwarded message --
> From: Eli Kagan 
> To: "cisco-nsp@puck.nether.net" 
> Cc: 
> Bcc: 
> Date: Fri, 12 Mar 2021 20:25:01 + (UTC)
> Subject: Cisco Cat4500 Quad Sup VSS ISSU IOS Upgrade
> Hi all,
> 
> I have a rather old Cat4507R+E pair, running on four Sup7e as a VSS, IOS-XE 
> version 3.8.8E.
> 
> I'd like to understand what's the right way of doing an ISSU on a quad sup 
> system. I am planing to go to version 3.8.10E unless someone has a better 
> suggestion.
>  
> Sharing your first hand experience would be greatly appreciated.
>  
> Thanks,
> Eli
> 
> 
> 
> -- Forwarded message --
> From: Eli Kagan via cisco-nsp 
> To: "cisco-nsp@puck.nether.net" 
> Cc: 
> Bcc: 
> Date: Fri, 12 Mar 2021 20:25:01 + (UTC)
> Subject: [c-nsp] Cisco Cat4500 Quad Sup VSS ISSU IOS Upgrade
> 
> ___
> 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] Cisco Cat4500 Quad Sup VSS ISSU IOS Upgrade

[Eli Kagan via cisco-nsp]

--- Begin Message ---
Thanks Garrett!

Unfortunately I cannot afford a 30 minutes outage.

What doesn't make sense to me is the "issu loadversion" step. If I understand 
correctly, it would load the current hot standby with the new version. But 
wouldn't a cold standby take over if I reloaded the hot standby CPU, 
effectively bringing me back to the same state?

Is there a reason why I shouldn't do the upgrade the old fashion way? That is, 
change the boot variable, reload hot standby manually, failover and then reload 
the other three supervisor engines. 
I mean, is there a benefit to using "issu 
loadverion/runversion/acceptversion/commitversion" process vs just loading the 
software and reloading manually?

Thanks,
Eli 






On Friday, March 12, 2021, 04:08:25 PM EST, Garrett Skjelstad 
 wrote: 





I know this is an awful answer, but just don't do ISSU on them. 

Most of my experiences come from quad Sup8s in the same chassis. We have been 
running 3.11.1 for the past 49 weeks, since our last cycle, which is 12/18 
months.

The biggest ISSUe (lol) with it, is just the sheer number of jumps back and 
forth as you climb the ISSU ladder from a historic release. We have also found 
it to be beneficial to do a pre-ISSU supervisor restarts for each supervisor 
prior to actually doing the upgrade so as to lessen the chance of getting 
'stuck' in a ISSU-loop with a hung Supervisor. The fact that 4500 sups sit in a 
'cold' mode when doing the jumps just adds to the delay, 6500s/6800s are MUCH 
nicer for this action in the fact they are 'warm(hot?)' and already booted.

A full cold restart of the shelves takes approximately 23 minutes per our lab 
units. We have found in some locations that have tolerable maintenance windows, 
to load/prep and simply cold start the shelves, instead of a weeklong of ISSU 
maintenance windows. Of course, if you patch every 60-120 days as the cadence 
of each release, perhaps it's more manageable. I read there are some additional 
protections and time optimizations in later rommon versions, but for our use, 
we just haven't seen the need for a seperate out of cycle ROMMON patches. We 
are currently looking at simply replacing them with Catalyst 9k models.

The 4500-Xs run the same supervisor set and are just as friendly, although 
contending with only duals vs quads.

Obviously out-of-band management on all supervisors is a necessity.

YMMV, good luck!
-Garrett

On Fri, Mar 12, 2021 at 12:27 PM Eli Kagan via cisco-nsp 
 wrote:
> 
> 
> 
> -- Forwarded message --
> From: Eli Kagan 
> To: "cisco-nsp@puck.nether.net" 
> Cc: 
> Bcc: 
> Date: Fri, 12 Mar 2021 20:25:01 + (UTC)
> Subject: Cisco Cat4500 Quad Sup VSS ISSU IOS Upgrade
> Hi all,
> 
> I have a rather old Cat4507R+E pair, running on four Sup7e as a VSS, IOS-XE 
> version 3.8.8E.
> 
> I'd like to understand what's the right way of doing an ISSU on a quad sup 
> system. I am planing to go to version 3.8.10E unless someone has a better 
> suggestion.
>  
> Sharing your first hand experience would be greatly appreciated.
>  
> Thanks,
> Eli
> 
> 
> 
> -- Forwarded message --
> From: Eli Kagan via cisco-nsp 
> To: "cisco-nsp@puck.nether.net" 
> Cc: 
> Bcc: 
> Date: Fri, 12 Mar 2021 20:25:01 + (UTC)
> Subject: [c-nsp] Cisco Cat4500 Quad Sup VSS ISSU IOS Upgrade
> 
> ___
> 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/

[c-nsp] Cisco Cat4500 Quad Sup VSS ISSU IOS Upgrade

[Eli Kagan via cisco-nsp]

--- Begin Message ---
Hi all,

I have a rather old Cat4507R+E pair, running on four Sup7e as a VSS, IOS-XE 
version 3.8.8E.

I'd like to understand what's the right way of doing an ISSU on a quad sup 
system. I am planing to go to version 3.8.10E unless someone has a better 
suggestion.
 
Sharing your first hand experience would be greatly appreciated.
 
Thanks,
Eli
--- 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/

[c-nsp] cat6800 sup6T

[Eli Kagan via cisco-nsp]

--- Begin Message ---
A follow up on my earlier email.
I would appreciate if you could share your real life experience running cat6800 
on sup6T.
Is the code stable enough? Any peculiar quirks to the hardware?  Any experience 
out there running quad sup VSS?
Thanks again,Eli

 Forwarded message --

From: Eli Kagan 
To: Cisco Network Service Providers 
Cc: 
Bcc: 
Date: Sat, 7 Jul 2018 22:51:07 + (UTC)
Subject: choosing a switch cat6500 vs cat6800
Hi everybody,


Need your opinion on choosing a switch for an upgrade. I got a bunch of cat4507 
sup7-e running right now thatneed to be replaced very soon.  I can’tseem to 
pick the right platform to replace it with. Cisco is being as confusing as 
always.
My requirements are pretty bland. The switch has to be highly reliable (banking 
environment), mature code and hardware. Should not end up with no more software 
updates in the next 5 years (PCI compliance). Should do VRFs, MACsec, VPC or 
VSS (quad sup VSS is better). No 10Gig is required as of today.
My options so far:1.   Cat6807, sup6T  -- would be my first choice but 
other techies have no experience with it and are reluctant to agree.

2.   Cat6506-E.  sup2T  --  7 years old, perhaps will be EoL shortly 
otherwise will do.
3.   Cat4507R+E, sup9 -- good on paper but I had too manyhardware and 
software issues with the existing cat4500 for me to be comfortablewith this 
option. On top of that, Cisco is “encouraging” to go to Cat9400instead 
4.   Cat9400 7-slot  --  I know nothing about that thing. Does it support 
quad sup VSS or similar? Is it too cutting edge for a financial client? Is the 
code stable enough?


5.   Nexus 7700 6-slot   or    Nexus 9504   --  both are expensive ashell.
Any insight would be highlyappreciated.

 

 
Thanks,

Eli


 

 

 

 

 



-- Forwarded message --
From: Eli Kagan via cisco-nsp 
To: Cisco Network Service Providers 
Cc: 
Bcc: 
Date: Sat, 7 Jul 2018 22:51:07 + (UTC)
Subject: [c-nsp] choosing a switch cat6500 vs cat6800
___
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/

-- 

--
Hunter Fuller
Network Engineer
VBH Annex B-5
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Systems and Infrastructure

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

[c-nsp] choosing a switch.... cat6500 vs cat6800

[Eli Kagan via cisco-nsp]

--- Begin Message ---
Hi everybody,


Need your opinion on choosing a switch for an upgrade. I got a bunch of cat4507 
sup7-e running right now thatneed to be replaced very soon.  I can’tseem to 
pick the right platform to replace it with. Cisco is being as confusing as 
always.
My requirements are pretty bland. The switch has to be highly reliable (banking 
environment), mature code and hardware. Should not end up with no more software 
updates in the next 5 years (PCI compliance). Should do VRFs, MACsec, VPC or 
VSS (quad sup VSS is better). No 10Gig is required as of today.
My options so far:1.   Cat6807, sup6T  -- would be my first choice but 
other techies have no experience with it and are reluctant to agree.

2.   Cat6506-E.  sup2T  --  7 years old, perhaps will be EoL shortly 
otherwise will do.
3.   Cat4507R+E, sup9 -- good on paper but I had too manyhardware and 
software issues with the existing cat4500 for me to be comfortablewith this 
option. On top of that, Cisco is “encouraging” to go to Cat9400instead 
4.   Cat9400 7-slot  --  I know nothing about that thing. Does it support 
quad sup VSS or similar? Is it too cutting edge for a financial client? Is the 
code stable enough?


5.   Nexus 7700 6-slot   or    Nexus 9504   --  both are expensive ashell.
Any insight would be highlyappreciated.

 

 
Thanks,

Eli


 

 

 

 

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

[c-nsp] etherchannel and macsec combination

[Eli Kagan via cisco-nsp]

--- Begin Message ---
Hi there,Can someone please confirm whether it is possible to create a 
port-channel trunk from MACsec encrypted ports on 4507R+E Sup 7-E or 8-E uplink 
ports and/or on any optical linecards (WS-X4712-SFP+E, WS-X4724-SFP-E)?Do any 
other switches support this MACsec/EtherChannel combination?Thanks,Eli--- 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] OT: support services

[Eli Kagan via cisco-nsp]

--- Begin Message ---
I have been buying this kind of service from Dimension Data. It was half the 
price of Cisco's offering. However, it was fully backed by a real Cisco 
contract so there was no issue with getting support trough TAC or with software 
updates.
-- ek

  From: Charles Sprickman via cisco-nsp 
 To: Cisco Network Service Providers  
 Sent: Saturday, August 5, 2017 2:29 PM
 Subject: [c-nsp] OT: support services
   
Hi all,

This is 100% cisco-specific, but not technical.

I’m finding lots of vendors offering their own version of support programs, 
many of which are competitively-priced and backed with really well-stocked part 
bins.  Of course they cannot offer software.

We’ve had one of our office folks calling Cisco for the last few days to try 
and get some pricing/part #s for software-only support.  Then it occurred to me 
that a very cisco-like move when competitors start offering support would be to 
drop the software-only option, forcing customers that want legit software back 
to Cisco.  Am I wrong?  Specifically, looking for software-only for ASR-1002X 
(and relevant to that other thread going on, yes 16GB, yes even with dual IOS 
running have room for multiple v4/v6 bgp feeds).

Ideally I’d like to buy the software support online without screwing around 
with a sales team.

Thanks,

Charles
-- 
Charles Sprickman
NetEng/SysAdmin
Bway.net - New York's Best Internet www.bway.net
sp...@bway.net - 212.982.9800



___
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] Tabo Topic? Third party Maintenance

[Eli Kagan via cisco-nsp]

--- Begin Message ---
Not sure whether this is helping or not Rick, but I have used Dimension Data 
maintenance before. They would sell you a straight SmartNet contract or their 
own in-house maintenance, which might or might not be backed by Cisco. I bought 
the former for less common equipment like large switches as it was cheaper than 
their in-house contracts. I bought their in-house maintenance for anything 
smallish as it was half the price of Cisco's. As for most common parts like 
switches, I kept spares on site wherever possible and do without a maintenance. 
This might not work for you if you are under compliance regulations that 
require such contracts. As for their service, I had no complaints but no 
praises either. It works, but you need to keep in mind that you are dealing 
with a huge company.



Cheers,Eli

  From: Rick Martin 
 To: "cisco-nsp@puck.nether.net"  
 Sent: Monday, January 23, 2017 12:16 PM
 Subject: [c-nsp] Tabo Topic? Third party Maintenance
  

I am under pressure to consider third party maintenance providers for our 
significant Cisco inventory, and I am quite leery of such an arrangement.  I 
suppose third party maintenance may be OK for products that we have plenty of 
spare inventory for such as customer edge routers or switches but the bigger 
core, aggregation or data center devices that provide critical services I have 
great concern. Our normal policy is to keep OEM maintenance in the following 
order;

1. Critical Devices which includes core routing, aggregation devices, data 
center hardware and larger building routers - 24X7X4 hour RMA (Smartnet Premium)
2. Customer edge devices - 8X5XNBD (Smartnet)

That methodology applies to Cisco and Juniper hardware. 

So my question is - do any of you that have larger enterprise or service 
provider networks currently utilize third party (Non OEM) maintenance 
contracts? If so what has been your experience with them? Or do you stick 
strictly to OEM maintenance?

Thanks in advance for any input.

Rick Martin
Network Architect
State of Arkansas, Department of Information Systems
(501) 682-4037

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

[c-nsp] virtual router on a cat4500

[Eli Kagan via cisco-nsp]

--- Begin Message ---
Hi all,I need community feedback about carving a virtual router instance out of 
Cat4507r+e Sup7-e. Let me explain. I have a pair of said Cat4507 running as 
distribution switches. I need to add two new routers to terminate MPLS VPN 
connection. Currently this connection terminates on a firewall, which is not 
ideal and I would like to change it. Hence, two new routers. And then I 
thought, why not create a vrf on the catalyst and use it as my CE. All I need 
is two interfaces, BGP and OSPF. So physically I would still have same Cat4507 
but logically it would be   [L3 distribution] --- [ firewall ] --- [ mpls ce 
]where distribution is the default VRF on the Cat4507 and CE is the new VRF on 
the same Catalyst.Any reasons why I should not do it?One concern I have is 
running OSPF between these two VRFs.Any insight would be greatly 
appreciated.Thanks,Eli--- 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/