David Dyer-Bennet
2008-Sep-19 22:42 UTC
[Xen-users] Still confused about bridging (I think)
I know I''m confused about *something*, because packets aren''t
getting
through.
The hardware has two NICs, eth0 connects to the corporate lan on
192.168.1.14, and to a private cluster lan on 172.17.0.1.
In dom0, I can reach systems on both lans.
In a guest on 172.17.1.2, I can''t reach anything. Nothing in 172.17,
nothing in 192.168.1. The guest is domain 9, called vl01.
In dom0 A bridge, xenbr0 (specified in my control files for the domains),
is set up to let everybody talk to everywhere.
[root@prcapp02 xen]# brctl show
bridge name bridge id STP enabled interfaces
virbr0 8000.000000000000 yes
xenbr0 8000.2ed4b2e93fd1 no vif9.0
vif7.0
tap0
peth0
vif0.0
In dom0 the following interfaces exist (I think most exist only
accidentally, from starting and stopping test domains as I try to work out
what''s going on):
[root@prcapp02 xen]# ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: peth0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 00:1e:c9:b3:2a:88 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global eth1
inet 172.17.0.100/16 brd 172.17.255.255 scope global secondary eth1:100
inet6 fe80::21e:c9ff:feb3:2a88/64 scope link
valid_lft forever preferred_lft forever
4: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
inet6 fe80::200:ff:fe00:0/64 scope link
valid_lft forever preferred_lft forever
6: vif0.0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
7: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 00:1e:c9:b3:2a:86 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.14/24 brd 192.168.1.255 scope global eth0
inet 192.168.1.16/32 brd 192.168.1.16 scope global eth0:16
inet6 fe80::21e:c9ff:feb3:2a86/64 scope link
valid_lft forever preferred_lft forever
8: vif0.1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
9: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
10: vif0.2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
11: veth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
12: vif0.3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
13: veth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
14: xenbr0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 2e:d4:b2:e9:3f:d1 brd ff:ff:ff:ff:ff:ff
24: vif7.0: <NO-CARRIER,BROADCAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen
32
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
25: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
500
link/ether 2e:d4:b2:e9:3f:d1 brd ff:ff:ff:ff:ff:ff
inet6 fe80::2cd4:b2ff:fee9:3fd1/64 scope link
valid_lft forever preferred_lft forever
27: vif9.0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
32
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
I can''t capture what''s on the domU, since VNC is refusing to
have anything
to do with cut-and-paste. But the single eth0 has the right address,
and the routing table has the right gateway (172.17.0.100).
tcpdump on the domU shows traffic for 192.168.1 going past, but no sign of
any traffic for 172.17 even when I make sure there is some.
--
David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Javier Guerra
2008-Sep-19 23:02 UTC
Re: [Xen-users] Still confused about bridging (I think)
On Fri, Sep 19, 2008 at 5:42 PM, David Dyer-Bennet <dd-b@dd-b.net> wrote:> I know I''m confused about *something*, because packets aren''t getting > through. > > The hardware has two NICs, eth0 connects to the corporate lan on > 192.168.1.14, and to a private cluster lan on 172.17.0.1. > > In dom0, I can reach systems on both lans. > > In a guest on 172.17.1.2, I can''t reach anything. Nothing in 172.17, > nothing in 192.168.1. The guest is domain 9, called vl01. > > In dom0 A bridge, xenbr0 (specified in my control files for the domains), > is set up to let everybody talk to everywhere. > > [root@prcapp02 xen]# brctl show > bridge name bridge id STP enabled interfaces > virbr0 8000.000000000000 yes > xenbr0 8000.2ed4b2e93fd1 no vif9.0 > vif7.0 > tap0 > peth0 > vif0.0where''s the ''way out'' from xenbr0? IOW, is peth0 connected to a real NIC? i think you should set two bridges, one connected to eth0 (192.168.1.14) , and the other to eth1 (172.17.0.1), then if you want a DomU on 172.17.x.x, connect it''s vif to the second bridge. -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
David Dyer-Bennet
2008-Sep-20 16:51 UTC
Re: [Xen-users] Still confused about bridging (I think)
Javier Guerra wrote:> On Fri, Sep 19, 2008 at 5:42 PM, David Dyer-Bennet <dd-b@dd-b.net> wrote: > >> I know I''m confused about *something*, because packets aren''t getting >> through. >> >> The hardware has two NICs, eth0 connects to the corporate lan on >> 192.168.1.14, and to a private cluster lan on 172.17.0.1. >> >> In dom0, I can reach systems on both lans. >> >> In a guest on 172.17.1.2, I can''t reach anything. Nothing in 172.17, >> nothing in 192.168.1. The guest is domain 9, called vl01. >> >> In dom0 A bridge, xenbr0 (specified in my control files for the domains), >> is set up to let everybody talk to everywhere. >> >> [root@prcapp02 xen]# brctl show >> bridge name bridge id STP enabled interfaces >> virbr0 8000.000000000000 yes >> xenbr0 8000.2ed4b2e93fd1 no vif9.0 >> vif7.0 >> tap0 >> peth0 >> vif0.0 >> > > where''s the ''way out'' from xenbr0? IOW, is peth0 connected to a real NIC? >Yes, that''s the "real" nic. Xen seems to have renamed the interfaces.> i think you should set two bridges, one connected to eth0 > (192.168.1.14) , and the other to eth1 (172.17.0.1), then if you want > a DomU on 172.17.x.x, connect it''s vif to the second bridge. >A bridge is a MAC-layer device, it never even looks at the IP address in the packet (the packet need not, in fact, be IP at all). So I''d need a pretty detailed explanation of how this might help before it''s even worth trying. -- David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
David Dyer-Bennet wrote:> Javier Guerra wrote: > >> On Fri, Sep 19, 2008 at 5:42 PM, David Dyer-Bennet <dd-b@dd-b.net> wrote: >> >> >>> I know I''m confused about *something*, because packets aren''t getting >>> through. >>> >>> The hardware has two NICs, eth0 connects to the corporate lan on >>> 192.168.1.14, and to a private cluster lan on 172.17.0.1. >>> >>> In dom0, I can reach systems on both lans. >>> >>> In a guest on 172.17.1.2, I can''t reach anything. Nothing in 172.17, >>> nothing in 192.168.1. The guest is domain 9, called vl01. >>> >>> In dom0 A bridge, xenbr0 (specified in my control files for the >>> domains), >>> is set up to let everybody talk to everywhere. >>> >>> [root@prcapp02 xen]# brctl show >>> bridge name bridge id STP enabled interfaces >>> virbr0 8000.000000000000 yes >>> xenbr0 8000.2ed4b2e93fd1 no vif9.0 >>> vif7.0 >>> tap0 >>> peth0 >>> vif0.0 >>> >> >> >> where''s the ''way out'' from xenbr0? IOW, is peth0 connected to a real NIC? >> > > > Yes, that''s the "real" nic. Xen seems to have renamed the interfaces. > >> i think you should set two bridges, one connected to eth0 >> (192.168.1.14) , and the other to eth1 (172.17.0.1), then if you want >> a DomU on 172.17.x.x, connect it''s vif to the second bridge.I agree with David here. It is the easiest way; otherwise, you''ll have to setup your own routing. I noticed some oddities (although things are constantly being renamed so everything depends on which version you are running :). For starters, on my system (xen-3.0.2-2) the veth devices disappear once xend is started. I have 3 nics in dom0, each dedicated to one of 3 bridges: WAN, LAN, and DMZ. The bridges and the peth devices are all set to NOARP while the eth and vif devices are all set to ARP ON. None of the nics, vifs, peths or bridges have IPs. domU #1 gets 3 virtual nics, one on each of the 3 bridges, and does all routing and firewalling between them. All public servers are on domUs attached to the DMZ, all development domUs are attached to the LAN. My ISP provides me with a /29 network giving me 7 public IPs on the WAN. This has worked rock solid since April ''06. my $0.02. Mike Wright :m)>> > > > A bridge is a MAC-layer device, it never even looks at the IP address in > the packet (the packet need not, in fact, be IP at all). So I''d need a > pretty detailed explanation of how this might help before it''s even > worth trying. >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
David Dyer-Bennet
2008-Sep-22 13:46 UTC
Re: [Xen-users] Still confused about bridging (I think)
On Sat, September 20, 2008 12:37, Mike Wright wrote:> David Dyer-Bennet wrote: >> Javier Guerra wrote: >> >>> On Fri, Sep 19, 2008 at 5:42 PM, David Dyer-Bennet <dd-b@dd-b.net> >>> wrote: >>> >>> >>>> I know I''m confused about *something*, because packets aren''t getting >>>> through. >>>> >>>> The hardware has two NICs, eth0 connects to the corporate lan on >>>> 192.168.1.14, and to a private cluster lan on 172.17.0.1. >>>> >>>> In dom0, I can reach systems on both lans. >>>> >>>> In a guest on 172.17.1.2, I can''t reach anything. Nothing in 172.17, >>>> nothing in 192.168.1. The guest is domain 9, called vl01. >>>> >>>> In dom0 A bridge, xenbr0 (specified in my control files for the >>>> domains), >>>> is set up to let everybody talk to everywhere. >>>> >>>> [root@prcapp02 xen]# brctl show >>>> bridge name bridge id STP enabled interfaces >>>> virbr0 8000.000000000000 yes >>>> xenbr0 8000.2ed4b2e93fd1 no vif9.0 >>>> vif7.0 >>>> tap0 >>>> peth0 >>>> vif0.0 >>>> >>> >>> >>> where''s the ''way out'' from xenbr0? IOW, is peth0 connected to a real >>> NIC? >>> >> >> >> Yes, that''s the "real" nic. Xen seems to have renamed the interfaces. >> >>> i think you should set two bridges, one connected to eth0 >>> (192.168.1.14) , and the other to eth1 (172.17.0.1), then if you want >>> a DomU on 172.17.x.x, connect it''s vif to the second bridge. > > I agree with David here. It is the easiest way; otherwise, you''ll have > to setup your own routing.Sounds like you''re *disagreeing* with me and agreeing with Javier to me. Which I wouldn''t bother to mention except I''m trying to be sure I''m understanding the rest of what you say properly.> I noticed some oddities (although things are constantly being renamed so > everything depends on which version you are running :). For starters, > on my system (xen-3.0.2-2) the veth devices disappear once xend is > started.That''s not happening in my setup (CentOS 5.2, which comes with xen 3.0.3). I''m still deeply confused about the different kinds of "interfaces" that are appearing on the list (from "ip addr list") and where they come from and what they''re for, though. There seems to be a complete and total absence of any documentation about this.> I have 3 nics in dom0, each dedicated to one of 3 bridges: WAN, LAN, and > DMZ. The bridges and the peth devices are all set to NOARP while the > eth and vif devices are all set to ARP ON. None of the nics, vifs, > peths or bridges have IPs.What''s the point of your multiple bridges? Are you trying to segment the traffic manually rather than letting the bridges figure it out themselves (which is after all their main purpose in life)? And how does traffic move between them, then? Again, bridges are MAC-layer devices. They don''t use IP addresses in their forwarding algorithms at all.> domU #1 gets 3 virtual nics, one on each of the 3 bridges, and does all > routing and firewalling between them. All public servers are on domUs > attached to the DMZ, all development domUs are attached to the LAN. My > ISP provides me with a /29 network giving me 7 public IPs on the WAN.So it looks like the purpose here is primarily keeping things from communicating when you don''t want them too? But my problem is that things can''t communicate when I do want them to. -- David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
David Dyer-Bennet wrote:> On Sat, September 20, 2008 12:37, Mike Wright wrote: > >>David Dyer-Bennet wrote: >> >>>Javier Guerra wrote: >>> >>> >>>>On Fri, Sep 19, 2008 at 5:42 PM, David Dyer-Bennet <dd-b@dd-b.net> >> >>I agree with David here. It is the easiest way; otherwise, you''ll have >>to setup your own routing. > > > Sounds like you''re *disagreeing* with me and agreeing with Javier to me. > Which I wouldn''t bother to mention except I''m trying to be sure I''m > understanding the rest of what you say properly.Sorry for my confusion. Looks like I was having a little trouble with this thread''s attributions :) I agree with *Javier*. Bridging was easy to setup and has worked reliably for me for the last 2 1/2 years. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Dustin Henning
2008-Sep-22 16:24 UTC
RE: [Xen-users] Still confused about bridging (I think)
David,
You appear to have an awful lot of interfaces I''m not familiar with.
Here''s what I can tell you in that regard:
-vifX.Y is the default naming convention for domU interfaces where X is the
domU and Y is the eth# in the domU
-tapX is an interface for an HVM domU, but X isn''t related to the domU
and I
don''t know how to tell which tap interface goes where
-xenbrX is the bridge on older Xen systems, usually a fake ethX is created
on these as well, and I thought it needed to be added to xenbr0 along with
the other interfaces, but I believe someone disagreed with me regarding that
on a previous thread where another user couldn''t get bridging working
-ethX is the bridge on newer Xen systems, and it has an IP assigned directly
instead of having a separate fake eth0
-pethX is the physical Ethernet interface as renamed by the Xen network
script
-I know of no reason why you would need to use multiple physical interfaces
and bridges for multiple networks/subnetworks unless they are physically
separated or perhaps separated by VLANs, this is assuming the NICs are
properly configured on the domUs and nothing is interfering with traffic on
the bridges or physical connection
-vif0.X - I don''t believe I have ever seen this before, as I have
always
seen dom0 use ethX one way or another, and yours appears to be doing that
based on your ip addr list output
-vethX - same as vif0.X
-It might be helpful to post the dom0 output from iptables -nL and route
-You might need to check out iptables and routes on your domUs
-Your physical switch could be limiting the port to one MAC or something
like this, I have seen issues with Cisco switches doing so in the past on
this list
Also, are you running SELinux? I haven''t read about any issues with
Xen
networking caused by it, but it''s probably worth investigating.
Good luck,
Dustin
-----Original Message-----
From: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of David
Dyer-Bennet
Sent: Friday, September 19, 2008 18:42
To: xen-users@lists.xensource.com
Subject: [Xen-users] Still confused about bridging (I think)
I know I''m confused about *something*, because packets aren''t
getting
through.
The hardware has two NICs, eth0 connects to the corporate lan on
192.168.1.14, and to a private cluster lan on 172.17.0.1.
In dom0, I can reach systems on both lans.
In a guest on 172.17.1.2, I can''t reach anything. Nothing in 172.17,
nothing in 192.168.1. The guest is domain 9, called vl01.
In dom0 A bridge, xenbr0 (specified in my control files for the domains),
is set up to let everybody talk to everywhere.
[root@prcapp02 xen]# brctl show
bridge name bridge id STP enabled interfaces
virbr0 8000.000000000000 yes
xenbr0 8000.2ed4b2e93fd1 no vif9.0
vif7.0
tap0
peth0
vif0.0
In dom0 the following interfaces exist (I think most exist only
accidentally, from starting and stopping test domains as I try to work out
what''s going on):
[root@prcapp02 xen]# ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: peth0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 00:1e:c9:b3:2a:88 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global eth1
inet 172.17.0.100/16 brd 172.17.255.255 scope global secondary eth1:100
inet6 fe80::21e:c9ff:feb3:2a88/64 scope link
valid_lft forever preferred_lft forever
4: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
inet6 fe80::200:ff:fe00:0/64 scope link
valid_lft forever preferred_lft forever
6: vif0.0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
7: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 00:1e:c9:b3:2a:86 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.14/24 brd 192.168.1.255 scope global eth0
inet 192.168.1.16/32 brd 192.168.1.16 scope global eth0:16
inet6 fe80::21e:c9ff:feb3:2a86/64 scope link
valid_lft forever preferred_lft forever
8: vif0.1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
9: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
10: vif0.2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
11: veth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
12: vif0.3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
13: veth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
14: xenbr0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 2e:d4:b2:e9:3f:d1 brd ff:ff:ff:ff:ff:ff
24: vif7.0: <NO-CARRIER,BROADCAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen
32
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
25: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
500
link/ether 2e:d4:b2:e9:3f:d1 brd ff:ff:ff:ff:ff:ff
inet6 fe80::2cd4:b2ff:fee9:3fd1/64 scope link
valid_lft forever preferred_lft forever
27: vif9.0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
32
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
I can''t capture what''s on the domU, since VNC is refusing to
have anything
to do with cut-and-paste. But the single eth0 has the right address,
and the routing table has the right gateway (172.17.0.100).
tcpdump on the domU shows traffic for 192.168.1 going past, but no sign of
any traffic for 172.17 even when I make sure there is some.
--
David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
David Dyer-Bennet
2008-Sep-22 21:47 UTC
RE: [Xen-users] Still confused about bridging (I think)
On Mon, September 22, 2008 11:24, Dustin Henning wrote:> David, > You appear to have an awful lot of interfaces I''m not familiar with.At this point I''m suspecting that CentOS (should be same as RHEL) 5.2 is considerably complicating my experience here. Their documentation isn''t answering any of these questions for me, though.> Here''s what I can tell you in that regard: > -vifX.Y is the default naming convention for domU interfaces where X is > the > domU and Y is the eth# in the domUSo vif 1.2 is the "other end" of probably eth2 in domain 1?> -tapX is an interface for an HVM domU, but X isn''t related to the domU and > I > don''t know how to tell which tap interface goes whereLuckily I have only one HVM domain at the moment, so there''s no ambiguity about what it connects to.> -xenbrX is the bridge on older Xen systems, usually a fake ethX is created > on these as well, and I thought it needed to be added to xenbr0 along with > the other interfaces, but I believe someone disagreed with me regarding > that > on a previous thread where another user couldn''t get bridging workingI think I created xenbr0, by including it in a "bridge=xenbr0" in the vif lien in /etc/xen/vl01.> -ethX is the bridge on newer Xen systems, and it has an IP assigned > directly > instead of having a separate fake eth0eth1 is, I believe, my physical second ethernet interface in this case. It connects to a private vlan used within this set of systems (I''m working towards a set of servers behind a load-balancer).> -pethX is the physical Ethernet interface as renamed by the Xen network > scriptYep, peth0 was eth0 originally. It connects to the corporate LAN.> -I know of no reason why you would need to use multiple physical > interfaces > and bridges for multiple networks/subnetworks unless they are physically > separated or perhaps separated by VLANs, this is assuming the NICs are > properly configured on the domUs and nothing is interfering with traffic > on > the bridges or physical connectionInteresting point there, in that eth1 is connected to a different vlan than eth0. With the switch handling it, I don''t think this will be visible in the packets and hence won''t propagate inside the server; but I''ve never worked with vlans in either form before.> -vif0.X - I don''t believe I have ever seen this before, as I have always > seen dom0 use ethX one way or another, and yours appears to be doing that > based on your ip addr list output > -vethX - same as vif0.XI have a vague memory that those are created in pairs for me by something in the startup scripts. i don''t think I''m using them for anything.> -It might be helpful to post the dom0 output from iptables -nL and route[root@prcapp02 xen]# iptables -nL Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED ACCEPT all -- 192.168.122.0/24 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vif1.0 Chain OUTPUT (policy ACCEPT) target prot opt source destination [root@prcapp02 xen]# ip route show 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.14 169.254.0.0/16 dev eth0 scope link 172.17.0.0/16 dev eth1 proto kernel scope link src 172.17.0.1 default via 192.168.1.254 dev eth0> -You might need to check out iptables and routes on your domUsiptables is empty in the domU I''m working with. The routing situation is screwy, and may be the underlying problem. I can''t get it to configure with the IP and routes I want. In my head, with the bridge setup (this domU plugged into a bridge that has everything else including both ethernet interfaces plugged into it) I think of my domU as being on a lan segment with everybody else. That should be simple (except it''ll be a multi-network LAN segment), but it doesn''t seem to be. I worked on bridge and routing code for a while in the 80s and 90s, so it''s possible that my vague belief that I understand something about how this works may be twisting around and biting me on the ass, too.> -Your physical switch could be limiting the port to one MAC or something > like this, I have seen issues with Cisco switches doing so in the past on > this listInteresting. I''ll have to think about how I could test this, because I believe the switch is from Cisco.> Also, are you running SELinux? I haven''t read about any issues with Xen > networking caused by it, but it''s probably worth investigating.It''s set to disabled currently (apparently a necessary step to getting LVS working). -- David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Javier Guerra
2008-Sep-22 22:09 UTC
Re: [Xen-users] Still confused about bridging (I think)
On Mon, Sep 22, 2008 at 4:47 PM, David Dyer-Bennet <dd-b@dd-b.net> wrote:> > On Mon, September 22, 2008 11:24, Dustin Henning wrote: >> -Your physical switch could be limiting the port to one MAC or something >> like this, I have seen issues with Cisco switches doing so in the past on >> this list > > Interesting. I''ll have to think about how I could test this, because I > believe the switch is from Cisco.also remember that an intelligent enough switch would detect the loop you''ve created by connecting both networks to the same switch (the software bridge) and disable it. -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, Sep 22, 2008 at 10:47 PM, David Dyer-Bennet <dd-b@dd-b.net> wrote:> > On Mon, September 22, 2008 11:24, Dustin Henning wrote: >> David, >> You appear to have an awful lot of interfaces I''m not familiar with. > > At this point I''m suspecting that CentOS (should be same as RHEL) 5.2 is > considerably complicating my experience here. Their documentation isn''t > answering any of these questions for me, though. > >> Here''s what I can tell you in that regard: >> -vifX.Y is the default naming convention for domU interfaces where X is >> the >> domU and Y is the eth# in the domU > > So vif 1.2 is the "other end" of probably eth2 in domain 1? > >> -tapX is an interface for an HVM domU, but X isn''t related to the domU and >> I >> don''t know how to tell which tap interface goes where > > Luckily I have only one HVM domain at the moment, so there''s no ambiguity > about what it connects to. > >> -xenbrX is the bridge on older Xen systems, usually a fake ethX is created >> on these as well, and I thought it needed to be added to xenbr0 along with >> the other interfaces, but I believe someone disagreed with me regarding >> that >> on a previous thread where another user couldn''t get bridging working > > I think I created xenbr0, by including it in a "bridge=xenbr0" in the vif > lien in /etc/xen/vl01. > >> -ethX is the bridge on newer Xen systems, and it has an IP assigned >> directly >> instead of having a separate fake eth0 > > eth1 is, I believe, my physical second ethernet interface in this case. > It connects to a private vlan used within this set of systems (I''m working > towards a set of servers behind a load-balancer). > >> -pethX is the physical Ethernet interface as renamed by the Xen network >> script > > Yep, peth0 was eth0 originally. It connects to the corporate LAN. > >> -I know of no reason why you would need to use multiple physical >> interfaces >> and bridges for multiple networks/subnetworks unless they are physically >> separated or perhaps separated by VLANs, this is assuming the NICs are >> properly configured on the domUs and nothing is interfering with traffic >> on >> the bridges or physical connection > > Interesting point there, in that eth1 is connected to a different vlan > than eth0. With the switch handling it, I don''t think this will be > visible in the packets and hence won''t propagate inside the server; but > I''ve never worked with vlans in either form before. > >> -vif0.X - I don''t believe I have ever seen this before, as I have always >> seen dom0 use ethX one way or another, and yours appears to be doing that >> based on your ip addr list output >> -vethX - same as vif0.X > > I have a vague memory that those are created in pairs for me by something > in the startup scripts. i don''t think I''m using them for anything.http://wiki.xensource.com/xenwiki/XenNetworking explains that 7 pairs of "connected virtual ethernet interfaces" are created but I really do not understand why that is necessary? and on my system I only see 4: ip link list | grep vif 2: vif0.0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop 4: vif0.1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop 6: vif0.2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop 8: vif0.3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop I have one HVM running: 1 8: vif6.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 32 And there is one bridge called eth0 which has the physical and vif6.0 in it: brctl show bridge name bridge id STP enabled interfaces eth0 8000.003048c39d98 no peth0 tap0 vif6.0 I need to create a second bridge with eth1, and a third bridge which needs to have a virtual interface on the dom0. I plan to connect several windows hvm''s that have been migrated from hardware to the third bridge so that they can talk to each other and get internet access through dom0, but they must NOT be able to talk to the lan on physical eth0 as bringing up duplicate domain controllers and servers would not be good at all,I guess that is what the "connected virtual ethernet interfaces" are for but I am unsure about how to create the 2 extra bridges, once the 3rd bridge is there I guess I need to configure a ip on the dom0 virtual interface that is connected to the bridge and setup some iptables rules to allow internet but block access to the local lan. I need to test a microsoft exchange 2003 > 2007 migration before I do it on the real servers, the upgrade has gone wrong once already and with a small window of time to do it I need to be sure it will be successful. I see no xenbr0 at all, so what do I need to put in the config files to use the 2nd or 3rd bridge? I am running Xen 3.2.1 on Gentoo with kernel 2.6.25.15, any help would be appreciated. Andy> >> -It might be helpful to post the dom0 output from iptables -nL and route > > [root@prcapp02 xen]# iptables -nL > Chain INPUT (policy ACCEPT) > target prot opt source destination > ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 > ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67 > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > ACCEPT all -- 0.0.0.0/0 192.168.122.0/24 state > RELATED,ESTABLISHED > ACCEPT all -- 192.168.122.0/24 0.0.0.0/0 > ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 > REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with > icmp-port-unreachable > REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with > icmp-port-unreachable > ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match > --physdev-in vif1.0 > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > > [root@prcapp02 xen]# ip route show > 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.14 > 169.254.0.0/16 dev eth0 scope link > 172.17.0.0/16 dev eth1 proto kernel scope link src 172.17.0.1 > default via 192.168.1.254 dev eth0 > > >> -You might need to check out iptables and routes on your domUs > > iptables is empty in the domU I''m working with. > > The routing situation is screwy, and may be the underlying problem. I > can''t get it to configure with the IP and routes I want. > > In my head, with the bridge setup (this domU plugged into a bridge that > has everything else including both ethernet interfaces plugged into it) I > think of my domU as being on a lan segment with everybody else. That > should be simple (except it''ll be a multi-network LAN segment), but it > doesn''t seem to be. > > I worked on bridge and routing code for a while in the 80s and 90s, so > it''s possible that my vague belief that I understand something about how > this works may be twisting around and biting me on the ass, too. > > >> -Your physical switch could be limiting the port to one MAC or something >> like this, I have seen issues with Cisco switches doing so in the past on >> this list > > Interesting. I''ll have to think about how I could test this, because I > believe the switch is from Cisco. > >> Also, are you running SELinux? I haven''t read about any issues with Xen >> networking caused by it, but it''s probably worth investigating. > > It''s set to disabled currently (apparently a necessary step to getting LVS > working). > > -- > David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ > Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ > Photos: http://dd-b.net/photography/gallery/ > Dragaera: http://dragaera.info > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
David Dyer-Bennet
2008-Sep-23 14:22 UTC
Re: [Xen-users] Still confused about bridging (I think)
On Mon, September 22, 2008 17:58, Andrew Lyon wrote:> > I see no xenbr0 at all, so what do I need to put in the config files touse the 2nd or 3rd bridge? Always remembering that my setup isn''t yet working, so my advice should be viewed with a bit of healthy skepticism -- I do believe I''ve succeeded in creating additional bridges. And it was very simple. To create my xenbr0, all I did was put: vif = [ "mac=00:16:3e:44:fb:8c,bridge=xenbr0" ] into /etc/xen/vl01 (where vl01 is one of my domain config files). For multiple ethernet interfaces in the guest, you just need multiple entries in the brackets (same as for disks, for example). -- David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info -- David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
David Dyer-Bennet
2008-Sep-23 14:22 UTC
Re: [Xen-users] Still confused about bridging (I think)
On Mon, September 22, 2008 17:09, Javier Guerra wrote:> On Mon, Sep 22, 2008 at 4:47 PM, David Dyer-Bennet <dd-b@dd-b.net> wrote: >> >> On Mon, September 22, 2008 11:24, Dustin Henning wrote: >>> -Your physical switch could be limiting the port to one MAC or something >>> like this, I have seen issues with Cisco switches doing so in the past on >>> this list >> >> Interesting. I''ll have to think about how I could test this, because Ibelieve the switch is from Cisco.> > also remember that an intelligent enough switch would detect the loopyou''ve created by connecting both networks to the same switch (the software bridge) and disable it. The bridge shouldn''t be causing an actual loop, that''s what the spanning-tree protocol is all about. -- David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info -- David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Dustin Henning
2008-Sep-23 14:26 UTC
RE: [Xen-users] Still confused about bridging (I think)
OK, my response is below, as I tried to do whatever that reply method is called, but it felt like mangling the integrity of the original e-mail to me (some of which was already deleted, some being deleted by me, and the rest being mangled by >''s). Also, no need for a flame war here or a long conversation about posting techniques in an inappropriate thread., but for your information (and everyone else on the group, none of whom have specifically complained at me for top posting thus far), I won''t be doing that again. The response took twice as long to create, and I find it far easier to top post a response while I find it just as easy to follow such a top-posted response. Dustin> -----Original Message----- > From: xen-users-bounces@lists.xensource.com [mailto:xen-users- > bounces@lists.xensource.com] On Behalf Of David Dyer-Bennet > Sent: Monday, September 22, 2008 17:48 > To: xen-users@lists.xensource.com > Subject: RE: [Xen-users] Still confused about bridging (I think) > > > On Mon, September 22, 2008 11:24, Dustin Henning wrote: > At this point I''m suspecting that CentOS (should be same as RHEL) 5.2 > is > considerably complicating my experience here. Their documentation > isn''t > answering any of these questions for me, though. >Your assumption should be generally correct, so I will skip most of this...> > So vif 1.2 is the "other end" of probably eth2 in domain 1? >Yes, if xenbr0 is the switch, vif1.2 is dom1''s eth2 cable/switchport...> > Luckily I have only one HVM domain at the moment, so there''s no > ambiguity > about what it connects to. > > > I think I created xenbr0, by including it in a "bridge=xenbr0" in the > vif > lien in /etc/xen/vl01. > > > eth1 is, I believe, my physical second ethernet interface in this case. > It connects to a private vlan used within this set of systems (I''m > working > towards a set of servers behind a load-balancer). > > > Yep, peth0 was eth0 originally. It connects to the corporate LAN. > > > Interesting point there, in that eth1 is connected to a different vlan > than eth0. With the switch handling it, I don''t think this will be > visible in the packets and hence won''t propagate inside the server; but > I''ve never worked with vlans in either form before. >Based on the above paragraph, I am assuming your VLANs are port specific and untagged. In this case, putting eth1 on the bridge (also, the IP address might need moved off of eth1 and onto a virtual interface, but I''m not sure on that) so that you could connect to both networks would effectively be the same as connecting a crossover cable between a port from each of the VLANs. While this would be functional, presumably you don''t want to do so and therefore do need multiple bridges, as otherwise you wouldn''t have set up multiple VLANs on the switch to begin with (unless they were to be connected by a router, in which case you still wouldn''t want to do that). This is to say that multiple networks/subnetworks can run on the same network segment, and VLANs are used primarily to dampen broadcast traffic or prevent hosts on one VLAN from communicating via the other VLAN (even a Windows host can have IPs from multiple networks on the same NIC).> > I have a vague memory that those are created in pairs for me by > something > in the startup scripts. i don''t think I''m using them for anything. > > > -It might be helpful to post the dom0 output from iptables -nL and > route > > [root@prcapp02 xen]# iptables -nL > Chain INPUT (policy ACCEPT) > target prot opt source destination > ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 > ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67 > ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > ACCEPT all -- 0.0.0.0/0 192.168.122.0/24 state > RELATED,ESTABLISHED > ACCEPT all -- 192.168.122.0/24 0.0.0.0/0 > ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 > REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject- > with > icmp-port-unreachable > REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject- > with > icmp-port-unreachable > ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV > match > --physdev-in vif1.0 > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination >I should have asked for the output from iptables-save, iptables -nL isn''t really informative enough. That said, the only command I have on my forwarding chain is this one: -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT Then I have the chain dropping all other traffic by way of a default rule. This configuration merits running iptables on domUs, though (not that yours doesn''t; I can''t be sure what some of the rules are doing).> > [root@prcapp02 xen]# ip route show > 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.14 > 169.254.0.0/16 dev eth0 scope link > 172.17.0.0/16 dev eth1 proto kernel scope link src 172.17.0.1 > default via 192.168.1.254 dev eth0 > > > iptables is empty in the domU I''m working with. > > The routing situation is screwy, and may be the underlying problem. I > can''t get it to configure with the IP and routes I want. > > In my head, with the bridge setup (this domU plugged into a bridge that > has everything else including both ethernet interfaces plugged into it) > I > think of my domU as being on a lan segment with everybody else. That > should be simple (except it''ll be a multi-network LAN segment), but it > doesn''t seem to be. > > I worked on bridge and routing code for a while in the 80s and 90s, so > it''s possible that my vague belief that I understand something about > how > this works may be twisting around and biting me on the ass, too. >Your routing looks fine, unless you want to d orouting instead of bridging within Xen, in which case I have no familiarity. As mentioned above, this setup you envision would defeat your VLANs by tying them together with your single bridge or require you to have multiple bridges. Also, as an aside, I don''t believe the loop prevention Javier mentioned would apply, as there would be no loop with two isolated VLANs tied together in one place, that is unless your VLANs were already tied together, in which case the second VLAN could already be communicated on through the bridge and your second NIC wouldn''t even be necessary. However, I am assuming he is talking about SPF and the like (switching loop prevention protocols) based on the fact that he said loop; it may be that some switches can have a security configuration that would prevent such an interconnection on layer 2, preventing a crossover cable between VLANs from practically rendering the two VLANs into one VLAN on two switches (or perhaps even on layer 3, preventing routing between VLANs).> > Interesting. I''ll have to think about how I could test this, because I > believe the switch is from Cisco. >Here''s one thread that lead to my Cisco comments: http://lists.xensource.com/archives/html/xen-users/2008-08/msg00597.html I believe there are more detailed ones regarding the one MAC Address per port thing, but I''ll let you look into that when/if you determine that only one box (dom0 or domU) is able to actually communicate with each network.> > It''s set to disabled currently (apparently a necessary step to getting > LVS > working). > > -- > David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ > Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ > Photos: http://dd-b.net/photography/gallery/ > Dragaera: http://dragaera.info > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Dustin Henning
2008-Sep-23 14:28 UTC
RE: [Xen-users] Still confused about bridging (I think)
> However, I am assuming he is talking about > SPF > and the like (switching loop prevention protocols) based on the fact > that he > said loop;Oops, I got my OSPF and STP mixed up, gotta love acronyms. I guess you already knew that, though, based on your last post. Dustin _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Javier Guerra
2008-Sep-23 14:37 UTC
Re: [Xen-users] Still confused about bridging (I think)
On Tue, Sep 23, 2008 at 9:22 AM, David Dyer-Bennet <dd-b@dd-b.net> wrote:> > > On Mon, September 22, 2008 17:09, Javier Guerra wrote: >> also remember that an intelligent enough switch would detect the loop > you''ve created by connecting both networks to the same switch (the > software bridge) and disable it. > > The bridge shouldn''t be causing an actual loop, that''s what the > spanning-tree protocol is all about.that''s wishful thinking, i don''t have much faith on STP when first setting a network. after it''s running, i usually turn it on and verify that it didn''t break anything (as it often does). a general advice: first make it work, then make it better/nicer. in your case, that would mean doing the same as usual in the physical world when you have two separate networks: use two separate switches. -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Dustin Henning
2008-Sep-23 15:40 UTC
RE: [Xen-users] Still confused about bridging (I think)
David,
As pointed out by the link provided by Andrew below, eth0 probably
doesn''t need added to your xenbr0 because vif0.0 serves that purpose
(no
idea why none of my machines have it, but this would also explain why a
previous thread had another user saying this was unnecessary while I find it
is). This might also mean that you would want to add vif0.1 to xenbr0
instead of eth1 if you were going to tie the VLANs together (not
recommended, as the VLANs could be done away with completely if unnecessary,
and there would then be no need for eth1 [to keep them on separate bridges]
and no bottleneck between the networks/subnetworks [assuming traffic goes
between them]).
David and Andy,
I don''t use the Xen network-bridge script (see this thread on how to
disable it:
http://lists.xensource.com/archives/html/xen-users/2008-07/msg00111.html),
as I find it easier and more consistent to set up my own networking and let
Xen deal only with the virtual interfaces. That said, if you are to try
such a configuration, how additional bridges and dom0 virtual interfaces
should be set up would be dependent upon your dom0 OS.
Andy,
You might re-post your submission to xen-users@lists.xensource.com
with a unique subject and not as a reply instead of jumping into the middle
of this thread (I believe this is called hi-jacking, and I am assuming it
was unintentional) with your problem.
Dustin
-----Original Message-----
From: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Andrew Lyon
Sent: Monday, September 22, 2008 18:59
To: David Dyer-Bennet; xen-users@lists.xensource.com
Subject: Re: [Xen-users] Still confused about bridging (I think)
http://wiki.xensource.com/xenwiki/XenNetworking explains that 7 pairs
of "connected virtual ethernet interfaces" are created but I really do
not understand why that is necessary? and on my system I only see 4:
ip link list | grep vif
2: vif0.0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
4: vif0.1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
6: vif0.2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
8: vif0.3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
I have one HVM running: 1
8: vif6.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
qlen
32
And there is one bridge called eth0 which has the physical and vif6.0 in it:
brctl show
bridge name bridge id STP enabled interfaces
eth0 8000.003048c39d98 no peth0
tap0
vif6.0
I need to create a second bridge with eth1, and a third bridge which
needs to have a virtual interface on the dom0.
I plan to connect several windows hvm''s that have been migrated from
hardware to the third bridge so that they can talk to each other and
get internet access through dom0, but they must NOT be able to talk to
the lan on physical eth0 as bringing up duplicate domain controllers
and servers would not be good at all,I guess that is what the
"connected virtual ethernet interfaces" are for but I am unsure about
how to create the 2 extra bridges, once the 3rd bridge is there I
guess I need to configure a ip on the dom0 virtual interface that is
connected to the bridge and setup some iptables rules to allow
internet but block access to the local lan.
I need to test a microsoft exchange 2003 > 2007 migration before I do
it on the real servers, the upgrade has gone wrong once already and
with a small window of time to do it I need to be sure it will be
successful.
I see no xenbr0 at all, so what do I need to put in the config files
to use the 2nd or 3rd bridge?
I am running Xen 3.2.1 on Gentoo with kernel 2.6.25.15, any help would
be appreciated.
Andy
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users