Event-option policy UP event getting triggered before DOWN event for AE bundle and its child interface. This behavior appears when child interfaces of AE bundle flap within milliseconds, where both child interfaces including AE bundle are configured with event options.
For example :
Event-option for AE0 and its child interface xe-0/0/0:0 is not properly applied. After flap AE0 and xe-0/0/0:0 interface has come online but event-options do not trigger up-event.
MX>show log messages | match "SNMP_TRAP|EVENTD"
Feb 06 13:36:01
Feb 6 13:35:26.314 MX-re0 mib2d[10928]: SNMP_TRAP_LINK_DOWN: ifIndex 553, ifAdminStatus down(2), ifOperStatus down(2), ifName xe-0/0/1:0
Feb 6 13:35:26.409 MX-re0 mib2d[10928]: SNMP_TRAP_LINK_DOWN: ifIndex 840, ifAdminStatus down(2), ifOperStatus down(2), ifName ae0
Feb 6 13:35:26.409 MX-re0 mib2d[10928]: SNMP_TRAP_LINK_DOWN: ifIndex 549, ifAdminStatus down(2), ifOperStatus down(2), ifName xe-0/0/0:0
Feb 6 13:35:26.409 MX-re0 mib2d[10928]: SNMP_TRAP_LINK_UP: ifIndex 553, ifAdminStatus up(1), ifOperStatus up(1), ifName xe-0/0/1:0
Feb 6 13:35:26.462 MX-re0 mib2d[10928]: SNMP_TRAP_LINK_UP: ifIndex 549, ifAdminStatus up(1), ifOperStatus up(1), ifName xe-0/0/0:0
Feb 6 13:35:26.463 MX-re0 mib2d[10928]: SNMP_TRAP_LINK_DOWN: ifIndex 553, ifAdminStatus down(2), ifOperStatus down(2), ifName xe-0/0/1:0
Feb 6 13:35:26.463 MX-re0 mib2d[10928]: SNMP_TRAP_LINK_DOWN: ifIndex 549, ifAdminStatus down(2), ifOperStatus down(2), ifName xe-0/0/0:0
Feb 6 13:35:26.464 MX-re0 mib2d[10928]: SNMP_TRAP_LINK_UP: ifIndex 553, ifAdminStatus up(1), ifOperStatus up(1), ifName xe-0/0/1:0
Feb 6 13:35:26.464 MX-re0 mib2d[10928]: SNMP_TRAP_LINK_UP: ifIndex 549, ifAdminStatus up(1), ifOperStatus up(1), ifName xe-0/0/0:0
Feb 6 13:35:28.509 MX-re0 mib2d[10928]: SNMP_TRAP_LINK_UP: ifIndex 840, ifAdminStatus up(1), ifOperStatus up(1), ifName ae0
Feb 6 13:35:28.777 MX-re0 eventd: EVENTD_CONFIG_CHANGE_SUCCESS: Configuration change successful: while executing policy track_xe-0/0/1:0_status_down with user root privileges
Feb 6 13:35:29.884 MX-re0 eventd: EVENTD_CONFIG_CHANGE_SUCCESS: Configuration change successful: while executing policy update-on-snmp-trap-link-up with user root privileges
Feb 6 13:35:30.992 MX-re0 eventd: EVENTD_CONFIG_CHANGE_SUCCESS: Configuration change successful: while executing policy track_xe-0/0/0:0_status_up with user root privileges
Feb 6 13:35:32.131 MX-re0 eventd: EVENTD_CONFIG_CHANGE_SUCCESS: Configuration change successful: while executing policy track_xe-0/0/0:0_status_up with user root privileges
Feb 6 13:35:33.262 MX-re0 eventd: EVENTD_CONFIG_CHANGE_SUCCESS: Configuration change successful: while executing policy track_xe-0/0/1:0_status_down with user root privileges
Feb 6 13:35:35.211 MX-re0 eventd: EVENTD_CONFIG_CHANGE_SUCCESS: Configuration change successful: while executing policy track_xe-0/0/1:0_status_up with user root privileges
Feb 6 13:35:37.206 MX-re0 eventd: EVENTD_CONFIG_CHANGE_SUCCESS: Configuration change successful: while executing policy track_xe-0/0/0:0_status_down with user root privileges
Feb 6 13:35:39.329 MX-re0 eventd: EVENTD_CONFIG_CHANGE_SUCCESS: Configuration change successful: while executing policy update-on-snmp-trap-link-down with user root privileges <<<<
Feb 6 13:35:40.485 MX-re0 eventd: EVENTD_CONFIG_CHANGE_SUCCESS: Configuration change successful: while executing policy track_xe-0/0/1:0_status_up with user root privileges
Feb 6 13:35:42.597 MX-re0 eventd: EVENTD_CONFIG_CHANGE_SUCCESS: Configuration change successful: while executing policy track_xe-0/0/0:0_status_down with user root privileges <<<<
MX> show interfaces terse
Feb 06 13:43:39
Interface Admin Link Proto Local
xe-0/0/1:0.0 up up aenet --> ae0.0
xe-0/0/0:0.0 up up aenet --> ae0.0
ae0.0 up up inet 10.0.0.1/30
This applies to all the products that support automation/eventd.
This is working as designed. The behavior is seen because the events are generated in very short time range(subsecond/milliseconds time). In eventd, changing configuration from a policy, we fork and create a child process. This child process is used to push the intended commit. The scheduling of child process is unpredictable which causes the config commits not to being in different times.
This behavior is a product limitation. It is not a limitation of eventd, but the OS itself that if processes are spawned within mili seconds, we will not know which one executes first. This is scheduler-dependent.
Hence, to overcome this, use of event script can be explored as a solution.
https://www.juniper.net/documentation/us/en/software/junos/automation-scripting/topics/concept/junos-script-automation-event-notifications-and-policy-overview.html
By using slax scripts, there will be more control on timing and executing commands based on the current state.
Workaround: Not possible
Restoration steps: Manually activate the config which was deactivated using the event script for the interface down event.