Mailing List Archive

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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ASR 920 Strange SFP behavior [ In reply to ]
_______________________________________________
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/
Re: ASR 920 Strange SFP behavior [ In reply to ]
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@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@puck.nether.net] On Behalf Of
> > Shawn L
> > Sent: Wednesday, March 18, 2020 1:09 PM
> > To: Cisco Network Service Providers <cisco-nsp@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@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/
Re: ASR 920 Strange SFP behavior [ In reply to ]
Hi Shawn,

on ASR920-12CZ we found that the safest way is to perform a reload if
you change a module from 1G to 10G or vice-versa.

Same "solution" may applies to your ASR920-12SZ as well.

IOS-XE starts a TCL script for speed reconfiguration, but the script
sometimes fails to run properly, in some version is missing, or fails to
do the job.

You will find in the list archive some funny discussions about
Mandatory.dualrate_eem.tcl :D


--
Best regards,
Adrian Minta



_______________________________________________
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/
Re: ASR 920 Strange SFP behavior [ In reply to ]
>  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.

In my experience, expect it to happen in both of these scenarios. Also,
if you have external authentication configured on your device, that's a
good way to have the script fail execution as well, unless you've
created some arbitrary priv15 account on your auth server.

Dual rate ports on this box need to be handled with care and patience.
Switching optics around rapidly (measured in minutes), or expecting
immediately accurate link lights are good ways to get bitten. A reload
*with optics inserted* should resolve it, but that takes its sweet time too.

Some bedtime reading... I mean, nightmare fuel:
https://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/chassis/b_Chassis_Guide_xe-16-5-asr920/using-dual-rate-port.pdf


Cheers

David




On 18/03/2020 23:47, Shawn L wrote:
> 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@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@puck.nether.net] On Behalf Of
>>> Shawn L
>>> Sent: Wednesday, March 18, 2020 1:09 PM
>>> To: Cisco Network Service Providers <cisco-nsp@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@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/
>
_______________________________________________
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/
Re: ASR 920 Strange SFP behavior [ In reply to ]
That's interesting. After reading David's reply, I rebooted one of the
920s that has been having issues and went to bed (no important traffic on
it yet). This morning -- the interfaces it couldn't identify yesterday (or
several days before that) are now all correctly identified.

I'll have to go to the site and check to see if they will come up when I
attach something to them, but at least now they're identified correctly.
There's been at least one reboot of the system -- I configured it, then
drove it to the site and installed it. So maybe it needs 2 reboots to
work? This will be an interesting update to the TAC case "rebooted <again>
and now it appears to work".

I'm not sure at this point that this is a platform we want to deploy.
We've had fine luck with the 12CZ and the 4SZ, but the 12SZ seem to still
have some issues they need to work out.

Any other boxes with similar features that people are using instead? MPLS,
a mix of 1 and 10 gig, DC power.

Shawn

On Wed, Mar 18, 2020 at 9:32 PM David H <c-nsp@af41.net> wrote:

> > 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.
>
> In my experience, expect it to happen in both of these scenarios. Also,
> if you have external authentication configured on your device, that's a
> good way to have the script fail execution as well, unless you've
> created some arbitrary priv15 account on your auth server.
>
> Dual rate ports on this box need to be handled with care and patience.
> Switching optics around rapidly (measured in minutes), or expecting
> immediately accurate link lights are good ways to get bitten. A reload
> *with optics inserted* should resolve it, but that takes its sweet time
> too.
>
> Some bedtime reading... I mean, nightmare fuel:
>
> https://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/chassis/b_Chassis_Guide_xe-16-5-asr920/using-dual-rate-port.pdf
>
>
> Cheers
>
> David
>
>
>
>
> On 18/03/2020 23:47, Shawn L wrote:
> > 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@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@puck.nether.net] On Behalf
> Of
> >>> Shawn L
> >>> Sent: Wednesday, March 18, 2020 1:09 PM
> >>> To: Cisco Network Service Providers <cisco-nsp@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@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/
> >
> _______________________________________________
> 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/
Re: ASR 920 Strange SFP behavior [ In reply to ]
Just an update one this. We switched several units to 16.12.3 and things
seem to be better. Still waiting on TAC, they want to open a separate case
on each unit, and analyze the far end. They've also indicated that all of
the issues with switching SPF for SFP+ should be fixed in 16.9.4, or a
previous release. But that doesn't seem to be the case. So far 16.12.3
has recognized all the SFP and SFP+ that we've thrown at it, including
after-market (guaranteed cisco compatible). We're still testing, but
things look a lot more promising now.


