Bug CSCvm57265 has happened to me. The ASR920 in question had its
OSPF/MPLS Router-ID on Lo0 (only loopback configured) and the TCL script
changed it into the MGMT VRF (from the GRT) when inserting a 10G optic
for the first time after enabling the license. Needless to say it took
the site down.
It only happen once, TAC told me they could not figure out the issue
unless I reproduce it.
On 8/26/2019 12:28 PM, Lukas Tribus wrote:
Hello Gert,
On Mon, 26 Aug 2019 at 14:47, Gert Doering <g...@greenie.muc.de> wrote:
Hi,
does anyone know what "EEM:Mandatory.dualrate_eem.tcl" is?
We have an ASR920 that grew an unexpected config change upon insertion
of a DAC cable into port ten0/0/12, and "unexpected config change" always
triggers an investigation here (who, why, what). One part of it was
somewhat related
interface TenGigabitEthernet0/0/12
description ...
no ip address
+ negotiation auto
service instance 200 ethernet
It seems to me dual-rate ports on the ASR920 are a bit of an
afterthought, which is why it needs integrated duct-tape EEM scripts
to work around code bugs. Because those EEM scripts are as fragile as
you would expect from your average "expect" style CLI scraping tool,
you get things like this:
CSCvb61075 Dual-rate EEM script expires: when the hostname has a dot
('.') character in it
CSCuz01963 "negotiation auto" changes to "no negotiation auto" under
the Tengig interface.
CSCvf97552 BDI ping failure will happen and dual rate EEM policy wont succeed
CSCuy55664 Dual-rate port SFP optics swap leads to egress forwarding issues
CSCvm21736 "negotiation auto" config gets removed from dual rate ports
post node Hard reset/Power cycle
CSCux89058 Negotiation auto - negated after OIR of 1G-SFP on Tengig
port in ASR920
CSCvf36147 'negotiation auto' command is not saved in startup configs
after reload in Striker-C
CSCur65014 ASR920:"No negotiation auto" config is not retained on reload
CSCuy55658 ASR920: Dual-rate port SFP optics swap leads to egress
forwarding issues
But my personal favorite is CSCvm57265:
Status: Open
Severity: 4 Minor
Symptom:
Higher numbered loopback configuration is changed and put into the MGMT VRF
automatically when SPF of dual rate interfaces of ASR920 is changed from SFP
(1GE) to SFP+ (10GE) or viceversa
Conditions:
ASR920 running version asr920igp-universalk9.03.18.04.SP.156-2.SP4-ext.
Dual rate interface up with SFP or SFP+ inserted.
SFP is changed either from SFP to SFP+ or SFP+ to SFP.
If there are several loopbacks configured on the device, the higher numbered
one will be changed and automatically put into the MGMT VRF erasing the rest of
the configuration. If only one loopback is configured, then that loopback will
be changed automatically.
Workaround:
If all loopbacks are used for communication or signalling, configure a temporal
loopback with a higher number that the rest. Only the higher loopback will get
changed:
Loopbacl10
Loopback20
Loopback40 --- This one will be changed
During the SFP change this temporal loopback will be changed but this will not
impact any service since this is only a dummy interface that can be erased
after the activity is complete.
You better put that Loopback40 in your templates ;)
cheers,
lukas
_______________________________________________
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/
