Bug ID 827021: MCP update message may be lost when primary blade changes in chassis

Last Modified: Aug 26, 2020

Bug Tracker

Affected Product:  See more info
BIG-IP LTM(all modules)

Known Affected Versions:
11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3,,,,, 11.6.4, 11.6.5,,, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3,,,,,,,, 12.1.4,, 12.1.5,,, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0,,,,,,,,, 13.1.1,,,,, 13.1.3,,,,, 14.0.0,,,,,, 14.0.1,, 14.1.0,,,,,, 14.1.2,,,,,,,, 15.0.0, 15.0.1,,,,, 15.1.0,,,,,

Opened: Sep 16, 2019
Severity: 3-Major


In a VIPRION chassis, when the Primary blade is disabled (intentionally or due to an unexpected loss of functionality) and a new Primary blade is selected, there is a brief window of time during which status messages forwarded from MCPD on a Secondary blade to MCPD on the Primary blade might be dropped, possibly resulting in an incorrect view of the state of configured objects.


This problem may result in the state of blade-local objects (such as interfaces or trunks) being seen and reported incorrectly across the blades in the chassis, or on one or more specific blades (Primary, Secondary) in the chassis. For example, if loss of the Primary blade results in one or more interfaces in a trunk being marked down by LACPD on a specific blade, resulting changes in trunk/member status may not be propagated correctly to the Primary blade, and from there to other Secondary blades.


This problem may occur under the following conditions: -- The state of a blade-local object/resources (such as a network interface or trunk) changes. -- There is a high load on MCPD (for example, due to configuration reload on the new Primary blade) which delays processing of some MCPD actions.



Fix Information


Behavior Change