#StackBounty: #linux #docker #centos7 #linux-networking #docker-compose Docker – No Outbound Traffic / Bridge Only Works When in Promis…

Bounty: 50

I have been struggling with a very strange networking issue for the past week. In summary, my containers can’t reach the internet unless I run tcpdump -i br-XXXXX (which puts the bridge into promiscuous mode)

I have two containers that I’m bringing up with Compose:

version: '3'
services:
  seafile:
    build: ./seafile/build
    container_name: seafile
    restart: always
    ports:
      - 8080:80
    networks:
      seafile_net:
        ipv4_address: 192.168.0.2
    volumes:
      - /mnt/gluster/files/redacted/data:/shared
    environment:
      - DB_HOST=10.200.7.100
      - DB_PASSWD=redacted
      - TIME_ZONE=America/Chicago
    depends_on:
      - seafile-memcached
  seafile-memcached:
    image: memcached:1.5.6
    container_name: seafile-memcached
    restart: always
    networks:
      seafile_net:
        ipv4_address: 192.168.0.3
    entrypoint: memcached -m 256
networks:
  seafile_net:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 192.168.0.0/24

Containers running:

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                  NAMES
93b1b773ad4e        docker_seafile      "/sbin/my_init -- /s…"   2 minutes ago       Up 2 minutes        0.0.0.0:8080->80/tcp   seafile
1f6b124c3be4        memcached:1.5.6     "memcached -m 256"       2 minutes ago       Up 2 minutes        11211/tcp              seafile-memcached

Network information:

$ docker network ls
NETWORK ID          NAME                 DRIVER              SCOPE
f67b015c4b84        bridge               bridge              local
d21cb7ba8ee4        docker_seafile_net   bridge              local
d0eb86ca57fa        host                 host                local
01f03fcfa103        none                 null                local

$ docker inspect d21cb7ba8ee4
[
    {
        "Name": "docker_seafile_net",
        "Id": "d21cb7ba8ee4a477497a7d343ea1a5f9b109237dce878a40605a281e1a2db1e9",
        "Created": "2020-09-24T15:03:46.39761472-04:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "192.168.0.0/24"
                }
            ]
        },
        "Internal": false,
        "Attachable": true,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "1f6b124c3be414040a6def3b3bc3e9f06e2af6a28afd6737823d1da65d5ab047": {
                "Name": "seafile-memcached",
                "EndpointID": "ab3e3c4aa216d158473fa3dde3f87e654422ffeca6ebb7626d072da10ba9a5cf",
                "MacAddress": "02:42:c0:a8:00:03",
                "IPv4Address": "192.168.0.3/24",
                "IPv6Address": ""
            },
            "93b1b773ad4e3685aa8ff2db2f342c617c42f1c5ab4ce693132c1238e73e705d": {
                "Name": "seafile",
                "EndpointID": "a895a417c22a4755df15b180d1c38b712c36047b01596c370815964a212f7105",
                "MacAddress": "02:42:c0:a8:00:02",
                "IPv4Address": "192.168.0.2/24",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "com.docker.compose.network": "seafile_net",
            "com.docker.compose.project": "docker",
            "com.docker.compose.version": "1.27.4"
        }
    }
]

$ ip link show master br-d21cb7ba8ee4
18: veth8fd88c9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-d21cb7ba8ee4 state UP mode DEFAULT group default
    link/ether b6:37:9e:fd:9e:da brd ff:ff:ff:ff:ff:ff
20: vetheb84e16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-d21cb7ba8ee4 state UP mode DEFAULT group default
    link/ether ca:90:c8:a6:2e:9b brd ff:ff:ff:ff:ff:ff

Once the containers are up, they are unable to reach the internet or any other resources on the host network. The following curl command was run from inside one of the containers. On the host server, this same command works fine:

root@93b1b773ad4e:/opt/seafile# curl -viLk http://1.1.1.1
* Rebuilt URL to: http://1.1.1.1/
*   Trying 1.1.1.1...
* TCP_NODELAY set
**hangs**

Here is a tcpdump (run on the host) of the bridge WITHOUT putting it into promiscuous mode. This was captured while I was trying to run the curl command from above:

$ tcpdump --no-promiscuous-mode -lnni br-d21cb7ba8ee4
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-d21cb7ba8ee4, link-type EN10MB (Ethernet), capture size 262144 bytes
14:15:42.447055 ARP, Request who-has 192.168.0.2 tell 192.168.0.1, length 28
14:15:43.449058 ARP, Request who-has 192.168.0.2 tell 192.168.0.1, length 28
14:15:45.448787 ARP, Request who-has 192.168.0.2 tell 192.168.0.1, length 28
14:15:46.451049 ARP, Request who-has 192.168.0.2 tell 192.168.0.1, length 28
14:15:47.453058 ARP, Request who-has 192.168.0.2 tell 192.168.0.1, length 28
14:15:49.449789 ARP, Request who-has 192.168.0.2 tell 192.168.0.1, length 28
14:15:50.451048 ARP, Request who-has 192.168.0.2 tell 192.168.0.1, length 28

But if I let tcpdump put the bridge into promiscuous mode, things start working:

$ tcpdump -lnni br-d21cb7ba8ee4
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-d21cb7ba8ee4, link-type EN10MB (Ethernet), capture size 262144 bytes
14:16:05.457844 ARP, Request who-has 192.168.0.2 tell 192.168.0.1, length 28
14:16:05.457863 ARP, Reply 192.168.0.2 is-at 02:42:c0:a8:00:02, length 28
**traffic continues**

Docker info:

$ docker info
Client:
 Debug Mode: false
Server:
 Containers: 2
  Running: 2
  Paused: 0
  Stopped: 0
 Images: 6
 Server Version: 19.03.13
 Storage Driver: devicemapper
  Pool Name: docker-8:3-3801718-pool
  Pool Blocksize: 65.54kB
  Base Device Size: 10.74GB
  Backing Filesystem: xfs
  Udev Sync Supported: true
  Data file: /dev/loop0
  Metadata file: /dev/loop1
  Data loop file: /var/lib/docker/devicemapper/devicemapper/data
  Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
  Data Space Used: 1.695GB
  Data Space Total: 107.4GB
  Data Space Available: 80.76GB
  Metadata Space Used: 3.191MB
  Metadata Space Total: 2.147GB
  Metadata Space Available: 2.144GB
  Thin Pool Minimum Free Space: 10.74GB
  Deferred Removal Enabled: true
  Deferred Deletion Enabled: true
  Deferred Deleted Device Count: 0
  Library Version: 1.02.164-RHEL7 (2019-08-27)
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 8fba4e9a7d01810a393d5d25a3621dc101981175
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 3.10.0-123.9.2.el7.x86_64
 Operating System: CentOS Linux 7 (Core)
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 3.704GiB
 Name: redacted.novalocal
 ID: redacted
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
WARNING: the devicemapper storage-driver is deprecated, and will be removed in a future release.
WARNING: devicemapper: usage of loopback devices is strongly discouraged for production use.
         Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.

Host information:

$ docker --version
Docker version 19.03.13, build 4484c46d9d

$ docker-compose --version
docker-compose version 1.27.4, build 40524192

$ cat /etc/redhat-release
CentOS Linux release 7.8.2003 (Core)

$ getenforce
Disabled

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           3.7G        1.1G        826M        109M        1.8G        2.2G
Swap:          1.0G        292M        731M

$ nproc
2

$ uptime
 10:39:49 up 3 days, 19:56,  1 user,  load average: 0.00, 0.01, 0.05

$ iptables-save
# Generated by iptables-save v1.4.21 on Mon Sep 28 10:41:22 2020
*filter
:INPUT ACCEPT [17098775:29231856941]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [15623889:13475217196]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o br-d21cb7ba8ee4 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-d21cb7ba8ee4 -j DOCKER
-A FORWARD -i br-d21cb7ba8ee4 ! -o br-d21cb7ba8ee4 -j ACCEPT
-A FORWARD -i br-d21cb7ba8ee4 -o br-d21cb7ba8ee4 -j ACCEPT
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER -d 192.168.0.2/32 ! -i br-d21cb7ba8ee4 -o br-d21cb7ba8ee4 -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i br-d21cb7ba8ee4 ! -o br-d21cb7ba8ee4 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o br-d21cb7ba8ee4 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Mon Sep 28 10:41:22 2020
# Generated by iptables-save v1.4.21 on Mon Sep 28 10:41:22 2020
*nat
:PREROUTING ACCEPT [408634:24674574]
:INPUT ACCEPT [380413:22825327]
:OUTPUT ACCEPT [520596:31263683]
:POSTROUTING ACCEPT [711734:42731963]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 192.168.0.0/24 ! -o br-d21cb7ba8ee4 -j MASQUERADE
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 192.168.0.2/32 -d 192.168.0.2/32 -p tcp -m tcp --dport 80 -j MASQUERADE
-A DOCKER -i br-d21cb7ba8ee4 -j RETURN
-A DOCKER -i docker0 -j RETURN
-A DOCKER ! -i br-d21cb7ba8ee4 -p tcp -m tcp --dport 8080 -j DNAT --to-destination 192.168.0.2:80
COMMIT
# Completed on Mon Sep 28 10:41:22 2020


Get this bounty!!!

#StackBounty: #ubuntu #networking #linux-networking #kubernetes managing multiple LAN on bare metals in kubernetes

Bounty: 50

Here is my setup :

  • I have multiple LAN’s on bare metals.
  • each LAN has a hardware router and has a static ip
  • each LAN has address range 192.168.1.*
  • external traffic usually comes to hardware router and then needs to be served by 1 of the service within the LAN

Need :

  • keep the LAN isolated sometimes(in few use cases) : like deploying an application to a LAN

Options :

  • Should i have 1 kubernetes OR 1 kubernetes for each LAN. 1 kubernetes per cluster would be a nightmare for me to manage so manage many clusters; I think 1 kubernetes overall is good.
  • for LAN specific deployments, should i create 1 namespace for each LAN or kubernetes labels are better to use or any other options
  • the external traffic usually comes via the static ip on hardware router, from there I need to route traffic usually within the LAN(thus ingress only within the LAN). How would ingress within the LAN would work.
  • also want to monitor, alarm and health check the entire cluster, namespace specific or label filtering.


Get this bounty!!!

#StackBounty: #linux #linux-networking #linux-kernel #keepalived #ipvs IPVS transmitting packets to incorrect backends

Bounty: 50

We are using ipvs for L4 loadbalancing which transmits packets to L7 backends on ipip tunnel mode.

There are three ipvs systems configured with source hashing for persistence. Sometimes, ipvs is transmitting the packets to incorrect backends.

For example, ipvs 1 recieves packet from client 1.1.1.1 and it sends the packet to backend realserver 1, the same client’s next packet is received by ipvs 2 which sends it to the backend realserver 2. Now, backend 2 has no idea of this packet because the connection was actually initiated with realserver 1, thus the realserver 2 ends the connection with an RST packet.

This happens not only with a particular client, all the clients are having the same behavior.

to my understanding, all L4 ipvs should pick the same real server because of the source hashing algorithm.

I built a same setup in lab, but couldn’t reproduce it. The setup that has issue is production, hence I cannot do any huge changes to it for debugging purpose.

Keepalived is used to manage the ipvs.

Any directions on how to debug this issue with minimal impact will be really helpful.

PS – I know source hashing isn’t very consistent, but the packets being sent to wrong real servers are too high. We have other clusters where we have never seen this issue.

Thanks !


Get this bounty!!!

#StackBounty: #networking #linux-networking #kvm-virtualization #ubuntu-18.04 KVM QEMU VMs with static IP loose network connectivity

Bounty: 100

I have a KVM/QEMU setup with both host & guest (VM) running Ubuntu 18.04 LTS with bridged networking. VMs are configured with static IP loose network connectivity randomly (there is no pattern). VMs which are configured with DHCP works fine.

Here is my host network config,

network:
    version: 2
    ethernets:
        eno1:
            dhcp4: no
            dhcp6: no
        eno4:
            dhcp4: true
        eno5np0:
            dhcp4: true
        eno6np1:
            dhcp4: true
        ens2f0np0:
            dhcp4: true
        ens2f1np1:
            dhcp4: true
    bridges:
        br0:
            interfaces: [eno1]
            dhcp4: no
            addresses:
            - 10.2.0.92/24
            gateway4: 10.2.1.252
            nameservers:
                addresses:
                - 8.8.8.8

Here is my vm (guest) network config with static IP,

network:
    version: 2
    ethernets:
            ens3:
                    dhcp4: no
                    addresses:
                    - 10.2.0.210/23
                    gateway4: 10.2.1.252
                    nameservers:
                        addresses:
                        - 8.8.8.8

Here is my vm (guest) network config with DHCP,

network:
    version: 2
    ethernets:
            ens3:
                    dhcp4: true

VMs with static IP goes into kind of idle state. So when ever trying to SSH or access the services in that, it takes time then it connects,

$ nc -z -v -w5 10.2.0.210 22
nc: connect to 10.2.0.210 port 22 (tcp) timed out: Operation now in progress

Try again, it will work, because the VM moved from idle to working state because of the first try,

$nc -z -v -w5 10.2.0.210 22
Connection to 10.2.0.210 22 port [tcp/ssh] succeeded!

There is no issue with VMs which has DHCP. It connects just fine any time,

