Controller-less WLANs

How to confirm if no traffic is being dropped on IAP for client connectivity issue

by on ‎07-04-2014 02:31 AM

If a wireless/Wired client connected to IAP could not pass traffic, we could check below

1. We can check if the traffic is denied by the IAP, which can be confirmed by below command. If the FLAG is D it shows that the traffic is denied due to ACL

# show datapath session
Datapath Session Table Entries
 
------------------------------
 
Flags: F - fast age, S - src NAT, N - dest NAT
       D - deny, R - redirect, Y - no syn
       H - high prio, P - set prio, T - set ToS
       C - client, M - mirror, V - VOIP
       I - Deep inspect, U - Locally destined
       s - media signal, m - media mon, a - rtp analysis
RAP Flags: 0 - Q0, 1 - Q1, 2 - Q2
 
  Source IP     Destination IP  Prot SPort DPort  Cntr Prio  ToS Age Destination   TAge Flags
--------------  --------------  ---- ----- -----  ---- ----  --- --- -----------   ---- -----
10.17.33.233    10.240.122.56   6    22    59003     0    0    4   0   dev4        107  R
10.17.168.233   10.17.32.247    17   54463 4500      0    0    4   0   local       bdd1 FC
10.240.122.56   10.17.33.233    6    59032 4343      0    0    0   1   dev4        5c   FC
10.240.122.56   10.17.33.233    6    59033 4343      0    0    0   1   dev4        5c   FC

2. If the traffic is not denied we could debug the packet on the IAP and Match the ingress/Egress of to/fro packets to identified if it is going through right interface. Example: Below user could not ping its gateway and could not learn its ARP.

Datapath Bridge Devices
-----------------------------
Flags: F - source-filter, T - trusted, Q - tagged, I - IP
       S - split-tunnel, B - bridge, M - mesh, P - PPPoE
       C - content-filter, O - corp-access, h - to HAP, f - to FAP
       h - dhcp-redirect b - blocked by STP
 
Dev  Name                      VLANs  PVID   ACLs   FramesRx  FramesTx  Flags
---  ------------------------  -----  ----  ------  --------  --------  --------
3    bond0                     4095   1       0/0      69206     12627  FTQB
6    gre0                      2      0       0/0      24476       522  FTQB
8    br0                       0      1     105/0      18757         0  IB
12   aruba000                  4095   1       0/0          0      1599  TQBM
13   aruba002                  1      2030  109/0          0       519  B
14   aruba102                  1      2030  109/0        734       524  B
15   aruba003                  1      2029  142/0          0       142  B
16   aruba103                  1      2029  142/0          0       142  B
 
Datapath Bridge Table Entries
-----------------------------
Flags: P - Permanent, D - Deny, R - Route, M - Mobile, X - Xsec, A - Auth
AP Flags: X - Awaiting 1X reply, B - Block all non-1X traffic, F - Force bridge role
 
      MAC          VLAN  Assigned VLAN  Destination  Flags  AP Flags  Bridge Role ACL
-----------------  ----  -------------  -----------  -----  --------  ---------------
00:22:FA:EB:55:A8  2030  2030           dev14                                       0  >>>>>>>>>> this user connected to Vlan 2030 / Dev 14 = aruba102 VAP.
18:64:72:C0:93:28  1     1              local        P                              0
18:64:72:C0:93:28  3333  3333           local        P                              0
AC:16:2D:9B:F2:5E  2030  2030           dev6                                        0
88:5A:92:C3:8F:1B  1     1              dev3                                        0


We can check the packet debug for ARP

Received packet from aruba102 (timestamp 0000179748)
[asap_firewall_forward(4428):firewall entry] len 42, vlan 0, egress CP, ingress aruba102:
  #mac: etype 0806 smac 00:22:fa:eb:55:a8 dmac ff:ff:ff:ff:ff:ff
  #arp: opcode 1, sip 192.168.0.150, tip 192.168.0.4, smac 00:22:fa:eb:55:a8, tmac 00:00:00:00:00:00
[asap_firewall_forward(5120):bridge section] len 42, vlan 2030, egress CP, ingress aruba102:
[asap_firewall_forward(5222):session section] len 42, vlan 2030, egress vlan 2030, ingress aruba102:
[asap_firewall_forward(5856):route section] len 42, vlan 2030, egress vlan 2030, ingress aruba102:  <<<< it shows the ARP request coming from aruba102 VAP and eress Vlan 2030


In the ARP response we could see

Received packet from gre0 (timestamp 0000179257)
[asap_firewall_forward(4428):firewall entry] len 46, vlan 0, egress CP, ingress gre0:
  #mac: etype 8100 smac 00:0b:86:16:6b:00 dmac 00:22:fa:eb:55:a8
  #vlan 2030, prio 0, etype 0806
  #arp: opcode 2, sip 192.168.0.4, tip 192.168.0.150, smac 00:0b:86:16:6b:00, tmac 00:22:fa:eb:55:a8
[asap_firewall_forward(5222):session section] len 46, vlan 2030, egress CP, ingress gre0:
[asap_firewall_forward(5856):route section] len 46, vlan 2030, egress CP, ingress gre0:
[asap_firewall_forward(5872):cp route section] len 46, vlan 2030, egress CP, ingress gre0:
[asap_firewall_forward(6108):forward section] len 46, vlan 2030, egress CP, ingress gre0:
[asap_firewall_forward(6448):stack section - protocol 0x8100, pkt type 0] len 46, vlan 2030, egress CP, ingress gre0: <<  to work the egress should be aruba102 VAP
[asap_firewall_send_up_stack(2803):going to stack protocol:0x806 type:0] len 28, vlan 2030, egress CP, ingress br0:
  #arp: opcode 2, sip 192.168.0.4, tip 192.168.0.150, smac 00:0b:86:16:6b:00, tmac 00:22:fa:eb:55:a8


Hence the packet were not reaching the client.

 
[asap_firewall_forward(5872):cp route section] len 42, vlan 2030, egress vlan 2030, ingr

 

Search Airheads
Showing results for 
Search instead for 
Did you mean: 
Is this a frequent problem?

Request an official Aruba knowledge base article to be written by our experts.