Symptom
The output to show session id does not show the security rule that the traffic is hitting. In the example below the security rule matched by the traffic is not present:
> show session id 4960
Session 4960
c2s flow:
source: 192.168.9.1 [trust_9999]
dst: 192.168.7.2
proto: 17
sport: 60909 dport: 162
state: ACTIVE type: FLOW
src user: panrcks\administrator
dst user: unknown
s2c flow:
source: 192.168.7.2 [trust_8888]
dst: 192.168.9.1
proto: 17
sport: 162 dport: 60909
state: ACTIVE type: FLOW
src user: unknown
dst user: panrcks\administrator
start time : Sun Feb 3 03:10:53 2013
timeout : 327 sec
time to live : 202 sec
total byte count(c2s) : 1124
total byte count(s2c) : 590
layer7 packet count(c2s) : 1
layer7 packet count(s2c) : 1
vsys : vsys1
application : snmp-trap
session to be logged at end : True
session in session ager : True
session synced from HA peer : False
layer7 processing : enabled
URL filtering enabled : False
session via sun-cookies : False
session terminated on host : Ture
session traverses tunnel : False
captive portal session : False
ingress interface : ethernet1/3
egress interface : ethernet1/2
diffserv marking IP DSCP : 0x34
session QoS rule : N/A (class 4)
Cause
Session information with missing security rule information will appear if a security rule is modified or deleted, but there are still active sessions that match the rule. The sessions will continue to exist due to the traffic, but the rule information will not be present as the rule has been modified or no longer exists. The traffic logs will still show the security rule and all other information accurately.
Note: If it is required that a session should be checked against the new security rules after the configuration change, then the rematch sessions feature should be turned on. See the following document for details on session rematch:How Session Rematch Works.
owner: sdurga