Wireless Access

we are facing disconnection problem in Master-to-Local connection,

the IPSec seems running , and we can see the two WLCs up in the monitoring tab, but for short period, the WLCs can't ping eeach other and connection lost.

 

keys are correct, the topology briefly described by:

 

local> local gateway :  LACP connection / no native VLAN

Master> Master gateway: one trunk port/ No native VLAN

 

Master is : 3200

local is: 7240

 

any advise please?

#3200
#7240

As long as the result of "show crypto ipsec sa" on either controller shows the opposite controller, they should be up.  They do not use ping to contact each other, so that should not be used to represent connectivity between them.

 

unfortunately the connection between them is lost too, when the ping lost.

after while every thing works .

omran almuhesen,

 

What does not work?

 

That could be a symptom of a connectivity issue in your network.  Connectivity between master and local controllers is used to:

 

- Synchroize configurations (only used every time you type "write mem" or save the configuration)

- Authenticate Local Guest Users that are created in the master controller

- Authenticate RAP devices (If 6.3 and above, this is distributed and always-on connectivity is needed between controllers)

 

Besides those things, each controller operates on its own and should be able to authenticate users and pass traffic even if the other controller is down or cannot be reached. 

 

Again, what function does not work, when this happens?

 

What version of AOS are you running? What I've seen is with 6.4.1.0 the communication between Master & Local does not work.  Local indicates that the Master could not be contracted, even though all of ipsec sa information is working well and ICMP works between the two.

 

Another issue I have seen recently with 6.1.3.7, is that after some time (>30 days), Local lost connectivity with the Master in similar fashion. That is, Master did not see Local, Local was indicating that Master could not be contacted.  Moreover, traceroute from Master to Local was hanging on the first hop, and from Local to Master was looping at the last hop before the master.  PING between them was also not working from either side.

 

The way I resolved it is by restarting ike process on the master, and then restarting authmgr process on the local.

 

Garyshtern wrote:

> What version of AOS are you running? What I've seen is with 6.4.1.0 the communication between Master & Local does not work.

> Local indicates that the Master could not be contracted, even though all of ipsec sa information is working well and ICMP works

> between the two.

 

We've seen similar behavior between an L2-connected HA dual pair since an upgrade to 6.4.1.0, manifesting as missed HA heartbeats.  We have a TAC case in on it.

 

we are using the 6.4 version on both 7240 and 3200 , also I need to know, should we add native clan in order to get master to local communicates with each other??!!

 

I've used local and master before and knows what you said, but this connection shows no stability, I think I'm going to open a case.

#7240

Garryshtern,

Were any of these incidents reported to TAC and troubleshot? Typically, controllers do not need constant connectivity so restarting services is a drastic and possibly harmful way to deal with two devices that typically do not need constant connectivity.

Colin,

 

I am aware of the limited use of Master/Local communications, but after my configuration wasn't synchronized from Master to Local, I started troubleshooting the issue.  I did not bother opening TAC case simply because I had no time to go through the escalations until I get someone knowledgeable enough (no offense).

 

Once I narrowed down the isuse to the IPSEC tunnel, it was pretty straight forward to restart the processes and everything started working again.

 

If I run into this again, I'll try to open a case and ask for immediate escalation.

Garryshtern,

Opening a case gives us a chance to investigate it and fix it. There are some circumstances where it is not simply an Aruba bug, but the specific environment is deployed in, so the issue will never be replicated in a lab. We are all for people reporting issues here on the forum, but unless they are investigated and fixed in their entirety and fixed there is nothing we can do about them.

Colin,

 

I am completely with you on both the bug and resolution front.  What I generally don't do is open up a case for a single occurance of an issue snce it can be a large number of variables, including environmental.

 

As I mentioned, I will open up a case if or when this happens again.

 

Thanks!

If someone searches for generic symptoms like master local connectivity and runs into your post, they will try restarting their services and harm their network. That is not what we want to happen.

Omran,

You do not need to define any native vlans. They only require IP connectivity between switch IP addresses.