​Junos Logical Unit On Aggregated Link Error

This is a common error when configuring aggregated Ethernet links on Junos.

The member or child interfaces must not have a logical unit defined.

Example 1 – Configuration Under The Child Interface

Look at the following output.

[edit]
lab@vMX-1# commit 
[edit interfaces ge-0/0/0]
  'unit 0'
     logical unit is not allowed on aggregated links
error: configuration check-out failed

[edit]
lab@vMX-1# show interfaces ge-0/0/0  
gigether-options {
    802.3ad ae0;
}
unit 0 {
    family inet {
        address 192.168.2.2/24;
    }
}

[edit]
lab@vMX-1#

To fix this, unit 0 must either be deactivated or deleted, as shown below.

[edit]
lab@vMX-1# delete interfaces ge-0/0/0 unit 0 

[edit]
lab@vMX-1# show interfaces ge-0/0/0  
gigether-options {
    802.3ad ae0;
}

[edit]
lab@vMX-1# commit 
commit complete

[edit]
lab@vMX-1#

Example 2 – Inherited Configuration

In this example, we get a similar error message as above, but the cause isn’t as clear.

[edit]
lab@vMX-1# commit                     
[edit groups test-apply-group interfaces ge-0/0/0]
  'unit 0'
     logical unit is not allowed on aggregated links
error: configuration check-out failed

[edit]
lab@vMX-1# show interfaces ge-0/0/0   
gigether-options {
    802.3ad ae0;
}

[edit]
lab@vMX-1#

Why do we get an error about a logical unit under ge-0/0/0 when no unit is configured? One clue is the location of the error. It is complaining about configuration under ‘edit groups test-apply-group interfaces ge-0/0/0’ rather than ‘edit interfaces ge-0/0/0’. We need to check for inherited configuration.

[edit]
lab@vMX-1# show interfaces ge-0/0/0 | display inheritance 
gigether-options {
    802.3ad ae0;
}
##
## '0' was inherited from group 'test-apply-group'
##
unit 0 {
    ##
    ## 'inet' was inherited from group 'test-apply-group'
    ##
    family inet {
        ##
        ## '192.168.2.2/24' was inherited from group 'test-apply-group'
        ##
        address 192.168.2.2/24;
    }
}

[edit]
lab@vMX-1#

It now becomes clear that interface ge-0/0/0 is inheriting configuration from an apply group.

The solution to this problem is more complicated than the first example.

The output tells us which apply group we inherit the configuration from, but it doesn’t tell us where that apply group is applied.

We can show the configuration and match on ‘apply-group’ to find where groups are applied, then use a second match for the group we want, and finally use display set to get the full configuration statement.

[edit]
lab@vMX-1# show | match apply-group | match test-apply-group | display set 
set groups test-apply-group interfaces ge-0/0/0 unit 0 family inet address 192.168.2.2/24
set interfaces apply-groups test-apply-group

[edit]
lab@vMX-1#

You might need to adjust the command to suit your particular configuration. In this example, having the group itself called ‘test-apply-group’ isn’t ideal, as it is caught in the first match statement. But we can see the group is applied at the interfaces level.

This needs to be solved on a case-by-case basis. A lot depends on where the configuration group is applied and what it does. Simply changing the group configuration, or removing the apply-group statement could have bad consequences.

Make sure you understand the impact before making any changes.

For this particular example, I can remove the apply-group statement without causing any other harm.

[edit]
lab@vMX-1# commit 
[edit groups test-apply-group interfaces ge-0/0/0]
  'unit 0'
     logical unit is not allowed on aggregated links
error: configuration check-out failed

[edit]
lab@vMX-1# delete interfaces apply-groups test-apply-group 

[edit]
lab@vMX-1# show | compare 
[edit interfaces]
-  apply-groups test-apply-group;
[edit interfaces]
+   ge-0/0/0 {
+       gigether-options {
+           802.3ad ae0;
+       }
+   }

[edit]
lab@vMX-1# commit 
commit complete

[edit]
lab@vMX-1#