Comment 9 for bug 1790098

------- Comment From <email address hidden> 2018-09-10 05:16 EDT-------
Vorlon,

In the detailed steps , the commands have been simplified.
Let me put simple use case for ease to avoid confusion.

1)Create bond using nmcli utility with below attributes set:
one slave (eth0) , mode = active_backup , ipv4 is assigned to bond say 30.1.2.100/24

2)Create VLAN on top of bond created in above step 1. ipv4 is assigned to vlan say 30.1.3.100/24

3)Ping operation under test works for 30.1.2.1 and 30.1.3.1

4)Deactivate bond. Vlan also gets deactivated. Both 30.1.2.1 and 30.1.3.1 are not reachable.
Because ip routes no more exists on deactivation of bond. #This is expected as per my understanding

5)Activate bond. VLAN DOES NOT GET ACTIVATED AUTOMATICALLY. Only 30.1.2.1 is reachable.
Route for VLAN is not created. #This was working in combination with nmcli + other distros automatically, and as a end user need not do any operation with respect to VLAN.

6)For nmcli + Ubuntu, we are forced to Manually Activate VLAN, route is then created for VLAN. 30.1.3.1 is now reachable.

Above steps can be repeated
1)Without assiging ip to bond as well
2)For some reasons if we want to add a new slave or delete a slave from bond OR change any attributes of bond say primary, primary_reselect etc, bond is deactivated, attributes of bond are modified and activated. In this process VLAN gets deactivated autmatically but not gets auto - activated resulting in loss of traffic

So either i suspect one of the two issues here
1)nmcli was internally handling this in case of other distros. i.e deactivated the vlan, when bond is deactivated and activate the vlan , when bond is activated.
OR
2)network kernel underlying module takes care of these notifications between bond and vlan. I suspected this because, as i did not see any log updates with respect to nmcli tool for automatically deactivating and activating VLAN