Just to chime in here, yes, fasthosts may be causing you trouble. Your
VM has a different MAC, so if they're doing anything with smart
switches which only allow certain mac addresses on certain ports. They
could be blocking you. It might be worth while to call them and ask if
you need to let them know if more than one mac is coming from your one
port.

Doug

On Wed, Jun 9, 2010 at 6:09 PM, Jamie McDonald <jm...@iclebyte.com> wrote:
> Soren,
>
> Good timing! I was just about to write another email as I've been playing
> with this all evening - alas still no joy.
>
> On Wed, Jun 9, 2010 at 10:24 PM, Soren Hansen <so...@ubuntu.com> wrote:
>>
>> On Wed, Jun 09, 2010 at 02:57:45PM +0100, Jamie McDonald wrote:
>> > The output of 'brctl show' on the host is as follows
>> >
>> > ## START brctl output ###
>> >
>> > $brctl show
>> > bridge name     bridge id               STP enabled     interfaces
>> > br0             8000.001999705a61       no                  eth0
>> >
>> > vnet0
>> > ## END brctl output ##
>>
>> I'm not sure if this output got linebroken somewhere. Can you perhaps
>> make sure the terminal you're using is large enough to hold the output
>> and put it on a pastebin so we can be sure noone's e-mail application is
>> messing with the formatting?
>
>  I have pasted a new copy here: http://pastebin.org/322148
>
>>
>> > From looking at this it looks like I should have my guest configured
>> > to use the vnet0 interface instead of br0?
>>
>> No. vnet0 /is/ your guest. The virtual machines use tap devices for
>> networking. Think of vnet0 as the host end of the virtual network cable
>> between the guets and the host. It is meant to be connected to br0 such
>> that eth0 and vnet0 both are "connected".
>
> Thanks for your explanation - this makes more sense. Based on what you have
> said then the VM is having the vnet0 tap interface created and successfully
> attached to the br0 interface along with eth0 as per the pastebin mentioned
> above.
>>
>> > brtables has not been modified in any way.
>>
>> Ok. And you haven't used Eucalyptus? It's the only thing I know of that
>> might fiddle with brtables behind the scenes.
>
> No I have not used Eucalyptus - this is a standard 9.10 build of Ubuntu
> server from Fasthosts.
>>
>> What is eth0 on the host, by the way? What kind of NIC?
>>
> # dmesg | grep eth0
> [    3.694657] 0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1)
> 00:19:99:70:5a:61
> [    3.694659] 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
> [    3.694812] 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: ffffff-0ff
> [    9.403673] device eth0 entered promiscuous mode
> [    9.476752] ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   11.045806] 0000:00:19.0: eth0: Link is Up 100 Mbps Full Duplex, Flow
> Control: None
> [   11.045808] 0000:00:19.0: eth0: 10/100 speed: disabling TSO
> [   11.046300] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [   11.046373] br0: port 1(eth0) entering forwarding state
> [   21.972047] eth0: no IPv6 routers present
>
> During my experiments this afternoon I have actually become more confused.
> I have removed all firewall rules from the host in order to test as
> suggested by Alex (thankyou for your input kind sir). IP Forwarding is
> enabled (even though it should make no difference) and the following rules
> were added (although again I really don't think I should need them).
>
> /sbin/iptables -A FORWARD -d 88.208.249.45 -j ACCEPT
> /sbin/iptables -A FORWARD -s 88.208.249.45 -j ACCEPT
>
>
> On the host machine I started listening for guest traffic on the eth0
> interface using the following: tcpdump -i eth0 'host 88.208.249.45'
> From the VM I then executed 'ping 88.208.248.1'. The TCP dump of eth0 on the
> host shows the ARP's being received by the host, however no response is ever
> sent - this always results in a 'destination host unreachable' message on
> the VM. This is obviously the same for any IP address on the internet.
>
> # tcpdump -i eth0 'host 88.208.249.45'
> tcpdump: WARNING: eth0: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> 23:04:33.961261 arp who-has server88-208-248-1.live-servers.net tell
> server88-208-249-45.live-servers.net
> 23:04:34.961244 arp who-has server88-208-248-1.live-servers.net tell
> server88-208-249-45.live-servers.net
> 23:04:35.961234 arp who-has server88-208-248-1.live-servers.net tell
> server88-208-249-45.live-servers.net
> 23:04:36.971239 arp who-has server88-208-248-1.live-servers.net tell
> server88-208-249-45.live-servers.net
> 23:04:37.971239 arp who-has server88-208-248-1.live-servers.net tell
> server88-208-249-45.live-servers.net
> 23:04:38.971240 arp who-has server88-208-248-1.live-servers.net tell
> server88-208-249-45.live-servers.net
>
>
> Any other suggestions I could try? Is there anything which Fasthosts could
> have in place which could inhibit a bridged network from operating
> correctly?
>
> Kind Regards
> - An increasingly insane Jamie.
>
>
>
> --
> ubuntu-server mailing list
> ubuntu-server@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
> More info: https://wiki.ubuntu.com/ServerTeam
>



-- 
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Reply via email to