Cloud Managed Networks

Hi All.

When doing WiFi in New Central I find it a little annoying that you cannot get to a "healthy green state" on AP syncronization. By default even the most basic profiles such as the default certificate deployment, setting an admin password or using security policies with roles, all has settings that are not supported by the APs, and thus cannot synchronize fully.

That seems like terrible UI design since most management cares about a "green health state" + it makes one insensitive about actual issues.

Fx. all APs will throw the below limitations on a basic sync in my setup:
They all stem from a basic filter Policy on roles, setting a password on the device and the default certificate push to APs. But You cannot find further details about what the issue is - there is nothing in the audit logs to suggest the actual settings it does not support, and the policies all do work on the AP.

It would be helpful to have specific situations, example - a 9004 BGW device GE 0/0/0 has a poe command removed, but the command is not valid on a 9004.

There are a number of fixes tentatively targeted for the next releases, a few highlights: certificates, CX switch port profiles.

If there is a message that cannot be reasonably explained, a support case would be helpful with the details of the device config and the error message.

Hi All.

When doing WiFi in New Central I find it a little annoying that you cannot get to a "healthy green state" on AP syncronization. By default even the most basic profiles such as the default certificate deployment, setting an admin password or using security policies with roles, all has settings that are not supported by the APs, and thus cannot synchronize fully.

That seems like terrible UI design since most management cares about a "green health state" + it makes one insensitive about actual issues.

Fx. all APs will throw the below limitations on a basic sync in my setup:
They all stem from a basic filter Policy on roles, setting a password on the device and the default certificate push to APs. But You cannot find further details about what the issue is - there is nothing in the audit logs to suggest the actual settings it does not support, and the policies all do work on the AP.

Yeah I agree - a ticket would be the right thing to do, but support does not feel the same.

There is no contact with engineering thru support for extending functionality when its not currently present.
 So all you do is spend dusins of hours having to persuade and re-gather ludicrous amounts of logs and dumps of the same thing on a piece of hardware that is not even relevant, since it's the Central UI that is missing features. The various escalation engineers all start from scratch every time and all think they are into the ticket even though they clearly have not read or understood the details. So I have given up on the ticket approach. I have opened at least 15 tickets on basic missing features - asking for workarounds - that renders New Central no-go for my customers. None has had the slightest interest of the even the 4th or 5th level escalation engineer - they just all end up telling me to wait and hope the feature will be supported some day. Incidentally, that's also why I'm now posting my findings on this forum instead.

It would be helpful to have specific situations, example - a 9004 BGW device GE 0/0/0 has a poe command removed, but the command is not valid on a 9004.

There are a number of fixes tentatively targeted for the next releases, a few highlights: certificates, CX switch port profiles.

If there is a message that cannot be reasonably explained, a support case would be helpful with the details of the device config and the error message.

Hi All.

When doing WiFi in New Central I find it a little annoying that you cannot get to a "healthy green state" on AP syncronization. By default even the most basic profiles such as the default certificate deployment, setting an admin password or using security policies with roles, all has settings that are not supported by the APs, and thus cannot synchronize fully.

That seems like terrible UI design since most management cares about a "green health state" + it makes one insensitive about actual issues.

Fx. all APs will throw the below limitations on a basic sync in my setup:
They all stem from a basic filter Policy on roles, setting a password on the device and the default certificate push to APs. But You cannot find further details about what the issue is - there is nothing in the audit logs to suggest the actual settings it does not support, and the policies all do work on the AP.

Hi All.

When doing WiFi in New Central I find it a little annoying that you cannot get to a "healthy green state" on AP syncronization. By default even the most basic profiles such as the default certificate deployment, setting an admin password or using security policies with roles, all has settings that are not supported by the APs, and thus cannot synchronize fully.

That seems like terrible UI design since most management cares about a "green health state" + it makes one insensitive about actual issues.

Fx. all APs will throw the below limitations on a basic sync in my setup:
They all stem from a basic filter Policy on roles, setting a password on the device and the default certificate push to APs. But You cannot find further details about what the issue is - there is nothing in the audit logs to suggest the actual settings it does not support, and the policies all do work on the AP.

-------------------------------------------

------------------------------
Marcel Koedijk | MVP Expert 2025 | ACEP | ACMP | ACCP | ACDP | Ekahau ECSE | Not an HPE Employee | Opinions are my own

Original Message:
Sent: Feb 10, 2026 06:25 AM
From: Keyser
Subject: Missing deeper reasons for "Syncronized with limitations" in New Central

Hi All.

When doing WiFi in New Central I find it a little annoying that you cannot get to a "healthy green state" on AP syncronization. By default even the most basic profiles such as the default certificate deployment, setting an admin password or using security policies with roles, all has settings that are not supported by the APs, and thus cannot synchronize fully.

That seems like terrible UI design since most management cares about a "green health state" + it makes one insensitive about actual issues.

Fx. all APs will throw the below limitations on a basic sync in my setup:
They all stem from a basic filter Policy on roles, setting a password on the device and the default certificate push to APs. But You cannot find further details about what the issue is - there is nothing in the audit logs to suggest the actual settings it does not support, and the policies all do work on the AP.

-------------------------------------------

.. am trying to answer all of your concerns in this reply:

Hi folks,

... wanted to provide a transparent update regarding the frustrations shared in this thread. We have been tracking the feedback from @Keyser, @sadams, @codye, and @mkk regarding the "Synchronized with Limitations" status in New Central and specific interface errors.

Based on your input, our engineering teams have prioritized two major fixes:

1. Solving the "Green State" & Dashboard Noise (Addressing @Keyser and @mkk)

@Keyser, you mentioned it's "terrible UI design" to be stuck in a yellow state for basic profiles, and @mkk, we agree that it's nearly impossible to explain a "non-green" dashboard to an end customer when the device is actually working fine.

• The Fix (CNX-212181): We are officially removing "Synchronized with Limitations" as a standalone health state.

• The Result: Moving forward, if a device has "capability-filtered" settings (like the default certificates or roles @Keyser highlighted), the device will now show as Synchronized (Green).

• Visibility: Those filtered items will move to an informational view within the device details so they don't clutter your high-level health status.

• Timeline: This is slated for the February 2026 (CNX-FEB-2026) release.

2. Clearer Reasons for Sync Issues (Addressing @sadams)

@sadams, you noted the need for more specific examples (like the PoE command on a 9004) to explain why a sync isn't "perfect."

• The Improvement: As part of the same update, we are refining how "Filtered Config" is reported. Instead of a vague warning, the UI will clearly state that these settings were filtered because they aren't applicable to that specific hardware, allowing you to reach that "healthy green state" without wondering what is missing.

3. Resolution for Interface "Module Error" (Addressing @codye)

@codye, you brought up a very specific and frustrating issue regarding ports getting stuck in an error state ( <ms-cmark-node _ngcontent-ng-c3009699313="" _nghost-ng-c3009699313="">Bug 307277</ms-cmark-node> ) and the difficulty in getting TAC to bridge that gap to Engineering.

• The Fix (AOSCX-307277): We have confirmed this bug affected 8360, 6300M, and 6400S platforms. It involved the interface getting stuck after certain link events.

• Resolution: This is officially Resolved in the latest maintenance releases (Fixed in CPE13.1030 and current 10.12 branches). This should prevent the "Operation not permitted" hardware config errors you were seeing. Btw, this is a switch related bug and not a Central or New Central bug.
  

Moving Forward

We hear the frustration regarding the "audit log" clarity and the TAC escalation process. By separating "Information" (capability mismatches) from "Errors" (actual sync failures), we aim to make the logs much more actionable.

Thank you all - @Keyser, @sadams, @codye, and @mkk - for the candid feedback. It was instrumental in getting these UI and firmware changes fast-tracked.

------------------------------
Marcel Koedijk | MVP Expert 2025 | ACEP | ACMP | ACCP | ACDP | Ekahau ECSE | Not an HPE Employee | Opinions are my own

Original Message:
Sent: Feb 10, 2026 06:25 AM
From: Keyser
Subject: Missing deeper reasons for "Syncronized with limitations" in New Central

Hi All.

When doing WiFi in New Central I find it a little annoying that you cannot get to a "healthy green state" on AP syncronization. By default even the most basic profiles such as the default certificate deployment, setting an admin password or using security policies with roles, all has settings that are not supported by the APs, and thus cannot synchronize fully.

That seems like terrible UI design since most management cares about a "green health state" + it makes one insensitive about actual issues.

Fx. all APs will throw the below limitations on a basic sync in my setup:
They all stem from a basic filter Policy on roles, setting a password on the device and the default certificate push to APs. But You cannot find further details about what the issue is - there is nothing in the audit logs to suggest the actual settings it does not support, and the policies all do work on the AP.

-------------------------------------------

Thank you HPE/Aruba :-) 

This I exactly the approach to become a MUCH better regarded solution. 
By addressing "us" and current issues here on your own official discussion forum, we all know that you are working on it, and that the problems have been noticed.

None of us expects an immediate fix, but we REALLY need to know you have noticed the problems and that they are being addressed.

Keep up the good work, and while I have had quite a few challenges with new central, missing features and such, I have to say I can also the perspective in the hierarchal profile design!
Once all the features are present in the UI this will become an insanely powerfull tool for large networks.

Thank you for getting back to us 🙏 

.. am trying to answer all of your concerns in this reply:

Hi folks,

... wanted to provide a transparent update regarding the frustrations shared in this thread. We have been tracking the feedback from @Keyser, @sadams, @codye, and @mkk regarding the "Synchronized with Limitations" status in New Central and specific interface errors.

Based on your input, our engineering teams have prioritized two major fixes:

1. Solving the "Green State" & Dashboard Noise (Addressing @Keyser and @mkk)

@Keyser, you mentioned it's "terrible UI design" to be stuck in a yellow state for basic profiles, and @mkk, we agree that it's nearly impossible to explain a "non-green" dashboard to an end customer when the device is actually working fine.

• The Fix (CNX-212181): We are officially removing "Synchronized with Limitations" as a standalone health state.

• The Result: Moving forward, if a device has "capability-filtered" settings (like the default certificates or roles @Keyser highlighted), the device will now show as Synchronized (Green).

• Visibility: Those filtered items will move to an informational view within the device details so they don't clutter your high-level health status.

• Timeline: This is slated for the February 2026 (CNX-FEB-2026) release.

2. Clearer Reasons for Sync Issues (Addressing @sadams)

@sadams, you noted the need for more specific examples (like the PoE command on a 9004) to explain why a sync isn't "perfect."

• The Improvement: As part of the same update, we are refining how "Filtered Config" is reported. Instead of a vague warning, the UI will clearly state that these settings were filtered because they aren't applicable to that specific hardware, allowing you to reach that "healthy green state" without wondering what is missing.

3. Resolution for Interface "Module Error" (Addressing @codye)

@codye, you brought up a very specific and frustrating issue regarding ports getting stuck in an error state ( <ms-cmark-node _ngcontent-ng-c3009699313="" _nghost-ng-c3009699313="">Bug 307277</ms-cmark-node> ) and the difficulty in getting TAC to bridge that gap to Engineering.

• The Fix (AOSCX-307277): We have confirmed this bug affected 8360, 6300M, and 6400S platforms. It involved the interface getting stuck after certain link events.

• Resolution: This is officially Resolved in the latest maintenance releases (Fixed in CPE13.1030 and current 10.12 branches). This should prevent the "Operation not permitted" hardware config errors you were seeing. Btw, this is a switch related bug and not a Central or New Central bug.
  

Moving Forward

We hear the frustration regarding the "audit log" clarity and the TAC escalation process. By separating "Information" (capability mismatches) from "Errors" (actual sync failures), we aim to make the logs much more actionable.

Thank you all - @Keyser, @sadams, @codye, and @mkk - for the candid feedback. It was instrumental in getting these UI and firmware changes fast-tracked.

------------------------------
Marcel Koedijk | MVP Expert 2025 | ACEP | ACMP | ACCP | ACDP | Ekahau ECSE | Not an HPE Employee | Opinions are my own

Original Message:
Sent: Feb 10, 2026 06:25 AM
From: Keyser
Subject: Missing deeper reasons for "Syncronized with limitations" in New Central

Hi All.

When doing WiFi in New Central I find it a little annoying that you cannot get to a "healthy green state" on AP syncronization. By default even the most basic profiles such as the default certificate deployment, setting an admin password or using security policies with roles, all has settings that are not supported by the APs, and thus cannot synchronize fully.

That seems like terrible UI design since most management cares about a "green health state" + it makes one insensitive about actual issues.

Fx. all APs will throw the below limitations on a basic sync in my setup:
They all stem from a basic filter Policy on roles, setting a password on the device and the default certificate push to APs. But You cannot find further details about what the issue is - there is nothing in the audit logs to suggest the actual settings it does not support, and the policies all do work on the AP.

-------------------------------------------

shankar.nair@hpe.com" data-itemmentionkey="5f061516-98e8-47b1-9e03-84f2c36a9963" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="False">@shankar.nair@hpe.com

We all appreciate the detailed responses and that you are listening to our concerns and feedback.

Regarding my comments on bug (AOSCX-307277)...

I understand this is a switch issue and not a Central issue. My comment was in response to TAC wanting to close cases quickly and not listening to our concerns. I am running 10.13.1140, and if this is resolved in 10.13.1030, then it should be resolved for me, no? However, I am still experiencing this issue on 10.13.1140 code. This was brought up to TAC, who didn't seem to care.

shankar.nair@hpe.com" data-itemmentionkey="5f061516-98e8-47b1-9e03-84f2c36a9963" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="False">@shankar.nair@hpe.com

We all appreciate the detailed responses and that you are listening to our concerns and feedback.

Regarding my comments on bug (AOSCX-307277)...

I understand this is a switch issue and not a Central issue. My comment was in response to TAC wanting to close cases quickly and not listening to our concerns. I am running 10.13.1140, and if this is resolved in 10.13.1030, then it should be resolved for me, no? However, I am still experiencing this issue on 10.13.1140 code. This was brought up to TAC, who didn't seem to care.

Dear codye,
Sorry that this happened to you.  We have let Engineering know of your concerns. Once we have some feedback, we will update you. Until then, please stay tuned.

shankar.nair@hpe.com" data-itemmentionkey="5f061516-98e8-47b1-9e03-84f2c36a9963" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="False">@shankar.nair@hpe.com

We all appreciate the detailed responses and that you are listening to our concerns and feedback.

Regarding my comments on bug (AOSCX-307277)...

I understand this is a switch issue and not a Central issue. My comment was in response to TAC wanting to close cases quickly and not listening to our concerns. I am running 10.13.1140, and if this is resolved in 10.13.1030, then it should be resolved for me, no? However, I am still experiencing this issue on 10.13.1140 code. This was brought up to TAC, who didn't seem to care.

Dear codye,
Sorry that this happened to you.  We have let Engineering know of your concerns. Once we have some feedback, we will update you. Until then, please stay tuned.

shankar.nair@hpe.com" data-itemmentionkey="5f061516-98e8-47b1-9e03-84f2c36a9963" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="False">@shankar.nair@hpe.com

We all appreciate the detailed responses and that you are listening to our concerns and feedback.

Regarding my comments on bug (AOSCX-307277)...

I understand this is a switch issue and not a Central issue. My comment was in response to TAC wanting to close cases quickly and not listening to our concerns. I am running 10.13.1140, and if this is resolved in 10.13.1030, then it should be resolved for me, no? However, I am still experiencing this issue on 10.13.1140 code. This was brought up to TAC, who didn't seem to care.

shankar.nair@hpe.com" data-itemmentionkey="1793a230-f6c5-4487-bd65-71d05686f836" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="True">@shankar.nair@hpe.com...

I deployed a new 6300M this weekend and experienced the same issue (interface wont link as it is stuck in state "module interface error")

Switch Version: 10.13.1140

Note - this issue seems particularly linked to HPE 50G XCVR's (S0V65A). Removing and reinserting the S0V65A does not help. I also tried disabling the port, waiting 5 minutes, reenabling the port (which has worked in the past), and this did not help. (maybe I need to keep it disabled for 10+ minutes?)

However - I could swap in and out different 10G XCVR's (I tried both J9151A and J9151E) and the port would immediately link every time, and never enter the error state.

Error persists when using 50G optic (S0V65A):

Error absent when using 10G optics (J9151A or J9151E):

Dear codye,
Sorry that this happened to you.  We have let Engineering know of your concerns. Once we have some feedback, we will update you. Until then, please stay tuned.

shankar.nair@hpe.com" data-itemmentionkey="5f061516-98e8-47b1-9e03-84f2c36a9963" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="False">@shankar.nair@hpe.com

We all appreciate the detailed responses and that you are listening to our concerns and feedback.

