0

i've got a windows 2008 server vm running on kvm, it had an rtl nic. i did a patch install on the vm, did a 'dist-upgrade' on the host, and now the bridges do not appear to be forwarding packets! the host has several nics and all are statically assigned. brDMZ is the bridge i'm interested in, its assigned 192.168.4.4 and i can ping that from another (physical) host. i've tried rolling back to 4.4.0-98 with no luck. any suggestions!? here's some output:

uname -a
Linux vmhost-01 4.4.0-101-generic #124-Ubuntu SMP Fri Nov 10 18:29:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

brctl show
bridge name     bridge id               STP enabled     interfaces
brCSS           8000.001e0b480aba       yes             eth0
brDMZ           8000.d485644f4aee       yes             eth3
docker0         8000.0242823a37ed       no
virbr0          8000.525400cf415c       yes             virbr0-nic

sudo ifconfig brDMZ
brDMZ     Link encap:Ethernet  HWaddr d4:85:64:4f:4a:ee
          inet addr:192.168.4.4  Bcast:192.168.4.255  Mask:255.255.255.0
          inet6 addr: fe80::d685:64ff:fe4f:4aee/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:168 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9004 (9.0 KB)  TX bytes:648 (648.0 B)

brctl showstp brDMZ
brDMZ
 bridge id              8000.d485644f4aee
 designated root        8000.d485644f4aee
 root port                 0                    path cost                  0
 max age                  20.00                 bridge max age            20.00
 hello time                2.00                 bridge hello time          2.00
 forward delay             2.00                 bridge forward delay       2.00
 ageing time             300.00
 hello timer               0.52                 tcn timer                  0.00
 topology change timer     0.00                 gc timer                 171.35
 flags


eth3 (1)
 port id                8001                    state                forwarding
 designated root        8000.d485644f4aee       path cost                  4
 designated bridge      8000.d485644f4aee       message age timer          0.00
 designated port        8001                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

brctl showmacs brDMZ
port no mac addr                is local?       ageing timer
  1     00:06:5b:f6:8b:dc       no               179.48
  1     00:0c:29:04:87:83       no               157.46
  1     00:0c:29:f1:90:8e       no                52.99
  1     00:14:5e:77:f7:d7       no                59.09
  1     d4:85:64:4f:4a:ee       yes                0.00
  1     d4:85:64:4f:4a:ee       yes                0.00

sudo ebtables -t filter -L
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 0, policy: ACCEPT
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
1
  • update: i created an ubuntu 16.04 host on the same bridge, with same results. however, if i run tcpdump IN the vm, it sees ARP requests coming from machine out on the network trying to ping it!?
    – david
    Commented Nov 27, 2017 at 17:23

1 Answer 1

2

running the tcpdump (in multiple places) gave me the clue to the fix on this. i noticed that arp traffic was showing up in the dumps on the vm and on the host, but outgoing and incoming traffic would only show up at the host, not at the vm. ufw was running but nothing was set (far as i could tell, dont really know anything about it), BUT i noticed that iptables -L showed the FORWARD chain had a policy of DENY! i compared that with another ubuntu installation i had and it had a default policy of ACCEPT, so - sure enough - change the policy to be ACCEPT and all was well!

i have a feeling that installing docker.io made some iptables changes, but i wont know for sure, just glad to have this issue behind me!

hope it helps someone else

1
  • I would like to add, the command to set policy is sudo iptables -P FORWARD ACCEPT for the above scenario
    – jamesy829
    Commented Jan 15, 2018 at 4:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .