梅花跟桃花长得差不多。它们的颜色一样，形状也差不多。但是，气味、花瓣的层次数，花蕊的浓度不一样。桃花的浓一点，梅花的淡一点。所以，它们还是有区别的。

梅花已经开了不少了。有的花瓣儿已经全部展开；有的只展开了两三片花瓣；有的还是花骨朵儿，很像害羞的小姑娘。梅花花瓣的层数不一。有的花瓣层数有两层；有的有三层；有的有四层。不过，花瓣是三层的居多，就像一条粉红色的，美丽的公主裙。花瓣儿的后面，有一种深粉色的花瓣儿，可真像公主裙的装饰品。 

走近梅花，就可以闻到一阵又一阵的清香扑鼻而来。真是“遥知不是雪，为有暗香来”啊！ 

我的植物朋友——梅花，我可真喜欢你那“凌寒独自开”的精神啊！

传统方式从零开始建设一个数据中心, 网络从建设到交付的过程像是“开荒”，繁琐的网络设备命令依赖工程师人工编写，费时又费力，并且交期与质量均无法得到保障。

为此我们设计了一款数据中心网络建设系统 —— Big Bang。将数据中心网络开局这一任务切分为 “架构规划” - “资源分配” - “配置生成及下发“ 三个步骤。每一步之间耦合松散而内部又高度内聚，实现低成本适配不同版本架构迭代、不同规模机房的小时级快速部署目标。

Big Bang 上线后支持了优刻得自建的乌兰察布大规模数据中心网络建设开局。至今已完成海内外多个机房的快速、高质量交付。

The Big Bang Theory : 宇宙是由一个致密炽热的奇点于一次大爆炸后膨胀形成的。

1. 上一代建设系统的不足

在 Big Bang 之前 UCloud 物理网络团队已经在运营一代数据中心建设系统, 随着业务和架构的演进, 上一代系统的一些缺点逐渐暴露出来 :

对多平面的 Fabric 数据中心网络支持不够灵活； 架构规则描述不灵活, 网络设计版本迭代后，需要再次投入大量研发人力适配，且存在需要研发理解网络业务设计的强耦合问题； 原子命令库方式组织的配置模板不直观，人工难以预测其生成的配置，导致维护成本过高，且修改后无测试，容易出错； 在建设海外机房时，由于网络延迟过高，基于编排器的配置下发方式出现了失败率快速攀升的问题。

通过上述问题的分析不难得出推论, 我们需要这样一款建设系统 :

灵活适配多版本、多形态、多平面的数据中心网络； 网络架构迭代不应需研发同学介入； 可以直观的修改配置模板，修改后可以自动化的低成本的进行测试； 低网络依赖，弱网条件下依然能好用。

1. Big Bang 设计概要

2.1 人肉运维之痛

在谈设计之前, 我们先来谈一下人工建设一个数据中心会遇到哪些挑战 ?

考察一个简单的两级 CLOS 架构 : 4 个 Spine, 32 个 Leaf 共 36 台设备构成一个业务专区, 这在 UCloud 数据中心中是很常见的 POD 规模。

建设这样一个网络, 首先需要给出设备接线表交由现场的同学进行布线。这张接线表要表达 “spine01.p1 接 leaf01.p49, 使用 QSFP28 100G 线缆” 这样的信息. 对于这个 POD 便产生了 4 * 32 = 128 个互联关系。

给出布线规则后, 我们再来考虑 IP 分配的问题。

图中每一条线均需要一对互联地址, 除此之外设备还需要分配管理地址、业务地址等。一个 POD 便需要 128 个互联网段、32 个业务网段、几十个管理地址。这些地址都需要工程师到 IP 管理系统中占用, 并与设备 ( 互联关系 ) 一一对应.

可以看到, 在 CLOS 架构下进行的互联计算、资源分配工作非常繁复, 并且数量会随着网元数量、接口数量的增加而急剧增加。

除此之外，还有一些要求会使这些挑战变得更加复杂：部分角色指定接线规则，如何分配端口？跨机房设备的线缆 / 模块如何选取对应物料？

Image 图1:数据中心网络示例

接下来考察实际的配置。

有些配置是所有角色共有的, 如生成树配置、AAA 配置等. 而有些配置又会根据设备角色的不同而有所区分, 如 DSCP 标记、三层接口等。

当引入了多设备厂商, 情况会变得更复杂：

接口名是 100GE 还是 Hundred Gigabit Ethernet ? slot / interface / index 是从 0 开始还是 1 开始 ? 去使能某个功能的关键字是用 undo 还是 no ?

建设团队的工程师会维护多角色、多厂商配置模版文件, 一般以 Excel / 文本文件的形式呈现。对某一特定设备开局时需要跳转多个文件, 进行不断的 copy / paste 来完成一个设备的配置编写。

如此, 完成一个几百台网络设备的数据中心网络开局, 可能需要 1 - 2 个人 / 周投入, 这显然不能满足业务快速扩展的需求。

2.2 Automate or die

不难发现, 整个开局过程中有大量繁复的计算和操作工作：

繁杂的接线分配、IP 地址分配工作 重复的配置文件的翻译工作 服务于架构角色的配置区分 人工进行这些繁复的工作，效率很低且容易出错, 而这正是程序擅长的。

2.3 系统分层设计

回到之前的问题 : 建设一个新的数据中心网络总共分几步 ?对整个建设过程进行考察和思索, 将过程抽象为如下三个过程, 对应大爆炸系统的三个组件 :

1. 规划 - 架构规划库

类似《GB 50017-2017 钢结构设计标准》, 这是一个抽象的实施规范，如 UCloud 可支撑单可用区 320,000 服务器的数据中心网络系统设计。

1. 分配 - 资源分配器

类似有建设需求后, 拿到了一块地开始计算需要哪些物料, 分配各项资源，并抽象生成连接图。

1. 建设 - 配置生成及刷入

类似拿着图纸进行施工,直到把楼盖好交付，生成出所有设备的配置文件, 刷入设备中。

这样做的好处 :

耦合松散, 每一个模块只完成一个或几个功能, 彼此通过结构化的信息进行流转, 彼此屏蔽了内部细节； 当其中的一小部分发生变化时，只需要修改发生变化的部分。如机房现场需要更换接线表的格式，只需要发布一个新版的资源分配器。上下游不需要感知资源分配器发生变化。

1. 架构规划库

如果需要程序来计算需要的设备、互联图、IP 段等信息，首先需要考虑的是:“应该如何抽象的表达一个架构？”

先退一步，我们应该如何描述一个机房的拓扑？

这要求我们描述一个图结构 :

点：有哪些设备 线：设备物理上是怎么互联的 点及线的属性：IP

基于此，我们再进行一次抽象，把具体每个设备的抽象为角色，把具体的 IP 变为可分配的 IP 段。然后得到我们需要描述的内容：

有哪些角色（设备） 有哪些 IP 段可供分配 角色之间是如何互联的 角色本身（如 loopback 口）要使用哪些 IP 段 互联要使用哪些 IP 段

因为：

一个较小的 IP 段肯定是由一个更大的 IP 段拆分而来，分出来的子 IP 段有关联。 我们需要多个角色通力合作才能连通网络，角色之间有关联。

基于上面这些假设，我们可以抽象出两棵树————设备树和 IP 段树，这二棵树各自扇出（fan out） ，最后在叶子节点上建立关联。

Image 图二 : 设备树与 IP 树

至此，我们已经表达了：

有哪些角色 有哪些 IP 段 角色本身（如 loopback 口）要使用哪些 IP 段 这三个信息点。

还剩下：

角色之间是如何互联的 角色之间的互联要使用哪个 IP 段 这两个信息点。

Image 图三 : 多平面网络

在数据中心网络演进到多平面的 Fabric 网络后，互联关系的种类呈现指数级上升。如何准确、易理解、低成本、低耦合的描述这些互联关系成为了摆在我们面前的巨大难题。

我们想到的第一个方案：预定义套餐，即预先定义出所有可选的互联方案。将这些逻辑固化到代码中去。如：笛卡尔积式互联，间隔互联，交叉互联等等。

我们迅速否决了这个方案，因为：

极高的理解成本：工程师很难从名字和描述等处获得足够的信息，需要配套大量的文档，相当于回退到了文档描述的时代。 极高的研发成本：每当新加一种互联类型，都需要大量研发资源投入适配，也需要研发同学深入的理解每种互联方案，再加上每种互联方案有大量的可调参数，如间隔步长等。 严重的跨模块耦合：当架构规划信息在“架构规划库” 和 “资源分配器” 之间传递时，需要为每个互联方案设计一种数据结构，相当于要求“架构规划库”和“资源分配器”都需要完全理解每一种互联方案。

我们从 tcpdump 工具中得到启发，当要描述特定领域内的复杂逻辑的时，可以尝试设计一种 领域特定语言（DSL）来解决。我们设计了一种描述互联的 DSL ---- UCLOUD DC CONNECT LANG 。语言短小精悍，说明文档约一页，描述一种互联关系只需要 10 个左右的字符，实践中，新员工只需要大约 1 天就可以理解这个语言，这个方案完全解决了预定义套餐产生的问题：

极低的理解和维护成本：只要理解了这个语言，就理解了所有的互联方案。 极低的研发成本：只需要实现了这个语言的逻辑，就可以覆盖所有的互联方案。所以，“资源分配器”只需要实现一次语言逻辑，终身免维护。 极低的耦合：架构规划库直接向资源分配器按 string 传递 DSL 原文即可，不再需要多种数据结构。

回到之前的“两棵树”上，给角色之间补充上互联信息和互联需要使用哪些 IP 地址段的信息。

Image 图四 : 图信息

至此，我们通过两棵树和一个三角形已经完整表达之前提到的五个信息点：

有哪些角色（设备） 有哪些 IP 段可供分配 角色之间是如何互联的 角色本身（如 loopback 口）要使用哪些 IP 段 角色之间的互联要使用哪些 IP 段

当然实际上还要稍微复杂一些，诸如 IP 段上会有业务标签，角色上会有端口分配规则等等。但这些本质上只是各个叶子节点的其他属性，只需要简单的加到叶子节点上即可。

