mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-29 11:04:03 +01:00
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:
parent
88b57149a9
commit
d5b86045fa
@ -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 |
Loading…
Reference in New Issue
Block a user