Higher Education

Has anyone tested the L2/L3 aggregation using the AP225s and 6.3.1 ?

We have it runnning on a testbed and just finding it odd how the GRE Striping IP is utilized.

The IP does migrate if you're using L2 VRRP redundancy on the lms-ip which is good, but

it does add a substantial delay (upto 30sec) for the GRE Striping tunnel to get dragged along.

(A typical VRRP change is handled in less than 5sec)

The primary question I have is if the GRE Striping IP need to be a routable address anywhere?

I've tested it with addresses on the controller's primary VLAN, with addresses on a secondary

VLAN, and even with private 172.30.x.y addresses that don't show up anywhere else on the 

controller or network.  I'm not sure if I'll run into some problem later if I use private addresses on the

GRE Striping IP?  I included the relevant section from the User Guide.  The example shows using

a GRE Striping IP on the same subnet as the LMS, but doesn't really say if that's required.

-----------------------------------------------------------------------------

The GRE striping IP needs to be routable between the controller and AP.  

        5G     src=X -------GRE TUNNEL--------------> Dest: Controller-IP-Y

AP                                                                                                                              CONTROLLER

       2.4G   src=X ------GRE TUNNEL--------------> Dest: Controller-IP-Y+1

Thanks, makes sense.

Your post brings up another question, is it required that the GRE Striping IP address

be one higher than the LMS address?  Both the UG example and yours seem to imply

so.

That's the way it has been explained to me. I'm not sure if it is a supported config or required config.

Thanks again.. I finally did some verified tests passing traffic (had to find a laptop and lock it to the 2.4GHz band)

and can say that:

1) the LMS IP and the GRE STRIPING IP have to be on the same subnet

2) the two IP's don't have to be sequential.  (But they DO need to hash to different LACP ports,  Odd/Even, etc.)

3) this works over VRRP, just slows the transfer

thanks

mike

Follow-up question, in pulling data from the tests to verify operation, it appears that the AP is using it's ENET interface as half-duplex? (Both Radios transmitting on one ENET and both receiving on the other)  I ran bandwidth tests from a 2.4GHz client to 2 different sites, then followed the same tests on different 5GHz client.

Can someone verify or deflect my testing as flawed?

(aruba) #show ap debug lacp ap-name ap-3

AP LACP Status
--------------
Link Status  LACP Rate  Num Ports  Actor Key  Partner Key  Partner MAC
-----------  ---------  ---------  ---------  -----------  -----------
Up           slow       2          17         1            78:ff:33:00:00:00
Slave Interface Status
----------------------
Slave I/f Name  Permanent MAC Addr  Link Status  Member of LAG  Link Fail Count
--------------  ------------------  -----------  -------------  ---------------
eth0            6c:f3:7f:77:75:4c   Up           Yes            0
eth1            6c:f3:7f:77:75:4d   Up           Yes            0
GRE Radio Traffic Received on Enet Ports
----------------------------------------
Radio Num  Enet 0 Rx Count  Enet 1 Rx Count
---------  ---------------  ---------------
0          101864           0
1          80001            0
Traffic Sent on Enet Ports
--------------------------
Radio Num  Enet 0 Tx Count  Enet 1 Tx Count
---------  ---------------  ---------------
0          295              46725
1          259              65479                 
non-wifi   2                6977

Is your edge switch configured to load-balance based on the source IP for port-channels?

Thank you, yes the switch does support L3 load-balance, but as you may have

already guessed, it's a simple Odd/Even algorithm which takes us back to the

GRE-Striping-IP getting set to LMS-IP +1

Our numbering scheme doesn't have the +1 address available, so of course I

used the +2 which made both of the IPs Odd.  I just grabbed a high Even IP

that was unused and the traffic distribution is more like I'd expect..

GRE Radio Traffic Received on Enet Ports
----------------------------------------
Radio Num  Enet 0 Rx Count  Enet 1 Rx Count
---------  ---------------  ---------------
0          128411           0
1          0                69823
Traffic Sent on Enet Ports
--------------------------
Radio Num  Enet 0 Tx Count  Enet 1 Tx Count
---------  ---------------  ---------------
0          50               47807
1          62845            0                     
non-wifi   2                1207

Thanks again

mike