I am running into the bug :
3850: Remove CLIs used to configure GRE tunnel - may cause crash.
The fix for this is in 15.0(13.65)EZD.
I have the following IOS-XE :
* 1 56 WS-C3850-48T 03.03.03SE cat3k_caa-universalk9 INSTALL
Which has IOSd:
Package: IOS, version: 150-1.EZ3, status: active
File: cat3k_caa-iosd-universalk9.SPA.150-1.EZ3.pkg, on: Switch1
How can I upgrade to the bug fix as we are already running the latest IOS-XE, is it possible to just upgrade the IOSd pkg, and how do I go about this?
Also, what do the letters at the end of the file represent, ie 150-1.EZ3 and 15.0(13.65)EZD?
Thanks in advance.
GRE tunnels are not supported on 3850 platform. Officially the stand is that we do not support GRE on any 3K platforms including 3850 as yet.
In future IOS releases attempts are being made to remove the tunnel related CLIs.
Thank You Inayath.
Regarding my other query, is it possible to just update a pkg file on a IOS-XE, and how can I do this if I needed to just upgrade the IOSd and nothing else, or is it that upgrades can only be done via the IOS-XE bundles?
Thanks Inayath, I had already seen that link and it does not answer my query, it references updating the IOS-XE as a bundle, I am wanting to only upgrade a single pkg.
As an example, 3.3.3 is the latest IOS-XE, and within that the IOSd is 15.01, what if I only wanted to upgrade the IOSd pkg 15.01 to the latest IOSd?
This is not good and will now stop a roll-out of a project that was going to use this feature according to the following document that states it IS supported..
When will this bug get FULLY corrected? or do I need to open a TAC case to get it resolved?
It says "Fixed" in the above bug.. but it's not.. So this is a lie.. its not fixed..
Cisco needs to fix this..
A TAC Case has been opened... Let's hope it's something that will allow layer three transport to be used for traffic isolation like the GRE was going to provide.
A s said earlier, I dont think that the feature of this would be added on this box .
Anyways you can get some help/confirmation on the TAC case.
Well according to the link I posted, it's an advertised feature that is available in a technical doc which most engineers will use since the feature finder for XE-IOS and the others is pretty useless in find what you are looking for...
If it was planned to have GRE as the original link suggested, then they need to fix the IOS to support this function..
This bug is "fixed" - the fix is removing the ability to configure this. When this switch first went live, we had the ability to enable this feature, however it should have never been possible. When enabled, it was completely run in software and in turn essentially DOS'ing the box.
EZ3 is maintenance release 3 - disregard 15.0(13.65)EZD.
"is it possible to just update a pkg file on a IOS-XE" ?? NO
I don't agree with your "fixed by removing function" for it was widely published that this feature was available.
Why was it even documented in the first place that it would work and that there were a list of commands and options?
So it's not "Fixed" .. It's still broken.. It's just being hidden from view, command line and trying to be swept underneath the rug, cause it causes issues and apparently at this juncture Cisco doesn't feel they need to correct this bug or root cause..
We understand your situation and totally respect your thought on this. I will see if I can write an email to the document team to have this feature removed further so that there is no more confusion.
Having read the details of the bug the plan is to have the tunnel cmd removed at the first place and ther would be no fix. One more thing which I would like to inform is that though they fix the bug still its recommended on the internal notes to not use this feature.
Sorry for inconvienence.
I'm very interested in this topic because we were using tunnel interfaces for verifying the availability of our leased lines - we don't have visibility to the WAN Equipment (Service Provider) and that was the best method to verify if our Lines are available - if a line was interrupted, the tunnel went down and we got a message via SNMP.
What would be an appropriate alternative for this functionality and how to realize?