On 4/23/2015 11:26 AM, Matthew Grooms wrote:
On 4/22/2015 8:34 PM, Scott O'Connell wrote:
I tried your suggestions.
I was successful in changing the vmhost01 bridge to include vlan100
and tap0, and in the vm (dev) binding the address directly to vtnet0.
On the VMHOST:
tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
metric 0 mtu 1500
options=80000<LINKSTATE>
ether 00:bd:4c:d1:02:00
media: Ethernet autoselect
status: active
Opened by PID 888
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
mtu 1500
ether 02:d3:e4:02:03:00
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: tap0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 6 priority 128 path cost 2000000
member: vlan100 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 5 priority 128 path cost 2000000
In the VM:
vtnet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
metric 0 mtu 1500
options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
ether 00:a0:98:2b:34:37
inet 10.0.1.6 netmask 0xffffff00 broadcast 10.0.1.255
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet 10Gbase-T <full-duplex>
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
The same results with regard to connectivity. Both the VMHOST and
the VM can communicate everywhere, except with each other.
I'm not sure how much detail to post, or what protocol I should be
testing from the tcpdump, but here are a couple of relevant
portions. Captured on the VMHOST with "tcpdump -i tap0 -n -vv", and
on the VM with "tcpdump -i vtnet0 -n -vv"
A ping from the VM (10.0.1.6) to VMHOST (10.0.1.17):
Captured on tap0:
18:18:40.656407 IP (tos 0x0, ttl 64, id 2398, offset 0, flags [none],
proto ICMP (1), length 84)
10.0.1.6 > 10.0.1.17: ICMP echo request, id 46082, seq 689,
length 64
18:18:40.656429 IP (tos 0x0, ttl 64, id 3824, offset 0, flags [none],
proto ICMP (1), length 84, bad cksum 0 (->55a3)!)
10.0.1.17 > 10.0.1.6: ICMP echo reply, id 46082, seq 689, length 64
Captured on vtnet0:
18:18:40.906203 IP (tos 0x0, ttl 64, id 2398, offset 0, flags [none],
proto ICMP (1), length 84)
10.0.1.6 > 10.0.1.17: ICMP echo request, id 46082, seq 689,
length 64
18:18:40.906366 IP (tos 0x0, ttl 64, id 3824, offset 0, flags [none],
proto ICMP (1), length 84, bad cksum 0 (->55a3)!)
10.0.1.17 > 10.0.1.6: ICMP echo reply, id 46082, seq 689, length 64
100% packet loss on the ping.
Here is the same traffic from both systems between the VM (10.0.1.6)
and the switch (10.0.1.1) through the VMHOST:
Captured on tap0:
18:23:42.712065 IP (tos 0x0, ttl 64, id 2858, offset 0, flags [none],
proto ICMP (1), length 84)
10.0.1.6 > 10.0.1.1: ICMP echo request, id 58626, seq 2, length 64
18:23:42.712595 IP (tos 0x0, ttl 255, id 2858, offset 0, flags
[none], proto ICMP (1), length 84)
10.0.1.1 > 10.0.1.6: ICMP echo reply, id 58626, seq 2, length 64
Captured on vtnet0:
18:23:43.141890 IP (tos 0x0, ttl 64, id 2858, offset 0, flags [none],
proto ICMP (1), length 84)
10.0.1.6 > 10.0.1.1: ICMP echo request, id 58626, seq 2, length 64
18:23:43.142553 IP (tos 0x0, ttl 255, id 2858, offset 0, flags
[none], proto ICMP (1), length 84)
10.0.1.1 > 10.0.1.6: ICMP echo reply, id 58626, seq 2, length 64
100% packet success on the ping.
I'm never quite sure when checksum's with TCP Dump or Wireshark are
expected, and when they aren't, but it appears that is where the
problem lies here.
With that said, if I'm understanding this correctly, and checksums
are the problem, I'm not sure what to try next.
Thanks again!
Hi Scott,
I certainly appears that ICMP echo reply packets are being returned
but the host isn't processing them for some reason. Do you have any
firewalls running on either system? You might try including a -e in
the tcpdump command line arguments. IIRC, that will also show you VLAN
and MAC address info from the packet headers. Maybe one of the network
kernel developers could provide some additional insight as to what may
be happening in this scenario.
-Matthew
The latest updates:
vmhost capture using "tcpdump -i tap0 -n -vv -e"
10:51:02.988660 00:a0:98:2b:34:37 > f0:1f:af:dd:2e:c5, ethertype IPv4
(0x0800), length 98: (tos 0x0, ttl 64, id 18864, offset 0, flags [none],
proto ICMP (1), length 84)
10.0.1.6 > 10.0.1.17: ICMP echo request, id 34069, seq 5, length 64
10:51:02.988689 f0:1f:af:dd:2e:c5 > 00:a0:98:2b:34:37, ethertype IPv4
(0x0800), length 98: (tos 0x0, ttl 64, id 16775, offset 0, flags [none],
proto ICMP (1), length 84, bad cksum 0 (->230c)!)
10.0.1.17 > 10.0.1.6: ICMP echo reply, id 34069, seq 5, length 64
vm capture using "tcpdump -i vtnet0 -n -vv -e"
10:51:03.462131 00:a0:98:2b:34:37 > f0:1f:af:dd:2e:c5, ethertype IPv4
(0x0800), length 98: (tos 0x0, ttl 64, id 18864, offset 0, flags [none],
proto ICMP (1), length 84)
10.0.1.6 > 10.0.1.17: ICMP echo request, id 34069, seq 5, length 64
10:51:03.462318 f0:1f:af:dd:2e:c5 > 00:a0:98:2b:34:37, ethertype IPv4
(0x0800), length 98: (tos 0x0, ttl 64, id 16775, offset 0, flags [none],
proto ICMP (1), length 84, bad cksum 0 (->230c)!)
10.0.1.17 > 10.0.1.6: ICMP echo reply, id 34069, seq 5, length 64
vmhost capture using "tcpdump -i tap0 -n -vv -e"
11:10:25.372567 00:a0:98:2b:34:37 > 00:22:56:ae:f1:c7, ethertype IPv4
(0x0800), length 98: (tos 0x0, ttl 64, id 20759, offset 0, flags [none],
proto ICMP (1), length 84)
10.0.1.6 > 10.0.1.1: ICMP echo request, id 43797, seq 3, length 64
11:10:25.373188 00:22:56:ae:f1:c7 > 00:a0:98:2b:34:37, ethertype IPv4
(0x0800), length 98: (tos 0x0, ttl 255, id 20759, offset 0, flags
[none], proto ICMP (1), length 84)
10.0.1.1 > 10.0.1.6: ICMP echo reply, id 43797, seq 3, length 64
vm capture using "tcpdump -i vtnet0 -n -vv -e"
11:10:25.890274 00:a0:98:2b:34:37 > 00:22:56:ae:f1:c7, ethertype IPv4
(0x0800), length 98: (tos 0x0, ttl 64, id 20759, offset 0, flags [none],
proto ICMP (1), length 84)
10.0.1.6 > 10.0.1.1: ICMP echo request, id 43797, seq 3, length 64
11:10:25.891083 00:22:56:ae:f1:c7 > 00:a0:98:2b:34:37, ethertype IPv4
(0x0800), length 98: (tos 0x0, ttl 255, id 20759, offset 0, flags
[none], proto ICMP (1), length 84)
10.0.1.1 > 10.0.1.6: ICMP echo reply, id 43797, seq 3, length 64
It doesn't look like any frames are being tagged. However, if I look at
lagg0, and pick another ping between the vm and the switch, vlan tagging
IS occurring:
11:18:28.209997 00:a0:98:2b:34:37 > 00:22:56:ae:f1:c7, ethertype 802.1Q
(0x8100), length 102: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 64,
id 21499, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.6 > 10.0.1.1: ICMP echo request, id 43797, seq 461, length 64
11:18:28.210527 00:22:56:ae:f1:c7 > 00:a0:98:2b:34:37, ethertype 802.1Q
(0x8100), length 102: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 255,
id 21499, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.1 > 10.0.1.6: ICMP echo reply, id 43797, seq 461, length 64
So I've tried bridging lagg0 and tap0 on the VMHOST, with vtnet0 and
vlan100 in the VM, and bridging vlan100 and tap0 on the VMHOST, and
native vtnet0 in the VM. Both instances the VMHOST and VM can't talk to
each other, but can with anything upstream of the VMHOST through lagg0.
(I wrote this mostly for myself, but decided to leave it in!)
I've tried applying various vlan options to the tap and bridge
interfaces, but since they're not physical interfaces, those options
appear to be invalid.
Any new ideas?
Thanks,
scotto
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"