Comment 4 for bug 1790098

Here is an example netplan yaml that emulates this configuration in a test container.

network:
    version: 2
    ethernets:
        eth0:
            dhcp4: false
    bonds:
        bond0:
            interfaces: [eth0]
            parameters:
                mode: active-backup
                arp-interval: 10
    vlans:
        bond0.100:
            id: 100
            link: bond0
            addresses: [10.44.49.39/24]
            routes:
              - to: 0.0.0.0/0
                via: 10.44.49.1

Setting 'arp-interval' causes the link to drop after a short period because the lxd bridge for the container isn't configured compatibly; so I've removed that line for testing here.

However, I haven't understood why you have addresses assigned on both the bond and the vlan, or what you're intending to achieve by reconfiguring the bond with nmcli. Here, the links appear to work as expected when managed directly with iproute2.

# ip -4 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
3: bond0.100@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.44.49.39/24 brd 10.44.49.255 scope global bond0.100
       valid_lft forever preferred_lft forever
# ip link set dev bond0 down
# ip -4 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
# ip link set dev bond0 up
# ip -4 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
3: bond0.100@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.44.49.39/24 brd 10.44.49.255 scope global bond0.100
       valid_lft forever preferred_lft forever
#

I don't see anything here to indicate the kernel is mishandling these interfaces.