[c-nsp] ASR920 and EEM:Mandatory.dualrate_eem.tcl

[Andrew K.]

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 <gert at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>