Wireless Access

Hi,

we have an infrastructure with a VM mobility conductor and two physical mobility controllers (in cluster) in version 8.10.  There are approximately 1200 APs, of which approximately 1000 are remote. Licenses and resources are adequate, already verified.

We have two problems:

Have you opened a case with TAC?

Hi,

we have an infrastructure with a VM mobility conductor and two physical mobility controllers (in cluster) in version 8.10.  There are approximately 1200 APs, of which approximately 1000 are remote. Licenses and resources are adequate, already verified.

We have two problems:

Hi,

it's real, unfortunatelly.

TAC opened and searching in logs, asking reports, ecc.

We have disactivated airmatch in conductor configuration, but the behaviour is the same. It's only a little bit better: time to down/up of remote is reduced and less rap stucks in down. But it's not the solution.

We need to know if this is normal (rebooting the conductor raps going down) or not. Campus APs aren't affected, only raps.

In fact, we had rap pools set on controllers, then, with activation of claster, rap pools are set on MC. It is possible that when MC restart it need to restablish the lease of the pool?

Thanks

Have you opened a case with TAC?

Hi,

we have an infrastructure with a VM mobility conductor and two physical mobility controllers (in cluster) in version 8.10.  There are approximately 1200 APs, of which approximately 1000 are remote. Licenses and resources are adequate, already verified.

We have two problems:

Assuming your configuration is correct, there should never be a reason to reboot a controller or AP manually during normal operation.  That's why I asked if you had a case open with TAC, you've either run into a misconfiguration or a bug.

Hi,

it's real, unfortunatelly.

TAC opened and searching in logs, asking reports, ecc.

We have disactivated airmatch in conductor configuration, but the behaviour is the same. It's only a little bit better: time to down/up of remote is reduced and less rap stucks in down. But it's not the solution.

We need to know if this is normal (rebooting the conductor raps going down) or not. Campus APs aren't affected, only raps.

In fact, we had rap pools set on controllers, then, with activation of claster, rap pools are set on MC. It is possible that when MC restart it need to restablish the lease of the pool?

Thanks

Have you opened a case with TAC?

Hi,

we have an infrastructure with a VM mobility conductor and two physical mobility controllers (in cluster) in version 8.10.  There are approximately 1200 APs, of which approximately 1000 are remote. Licenses and resources are adequate, already verified.

We have two problems:

I hope the configuration is correct, the only modified set after the cluster activation is rap pools mooved into MC, no other changes. There is no nat, no public IP.

It seems that service mongo is continuosly restarting... Hope support can fix it.

Thanks

Assuming your configuration is correct, there should never be a reason to reboot a controller or AP manually during normal operation.  That's why I asked if you had a case open with TAC, you've either run into a misconfiguration or a bug.

Hi,

it's real, unfortunatelly.

TAC opened and searching in logs, asking reports, ecc.

We have disactivated airmatch in conductor configuration, but the behaviour is the same. It's only a little bit better: time to down/up of remote is reduced and less rap stucks in down. But it's not the solution.

We need to know if this is normal (rebooting the conductor raps going down) or not. Campus APs aren't affected, only raps.

In fact, we had rap pools set on controllers, then, with activation of claster, rap pools are set on MC. It is possible that when MC restart it need to restablish the lease of the pool?

Thanks

Have you opened a case with TAC?

Hi,

we have an infrastructure with a VM mobility conductor and two physical mobility controllers (in cluster) in version 8.10.  There are approximately 1200 APs, of which approximately 1000 are remote. Licenses and resources are adequate, already verified.

We have two problems:

You mean the IP pools were reconfigured at the Mobility Conductor (MCR) level?

I hope the configuration is correct, the only modified set after the cluster activation is rap pools mooved into MC, no other changes. There is no nat, no public IP.

It seems that service mongo is continuosly restarting... Hope support can fix it.

Thanks

Assuming your configuration is correct, there should never be a reason to reboot a controller or AP manually during normal operation.  That's why I asked if you had a case open with TAC, you've either run into a misconfiguration or a bug.

Hi,

it's real, unfortunatelly.

TAC opened and searching in logs, asking reports, ecc.

We have disactivated airmatch in conductor configuration, but the behaviour is the same. It's only a little bit better: time to down/up of remote is reduced and less rap stucks in down. But it's not the solution.

We need to know if this is normal (rebooting the conductor raps going down) or not. Campus APs aren't affected, only raps.

In fact, we had rap pools set on controllers, then, with activation of claster, rap pools are set on MC. It is possible that when MC restart it need to restablish the lease of the pool?

Thanks

Have you opened a case with TAC?

Hi,

we have an infrastructure with a VM mobility conductor and two physical mobility controllers (in cluster) in version 8.10.  There are approximately 1200 APs, of which approximately 1000 are remote. Licenses and resources are adequate, already verified.

We have two problems:

Yes Chulcher, the lc-rap-pool reconfigured at MC level.

It seems that the problem is mongo db and mongo service that doesn't start. I'm planning a session with tac to try to fix.

Thanks.

You mean the IP pools were reconfigured at the Mobility Conductor (MCR) level?

I hope the configuration is correct, the only modified set after the cluster activation is rap pools mooved into MC, no other changes. There is no nat, no public IP.

It seems that service mongo is continuosly restarting... Hope support can fix it.

Thanks

Assuming your configuration is correct, there should never be a reason to reboot a controller or AP manually during normal operation.  That's why I asked if you had a case open with TAC, you've either run into a misconfiguration or a bug.

Hi,

it's real, unfortunatelly.

TAC opened and searching in logs, asking reports, ecc.

We have disactivated airmatch in conductor configuration, but the behaviour is the same. It's only a little bit better: time to down/up of remote is reduced and less rap stucks in down. But it's not the solution.

We need to know if this is normal (rebooting the conductor raps going down) or not. Campus APs aren't affected, only raps.

In fact, we had rap pools set on controllers, then, with activation of claster, rap pools are set on MC. It is possible that when MC restart it need to restablish the lease of the pool?

Thanks

Have you opened a case with TAC?

Hi,

we have an infrastructure with a VM mobility conductor and two physical mobility controllers (in cluster) in version 8.10.  There are approximately 1200 APs, of which approximately 1000 are remote. Licenses and resources are adequate, already verified.

We have two problems:

Good to hear.

MC = Mobility Controller

MCR = Mobility Conductor

Yes Chulcher, the lc-rap-pool reconfigured at MC level.

It seems that the problem is mongo db and mongo service that doesn't start. I'm planning a session with tac to try to fix.

Thanks.

You mean the IP pools were reconfigured at the Mobility Conductor (MCR) level?

I hope the configuration is correct, the only modified set after the cluster activation is rap pools mooved into MC, no other changes. There is no nat, no public IP.

It seems that service mongo is continuosly restarting... Hope support can fix it.

Thanks

Assuming your configuration is correct, there should never be a reason to reboot a controller or AP manually during normal operation.  That's why I asked if you had a case open with TAC, you've either run into a misconfiguration or a bug.

Hi,

it's real, unfortunatelly.

TAC opened and searching in logs, asking reports, ecc.

We have disactivated airmatch in conductor configuration, but the behaviour is the same. It's only a little bit better: time to down/up of remote is reduced and less rap stucks in down. But it's not the solution.

We need to know if this is normal (rebooting the conductor raps going down) or not. Campus APs aren't affected, only raps.

In fact, we had rap pools set on controllers, then, with activation of claster, rap pools are set on MC. It is possible that when MC restart it need to restablish the lease of the pool?

Thanks

Have you opened a case with TAC?

Hi,

we have an infrastructure with a VM mobility conductor and two physical mobility controllers (in cluster) in version 8.10.  There are approximately 1200 APs, of which approximately 1000 are remote. Licenses and resources are adequate, already verified.

We have two problems: