Traffic was looping within the Virtual Chassis (VC), resulting in a temporary outage that impacted multiple flows in the EX4400 VC operating with VXLAN enabled.

• When a UFT profile change is applied on a standalone switch, it leads to a PFE restart. 
• However, in a Virtual Chassis setup, the entire VC must be rebooted for the new UFT profile to take effect across all members.
• If this full reboot is not performed, the VC can enter an inconsistent state when some individual members are later rebooted/replaced. This occurs because the rebooted members load the new UFT profile while the remaining members continue to operate with the old one.
• In such scenarios, a full, coordinated reboot of all VC members is required to ensure a consistent UFT profile across the chassis and to restore stable traffic forwarding.

In this example, the customer configured the “vxlan-gbp-l3-profile” on their Virtual Chassis but did not perform a full VC reboot afterward.

When the customer later replaced FPC1 (that resulted in the reboot of that member), an outage occurred. This caused the rebooted member to load the updated UFT profile while the remaining members continued using the old one, leading to an inconsistent UFT profile across the VC.

The following log messages will appear the syslog, indicating the members that require a reboot after the UFT change.

Nov 19 07:08:33.370 router dc-pfe[17620]: Reboot required to change current UFT mode from: 2 to: 12

Nov 19 07:08:33.373 router fpc0 Reboot required to change current UFT mode from: 2 to: 12

Nov 19 07:08:36.468 router fpc2 Reboot required to change current UFT mode from: 2 to: 12

Nov 19 07:08:37.738 router fpc3 Reboot required to change current UFT mode from: 2 to: 12

Nov 19 07:08:39.035 router fpc4 Reboot required to change current UFT mode from: 2 to: 12

Nov 19 07:08:40.320 router fpc5 Reboot required to change current UFT mode from: 2 to: 12

In the following log, FPC 1 was rebooted and is now using the newly configured profile, which is why it’s not listed in this update. Please verify the uptime of all members to confirm.

user@router> show chassis fpc detail

Slot 0 information:

Start time 2025-09-13 13:42:39 UTC

Uptime 66 days, 18 hours, 3 minutes, 11 seconds

Slot 1 information:

Start time 2025-10-18 08:55:59 UTC. -> FPC 1 was rebooted

Uptime 31 days, 22 hours, 49 minutes, 51 seconds

Slot 2 information:

Start time 2025-09-13 13:42:37 UTC

Uptime 66 days, 18 hours, 3 minutes, 14 seconds

Slot 3 information:

Start time 2025-09-13 13:42:37 UTC

Uptime 66 days, 18 hours, 3 minutes, 14 seconds

Slot 4 information:

Uptime 66 days, 18 hours, 3 minutes, 14 seconds

Last reboot reason 0x1:power cycle/failure

Slot 5 information:

Start time 2025-09-13 13:42:42 UTC

Uptime 66 days, 18 hours, 3 minutes, 9 seconds

The CLI output might suggest an incorrect UFT mapping, and we’ve raised a PR address it. However, this can be verified on the hardware using the following shell commands.

cprod -A fpc1 -c "show cmqfx pic”  | grep uft

ASIC init Done: 1

uft_config: 12  <———————————— current active UFT profile number.

uft_num_prefix: 1

cprod -A fpc0 -c "show cmqfx pic”  | grep uft

uft_config: 12  <———————————— current active UFT profile number.uft_num_prefix: 1

Here profile number 2 means l2-profile-three -(default) is active while profile number 12 means vxlan-gbp-l3-profile. The following output indicates different profiles being programmed on the hardware, as seen on your switches. 

All the members of a VC needs to be restarted after a UFT profile change. This is a mandatory step.