The network layer of OSI reference model takes care of routing, relaying, moving information from the source to the destination. The popular protocol of the network layer is the Internet Protocol (IP).
IP has two functions:
1. Addressing
2. Fragmentation
Addressing is about how each node in a network is identified. We make use of IP addresses here. There are two versions of IP addresses. We call them as IPv4 and IPv6 based on the version.
Fragmentation is necessary when the datagram (the information from the upper layer - transport layer) has to traverse through a number of networks where the allowed packet size is smaller than the source network. The IP takes care of this fragmentation at the source and reassembly at the destination. There are some fields in the IP header to allow the fragmentation and reassembly. Different fields and the IP header are explained in below paragraphs.
IP Header Structure
Version (4 bits): IP header
format (IP version)
Header Length (4 bits): Size of
IP header in multiples of 4 bytes. Minimum value is 5 (20 bytes)
Type of Service (1 byte): Specifies what
treatment the datagram should undergo as it traverses the network.
Total Length (2 bytes): Datagram length in bytes ? includes both header
and data. Maximum size 65535 bytes.
Identification (2 bytes): A value
assigned to the datagram by the sender. It is used in assembling the fragments
of a datagram, if required.
Flags (3 bits):
Fragmentation Offset (13 bits): Indicates where in the datagram this fragment
belongs. The offset is measured in units of 64 bits.
Time to Live (1 byte): Maximum
lifetime allowed for datagram. TTL is decremented by one each time the datagram
crosses a router; and the datagram is discarded once the TTL reaches zero. The
purpose is to avoid the possibility of undeliverable datagrams indefinitely
keep circulating over the Internet.
Protocol (1 byte): Indicates the protocol used by the sender.
Header Checksum (2 bytes): This field protects only the header fields.
Computation: Sum all 16-bit words, then get 1?s complement of it. While a
packet is passed from one network to the other, routers decrement the TTL
field. At that time, they have to re-compute header checksum and fill this
field.
Source and destination addresses:
4 bytes each for source and destination IPv4 addresses.
Options (variable length): This
field has some optional tools to monitor the proper functioning of several
network functionalities, namely: loose source routing option forces the
datagram to cross a given list of IP devices to reach its destination; the
strict source routing forces the datagram to cross exclusively the given list
of IP devices; the record route option is used to trace the route the datagram
takes; the timestamp option requires each traversed router to record (append)
its IP address and time to the datagram.
Padding: All zero field used to guarantee that the
header ends on a 32-bit boundary.
Reference: Hands-On Networking: From Theory to Practice
SR-IOV is a PCI device virtualization technology that allows a single PCI device to appear as multiple PCI devices on the physical PCI bus; the real physical device is called the Physical Function (PF) while the others are called Virtual Functions (VFs).
The purpose of this is for the hypervisor to directly assign one or more VFs to a virtual machine (VM) using Intel VT-D technology: the guest will be able to use the VF as any other directly assigned PCI device.
The common use case is an SR-IOV NIC. Assigning one or more VFs to a virtual machine allows the virtual machine to directly exploit the hardware without any mediation by the hypervisor. This means better performances and scalability since it has very little or no impact on dom0.
On the downside the VFs have no relations with VIFs and bridges in dom0 so they have to be configured separately and independently by the user. Also a virtual machine loses all the assigned VFs after being migrated to a different host. Thus, virtual machines that are migrated between hosts using XenMotion or High Availability (HA) failover require manual reinstatement of VFs on the new host.
Because Provisioning Services hosts tend to be network I/O bound rather than memory or CPU bound, they are ideal candidates to take advantage of this capability. The limitations on XenServer virtual machine failover and XenMotion are not significant in a Provisioning Services deployment because Provisioning Services implements its own HA and load balancing mechanisms.
Requirements
To make use of this capability, you must have a host server in which a SR-IOV capable network device is installed. The device tested for this article is the Intel® 82599 10 Gigabit Ethernet Controller.
Note: The setup procedure below requires that the 10 GigE NIC not be used as the management interface for the host. A second physical NIC must be installed on the system for that purpose.
Procedure
Use the following procedure to configure an SR-IOV-enabled Provisioning Services VM on XenServer 5.6, provided that your system meets the hardware and firmware requirements described above.
Enable iommu on the host
Edit /boot/extlinux.conf and add iommu=1 to the xen command line options.
Regenerate the bootloader by executing the following within the XenServer host console:
extlinux /boot
Loading the pciback driver into dom0
This must be done every time the host boots. To do this automatically, add the following line to /etc/rc.local:
modprobe pciback
Reboot the host
Assign one or more VFs to a virtual machine.
Get a list of VFs in the system executing the lspci command in the XenServer console. You should see many (such as 120) devices like this:
07:10.0 Ethernet controller: Intel Corporation 82559 Ethernet Controller Virtual Function (rev 01)
Assign one of these VFs to the target virtual machine executing the following command:
xe vm-param-set other-config:pci=0/0000:07:10.0 uuid=uuid_of_the_VM
Substitute 07:10.0 in the example above with the pci bus address of the VF you want to assign.
Boot the virtual machine and install the correct VF driver in it. Once the driver is installed, Provisioning Services should be installed and configured as normal.
Source
Citrix Xen Knowledge Center
Definition
The intention behind link aggregation is to have a logical interface with higher bandwidth other capabilities by combining a set of physical interfaces.
Different Names
Link aggregation is also called Ethernet Bonding or NIC Bonding or Network Bonding (or just Bonding), NIC Teaming (or just Teaming), Port Channel, Link Bundling, EtherChannel, MLT (Multi-Link Trunking), Trunking, Fat Pipe, etc.
Uses
The link aggregations are normally used as a solution for different requirements like
1. using limited IP address space to serve large amount of bandwidth using a number of physical links more than IP addresses
2. security where aggregated interface hides the existence of physical interfaces
3. better connection availability (no change in connection status even if one of the physical link fails)
4. higher performance using physical interfaces with performance less than required
5. load balancing to effectively use physical links to their capacity
Standard
Link aggregations now conform to the IEEE 802.3ad standard. The definition is now moved to a standalone
standard IEEE 802.1AX. The standard defines link aggregation like this: "Link Aggregation allows one or more links to be aggregated together to form a Link Aggregation Group, such that a MAC client can treat the Link Aggregation Group as if it were a single link". The standard also defined the Link Aggregation Control Protocol (LACP) for the networking devices that intend to support IEEE 802.3ad standard. The devices with LACP support can be used to form a link aggregation via LACP.
Applications
Based on the requirements, link aggregation can be typically used in different cases. It can be between two switches thus providing higher bandwidth between the hosts connected through them without hardware upgrade. It can be between a server and a switch in which case the network connection between the server and the switch can provide higher performance. It can also be between servers to provide higher bandwith transfers between them.
Other Sources
Link Aggregation at Wikipedia
Sun Documentation on Link Aggregation
IEEE 802.1AX-2008
A physical network adapter is also called a Network Interface Card or in short a NIC. The Crossbow project in OpenSolaris added more virtualization capabilities to the existing network stack starting from OpenSolaris Build 105. The latest OpenSolaris version 2009.06 has Crossbow features enabled.
A virtual NIC, or in short a VNIC, is a pseudo network interface created over an existing physical NIC. A phisical NIC can have more than one VNICs on it. Each VNICs created will have a separate MAC address. It is possible to make use of Crossbow's resource management to control bandwidth through VNICs.
In OpenSolaris with Crossbow, it is possible to create virtual NICs using Data Link Administration command dladm. To create a virtual NIC over an existing physical NIC, e1000g0, execute
# dladm create-vnic -t -l e1000g0 vnic1
We passed -t to dladm to indicate that the VNIC is to be made temporary meaning that the VNIC is available until we either reboot the system or delete it through dladm. To create persistent VNICs, remove -t from the above.
The option -l e1000g0 indicate that the VNIC is to be created over physical interface e1000g0. The name of newly created VNIC will be vnic1. This was passed as last argument to dladm.
To delete an VNIC, we again use dladm command.
# dladm delete-vnic vnic1
To make use of VNICs created through dladm, they need to be plumbed and assigned a valid IP address. In short, VNICs are similar to any physical NICs once they are created.
# ifconfig vnic1 plumb
# ifconfig vnic1 1.1.1.1 up
# ifconfig vnic1 down
# ifconfig vnic1 unplumb
While using any operating system, at any time, there may be a need to know the number of active processes and threads. In Microsoft Windows operating systems, it is possible through different GUI-based tools like Windows Built-in Task Manager, SysInternals Process Explorer etc. But in Unix, Linux or any of the Unix variant operating systems, we normally look for commands to get things done.
The below commands have been tested in OpenSolaris so far. They are expected to work on Linux and other Unix variant operating systems as well.
For example, to find the number of iperf processes,
# ps -ef | grep iperf | grep -v "grep" | wc -l
If you know how this works, you can then skip this paragraph. The first command ps is the key command which gets us all running processes at that time. The output of ps is then piped to grep. The grep command is used to search for lines containing iperf (the process we are interested in). Since grep will also be listed as a process with iperf word in the same line, we need to get rid of that entry. Otherwise, our list will have one extra entry which we are not interested in. So, we have second grep. Here we remove all lines containing word grep in the lines from first grep. The last command wc (word count) is used to get count of lines which is nothing but the number of running iperf processes.
Similarly to find the number of iperf threads,
# ps -eLf | grep iperf | grep -v "grep" | wc -l
Here the only change is in the arguments passed to ps command. The argument -L hints ps to look for only light weight processes (also called threads).
There is one more way of finding the number of threads. In this method, we make use of mdb, the modular debugger.
To find the number of iperf threads using this method, execute
# echo ::threadlist | mdb -k | grep iperf | wc -l
Here passing ::threadlist to mdb shows a list of threads running in the system. In that list, grep for iperf and find the count of lines.
For browsers to be able to display webpages, the underlying network stack has to resolve web address to IP address. This name resolution is performed by different ways. One of them in by using DNS (Domain Name System).
For example, to open the home page of this site, we request web browser to open the page at www.osfaqs.com. The naming system first resolves www.osfaqs.com to its corresponding IP address using DNS. In a simple way, you can find the IP address for any valid web site using ping. For example, run "ping www.osfaqs.com". Ping program works based on ICMP protocol for which name resolution is required before continuing to send request to www.osfaqs.com. You can see the IP address being displayed by the ping program before sending request to the server hosting www.osfaqs.com.
In Solaris, naming servers can be specified through a configuration file resolv.conf. This file has a standard location /etc/resolv.conf. To add 208.67.222.222 as one of the naming servers, add an entry in /etc/resolv.conf like this
nameserver 208.67.222.222
If you have multiple naming servers, add them in the same way in separate lines.
Solaris also has a file, nsswitch.conf, which controls how a process looks up various databases. Each of these databases comes from a source like hosts, groups, users, etc. This file specifies the order in which the naming system has to look up the sources. For the naming system to be able to resolve domain names to IP addresses, make sure that the line with hosts also has dns; i.e., there should be a line in /etc/nsswitch.conf like this
hosts: files dns
If naming fails even after setting up naming system in /etc/resolv.conf and /etc/nsswitch.conf, look at routing table. Default route may be set to a different route.
|
Blog Directory ID: 2221
Blog URL: http://www.kernelfaq.com
Report Blog: Report Blog Listing – This is a free listing which requires a link back!
Google Pagerank: 0
Blog Description: Technical info on Unix, Linux, Apple Mac OS X, Solaris and other Unix variant operating systems, Kernels, Kernel Programming, Device Drivers, etc.
Blog Tags: Unix - Linux - Kernel - Network - FreeBSD - Mac - Solaris 
Blog Category: Computer Blogs
Blog Owner: Gireesh
Blog Added: April 12, 2008 09:43:08 AM
Audience Rating: General Audience
Blog Platform Not Selected
Blog Country: 
United States
My Yahoo! 
Refer Blog Listing - 
Print Listing
Total Visits: 18
Blog Rating: 0.00
Rate Blog: 
