Wireless Access

I posted a while back looking for clarification on the significance and usage of the "Y" flag (No SYN) in the datapath session output. As I do remote support for customers this is sometimes the only proof that something is or is not working. This time round my question is when I ping a connected client on a RAP I get the Y flag against the outbound echo request but not against the echo response entries. If I do the same thing on a CAP I get the reverse - the Y flag is against the echo responses. If I ping a bogus IP address I get no Y flag at all. Whats going on here - can anyone enlighten me?

Hi

Can you add some examples to clarify each of your questions ? Pinging from where - controller CLI or attached trusted wired device ? What RAP mode ? are you only checking the controller dp session table, what about for RAP if split/bridge are you also checking the on-ap session table.

From controller CLI (6.3.1.8) to CAP wifi client, I get no Y flags for responding pings, for unknown host (as long as there is route-cache to get out), I get Y flags as expected. The RAP case may be different, but need to know what you tested.

regards

-jeff

The pings are being run from the controller CLI primarily but the same is happening from other devices on the network. The clients are on bridge mode SSIDs.

The output I am looking at is from - show datapath session ap-name <apname>

can you show example output and note the version you are using ? bridge rap or cpsec cap ?

in my lab 6.4.x bridge cpsec cap not showing any flags for reachable icmp, unreachable tcp from ap side dp session table - there may be something buggy in here wrt flags it seems

>> ex ping and ssh from cap bridge client to unreachable IP

(sg-3200) #show datapath session ap-name ap105-24:78  | include 22,Flag
Source IP       Destination IP  Prot SPort DPort Cntr  Prio ToS Age Destination TAge Packets   Bytes     Flags           
1.2.3.4         172.16.1.25     6    22    53509 0     0    0   0   dev15       20   0         0
1.2.3.4         172.16.1.25     1    2     0     0     0    0   0   dev15       8    0         0         
1.2.3.4         172.16.1.25     1    1     0     0     0    0   0   dev15       20   0         0         
172.16.1.25     1.2.3.4         6    53509 22    0     0    0   0   dev15       20   0         0
172.16.1.25     1.2.3.4         1    2     2048  0     0    0   0   dev15       8    0         0         
172.16.1.25     1.2.3.4         1    1     2048  0     0    0   0   dev15       20   0         0         

>> ping from CLI to reachable bridge cap client

(sg-3200) #ping 172.16.1.25
Press 'q' to abort.
Sending 5, 92-byte ICMP Echos to 172.16.1.25, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4.411/7.658/20.38 ms

(sg-3200) #show datapath session table | include 172.16.1.25,Flag
Source IP       Destination IP  Prot SPort DPort Cntr  Prio ToS Age Destination TAge Packets   Bytes     Flags           
172.16.1.154    172.16.1.25     1    11    2048   0/0  0    0   0   local       1    1         120       FCI             
172.16.1.154    172.16.1.25     1    13    2048   0/0  0    0   0   local       1    1         120       FCI             
172.16.1.154    172.16.1.25     1    12    2048   0/0  0    0   0   local       1    1         120       FCI             
172.16.1.154    172.16.1.25     1    15    2048   0/0  0    0   0   local       1    1         120       FCI             
172.16.1.154    172.16.1.25     1    14    2048   0/0  0    0   0   local       1    1         120       FCI             
172.16.1.25     172.16.1.154    1    11    0      0/0  0    0   0   local       1    1         120       FI              
172.16.1.25     172.16.1.154    1    15    0      0/0  0    0   0   local       1    1         120       FI              
172.16.1.25     172.16.1.154    1    14    0      0/0  0    0   0   local       1    1         120       FI              
172.16.1.25     172.16.1.154    1    13    0      0/0  0    0   0   local       1    1         120       FI              
172.16.1.25     172.16.1.154    1    12    0      0/0  0    0   0   local       1    1         120       FI              

(sg-3200) #show datapath session ap-name ap105-24:78                         
Source IP       Destination IP  Prot SPort DPort Cntr  Prio ToS Age Destination TAge Packets   Bytes     Flags           
--------------- --------------- ---- ----- ----- ----- ---- --- --- ----------- ---- --------- --------- --------------- 
172.16.1.25     172.16.1.154    1    11    0     0     0    0   1   dev3        45   0         0         
172.16.1.25     172.16.1.154    1    15    0     0     0    0   1   dev3        45   0         0         
172.16.1.25     172.16.1.154    1    14    0     0     0    0   1   dev3        45   0         0         
172.16.1.25     172.16.1.154    1    13    0     0     0    0   1   dev3        45   0         0         
172.16.1.25     172.16.1.154    1    12    0     0     0    0   1   dev3        45   0         0         
172.16.1.154    172.16.1.25     1    11    2048  0     0    0   1   dev3        45   0         0         
172.16.1.154    172.16.1.25     1    13    2048  0     0    0   1   dev3        45   0         0         
172.16.1.154    172.16.1.25     1    12    2048  0     0    0   1   dev3        45   0         0         
172.16.1.154    172.16.1.25     1    15    2048  0     0    0   1   dev3        45   0         0         
172.16.1.154    172.16.1.25     1    14    2048  0     0    0   1   dev3        45   0         0  

rap bridge behaving the same as above.

Attached is a screenshot with the pings traffic boxed. The lower 5 are the ping requests and the upper ones are the ping responses. So there are Y flags on the echo requests.

strange, perhaps you have something enabled in firewall that is non standard, I am out of suggestions, next stop TAC case, sorry.

Sorry, forgot to add this is with version 6.1.3.5, the device is a RAP and the client is connected to a bridged SSID. Attached is a table showing the differences when running different commands and running pings to/from different devices.

i'll try a quick test in 6.1.3.5 for you tomorrow and let you know if i see the same, for sure 6.4 doesnt appear to behave this way.

MattF

Looks like 6.4 is the odd man out, where someone has potentially hidden the flags. will ask R&D about it, 6.1.3.x and 6.3.1.x behave the same as your observations for AP side datapath session table. So far, I dont find any issue with the controller side flags using any of same samples in this post. I will raise a bug to try and ascertain:

a> why the dp session table flags on AP are missing in 6.4.x

b> why they are not correct in 6.3.x and lower (and whether a> is the 'solution' to that)

regards

-jeff

Thanks, I appreciate your efforts.

any update on this jgoff?

hello boneyard

The missing flags is a bug, it has already been fixed in the R&D stream and needs to be backpropped. The value of the flags is another matter, the dev working the bug is yet to respond to that.

regards

-jeff

ok, thanks for the info.