mjhjmtu

I have some bridge networks which I don't know where they come from:

$ ifconfig | grep -o "^br-w*"
br-4e3069271b9c
br-919ad27f74b2
br-e448c7cbb558
br-e6840866c3b6
br-636926a06053

(I suspect either docker, vmware or virtualbox which are installed).

The problem is, these bridge networks are somehow interfering with some intranet addresses, while other intranet addresses still work:

$ ping some.intranet.tld
From 172.21.0.1 icmp_seq=1 Destination Host Unreachable
From 172.21.0.1 icmp_seq=2 Destination Host Unreachable
From 172.21.0.1 icmp_seq=3 Destination Host Unreachable

$ ifconfig | grep -C 1 "172.21.0.1"
br-636926a06053 Link encap:Ethernet HWaddr 02:42:af:36:20:65 
inet addr:172.21.0.1 Bcast:172.21.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1

After issuing sudo ifconfig br-636926a06053 down everything works again.

PING some.intranet.tld (12.23.45.67) 56(84) bytes of data.
64 bytes from some.intranet.tld (12.23.45.67): icmp_seq=1 ttl=122 time=11.7 ms

But the problem appears again after restart and also I'm not sure if there are any negative side-effects shutting down that connection.

How to find out which program starts these bridge networks and how to eliminate the issue ?

Update:

It seems these bridges are coming from vmware:

$ sudo grep br-636926a06053 /var/log/syslog.1
Aug 7 08:58:56 hostname vmnet-natd: RTM_NEWLINK: name:br-636926a06053 index:7 flags:0x00001002
Aug 7 08:58:56 hostname vmnetBridge: RTM_NEWLINK: name:br-636926a06053 index:7 flags:0x00001002
Aug 7 08:58:56 hostname NetworkManager[1212]: <info> [1533625136.8516] manager: (br-636926a06053): new Bridge device (/org/freedesktop/NetworkManager/Devices/5)

It's most certainly Docker. VMware only detects them appearing (eg: to have them displayed in the GUI or perhaps to alter some networking rules (natd?)) as would the command ip monitor link in real time.

In docker network create it's hinted this:

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

What is not written is that the default choice starts from 172.17.0.0/16 and each subsequent network moves on up to 172.31.0.0/16 if not told otherwise. I couldn't find it explicitely, but most examples show that newly created bridges are all /16 part of 172.16.0.0/12, for example: in Multiple Docker Networks with no explicit --subnet the two subnets 172.29.0.0/16 and 172.30.0.0/16 are created. I'd be glad to add a definite reference to the default behaviour if provided.

To eliminate the issue, you should check what automated part in Docker (perhaps itself a privileged container etc.) creates those networks (you have logs on when they are activated as an interface, that may not be when they were initially created in the Docker configuration, but a simple docker network ls should confirm all this), and how to change their default network settings. I'm sure there are more radical methods, eg creating a network to reserve so Docker won't create the same, then keep it down, either by a Docker method if available, or like you did ip link set br-somenetworkid down.