Thanks for taking the time Tom and Philipp, it's clearer now. > Based on the address, the appropriate interface can be selected; that is > impossible in your routing configuration.
I'll do some more RTFM. Regards Mark On Thursday 23 August 2007 20:56, Tom Eastep <[EMAIL PROTECTED]> may have written: > On Thu, 2007-08-23 at 20:29 +0200, Mark Furner wrote: > > Hmm > > > > Sorry. I'm trying to bind some xen virtual machines on my server in the > > manner you describe in [1] but with less external machines and subnets > > involved. > > > > * One local zone spanning both real NICs eth0 and eth1, which are shared > > by the DomUs. (IP range static: 192.168.1.2-10) > > ... > > * A VPN server listening on eth1 in Dom0 has its own zone, IP range > > also set to within the same subnet. (192.168.1.55-60) > > No! > > If you are going to partition the 192.168.1.0/24 network by interface > you have to do proper subnetting based on powers of two. You can't break > it up into partitions based on the total number of fingers that humans > have (which is the basis for our millenniums-old love affair with > base-10). > > What Phillip is suggesting is that you use different /24 IP networks for > each interface (not switch from a one /24 to one /16). Compare what you > are doing with my firewall (output abbreviated for clarity): > > 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000 > link/ether 00:19:21:d0:61:65 brd ff:ff:ff:ff:ff:ff > inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0 > ------------------ > inet6 fe80::219:21ff:fed0:6165/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:02:e3:08:55:fa brd ff:ff:ff:ff:ff:ff > inet 192.168.3.254/24 brd 192.168.3.255 scope global eth1 > ---------------- > inet6 fe80::202:e3ff:fe08:55fa/64 scope link > valid_lft forever preferred_lft forever > 6: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue > link/ether 00:a0:cc:db:31:c4 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.254/24 brd 192.168.1.255 scope global br0 > ---------------- > inet6 fe80::2a0:ccff:fedb:31c4/64 scope link > valid_lft forever preferred_lft forever > 8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,10000> mtu 1500 qdisc pfifo_fast > qlen 100 link/[65534] > inet 192.168.2.1 peer 192.168.2.2/32 scope global tun0 > ----------- > 9: eth3: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue > link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff > inet 206.124.146.176/32 brd 206.124.146.255 scope global eth3 > ------------------ > inet6 fe80::fcff:ffff:feff:ffff/64 scope link > valid_lft forever preferred_lft forever > > Notice that each interface (with the exception of tun0 and the > Xen-renamed 'eth3') is a different RFC 1918 network. In your > configuration, they are all the same network! > > My eth3 is configured as a single address (/32) -- your Xen VIFs > are /24s and are the same /24 as all of the other interfaces. > > Here's my Routing table (Annotated and abbreviated for clarity) > > 206.124.146.177 dev eth3 scope link src 206.124.146.176 > <====== Xen DomU 192.168.2.2 dev tun0 proto kernel scope link src > 192.168.2.1 <====== Routed OpenVPN Clients 192.168.3.0/24 dev > eth1 proto kernel scope link src 192.168.3.254 <====== Wifi > 192.168.2.0/24 via 192.168.2.2 dev tun0 > <====== Peer on OpenVPN perm interface tun0 192.168.1.0/24 dev br0 proto > kernel scope link src 192.168.1.254 <====== Local LAN and > 206.124.146.0/24 dev eth0 proto kernel scope link src 206.124.146.176 > <====== External Network default via 206.124.146.254 dev eth0 > <====== Default route via ISP's router > > Based on the address, the appropriate interface can be selected; that is > impossible in your routing configuration. > > Phillip was trying to encourage you to do the same thing. If you need to > do more reading about subnetting and routing, there is a brief treatment > of the subject in the Shorewall Setup Guide > (http://www.shorewall.net/shorewall_setup_guide.htm). Or you may want to > get a good introductory addressing and routing text (I can't recommend a > current one -- the one I learned from is out of date and out of print). > > -Tom ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