Regarding my comments on bug (AOSCX-307277)...

I understand this is a switch issue and not a Central issue. My comment was in response to TAC wanting to close cases quickly and not listening to our concerns. I am running 10.13.1140, and if this is resolved in 10.13.1030, then it should be resolved for me, no? However, I am still experiencing this issue on 10.13.1140 code. This was brought up to TAC, who didn't seem to care.

Hi @codye,

Thank you for the detailed follow-up and the screenshots. This comparison between the 10G and 50G optics is incredibly helpful data.

To be completely transparent: While my daily role typically focuses on high-level service escalations for premium customers rather than bug tracking for Foundation care,  didn't want to leave you hanging. Your 10G testing proves the previous fix (AOSCX-307277) is working, but it's clear the 50G optics (S0V65A) require a separate look from Engineering.

..shall personally follow up on this to ensure your concern gets addressed and doesn't fall through the cracks of the standard process.

How we can move this forward together:
Since the previous Jira is closed, we need an "official vehicle" to get this new 50G data back in front of the developers.

1. TAC Case: Could you please open a TAC case for this specific 50G "Module interface error"?

2. Follow-up: Once you have that case number, please share it here (or DM me).

3. Our Commitment: We will then step in to bridge the gap, linking your new case and these screenshots directly to the engineering team -shall act as your advocate to make sure they see this isn't just a config issue, but a specific optic-handling scenario that needs resolution.

We're committed to seeing this through for you - please hang in there!

Best,
Shankar

shankar.nair@hpe.com" data-itemmentionkey="1793a230-f6c5-4487-bd65-71d05686f836" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="True">@shankar.nair@hpe.com...

I deployed a new 6300M this weekend and experienced the same issue (interface wont link as it is stuck in state "module interface error")

Switch Version: 10.13.1140

Note - this issue seems particularly linked to HPE 50G XCVR's (S0V65A). Removing and reinserting the S0V65A does not help. I also tried disabling the port, waiting 5 minutes, reenabling the port (which has worked in the past), and this did not help. (maybe I need to keep it disabled for 10+ minutes?)

However - I could swap in and out different 10G XCVR's (I tried both J9151A and J9151E) and the port would immediately link every time, and never enter the error state.

Error persists when using 50G optic (S0V65A):

Error absent when using 10G optics (J9151A or J9151E):

Dear codye,
Sorry that this happened to you.  We have let Engineering know of your concerns. Once we have some feedback, we will update you. Until then, please stay tuned.

shankar.nair@hpe.com" data-itemmentionkey="5f061516-98e8-47b1-9e03-84f2c36a9963" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="False">@shankar.nair@hpe.com

We all appreciate the detailed responses and that you are listening to our concerns and feedback.

Regarding my comments on bug (AOSCX-307277)...

I understand this is a switch issue and not a Central issue. My comment was in response to TAC wanting to close cases quickly and not listening to our concerns. I am running 10.13.1140, and if this is resolved in 10.13.1030, then it should be resolved for me, no? However, I am still experiencing this issue on 10.13.1140 code. This was brought up to TAC, who didn't seem to care.

shankar.nair@hpe.com" data-itemmentionkey="99d208e6-81a3-4b21-a67f-761a51978de0" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="False">@shankar.nair@hpe.com

Thank you. I will get a case opened today and DM you the case #.

Hi @codye,

Thank you for the detailed follow-up and the screenshots. This comparison between the 10G and 50G optics is incredibly helpful data.

To be completely transparent: While my daily role typically focuses on high-level service escalations for premium customers rather than bug tracking for Foundation care,  didn't want to leave you hanging. Your 10G testing proves the previous fix (AOSCX-307277) is working, but it's clear the 50G optics (S0V65A) require a separate look from Engineering.

..shall personally follow up on this to ensure your concern gets addressed and doesn't fall through the cracks of the standard process.

How we can move this forward together:
Since the previous Jira is closed, we need an "official vehicle" to get this new 50G data back in front of the developers.

1. TAC Case: Could you please open a TAC case for this specific 50G "Module interface error"?

2. Follow-up: Once you have that case number, please share it here (or DM me).

3. Our Commitment: We will then step in to bridge the gap, linking your new case and these screenshots directly to the engineering team -shall act as your advocate to make sure they see this isn't just a config issue, but a specific optic-handling scenario that needs resolution.

