Security

Hey guys, to anybody who wants to solve this without calling TAC, we had the same issue and it was resolved by using a fixed mac-address on the Hyper-V servers (requires the server to be off to change), then issuing the system refresh-network command at CLI, which will require a reboot. Apparently this command remaps the ethernet ports to the new MAC addresses. After that no more IP loss after reboot.

-RK

Hey guys, to anybody who wants to solve this without calling TAC, we had the same issue and it was resolved by using a fixed mac-address on the Hyper-V servers (requires the server to be off to change), then issuing the system refresh-network command at CLI, which will require a reboot. Apparently this command remaps the ethernet ports to the new MAC addresses. After that no more IP loss after reboot.

-RK

After several emails back and forward from TAC with them saying that IP settings would not be lost after a reboot, I had to look into this myself.

Confirming that this fixed the issue for us on v6.11.13.264080. Thank you!

Hey guys, to anybody who wants to solve this without calling TAC, we had the same issue and it was resolved by using a fixed mac-address on the Hyper-V servers (requires the server to be off to change), then issuing the system refresh-network command at CLI, which will require a reboot. Apparently this command remaps the ethernet ports to the new MAC addresses. After that no more IP loss after reboot.

-RK

Hi,
as this thread is a bit dated, I would say there are some new insights to this topic.

I think this behaviour is not a ClearPass related problem.
But more an issue with Hyper-V.
I saw this not only with ClearPass but also with Mobility Conductor VMs and basically with any linux VM.

After several installations, I can recommend the following best practice:

• Use Static MAC Addresses
• Use MAC Addresses reserved for private use, like recommended also for VSX Active Gateway VMAC
  (May the Hyper-V management will reuse a dynamic assigned MAC, converted to a static MAC, if the Guest VM was moved.)
• Use a lower MAC Address for NIC 1
• Use a higher MAC Address for NIC 2

You should use the lower MAC address for adapter one.
Because the guest will use the adapter with the lowest MAC address for the first (lowest numbered) NIC.
There are also hints about it in the ClearPass Update and installation guides:
After You Install on ESXi Servers: Establishing NW Connectivity
VMware vSphere Hypervisor Installation Process Overview
This is indeed VMware specific, but I saw the same behaviour also on Hyper-V.
And also regardless of the guest VM product.
For example, if you boot up a Rocky Linux, the adapter with the lowest MAC will get the first NIC within the guest.

If you now move the VM to another Hyper-V host, it could happen that the target hypervisor renumbers the NICs in a "dynamic fashion".
And if the NICs get completely new MAC Addresses (based on the HW MAC of the host), the IP will not be migrated from the old VM NIC to the new one.
You will have to reconfigure your IP settings on the Guest, or recover the original MAC address settings for the guest VM.

I had also the problem once, that the VM on the source Hyper-V host was using a higher MAC address (static) for NIC one, than for NIC two on the target Hyper-V Host (dynamic).
In this case, the VM was flipping the NIC numbering.
And because NIC two was not connected, it was going offline.
We had to enable NIC 2 and disable NIC 1.

If this happens to you on a Mobility Conductor, the Conductor will change its license passphrase - so if you download your licenses from NSP, you know what to expect.

So this is true not only for ClearPass, but potentially for all Linux guests on Hyper-V.
 

After several emails back and forward from TAC with them saying that IP settings would not be lost after a reboot, I had to look into this myself.

Confirming that this fixed the issue for us on v6.11.13.264080. Thank you!

Hey guys, to anybody who wants to solve this without calling TAC, we had the same issue and it was resolved by using a fixed mac-address on the Hyper-V servers (requires the server to be off to change), then issuing the system refresh-network command at CLI, which will require a reboot. Apparently this command remaps the ethernet ports to the new MAC addresses. After that no more IP loss after reboot.

-RK

Cheers for the detailed update - I'll have a look at the MAC numbering.

Out of interest, how have you found the reliability of Mobility Conductor on Hyper-V? Our findings showed it's not officially supported (might just be specific versions, I don't remember), so we had to spin up a KVM instance specifically for it. Our customer, like everyone, was moving off VMware. I'd be keen to hear how it's been for you - I'm sure you can imagine that having a separate server just for KVM isn't the most perfect solution.

Hi,
as this thread is a bit dated, I would say there are some new insights to this topic.

I think this behaviour is not a ClearPass related problem.
But more an issue with Hyper-V.
I saw this not only with ClearPass but also with Mobility Conductor VMs and basically with any linux VM.

After several installations, I can recommend the following best practice:

• Use Static MAC Addresses
• Use MAC Addresses reserved for private use, like recommended also for VSX Active Gateway VMAC
  (May the Hyper-V management will reuse a dynamic assigned MAC, converted to a static MAC, if the Guest VM was moved.)
• Use a lower MAC Address for NIC 1
• Use a higher MAC Address for NIC 2

You should use the lower MAC address for adapter one.
Because the guest will use the adapter with the lowest MAC address for the first (lowest numbered) NIC.
There are also hints about it in the ClearPass Update and installation guides:
After You Install on ESXi Servers: Establishing NW Connectivity
VMware vSphere Hypervisor Installation Process Overview
This is indeed VMware specific, but I saw the same behaviour also on Hyper-V.
And also regardless of the guest VM product.
For example, if you boot up a Rocky Linux, the adapter with the lowest MAC will get the first NIC within the guest.

If you now move the VM to another Hyper-V host, it could happen that the target hypervisor renumbers the NICs in a "dynamic fashion".
And if the NICs get completely new MAC Addresses (based on the HW MAC of the host), the IP will not be migrated from the old VM NIC to the new one.
You will have to reconfigure your IP settings on the Guest, or recover the original MAC address settings for the guest VM.

I had also the problem once, that the VM on the source Hyper-V host was using a higher MAC address (static) for NIC one, than for NIC two on the target Hyper-V Host (dynamic).
In this case, the VM was flipping the NIC numbering.
And because NIC two was not connected, it was going offline.
We had to enable NIC 2 and disable NIC 1.

If this happens to you on a Mobility Conductor, the Conductor will change its license passphrase - so if you download your licenses from NSP, you know what to expect.

So this is true not only for ClearPass, but potentially for all Linux guests on Hyper-V.
 

After several emails back and forward from TAC with them saying that IP settings would not be lost after a reboot, I had to look into this myself.

Confirming that this fixed the issue for us on v6.11.13.264080. Thank you!

Hey guys, to anybody who wants to solve this without calling TAC, we had the same issue and it was resolved by using a fixed mac-address on the Hyper-V servers (requires the server to be off to change), then issuing the system refresh-network command at CLI, which will require a reboot. Apparently this command remaps the ethernet ports to the new MAC addresses. After that no more IP loss after reboot.

-RK

Hi,

in my opinion, it is supported for Aruba AOS-8 for quite a while.
For example, the installation is documented already in the AOS 8.2.0.0 Virtual Appliance Installation Guide from page 51.
It is also documented in the 8.10 Version from page 60.
But it is not documented in the initial document from 2016, so Hyper-V Support seems to be introduced with 8.2.x. and Windows Server 2012 R2.

However, I'm realy not an Hyper-V fan.
There are several disadvantages over other Hypervisors.
But, if you follow the installation guide, mobility conductor VMs are running stable.

Cheers for the detailed update - I'll have a look at the MAC numbering.

Out of interest, how have you found the reliability of Mobility Conductor on Hyper-V? Our findings showed it's not officially supported (might just be specific versions, I don't remember), so we had to spin up a KVM instance specifically for it. Our customer, like everyone, was moving off VMware. I'd be keen to hear how it's been for you - I'm sure you can imagine that having a separate server just for KVM isn't the most perfect solution.

Hi,
as this thread is a bit dated, I would say there are some new insights to this topic.

I think this behaviour is not a ClearPass related problem.
But more an issue with Hyper-V.
I saw this not only with ClearPass but also with Mobility Conductor VMs and basically with any linux VM.

After several installations, I can recommend the following best practice:

• Use Static MAC Addresses
• Use MAC Addresses reserved for private use, like recommended also for VSX Active Gateway VMAC
  (May the Hyper-V management will reuse a dynamic assigned MAC, converted to a static MAC, if the Guest VM was moved.)
• Use a lower MAC Address for NIC 1
• Use a higher MAC Address for NIC 2

You should use the lower MAC address for adapter one.
Because the guest will use the adapter with the lowest MAC address for the first (lowest numbered) NIC.
There are also hints about it in the ClearPass Update and installation guides:
After You Install on ESXi Servers: Establishing NW Connectivity
VMware vSphere Hypervisor Installation Process Overview
This is indeed VMware specific, but I saw the same behaviour also on Hyper-V.
And also regardless of the guest VM product.
For example, if you boot up a Rocky Linux, the adapter with the lowest MAC will get the first NIC within the guest.

If you now move the VM to another Hyper-V host, it could happen that the target hypervisor renumbers the NICs in a "dynamic fashion".
And if the NICs get completely new MAC Addresses (based on the HW MAC of the host), the IP will not be migrated from the old VM NIC to the new one.
You will have to reconfigure your IP settings on the Guest, or recover the original MAC address settings for the guest VM.

I had also the problem once, that the VM on the source Hyper-V host was using a higher MAC address (static) for NIC one, than for NIC two on the target Hyper-V Host (dynamic).
In this case, the VM was flipping the NIC numbering.
And because NIC two was not connected, it was going offline.
We had to enable NIC 2 and disable NIC 1.

If this happens to you on a Mobility Conductor, the Conductor will change its license passphrase - so if you download your licenses from NSP, you know what to expect.

So this is true not only for ClearPass, but potentially for all Linux guests on Hyper-V.
 

After several emails back and forward from TAC with them saying that IP settings would not be lost after a reboot, I had to look into this myself.

Confirming that this fixed the issue for us on v6.11.13.264080. Thank you!

Hey guys, to anybody who wants to solve this without calling TAC, we had the same issue and it was resolved by using a fixed mac-address on the Hyper-V servers (requires the server to be off to change), then issuing the system refresh-network command at CLI, which will require a reboot. Apparently this command remaps the ethernet ports to the new MAC addresses. After that no more IP loss after reboot.

-RK

Thanks for the detailed info. Yes, I agree that Hyper-V is fairly simple compared to some other hypervisors - although with VMware now being priced out of the market for most then we're quite limited on options. Thanks again!

Hi,

in my opinion, it is supported for Aruba AOS-8 for quite a while.
For example, the installation is documented already in the AOS 8.2.0.0 Virtual Appliance Installation Guide from page 51.
It is also documented in the 8.10 Version from page 60.
But it is not documented in the initial document from 2016, so Hyper-V Support seems to be introduced with 8.2.x. and Windows Server 2012 R2.

However, I'm realy not an Hyper-V fan.
There are several disadvantages over other Hypervisors.
But, if you follow the installation guide, mobility conductor VMs are running stable.

Cheers for the detailed update - I'll have a look at the MAC numbering.

Out of interest, how have you found the reliability of Mobility Conductor on Hyper-V? Our findings showed it's not officially supported (might just be specific versions, I don't remember), so we had to spin up a KVM instance specifically for it. Our customer, like everyone, was moving off VMware. I'd be keen to hear how it's been for you - I'm sure you can imagine that having a separate server just for KVM isn't the most perfect solution.

Hi,
as this thread is a bit dated, I would say there are some new insights to this topic.

I think this behaviour is not a ClearPass related problem.
But more an issue with Hyper-V.
I saw this not only with ClearPass but also with Mobility Conductor VMs and basically with any linux VM.

After several installations, I can recommend the following best practice:

• Use Static MAC Addresses
• Use MAC Addresses reserved for private use, like recommended also for VSX Active Gateway VMAC
  (May the Hyper-V management will reuse a dynamic assigned MAC, converted to a static MAC, if the Guest VM was moved.)
• Use a lower MAC Address for NIC 1
• Use a higher MAC Address for NIC 2

You should use the lower MAC address for adapter one.
Because the guest will use the adapter with the lowest MAC address for the first (lowest numbered) NIC.
There are also hints about it in the ClearPass Update and installation guides:
After You Install on ESXi Servers: Establishing NW Connectivity
VMware vSphere Hypervisor Installation Process Overview
This is indeed VMware specific, but I saw the same behaviour also on Hyper-V.
And also regardless of the guest VM product.
For example, if you boot up a Rocky Linux, the adapter with the lowest MAC will get the first NIC within the guest.

If you now move the VM to another Hyper-V host, it could happen that the target hypervisor renumbers the NICs in a "dynamic fashion".
And if the NICs get completely new MAC Addresses (based on the HW MAC of the host), the IP will not be migrated from the old VM NIC to the new one.
You will have to reconfigure your IP settings on the Guest, or recover the original MAC address settings for the guest VM.

I had also the problem once, that the VM on the source Hyper-V host was using a higher MAC address (static) for NIC one, than for NIC two on the target Hyper-V Host (dynamic).
In this case, the VM was flipping the NIC numbering.
And because NIC two was not connected, it was going offline.
We had to enable NIC 2 and disable NIC 1.

