|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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@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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |