7

I am on a Debian upgraded from 7.11 to 8.5, so the xen package is upgraded from 4.1 to 4.4.

I do not know much about networks, but when I see a diagram like this (taken from the Xen Networking wiki page), I expect to be able to ping 198.51.100.27 with ping -I xenbr0 198.51.100.27, and vice versa from the virtual machine ping 198.51.100.1.

However, this is not the case. I set up a clean xenbr0 with

# brctl addbr xenbr0
# ifconfig xenbr0 192.168.12.1 netmask 255.255.255.0 up

and in the HVM configuration file

vif=["mac=11:22:33:44:55:66, ip='192.168.12.2', bridge=xenbr0"]

After I start the VM with xl create, this is the output from brctl show:

bridge name     bridge id               STP enabled     interfaces
xenbr0          8000.feffffffffff       no              vif3.0
                                                        vif3.0-emu

I connect to the VM with SPICE and configure it as shown below:

enter image description here

And since I am only trying to ping the default gateway I assume no name resolving will take place.

With this setup, ping 192.168.12.2 -I xenbr0 on the dom0 results in

PING 192.168.12.2 (192.168.12.2) from 192.168.12.1 xenbr0: 56(84) bytes of data.
From 192.168.12.1 icmp_seq=1 Destination Host Unreachable

and from the Windows VM, ping 192.168.12.1 from cmd has the output

Pinging 192.168.12.1 with 32 bytes of data:
Reply from 192.168.12.2: Destination host unreachable.

which suggests the machines have no idea about how to reach each other. Aren't they supposed to be linked by xl create? Why does this happen?

sikerbela
  • 616
  • 7
  • 16
  • 1
    I agree with your expectation. You have the option of running a `tcpdump` listener on the interface targeted by the ping. This will show whether the interface receives the ARP probe, which the ping'ing host uses to search for the target IP address. And whether it sends an ARP response. (You can see what a request looks like if you run tcpdump on the ping'ing host). E.g. tcpdump captures packets _before_ firewall rules are applied. Good to try in both directions as you did with plain ping test... though you might find it easiest to get such a packet capture on the Linux side. – sourcejedi Aug 06 '16 at 12:57
  • As from what I see, both sides can send ARP probes, the Windows VM asks who-has 192.168.2.1 and the Debian Dom0 asks who-has 192.168.2.2 but neither receives a response. I don't know what ARP responses look like, but for sure I did not see anything looking like "yes this MAC address has that IP you've been asking for" – sikerbela Aug 06 '16 at 14:12
  • You just mentioned offhand now, "the Windows VM;" I would suggest please adding this information in the title, as well as at least once in the question. Be sure to include which version of Windows, and which shell you are using in Windows! – forgotstackxpassword Aug 06 '16 at 16:54
  • Apologies for complexity - and I don't have ideas either way - but the more interesting part IMO was whether the ARP probe is received at the target. I.e. if they can be received at both ends, it shows the bridge is actually passing some packets. Although ARP probes are a bit special in that they are sent to the broadcast address, instead of to a specific Ethernet address. – sourcejedi Aug 06 '16 at 19:07
  • I just discovered the ARP probes *do* reach the vif and the vif *does* respond with "192.168.2.2 is at 11:22:..." when pinging from the dom0 but `ping` still says `Destination Host Unreachable`. Logs on the way. – sikerbela Aug 07 '16 at 01:00
  • Pinging from the dom0: [xenbr0](http://dpaste.com/0YSNKSM.txt) [vif2.0](http://dpaste.com/3M6C2JW.txt) Pinging from the domU: [xenbr0](http://dpaste.com/1Q5ZD9T.txt) [vif2.0](http://dpaste.com/0JM5FPQ.txt) – sikerbela Aug 07 '16 at 01:10
  • how is that all going; i wonder if there are some defaults in xen or one of your systems blocking icmp/ping or something like that – forgotstackxpassword Aug 26 '16 at 16:45
  • I ended up dedicating a wifi dongle to the VM. However, I think there is something essential missing when we omit the `eth0` device. – sikerbela Aug 29 '16 at 10:56

2 Answers2

1

If everything is setup correctly, you should be able to ping, no problem.

At first, try the recommended configurations:

If you are just wanting to study how the routes work, you might make a paravirtualized (PV) setup, instead of HVM, as you mentioned; but if you stick with HVM make sure you have the drivers for Windows installed. This is all outlined at the very top of the Xen guide. It also explains how to assign a MAC address, the MAC address in the post as of writing, is invalid--which is ok sometimes for virtual situations, but not for every configuration.

When you setup your xenbr0 on the host, the bridge essentially replaces the eth0 interface on Debian-based systems. It is true that (from the xen guide) eth0 is optional "By omitting the physical Ethernet device an isolated network containing only guest domains can be created," but the examples in the guide, as well as your post here, are not worded that way. For future readers as well, in a Fedora-family virtual client, as well with Windows, please see all the documentation for slightly different configuration requirements. This, specifically sounds like your problem, unless you are blocked by a firewall, tcp wrappers, or anything else not mentioned in the original post.

Confirmation

In Windows you can verify the network setup with, for example, ipconfig /all.

In the Xen sample configurations from the same website that we both already referenced, it suggests below, as well as other configurations, for the host; for example, type all of the below, without skipping the first part.

Example 2: A single bridged network using eth0 configured with a static local IP address

iface eth0 inet manual

iface xenbr0 inet static

    bridge_ports eth0
    address 192.168.1.2
    broadcast 192.168.1.255
    netmask 255.255.255.0
    gateway 192.168.1.1

You can confirm this with ifconfig and route on both your dom0 and dom1, or similar tools on the host, as explained in the link above and make sure that it is all configured correctly.

Basic tweaking

If you want to make sure that neither reach the internet (or other parts of a network, in general), other than keeping the physical cable unplugged of course, you could change the default gateway to 0.0.0.0, and then add a "route" (a box should be just below in most Network Manager-style GUIs), with the same client IP address and subnet mask, but then with the address of the host, as a gateway. In some GUIs there is even a box that says something like "allow this connection route only for the local network."

Adding a "route" in your Windows client may also act as a work around to solve your original problem.

forgotstackxpassword
  • 466
  • 1
  • 4
  • 17
  • Why should `eth0` be up? Even if the machine does not have external connectivity or even a physical link, shouldn't I expect it to be connected to the inner virtual machines? – sikerbela Aug 06 '16 at 11:41
  • In Xen the bridge lays over an existing physical device, so that the virtual devices can get out to the network; I understand what you're getting at in theory, but if everything is set up correctly, and nothing blocking it it should work. I've updated the phrase formerly in my answer about eth0 "up," I was referring to "...remove the IP settings from eth0 and move them to the bridge interface. ....eth0 will function purely as the physical uplink from the bridge so it can't have any IP (L3) settings on it..." from the guide. – forgotstackxpassword Aug 06 '16 at 16:48
  • I think it is clear in the question- there is no `eth0` in my setup. There is only a `xenbr0` over `vifX.0` interfaces. However, I still expect to be able to ping `vifX.0` and so the `xenbr0` over it from the virtual `eth` and vice versa, and since it is obviously not working, I would like to know why. – sikerbela Aug 06 '16 at 17:54
  • Yeah cool, thanks for the clarification. The only significant, but crucial, thing I was suggesting, was that according to the standard xen documentation, you *need* eth0, at least in the sense that, that is your interface which then is transformed into br0. You're still right on to ask the question, theoretically, "is it possible to only have the br0," everyone can still look into it. – forgotstackxpassword Aug 06 '16 at 19:07
  • if you add more info also it would help others or also myself clarifying this answer, for example, if you are using Windows. – forgotstackxpassword Aug 06 '16 at 19:08
  • I added a small note at the end of the answer about "routes." Thanks for updating the info about Windows a bit. – forgotstackxpassword Aug 06 '16 at 21:12
1

(Can't comment as that requires 50 rep)

Since the packets arrive on the vif and the vif part of the bridge, the next step would be to check ebtables and iptables(iptables -L), especially if /proc/sys/net/bridge/bridge-nf-call-iptables is 1 and netfilter therefore inspects packets on the bridge.

maxf
  • 1,609
  • 9
  • 12
  • looks like you could post it now as a comment, racking up the points! I think you're right on here, I was just saying above there must be icmp block in a firewall, etc. – forgotstackxpassword Aug 26 '16 at 16:47