cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10439
Views
20
Helpful
10
Replies

IOM 1/2 (B) current connectivity does not match discovery policy: unsupported-connectivity

ADAman
Level 1
Level 1

anyone have a clue? My chassis-discovery policy is correctly set to 2, the same number as the two IOM ports per FI.

1 Accepted Solution

Accepted Solutions

If you fix the problem, the error will clear.

Robert

View solution in original post

10 Replies 10

Robert Burns
Cisco Employee
Cisco Employee

Have to tried re-acknowledging the chassis?

If that doesn't work, unconfigure the server ports on the FI-B and re-configure them.

Robert

ok, thanks. But in cases like this, how do I check if changes like this solves the problem? Other than rebooting the FIs?

Because it usually does not write warnings and errors repeatedly.

If you fix the problem, the error will clear.

Robert

yes, it is now cleared. Just did "Acknowledge". But before I can start upgrading fw here, I need to backup the config. See other thread, please.

Hey Atle, when you re-achknowledged the chassis, do you experience any outages? momentary/extended?

I have the same error msg and one of the Fabric ports 's "Un Acknowledged" and another is "Un Inititalized". I'd like to re-acknowledge the chassis but not sure if of the potential for an outage.

Jonathan,

By reacknowledging the chassis, you will definitely experience a loss of service, so this requires a maintenance window.

Can you share an screenshot of the errors you see for the ports?

-Kenny

Hey Keny,

Thanks for the reply, I meant to post my resolution for this. First off, this is error I had in addition to a F0399 error which I don't have a screenshot of:

Additionally, this is what the Fabric Ports status looked like:

Last night during a maint window, I re-acknoledged the chassis which did indeed cause an outage for about 3-5 seconds. During this time all of my VMs had HA errors. I've added to my SOP to disable HA during a chassi re-ack. Afterwards, any VM that was powered off during the re-ack was also marked as (inaccessible) in the Vcenter client. These VMs could not be powered on. This was non critical as all powered off VMs were not production critical so I put in a ticket w VMware and worked with them this morning to resolve.

After working with VMWare, I discovered there were two ways to fix the problem. 1.) Instead of connecting to VCenter, you could connect directly to the individual ESXi hosts. For some reason, the (inaccessible) VMs could be powered on when you did that. 2.) Later, I found that the storage was in an ambiguous state and that if I simply refreshed the view on the stat stores, all of the VMs would be accessible even through VCenter.

Thanks for checking on me; my UCS is back up and running. I'm working on upgrading the firmeware to prevent this error from cropping up again (this according to TAC).

-j

Jonathan,

Glad the issue is resolved by now and thanks for sharing the resolution steps. 

-Kenny

Reacking the chassis means a interrupt of traffic for about 20+ seconds, no reboot of any server. Any ESXi or Windows server will survive such a intervention; I agree however, that a heavy loaded db server might not be very happy.

lawrence.chiong
Level 1
Level 1

Thanks Jonathan.  Your detailed solution help resolved my issue.

Lawrence

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card