From: Vangelis Koukis Date: Mon, 10 Mar 2014 14:13:56 +0000 (+0200) Subject: Fix a few typos X-Git-Url: https://code.grnet.gr/git/snf-network/commitdiff_plain/4b1eede6bd8344ea6417c07a43eda1e5df5c9248 Fix a few typos --- diff --git a/docs/index.rst b/docs/index.rst index 716d794..88fe304 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -7,7 +7,7 @@ Welcome to snf-network's documentation! ======================================= snf-network is a set of scripts that handle the network configuration of -an instance inside a Ganeti cluster. It takes advantange of the +an instance inside a Ganeti cluster. It takes advantage of the variables that Ganeti exports to their execution environment and issue all the necessary commands to ensure network connectivity to the instance based on the requested setup. @@ -40,7 +40,7 @@ are inherited by the network in which a NIC resides (optional). Scripts ------- -The scripts can be devided into two categories: +The scripts can be divided into two categories: 1. The scripts that are invoked explicitly by Ganeti upon NIC creation. @@ -51,13 +51,13 @@ The first group has the exact NIC info that is about to be configured where the latter one has the info of the whole instance. The big difference is that instance configuration (from the master perspective) might vary or be total different from the one that is currently running. The reason is that some -modifications can take place without hotplug. +modifications can take place without hotplugging. kvm-ifup-custom ^^^^^^^^^^^^^^^ -Ganeti upon instance startup and NIC hotplug creates the TAP devices to +Ganeti upon instance startup and NIC hotplugging creates the TAP devices to reflect to the instance's NICs. After that it invokes the Ganeti's `kvm-ifup` script with the TAP name as first argument and an environment including all NIC's and the corresponding network's info. This script searches for @@ -89,7 +89,7 @@ example script which executes `/etc/xen/scripts/vif-custom` if found. snf-network-hook ^^^^^^^^^^^^^^^^ -This hook gets all static info related to an instance from evironment variables +This hook gets all static info related to an instance from environment variables and issues any commands needed. It was used to fix node's setup upon migration when ifdown script was not supported but now it does nothing. @@ -101,7 +101,7 @@ This hook updates an external `DDNS `_ setup via ``nsupdate``. Since we add/remove entries during ifup/ifdown scripts, we use this only during instance remove/shutdown/rename. It does not rely on exported environment but it queries first the DNS server to obtain current entries and -then it invokes the neccessary commands to remove them (and the relevant +then it invokes the necessary commands to remove them (and the relevant reverse ones too). @@ -121,9 +121,9 @@ ip-less-routed This setup has the following characteristics: -* An external gateway on the same collition domain with all nodes on some +* An external gateway on the same collision domain with all nodes on some interface (e.g. eth1, eth0.200) is needed. -* Each node is a router for the hostes VMs +* Each node is a router for the hosted VMs * The node itself does not have an IP inside the routed network * The node does proxy ARP for IPv4 networks * The node does proxy NDP for IPv6 networks while RA and NA are @@ -153,7 +153,7 @@ Since we suppose to be on the same link with the router, ARP takes place first: - ARP, Request who-has GW_IP tell IP - ARP, Reply GW_IP is-at TAP_MAC ``echo 1 > /proc/sys/net/conf/TAP/proxy_arp`` - - So `arp -na` insided the VM shows: ``(GW_IP) at TAP_MAC [ether] on eth0`` + - So `arp -na` inside the VM shows: ``(GW_IP) at TAP_MAC [ether] on eth0`` 2) The host wants to know the GW_MAC. Since the node does **not** have an IP inside the network we use the dummy one specified above. @@ -180,7 +180,7 @@ With the above we have a working proxy ARP configuration. The rest is done via simple L3 routing. Lets assume the following: * ``TABLE`` is the extra routing table -* ``SUBNET`` is the IPv4 subnet where the VM's IP reside +* ``SUBNET`` is the IPv4 subnet where the VM's IP resides 1) Outgoing traffic: @@ -193,7 +193,7 @@ via simple L3 routing. Lets assume the following: - Packet arrives at router - Router knows from proxy ARP that the IP is at DEV_MAC. - - Router sends ethernet packet with tgt DEV_MAC + - Router sends Ethernet packet with tgt DEV_MAC - Host receives the packet from DEV interface - Traffic coming out DEV is routed via TABLE ``ip rule add dev DEV table TABLE`` @@ -223,17 +223,17 @@ private-filtered ^^^^^^^^^^^^^^^^ In order to provide L2 isolation among several VMs we can use ebtables on a -**single** bridge. The infrastracture must provide a physical VLAN or separate -interaface shared among all nodes in the cluster. All virtual interfaces will +**single** bridge. The infrastructure must provide a physical VLAN or separate +interface shared among all nodes in the cluster. All virtual interfaces will be bridged on a common bridge (e.g. ``prv0``) and filtering will be done via ebtables and MAC prefix. The concept is that all interfaces on the same L2 -should have the same MAC prefix. MAC prefix uniqueness is quaranteed by -synnefo and passed to Ganeti as a network option. +should have the same MAC prefix. MAC prefix uniqueness is guaranteed by +Synnefo and passed to Ganeti as a network option. To ensure isolation we should allow traffic coming from tap to have specific source MAC and at the same time allow traffic coming to tap to have a source MAC in the same MAC prefix. Applying those rules only in FORWARD chain will not -guarantee isolation. The reason is because packets with target MAC a `mutlicast +guarantee isolation. The reason is because packets with target MAC a `multicast address `_ go through INPUT and OUTPUT chains. To sum up the following ebtables rules are applied: