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@xxxxxxxxxxxxxxxxxxx [mailto:xen-users-
> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of David Dyer-Bennet
> Sent: Monday, September 22, 2008 17:48
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxx; 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home