[c-nsp] ASR 920 Strange SFP behavior

[Shawn L]

I don't think this is due to switching between SFP and SFP+.  In this
particular case, the switch has never had any SFPs or SFP+ in it, it's
brand new.  Fire up, accept the license agreement, reload.  Install new
IOS, reload, provision, plug-in.  I also have one where the SFP+ in slots
8-11 work fine, but a SFP inserted into slots 0 or 1 doesn't come up and
still thinks it's 10 gig.  Also tried to set the speeds manually (speed
1000 for example) but it tells me the command isn't valid for the interface.

On Wed, Mar 18, 2020 at 9:44 AM Brian Turnbow <b.turnbow at twt.it> wrote:

> Hi Shawn,
>
> Are you by chance switching from sfp to sfp+ on the ports by chance?
> Because the 12sz launches scripts when changing speeds that basically
> default the config and rewrites it, but doesn't always work as planned..
> There was a discussion here about it a while back.
> https://puck.nether.net/pipermail/cisco-nsp/2019-August/106974.html
>
>
> Brian
>
> > -----Original Message-----
> > From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> > Shawn L
> > Sent: Wednesday, March 18, 2020 1:09 PM
> > To: Cisco Network Service Providers <cisco-nsp at puck.nether.net>
> > Subject: [c-nsp] ASR 920 Strange SFP behavior
> >
> > I have a group of 5 Cisco ASR-920-12SZ switches / routers that are all
> > exhibiting some strange behavior with respect to ports and SFPs.  This
> is the
> > new 12 port 10 gig device that just came out relatively recently.  I
> also have
> > some of the 920-12CZ and 4CZ that aren't having the issue.  Just
> wondering if
> > anyone else has seen this before or has any ideas.
> >
> > All the routers are running the same firmware -- 16.9.4.  I can take a
> working
> > SFP out of one switch (doesn't matter if it's Cisco branded or not) and
> insert it
> > in another, and it doesn't get recognized.  The port sometimes comes up,
> but
> > doesn't pass traffic.  The SFP is sometimes recognized, sometimes
> recognized
> > incorrectly (ie type is correct, speed is wrong).
> >
> > If I take that same SFP and put it back in the 'first' switch, it gets
> recognized
> > and comes right up.  When the SFP is unrecognized, or "partially"
> recognized
> > the list of available commands for the interface also changes.  IE
> 'negotiation
> > auto / no negotiate auto" is sometimes available, at other times it's an
> > unrecognized command.  I'm guessing that whether the commands are
> > available or not depend on what it thinks the SFP supports.
> >
> > Tried adding the 'transceiver permit pid all', but it didn't help.  The
> cisco
> > switch commands for unsupported transceivers (service unsupported-
> > transceiver/no errdisable detect cause gbic-invalid) don't appear to be
> > accepted.  I wonder if there's a different set of commands for this
> platform.
> >
> > At first (after confirming that I wasn't crazy) we thought it might be
> an issue
> > with licensing.... The licensing on them is rather strange.
> >
> > "If no pluggable is present in the router at bootup, then any six ports
> can be
> > used as default licenses (6x10G + 6x1G = 66G). However, if 10G
> pluggables are
> > present in all the ports of router at bootup, then the first six port
> are marked
> > for default licenses. The remaining ports can be used as licensed ports."
> >
> > But after checking, we have the same licenses on all of the boxes.  We've
> > opened a TAC case about the issue, but haven't really gotten anywhere
> with it
> > as of yet.
> >
> > Shawn
> > _______________________________________________
> > 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/
>