I''m trying to do firewalling on Xen, and am becoming a bit confused. I want to do filtering based on the interface name for a number of rules. I''d like to say: anything coming into dom0 from the internet is okay. I tried: anything coming in on physical interface peth0 with outgoing physical interface vif0.0 is okay. This seems to work. The one that doesn''t work: I want to say - anything from any domU to dom0 is NOT okay I said: if physical interface of incoming packets is not peth0 and destination physical interface is vif0.0 reject. This doesn''t seem to work, as the dom0 is no longer able to connect to things. Is there a good discussion as to which interfaces packets go to/from in which cases? When do packets go through peth0? When do they only go through the vif devices? I''m using firehol to generate the IPTables scripts... -- Luke _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I''m not sure if it makes sense to include peth0 and vif0.0 in your rules, as you mucking around with interfaces that are in the same bridge. If you''re just trying to firewall dom0 you should do something like: interface eth0 mydom0 server http accept client all accept ... Blocking traffic to the domU: Think of the domU as sitting on the same lan that dom0''s eth0 is connected to. Add rules to block traffic from domU''s IP address. If you *really* want to filter by interface, you might want to think about using xen''s routed configuration instead of the bridged config. Cheers, Dan. Luke wrote:> I''m trying to do firewalling on Xen, and am becoming a bit confused. > I want to do filtering based on the interface name for a number of > rules. > > I''d like to say: > anything coming into dom0 from the internet is okay. > > I tried: > anything coming in on physical interface peth0 with outgoing physical > interface vif0.0 is okay. > > This seems to work. > > > > The one that doesn''t work: > > I want to say - > anything from any domU to dom0 is NOT okay > > I said: > if physical interface of incoming packets is not peth0 and > destination physical interface is vif0.0 reject. > > This doesn''t seem to work, as the dom0 is no longer able to connect > to things. > > > Is there a good discussion as to which interfaces packets go to/from > in which cases? When do packets go through peth0? When do they only > go through the vif devices? > > I''m using firehol to generate the IPTables scripts... >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Feb 14, 2006, at 10:27 AM, Daniel Goertzen wrote:> I''m not sure if it makes sense to include peth0 and vif0.0 in your > rules, as you mucking around with interfaces that are in the same > bridge.Isn''t this what the bridge interface filtering tools are for? If I can just figure out when packets go through each interface, I should be able to do it (see IPTables or Firehol''s physin/physout commands).> If you''re just trying to firewall dom0 you should do something like:I need to do more than that, however.> Blocking traffic to the domU: Think of the domU as sitting on the > same lan that dom0''s eth0 is connected to. Add rules to block > traffic from domU''s IP address. If you *really* want to filter by > interface, you might want to think about using xen''s routed > configuration instead of the bridged config.I''d really rather not introduce that complication, since all I need to figure out is which virtual interfaces these types of packets go from/to. Plus, I''d really like to understand the packet flow through Xen''s dom0 and domUs Thanks -- Luke _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tuesday 14 February 2006 16:38, Luke wrote: ...> I''d really rather not introduce that complication, since all I need > to figure out is which virtual interfaces these types of packets go > from/to. Plus, I''d really like to understand the packet flow through > Xen''s dom0 and domUsThe flow is something like: packet arrives at hardware, is handled by dom0 eth driver and appears on peth0. peth0 is bound to to the bridge, so its passed to the bridge from there. This step is run on ethernet level, no IP addresses are set on peth0 or bridge. Now the bridge distributes the packet, just like a switch would. Filtering at this stage would be possible with eb_tables. now there''s a number of vifX.Y connected to the bridge, it decides where to put the packet based on the receivers MAC. the vif iface puts the packet into xen, which then puts the packet back to the domain the vif leads to (its also done that way for dom0, hence the vif0.0->(v)eth0 pair). The target device in the dom0/domU finally has an ip address, you can apply ip-tables filtering here. /Ernst _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
You are right, physin/physout should do the trick for well behaved interfaces and bridges (I am relatively new to firehol). The problem is that the xen interfaces don''t seem to be entirely normal: http://lists.xensource.com/archives/html/xen-users/2006-01/msg00684.html Not sure if this would break bridge filtering, but it should give you hint if things continue to not work. FYI I am implementing a firewall using firehol in a domU. It has 3 interfaces which are plugged into 3 bridges in my dom0 (internet, lan, and dmz). Only 2 of the bridges connect to physical ethernet interfaces (internet, lan); the other one is meant for routing to dmz domU''s only. My setup is not complete but partial tests are showing good results. Cheers, Dan. Luke wrote:> > On Feb 14, 2006, at 10:27 AM, Daniel Goertzen wrote: > >> I''m not sure if it makes sense to include peth0 and vif0.0 in your >> rules, as you mucking around with interfaces that are in the same >> bridge. > > > Isn''t this what the bridge interface filtering tools are for? If I > can just figure out when packets go through each interface, I should > be able to do it (see IPTables or Firehol''s physin/physout commands). > >> If you''re just trying to firewall dom0 you should do something like: > > > I need to do more than that, however. > >> Blocking traffic to the domU: Think of the domU as sitting on the >> same lan that dom0''s eth0 is connected to. Add rules to block >> traffic from domU''s IP address. If you *really* want to filter by >> interface, you might want to think about using xen''s routed >> configuration instead of the bridged config. > > > I''d really rather not introduce that complication, since all I need > to figure out is which virtual interfaces these types of packets go > from/to. Plus, I''d really like to understand the packet flow through > Xen''s dom0 and domUs > > Thanks >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 2006-02-14 at 10:44 -0600, Daniel Goertzen wrote:> FYI I am implementing a firewall using firehol in a domU. It has 3 > interfaces which are plugged into 3 bridges in my dom0 (internet, lan, > and dmz). Only 2 of the bridges connect to physical ethernet interfaces > (internet, lan); the other one is meant for routing to dmz domU''s only. > My setup is not complete but partial tests are showing good results.On the two systems I setup running xen3 and a firewall, I found it made much more sense to create a firewall domU with minimal OS, and do all my iptables filtering there. Just like Daniel describes, I created a bridge for each physical interface, connect the physical interface and firewall domU to each those bridges, then create one additional bridge (my XEN DMZ) to which I attached the firewall, dom0''s veth0 and all other domU''s. +-------+ +---------+ +-----------+ | peth0 |---| br0eth0 | +-------|veth0 dom0 | +-------+ +---------+ | +-----------+ | | +--eth0--+ | | | | | e | | fire1 t +--------+ +-----------+ | domU1 h---| br2dmz |---|eth0 domU2 | | 2 +--------+ +-----------+ | | | +--eth1--+ | | | +-------+ +---------+ | +-----------+ | peth1 |---| br1eth1 | +-------|eth0 domU3 | +-------+ +---------+ +-----------+ From the firewall domU''s perspective, it doesn''t see any bridges, just eth0, eth1, etc. This makes setting up firewall/nat rules much easier, plus it''s more secure, because you don''t need all the packages in the firewall domU that dom0 needs to run Xen. Plus, we''re not routing traffic through dom0''s IP stack (it just deals with bridging). Since dom0 is where all the physical network interfaces, bridges, and disk devices are visible, it is the most critical system on the box, security wise. If someone gets into dom0, they have the keys to the kingdom. By not routing any traffic through dom0, and keeping it behind the firewall (or making it completely inaccessible from the network), you reduce the risk that someone could access it and compromise your whole network of systems. -- Patrick Wolfe email: pwolfe@employease.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, Feb 14, 2006 at 12:51:16PM -0500, Patrick Wolfe wrote:> On Tue, 2006-02-14 at 10:44 -0600, Daniel Goertzen wrote: > > FYI I am implementing a firewall using firehol in a domU. It has 3 > > interfaces which are plugged into 3 bridges in my dom0 (internet, lan, > > and dmz). Only 2 of the bridges connect to physical ethernet interfaces > > (internet, lan); the other one is meant for routing to dmz domU''s only. > > My setup is not complete but partial tests are showing good results. > > > On the two systems I setup running xen3 and a firewall, I found it made > much more sense to create a firewall domU with minimal OS, and do all my > iptables filtering there. Just like Daniel describes, I created a > bridge for each physical interface, connect the physical interface and > firewall domU to each those bridges, then create one additional bridge > (my XEN DMZ) to which I attached the firewall, dom0''s veth0 and all > other domU''s. > > +-------+ +---------+ +-----------+ > | peth0 |---| br0eth0 | +-------|veth0 dom0 | > +-------+ +---------+ | +-----------+ > | | > +--eth0--+ | > | | | > | e | > | fire1 t +--------+ +-----------+ > | domU1 h---| br2dmz |---|eth0 domU2 | > | 2 +--------+ +-----------+ > | | | > +--eth1--+ | > | | > +-------+ +---------+ | +-----------+ > | peth1 |---| br1eth1 | +-------|eth0 domU3 | > +-------+ +---------+ +-----------+ >My setup is similar to above, except I wanted dom0 only accessible on the private lan as follows: +-------+ +---------+ +-----------+ | peth0 |---| br0eth0 |----|eth0 domU2 | +-------+ +---------+ +-----------+ | +--eth0--+ | | | fire1 | | domU1 | | | +--eth1--+ | +-------+ +---------+ +----------+ | peth1 |---| br1eth1 |----|eth1 dom0 | +-------+ +---------+ +----------+ The domU''s can access anyone without trouble. Dom0 can successfully ping any IP address, but cannot connect to remote services. I''m accepting all services in iptables (firehol), and since no packets are being logged as blocked/dropped, I''m reasonably sure the iptables rules are correct. From dom0, attempting a wget of google''s homepage (64.233.187.99) shows the connection is successful, but the request times out waiting for a response: ~# wget 64.233.187.99 --13:59:05-- http://64.233.187.99/ => `index.html'' Connecting to 64.233.187.99:80... connected. HTTP request sent, awaiting response... The conntrack info in from /proc/net/ip_conntrack on the firewall confirms the connection is active (if i''m reading it right): ~# cat ip_conntrack tcp 6 264 ESTABLISHED src=192.168.1.20 dst=64.233.187.99 sport=1797 dport=80 packets=8 bytes=940 src=64.233.187.99 dst=<domU1 eth0 IP> sport=80 dport=1797 packets=1 bytes=44 [ASSURED] use=1 It appears as though the response comes all the way back to eth0 on the firewall (again, if i''m reading the above connection info right), but it doesn''t continue down to dom0. So my question is, how does one masquerade dom0 through a domU? Do forwarding rules need to be in place in dom0 between br0eth0 and br1eth1, or can all the iptables work be done in a domU? For reference, here''s my bridge setup showing the associated domain interfaces: ~# brctl show bridge name bridge id STP enabled interfaces xenbr0 8000.feffffffffff no peth0 vif1.0 vif2.0 xenbr1 8000.feffffffffff no peth1 vif0.1 vif1.1 Thanks for any insight, -Kevin _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Patrick Wolfe wrote:> On Tue, 2006-03-07 at 15:00 -0600, Kevin wrote: > > >> The domU''s can access anyone without trouble. Dom0 can successfully ping any IP address, but cannot connect to remote services. >> From dom0, attempting a wget of google''s homepage (64.233.187.99) shows the connection is successful, but the request times out >> > > It sounds like you haven''t run ''ethtool -K eth0 tx off'' on dom0. > > You need to run that command on every xen virtual ethernet interface, or > you get corrupt checksums on random packets. You can verify this by > running ''tcpdump'' or ''ethereal'' while doing the wget. > > I hope this fix this problem by 3.0.2. It''s sure annoying. > >You were exactly right Patrick; the following patch for /etc/xen/scripts/network-bridge (thanks Nicholas -- http://lists.xensource.com/archives/html/xen-users/2006-02/msg00747.html ) worked for me in fixing up my dom0''s eth1: add_to_bridge2 ${bridge} ${pdev} do_ifup ${netdev} + # disable ip checksum offloading for veth device + [ -x /usr/sbin/ethtool ] && /usr/sbin/ethtool -K ${netdev} tx off Thanks again, -Kevin _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I think that a better solution is to hide the pethX from dom0 and export them to the router domU, because in xen 3 you are limited to 3 interfaces per domU and you don''t get the overhead of the bridging code. The configuration files will be much simpler also. I think it was pciback.hide=(pcidev0)(...)(pcidevN) on the dom0 kernel command line and pci=[''pcidev0'',''...'',''pcidevN''] on the domU config file. Note that you must have drivers for the hardware in the domainU On Tue, 14 Feb 2006, Patrick Wolfe wrote:> On Tue, 2006-02-14 at 10:44 -0600, Daniel Goertzen wrote: >> FYI I am implementing a firewall using firehol in a domU. It has 3 >> interfaces which are plugged into 3 bridges in my dom0 (internet, lan, >> and dmz). Only 2 of the bridges connect to physical ethernet interfaces >> (internet, lan); the other one is meant for routing to dmz domU''s only. >> My setup is not complete but partial tests are showing good results. > > > On the two systems I setup running xen3 and a firewall, I found it made > much more sense to create a firewall domU with minimal OS, and do all my > iptables filtering there. Just like Daniel describes, I created a > bridge for each physical interface, connect the physical interface and > firewall domU to each those bridges, then create one additional bridge > (my XEN DMZ) to which I attached the firewall, dom0''s veth0 and all > other domU''s. > > +-------+ +---------+ +-----------+ > | peth0 |---| br0eth0 | +-------|veth0 dom0 | > +-------+ +---------+ | +-----------+ > | | > +--eth0--+ | > | | | > | e | > | fire1 t +--------+ +-----------+ > | domU1 h---| br2dmz |---|eth0 domU2 | > | 2 +--------+ +-----------+ > | | | > +--eth1--+ | > | | > +-------+ +---------+ | +-----------+ > | peth1 |---| br1eth1 | +-------|eth0 domU3 | > +-------+ +---------+ +-----------+ > > From the firewall domU''s perspective, it doesn''t see any bridges, just > eth0, eth1, etc. This makes setting up firewall/nat rules much easier, > plus it''s more secure, because you don''t need all the packages in the > firewall domU that dom0 needs to run Xen. Plus, we''re not routing > traffic through dom0''s IP stack (it just deals with bridging). Since > dom0 is where all the physical network interfaces, bridges, and disk > devices are visible, it is the most critical system on the box, security > wise. If someone gets into dom0, they have the keys to the kingdom. > > By not routing any traffic through dom0, and keeping it behind the > firewall (or making it completely inaccessible from the network), you > reduce the risk that someone could access it and compromise your whole > network of systems. > > -- > > Patrick Wolfe > > email: pwolfe@employease.com > >-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Patrick Wolfe wrote:> +-------+ +---------+ +-----------+ > | peth0 |---| br0eth0 | +-------|veth0 dom0 | > +-------+ +---------+ | +-----------+ > | | > +--eth0--+ | > | | | > | e | > | fire1 t +--------+ +-----------+ > | domU1 h---| br2dmz |---|eth0 domU2 | > | 2 +--------+ +-----------+ > | | | > +--eth1--+ | > | | > +-------+ +---------+ | +-----------+ > | peth1 |---| br1eth1 | +-------|eth0 domU3 | > +-------+ +---------+ +-----------+Don''t you find it troublesome that all of your domUs can communicate freely with each other? I''m thinking that if one domU is breached, a hacker will have total freedom to poke at any ports on any of the other domUs regardless of the firewall. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Don''t you find it troublesome that all of your domUs can communicate > freely with each other? > > I''m thinking that if one domU is breached, a hacker will have total > freedom to poke at any ports on any of the other domUs regardless of > the firewall.You are correct, but that''s typically how servers are setup in a DMZ in a non-consolidated environment. Each server is responsible for protecting itself from penetration. My firewall''s primary goal is to protect your INTERNAL systems from the internet and the DMZ systems. It also provides some protection for the DMZ systems, but if one of them has a hole and gets hacked, you want to make sure they can''t get any further than the DMZ. If you want to get all paranoid and isolate each domU from each other, go for it. Use the routed method, and have separate firewall rules for each server. Your firewall will be a little more heavily loaded, but that''s the price you pay. Also, keep in mind that XEN currently doesn''t support more than three network interfaces per domU, so you end up having to have one firewall for every two domU''s. In my opinion, a better solution is be to install shorewall (or whatever firewall package you like) on every domU, so it can protect itself. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Patrick Wolfe wrote:> You are correct, but that''s typically how servers are setup in a DMZ in > a non-consolidated environment. Each server is responsible for > protecting itself from penetration. My firewall''s primary goal is to > protect your INTERNAL systems from the internet and the DMZ systems. It > also provides some protection for the DMZ systems, but if one of them > has a hole and gets hacked, you want to make sure they can''t get any > further than the DMZ.Ok.> If you want to get all paranoid and isolate each domU from each other, > go for it. Use the routed method, and have separate firewall rules for > each server.Where would the router sit? A domU or in dom0 as per your previous diagram? In the dom0 case, wouldn''t you suddenly get traffic hitting dom0''s IP stack?> Your firewall will be a little more heavily loaded, but > that''s the price you pay. Also, keep in mind that XEN currently doesn''t > support more than three network interfaces per domU, so you end up > having to have one firewall for every two domU''s.Ok. I use VLANs to separate the domUs, and since the VLANs terminate in a virtual interface, I don''t suffer from this limitation.> In my opinion, a better solution is be to install shorewall (or whatever > firewall package you like) on every domU, so it can protect itself.It does have the advantage that it''s easier for each domU to define it''s own rules. But you sort of loose a lot of central management, I think. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Molle Bestefich wrote:>> If you want to get all paranoid and isolate each domU from each other, >> go for it. Use the routed method, and have separate firewall rules for >> each server. > > Where would the router sit? > A domU or in dom0 as per your previous diagram? > In the dom0 case, wouldn''t you suddenly get traffic hitting dom0''s IP > stack?That is the downside of using the routed method, all traffic hits dom0''s IP stack. The firewall package "shorewall" supports this configuration, so you could just make dom0 the firewall instead of a domU. Personally, I don''t like this config, but it would work.>> Also, keep in mind that XEN currently doesn''t >> support more than three network interfaces per domU, so you end up >> having to have one firewall for every two domU''s. > > Ok. I use VLANs to separate the domUs, and since the VLANs terminate > in a virtual interface, I don''t suffer from this limitation.Huh? It''s the virtual network interfaces that are limited to 3 per domU. The dom0 is the only domain that can have more interfaces (real or virtual).>> In my opinion, a better solution is be to install shorewall (or whatever >> firewall package you like) on every domU, so it can protect itself. > > It does have the advantage that it''s easier for each domU to define > it''s own rules. But you sort of loose a lot of central management, I > think.Yep, you have N+1 firewalls to manage, but typically host based firewalls don''t get modified very often. Typically only needed when you add or change a network service. But it can be a pain. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Molle Bestefich wrote:> > > I''m thinking that if one domU is breached, a hacker will have total > freedom to poke at any ports on any of the other domUs regardless of > the firewall.I disagree.In the topology presented in http://www.shorewall.net/XenMyWay.html, a breach of the most vulnerable domU (the ''lists'' domain) cannot compromise any of the other domUs or the dom0 or any of the local systems. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Saturday 08 July 2006 03:24, Tom Eastep wrote:> Molle Bestefich wrote: > > I''m thinking that if one domU is breached, a hacker will have total > > freedom to poke at any ports on any of the other domUs regardless of > > the firewall. > > I disagree.In the topology presented in > http://www.shorewall.net/XenMyWay.html, a breach of the most vulnerable > domU (the ''lists'' domain) cannot compromise any of the other domUs or > the dom0 or any of the local systems. > > -TomHello Tom, I''d like to take advantage of your presence here to make tyou a question... I saw that all your xen configurations use bridging, regardless of the complexity of the network topology one needs.... that not wrong in principle, of course .. my curiosity is about a you opinion about advantages and/or disadvantages of the the routing in a configuration in which one has a number of domUs not needing a public IP and running different services (it is a single server with its services splitted on different domUs).. In this configuration the dom0 being the router/firewal controlling all the traffic from the domUs to/from each others and to/from the net/fw... A your opninion would be very very apreciated as you are a very skilled person in this field (of course :-P) Regards -- Dr. Emiliano Gabrielli - Responsabile Divisione Informatica email: emiliano.gabrielli@deArchitettura.com deArchitettura.com Via Francesco Tovaglieri, 411 - 00155 Roma tel: 0645438979 | fax: 0645438980 | url: www.deArchitettura.com _________________________________________________________________________ CONFIDENZIALE: Le informazioni contenute nella presente comunicazione ed i relativi allegati sono confidenziali e riservati. Se avete ricevuto questo messaggio per errore, vi preghiamo di distruggerlo e di informarci immediatamente all''indirizzo email info@deArchitettura.com Ai sensi del D.Lgs. 196/2003 sulla privacy e dell''art. 616 del c.p. รจ proibita qualsiasi forma di riproduzione o divulgazione del documento trasmesso, senza l''esplicito consenso di deArchitettura.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Patrick Wolfe wrote:> Also, keep in mind that XEN currently doesn''t > support more than three network interfaces per domUThis is _not_ true (text copy-pasted from one of our test routers): dom0:~> uname -srm NetBSD 3.0_STABLE i386 dom0:~> pkg_info | grep xen xentools20-2.0.7nb7 Userland Tools for Xen xenconsole-0.15b1.1nb1 Console monitor for Xen domU:~> uname -srm NetBSD 3.0_STABLE i386 domU:~> ifconfig -a lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 xennet0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:01 inet xxx.xxx.xxx.xxx netmask 0xfffffff8 broadcast xxx.xxx.xxx.xxx inet6 fe80::a800:ff:fe01:7701%xennet0 prefixlen 64 scopeid 0x2 xennet1: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:02 inet xxx.xxx.xxx.xxx netmask 0xfffffff8 broadcast xxx.xxx.xxx.xxx inet6 fe80::a800:ff:fe01:7702%xennet1 prefixlen 64 scopeid 0x3 xennet2: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:03 xennet3: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:04 xennet4: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:05 xennet5: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:06 xennet6: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:07 xennet7: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:08 xennet8: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:09 xennet9: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:0a xennet10: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:0b xennet11: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:0c xennet12: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:0d xennet13: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:0e xennet14: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:0f xennet15: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: aa:00:00:01:77:10 domU:~> _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Martti Kuparinen wrote:> Patrick Wolfe wrote: > >> Also, keep in mind that XEN currently doesn''t support more than three >> network interfaces per domU > > This is _not_ true (text copy-pasted from one of our test routers):...> xennet15: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 > address: aa:00:00:01:77:10Sorry. I should have said XEN *version 3* only supports three virtual network interfaces per domU. Or is that a XEN3+Linux limitation only? I''ve never used XEN 2, nor XEN with NetBSD. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users