É certamente o Docker. O VMware apenas os detecta (por exemplo: para exibi-los na GUI ou talvez para alterar algumas regras de rede (natd?)) Como seria o comando ip monitor link em tempo real.
Em docker network create , é sugerido o seguinte:
Specify advanced options
When you create a network, Engine creates a non-overlapping subnetwork for the network by default. This subnetwork is not a subdivision of an existing network. It is purely for ip-addressing purposes. You can override this default and specify subnetwork values directly using the --subnet option. On a bridge network you can only create a single subnet:
$ docker network create --driver=bridge --subnet=192.168.0.0/16 br0
O que não está escrito é que a escolha padrão começa em 172.17.0.0/16 e cada rede subseqüente se move em até 172.31.0.0/16 se não for dito o contrário. Não consegui encontrá-lo explicitamente, mas a maioria dos exemplos mostra que as pontes recém-criadas são todas /16 parte de 172.16.0.0/12 , por exemplo: em Multiple Docker Networks sem --subnet explícito as duas sub-redes 172.29.0.0/16 e 172.30.0.0/16 são criadas. Eu ficaria feliz em adicionar uma referência definitiva ao comportamento padrão, se fornecido.
Para eliminar o problema, você deve verificar qual parte automatizada do Docker (talvez um contêiner privilegiado, etc.) cria essas redes (você tem logs quando são ativados como uma interface, que podem não ser quando foram criados inicialmente na configuração do Docker, mas um docker network ls simples deve confirmar tudo isso) e como alterar suas configurações de rede padrão. Tenho certeza de que existem métodos mais radicais, por exemplo, criar uma rede para reservar, para que o Docker não crie o mesmo e, em seguida, mantenha-o inativo, seja por um método Docker, se disponível, ou como você fez ip link set br-somenetworkid down .