wing AP - same subnet - different vx9000

[marconet_22]

HI

I have two type of AP in the same subnet (AP6522 and AP305cx)

AP6522 registered to vx9000-A rel 5.9

AP305cx registered to vx9000-B rel 7.7

When restart the APs, I loose AP6522 from vx9000-A.

I looking for "RF domain manager" for each rf-domain and i put the command:

mint link force ip "ip address vx" level 2

It solves the issue but when restart the APs the issue come back again.

Can someone help me?

[Angelo_Cargnel]

Hi,
best practices will not allow that APs in the same subnet (mint level 1 broadcast domain) will have different controllers.
All APs in the same subnet will elect by mint level 1 one AP as the rf-domain manager.
The domain manager AP is the only AP in this mint level 1 domain that will have a mint level 2 link to his controller.
All other APs in the same subnet (mint level 1 domain) will drop their mint level 2 link to the controller, once the rf-domain manager election is successful and then use the domain manager AP with a mint level 1 communication as a kind of proxy to communicate to the controller.

A possible solution for your problem is to separate the mint level 1 domain for each AP type logical by using the optional mint level 1 area-id.
To do so, you can use the command "mint level 1 area-id 1001" in the AP6522 profile and in the AP305cx profile "mint level 1 area-id 1002".
1001 and 1002 are only an example. You can use any number between 1 and 16777215. But they have to be different.

Now you have two logical mint level 1 areas where each will elect it's own rf-domain manager AP and your APs are able to use the proxy mint level 2 link to the designated controller.

Cheers,
Angelo

[Christoph_S]

Hello @marconet_22.,

This is not a supported deployment. You cannot have 2 VX controllers on the same subnet for different APs. This will cause all sorts of Mint issues, one of which is your adoption problem. Each one should be on it's own subnet not communicating with the other. You can also try this other option per this article: https://extreme-networks.my.site.com/ExtrArticleDetail?an=000085119.

You can also have a look at these steps: https://extreme-networks.my.site.com/ExtrArticleDetail?an=000094000

Note the provisioning policy should be for the AP6522 and should be configured on VX-B

YOu can also try this: On VX-B create a mac-access-list to deny the AP6522 APs. Map it to ge1. 

Since this is not a supported deployment, above are only suggestions but we don't know if there will be long term implications so please test thoroughly before implementing. 

I hope one if those helps. 

BR,