SIP aged-out session being left in the DISCARD state

[TranceforLife]

Hi Guys,

Has anyone come across this when the aged-out SIP session being left in the DISCARD state and the only way you can fix the issue is to clear the session with > clear session id 380025 command.

xxxxxxxxxxxxxx(active)> show session all filter source xxxxxxxxxxxxxx
--------------------------------------------------------------------------------
ID          Application    State   Type Flag  Src[Sport]/Zone/Proto (translated IP[Port])
Vsys                                          Dst[Dport]/Zone (translated IP[Port])
--------------------------------------------------------------------------------
293393       sip            ACTIVE  PRED       xxxxxxxxxxxxxx[0]/Campus/17  (xxxxxxxxxxxxxx[0])
vsys1                                         xxxxxxxxxxxxxx[5060]/DC-DMZ  (xxxxxxxxxxxxxx[5060])
364602       sip            ACTIVE  FLOW       xxxxxxxxxxxxxx[5060]/Campus/17  (xxxxxxxxxxxxxx[5060])
vsys1                                         xxxxxxxxxxxxxx[5060]/DC-DMZ  (xxxxxxxxxxxxxx[5060])
380025       sip            DISCARD FLOW       xxxxxxxxxxxxxx[5060]/Campus/17  (xxxxxxxxxxxxxx[5060])
vsys1                                         xxxxxxxxxxxxxx[5060]/DC-DMZ  (xxxxxxxxxxxxxx[5060])
xxxxxxxxxxxxxx(active)> show session id 380025

Session          380025

        c2s flow:
                source:     xxxxxxxxxxxxxx [Campus]
                dst:         xxxxxxxxxxxxxx
                proto:       17
                sport:       5060            dport:      5060
                state:       DISCARD         type:       FLOW
                src user:    unknown
                dst user:    unknown
                offload:     Yes

        s2c flow:
                source:     xxxxxxxxxxxxxx [DC-DMZ]
                dst:         xxxxxxxxxxxxxx
                proto:       17
                sport:       5060            dport:      5060
                state:       DISCARD         type:       FLOW
                src user:    unknown
                dst user:    unknown
                offload:     Yes

        DP                                   : 0
        index(local):                        : 380025
        start time                           : Tue Feb 22 07:54:47 2017
        timeout                              : 60 sec
        time to live                         : 59 sec
        total byte count(c2s)                : 18691897
        total byte count(s2c)                : 18853287
        layer7 packet count(c2s)             : 34237
        layer7 packet count(s2c)             : 34185
        vsys                                 : vsys1
        application                          : sip 
        session to be logged at end          : False
        session in session ager              : True
        session updated by HA peer           : False
        layer7 processing                    : enabled
        URL filtering enabled                : True
        URL category                         : any
        session via prediction               : True
        use parent's policy                  : True
        parent session                       : 124110
        refresh parent session               : True
        session via syn-cookies              : False
        session terminated on host           : False
        session traverses tunnel             : False
        captive portal session               : False
        ingress interface                    : ethernet1/23
        egress interface                     : ethernet1/24.3306
        session QoS rule                     : N/A (class 4)
        tracker stage firewall               : session rematch
        end-reason                           : aged-out
xxxxxxxxxxxxxx(active)> clear session id 380025

Thx,

Myky

pinging @reaper@BPry@kiwi

[reaper · Accepted solution]

yes

yes i have 😉

the DISCARD stage has a really short lifespan, but that lifespan keeps getting refreshed as long as packets are received that match the discarded session, this so stray packets get cleaned up and you don't get odd non-syn packets

on rare occasions a session may get terminated but then

A) one side is not in agreement of closing the session and simply keeps sending packets

B) a new session negotiation with identical tuples is immediately started, inside the discard stage which triggers the refresh

best way is to try and find out if one of the above scenarios is true and then decide if you want to increase the timeout on your sip application, or decrease the lifetime of the discard stage

[BPry]

You guys are up way to early\late 😉

@TranceforLife this is an article that specifically talks about what is likely happening. I've seen it more with SIP than most things but other applications likely run into the same scenario occasionally without anyone noticing. 

https://live.paloaltonetworks.com/t5/Management-Articles/Discard-Session-Rematch/ta-p/60043

[TranceforLife]

Guys,

Thanks as always. Friday is getting busy. Will review all this and get back.

Have a good day ahead!

thx,

Myky

[TranceforLife]

Hi @reaper

As l understood this correctly SIP session being identified by Palo as aged-out (no keep alive received from the client). Then session state changed to the DISCARD (which also got some little timeout value) and after session removed from the table. So this looks like as per your comment that the good traffic again sent my client withing this "little timeout interval", but because session already in DISCARD state Palo will not change it to ALLOW hence all traffic dropped. 

Thx,

Myky

[reaper]

exactly 🙂

[TranceforLife]

Thanks clear as a day (unfortunately not in UK , haha where always rains).  Do you think might worth to check the SIP system to ensure it sends keepalive messages withing one-hour interval? Not sure if it actually should if no data transmitted.

[BPry · Accepted solution]

@TranceforLife, 

Likely you wouldn't need it to be sending a keep-alive message if it didn't have anything to communicate unless you are running on a hosted system. I've seen hosted systems have a time-out on the user login where the phone would physically logoff the hosted provider if a keep-alive message was not sent. 

[TranceforLife]

I owe you guys !