Updates to Xen article

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@7658 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2007-11-14 16:18:17 +00:00
parent 88b57149a9
commit d5b86045fa
3 changed files with 25 additions and 7 deletions

View File

@ -331,8 +331,8 @@ bootentry = 'hda2:/boot/vmlinuz-xen,/boot/initrd-xen'
<para><command>ethtool -K eth0 tx off</command></para> <para><command>ethtool -K eth0 tx off</command></para>
<para>Under <trademark>SuSE</trademark> 10.2, I placed the following <para>Under <trademark>OpenSuSE</trademark> 10.2, I placed the
in following in
<filename><filename>/etc/sysconfig/network/ifcfg-eth-id-00:16:3e:b1:d7:90</filename></filename> <filename><filename>/etc/sysconfig/network/ifcfg-eth-id-00:16:3e:b1:d7:90</filename></filename>
(the config file for eth0):</para> (the config file for eth0):</para>
@ -350,10 +350,10 @@ bootentry = 'hda2:/boot/vmlinuz-xen,/boot/initrd-xen'
</caution> </caution>
<caution> <caution>
<para>Update. Under SuSE 10.2, communication from a domU works okay <para>Update. Under OpenSuSE 10.2, communication from a domU works
without running ethtool <emphasis role="bold">but traffic shaping in okay without running ethtool <emphasis role="bold">but traffic shaping
dom0 doesn't work!</emphasis> So it's a good idea to run it just to be in dom0 doesn't work!</emphasis> So it's a good idea to run it just to
safe.</para> be safe.</para>
</caution> </caution>
</section> </section>
@ -377,8 +377,26 @@ bootentry = 'hda2:/boot/vmlinuz-xen,/boot/initrd-xen'
by the DHCP server running in Dom0 and when they are attached by the DHCP server running in Dom0 and when they are attached
wirelessly, the IP address is assigned by OpenVPN.</para> wirelessly, the IP address is assigned by OpenVPN.</para>
<para>Readers who are paying attention will notice that eth4 has the
same public IP address (206.124.146.176) as eth0 (and eth3), yet the
<emphasis role="bold">test</emphasis> system connected to that interface
has an RFC 1918 address (192.168.1.7). That configuration is established
by Xen which clones the primary IP address of eth0 on all of the routed
virtual interfaces that it creates. <emphasis
role="bold">test</emphasis> is configured with it's default route via
192.168.1.254 which is the IP address of the firewall's br0. That works
because of the way that the Linux network stack treats local IPv4
addresses; by default, it will respond to ARP "who-has" broadcasts for
any local address and not just for the addresses on the interface that
received the broadcast (but of course the MAC address returned in the
"here-is" response is that of the interface that received the
broadcast). So when <emphasis role="bold">test</emphasis> broadcasts
"who-has 192.168.1.254", the firewall responds with "here-is
192.168.1.254 00:16:3e:83:ad:28" (00:16:3e:83:ad:28 is the MAC of
virtual interface eth4).</para>
<para>The Shorewall configuration files are shown below. All routing and <para>The Shorewall configuration files are shown below. All routing and
secondary IP addresses are handled in the SuSE network secondary IP addresses are handled in the OpenSuSE network
configuration.</para> configuration.</para>
<blockquote> <blockquote>

Binary file not shown.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 36 KiB

After

Width:  |  Height:  |  Size: 34 KiB