This article provides details of the change in Junos OS default behavior in aAggregate Ethernet (AE) interfaces creation and MAC assignment, and how it will affect the MAC assignment after upgrade or RE reboot events. 

These changes take effect in Junos OS 14.2 and later releases.

 

Starting from Junos OS 14.2 , there is a change in how Aggregate Ethernet interfaces are created and MAC addresses are assigned. To conserve internal resources (which is required in scaled setups), from Junos OS 14.2 the AEae bundles will be created on demand and not pre-created.

Prior behavior:

In Junos OS releases prior to 14.2R1, aggregated-ethernet (AE) parent interfaces are created when the set chassis aggregated-devices ethernet device-count X command is configured; no other configuration is required. Even if an AE interface is not configured, 'x' number of AE bundles are created, ready to be configured and used. 

Example:
The command set chassis aggregated-devices ethernet device-count 15 is configured. After commit, 15 AE bundles will be  created and chassisd will fetch MACs from s pre-defined pool. Chassid will assign MAC sequentially to AEs from ae0 to ae14.

Behavior from Junos OS 14.2 release onward:

From Junos OS 14.2 onward, it will still be necessary to use the set chassis aggregated-devices ethernet device-count X command, but this will not create the AE bundles. This statement will only limit the maximum number of AE bundles that can be created. No prior AE bundles will be created until an AE bundle is defined/configured, and associated with at least one child physical interface.

Example:
Bundles ae0 and ae5 are configured with at least one child interface each. The kernel will create ae0 and ae5 only (no other AEs will be seen on the system). Chassisd will fetch the first available MAC from the pool and will assign it to ae0 and ae5 in the order in which they are created.

How this change in behavior will affect upgrades, reboots and RE switchover events (without GRES):

In the above example, ae5 is first configured and ae0 later, then MAC1 will be assigned to ae5 and MAC2 to ae0 as in the order of creation. After an  upgrade, reboot event or switchover event (without GRES), the kernel will create AE bundles numbered lower to higher. Chassisd will fetch the MAC sequentially from the pool. Bundle ae0 will be created first and then ae5. Now ae0 will get MAC1 and ae5 will get MAC2. This change in MAC after the above events will affect any application or solution which relies on MAC like MAC accounting, port security using MAC, static ARP entries, etc.

Example output from lab:
If we configure AE bundles in the following order when on 14.2:
ae0, ae10, ae1, ae11, ae3, ae13, ae4, ae14

Below are the MAC assignments as seen in Junos OS 14.2 and after upgrading to Junos OS 15.1.
 
Before:

ae0   9c:cc:83:8b:b0:30
ae1   9c:cc:83:8b:b0:32
ae3   9c:cc:83:8b:b0:34
ae4   9c:cc:83:8b:b0:36
ae10  9c:cc:83:8b:b0:31
ae11  9c:cc:83:8b:b0:33
ae13  9c:cc:83:8b:b0:35
ae14  9c:cc:83:8b:b0:37

 
After:  

ae0   9c:cc:83:8b:b0:30
ae1   9c:cc:83:8b:b0:31
ae3   9c:cc:83:8b:b0:32
ae4   9c:cc:83:8b:b0:33
ae10  9c:cc:83:8b:b0:39
ae11  9c:cc:83:8b:b0:3a
ae13  9c:cc:83:8b:b0:3b
ae14  9c:cc:83:8b:b0:3c

Conclusion:

From Junos OS 14.2 onward, the creation of AE interfaces has been changed to be done on-demand; implicitly, so are the MAC assignments. While saving resources, this breaks an implicit assumption that MAC assignments would be persistent across reboots and Junos OS upgrades, as the changes caused assignments to be dependent on the order of addition/deletion of AEs.  In this case, after a reboot, AE MACs were reassigned in numeric order, with ae0 receiving the first assignable MAC, etc.  Any external dependency or filtering on the MAC assigned before the reboot will no longer be valid when the MAC changes. Care should be taken to circumvent any external disruption that might be caused by this change in behavior in Junos OS.