$ nc -z -v -w5 10.2.0.184 22
Connection to 10.2.0.184 22 port [tcp/ssh] succeeded!

I have checked the following links,

but it didn’t help.

Any issue in the KVM configuration? Not only SSH, but any services exposed in the VMs are also not accessible. I have verified that VMs are in running state when I query virsh.


Get this bounty!!!

#StackBounty: #networking #ssh #linux-networking #hacking Compromised Ubiquity ERLite 3?

Bounty: 50

I’m not a network administrator just trying to help a friend who’s been having issues lately with his PPTP VPN.

At first glance I noticed a very high CPU usage as well as constantly >50Mbps of RX/TX

enter image description here

After that, I went to analyse one of those commands

enter image description here

I can telnet to those ports so they are clearly open and receiving.

What else should I try to analyse what it is going on? Any ideas?


Get this bounty!!!

#StackBounty: #nginx #linux-networking #load-balancing #tcp #debian-buster Nginx fails on high load with Debian10 and not with Debian9

Bounty: 100

We had never any problems with nginx. We use 5 nginx server as loadbalancers in front of many spring boot application servers.

We were running them for years on debian 9 with the default nginx package 1.10.3. Now we switched three of our loadbalancers to debian 10 with nginx 1.14.2. First everything runs smoothly. Then, on high load we encountered some problems. It starts with

2020/02/01 17:10:55 [crit] 5901#5901: *3325390 SSL_write() failed while sending to client, client: ...
2020/02/01 17:10:55 [crit] 5901#5901: *3306981 SSL_write() failed while sending to client, client: ...

In between we get lots of

2020/02/01 17:11:04 [error] 5902#5902: *3318748 upstream timed out (110: Connection timed out) while connecting to upstream, ...
2020/02/01 17:11:04 [crit] 5902#5902: *3305656 SSL_write() failed while sending response to client, client: ...
2020/02/01 17:11:30 [error] 5911#5911: unexpected response for ocsp.int-x3.letsencrypt.org

It ends with

2020/02/01 17:11:33 [error] 5952#5952: unexpected response for ocsp.int-x3.letsencrypt.org

The problem does only exits for 30-120 seconds on high load and disappears afterwards.

In the kernel log we have sometimes:
Feb 1 17:11:04 kt104 kernel: [1033003.285044] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters.

But on other occasions we don’t see any kernel.log messages

On both debian 9 and debian 10 servers we use the identical setup and had some TCP Tuning in place:

# Kernel tuning settings
# https://www.nginx.com/blog/tuning-nginx/
net.core.rmem_max=26214400
net.core.wmem_max=26214400
net.ipv4.tcp_rmem=4096 524288 26214400
net.ipv4.tcp_wmem=4096 524288 26214400
net.core.somaxconn=1000
net.core.netdev_max_backlog=5000
net.ipv4.tcp_max_syn_backlog=10000
net.ipv4.ip_local_port_range=16000 61000
net.ipv4.tcp_max_tw_buckets=2000000
net.ipv4.tcp_fin_timeout=30
net.core.optmem_max=20480

The nginx config is exactly the same, so I just show the main file:

user www-data;
worker_processes auto;
worker_rlimit_nofile 50000;
pid /run/nginx.pid;

events {
    worker_connections 5000;
    multi_accept on;
    use epoll;
}

http {
    root /var/www/loadbalancer;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    types_hash_max_size 2048;
    server_tokens off;
    client_max_body_size 5m;
    client_header_timeout 20s; # default 60s
    client_body_timeout 20s; # default 60s
    send_timeout 20s; # default 60s

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:100m;
    ssl_buffer_size 4k;
    ssl_dhparam /etc/nginx/dhparam.pem;
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';

    ssl_session_tickets on;
    ssl_session_ticket_key /etc/nginx/ssl_session_ticket.key;
    ssl_session_ticket_key /etc/nginx/ssl_session_ticket_old.key;

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/ssl/rapidssl/intermediate-root.pem;

    resolver 8.8.8.8;

    log_format custom '$host $server_port $request_time $upstream_response_time $remote_addr "$ssl_session_reused" $upstream_addr $time_iso8601 "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent";

    access_log /var/log/nginx/access.log custom;
    error_log /var/log/nginx/error.log;

    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
proxy_cache_path /var/cache/nginx/ levels=1:2 keys_zone=imagecache:10m     inactive=7d use_temp_path=off;
    proxy_connect_timeout 10s;
    proxy_read_timeout 20s;
    proxy_send_timeout 20s;
    proxy_next_upstream off;

    map $http_user_agent $outdated {
    default 0;
    "~MSIE [1-6]." 1;
    "~Mozilla.*Firefox/[1-9]." 1;
    "~Opera.*Version/[0-9]." 1;
    "~Chrome/[0-9]." 1;
  }

  include sites/*.conf;
}

The upstream timeout signals some problems with our java machines. But at the same time the debian9 nginx/loadbalancer is running fine and has no problems connecting to any of the upstream servers.
And the problems with letsencrypt and SSL_write are signaling to me some problems with nginx or TCP or whatever.
I really don’t know how to debug this situation. But we can reliable reproduce it most of the times we encounter high load on debian10 servers and did never see it on debian 9.

Then I installed the stable version nginx 1.16 on debian10 to see if this is a bug in nginx which is already fixed:

nginx version: nginx/1.16.1
built by gcc 8.3.0 (Debian 8.3.0-6)
built with OpenSSL 1.1.1c 28 May 2019 (running with OpenSSL 1.1.1d 10 Sep 2019)
TLS SNI support enabled
configure arguments: ...

But it didn’t help.

It seems to be a network related problem. But we do not encouter it on the application servers. But the load is of course lower as the loadbalancer/nginx machine has to handle external and internal traffic.

It is very difficult to debug as it only happens on high load. We treid to load test the servers with ab, but we could not reproduce the problem.

Can somebody help me and give me some hints how to start further debugging of this situation?


Get this bounty!!!

#StackBounty: #linux #linux-networking #ip-routing linux – routing between bridge networks without overlay

Bounty: 50

Here’s the scenario. There are two hosts in a subnet (both are virtualbox VMs) and both are on the same network 192.168.1.0.
I’ve additionally created two bridge interfaces with separate network slices.

Question:
Is there a way for the ip on host1 bridge to communicate with an ip on host2 bridge?
I’m looking for a way to configure the routes using ip route or similar, to route the L3 packets on one bridge to another without the need to install an additional networking layer like vxlan or something.

Configuration:

Host1 interfaces:

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:ca:4a:14 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.197/24 brd 192.168.1.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:feca:4a14/64 scope link
       valid_lft forever preferred_lft forever```

7: br-faf88cbd32f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:28:8c:40:00 brd ff:ff:ff:ff:ff:ff
    inet 172.11.11.1/24 brd 172.11.11.255 scope global br-faf88cbd32f0
       valid_lft forever preferred_lft forever

Host1 routing:

default via 192.168.1.1 dev enp0s3 proto static
172.11.11.0/24 dev br-faf88cbd32f0 proto kernel scope link src 172.11.11.1
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.197

Host2 interfaces:

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:40:ae:5f brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.196/24 brd 192.168.1.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe40:ae5f/64 scope link
       valid_lft forever preferred_lft forever

92: br-037dfd7b32bc: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:fe:0d:54:86 brd ff:ff:ff:ff:ff:ff
    inet 172.11.12.1/24 brd 172.11.12.255 scope global br-037dfd7b32bc
       valid_lft forever preferred_lft forever
    inet6 fe80::42:feff:fe0d:5486/64 scope link
       valid_lft forever preferred_lft forever

Host2 routing:

default via 192.168.1.1 dev enp0s3 proto static
172.11.12.0/24 dev br-037dfd7b32bc proto kernel scope link src 172.11.12.1
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.196


Get this bounty!!!

#StackBounty: #linux #linux-networking #vlan #alpine Arbitrary vlan interface name – undocumented configuration?

Bounty: 50

Today i was playing around with ethernet adapters and vlans in Alpine Linux. I tried to give the interfaces arbitrary names.

After looking at the source i had the following example working

Ethernet adapter named lan01 configured as DHCP client and a VLAN on this adapter named lan-test on VLAN ID 100

My /etc/network/interfaces:

auto lo
iface lo inet loopback

auto lan01
iface lan01 inet dhcp
        hostname alpine

auto lan-test
iface lan-test inet static
        vlan-id 100
        vlan-raw-device lan01
        address 10.10.0.1
        netmask 255.255.255.0

ifup and ifdown in Alpine Linux uses busybox.

Nowhere in any documentation i found the option vlan-id. However the vlan-raw-device is found in most documentation/man pages.
So this brings me to the question: Why is this option not documented anywhere?

Some of my guesses:

  • It is old and deprecated thus should not be used anymore
  • It is new and untested.
  • It never got documented properly
  • I just overlooked it many many times in the documentation


Get this bounty!!!