On Fri, Mar 20, 2020 at 5:44 AM Philip Olsson <philip@teleservice.net>
wrote:

> Cisco NCS540, I'm currently deploying it and depending on what you expect,
> it can be 'meh'. Replacement for asr9k PE , it is not. Maybe for 7600's..
> But for just basic services and ports it seems to work out fine.
>
> Or you could look at the Juniper MX204 - not that much more than the
> NCS540 and people seem really happy with it.
>
> Mvh
> Philip
>
> > -----Ursprungligt meddelande-----
> > Från: cisco-nsp [mailto:cisco-nsp-bounces@puck.nether.net] För Shawn L
> > Skickat: den 19 mars 2020 13:35
> > Till: Cisco Network Service Providers <cisco-nsp@puck.nether.net>
> > Ämne: Re: [c-nsp] ASR 920 Strange SFP behavior
> >
> > That's interesting. After reading David's reply, I rebooted one of the
> 920s that
> > has been having issues and went to bed (no important traffic on it
> yet). This
> > morning -- the interfaces it couldn't identify yesterday (or several
> days before
> > that) are now all correctly identified.
> >
> > I'll have to go to the site and check to see if they will come up when I
> attach
> > something to them, but at least now they're identified correctly.
> > There's been at least one reboot of the system -- I configured it, then
> drove it
> > to the site and installed it. So maybe it needs 2 reboots to work? This
> will be
> > an interesting update to the TAC case "rebooted <again> and now it
> appears
> > to work".
> >
> > I'm not sure at this point that this is a platform we want to deploy.
> > We've had fine luck with the 12CZ and the 4SZ, but the 12SZ seem to
> still have
> > some issues they need to work out.
> >
> > Any other boxes with similar features that people are using instead?
> MPLS, a
> > mix of 1 and 10 gig, DC power.
> >
> > Shawn
> >
> > On Wed, Mar 18, 2020 at 9:32 PM David H <c-nsp@af41.net> wrote:
> >
> > > > 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.
> > >
> > > In my experience, expect it to happen in both of these scenarios.
> > > Also, if you have external authentication configured on your device,
> > > that's a good way to have the script fail execution as well, unless
> > > you've created some arbitrary priv15 account on your auth server.
> > >
> > > Dual rate ports on this box need to be handled with care and patience.
> > > Switching optics around rapidly (measured in minutes), or expecting
> > > immediately accurate link lights are good ways to get bitten. A reload
> > > *with optics inserted* should resolve it, but that takes its sweet
> > > time too.
> > >
> > > Some bedtime reading... I mean, nightmare fuel:
> > >
> > > https://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/gui
> > > de/chassis/b_Chassis_Guide_xe-16-5-asr920/using-dual-rate-port.pdf
> > >
> > >
> > > Cheers
> > >
> > > David
> > >
> > >
> > >
> > >
> > > On 18/03/2020 23:47, Shawn L wrote:
> > > > 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@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@puck.nether.net] On
> > > >>> Behalf
> > > Of
> > > >>> Shawn L
> > > >>> Sent: Wednesday, March 18, 2020 1:09 PM
> > > >>> To: Cisco Network Service Providers <cisco-nsp@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@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/
> > > >
> > > _______________________________________________
> > > 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/
>
_______________________________________________
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/