had an issue with my communities account which has now been fixed, otherwise would have posted this sooner!
I believe i've found the solution, I had the same issue on a new cluster/farm, with a distributed virtual switch, that i've been building for a client.
Please can you check the following in the Network configuration of your Host Profile reference host:
Select vSphere Distributed Switch
Manage Virtual Adapters
At this point i'm assuming you have more than one VMKernel (vmk) port
Select the first vmk? port (vmk0 usually)
At the bottom right click on 'View Routing Table'
You should see some entries for default routes
Select the next vmk? port (vmk1 say)
Again at the bottom right click on 'View Routing Table'
You should not see any entries at all (completely blank)
Repeat for any further VMKernel ports you have configured, they should all have blank routing tables
Now if this is not the case, and vmk0 does not have a populated routing table, then i've found these steps do help:
Click 'Edit' at the top
Make, & immediately undo, any change. For example untick and then retick any box (or vice versa), and then click on OK
This will force an update without actually making a change to the settings
You should now find that the vmk0 port has the routing table.
Update the host profile from the reference host, and then re-check compliance.
Hopefully all should now be working well!
Im getting the same issue, unfortunatly Novaldex's solution didnt work for me. I have the following in my lab:-
0.0.0.0 0 192.168.0.10
192.168.0.0 24 0.0.0.0
No routes defined.
This is the same on the host profile referenced host aswell, so not sure why the host im running the compliance on is still showing the error
Any help appreciated..
I am currently experencing the same issue in my environment. Some background information about my environment...
Server Enclosure: HP C7000
HP Proliant Blades - BL465c G7
Virtual Connect Profiles - Identical with same ethernet network
A couple of things that I was able to duplicate consistently...
One, regardless if the network is a /23 (192.168.16.1-192.168.17.254) or /24 (IPv4 Address range 192.168.16.1-192.168.16.254), I will get the "IPv4 Routes do not match" following a host having the profile applied. This is only the case if there are more than one VMkernel's.
Secondly, I have noticed that I do not encounter the issue at all when only one VMkernel is used. In this case, I would only have the "Managment" VMkernel of course, and this is with the standard switch (vSwitch0).
If I add an additional VMkernel to the switch, update the host profile from the reference host, and then apply the host profile to the respective hosts, they will provide the "IPv4 Routes do not match" message. This is NOT the case all the time however. Occasionally the hosts after a restart will be in compliance, however for the most part, they are consistently spitting out the compliance failure for mentioned.
Sorry Pagri, i'm not sure why yours is reporting the routing issue! I can only imagine that there is something else amiss. My first thoughts are down to how many adapters you have configured in your hosts & dvSwitch, how many are there?
Let me try filling out my suggestion with a bit more background of what I discovered.
I've got 4 IBM HS22 blades in my farm, QLogic CNAs & FCoE. Just for the record
(btw, if you're having issues with IBM blades/QLogic CNAs & FCoE, shout, i've already been through months of pain!)
So, originally my hosts only had a single vmkernel port, running only management (I hadn't configured vMotion yet). No issues.
Added vMotion to the single vmkernel port, still no issues.
Realised that I was planning on doing some traffic shaping and preferred to separate vMotion, I created a second vmkernel port on my reference host, updated the host profile, and the other 3 hosts failed, obviously before applying the updates, but continued to fail afterwards.
What I found was that by adding the new vmkernel port, the routing table moved from vmk0 to vmk1, but only on the host where I made the change. All other hosts kept the routing table on the correct port, vmk0. All I can imagine is that by applying a blanket change, all ports were updated at the same time, and therefore (internally I guess) it kept it on the original lower port.
By making a minor change to the vmk0 port on the original host, the routing table moved back.
Yes, it's not very scientific, but it worked for me.
I then updated the host profile again, and then re-ran the compliance checks against the others. This time it was successful.
I have to confess I don't understand why it hopped around like that, wish I did.
Happy to give any more advice, don't be afraid to ask. I promise not to bite!