Wireless Access

I observed this behaviour of Aruba OS while setting up a redundant master controller. As per my knowledge, when a device intiate a communication to a VIP , the source IP of reply packet should be the VIP and not the physical interface IP. Correct me if I am wrong.

For eg consider two mobilty controller operating in Master-standby mode.

Controller A--> Physical IP 10.10.10.1

Controller B--> Physical IP  10.10.10.2

Let the VIP be IP 10.10.10.3  floating between the two controllers. I have established a master-redundancy using the above vrrp.

Suppose  AP are campus AP trying to contact the controller on the VIP IP 10.10.10.3. I see the reply packets from the controller A(since it is the master) with source IP 10.10.10.1.

Shouldnt the AP get confused. It sent the packet to 10.10.10.3. It receives the reply from 10.10.10.1.

I did a packet pacture in other network (cisco,juniper) to see what is the source IP of reply packet. I see when i ping vip the reply packet has source IP as VIP and not the physical interface IP.

So looks like Aruba is not following the VRRP standard.

Anybody experienced this. Correct me if I am understanding it wrong.

Aruba- master / dns entry

What is the aruba-master dns entry the 10.1 or the 10.3 ?

There is one dns entry

VIP-10.10.10.3 ---aruba-master

no entry for others

DId you just recently made that change ?

I am wondering if when you made the change the AP was already talking to the 10.1 and it would stay that way until it reboots ?

Can you also do a nslookup to make sure the aruba-master is resolving to the 10.3?

Also do a show vrrp and make sure that it is up and running. 

Initially I had only one controller and it had 10.10.10.3

When i brought second controller I amde 10.10.10.3 as VIP and gave a new IP to both the controller.

This way no DNS changes. ALso I have rebooted all the APs.

DNS entry confirmed to be showing 10.10.10.3 for aruba-master

If you console into one of the APs can you see what is the IP is getting when it is booting up 

When it is booting up you will see the following : Master is ....<Master IP Address>

I sniffed the traffic in my network and I know its trying to contact the controller on 10.10.10.3.

The problem is why is the controller replying with 10.10.10.1 source ip instead of 10.10.10.3

I just doing some reading and it looks like when you sniff you supposed to see the following :

That under the internet protocol drop down you will see as the source address  the actual IP assigned to the controller and then under the Virtual Router Redundancy protocol drop down you will see the VIP .

Is that what your are seeing ?

I did a tcpdump on my device...and see the source/ destination ip as mentioned above. What you are saying is like capturing the packet and opening in a wireshark???

can you share your information source

Thanks

Should have shared this before , here you go :

This packet is vrrp management packet and does not relate to the topic in discussion. We are discussing the reply packet when an AP contacts the controller on VIP. The above packet is a vrrp packet exchange between two controllers.

Thanks

It should work fine.  There is no confusion.

yes it works fine. But the problem is it is not following vrrp standard and I will have to add two rules (one for AP->controller and other for controller->AP) on firewall.  When i had single controller. I had only one rule on my firewall from controller-AP.

So that has worked that way for a very long time.  You will have to have a separate  public and 1:1 nat for each controller's ip address.  You would then have the remote AP connect to a DNS A-record address that has both public addresses for redundancy/load balancing.

When there was a single controller. There was no question of vrrp. when i add the second controller the vrrp is not functioning in a standard way. AP reach to controller on VIP and the controller reply to AP with source IP of its physical interface rather than VIP. This is something suspicious for the firewalls in between. Packets go out for one destination. Reply come in with a different source!

I was provided a solution to convert all campus AP to RAP in order to get rid of this problem.

Thanks

Okay.  I thought you had remote APs, because it is a best practice to have your controller and your access points on the same side of the firewall.   I was wrong.  Is there a reason why your APs and your controller are on different sides of the firewall?  It becomes very difficult to support in that manner.

Okay, I think I am missing something.  Why is the controller directly connected to the internet?  You said you were not doing remote AP.  It should be inside, right?

People plan network keeping in mind all possibilities. In futture if a RAP is added we do not need to move controller to DMZ.

The whole point of this discussion is 'why is the controller replying with a physical interface IP instead of using VIP as source IP'. This makes the traffic coming from controller suspicious. Why does Aruba use a word VRRP when it is not following the standard. They should name it something like ARRP if its designing its own protocol!

Thanks

Frequently users ask specific questions on the forum and they never discuss the entire solution, so they get poor advice.  If we ask about the total solution, it saves time and energy because we can take so much more into account.

I do not know why Aruba does what they do with VRRP, but I do not see any indications of it being changed anytime soon.  That is why I was offering you alternatives.  Very few users put their controller and their access points on the opposite side of a firewall because of the difficulty of opening all those ports and maintaining a networked device in  DMZ.  If you placed it inside the firewall and did RAP, you would only have to open a single port.

I recently saw a cluster behave similar to what the OP described.

With CPsec enabled the source IP used by the controller for non-secure PAPI messages to an AP coming up initially is _not_ the VIP (as expected), but the respective controller IP (VRRP Master).

If there's no firewall in between the APs and the controllers you won't notice this glitch, but if you do have something with stateful port inspection in between, you're facing trouble.
Workaround suggested by TAC is to allow the controller IPs on the firewall as well.

However, it has to be noted that this is not exactly working as expected.

So Aruba finally acknowledged this bug and they promised to fix this. Thanks everyone for your help.

Do you have a bug number or other refference for this...  I am having a simmilar issue with an IPSec tunnel over a public network where the VRRP address is being static NAT.

This still appears to be an issue in Aruba OS 8...