From Fedora Project Wiki
No edit summary
m (Removed some stray sample output.)
(24 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Network Team driver
= Network Team driver =


== Summary ==
== Summary ==
Network Team driver allows multiple NICs to be teamed together and act like a single one.  
<!-- A sentence or two summarizing what this feature is and what it will do.  This information is used for the overall feature summary page for each release. -->
Network Team driver allows multiple network interfaces to be teamed together and act like a single one.


== Owner ==
== Owner ==
Line 11: Line 12:
== Current status ==
== Current status ==
* Targeted release: Fedora 18
* Targeted release: Fedora 18
* Last updated: 2012-07-18
* Last updated: 2012-10-04
* Percentage of completion: 90%
* Percentage of completion: 100%


<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->
<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->


== Detailed Description ==
== Detailed Description ==
The purpose of the Team driver is to provide a mechanism to team multiple NICs (ports) into one logical one (teamdev) at L2 layer. The process is called "channel bonding", "Ethernet bonding", "channel teaming", "link aggregation", etc. This is already implemented in the Linux kernel by the bonding driver. The main thing to realize is that the Team driver project is not trying to replicate or mimic the bonding driver. What it does is it resolve the same problem using a different approach. Therefore, for example, the way Team is configured differs dramatically from the way bonding is. Team has many advantages over Bonding. It's modular, userspace driven, fast.
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
 
The purpose of the Team driver is to provide a mechanism to team multiple NICs (ports) into one logical one (teamdev) at L2 layer. The process is called "channel bonding", "Ethernet bonding", "channel teaming", "link aggregation", etc. This is already implemented in the Linux kernel by the bonding driver.
 
One thing to note is that Team driver project does try to provide the similar functionality as the bonding driver, however architecturally it is quite different from bonding driver. Team driver is modular, userspace driven, very lean and efficient, and it does have some distinct advantages over bonding. The way Team is configured differs dramatically from the way bonding is.
 
This feature consists of two parts:
* kernel module (modules). They are already part of Fedora 18 kernel package.
* userspace library (libteam package) and daemon (teamd package).
 
Although there is support for Team driver in initscripts, the plan is to integrate Team devices handling into Network Manager as well, probably for Fedora 19.


== Benefit to Fedora ==
== Benefit to Fedora ==
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->


This will bring possibility to run userspace driven NIC teaming. There are some features not supported by bonding are supported by Team driver, for example:
Team Driver provides userspace driven NIC Teaming. In addition to that there are some new features in Team Driver that are not available in bonding. For example:
* load balancing for LACP
* load balancing for LACP
* separate per-port link monitoring setup
* separate per-port link monitoring setup
* port priorities and stickiness
* port priorities and stickiness
* IPv6 Neighbor Solicitation/Neighbor Advertisement link monitoring  
* IPv6 Neighbor Solicitation/Neighbor Advertisement link monitoring


== Scope ==
== Scope ==
<!-- What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
Team driver is quite isolated, and does not impact other areas. It does not touch any existing things.


== How To Test ==
== How To Test ==
Line 45: Line 58:
3. What are the expected results of those actions?
3. What are the expected results of those actions?
-->
-->
Install "teamd" package first. You need two network interfaces for this basic test. In case their names are not "eth1" and "eth2", please adjust the config file.
<pre>
test2:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 52:54:00:1a:db:bb brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 52:54:00:99:bb:27 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 52:54:00:b7:cc:fb brd ff:ff:ff:ff:ff:ff
test2:~# cat /usr/share/doc/teamd-0.1/example_configs/activebackup_ethtool_1.conf
{
        "device":      "team0",
        "runner":      {"name": "activebackup"},
        "link_watch":  {"name": "ethtool"},
        "ports":        {
                "eth1": {
                        "prio": -10,
                        "sticky": true
                },
                "eth2": {
                        "prio": 100
                }
        }
}
test2:~# teamd -f /usr/share/doc/teamd-0.1/example_configs/activebackup_ethtool_1.conf -d
test2:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 52:54:00:1a:db:bb brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master team0 state UP mode DEFAULT qlen 1000
    link/ether ea:8e:85:d3:95:5d brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master team0 state UP mode DEFAULT qlen 1000
    link/ether 52:54:00:b7:cc:fb brd ff:ff:ff:ff:ff:ff
5: team0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
    link/ether ea:8e:85:d3:95:5d brd ff:ff:ff:ff:ff:ff
test2:~# ip addr add 192.168.23.2/24 dev team0
test2:~# ip link set team0 up
test2:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 52:54:00:1a:db:bb brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master team0 state UP mode DEFAULT qlen 1000
    link/ether ea:8e:85:d3:95:5d brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master team0 state UP mode DEFAULT qlen 1000
    link/ether 52:54:00:b7:cc:fb brd ff:ff:ff:ff:ff:ff
5: team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
    link/ether ea:8e:85:d3:95:5d brd ff:ff:ff:ff:ff:ff
test2:~# teamd -f /usr/share/doc/teamd-0.1/example_configs/activebackup_ethtool_1.conf -k
test2:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 52:54:00:1a:db:bb brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000
    link/ether 52:54:00:99:bb:27 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000
    link/ether 52:54:00:b7:cc:fb brd ff:ff:ff:ff:ff:ff
</pre>


== User Experience ==
== User Experience ==
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
User will not experience any difference comparing to existing state. Only there is new possibility to create Team devices.


== Dependencies ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
No dependencies.


== Contingency Plan ==
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
Currently, the feature is fully functional. Only some little things and tweaks are going to go in for Fedora 18.


== Documentation ==
== Documentation ==
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
*
* https://fedorahosted.org/libteam/
* https://fedorahosted.org/libteam/wiki/InfrastructureSpecification


== Release Notes ==
== Release Notes ==
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
*
Fedora 18 includes Team Driver which provides a possibility to team multiple network interfaces together so they act like a single network interface. This extends teaming possibilities provided by existing bonding driver. It also provides userspace driven, modular alternative to bonding driver.


== Comments and Discussion ==
== Comments and Discussion ==
* See [[Talk:Features/Your_Feature_Name]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
* See [[Talk:Features/TeamDriver]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->




[[Category:FeaturePageIncomplete]]
[[Category:FeatureAcceptedF18]]
<!-- When your feature page is completed and ready for review -->
<!-- When your feature page is completed and ready for review -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Revision as of 17:57, 3 December 2012

Network Team driver

Summary

Network Team driver allows multiple network interfaces to be teamed together and act like a single one.

Owner

Current status

  • Targeted release: Fedora 18
  • Last updated: 2012-10-04
  • Percentage of completion: 100%


Detailed Description

The purpose of the Team driver is to provide a mechanism to team multiple NICs (ports) into one logical one (teamdev) at L2 layer. The process is called "channel bonding", "Ethernet bonding", "channel teaming", "link aggregation", etc. This is already implemented in the Linux kernel by the bonding driver.

One thing to note is that Team driver project does try to provide the similar functionality as the bonding driver, however architecturally it is quite different from bonding driver. Team driver is modular, userspace driven, very lean and efficient, and it does have some distinct advantages over bonding. The way Team is configured differs dramatically from the way bonding is.

This feature consists of two parts:

  • kernel module (modules). They are already part of Fedora 18 kernel package.
  • userspace library (libteam package) and daemon (teamd package).

Although there is support for Team driver in initscripts, the plan is to integrate Team devices handling into Network Manager as well, probably for Fedora 19.

Benefit to Fedora

Team Driver provides userspace driven NIC Teaming. In addition to that there are some new features in Team Driver that are not available in bonding. For example:

  • load balancing for LACP
  • separate per-port link monitoring setup
  • port priorities and stickiness
  • IPv6 Neighbor Solicitation/Neighbor Advertisement link monitoring

Scope

Team driver is quite isolated, and does not impact other areas. It does not touch any existing things.

How To Test

Install "teamd" package first. You need two network interfaces for this basic test. In case their names are not "eth1" and "eth2", please adjust the config file. 

test2:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 52:54:00:1a:db:bb brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 52:54:00:99:bb:27 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 52:54:00:b7:cc:fb brd ff:ff:ff:ff:ff:ff
test2:~# cat /usr/share/doc/teamd-0.1/example_configs/activebackup_ethtool_1.conf 
{
        "device":       "team0",
        "runner":       {"name": "activebackup"},
        "link_watch":   {"name": "ethtool"},
        "ports":        {
                "eth1": {
                        "prio": -10,
                        "sticky": true
                },
                "eth2": {
                        "prio": 100
                }
        }
}
test2:~# teamd -f /usr/share/doc/teamd-0.1/example_configs/activebackup_ethtool_1.conf -d
test2:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 52:54:00:1a:db:bb brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master team0 state UP mode DEFAULT qlen 1000
    link/ether ea:8e:85:d3:95:5d brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master team0 state UP mode DEFAULT qlen 1000
    link/ether 52:54:00:b7:cc:fb brd ff:ff:ff:ff:ff:ff
5: team0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT 
    link/ether ea:8e:85:d3:95:5d brd ff:ff:ff:ff:ff:ff
test2:~# ip addr add 192.168.23.2/24 dev team0
test2:~# ip link set team0 up
test2:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 52:54:00:1a:db:bb brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master team0 state UP mode DEFAULT qlen 1000
    link/ether ea:8e:85:d3:95:5d brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master team0 state UP mode DEFAULT qlen 1000
    link/ether 52:54:00:b7:cc:fb brd ff:ff:ff:ff:ff:ff
5: team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether ea:8e:85:d3:95:5d brd ff:ff:ff:ff:ff:ff
test2:~# teamd -f /usr/share/doc/teamd-0.1/example_configs/activebackup_ethtool_1.conf -k
test2:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 52:54:00:1a:db:bb brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000
    link/ether 52:54:00:99:bb:27 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000
    link/ether 52:54:00:b7:cc:fb brd ff:ff:ff:ff:ff:ff

User Experience

User will not experience any difference comparing to existing state. Only there is new possibility to create Team devices.

Dependencies

No dependencies.

Contingency Plan

Currently, the feature is fully functional. Only some little things and tweaks are going to go in for Fedora 18.

Documentation

Release Notes

Fedora 18 includes Team Driver which provides a possibility to team multiple network interfaces together so they act like a single network interface. This extends teaming possibilities provided by existing bonding driver. It also provides userspace driven, modular alternative to bonding driver.

Comments and Discussion

Retrieved from "https://fedoraproject.org/w/index.php?title=Features/Team&oldid=313446"