[fedora-virt] Access from host to guest via bridge macvtap device not work.

Dean Hunter deanhunter at comcast.net
Fri May 24 17:05:26 UTC 2013


On Fri, 2013-05-24 at 10:06 +0200, Dario Lesca wrote:
> Il giorno gio, 23/05/2013 alle 13.38 +0100, Richard W.M. Jones ha
> scritto:
> > Try running tcpdump/wireshark on the bridge and see where the
> > packets are going.
> 
> This is my network state:
> 
> # host (my notebook, dodo) ip 10.39.3.47/20 via dhcp
> 
> > [root at dodo:~]# ip a
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
> >     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> >     inet 127.0.0.1/8 scope host lo
> >        valid_lft forever preferred_lft forever
> >     inet6 ::1/128 scope host 
> >        valid_lft forever preferred_lft forever
> > 2: p6p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> >     link/ether d0:67:e5:4c:47:ce brd ff:ff:ff:ff:ff:ff
> >     inet 10.39.3.47/20 brd 10.39.15.255 scope global p6p1
> >        valid_lft forever preferred_lft forever
> >     inet6 fe80::d267:e5ff:fe4c:47ce/64 scope link 
> >        valid_lft forever preferred_lft forever
> > 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
> >     link/ether 8c:70:5a:2b:24:74 brd ff:ff:ff:ff:ff:ff
> > 4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 
> >     link/ether 52:54:00:2a:c6:e2 brd ff:ff:ff:ff:ff:ff
> >     inet 10.11.12.1/24 brd 10.11.12.255 scope global virbr0
> >        valid_lft forever preferred_lft forever
> > 5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 500
> >     link/ether 52:54:00:2a:c6:e2 brd ff:ff:ff:ff:ff:ff
> > 7: macvtap0 at p6p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
> >     link/ether 52:54:00:1c:e6:a5 brd ff:ff:ff:ff:ff:ff
> >     inet6 fe80::5054:ff:fe1c:e6a5/64 scope link 
> >        valid_lft forever preferred_lft forever
> > [root at dodo:~]# 
> > [root at dodo:~]# ip r
> > default via 10.39.0.254 dev p6p1 
> > 10.11.12.0/24 dev virbr0  proto kernel  scope link  src 10.11.12.1 
> > 10.39.0.0/20 dev p6p1  proto kernel  scope link  src 10.39.3.47 
> > [root at dodo:~]# 
> > [root at dodo:~]# iptables-save 
> > # Generated by iptables-save v1.4.16.2 on Fri May 24 09:00:42 2013
> > *nat
> > :PREROUTING ACCEPT [117442:23112300]
> > :INPUT ACCEPT [1823:282770]
> > :OUTPUT ACCEPT [192:23149]
> > :POSTROUTING ACCEPT [188:21200]
> > -A POSTROUTING -s 10.11.12.0/24 ! -d 10.11.12.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
> > -A POSTROUTING -s 10.11.12.0/24 ! -d 10.11.12.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
> > -A POSTROUTING -s 10.11.12.0/24 ! -d 10.11.12.0/24 -j MASQUERADE
> > COMMIT
> > # Completed on Fri May 24 09:00:42 2013
> > # Generated by iptables-save v1.4.16.2 on Fri May 24 09:00:42 2013
> > *mangle
> > :PREROUTING ACCEPT [177170:66443653]
> > :INPUT ACCEPT [56076:43349146]
> > :FORWARD ACCEPT [0:0]
> > :OUTPUT ACCEPT [35446:9156840]
> > :POSTROUTING ACCEPT [35535:9181312]
> > -A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
> > COMMIT
> > # Completed on Fri May 24 09:00:42 2013
> > # Generated by iptables-save v1.4.16.2 on Fri May 24 09:00:42 2013
> > *filter
> > :INPUT ACCEPT [56056:43346125]
> > :FORWARD ACCEPT [0:0]
> > :OUTPUT ACCEPT [35446:9156840]
> > -A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
> > -A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
> > -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
> > -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
> > -A FORWARD -d 10.11.12.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
> > -A FORWARD -s 10.11.12.0/24 -i virbr0 -j ACCEPT
> > -A FORWARD -i virbr0 -o virbr0 -j ACCEPT
> > -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
> > -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
> > COMMIT
> > # Completed on Fri May 24 09:00:42 2013
> > [root at dodo:~]# 
> > [root at dodo:~]# arp -na|grep 2.47
> > ? (10.39.2.47) at <incomplete> on p6p1
> 
> # guest (qemu-kvm, fedora19) ip 10.39.2.47/20
> 
> > [root at fedora19 ~]# ip a
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
> >     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> >     inet 127.0.0.1/8 scope host lo
> >        valid_lft forever preferred_lft forever
> >     inet6 ::1/128 scope host 
> >        valid_lft forever preferred_lft forever
> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
> >     link/ether 52:54:00:1c:e6:a5 brd ff:ff:ff:ff:ff:ff
> >     inet 10.39.2.47/20 brd 10.39.15.255 scope global eth0
> >        valid_lft forever preferred_lft forever
> >     inet6 fe80::5054:ff:fe1c:e6a5/64 scope link 
> >        valid_lft forever preferred_lft forever
> > [root at fedora19 ~]# 
> > [root at fedora19 ~]# 
> > [root at fedora19 ~]# ip r
> > default via 10.39.0.254 dev eth0 
> > 10.39.0.0/20 dev eth0  proto kernel  scope link  src 10.39.2.47 
> > [root at fedora19 ~]# 
> > [root at fedora19 ~]# 
> > [root at fedora19 ~]# iptables-save 
> > # Generated by iptables-save v1.4.18 on Fri May 24 09:07:22 2013
> > *filter
> > :INPUT ACCEPT [247:30338]
> > :FORWARD ACCEPT [0:0]
> > :OUTPUT ACCEPT [117:13684]
> > COMMIT
> > # Completed on Fri May 24 09:07:22 2013
> > [root at fedora19 ~]# 
> > [root at fedora19 ~]# 
> > [root at fedora19 ~]# arp -na|grep .47
> > ? (10.39.3.47) at <incomplete> on eth0
> > [root at fedora19 ~]# 
> 
> If I monitoring with tcpdump when I ping from guest 2.47 to host 3.47 I
> see this:
> 
> > [root at dodo:~]# tcpdump -nni p6p1 host 10.39.2.47
> > 09:15:12.672329 ARP, Request who-has 10.39.3.47 tell 10.39.2.47, length 28
> > 09:15:13.673653 ARP, Request who-has 10.39.3.47 tell 10.39.2.47, length 28
> > 09:15:14.675706 ARP, Request who-has 10.39.3.47 tell 10.39.2.47, length 28
> > 09:15:16.673190 ARP, Request who-has 10.39.3.47 tell 10.39.2.47, length 28
> 
> Then is a ARP problem.
> 
> The host find arp entry on interface p6p1, but the guest is on
> "macvtap0 at p6p1" device
> 
> also, it's not possible monitoring on "macvtap0 at p6p1" device:
> > [root at dodo:~]# tcpdump -nni macvtap0 at p6p1 host 10.39.2.47
> > tcpdump: macvtap0 at p6p1: No such device exists
> > (SIOCGIFHWADDR: No such device)
> 
> Other test.
> 
> On guest I add manually the ARP entry:
> > [root at fedora19 ~]# ip neighbor rep 10.39.3.47 lladdr d0:67:e5:4c:47:ce dev eth0 nud permanent
> 
> Now when I ping 3.47 from 2.47, on 3.47 I got this:
> 
> > [root at dodo:~]# tcpdump -nni p6p1 host 10.39.2.47
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> > listening on p6p1, link-type EN10MB (Ethernet), capture size 65535 bytes
> > 09:26:16.413265 IP 10.39.2.47 > 10.39.3.47: ICMP echo request, id 2257, seq 1, length 64
> > 09:26:17.413021 IP 10.39.2.47 > 10.39.3.47: ICMP echo request, id 2257, seq 2, length 64
> > 09:26:18.412995 IP 10.39.2.47 > 10.39.3.47: ICMP echo request, id 2257, seq 3, length 64
> 
> Now try add the ARP entry on host 3.47 but I got this error:
> > [root at dodo:~]# ip neighbor rep 10.39.2.47 lladdr 52:54:00:1c:e6:a5 dev macvtap0 at p6p1 nud permanent
> > Cannot find device "macvtap0 at p6p1"
> 
> seem It's not possible to assign it on macvtap0 at p6p1, this is not a device.
> 
> Some suggest?
> 

When I was using macvtap I had the same problem. I found an article in
the libvirt wiki that described the problem and a work-aroung:

http://wiki.libvirt.org/page/Guest_can_reach_outside_network,_but_can%
27t_reach_host_%28macvtap%29

I hope it helps.




More information about the virt mailing list