show controller ethernet-controller phy

[Ruhtra]

Is there a cisco document that can help me identify closer the output of this command?  For example, if I use

Switch#show controller ethernet-controller tw1/0/8 phy

Tw1/0/8 (if_id: 16)
----------------------------------------------------

00e0 : 1140 Control Register : 0001 0001 0100 0000
00e1 : 796d Control Status : 0111 1001 0110 1101
00e2 : ae02 Phy(B:14B98) ID 1 : 1010 1110 0000 0010
00e3 : 5161 Phy(B:14B98) ID 2 : 0101 0001 0110 0001
000f : d203 Firmware Build Version : 1101 0010 0000 0011
00e4 : 9d81 Auto-Negotiation Advertisement : 1001 1101 1000 0001
00e5 : 41e1 Auto-Negotiation Link Partner : 0100 0001 1110 0001

Looking at register 00e5 (0005 on a G switch) I know that is telling me what the end device is advertising for auto-negotiation.

Specifically, I am dealing with a ton of inherited legacy field devices, and dealing with engineers that think it's okay to mix hard-coded and auto-negotiation.  I want to be able to tell engineers that their devices are advertising X, please let my change my switch to auto.  I can't just change it.  If for any reason I cause the field device to hiccup, could cause a loss of $$ product.  So has to be coordinated when there is no product being run.

The IEEE 802.3 Clause 28 is not directly accessible without a subscription for seeing what each of the bits in the 16-bit word indicate. for what the Link Partner is advertising for capabilities.    In the example above for 00e5, 41e1 support 10/100 Full/Half and is sending FLP pulses.  

It's like pulling teeth to get the engineers to let me change the switch from hard-coded 10-half to auto/auto.  I have the best practices and auto negotiation troubleshooting guides.  I am looking for the document that will let me show them "hey, your devices is advertising X.  Let me match the switch to eliminate the errors".

[Ruhtra]

I 'think" this is right based on searches.   But some of this is AI responses.  Which I don't trust.

• Bit 15: Next Page (to Gigabit/PoE capabilities)
• Bit 14: FLP pulses received
• Bit 13: Remote Fault
• Bit 12: Technology Ability Acknowledgement
• Bit 11: Asymmetric Pause
• Bit 10: Pause (Flow Control)
• Bit 9: 100Base-T4 (Rarely used)
• Bit 8: 100Base-TX Full Duplex
• Bit 7: 100Base-TX Half Duplex
• Bit 6: 10Base-T Full Duplex
• Bit 5: 10Base-T Half Duplex
• Bits 4-1: Message Type; Ethernet, IEEE 802.9, or Token Ring.  Should always be 00001

[balaji.bandi]

Not that I am aware. You may find a single document, since Cisco sources from different Chip vendors. Cisco may own some in the new models.

what is the use case you trying to investigate this low level information ?

[Ruhtra]

I want to be able to show the automation engineer that their equipment is advertising auto-negotiation and capabilities.

If I set my side to auto/auto, and doesn't receive FLP, then it will go to a-10 a-half.  I want to see the register and validate if it's 0000 which is no FLP, or 0021 which is FLP, but can only do 10-half, and etc.  Some of the engineers can be very "difficult" without showing them documentation.

[Ruhtra]

This isn't a one-time issue.  I have several hundred devices that have been hard-coded and have to work with dozens of different engineers for different product lines to negotiate making changes.  Just looking for more evidence to support my case.

[balaji.bandi]

What kind of model switch is this? Why do we think this is a switch-side issue? Would you happen to know how the other device connected to the switch port is configured?

We have seen many low-grade products fail to meet standards due to cost savings.

I am not saying cisco 100% great here.

[Ruhtra]

Let me re-phrase.  There is nothing wrong with the switch.  This is a configuration issue I inherited.  Many years ago (20+) the switch interfaces had to be hard coded because the field devices were not capable of auto-negotiation.  Over time, many field devices had been replaced without informing the network team.  Fast forward to today, we still have several hundred interfaces hard coded that shouldn't be.  The hard part is convincing the automation team to let me update the switch interface configuration to auto/auto.  In their mind it works, leave it alone.  

If that documentation doesn't exist, that's fine.  Was just asking.

[balaji.bandi]

I understand your problem. We had the same issue a while back, replacing 1000 switches in the largest site.

I have written a small Python script to collect all pre-change data for the switch. When the switch is replaced, we follow a process to ensure the MAC address or the new switch port-associated patch is replicated with the same configuration, if supported by the devices.

Example: I had an old server with 10MB, a Nexus 9K model that does not support it, and the vendor does not have an upgrade version.

We need to identify a lower-model alternative mechanism to make the patch work.

I can understand the pain of replacing with knowing the team is sad.

[Ruhtra]

Sorry, C9300 series, mix of C9300-48U and 48UXM.  48U where we are limited to 10Mb since 48UXM can't go below 100Mb, or where we have an old rack that a 48UXM wouldn't fit in.  This plant is only 75 years old. 🙂

[pieterh · Accepted solution]

this document describes the negotiation in detail
https://ieee802.org/3/ap/public/jul04/szczepanek_02_0704.pdf 
https://www.iol.unh.edu/sites/default/files/knowledgebase/ethernet/Copper_ANEG_JEFF_LAPAK.pdf  
I think section •Link Partner Base Page Ability contains the explanation of the bits you need

>>> Many years ago (20+) the switch interfaces had to be hard coded because the field devices were not capable of auto-negotiation.  <<<
=> Yes many of us have had that experience

>>>Over time, many field devices had been replaced without informing the network team.  Fast forward to today, we still have several hundred interfaces hard coded that shouldn't be. <<<
=> yes, my company has been there too, many devices have also advanced to100Mbit or 1Gbit interfaces
resulting in complaints of building automation team that their replaced devices do not communicate propperly.

>>> The hard part is convincing the automation team to let me update the switch interface configuration to auto/auto.  In their mind it works, leave it alone <<<
=> this can be VERY hard, because many times the hardware has been upgraded, but the network stack did not!!!
I have seen many network stacks that can only handle traffic at 10Mbit half duplex

So I totally understand your wish to detect if the device tries autonegotiation and present the "proof" to the corresponding team

[Ruhtra]

Yes, those documents help immensely, thank you.