MPLS Active-Standby multi-homing topology: When the primary routing-engine was restarted in the primary side (the active PE), customer frames started to be directed to the secondary side.
Based on the mastership log file, RE0 went into backup mode when it restarted, and then reclaim the master from RE1 at 21:11 on May 30. It will trigger the EVPN-MPLS AS multihoming status change.
May 30 21:08:00 mcontrol_notmaster
May 30 21:11:43 CHASSISD release 21.2R3-S7.7 built by builder on 2024-02-05 15:18:03 UTC
May 30 21:11:45 *** mcontrol init V01 ***
May 30 21:11:45 soft-restart: is not a master
May 30 21:11:45 initial vc state: initializing
May 30 21:11:45 vc vccb init, mid=255 sn=������������ slots=8
May 30 21:11:45 mcontrol_ore_alive_set: other RE is not alive
May 30 21:11:45 Socket = 0x00000038
May 30 21:11:45 mcontrol hipri thread created
May 30 21:11:45 *** re_priority is 1***
May 30 21:11:45 init master recon flag TRUE
May 30 21:11:45 event = E_CFG_M, state = init, param = 0x0x0
May 30 21:11:45 currentAction = A_REQC
May 30 21:11:45 send "claim mastership" request
May 30 21:11:45 Currentstate init NextState claim reason_code 0
May 30 21:11:45 new state = claim
May 30 21:11:45 mcontrol_init: Became backup.
May 30 21:11:46 mcontrol_send_re_info: allocated 21016 bytes for RE info
May 30 21:11:47 mcontrol_send_re_info: length is now 704 bytes for RE info
May 30 21:11:47 reallocated memory used for reading mcontrol messages to 20
May 30 21:11:47 mcontrol_ore_alive_set: other RE is alive
May 30 21:11:47 received version 1, "claim mastership" acknowledgement
May 30 21:11:47 event = E_ACK_C, state = claim, param = 0x0x0
May 30 21:11:47 currentAction = A_MASTER
May 30 21:11:47 The local RE becomes the master, retry = 0.
May 30 21:11:58 The local RE mastership transition completed.
May 30 21:11:58 Currentstate claim NextState master reason_code 0
May 30 21:11:58 new state = master
May 30 21:11:58 reallocated memory used for reading mcontrol messages to 9984
May 30 21:11:58 event = E_ORE_B, state = master, param = 0x0x9d73008
May 30 21:11:58 currentAction = A_NOOP
May 30 21:11:58 Currentstate master NextState master reason_code 0
May 30 21:11:58 vc master RE state change: initializing -> synching
May 30 21:11:58 vc master RE append vc ext enabled
May 30 21:11:58 mcontrol_send_re_info: length is now 908 bytes for RE info
May 30 21:11:59 mcontrol_chk_pfe_lnk_status_to_switch_master: The RE<->PFE link is up
May 30 21:12:13 reallocated memory used for reading mcontrol messages to 10012
May 30 21:12:13 vc master RE recv backup RE vc data, mid=255 sn=������������ slots=8
May 30 21:12:13 vc master RE state change: synching -> in-synch
It is an expected behavior.
For EVPN-MPLS Active-Standby multihoming, BGP protocol is used to synchronize the status of two EVPN PE routers.
There is no GRES, nor NSR (non-stop routing) configured in the device, which means there is no synchronization between two REs, when the primary RE restarted, the BGP status might be reset and the EVPN standby PE could be switched into forwarding mode, it is expected.
NSR, database-replication is not running:
------------------------------------
root@and39-fst-re0> show database-replication summary
warning: replication-process subsystem not running - not needed by configuration.
root@and39-fst-re0> show database-replication statistics
Since the key data was not collected during the switch stage, I use the following lab data as example to explain:
#router02: --> moves from blocking to forwarding
Protocol bridge, MTU: 9192, Generation: 221, Route table: 9, Mesh Group: __all_ces__, EVPN multi-homed status: Blocking, Next-hop: 4371, vpls-status: up
---(refreshed at 2024-05-23 04:25:26 UTC)---
Protocol bridge, MTU: 9192, Generation: 221, Route table: 9, Mesh Group: __all_ces__, EVPN multi-homed status: Forwarding, Next-hop: 4371, vpls-status: up
#router01: --> moves from forwarding to blocking
Protocol bridge, MTU: 9192, Generation: 218, Route table: 9, Mesh Group: __all_ces__, EVPN multi-homed status: Forwarding, Next-hop: 4302, vpls-status: up
---(refreshed at 2024-05-23 04:25:25 UTC)---
Protocol bridge, MTU: 9192, Generation: 218, Route table: 9, Mesh Group: __all_ces__, EVPN multi-homed status: Blocking, Next-hop: 4302, vpls-status: up
As you can see, since the BGP protocol synchronizes the status of two multihoming PE routers, if there are some issues in the network, active/standby status may switch between two PE devices.
In above case, old primary router01 moved from forwarding to blocking, and router02 moved from blocking to forwarding. This is totally fine and following the RFC standard.