Wireless Access

last person joined: 19 hours ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

show datapath session....Help!

This thread has been viewed 17 times
  • 1.  show datapath session....Help!

    Posted Jan 28, 2017 09:54 PM

    Hello,

    I am new to Aruba and am experiencing an issue that I can’t seem to get my head around.

    I have two clients, when placing a jabber SIP call from one to the other the call will complete but the calling station will have one way audio and the called party will have 2 way audio.  I have trouble shot this down to my Aruba controller where I see when looking at the data path session:

     

    (Aruba7010) #show datapath session table 192.168.3.2 | include 16680
    192.168.3.2    192.168.3.1    17   22118 16680  0/0     0    0   0   local       c7   83109604   690679436  FY
    192.168.3.1    192.168.3.2    17   16680 22118  0/0     0    46  0   local       c7   9692       581412     FC
    
    (Aruba7010) #show datapath session table 192.168.3.2 | include 16680
    192.168.3.2    192.168.3.1    17   22118 16680  0/0     0    0   0   local       c7   83310875   702749972  FY
    192.168.3.1    192.168.3.2    17   16680 22118  0/0     0    46  0   local       c7   9714       582732     FC

     

    From researching this I have concluded that the problem is most likely related to the “Y” flag on the return flow.  From what I can find out the “Y” means [No-Sync] and there is no return traffic matching the flow.  What I am not understanding is that there is return traffic and the Aruba controller even sees it as indicated by the “Byte” “Packet” fields being populated and incromenting.

     

    Is it normal for there to be a “Y” flag on a datapath session that also included a packet and byte count?

     

    Thank you in advanced!



  • 2.  RE: show datapath session....Help!

    EMPLOYEE
    Posted Jan 28, 2017 10:05 PM

    The Y flag specifically means no syn.  Only TCP connections have a syn so a Y flag for UDP connections is normal.

     

    What kind of clients are these?

     

    Typically one sided audio is because the access points power does not match that of the client, so either the client can see the AP well, but the AP cannot hear it well (power on AP too high) or vice versa...



  • 3.  RE: show datapath session....Help!

    Posted Jan 28, 2017 10:39 PM

    The Clients are laptops with Cisco Jabber behind a VPN terminated at the controller.  The clients seem to be ok to the AP, the issue persists even if you are wired directly to the controller and seems to be more in relation to the VPN session from what I can tell.  The Cisco Jabber SIP call works just fine when calling from Client 1 “inside the VPN” and Client 2 “outside the VPN” both being on the same subnet.  The issue only arising when both clients pass traffic through the VPN to each other.

     

    When watching call setup happen using Wireshark on both clients you can see that the calling station never gets RTCP packets (the flow marked as “FY”) and the RTP stream itself (also marked as “FY”) seem to disappear at the Controllers VPN interface.  This is what got me investigating the Y as only the affected traffic is marked as such.

     

    Also it should be noted that the one way voice issue is always bound to the call originator, regardless if client 1 calls client 2 or vice-versa.  The receiver always has two way voice and its return RDP/RTCP traffic seems to show on the controller but never arrives at the other endpoint.

     

    I’m currently at a dead end and don’t know what else to check for on the Aruba.

     

    Thank you for your reply.

     



  • 4.  RE: show datapath session....Help!

    EMPLOYEE
    Posted Jan 29, 2017 06:46 AM

    When you say "a VPN Terminated at the controller" do you mean the clients have VPN software and that software is terminated at the controller?

     

    What VPN software is the client using?  Where is the Jabber Server?

     

     



  • 5.  RE: show datapath session....Help!

    Posted Jan 29, 2017 01:15 PM
    yes the controller is the VPN server and the clients use VIA software. The jabber server sits local to the same router as the controller just on a separate subnet, it's a CUCM and CUPS pare. the servers provides XMPP and SIP, every thing going works fine with the exception of jabber SIP calls from one client to another if they both terminate a VPN at the same Aruba controller.


    #AirheadsMobile


  • 6.  RE: show datapath session....Help!

    EMPLOYEE
    Posted Jan 29, 2017 06:40 PM

    Did you ask Cisco whether or not your configuration was supported? 



  • 7.  RE: show datapath session....Help!

    Posted Jan 30, 2017 03:07 AM
    The issue seemed to be more to be an issue with the Aruba controller from what I can tell. A wireshark off the VIA interface showes that the packets don't make it back to the calling station though they seem to be being sent out of the Aruba. My original question was mostly posed to how to track down where UDP packets are going as there dosent seem to be an issue with the Aruba...but that's the last place they are ever seen so something must be going on there. Whether my typology is supported by Cisco isn't exactly a concern for now. I'm looking for advice or information on why the Aruba does not seem to be sending out the RTP stream. If I send them out with a TTL of 20 and they are never routed they should reach the other interface and seen on a packet scan regardless if what the Cisco client thinks of it. I'm going to attempt to see if I can find evidence of the traffic on the cipher side of the VPN or not. If it looks like it's leaving the Aruba on the cipher side that should rule it out but otherwise I'm not sure what to do. the Aruba looks like it's sending it out but all other evidences says it's not, all I know to look for is "show datapath session table x.x.x.x". Is there any commands to look at VPN counters or any thing like that? I'm appreciative of any helpful information and your reply and I apologize because my question sounds kind of "do my work" to me but I'm having a hard time finding information about the Aruba relevant to my situation.


    #AirheadsMobile


  • 8.  RE: show datapath session....Help!

    EMPLOYEE
    Posted Jan 30, 2017 06:11 AM

    I apologize.  I was only asking if Cisco supported this configuration, because I have not personally deployed jabber over a VPN before and was wondering if there was some specific limitation.

     

    Are your VPN clients fully tunneled or split?  Do they have fully routable addresses in your network or a pool that only exists within the controller?



  • 9.  RE: show datapath session....Help!

    Posted Jan 30, 2017 09:07 AM

    Did you only test with the Cisco Jabber client or did you try other applications as well? One-way audio could  be a result of a routing issue, like asymmetric routing or maybe a firewall issue.

     

    That's why I ask if you tested other applications as well.



  • 10.  RE: show datapath session....Help!

    Posted Jan 30, 2017 01:26 PM
    I have done Web browsing and the like, all that works well but that's the only other data product the clients have outside of XMPP and SIP calling. We do not have split tunneling configured. all I addresses are globally routed, no NAT ether. I don't think it would be async routing issue as the 2 clients are on the same subnet/vlan and are matching a forward rule in the Aruba so no routing should be routed except call setup by the CUCM/CUPS to and from the clients, all call setup looks fine. The issue seems be when the Cisco server hands off control and the clients actuly talk to each other. I have also tried a setup in troubleshooting where both clients and the CUCM cluster are routed I sted of forwarded though the same odd behavior continues, when one client is on VPN and the other is not every thing works but when both clients terminate on the same Aruba the RTP stream seams to not make it out of the Aruba to the other client.


    #AirheadsMobile