1. 资源分配器

架构规划库的信息流转到资源分配器后，资源分配器就要来分配资源。

那么第一个问题就是：它需要分配什么资源？

我们的答案：分配那些需要在全网资源池中获取的，与具体架构及具体路由协议无关的资源。

这样做的主要原因是我们希望资源分配器与网络架构设计完全解耦，否则会导致：

要么，需要持续投入研发人力跟踪实现数据中心内的动态路由协议从 OSPF 到 BGP 再到分布式数据库所需的各种资源分配逻辑。 （开发工具的同学不见得可以低成本、快速地理解网络设计上的细节。）

又或者，系统能力限制网络架构设计，若系统只支持 BGP AS 号分配，那架构设计只能使用 BGP 协议 那这些协议相关的逻辑资源怎么办？我们借鉴了“变量作用域”的概念。

资源分配器为每个角色分配一组局部（包括但不限于数据中心内、设备组内等）唯一的 ID 值，我们称之为 ID 组。在下一步配置生成中再根据 ID 组计算出这些资源。

这样的设计保证了：

局部唯一性 可计算性，互联两侧角色可以根据同样的参数和算法得到同样的逻辑资源，使得路由协议能正确协商

确定了需要分配的资源后，资源分配器根据架构规划库给出的架构信息，人工给出的规模信息，从 CMDB、IPAM 等资源池中获取设备、IP等资源，并计算出一个描述了整个数据中心拓扑的数据文件，称为连接图。

连接图中的信息主要包括两类：

1）设备信息（点）

上文提到的 ID 组 管理 IP … 2）互联信息（线）

两侧设备 两侧 IP 两侧端口 …

连接图信息将会继续传递给配置生成器。

1. 配置生成器

至此, 我们已经有了基于架构规划库给出的规则分配好的资源(连接图信息), 这些信息如何转化成交换机可以理解的配置 ? 这就是配置生成器做的工作。

5.1 配置的生成

实际写到交换机上的命令可以分为三大类 :

全局一致的配置, 如 AAA 配置、安全策略配置等 与角色自身属性有关的配置 角色之间的互联配置，如 BGP peer address、BGP AS 、三层口 IP 等

一个配置例子：

hostname LAS.xxxxxx

interface HundredGigabitEthernet 0/1

no switchport

description To_LCS

ip address 10.68.176.53 255.255.255.254

可以发现，配置实际上是由一些固定的模板及变量组合而成的。而这些变量肯定来自于资源分配器的连接图中，点自身的属性，或者线的属性，又或者是与点连接的另外的点的属性。所以，只需要写好模板，再遍历连接图，我们就可以很轻松地得到整个机房所有设备的配置。

上文的配置在模版中的表现形式 ：

hostname {{ device_name }}

interface {{ pair["local_interface_name"] }}

no switchport

description {{ conn["peer_device"]["device_name"] }}

ip address {{ ip["ip"] }} {{ ip["mask"] }}

我们使用 jinja2 来帮助渲染模板，jinja2 支持模板的继承和组合，可以避免在每个角色的模板中重复写很多通用配置。同时，jinja2 模板非常的直观，简洁，所见即所得。替换为 jinja2 后大幅降低了配置命令的错误率。

我们还通过 git 管理模板，并围绕 git 构建了模板编写及修改工作流，引入了自动化测试机制，保证了对模板的修改有解释，有review，且经过测试，基本消除模板语法错误导致的沟通成本。

5.2 临门一脚

通过前述的资源分配等步骤, 至此我们已经完成了所有设备的配置生成工作, IDC 现场的同学也按系统给出的信息将设备完成上架、接线、开电。

至此我们只剩整个数据中心物理网络建设的“临门一脚”, 这些配置文件(以交换机 sn 命名的 txt 文件)如何下发到交换机上, 作为 startup config 启动并运行 ?

这里我们使用目前各主流厂商均支持的“零配置启动”功能 :

定义

ZTP（Zero Touch Provisioning）是指新出厂或空配置设备上电启动时采用的一种自动加载版本文件（包括系统软件、配置文件、License文件、补丁文件、自定义文件）的功能。

目的

在部署网络设备时，设备硬件安装完成后，需要管理员到安装现场对设备进行软件调试。当设备数量较多、分布较广时，管理员需要在每一台设备上进行手工配置，既影响了部署的效率，又需要较高的人力成本。

设备运行ZTP功能，可以从U盘或文件服务器获取版本文件并自动加载，实现设备的免现场配置、部署，从而降低人力成本，提升部署效率。

实际运行中, 我们会在新建的数据中心部署一台 PC (一个致密炽热的奇点)， 这台 PC 上运行了 DHCP、TFTP 服务以及存放了该数据中心所有设备的配置文件。

类比服务器的 PXE 装机过程, 我们利用 DHCP 服务器下发 TFTP Server 和 Bootfile, 交换机会自动执行该脚本, 而后从 TFTP 服务器下载其所需的配置文件。

在这里我们之前忽略了一个问题 : 同一数据中心内采购多厂商的设备, 如何解决生成 / 下发特定厂商配置文件的问题?

答案是不解决, 或者说不在前期考虑这个问题。

配置生成器不感知, 也不在乎上架使用的具体设备型号, 而是直接生成出所有可能厂商的配置文件. 例如某一特定角色共有 A、B、C 三个厂商的三份配置文件。

在交换机发送 DHCP Discover 报文时携带其厂牌信息, 如此奇点只要根据其厂牌返回不同的 TFTP 路径即可完成配置的下发。

通过以上几个步骤, 在现场完成上架、布线等工作后, 我们可以在小时级别将整个数据中心内的配置拉起, 完成开局。

5.3 one more thing

完成配置下发并不是结束, 我们还赋予了“奇点”一些其他功能 : 因为有了整网的连接图, 我们可以在最终交付给业务之前做一些检查, 确认我们的数据中心网络是可靠的。

通过对所有设备的连通性检查, 确认设备均已正确上线, 管理面均可达。 通过比对交换机的 startup config 与 running config , 确认全部配置下发正确。 通过 ZTP 功能, 我们可以指定上线设备的版本信息, 由系统自动升级为 DCN 指定的操作系统版本. 通过比对连接图中的 peer 关系与读取设备的 LLDP 信息, 确认全部接线正确。（在我们实际运行中此处常会检出一些错误 : 人工依然是不可靠的, 而工具可以检查和避免这种错误。） 6. 总结

从零建设一个可容纳万台服务器的数据中心网络需要多久 ?

答案是：几小时。

比起“交付时间压缩了多少”, 更大的价值更在于我们将目光聚焦在工程师擅长的地方, 将其从繁琐的表格、分配工作中解放, 更多精力去理解用户的工作流和关注点, 打造真正能输出业务价值的网络基础设施。

UCloud 物理网络团队坚信“连接的力量”, 为各公有云产品、为客户提供更稳定、更高效的网络服务。

Support Youth HIV/AIDS awareness with this NFT drop. 100% of proceeds go to the cause!

Mint now

Dear Bankless Nation,

Last September we published the Essential Guide to Arbitrum—one of Ethereum’s leading scaling solutions that had just launched on mainnet.

It was new and exciting, but at the time, there wasn’t really much to do. You could bridge over and use some of the leading DEXs like Uniswap, Balancer, and Sushi. That was it.

It was early.

Fast forward to today, and the ecosystem has grown rapidly. There’s now over $6B in value locked across all Layer 2s, and Arbitrum represents over $4B of it—over 60% market share!

The network is also steadily approaching 1M unique addresses (still early!!)

There’s more liquidity, more infrastructure, and more opportunities. Less than 9 months later and there’s now a vibrant ecosystem of applications on Arbitrum.

Low fees. More opportunities.

So today we’re revisiting the best opportunities on Arbitrum.

I wonder—could this make you eligible for an airdrop someday? 🤔

Let’s go.

- RSA

*P.S. Don’t miss our Alpha Report! We dropped ***🔥 **token ratings for BAL, SUSHI, MKR, TRIBE, and FXS. Premium subs can tap in now. Need access? Go premium.

🙏** Sponsor: ***Polygon Studios—Fostering culture across Gaming, NFTs, and the Metaverse✨*

🎙️ NEW LAYER ZERO

Listen to podcast episode | Apple | Spotify | YouTube | RSS Feed

Tactic Tuesday

Bankless Writer: William M. Peaster, Bankless contributor and Metaversal writer

Arbitrum One is currently the most popular layer 2 scaling solution for Ethereum, offering a range of L2 adventures and the best liquidity - at least for now.

This Bankless tactic covers a handful of the hottest Arbitrum opportunities you can consider trying today!

• Goal: Explore cool Arbitrum projects

• Skill: Intermediate

• Effort: 1 hour

• ROI: Up to 60% APR at current rates

Riding the rise of Arbitrum in style

The state of Arbitrum

Per L2BEAT, there’s currently $6.7B worth of total value locked (TVL) across all of Ethereum’s most advanced scaling solutions. Accordingly, Arbitrum’s nearly $4B TVL at the moment means the scaling solution currently accounts for over 50% of the market share. 

While the size of Arbitrum’s user base is still dwarfed by the size of Ethereum’s, the Nansen Arbitrum dashboard indicates that the upstart L2 hosted an impressive ~150k unique active addresses over the last month and hosted nearly 50M addresses since its inception. For comparison, the Optimism L2 hosted ~40k addresses on the month and over 24M addresses to date. 

Tap into Nansen for more elite analytics

With regard to the L2’s roadmap, the creators of the scaling solution recently announced AnyTrust Chains, which will operate along Arbitrum and offer ultra low-cost transactions, and the nearing of Arbitrum Nitro, which will optimize the L2’s network and drastically lower its transaction fees even further. 

Arbitrum Starter Pack

*Here are some resources you can use to help you more easily navigate the Arbitrum ecosystem. *

👉 Get Bankless’s Essential Guide to Arbitrum here 👈

**Essential Tools: **

• Arbiscan: Block explorer for analyzing Arbitrum transactions.

• Arbitrum Bridge: Official bridge for ETH and ERC20 token transfers between Arbitrum and Ethereum. You can also use Hop Protocol as a faster bridge!