If this happens to you on a Mobility Conductor, the Conductor will change its license passphrase - so if you download your licenses from NSP, you know what to expect.

So this is true not only for ClearPass, but potentially for all Linux guests on Hyper-V.
 

After several emails back and forward from TAC with them saying that IP settings would not be lost after a reboot, I had to look into this myself.

Confirming that this fixed the issue for us on v6.11.13.264080. Thank you!

Hey guys, to anybody who wants to solve this without calling TAC, we had the same issue and it was resolved by using a fixed mac-address on the Hyper-V servers (requires the server to be off to change), then issuing the system refresh-network command at CLI, which will require a reboot. Apparently this command remaps the ethernet ports to the new MAC addresses. After that no more IP loss after reboot.

-RK

My you trie to evaluate HPE Morpheus VME.

Thanks for the detailed info. Yes, I agree that Hyper-V is fairly simple compared to some other hypervisors - although with VMware now being priced out of the market for most then we're quite limited on options. Thanks again!

Hi,

in my opinion, it is supported for Aruba AOS-8 for quite a while.
For example, the installation is documented already in the AOS 8.2.0.0 Virtual Appliance Installation Guide from page 51.
It is also documented in the 8.10 Version from page 60.
But it is not documented in the initial document from 2016, so Hyper-V Support seems to be introduced with 8.2.x. and Windows Server 2012 R2.

However, I'm realy not an Hyper-V fan.
There are several disadvantages over other Hypervisors.
But, if you follow the installation guide, mobility conductor VMs are running stable.

Cheers for the detailed update - I'll have a look at the MAC numbering.

Out of interest, how have you found the reliability of Mobility Conductor on Hyper-V? Our findings showed it's not officially supported (might just be specific versions, I don't remember), so we had to spin up a KVM instance specifically for it. Our customer, like everyone, was moving off VMware. I'd be keen to hear how it's been for you - I'm sure you can imagine that having a separate server just for KVM isn't the most perfect solution.

Hi,
as this thread is a bit dated, I would say there are some new insights to this topic.

I think this behaviour is not a ClearPass related problem.
But more an issue with Hyper-V.
I saw this not only with ClearPass but also with Mobility Conductor VMs and basically with any linux VM.

After several installations, I can recommend the following best practice:

• Use Static MAC Addresses
• Use MAC Addresses reserved for private use, like recommended also for VSX Active Gateway VMAC
  (May the Hyper-V management will reuse a dynamic assigned MAC, converted to a static MAC, if the Guest VM was moved.)
• Use a lower MAC Address for NIC 1
• Use a higher MAC Address for NIC 2

You should use the lower MAC address for adapter one.
Because the guest will use the adapter with the lowest MAC address for the first (lowest numbered) NIC.
There are also hints about it in the ClearPass Update and installation guides:
After You Install on ESXi Servers: Establishing NW Connectivity
VMware vSphere Hypervisor Installation Process Overview
This is indeed VMware specific, but I saw the same behaviour also on Hyper-V.
And also regardless of the guest VM product.
For example, if you boot up a Rocky Linux, the adapter with the lowest MAC will get the first NIC within the guest.

If you now move the VM to another Hyper-V host, it could happen that the target hypervisor renumbers the NICs in a "dynamic fashion".
And if the NICs get completely new MAC Addresses (based on the HW MAC of the host), the IP will not be migrated from the old VM NIC to the new one.
You will have to reconfigure your IP settings on the Guest, or recover the original MAC address settings for the guest VM.

I had also the problem once, that the VM on the source Hyper-V host was using a higher MAC address (static) for NIC one, than for NIC two on the target Hyper-V Host (dynamic).
In this case, the VM was flipping the NIC numbering.
And because NIC two was not connected, it was going offline.
We had to enable NIC 2 and disable NIC 1.

If this happens to you on a Mobility Conductor, the Conductor will change its license passphrase - so if you download your licenses from NSP, you know what to expect.

So this is true not only for ClearPass, but potentially for all Linux guests on Hyper-V.
 

After several emails back and forward from TAC with them saying that IP settings would not be lost after a reboot, I had to look into this myself.

Confirming that this fixed the issue for us on v6.11.13.264080. Thank you!

Hey guys, to anybody who wants to solve this without calling TAC, we had the same issue and it was resolved by using a fixed mac-address on the Hyper-V servers (requires the server to be off to change), then issuing the system refresh-network command at CLI, which will require a reboot. Apparently this command remaps the ethernet ports to the new MAC addresses. After that no more IP loss after reboot.

-RK