[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Network-bridge script with bonding and vlan



----- Original Message ----- From: "Ewan Mellor" <ewan@xxxxxxxxxxxxx>


The new script allows for one bridge per outgoing interface, I think, so in
your case one bridge per VLAN ought to be possible.  Why do you need one
bridge per domain? What are you bridging in this case? The topology we use uses a bridge to plex all of the guests onto a specific outgoing interface --
so what are you bridging to require one per domain?

The main outcome I'm trying to achieve is isolation between the domains. Typically we would have this separation between our production servers (not all lumped together on one LAN). Having the separation at layer 2 would seem like to be a positive thing to maintain. Using the VLAN interfaces gives the impression that the machine has many network adapters [this would seem to me to be a good fit with a virtualisation technology].

In the trivial case the xen support is vif0.0->veth0, and vifN.0->eth0
(where N is a non-zero domain number).
Do your arrows refer to incoming packets?  If so, I think that is right,
though veth0 is renamed to eth0 now, so that dom0 sees a "normal" eth0
interface.

Sorry, I wasn't very clear there. Yes, incoming packets, or backend<->frontend.


The scripts seem to treat xen0 as a special case, and I'm not sure why.
Domain 0 is the privileged domain i.e. the one that manages the creation of other domains. It comes up on boot, and is where things like the script in question are running. That is why it is a special case. Also, it is arranged
so that dom0's interface appears to have the MAC address of the underlying
NIC -- you can't do this with the guest domains, of course.

Got that. But could the part of the dom0 script that configures the dom0 vif0.0<->veth0 part of the networking be extracted/pluggable just like the domU setup of the vifN.0 interface.

I've no idea whether that makes sense, but why are you trying to do it?

I guess it comes from the desire not to configure an interface one way, and then moments later tear it all down and configure it another way. I can see that the current way is great for development, and integrates well with an existing machine - not sure I'd want to head in that direction on a non-development system.

The bottom line, I think, is that Xen does not try to do everything with
network configuration.  We are happy to help, and happy to provide example

Thanks very much for your feedback. I lot of my comments are probably due to being a relative newbie.

Most of the configuration I have been doing has been with the fc4 init scripts. I'm looking for less, rather than more. However I am having problems getting packets forwarded/bridged correctly. ICMP pings seem to work just fine, but the only way to get TCP/UDP packets to forward is to attach tcpdump to the VLAN interface. I probably missing something very obvious. I don't have the machine in front of me (and the networking isn't working), so can't post the current config.

I'm unclear as to why the physical/bridge/backend interfaces need to have a special mac address (fe:ff:ff:ff:ff:ff), and why they need arp disabled (since they have no IP address). What is special about fe:ff:ff:ff:ff:ff? Could it be any locally assigned unicast mac address?

Greg.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.