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

[Lukas Tribus]

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