Switching

Hi Community,

 

I have this log on our ex4200-24t switch, and I have no idea what it mean or how to clear it.

 

ifl_pfestat_add_async_sync_dependency: No dependency for this ifl

 

your help and feedback is greatly appreciated.

 

regards 

 

 

Hi mkhangi,

 

Those logs do not indicate any functionality breakage/impact.  If you reduce logging level, you would not see them.  Please see this for explanation: https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1239651

 

If you need to enable "syslog any any" for recording log messages, then you would need add to skip these logs with appropriate match condition : https://kb.juniper.net/InfoCenter/index?page=content&id=KB9382

 

Hope this helps.

 

Regards,
-r.

--------------------------------------------------

If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated :).

 

Hi Mriyaz,

 

thank you for the feedback.

I just wanted to know the meaning of the log, specially that it is happening in more than one device

 

is it from the forwading engine? or is it memory realated?

 

best regards 

Hi mkhangi,

 

This log is just indicating there were two requests (say one from CLI command and one from SNMP polling) for the same IFL stats at the same time.  Kernel receives both requests and sends one query to the PFE and waits for a response.  In this case, kernel just sends one query to PFE for the stats for ethernet IFLs.  And the PFE response will be forwarded to both the applications (say SNMP and CLI) that made the request.   In this case, we will see the log message printed in Syslog if the logging level is configured to "any any".  It's a DEBUG log so we won't see it if the logging level is reduced.  Please note that for non-ethernet IFLs (like atm etc.), the kernel will send two duplicate queries to the PFE and such logs won't be seen.   

 

What is IFL? Here are some abbreviatons for interface attributes you might see in Junos logs:

ifd	Refers to a physical device
ifl	Refers to a logical device
iff	Refers to an address family
ifa	Refers to an address entry
iif	Refers to an incoming interface, either an ifd or an ifl (uses a kernel interface index, not an SNMP index)

 

Hope this helps.  Please let me know.

 

Regards,
-r.

--------------------------------------------------

If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated :).

 

Hi Mriyaz,

 

Thank you for the feedback, the picture is becoming clearer now.

 

One last question, is there a way to find out which logical (IFL) being polled therefore causing this debug log? the log messages themeselves do not contain further information such as the IFL index for instance.

 

Appreciate your help

 

best regards 

Hi mkhangi,

 

You can try this:

 

From CLI:
set system syslog file messages kernel any

 

From command prompt (start shell):
sysctl net.pfe.pfestat_log_enable=4

 

Then, once you execute some interface stats command from cli ("show interfaces extensive <intf#>"), you can check the logs in /var/log/messages for IFL index.

Example:
For this interface: Logical interface xe-0/1/1.0 (Index 120) (SNMP ifIndex 893) (Generation 202)

Sample Log messages:
/kernel: pfestat: req id 45585 type 16 ipc type 3 subtype 25 uniq 120 inuse 1 sendmask 0000000000000004
/kernel: pfestat_req_receive entry req(0x842a4140) uniquifier(120) msg(0x83a30000) peer_index(2) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
/kernel: pfestat: receive req id 45585 type 16 rel_id 0 ipc type 3 subtype 25 uniq 120 peer 2 sendmask 0000000000000000 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
/kernel: pfestat: req id 45587 type 16 ipc type 3 subtype 25 uniq 120 inuse 1 sendmask 0000000000000004
/kernel: pfestat_req_receive entry req(0x83c6a8c0) uniquifier(120) msg(0x83a30000) peer_index(2)
/kernel: pfestat: receive req id 45587 type 16 rel_id 0 ipc type 3 subtype 25 uniq 120 peer 2 sendmask 0000000000000000

 

Hope this helps.

 

Regards,
-r.

--------------------------------------------------

If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated :).

Hi Mriyaz,

 

I think we are getting somewhere, I was able to trace it:

Feb 27 15:31:12   /kernel:  ENTRY TIME in: rts_iflsmproc is:1551252672.593165767 sec

Feb 27 15:31:12   /kernel:  rts_iflsmproc ifl index=73, relay id=0 app id=7cflags=0x0, op=4, seq '23858760', who=2

Feb 27 15:31:12  /kernel: pfestat_req_create entry info(0x97765c6c) ops(0x97765b28)

Feb 27 15:31:12   /kernel: pfestat_req_add entry

Feb 27 15:31:12   /kernel: pfestat_table_add entry

Feb 27 15:31:12   /kernel: pfestat_table_add exit

Feb 27 15:31:12   /kernel: pfestat_req_add exit

Feb 27 15:31:12   /kernel: pfestat_req_create: req id 23415 type 16 subtype 23744 cflags 0x0 relay_id 0

Feb 27 15:31:12   /kernel: pfestat_req_create exit req(0x83ef0dd0)

Feb 27 15:31:12   /kernel: ifl_pfestat_add_async_sync_dependency: No dependency for this iflpfestat_req_expect entry

Feb 27 15:31:12   /kernel: pfestat: req id 23415 type 16 ipc type 3 subtype 25 uniq 73 inuse 1 sendmask

Feb 27 15:31:12  /kernel: 0000000000000004pfestat_req_expect exit

 

traced it back to 

 

 show interfaces extensive | match ifIndex | match 73

 Logical interface vlan.3029 (Index 73) (SNMP ifIndex 631) (HW Token 3029) (Generation 138)

 

now that I know which logical interfaces are causing these logs, can they be stopped? or is reducing the debuggin level is the only solution for these messages?

 

Again thank you alot for your feeback, I have been at it for a week. I only started making progress 2 days ago thanks to you.

 

best regards 

Hi mkhangi,

Glad that helped, please mark the relevant post as "Accepted Solution" so others can benefit too.

"now that I know which logical interfaces are causing these logs, can they be stopped? or is reducing the debugging level is the only solution for these messages?"
Two possible solutions are -
a) Reducing the debugging level or
b) Suppressing the log messages using filters as explained here: https://kb.juniper.net/InfoCenter/index?page=content&id=KB9382
One word of caution, please revert the change to avoid flooding the log messages with kernel logs i.e. from command prompt (start shell):
sysctl net.pfe.pfestat_log_enable=0
Hope this helps.
Regards,
-r.
--------------------------------------------------
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated :).