hm, tcpdump from external -> eth3 of dom0 looks fine
tcpdump from exteran -> eth1 of domU = no reply
tcpdump from eth3 -> ext = fine
tcpdump from eth3->domU ... the ping says it's ok, but tcpdump shows
nothing
likewise domU->eth3 ... says it's pinging, but tcpdump shows nothing
so is what's happening here is both sides pinging the bridge, but nothing
is going through? i have this in dmesg:
device vif1.0 entered promiscuous mode
xen-br0: port 1(vif1.0) entering learning state
xen-br0: topology change detected, propagating
xen-br0: port 1(vif1.0) entering forwarding state
device vif1.1 entered promiscuous mode
xen-br1: port 2(vif1.1) entering learning state
xen-br1: topology change detected, propagating
xen-br1: port 2(vif1.1) entering forwarding state
so that looks good ...
i'm not supposed to make the domU gateway the same as the domO nic or
anything am i?
perhaps that dump information will clarify the problem ...
i hope =)
On Mon, 2 May 2005, Mark Doll wrote:
Hi Andrew!
andrew mathes wrote:
ok, so, ... brctl show shows this:
xen-br0 8000.001143fd7101 no eth0
vif10.0
vif11.0
vif12.0
vif9.0
xen-br1 8000.001143fd7102 no eth3
vif10.1
vif11.1
vif12.1
vif9.1
so obviously the interfaces are bound to the correct bridges, i just
can't reach any of the interfaces through the second bridge (eth0 isn't
plugged in ...)
This looks good. So since it worked for me, check if
- all interfaces are up including (the unconfigured) eth3 in domain0
- eth1 of domain10 (domain11, domain12) and the external host connected
to eth3 of domain0 are configured with the same IP subnet
- make shure that spoof protection makes no problems, so better disable
it by setting /proc/sys/net/conf/*/rp_filter to 0
- the bridge is in forwarding state? With dmesg you should see something
like
xen-br1: port 1(vif10.1) entering learning state
xen-br1: topology change detected, propagating
xen-br1: port 1(vif10.1) entering forwarding state
and so on for the other vifs
For debugging you should use something simpler than ssh. I always use
"ping" together with "tcpdump". I. e. in domain0 use "tcpdump -eni eth3
icmp or arp") to check how far the address resolution and the ping
packets go and if answers are coming in. Try this on all hosts.
Sometimes a broadcast ping, i. e. "ping -b 10.11.12.255" if your network
is 10.11.12.0/24, or "ping -I eth0 -b 255.255.255.255" if eth0 is on the
subet you wish to check, is more robust in the presence of misconfigured
IP addresses.
Mark.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home