• Arbitrum One Portal: Application scanner to keep up to date with new DeFi and NFT projects. 

• Chainlist: Tool to add the Arbitrum network to your MetaMask wallet.

5 🔥 opportunities on Arbitrum right now

*Below, I’ve curated a handful of what I consider to be the most compelling opportunities for adventurers on Arbitrum at the moment. *

1. Get exposure to blue-chip NFTs via NFTI

What you need to know

• In Feb. 2022, Scalara (previously Pulse Inc.) revealed the methodology for the Scalara NFT Index, or NFTI. Within a matter of days, someone used the methodology to launch the index through the index-tracking protocol Kuiper.

• NFTI offers potential returns on the floor price performances of top NFT collections. Specifically, the index serves as an automated, weighted basket of xTokens from NFT liquidity protocol NFTX. In addition, NFTX’s inventory staking program provides NFTI holders with additional yields unrelated to price performances. 

• Initially, NFTI tracks the CryptoPunks, CrypToadz, Chromie Squiggles, Cool Cats, Doodles, Meebits, and World of Women collections. Investors can now use a single ERC20 to get exposure to these blue-chip NFT projects on any budget. In comparison, investing in these collections by simultaneously paying their full floor prices would amount to hundreds of ETH right now. 

• Previously, the vast majority of blue-chip NFT liquidity has been siloed on Ethereum, so NFTI’s arrival on Arbitrum makes it possible to enjoy fast and inexpensive L2 transactions around some of the biggest NFT projects for the first time ever.

How to access NFTI

1. Top up your Arbitrum wallet with ETH for gas if you haven’t already.

2. Then head to the ETH-NFTI pool on Uniswap V3’s Arbitrum deployment. 

3. Use the “Swap” UI to input how much NFTI you’d like to trade for and complete the transaction with your wallet. Beware of high slippage!

4. That’s it! You can hodl NFTI while you’re long and want exposure to its collections, or you can sell through the same Uniswap V3 pool whenever you’re ready to take your money off the table.

2. Invest with Yearn’s L2 Curve Tricrypto vault

What you need to know

• In Feb. 2022, the team behind the leading DeFi yield aggregator Yearn announced the protocol’s deployment to Arbitrum. Notably, this deployment marked the first L2 that Yearn supported. 

• The Yearn team decided to trial Arbitrum first because of the L2’s low costs, its confidence-inspiring TVL stats, and its compatibility with direct deposits/withdrawals via major crypto exchanges like Binance and FTX. 

• Yearn’s inaugural offering on Arbitrum is a Curve Tricrypto vault. Curve’s Tricrypto pool contains WBTC, WETH, and USDT, and depositors to this pool can take their liquidity provider (LP) tokens to Yearn’s vault to boost their earnings through an automated, Curve-centric DeFi strategy.

How to access the Curve’s L2 Tricrypto vault

1. Make a deposit to Curve’s Tricrypto pool on Arbitrum.

2. With your ensuing LP tokens, head back to the Curve Tricrypto vault page. 

3. Use the “Deposit” UI to input how many crvTricrypto LP tokens you want to supply.

4. Complete an approval and then a deposit transaction, and you’re in. Right now the vault is generating ~7.4% APY.

3. Provide liquidity on Stargate Finance

What you need to know

• Stargate, an “omnichain” bridging protocol, is the first project to launch atop Layer Zero, an interoperability solution that can make it easy for disparate blockchains to directly communicate with each other. 

• Stargate currently supports a series of stablecoin pools across multiple blockchains that are compatible with the Ethereum Virtual Machine (EVM). These chains include Arbitrum, Avalanche, BSC, and beyond. 

• By adding liquidity to Stargate’s liquidity pools, users stand to earn a small cut of every transfer made through Stargate. Additionally, it’s possible to stake Stargate LP tokens to earn further rewards denominated in STG, the native token of the protocol.

How to access Stargate’s Arbitrum staking opps

1. Add some USDC or USDT to your Arbitrum wallet for LPing with. 

2. Then head to the Stargate Pool page and connect your wallet. 

3. Click on the Arbitrum USDC pool or the Arbitrum USDT pool option and make your desired deposit amount. 

4. With your new LP tokens, navigate to the Farming page and click on the staking opportunity that applies to you. Input how many LP tokens you want to stake and then complete the staking transaction.

5. Voila! That’s how to join Stargate’s Arbitrum farms. Note the USDC and USDT farms are offering ~10% APY and ~9% APY respectively at the moment.

4. Stake on GMX to earn up to 47% APR at current rates

What you need to know

• GMX is a decentralized spot and perpetual exchange presently live on Arbitrum and AVAX. At the heart of the protocol lies a multi-asset pool, through which LPs can earn revenues via market making and supporting leveraged trading. 

• The eponymously named GMX token is the protocol’s native governance and utility token. Holders can stake GMX to earn escrowed GMX (esGMX) rewards and ETH earnings from swap fees over time.

• GMX’s other central token, GLP, is the protocol’s native liquidity provider token. Simply put, GLP is an index of assets spanning the tokens that exist in GMX’s foundational multi-asset pool, and it’s possible to stake GLP to earn ETH and esGMX rewards.

How to access GMX or GLP staking

• Go to the GMX Buy page and follow the instructions to acquire your desired amount of GMX or GLP. 

• If you buy GLP, you’re already done because your GLP is automatically staked upon the purchase. You can then track your earnings or unwind your position through the GMX Earn page. Note, GLP staking is generating 47% APR (27% in ETH + 20% in esGMX) right now. 

• For GMX stakers, follow up by going to the GMX Earn page and connecting your wallet.

• Then scroll down to the GMX staking UI and slick “Stake” to complete the transaction with your wallet. Keep in mind that GMX staking is presently yielding 28% APR (11% in ETH + 17% in esGMX).

5. Earn up to 60% APR on Vesta liquidity mining

What you need to know

• Similar to Liquity, Vesta is a “zero interest” lending protocol. 

• Yet while Liquity exists on Ethereum and only supports ETH collateral, Vesta is built on Arbitrum and supports multiple collateral types like ETH, renBTC, gOHM, and GMX.

• The native dollar-pegged stablecoin of the protocol is VST, while the project’s native governance token is VSTA. In an effort to bootstrap liquidity around VSTA, the Vesta team is currently running a liquidity mining program centered on the ETH-VSTA pool on Balancer’s Arbitrum deployment. Accordingly, users can stake their LP tokens from this pool back on Vesta to earn 42% APR in VSTA rewards + 17% APR in BAL rewards right now.

How to access Vesta liquidity mining

• Supply liquidity to the VSTA-ETH pool on Balancer.

• Then go to Vesta’s Liquidity Mining page and click on the VSTA-ETH option, which will bring up the UI depicted in the image above. 

• Input how many VSTA-ETH LP tokens you want to stake, and then press “Stake” and complete the transaction with your wallet. Just keep in mind that your accrued staking rewards could be counteracted by impermanent loss in the underlying VSTA-ETH pool.

Pioneering The Frontier

The projects described above are pioneering around Arbitrum’s frontier and offer compelling opportunities for L2 adventurers to explore today.

They all come with risks, though they typify how the era of rapid and inexpensive DeFi and NFT activities is already upon us — the world’s just in the process of catching up.  

Action steps

• 🔥 Check out NFTI, Yearn, Stargate, GMX, and **Vesta **on Arbitrum!

• 👀 Also check out our previous How to get ready for L2 tokens tactic

Author Bio

William M. Peaster is a professional writer and creator of Metaversal—a new Bankless newsletter focused on the emergence of NFTs in the cryptoeconomy. He’s also recently been contributing content to Bankless, JPG, and beyond!

Subscribe to Bankless. $22 per mo. Includes archive access, Inner Circle & Badge.

🙏Thanks to our sponsor

POLYGON STUDIOS

Polygon Studios is on a mission to help build digital culture, play-to-earn gaming, NFTs, and the Metaverse ecosystem on Polygon. Some of the key projects supported by Polygon Studios include The Sandbox, Skyweaver, Big Time, Crypto Unicorns, and Decentraland—among others. Polygon Studios also helps fundraising & onboarding. Check it out here.

Stay updated on the latest amazing gaming, NFT, and metaverse projects:

👉 Join the Polygon Studios Discord

👉 Follow Polygon Studios on Twitter

Want to get featured on Bankless? Send your article to submissions@banklesshq.com

Write for Bankless

***Not financial or tax advice. *This newsletter is strictly educational and is not investment advice or a solicitation to buy or sell any assets or to make any financial decisions. This newsletter is not tax advice. Talk to your accountant. Do your own research.

Disclosure. From time-to-time I may add links in this newsletter to products I use. I may receive commission if you make a purchase through one of these links. Additionally, the Bankless writers hold crypto assets. See our investment disclosures here.

推特：https://twitter.com/HopProtocol

  网址：<https://hop.exchange/>

2、项目：Connext

  简介：EVM 链之间的另一个重要垮链平台

  推特：<https://twitter.com/ConnextNetwork>

  网址：<https://www.connext.network/>

3、项目：Element Finance

    简介：Element 是用于固定和可变收益市场的开源协议。

    推特：<https://twitter.com/element_fi>

     网址：<https://www.element.fi/>

     投资机构：A16z、Polychain、Republic等

4、项目：Eco

   简介：一个兼顾消费、汇款、储蓄和赚钱的金融属性平台

   推特：<https://twitter.com/eco>

    网址：<https://www.eco.com/>

    投资机构：Andreessen.horowitz、Founders Fund、Activant等

5、项目：Argent

   简介：最好的以太坊钱包之一，具有最佳的用户体验，并且已经与许多产品和 L2 集成

  推特：<https://twitter.com/argentHQ>

  网址：<https://www.argent.xyz/>

  投资机构：Paradigm、Index Ventures、Creandum

6、项目：Aztec

   简介：web3 的可编程隐私层

  推特：<https://twitter.com/aztecnetwork>

  网址：<https://aztec.network/>

7、项目：Foundation

  简介：一个新的创意经济的平台，NFT的交易创建平台

 推特：<https://twitter.com/foundation>

 网址：<https://foundation.app/>

8、项目：Polymarket

   简介：建立在马蹄上的一个去中心化的信息市场平台。

  推特：<https://twitter.com/PolymarketHQ>

  网址：<https://polymarket.com/>

9、项目：Superfluid

  简介：以太坊社区上的可编程资金流，处理订阅、工资、奖励和任何价值流，每秒持续结算

 推特：<https://twitter.com/Superfluid_HQ>

 网址：<https://www.superfluid.finance/home>

10、项目：ZigZag Exchange

    简介：第一个在 zkSync 上运行的具有中央订单簿的 DEX

   推特：<https://twitter.com/ZigZagExchange>

   网址：<https://trade.zigzag.exchange/>

   充钱交互

11、项目：OPYN

   简介：以太坊上构建 DeFi 原生衍生品和期权基础设施，最好的 DeFI 协议之一。

   推特：<https://twitter.com/opyn_>

   网址：<https://www.opyn.co/>

   投资机构：Paradigm领投

12、项目：Ondo Finance

    简介：Ondo 是一家提供结构化产品的去中心化投资银行，他们为那些想要租用流动性的 DAO 开发了一个解决方案。

  推特：<https://twitter.com/OndoFinance>

   网址：<https://ondo.finance/>

13、项目：ZORA

     简介：在以太坊上购买、出售和管理 NFT 的开放协议。

    推特：<https://twitter.com/ourZORA>

    网址：<https://zora.co/>

14、项目：RENFT

    简介：他们正在为 NFT 构建金融层，推出了第一个通用租赁市场，并建立了第一个无抵押贷款/借款

   推特：<https://twitter.com/renftlabs>

    网址：<https://withkoji.com/@reNFT>

15、项目：Mirror

     简介：用于共享和资助任何东西的基本 web3 工具包

    推特：<https://twitter.com/viamirror>

     网址：<https://mirror.xyz/>

16、项目：RabbitHole

    简介：通过发现和使用最新的加密应用程序来赚取加密货币的WEB3贡献者平台

   推特：<https://twitter.com/rabbithole_gg>

    网址：<https://rabbithole.gg/>

17、项目：ZED RUN

     简介：ZED 是一款基于区块链技术的可证明公平的数字赛马游戏。

    推特：<https://twitter.com/zed_run>

     网址：<https://zed.run/>

18、项目：Euler

    简介：Euler 是一种资本效率高的无许可借贷协议，可帮助用户从其加密资产中赚取利息或对冲波动的市场。

   推特：<https://twitter.com/eulerfinance>

    网址：<https://www.euler.finance/>

    投资机构：Paradigm领投

19、项目：Slingshot

     简介：Polygon、Arbitrum、Optimism 等链的Web3 交易平台

    推特：<https://twitter.com/SlingshotCrypto>

    网址：<https://slingshot.finance/>

20、项目：Morpho Labs

     简介：一个全新的Defi协议，通过点对点流动性改善您的供应和借入 APY

    推特：<https://twitter.com/MorphoLabs>

    网址：<https://www.morpho.best/>

21、项目：Yield Protocol

    简介：ETH上的固定利率借贷

   推特：<https://twitter.com/yield>

   网址：<https://yieldprotocol.com/>

   投资机构：Paradigm、Framework领投

22、项目：Pods

    简介：Pods 协议是一种去中心化的非托管期权协议，允许用户使用新的 Options AMM 进行买卖和提供流动性。

     推特：<https://twitter.com/PodsFinance>

    网址：<https://www.pods.finance/>

    投资机构：Framework领投

23、项目：Potion Labs

    简介：价格保险 的DEFI，AMM 协议 ，使加密市场更加安全，提供对买卖双方都安全且可持续的风险产品。

   推特：<https://twitter.com/PotionLabs>

   网址：<https://linktr.ee/PotionLabs>

   合作机构：polychanCapital、Pantera等

24、项目：Kwenta

     简介：SNX的杠杆期权平台

    推特：<https://twitter.com/kwenta_io>

   网址：<https://kwenta.io/>

25、项目：DeFi Saver

    简介：DeFi Saver 是用于创建、管理和跟踪您的 DeFi 头寸的一站式仪表板

    推特：<https://twitter.com/DeFiSaver>

    网址：<https://defisaver.com/>

26、项目：Set

     简介：资产管理协议，在 Set 的开源协议上构建市场领先的创新 DeFi 结构化产品

    推特：<https://twitter.com/SetProtocol>

     网址：<https://www.tokensets.com/>

27、项目：volmex.finance

    简介：以太坊、多边形和 Arbitrum 上的代币化波动率协议。

   推特：<https://twitter.com/volmexfinance>

   网址：<https://volmex.finance/>

  投资机构：CMS、三箭、D64等

28、项目：Sense Finance

     简介：固定利率的DEFI协议

    推特：<https://twitter.com/senseprotocol>

    网址：<https://sense.finance/>

    合作机构：Dragonfly Capital、BainCapital等

29、项目：zkSync

     简介：以太坊L2协议

     推特：<https://twitter.com/zksync>

     网址：<https://zksync.io/>

    投资机构：ETH foundation、A16Z、USV 等

30、项目：StarkWare

     简介：以太坊L2协议

     推特：<https://twitter.com/StarkWareLtd>

    网址：<https://starkware.co/>

    投资机构：Paradigm、Sequoia等

31、项目：Optimism

   简介：以太坊L2协议

   推特：<https://twitter.com/optimismPBC>

   网址：<https://www.optimism.io/>

   投资机构：paradigm、A16Z领投

32、项目：Arbitrum

     简介：以太坊L2协议

     推特：<https://twitter.com/arbitrum>

     网址：<https://arbitrum.io/>

    投资机构：Lightspeed、Pantera、Polychain Capital等

33、项目：Art Blocks

     简介：NFT创意平台，生成作品的独特迭代不可更改地托管在以太坊区块链上。

   推特：<https://twitter.com/artblocks_io>

    网址：<https://www.artblocks.io/>

34、项目：DeBank

     简介：领先的 DeFi 投资组合跟踪器，支持 20 条链中数量最多的 DeFi 协议

    推特：<https://twitter.com/DeBankDeFi>

     网址：<https://debank.com/>

35、项目：Zapper

     简介：web3 聚合DEX，包括NFT可投资组合

    推特：<https://twitter.com/zapper_fi>

    网址：<https://zapper.fi/zh>

36、项目：Zerion

     简介：用于 DeFi 和 NFT 能够在任何链上的任何钱包进行交换、质押、借入、借出

    推特：<https://twitter.com/zerion_io>

    网址：<https://zerion.io/>

    合作机构：Blockchain、Placeholder等

37、项目：Phantom

    简介：为 DeFi 和 NFT 打造的Solana 链上的优质钱包

  推特：<https://twitter.com/phantom>

  网址：<https://phantom.app/>

38、项目：MetaMask

     简介：WEB3钱包

     推特：<https://twitter.com/MetaMask>

   网址：<https://metamask.io/>

39、项目：Showtime

     简介：web3 社交网络，创作者和收藏家在这里展示他们的 NFT，从数字艺术到照片和视频。

     推特：<https://twitter.com/tryShowtime>

   网址：<https://showtime.io/>

40、项目：GALLERY

    简介：Gallery 是一个平台，可以在其中查看、策划、分享和发现您最喜爱的 NFT。 能够通过自己的作品表达自己，并与 NFT 社区中的其他成员建立联系。

  推特：<https://twitter.com/GALLERY>

  网址：<https://gallery.so/>

41、项目：Fractional

    简介：NFT碎片化铸造交易平台

    推特：<https://twitter.com/fractional_art>

  网址：<https://fractional.art/>

  投资机构：Paradigm、Variant等

42、项目：ᴏɴᴄʏʙᴇʀ

     简介：3D 和 VR 体验式NFT一键展示平台

    推特：<https://twitter.com/oncyber_io>

  网址：<https://oncyber.io/>

43、项目：royal

     简介：音乐NFT平台

     推特：<https://twitter.com/join_royal>

     网址：<https://royal.io/>

44、项目：sound.xyz

     简介：音乐NFT平台，为艺术家构建 web3 工具

    推特：<https://twitter.com/soundxyz_>

    网址：<https://www.sound.xyz/rubyred/too-late-to-call>

45、项目：Arpeggi Labs

      简介：WEB3音乐创作平台

    推特：<https://twitter.com/arpeggi_labs>

    网址：<https://www.arpeggi.io/>

46、项目：Bonfida

     简介：sol 域名交易平台

     推特：<https://twitter.com/bonfida>

    网址：<https://bonfida.org/#/>

    合作机构：AKG、Alameda Research、Resident等

47、项目：Flowns

      简介：基于Flow构建的新一代去中心化域名服务平台。

     推特：<https://twitter.com/flownsorg>

      网址：<https://www.flowns.org/zh>

48、项目：unstoppable.x

      简介：NFT高级域名创建平台

      推特：<https://twitter.com/unstoppableweb>

     网址：<https://linktr.ee/unstoppableweb>

     投资机构：Draper、Coinbase、Ventures、Protocol Labs等

原文标题：《一文概览新年至今拿到融资的 NFT 平台》

原文作者：Jiawei（

Twitter: @Elegy4TheArctic

Metaplex

Metaplex 基金会于 1 月 18 日宣布获得 4600 万美元的战略投资，由 Multicoin Capital 和 Jump Crypto 领投。参投者包括 Solana Ventures、 Alameda Research、 Animoca Brands 等机构，以及包括 NBA 巨星乔丹、艾弗森在内的其他个人投资者。这笔资金将被用于扩大业务规模和为社区提供资金支持。

Metaplex 是 Solana 上的 NFT 基础设施协议，提供了一系列的工具和智能合约集成，旨在简化 NFT 的创建与发布。架构层面由 Token Metadata、Token Vault、Auction 和 Metaplex 四个合约集构成。主要提供如下产品：

• Storefront：通用的 NFT 标准，支持创建/铸造 NFT，一级/二级市场的 NFT 拍卖，以及钱包和 APP 中的 NFT 可视化。

• Candy Machine v2：全链上的 NFT 分发程序，提供白名单管理、验证码集成等功能。

此外，Metaplex 还支持公平启动、空投和 NFT 销毁等功能，在 GitHub 有 5,300 次 Fork。

Metaplex 于去年 6 月上线，迄今已有 85,000 个项目的 570 万个 NFT 被铸造，其中包括 Solana 上的热门 NFT 项目 Degen Ape Academy 和 Aurory，并有着超过 60 万的活跃藏家。将在今年推出 iOS 和 Android SDK。

Pixel Vault

Pixel Vault 是一家 Web3 媒体公司，致力于为加密原生资产创作叙事，著名的 PUNKS Comic 和 MetaHero Universe 都是其打造的文化 IP。

PUNKS Comic 于去年 5 月 10 日上线，是首个基于 CryptoPunks 创作的 NFT 和数字漫画。目前在 OpenSea 上已有 5.3 万枚以太坊的交易量。

围绕 PUNKS Comic 还建立了对应的经济系统：

• 销毁 PUNKS Comic NFT，获得 Pixel Vault Founder』s DAO NFT（目前地板价为 5 ETH，而 PUNKS Comic 的发售价仅为 0.2 ETH），享有其治理权和 Discord 的访问权限；

• PUNKS Comic 持有者可以按 0.08 ETH 的价格购买 MintPass NFT，在推出新 IP MetaHero 时可直接进行一比一兑换。而 MetaHero 至今仍维持着接近 5 ETH 的地板价；

• 质押 PUNKS Comic 并获得 PUNKS Token，代表着漫画中出现的 16 个 CryptoPunks NFT 的部分所有权。

Pixel Vault 于 2 月 2 日宣布完成 1 亿美元融资，本轮融资由 Velvet Sea Ventures 和 01 Advisors 参投。这笔资金将用于支持电视、电影和游戏项目的开发。

（01 Advisors 是一家由 Twitter 前首席执行官 Dick Costolo 和 Twitter 前首席运营官 Adam Bain 在 2018 年共同创立的风投公司。Velvet Sea Ventures 还投资了 Autograph 和 SuperRare）

Autograph

Autograph 是一个集体育、娱乐和流行文化于一体的 NFT 平台，总部位于洛杉矶，由著名橄榄球球星、7 届超级碗冠军球员 Tom Brady 联合创办，致力于帮助体育运动员和艺人等发行他们的 NFT。

Tom Brady 持有一部分 FTX 的股份，自称加密货币的「big believer」，将加密社区的标志之一「激光眼」作为自己的推特头像。

这家 NFT 平台于今年 1 月 19 日获得 1.7 亿美元的 B 轮融资，由 a16z 和 Kleiner Perkins 领投，资金将被用于扩展 NFT 技术，并与体育和娱乐合作伙伴建立广泛的合作关系。

团队方面，Autograph 的 CEO Dillon Rosenblatt 来自 Apple Music，COO Ted Russell 担任过福克斯娱乐集团的执行副总裁，CMO Patrick Cassidy 是新百伦的品牌和市场总监。

Autograph 于 2021 年 4 月上线，与内容领域巨头狮门娱乐和体育娱乐公司 DraftKings 建立了合作关系，SBF 也在 Autograph 的执行董事会占有席位。去年 9 月底，高尔夫球巨星 Tiger Woods 就通过其平台发行了 10,000 枚 NFT。

KLKTN

KLKTN 于今年 1 月 26 日宣布完成 640 万美元融资，投资者包括 Animoca Brands、Dapper Labs 、软银前 CSO 兼董事会成员 Katsunori Sago 和 MIT 媒体实验室主管 Joi Ito 等。

KLKTN 是一个 NFT 艺术家平台和交易平台，总部设在香港，主打亚洲市场，旨在通过数字藏品连接音乐人、艺术家和粉丝，让音乐人和艺术家分享他们的幕后花絮和创作过程，并可以选择性地铸造成 NFT。去年 7 月，K-pop 明星禹成贤（Kevin Woo）在 KLKTN 上推出了单曲「Got it」。

团队方面，KLKTN 的 CEO Daisuke Iwase 是日本的金融科技企业家，毕业于哈佛商学院；首席创意官 Jeff Miyahara 是日韩唱片制作人和词曲作者；CTO Fabiano Soriani 曾在 Dapper 工作，参与了 CryptoKitties 和 Flow 的研发。

Closing Thoughts

Metaplex 作为 Solana 上的 NFT 基础设施，提供 NFT 分发、白名单管理 Fair Launch 和空投等功能，几乎覆盖了 NFT 发行的全流程。在不少 DEX 推出一键发币/一键挖矿的功能之后，未来的 NFT 发行大概也会支持「低代码」或「无代码」的模式。

Pixel Vault 推出的经济激励使得旗下的 IP 除了文化传播效应之外，还创造了丰厚的回报。近期还与无聊猿合作，发行了限量版的第二期漫画。更多与头部 NFT 项目/社区的合作会使 IP 有着更丰富的外延和想象空间。

Autograph 和 KLKTN 均是 NFT 平台，分别专注于体育和艺术领域，在这两部分中有写到他们的核心团队背景。

因为 NFT 平台本身没有太多技术上的门槛，并且也不容易体现平台间的区分度，而更多需要回答「Why me」的问题。创始人和团队在体育和娱乐圈的资源无疑更加重要。

在调研以上项目信息时，偶然看到 a16z 合伙人 Chris Dixon 的一篇推文，其中提到「Web3 isn't just a tech movement. It's a cultural one」，深以为然。

本文介绍的四个项目中，Autograph 和 KLKTN 有着强劲的体育/娱乐背景，Pixel Vault 本身打造的就是加密社区的文化 IP，连基础设施层项目 Metaplex 背后也有乔丹和艾弗森的身影。

体育界与娱乐圈顶流纷纷投身于 NFT 领域，使 NFT「出圈」成为未来的必然趋势。

律动 BlockBeats 提醒，根据银保监会等五部门于 2018 年 8 月发布《关于防范以「虚拟货币」「区块链」名义进行非法集资的风险提示》的文件，请广大公众理性看待区块链，不要盲目相信天花乱坠的承诺，树立正确的货币观念和投资理念，切实提高风险意识；对发现的违法犯罪线索，可积极向有关部门举报反映。

The funding round was led by Solana Ventures and Distributed Global. Other participants in the funding round include Lightspeed Venture Partners, Circle Ventures, Coinbase Ventures, Alameda Research, DST Global partners, Road Ventures, Global Founders Capital, BECO Capital, Greenoaks, GoldenTree, Asset Management, and 500 Startups.

“We believe Zebec is well-positioned to become a core primitive for a multitude of streaming money and payment applications,” said Johnny Steindorff, managing partner at Distributed Global. The capital raise comes just three months after the platform’s launch and seed round, bringing the total funding to $21 million.

What is Zebec?

Zebec allows its users to stream payments. Something that was previously limited by our banking system because transactions were subject to fees and lumped together. This innovative way of processing payments opens up new possibilities. For example, authors can charge their readers by the page, and artists get paid instantly for every stream of their songs, but it’s not just beneficial for creators.

The ability to receive USDC by the second can also benefit hourly workers. The Protocol also offers workers the ability to cash out all of their money, automatically convert a portion of their pay check into major cryptocurrencies, or transfer funds to a compliant crypto IRA and 401k account. Since the protocol is built on Solana, transactions take only a few seconds, and the fees for a transaction are only a fraction of a cent.

What we can expect in 2022

Sam Thapaliya, the founder of Zebec, was born during the civil war in Nepal and grew up without bank accounts. He hopes that with Zebec, he can help create a world where everyone has real-time access to capital. His efforts have not gone unnoticed, as Zebec recently became Solana’s first project to be accepted into Visa’s prestigious FinTech Fast Track program, which supports innovative start-ups that are revolutionizing digital payments.

Thapaliya told Cryptonary that Zebec will use the funding to hire employees and create an ecosystem to help companies build on Zebec. More than 250 projects are already building various businesses on the Zebec protocol, but Thapaliya hopes to have doubled that number by the end of the year.

系统方面，建议您尝试执行以下方案扫描修复系统组件：

右击开始按钮>点击"命令提示符"（以管理员身份运行 ），输入：

Dism /Online /Cleanup-Image /ScanHealth

这条命令将扫描全部系统文件并和官方系统文件对比，扫描计算机中的不一致情况。

Dism /Online /Cleanup-Image /CheckHealth

这条命令必须在前一条命令执行完以后，发现系统文件有损坏时使用。

DISM /Online /Cleanup-image /RestoreHealth

这条命令是把那些不同的系统文件还原成官方系统源文件。

完成后重启，无论以上是否成功，键入以下命令：sfc /SCANNOW

1. bonding简介

Linux bonding驱动提供了聚合多个网络接口成为一个单一逻辑接口的方法。对于重要的服务器， bonding可以通过hot standby来提供failover特性，提高系统的可靠性；而对于像文件服务器这样的对网络要求很高的场合,bonding可以极大的提高网络IO总带宽及性能。

1. 网络拓扑

            |uplink                         uplink|
   
      +-----+----+                          +-----+----+
   
      |          |堆叠                  |          |
   
      | switch A +--------------------------+ switch B |
   
      |          |                          |          |
   
      +-----+----+                          +-----++---+
   
            |port1                           port1|
   
            |             +-------+               |
   
            +-------------+ host1 +---------------+
   
                         eth0 +-------+ eth1
   

2. 网络配置

目前新版本Linux内核都已经内置bonding支持，只需要安装ifenslave后即可进行配置，以Debian为例。

106.2.49.195这台机器有2张网卡，现在需要做如下操作：

eth0和eth1 做bond，模式0 ，使用IP：106.2.49.195

编辑 /etc/network/interfaces ：

auto bond0

iface bond0 inet static

bond_slaves eth0 eth1

bond_mode balance-rr

bond_xmit_hash_policy layer2+3

bond_miimon 100

bond_downdelay 200

bond_updelay 200

address 106.2.49.195

netmask 255.255.255.0

gateway 106.2.49.1

重启网络后可以看到虚拟的网卡bond0， 在/sys/class/net/bond0/bonding下可以看到bond0的相关信息：如工作模式，当前状态等等。

1. 注意事项

1）Bonding常用的模式有：

0或者balance-rr

1或者active-backup

4或者802.3ad

2）系统下做bonding时，要先将上联交换机对应端口配置成port-channel并且设定为对应的模式，不然无法正常工作。

downdelay

Specifies the time, in milliseconds, to wait before disabling

a slave after a link failure has been detected.This option

is only valid for the miimon link monitor.The downdelay

value should be a multiple of the miimon value; if not, it

will be rounded down to the nearest multiple.The default

     value is 0.

lacp_rate

Option specifying the rate in which we'll ask our link partner

to transmit LACPDU packets in 802.3ad mode.Possible values

are:

slow or 0

      Request partner to transmit LACPDUs every 30 seconds

fast or 1

      Request partner to transmit LACPDUs every 1 second

The default is slow.

miimon

     Specifies the MII link monitoring frequency in milliseconds.

     This determines how often the link state of each slave is

     inspected for link failures.  A value of zero disables MII

     link monitoring.  A value of 100 is a good starting point.

     The use_carrier option, below, affects how the link state is

     determined.  See the High Availability section for additional

     information.  The default value is 0.

mode

    Specifies one of the bonding policies. The default is
    balance-rr (round robin).  Possible values are:

    balance-rr or 0

           Round-robin policy: Transmit packets in sequential
           order from the first available slave through the
           last.  This mode provides load balancing and fault
           tolerance.

    active-backup or 1

           Active-backup policy: Only one slave in the bond is
           active.  A different slave becomes active if, and only
           if, the active slave fails.  The bond's MAC address is
           externally visible on only one port (network adapter)
           to avoid confusing the switch.

           In bonding version 2.6.2 or later, when a failover
           occurs in active-backup mode, bonding will issue one
           or more gratuitous ARPs on the newly active slave.
           One gratuitous ARP is issued for the bonding master
           interface and each VLAN interfaces configured above
           it, provided that the interface has at least one IP
           address configured.  Gratuitous ARPs issued for VLAN
           interfaces are tagged with the appropriate VLAN id.

           This mode provides fault tolerance.  The primary
           option, documented below, affects the behavior of this
           mode.

    balance-xor or 2

           XOR policy: Transmit based on the selected transmit
           hash policy.  The default policy is a simple [(source
            MAC address XOR'd with destination MAC address XOR
           packet type ID) modulo slave count].  Alternate transmit
           policies may be selected via the xmit_hash_policy option,
           described below.

           This mode provides load balancing and fault tolerance.

    broadcast or 3

           Broadcast policy: transmits everything on all slave
           interfaces.  This mode provides fault tolerance.

    802.3ad or 4

           IEEE 802.3ad Dynamic link aggregation.  Creates
           aggregation groups that share the same speed and
           duplex settings.  Utilizes all slaves in the active
           aggregator according to the 802.3ad specification.

           Slave selection for outgoing traffic is done according
           to the transmit hash policy, which may be changed from
           the default simple XOR policy via the xmit_hash_policy
           option, documented below.  Note that not all transmit
           policies may be 802.3ad compliant, particularly in
           regards to the packet mis-ordering requirements of
           section 43.2.4 of the 802.3ad standard.  Differing
           peer implementations will have varying tolerances for
           noncompliance.

           Prerequisites:

           1. Ethtool support in the base drivers for retrieving
           the speed and duplex of each slave.

           2. A switch that supports IEEE 802.3ad Dynamic link
           aggregation.

           Most switches will require some type of configuration
           to enable 802.3ad mode.

    balance-tlb or 5

           Adaptive transmit load balancing: channel bonding that
           does not require any special switch support.

           In tlb_dynamic_lb=1 mode; the outgoing traffic is
           distributed according to the current load (computed
           relative to the speed) on each slave.

           In tlb_dynamic_lb=0 mode; the load balancing based on
           current load is disabled and the load is distributed
           only using the hash distribution.

           Incoming traffic is received by the current slave.
           If the receiving slave fails, another slave takes over
           the MAC address of the failed receiving slave.

           Prerequisite:

           Ethtool support in the base drivers for retrieving the
           speed of each slave.

    balance-alb or 6

           Adaptive load balancing: includes balance-tlb plus
           receive load balancing (rlb) for IPV4 traffic, and
           does not require any special switch support.  The
           receive load balancing is achieved by ARP negotiation.
           The bonding driver intercepts the ARP Replies sent by
           the local system on their way out and overwrites the
           source hardware address with the unique hardware
           address of one of the slaves in the bond such that
           different peers use different hardware addresses for
           the server.

           Receive traffic from connections created by the server
           is also balanced.  When the local system sends an ARP
           Request the bonding driver copies and saves the peer's
           IP information from the ARP packet.  When the ARP
           Reply arrives from the peer, its hardware address is
           retrieved and the bonding driver initiates an ARP
           reply to this peer assigning it to one of the slaves
           in the bond.  A problematic outcome of using ARP
           negotiation for balancing is that each time that an
           ARP request is broadcast it uses the hardware address
           of the bond.  Hence, peers learn the hardware address
           of the bond and the balancing of receive traffic
           collapses to the current slave.  This is handled by
           sending updates (ARP Replies) to all the peers with
           their individually assigned hardware address such that
           the traffic is redistributed.  Receive traffic is also
           redistributed when a new slave is added to the bond
           and when an inactive slave is re-activated.  The
           receive load is distributed sequentially (round robin)
           among the group of highest speed slaves in the bond.

           When a link is reconnected or a new slave joins the
           bond the receive traffic is redistributed among all
           active slaves in the bond by initiating ARP Replies
           with the selected MAC address to each of the
           clients. The updelay parameter (detailed below) must
           be set to a value equal or greater than the switch's
           forwarding delay so that the ARP Replies sent to the
           peers will not be blocked by the switch.

           Prerequisites:

           1. Ethtool support in the base drivers for retrieving
           the speed of each slave.

           2. Base driver support for setting the hardware
           address of a device while it is open.  This is
           required so that there will always be one slave in the
           team using the bond hardware address (the
           curr_active_slave) while having a unique hardware
           address for each slave in the bond.  If the
           curr_active_slave fails its hardware address is
           swapped with the new curr_active_slave that was
           chosen.

updelay

    Specifies the time, in milliseconds, to wait before enabling a
    slave after a link recovery has been detected.  This option is
    only valid for the miimon link monitor.  The updelay value
    should be a multiple of the miimon value; if not, it will be
    rounded down to the nearest multiple.  The default value is 0.

use_carrier

    Specifies whether or not miimon should use MII or ETHTOOL
    ioctls vs. netif_carrier_ok() to determine the link
    status. The MII or ETHTOOL ioctls are less efficient and
    utilize a deprecated calling sequence within the kernel.  The
    netif_carrier_ok() relies on the device driver to maintain its
    state with netif_carrier_on/off; at this writing, most, but
    not all, device drivers support this facility.

    If bonding insists that the link is up when it should not be,
    it may be that your network device driver does not support
    netif_carrier_on/off.  The default state for netif_carrier is
    "carrier on," so if a driver does not support netif_carrier,
    it will appear as if the link is always up.  In this case,
    setting use_carrier to 0 will cause bonding to revert to the
    MII / ETHTOOL ioctl method to determine the link state.

    A value of 1 enables the use of netif_carrier_ok(), a value of
    0 will use the deprecated MII / ETHTOOL ioctls.  The default
    value is 1.

xmit_hash_policy

    Selects the transmit hash policy to use for slave selection in
    balance-xor, 802.3ad, and tlb modes.  Possible values are:

    layer2

           Uses XOR of hardware MAC addresses and packet type ID
           field to generate the hash. The formula is

           hash = source MAC XOR destination MAC XOR packet type ID
           slave number = hash modulo slave count

           This algorithm will place all traffic to a particular
           network peer on the same slave.

           This algorithm is 802.3ad compliant.

    layer2+3

           This policy uses a combination of layer2 and layer3
           protocol information to generate the hash.

           Uses XOR of hardware MAC addresses and IP addresses to
           generate the hash.  The formula is

           hash = source MAC XOR destination MAC XOR packet type ID
           hash = hash XOR source IP XOR destination IP
           hash = hash XOR (hash RSHIFT 16)
           hash = hash XOR (hash RSHIFT 8)
           And then hash is reduced modulo slave count.

           If the protocol is IPv6 then the source and destination
           addresses are first hashed using ipv6_addr_hash.

           This algorithm will place all traffic to a particular
           network peer on the same slave.  For non-IP traffic,
           the formula is the same as for the layer2 transmit
           hash policy.

           This policy is intended to provide a more balanced
           distribution of traffic than layer2 alone, especially
           in environments where a layer3 gateway device is
           required to reach most destinations.

           This algorithm is 802.3ad compliant.

    layer3+4

           This policy uses upper layer protocol information,
           when available, to generate the hash.  This allows for
           traffic to a particular network peer to span multiple
           slaves, although a single connection will not span
           multiple slaves.

           The formula for unfragmented TCP and UDP packets is

           hash = source port, destination port (as in the header)
           hash = hash XOR source IP XOR destination IP
           hash = hash XOR (hash RSHIFT 16)
           hash = hash XOR (hash RSHIFT 8)
           And then hash is reduced modulo slave count.

           If the protocol is IPv6 then the source and destination
           addresses are first hashed using ipv6_addr_hash.

           For fragmented TCP or UDP packets and all other IPv4 and
           IPv6 protocol traffic, the source and destination port
           information is omitted.  For non-IP traffic, the
           formula is the same as for the layer2 transmit hash
           policy.

           This algorithm is not fully 802.3ad compliant.  A
           single TCP or UDP conversation containing both
           fragmented and unfragmented packets will see packets
           striped across two interfaces.  This may result in out
           of order delivery.  Most traffic types will not meet
           this criteria, as TCP rarely fragments traffic, and
           most UDP traffic is not involved in extended
           conversations.  Other implementations of 802.3ad may
           or may not tolerate this noncompliance.

    encap2+3

           This policy uses the same formula as layer2+3 but it
           relies on skb_flow_dissect to obtain the header fields
           which might result in the use of inner headers if an
           encapsulation protocol is used. For example this will
           improve the performance for tunnel users because the
           packets will be distributed according to the encapsulated
           flows.

    encap3+4

           This policy uses the same formula as layer3+4 but it
           relies on skb_flow_dissect to obtain the header fields
           which might result in the use of inner headers if an
           encapsulation protocol is used. For example this will
           improve the performance for tunnel users because the
           packets will be distributed according to the encapsulated
           flows.

    The default value is layer2.  This option was added in bonding
    version 2.6.3.  In earlier versions of bonding, this parameter
    does not exist, and the layer2 policy is the only policy.  The
    layer2+3 value was added for bonding version 3.2.2.

Creating and Destroying Bonds

To add a new bond foo:

echo +foo > /sys/class/net/bonding_masters

To remove an existing bond bar:

echo -bar > /sys/class/net/bonding_masters

To show all existing bonds:

cat /sys/class/net/bonding_masters

Ref: https://www.kernel.org/doc/Documentation/networking/bonding.txt

bonding的模式：0-6，即：7种模式

第一种模式：mod=0 ，即：(balance-rr) Round-robin policy（平衡抡循环策略） 特点：传输数据包顺序是依次传输（即：第1个包走eth0，下一个包就走eth1....一直循环下去，直到最后一个传输完毕）， 此模式提供负载平衡和容错能力；但是我们知道如果一个连接或者会话的数据包从不同的接口发出的话，中途再经过不同的链路，在客户端很有可能会出现数据包无序到达的问题，而无序到达的数据包需要重新要求被发送，这样网络的吞吐量就会下降

第二种模式：mod=1，即： (active-backup) Active-backup policy（主-备份策略） 特点：只有一个设备处于活动状态，当 一个宕掉另一个马上由备份转换为主设备。mac地址是外部可见得，从外面看来，bond的MAC地址是唯一的，以避免switch(交换机)发生混乱。此模式只提供了容错能力；由此可见此算法的优点是可以提供高网络连接的可用性，但是它的资源利用率较低，只有一个接口处于工作状态，在有 N 个网络接口的情况下，资源利用率为1/N

第三种模式：mod=2，即：(balance-xor) XOR policy（平衡策略） 特点：基于指定的传输HASH策略传输数据包。缺省的策略是：(源MAC地址 XOR 目标MAC地址) % slave数量。其他的传输策略可以通过xmit_hash_policy选项指定，此模式提供负载平衡和容错能力

第四种模式：mod=3，即：broadcast（广播策略） 特点：在每个slave接口上传输每个数据包，此模式提供了容错能力

第五种模式：mod=4，即：(802.3ad) IEEE 802.3ad Dynamic link aggregation（IEEE 802.3ad 动态链接聚合） 特点：创建一个聚合组，它们共享同样的速率和双工设定。根据802.3ad规范将多个slave工作在同一个激活的聚合体下。 外 出流量的slave选举是基于传输hash策略，该策略可以通过xmit_hash_policy选项从缺省的XOR策略改变到其他策略。需要注意的是， 并不是所有的传输策略都是802.3ad适应的，尤其考虑到在802.3ad标准43.2.4章节提及的包乱序问题。不同的实现可能会有不同的适应性。 必要条件： 条件1：ethtool支持获取每个slave的速率和双工设定 条件2：switch(交换机)支持IEEE 802.3ad Dynamic link aggregation 条件3：大多数switch(交换机)需要经过特定配置才能支持802.3ad模式

第六种模式：mod=5，即：(balance-tlb) Adaptive transmit load balancing（适配器传输负载均衡） 特点：不需要任何特别的switch(交换机)支持的通道bonding。在每个slave上根据当前的负载（根据速度计算）分配外出流量。如果正在接受数据的slave出故障了，另一个slave接管失败的slave的MAC地址。 该模式的必要条件：ethtool支持获取每个slave的速率

第七种模式：mod=6，即：(balance-alb) Adaptive load balancing（适配器适应性负载均衡） 特点：该模式包含了balance-tlb模式，同时加上针对IPV4流量的接收负载均衡(receive load balance, rlb)，而且不需要任何switch(交换机)的支持。接收负载均衡是通过ARP协商实现的。bonding驱动截获本机发送的ARP应答，并把源硬件地址改写为bond中某个slave的唯一硬件地址，从而使得不同的对端使用不同的硬件地址进行通信。 来 自服务器端的接收流量也会被均衡。当本机发送ARP请求时，bonding驱动把对端的IP信息从ARP包中复制并保存下来。当ARP应答从对端到达 时，bonding驱动把它的硬件地址提取出来，并发起一个ARP应答给bond中的某个slave。使用ARP协商进行负载均衡的一个问题是：每次广播 ARP请求时都会使用bond的硬件地址，因此对端学习到这个硬件地址后，接收流量将会全部刘翔当前的slave。这个问题通过给所有的对端发送更新 （ARP应答）来解决，应答中包含他们独一无二的硬件地址，从而导致流量重新分布。当新的slave加入到bond中时，或者某个未激活的slave重新 激活时，接收流量也要重新分布。接收的负载被顺序地分布（round robin）在bond中最高速的slave上 当某个链路被重新接上，或者 一个新的slave加入到bond中，接收流量在所有当前激活的slave中全部重新分配，通过使用指定的MAC地址给每个 client发起ARP应答。下面介绍的updelay参数必须被设置为某个大于等于switch(交换机)转发延时的值，从而保证发往对端的ARP应答 不会被switch(交换机)阻截。 必要条件： 条件1：ethtool支持获取每个slave的速率； 条件2：底层驱动支持设置 某个设备的硬件地址，从而使得总是有个slave(curr_active_slave)使用bond的硬件地址，同时保证每个bond 中的slave都有一个唯一的硬件地址。如果curr_active_slave出故障，它的硬件地址将会被新选出来的 curr_active_slave接管 其实mod=6与mod=0的区别：mod=6，先把eth0流量占满，再占eth1，....ethX；而mod=0的话，会发现2个口的流量都很稳定，基本一样的带宽。而mod=6，会发现第一个口流量很高，第2个口只占了小部分流量

来源： http://wushank.blog.51cto.com/3489095/1147864

root@hk4-31:~# lspci -nn|grep -i net
01:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme II BCM57800 1/10 Gigabit Ethernet [14e4:168a] (rev 10)
01:00.1 Ethernet controller [0200]: Broadcom Corporation NetXtreme II BCM57800 1/10 Gigabit Ethernet [14e4:168a] (rev 10)
01:00.2 Ethernet controller [0200]: Broadcom Corporation NetXtreme II BCM57800 1/10 Gigabit Ethernet [14e4:168a] (rev 10)
01:00.3 Ethernet controller [0200]: Broadcom Corporation NetXtreme II BCM57800 1/10 Gigabit Ethernet [14e4:168a] (rev 10)
04:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)
04:00.1 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)
41:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)
41:00.1 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

现在想使用其中一块外接INTEL网卡做VF给KVM虚拟机使用，要解决：

• 只启用指定网卡的SR-IOV

• VF产生后会和系统的网卡顺序混淆，使用时非常难找，因此需要重命名

##VT-d及VF配置

• 安装sysfsutils,并且指定外接其中一块网卡的2个端口才启用VF：

bus/pci/devices/0000:04:00.0/sriov_numvfs = 8
bus/pci/devices/0000:04:00.1/sriov_numvfs = 8

• 启用INTEL的VT-d，除了BIOS启用外还要修改GRUB启动参数

GRUB_CMDLINE_LINUX="intel_iommu=on"

后更新grub:

update-grub

重启后即可以看到：

01:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme II BCM57800 1/10 Gigabit Ethernet [14e4:168a] (rev 10)
01:00.1 Ethernet controller [0200]: Broadcom Corporation NetXtreme II BCM57800 1/10 Gigabit Ethernet [14e4:168a] (rev 10)
01:00.2 Ethernet controller [0200]: Broadcom Corporation NetXtreme II BCM57800 1/10 Gigabit Ethernet [14e4:168a] (rev 10)
01:00.3 Ethernet controller [0200]: Broadcom Corporation NetXtreme II BCM57800 1/10 Gigabit Ethernet [14e4:168a] (rev 10)
04:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)
04:00.1 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)
04:10.0 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:10.1 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:10.2 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:10.3 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:10.4 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:10.5 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:10.6 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:10.7 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:11.0 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:11.1 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:11.2 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:11.3 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:11.4 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:11.5 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:11.6 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
04:11.7 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)
41:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)
41:00.1 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

##UDEV修改解决网卡重命名问题 脚本，用于查看系统网卡及udev:

#!/bin/sh

nets=$(ifconfig -a|grep -E 'eth|vf|pf' |awk '{print $1}')

for i in $nets
do
        driver=$(ethtool -i $i|grep driver)
        bus=$(ethtool -i $i|grep bus-in)
        link=$(ethtool $i | grep 'Link det')
        speed=$(ethtool  $i|grep 'Speed')
        echo "$i        $driver         $bus    $link   $speed"
done | column -t



regexp='looking at parent device.*\/devices\/pci[0-9]+:[0-9]+\/[0-9]+:[0-9]+:[0-9]+.[0-9]+\/[0-9]+:[0-9]+:[0-9]+\.[0-9]+'
nics=$(ls -d /sys/class/net/eth* /sys/class/net/pf* /sys/class/net/vf*)
for nic in $nics
do
        udevadm info -a $nic | grep -A3 -E "$regexp"|tail -n3|tr '\n' '\t'
        i=$(echo $nic | cut -d '/' -f5)
        echo "NAME=\"$i\""
done

查看目前的结果：

eth0    driver: bnx2x           bus-info: 0000:01:00.0          Speed: 10000Mb/s
eth1    driver: bnx2x           bus-info: 0000:01:00.1          Speed: 10000Mb/s
eth3    driver: bnx2x           bus-info: 0000:01:00.2          Speed: 1000Mb/s
eth4    driver: bnx2x           bus-info: 0000:01:00.3          Speed: 1000Mb/s
eth8    driver: ixgbevf         bus-info: 0000:04:11.0          Speed: Unknown!
eth9    driver: ixgbevf         bus-info: 0000:04:10.2          Speed: Unknown!
eth10   driver: ixgbevf         bus-info: 0000:04:10.4          Speed: Unknown!
eth11   driver: ixgbevf         bus-info: 0000:04:10.6          Speed: Unknown!
eth12   driver: ixgbevf         bus-info: 0000:04:10.0          Speed: Unknown!
eth13   driver: ixgbevf         bus-info: 0000:04:11.2          Speed: Unknown!
eth14   driver: ixgbevf         bus-info: 0000:04:11.4          Speed: Unknown!
eth15   driver: ixgbevf         bus-info: 0000:04:11.6          Speed: Unknown!
eth16   driver: ixgbevf         bus-info: 0000:04:10.1          Speed: Unknown!
eth17   driver: ixgbevf         bus-info: 0000:04:10.3          Speed: Unknown!
eth18   driver: ixgbevf         bus-info: 0000:04:10.5          Speed: Unknown!
eth19   driver: ixgbevf         bus-info: 0000:04:10.7          Speed: Unknown!
eth20   driver: ixgbevf         bus-info: 0000:04:11.1          Speed: Unknown!
eth21   driver: ixgbevf         bus-info: 0000:04:11.3          Speed: Unknown!
eth22   driver: ixgbevf         bus-info: 0000:04:11.5          Speed: Unknown!
eth23   driver: ixgbevf         bus-info: 0000:04:11.7          Speed: Unknown!

 KERNELS=="0000:01:00.0" SUBSYSTEMS=="pci" DRIVERS=="bnx2x" NAME="eth0"
KERNELS=="0000:01:00.1" SUBSYSTEMS=="pci" DRIVERS=="bnx2x" NAME="eth1"
KERNELS=="0000:04:10.4" SUBSYSTEMS=="pci" DRIVERS=="ixgbevf" NAME="eth10"
KERNELS=="0000:04:10.6" SUBSYSTEMS=="pci" DRIVERS=="ixgbevf" NAME="eth11"
KERNELS=="0000:04:11.2" SUBSYSTEMS=="pci" DRIVERS=="ixgbevf" NAME="eth13"
KERNELS=="0000:04:11.4" SUBSYSTEMS=="pci" DRIVERS=="ixgbevf" NAME="eth14"
KERNELS=="0000:04:11.6" SUBSYSTEMS=="pci" DRIVERS=="ixgbevf" NAME="eth15"
KERNELS=="0000:04:10.1" SUBSYSTEMS=="pci" DRIVERS=="ixgbevf" NAME="eth16"
KERNELS=="0000:04:10.3" SUBSYSTEMS=="pci" DRIVERS=="ixgbevf" NAME="eth17"
KERNELS=="0000:04:10.5" SUBSYSTEMS=="pci" DRIVERS=="ixgbevf" NAME="eth18"
KERNELS=="0000:04:10.7" SUBSYSTEMS=="pci" DRIVERS=="ixgbevf" NAME="eth19"
KERNELS=="0000:04:00.0" SUBSYSTEMS=="pci" DRIVERS=="ixgbe" NAME="eth2"
KERNELS=="0000:04:11.1" SUBSYSTEMS=="pci" DRIVERS=="ixgbevf" NAME="eth20"
KERNELS=="0000:04:11.3" SUBSYSTEMS=="pci" DRIVERS=="ixgbevf" NAME="eth21"
KERNELS=="0000:04:11.5" SUBSYSTEMS=="pci" DRIVERS=="ixgbevf" NAME="eth22"
KERNELS=="0000:04:11.7" SUBSYSTEMS=="pci" DRIVERS=="ixgbevf" NAME="eth23"
KERNELS=="0000:01:00.2" SUBSYSTEMS=="pci" DRIVERS=="bnx2x" NAME="eth3"
KERNELS=="0000:01:00.3" SUBSYSTEMS=="pci" DRIVERS=="bnx2x" NAME="eth4"
KERNELS=="0000:04:00.1" SUBSYSTEMS=="pci" DRIVERS=="ixgbe" NAME="eth5"
KERNELS=="0000:41:00.0" SUBSYSTEMS=="pci" DRIVERS=="ixgbe" NAME="eth6"
KERNELS=="0000:41:00.1" SUBSYSTEMS=="pci" DRIVERS=="ixgbe" NAME="eth7"
KERNELS=="0000:04:10.2" SUBSYSTEMS=="pci" DRIVERS=="ixgbevf" NAME="eth9"

由于VF的MAC地址有不确定性，所以这里我们选择以PCI BUS ID来作为命名依据： vi /etc/udev/rules.d/99-pfvf-net.rules 并且去掉默认生成的net.rules里这几个网卡的内容

KERNELS=="0000:04:00.0"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbe"    NAME="pf-hk"
KERNELS=="0000:04:00.1"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbe"    NAME="pf-cmcc"
KERNELS=="0000:04:10.0"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf0-hk"
KERNELS=="0000:04:10.2"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf1-hk"
KERNELS=="0000:04:10.4"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf2-hk"
KERNELS=="0000:04:10.6"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf3-hk"
KERNELS=="0000:04:11.0"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf4-hk"
KERNELS=="0000:04:11.2"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf5-hk"
KERNELS=="0000:04:11.4"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf6-hk
KERNELS=="0000:04:11.6"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf7-hk"
KERNELS=="0000:04:10.1"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf0-cmcc"
KERNELS=="0000:04:10.3"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf1-cmcc"
KERNELS=="0000:04:10.5"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf2-cmcc"
KERNELS=="0000:04:10.7"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf3-cmcc"
KERNELS=="0000:04:11.1"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf4-cmcc"
KERNELS=="0000:04:11.3"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf5-cmcc"
KERNELS=="0000:04:11.5"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf6-cmcc"
KERNELS=="0000:04:11.7"         SUBSYSTEMS=="pci"       DRIVERS=="ixgbevf"  NAME="vf7-cmcc"

需要注意的是， vf的pci id并不是连续的， 在2个PF的情况下，这些VF交叉出现

现在让命名生效，先卸载PF和VF的驱动：

modprobe -r ixgbe
modprobe -r ixgbevf

更新 udev设备名:

udevadm trigger  --action=add

然后重新加载驱动，即可以看到想要的顺序了：

eth0      driver:  bnx2x    bus-info:  0000:01:00.0  Link  detected:  yes  Speed:  10000Mb/s
eth1      driver:  bnx2x    bus-info:  0000:01:00.1  Link  detected:  yes  Speed:  10000Mb/s
eth3      driver:  bnx2x    bus-info:  0000:01:00.2  Link  detected:  yes  Speed:  1000Mb/s
eth4      driver:  bnx2x    bus-info:  0000:01:00.3  Link  detected:  yes  Speed:  1000Mb/s
eth6      driver:  ixgbe    bus-info:  0000:41:00.0  Link  detected:  yes  Speed:  10000Mb/s
eth7      driver:  ixgbe    bus-info:  0000:41:00.1  Link  detected:  yes  Speed:  10000Mb/s
pf-cmcc   driver:  ixgbe    bus-info:  0000:04:00.1  Link  detected:  no   Speed:  10000Mb/s
pf-hk     driver:  ixgbe    bus-info:  0000:04:00.0  Link  detected:  no   Speed:  10000Mb/s
vf0-cmcc  driver:  ixgbevf  bus-info:  0000:04:10.1  Link  detected:  no   Speed:  Unknown!
vf0-hk    driver:  ixgbevf  bus-info:  0000:04:10.0  Link  detected:  no   Speed:  Unknown!
vf1-cmcc  driver:  ixgbevf  bus-info:  0000:04:10.3  Link  detected:  no   Speed:  Unknown!
vf1-hk    driver:  ixgbevf  bus-info:  0000:04:10.2  Link  detected:  no   Speed:  Unknown!
vf2-cmcc  driver:  ixgbevf  bus-info:  0000:04:10.5  Link  detected:  no   Speed:  Unknown!
vf2-hk    driver:  ixgbevf  bus-info:  0000:04:10.4  Link  detected:  no   Speed:  Unknown!
vf3-cmcc  driver:  ixgbevf  bus-info:  0000:04:10.7  Link  detected:  no   Speed:  Unknown!
vf3-hk    driver:  ixgbevf  bus-info:  0000:04:10.6  Link  detected:  no   Speed:  Unknown!
vf4-cmcc  driver:  ixgbevf  bus-info:  0000:04:11.1  Link  detected:  no   Speed:  Unknown!
vf4-hk    driver:  ixgbevf  bus-info:  0000:04:11.0  Link  detected:  no   Speed:  Unknown!
vf5-cmcc  driver:  ixgbevf  bus-info:  0000:04:11.3  Link  detected:  no   Speed:  Unknown!
vf5-hk    driver:  ixgbevf  bus-info:  0000:04:11.2  Link  detected:  no   Speed:  Unknown!
vf6-cmcc  driver:  ixgbevf  bus-info:  0000:04:11.5  Link  detected:  no   Speed:  Unknown!
vf6-hk    driver:  ixgbevf  bus-info:  0000:04:11.4  Link  detected:  no   Speed:  Unknown!
vf7-cmcc  driver:  ixgbevf  bus-info:  0000:04:11.7  Link  detected:  no   Speed:  Unknown!
vf7-hk    driver:  ixgbevf  bus-info:  0000:04:11.6  Link  detected:  no   Speed:  Unknown!

##注意事项 别忘记在/etc/network/interfaces里添加pf自启动，不需要配置ip，但是如果PF是DOWN的，VF在虚拟机里将不能使用

auto pf-cmcc
iface pf-cmcc inet manual
up ip link  set pf-cmcc up

auto pf-hk
iface pf-hk inet manual
up ip link set pf-hk up

WIN+x a

slmgr /skms x.x.x.x

slmgr /ato

slmgr /xpr

Office/Project/Visio 2013(2010换下安装路径) 激活命令：

32位：CD “%ProgramFiles(x86)%\MICROSOFT OFFICE\OFFICE15″

64位：CD “%ProgramFiles%\MICROSOFT OFFICE\OFFICE15″

CSCRIPT OSPP.VBS /SETHST:123.58.180.4

CSCRIPT OSPP.VBS /ACT

CSCRIPT OSPP.VBS /DSTATUS