We're committed to seeing this through for you - please hang in there!

Best,
Shankar

shankar.nair@hpe.com" data-itemmentionkey="1793a230-f6c5-4487-bd65-71d05686f836" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="True">@shankar.nair@hpe.com...

I deployed a new 6300M this weekend and experienced the same issue (interface wont link as it is stuck in state "module interface error")

Switch Version: 10.13.1140

Note - this issue seems particularly linked to HPE 50G XCVR's (S0V65A). Removing and reinserting the S0V65A does not help. I also tried disabling the port, waiting 5 minutes, reenabling the port (which has worked in the past), and this did not help. (maybe I need to keep it disabled for 10+ minutes?)

However - I could swap in and out different 10G XCVR's (I tried both J9151A and J9151E) and the port would immediately link every time, and never enter the error state.

Error persists when using 50G optic (S0V65A):

Error absent when using 10G optics (J9151A or J9151E):

Dear codye,
Sorry that this happened to you.  We have let Engineering know of your concerns. Once we have some feedback, we will update you. Until then, please stay tuned.

shankar.nair@hpe.com" data-itemmentionkey="5f061516-98e8-47b1-9e03-84f2c36a9963" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="False">@shankar.nair@hpe.com

We all appreciate the detailed responses and that you are listening to our concerns and feedback.

Regarding my comments on bug (AOSCX-307277)...

I understand this is a switch issue and not a Central issue. My comment was in response to TAC wanting to close cases quickly and not listening to our concerns. I am running 10.13.1140, and if this is resolved in 10.13.1030, then it should be resolved for me, no? However, I am still experiencing this issue on 10.13.1140 code. This was brought up to TAC, who didn't seem to care.

Again, to whoever can forward this issue to those running this forum...

Once again, after constructing a simple reply post which includes tagging a user (using the "@" sign) as shown here:

After posting, the reply displays additional garbage text:

shankar.nair@hpe.com" data-itemmentionkey="99d208e6-81a3-4b21-a67f-761a51978de0" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="False">@shankar.nair@hpe.com

Thank you. I will get a case opened today and DM you the case #.

Hi @codye,

Thank you for the detailed follow-up and the screenshots. This comparison between the 10G and 50G optics is incredibly helpful data.

To be completely transparent: While my daily role typically focuses on high-level service escalations for premium customers rather than bug tracking for Foundation care,  didn't want to leave you hanging. Your 10G testing proves the previous fix (AOSCX-307277) is working, but it's clear the 50G optics (S0V65A) require a separate look from Engineering.

..shall personally follow up on this to ensure your concern gets addressed and doesn't fall through the cracks of the standard process.

How we can move this forward together:
Since the previous Jira is closed, we need an "official vehicle" to get this new 50G data back in front of the developers.

1. TAC Case: Could you please open a TAC case for this specific 50G "Module interface error"?

2. Follow-up: Once you have that case number, please share it here (or DM me).

3. Our Commitment: We will then step in to bridge the gap, linking your new case and these screenshots directly to the engineering team -shall act as your advocate to make sure they see this isn't just a config issue, but a specific optic-handling scenario that needs resolution.

We're committed to seeing this through for you - please hang in there!

Best,
Shankar

shankar.nair@hpe.com" data-itemmentionkey="1793a230-f6c5-4487-bd65-71d05686f836" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="True">@shankar.nair@hpe.com...

I deployed a new 6300M this weekend and experienced the same issue (interface wont link as it is stuck in state "module interface error")

Switch Version: 10.13.1140

Note - this issue seems particularly linked to HPE 50G XCVR's (S0V65A). Removing and reinserting the S0V65A does not help. I also tried disabling the port, waiting 5 minutes, reenabling the port (which has worked in the past), and this did not help. (maybe I need to keep it disabled for 10+ minutes?)

However - I could swap in and out different 10G XCVR's (I tried both J9151A and J9151E) and the port would immediately link every time, and never enter the error state.

Error persists when using 50G optic (S0V65A):

Error absent when using 10G optics (J9151A or J9151E):

Dear codye,
Sorry that this happened to you.  We have let Engineering know of your concerns. Once we have some feedback, we will update you. Until then, please stay tuned.

shankar.nair@hpe.com" data-itemmentionkey="5f061516-98e8-47b1-9e03-84f2c36a9963" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="False">@shankar.nair@hpe.com

We all appreciate the detailed responses and that you are listening to our concerns and feedback.

Regarding my comments on bug (AOSCX-307277)...

I understand this is a switch issue and not a Central issue. My comment was in response to TAC wanting to close cases quickly and not listening to our concerns. I am running 10.13.1140, and if this is resolved in 10.13.1030, then it should be resolved for me, no? However, I am still experiencing this issue on 10.13.1140 code. This was brought up to TAC, who didn't seem to care.

Hi Codye,

1. Regarding the 50G transceiver issue, we have raised a Jira and are fast-tracking it with the development team.

2. For the formatting issue (the additional unexpected text in the display), we have escalated this to senior-level TME and PLM management for further investigation.

3. We understand the impact these issues are having and are prioritizing them accordingly. We will keep you informed as we receive updates.

Best,
-shankar

Again, to whoever can forward this issue to those running this forum...

Once again, after constructing a simple reply post which includes tagging a user (using the "@" sign) as shown here:

After posting, the reply displays additional garbage text:

shankar.nair@hpe.com" data-itemmentionkey="99d208e6-81a3-4b21-a67f-761a51978de0" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="False">@shankar.nair@hpe.com

Thank you. I will get a case opened today and DM you the case #.

Hi @codye,

Thank you for the detailed follow-up and the screenshots. This comparison between the 10G and 50G optics is incredibly helpful data.

To be completely transparent: While my daily role typically focuses on high-level service escalations for premium customers rather than bug tracking for Foundation care,  didn't want to leave you hanging. Your 10G testing proves the previous fix (AOSCX-307277) is working, but it's clear the 50G optics (S0V65A) require a separate look from Engineering.

..shall personally follow up on this to ensure your concern gets addressed and doesn't fall through the cracks of the standard process.

How we can move this forward together:
Since the previous Jira is closed, we need an "official vehicle" to get this new 50G data back in front of the developers.

1. TAC Case: Could you please open a TAC case for this specific 50G "Module interface error"?

2. Follow-up: Once you have that case number, please share it here (or DM me).

3. Our Commitment: We will then step in to bridge the gap, linking your new case and these screenshots directly to the engineering team -shall act as your advocate to make sure they see this isn't just a config issue, but a specific optic-handling scenario that needs resolution.

We're committed to seeing this through for you - please hang in there!

Best,
Shankar

shankar.nair@hpe.com" data-itemmentionkey="1793a230-f6c5-4487-bd65-71d05686f836" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="True">@shankar.nair@hpe.com...

I deployed a new 6300M this weekend and experienced the same issue (interface wont link as it is stuck in state "module interface error")

Switch Version: 10.13.1140

Note - this issue seems particularly linked to HPE 50G XCVR's (S0V65A). Removing and reinserting the S0V65A does not help. I also tried disabling the port, waiting 5 minutes, reenabling the port (which has worked in the past), and this did not help. (maybe I need to keep it disabled for 10+ minutes?)

However - I could swap in and out different 10G XCVR's (I tried both J9151A and J9151E) and the port would immediately link every time, and never enter the error state.

Error persists when using 50G optic (S0V65A):

Error absent when using 10G optics (J9151A or J9151E):

Dear codye,
Sorry that this happened to you.  We have let Engineering know of your concerns. Once we have some feedback, we will update you. Until then, please stay tuned.

shankar.nair@hpe.com" data-itemmentionkey="5f061516-98e8-47b1-9e03-84f2c36a9963" biobubblekey="mentiona6e7f9b1-714e-4dd9-a642-018ad491239d" href="https://airheads.hpe.com/profile?UserKey=a6e7f9b1-714e-4dd9-a642-018ad491239d" data-can-remove="False">@shankar.nair@hpe.com

We all appreciate the detailed responses and that you are listening to our concerns and feedback.

Regarding my comments on bug (AOSCX-307277)...

I understand this is a switch issue and not a Central issue. My comment was in response to TAC wanting to close cases quickly and not listening to our concerns. I am running 10.13.1140, and if this is resolved in 10.13.1030, then it should be resolved for me, no? However, I am still experiencing this issue on 10.13.1140 code. This was brought up to TAC, who didn't seem to care.