|
|
|
|
|
|
|
|
|
|
xen-users
Re: [Xen-users] multiple vif's/bridges
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
|
|
|
|
|