A net
Donghai Han's Weblog Donghai Han's Weblog
星期四 四月 05, 2007
先说句题外话，这个标题来自于阿基米德的名言，估计老板们会比较喜欢听，
嗯，兄弟们都不用买计算机了，建个zone就够了吗，节流！节流！
从去年六月开始我就投入了IP Instances （Crossbow 的一部分）项目中，
一直忙到现在才算基本完成（还有一点工作，但是总体来说已经完成了）。
关于这个项目的基本情况，我们的总设计师，Erik Nordmark老大已经写了两篇文档：
IP Instances Overview and Usage Document
and
IP Instances Internal Design Document
（我的名字也忝列其中，惭愧的是贡献甚少）
技术上的细节就不谈了，上面两篇文档中说得很清楚，就用户的体验而言，新东西就在于
一个zone现在可以拥有自己的网络接口，那么在使用上，在一个zone里和在物理机器上
就没什么区别了。
在集成了IP Instances之后，Solaris上有了两种zone：
shared-IP zones: 就是原来的那种zone
exclusive-IP zones: IP Instances项目引入的新类型
在zonecfg info的输出中, 多了一个新的属性:
ip-type
它的值可以是"shared"或"exclusive",分别对应于上面所说的两种zone。
在配置exclusive-IP zone的时候，语法与之前有所不同，只需要分配一个接口就可以
了，网络配置是在这个zone里面自己完成的，也就是说，配置网络的自由/乐趣属于这
个zone的管理员了。
举个例子，假设一台计算机有两个网络接口，bge0和bge1，管理员决定把bge1分配给 一个叫test0的zone。
zonecfg -z test0
test0: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:test0> create
zonecfg:test0> set zonepath=/export/test0
zonecfg:test0> set ip-type=exclusive
zonecfg:test0> add net
zonecfg:test0:net> set physical=bge1
zonecfg:test0:net> end
zonecfg:test0> exit
然后，zoneadm -z test0 install再zoneadm -z test0 boot
zlogin -C test0，走一遍系统配置的流程就可以了。
有个问题不太好意思，当前只有GLDv3的驱动是可以和exclusive-IP的zone一起工作的
不过呢，这种情况也不会持续太久，一旦Clearview项目 的 Nemo Unification and Vanity Naming 做完了，就没有这种限制了。
exclusive-IP zone的配置基本上与物理机器一样，最简单的方法就是使用sysidcfg了
在zone的安装完毕之后，或者当你在这个zone里面运行了sys-config之后，可以在
这个zone的/etc目录下放一个名为sysidcfg的文件，内容大概如下：
system_locale=C
terminal=xterms
security_policy=NONE
root_password="加密后的密码"
nfs4_domain="nfs域名"
name_service=NIS{
domain_name="nis域"
name_server="服务器的名字(服务器的ip)"
}
timezone="时区"
network_interface=primary
{hostname="zone的机器名"
default_route="缺省路由"
ip_address="ip地址"
netmask="子网掩码"
protocol_ipv6="yes或no"}
然后启动这个zone，搞定！
现在，在这个zone里, 你可以:
ifconfig bge1 plumb/unplumb/up/down
snoop -d bge1
etc...
还有, 在zonecfg里还可以将physical置为一个VLAN, 例如, bge33001, 用法与物理网络
接口完全一样！
嗯，兄弟们都不用买计算机了，建个zone就够了吗，节流！节流！
从去年六月开始我就投入了IP Instances （Crossbow 的一部分）项目中，
一直忙到现在才算基本完成（还有一点工作，但是总体来说已经完成了）。
关于这个项目的基本情况，我们的总设计师，Erik Nordmark老大已经写了两篇文档：
IP Instances Overview and Usage Document
and
IP Instances Internal Design Document
（我的名字也忝列其中，惭愧的是贡献甚少）
技术上的细节就不谈了，上面两篇文档中说得很清楚，就用户的体验而言，新东西就在于
一个zone现在可以拥有自己的网络接口，那么在使用上，在一个zone里和在物理机器上
就没什么区别了。
在集成了IP Instances之后，Solaris上有了两种zone：
shared-IP zones: 就是原来的那种zone
exclusive-IP zones: IP Instances项目引入的新类型
在zonecfg info的输出中, 多了一个新的属性:
ip-type
它的值可以是"shared"或"exclusive",分别对应于上面所说的两种zone。
在配置exclusive-IP zone的时候，语法与之前有所不同，只需要分配一个接口就可以
了，网络配置是在这个zone里面自己完成的，也就是说，配置网络的自由/乐趣属于这
个zone的管理员了。
举个例子，假设一台计算机有两个网络接口，bge0和bge1，管理员决定把bge1分配给 一个叫test0的zone。
zonecfg -z test0
test0: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:test0> create
zonecfg:test0> set zonepath=/export/test0
zonecfg:test0> set ip-type=exclusive
zonecfg:test0> add net
zonecfg:test0:net> set physical=bge1
zonecfg:test0:net> end
zonecfg:test0> exit
然后，zoneadm -z test0 install再zoneadm -z test0 boot
zlogin -C test0，走一遍系统配置的流程就可以了。
有个问题不太好意思，当前只有GLDv3的驱动是可以和exclusive-IP的zone一起工作的
不过呢，这种情况也不会持续太久，一旦Clearview项目 的 Nemo Unification and Vanity Naming 做完了，就没有这种限制了。
exclusive-IP zone的配置基本上与物理机器一样，最简单的方法就是使用sysidcfg了
在zone的安装完毕之后，或者当你在这个zone里面运行了sys-config之后，可以在
这个zone的/etc目录下放一个名为sysidcfg的文件，内容大概如下：
system_locale=C
terminal=xterms
security_policy=NONE
root_password="加密后的密码"
nfs4_domain="nfs域名"
name_service=NIS{
domain_name="nis域"
name_server="服务器的名字(服务器的ip)"
}
timezone="时区"
network_interface=primary
{hostname="zone的机器名"
default_route="缺省路由"
ip_address="ip地址"
netmask="子网掩码"
protocol_ipv6="yes或no"}
然后启动这个zone，搞定！
现在，在这个zone里, 你可以:
ifconfig bge1 plumb/unplumb/up/down
snoop -d bge1
etc...
还有, 在zonecfg里还可以将physical置为一个VLAN, 例如, bge33001, 用法与物理网络
接口完全一样！
Since last June I have been working on IP Instances project (part of Crossbow ), which we
put back into Nevada on Jan 19/20 (depends on what part of the little earth you stand on)
and backported to S10u4 just recently. My boss, Markus has mentioned it on his blog on
Jan 22
For information on IP Instances, we have two excellent documentations, they are:
IP Instances Overview and Usage Document
and
IP Instances Internal Design Document
(Our Architect, Erik Nordmark wrote them, though my name is listed in the first one, what I
wrote is just a tiny tiny part :-) )
Basically, w.r.t user experience, the most interesting part of IP Instances is that a zone
can own it's own network interfaces, so even in a zone, one can play with network interfaces
just like on a physical machine.
With IP Instances, now we have two types of zones:
shared-IP zones: today's S10 behavior
exclusive-IP zones: new, introduced by IP Instances project
If you look at the output of zonecfg info, you will find a new property:
ip-type
which could be "shared" or "exclusive", correspond to shared-IP zones and exclusive-IP zones.
The Syntax of zone network configuration has been changed. Now what zonecfg does for an
exclusive-IP zone is only assigning interfaces, the network setup is done INSIDE the zone,
just like what we do for a physical machine, that is, now it is the job/right of the non-global
zone root to play with it.
Here's an example: machine with bge0 and bge1 configuring zone test0 to use bge1.
zonecfg -z test0
test0: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:test0> create
zonecfg:test0> set zonepath=/export/test0
zonecfg:test0> set ip-type=exclusive
zonecfg:test0> add net
zonecfg:test0:net> set physical=bge1
zonecfg:test0:net> end
zonecfg:test0> exit
Then a zoneadm -z test0 install and zoneadm -z test0 boot
Then zlogin -C test0 to the zone test0's console and go through the set up process.
!Note: only GLDv3 drivers work with exclusive-IP zones at this time, sorry about that. :-(
But, you don't have to wait a long time, since with Nemo Unification and Vanity Naming of Clearview integrated in the near
future, we will be able to support all drivers.
To set up an exclusive-IP zone is the same as the global zone, and the most easy way will
be using sysidcfg, once you install the zone, or done a sys-unconfig in the zone, you can put
a file named sysidcfg
under the zone's /etc directory, with contents like this:
system_locale=C
terminal=xterms
security_policy=NONE
root_password="encrypted_password(same as the one will be in shadow)"
nfs4_domain="your nfs domain"
name_service=NIS{
domain_name="your nis domain"
name_server="name_server's name(name_server's ip)"
}
timezone="your time zone"
network_interface=primary
{hostname="name of the zone"
default_route="default route"
ip_address="ip address of the interface"
netmask="net mask of the interface"
protocol_ipv6="yes or no"}
And boot the zone, you will then have a working zone with everything setup!
Now, zlogin to the zone, and you can just do anything you like:
ifconfig bge1 plumb/unplumb/up/down/...
snoop -d bge1
etc...
One thing, in zonecfg you can also set physical to a VLAN, say, bge33001, then when the zone
boots, that VLAN will be created on the fly for the zone, and the set up process will be the
same as for a physical network interface...
Isn't it just fun?
put back into Nevada on Jan 19/20 (depends on what part of the little earth you stand on)
and backported to S10u4 just recently. My boss, Markus has mentioned it on his blog on
Jan 22
For information on IP Instances, we have two excellent documentations, they are:
IP Instances Overview and Usage Document
and
IP Instances Internal Design Document
(Our Architect, Erik Nordmark wrote them, though my name is listed in the first one, what I
wrote is just a tiny tiny part :-) )
Basically, w.r.t user experience, the most interesting part of IP Instances is that a zone
can own it's own network interfaces, so even in a zone, one can play with network interfaces
just like on a physical machine.
With IP Instances, now we have two types of zones:
shared-IP zones: today's S10 behavior
exclusive-IP zones: new, introduced by IP Instances project
If you look at the output of zonecfg info, you will find a new property:
ip-type
which could be "shared" or "exclusive", correspond to shared-IP zones and exclusive-IP zones.
The Syntax of zone network configuration has been changed. Now what zonecfg does for an
exclusive-IP zone is only assigning interfaces, the network setup is done INSIDE the zone,
just like what we do for a physical machine, that is, now it is the job/right of the non-global
zone root to play with it.
Here's an example: machine with bge0 and bge1 configuring zone test0 to use bge1.
zonecfg -z test0
test0: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:test0> create
zonecfg:test0> set zonepath=/export/test0
zonecfg:test0> set ip-type=exclusive
zonecfg:test0> add net
zonecfg:test0:net> set physical=bge1
zonecfg:test0:net> end
zonecfg:test0> exit
Then a zoneadm -z test0 install and zoneadm -z test0 boot
Then zlogin -C test0 to the zone test0's console and go through the set up process.
!Note: only GLDv3 drivers work with exclusive-IP zones at this time, sorry about that. :-(
But, you don't have to wait a long time, since with Nemo Unification and Vanity Naming of Clearview integrated in the near
future, we will be able to support all drivers.
To set up an exclusive-IP zone is the same as the global zone, and the most easy way will
be using sysidcfg, once you install the zone, or done a sys-unconfig in the zone, you can put
a file named sysidcfg
under the zone's /etc directory, with contents like this:
system_locale=C
terminal=xterms
security_policy=NONE
root_password="encrypted_password(same as the one will be in shadow)"
nfs4_domain="your nfs domain"
name_service=NIS{
domain_name="your nis domain"
name_server="name_server's name(name_server's ip)"
}
timezone="your time zone"
network_interface=primary
{hostname="name of the zone"
default_route="default route"
ip_address="ip address of the interface"
netmask="net mask of the interface"
protocol_ipv6="yes or no"}
And boot the zone, you will then have a working zone with everything setup!
Now, zlogin to the zone, and you can just do anything you like:
ifconfig bge1 plumb/unplumb/up/down/...
snoop -d bge1
etc...
One thing, in zonecfg you can also set physical to a VLAN, say, bge33001, then when the zone
boots, that VLAN will be created on the fly for the zone, and the set up process will be the
same as for a physical network interface...
Isn't it just fun?
星期五 六月 09, 2006
春晚的“昨天今天明天”用了几年的时间才出了续集，原因估计是没凑齐人，
我的blog呢，也一样是耗时两月才再次续貂，嘿嘿，原因是一样地，没凑齐，我。
这段时间到是发生了不少事情，譬如说：
上次提到的DLPI回环处理的修改基本上完成了（当然，迄今为止我们的工作还限于
GLDv3也就是Nemo的范畴）。简单来说，就是两点：
1 在该回环的地方回环
我们知道，GLDv3是分层的，一个简单的示意图如下：
snoop ip bridge
\ | /
dls （其他用户）
\ /
mac
driver
其中dls与mac是属于GLDv3的范畴，dls是mac层用户，mac还可以有其他用户，譬如aggr，不过
在大多数情况下，都是dls，而上层的协议/应用则基本上都是dls的用户。
在原来的实现中，假如ip发送了一个数据包，那么这个包要经过dls，再经过mac之后
才会回环给snoop，这样做其实从效率上没有什么损失，因为Nemo的设计/实现已经充分
考虑了这一点，但是它的问题在于
（1）违反了分层的原则，既然分了层次，就不应该做“穿透”的操作
（2）在回环处理时无法标识发送方，因为对于mac来说，dls以上的层次是完全
不可见的。
经过我们的修改，现在的回环可以发生在dls层，也可以发生在mac层，以上面的图为例，
如果其他用户并不存在，那么只有dls层在做本地的回环处理，mac根本就不知道（也不
应该知道/关心）发生了回环处理。而且由于在dls层，每个用户都有唯一的标识，因此
就更加容易控制了。
2 随时“混杂”
在之前的设计中，只有有了promisc模式的用户，才会激活回环处理，而且基本上只有
promisc模式的用户才会接收回环的传来的包，在前-bridge :-) 时代，这是完全没有
问题的，因为基本上没有其他的需求，但是在加入bridge之后，这就不够了，因为bridge
的作用就是把“桥那头”的所有相关的流量都“搞”过来，而这些流量中，就有可能有
发送给同一个dls之上的ip协议栈的，虽然由于bridge本身是promisc模式的，但是ip，
它老人家哪里知道这个，它根本就不接受回环的包。
现在好了，经过我们的修改，只要有多个用户，只要有任何一个用户在发送，就回环。。。
性能怎么办？嗯，这个，世界是现实地，理想化是不可以地，满足所有人还是需要地，
代码中还是有很多if地，所以，结果还是可以接受地。
这段时间我还干了点预料之外的工作，就是生成树协议的实现。本来这部分应该是由Yukun同学
完成的，但是他有另外的、更加重要的、关乎国计民生的国家大事需要处理，于是我就只好
被推上前线了，还好，也做得七七八八了。
好了，流水帐式的工作汇报完成了。。。 总结真是一个可怕的东西，写着写着就开始怀疑：我
这两个月都干什么了？这么就这么点东西。。。
不能再写了，真是越写越少啊
我的blog呢，也一样是耗时两月才再次续貂，嘿嘿，原因是一样地，没凑齐，我。
这段时间到是发生了不少事情，譬如说：
上次提到的DLPI回环处理的修改基本上完成了（当然，迄今为止我们的工作还限于
GLDv3也就是Nemo的范畴）。简单来说，就是两点：
1 在该回环的地方回环
我们知道，GLDv3是分层的，一个简单的示意图如下：
snoop ip bridge
\ | /
dls （其他用户）
\ /
mac
driver
其中dls与mac是属于GLDv3的范畴，dls是mac层用户，mac还可以有其他用户，譬如aggr，不过
在大多数情况下，都是dls，而上层的协议/应用则基本上都是dls的用户。
在原来的实现中，假如ip发送了一个数据包，那么这个包要经过dls，再经过mac之后
才会回环给snoop，这样做其实从效率上没有什么损失，因为Nemo的设计/实现已经充分
考虑了这一点，但是它的问题在于
（1）违反了分层的原则，既然分了层次，就不应该做“穿透”的操作
（2）在回环处理时无法标识发送方，因为对于mac来说，dls以上的层次是完全
不可见的。
经过我们的修改，现在的回环可以发生在dls层，也可以发生在mac层，以上面的图为例，
如果其他用户并不存在，那么只有dls层在做本地的回环处理，mac根本就不知道（也不
应该知道/关心）发生了回环处理。而且由于在dls层，每个用户都有唯一的标识，因此
就更加容易控制了。
2 随时“混杂”
在之前的设计中，只有有了promisc模式的用户，才会激活回环处理，而且基本上只有
promisc模式的用户才会接收回环的传来的包，在前-bridge :-) 时代，这是完全没有
问题的，因为基本上没有其他的需求，但是在加入bridge之后，这就不够了，因为bridge
的作用就是把“桥那头”的所有相关的流量都“搞”过来，而这些流量中，就有可能有
发送给同一个dls之上的ip协议栈的，虽然由于bridge本身是promisc模式的，但是ip，
它老人家哪里知道这个，它根本就不接受回环的包。
现在好了，经过我们的修改，只要有多个用户，只要有任何一个用户在发送，就回环。。。
性能怎么办？嗯，这个，世界是现实地，理想化是不可以地，满足所有人还是需要地，
代码中还是有很多if地，所以，结果还是可以接受地。
这段时间我还干了点预料之外的工作，就是生成树协议的实现。本来这部分应该是由Yukun同学
完成的，但是他有另外的、更加重要的、关乎国计民生的国家大事需要处理，于是我就只好
被推上前线了，还好，也做得七七八八了。
好了，流水帐式的工作汇报完成了。。。 总结真是一个可怕的东西，写着写着就开始怀疑：我
这两个月都干什么了？这么就这么点东西。。。
不能再写了，真是越写越少啊
星期一 四月 03, 2006
整整一个月前，老板发信给我说要链接我的blog，然后就问我：
All I have been able to find so far was:
http://blogs.sun.com/roller/page/hdh?anchor=first_one_has_to_be
Is that all?
嗯，这个，我狂汗，是啊，申请了blog接近一年，却是连个坑都没有挖，惭愧
于是下决心，写！
这个决心一下，又是一个月过去了，申请blog已经超过一年了，今天不再下决心了，直接动手吧。
这里借用赵本山、宋丹丹和崔永元的一个著名小品的题目：昨天今天明天：
昨天，我在三层以上写代码，今天，我在二层做研发，明天，明天星期二吧？
好，废话少说，现在我正在参与的项目叫做 Ethernet bridge module for Solaris
这个项目就是在Solaris上实现以太网桥，也就是二层交换的功能。当前的目标很简单，就是实现基本的
桥接功能，包括生成树算法的实现。另外，一个间接的好处（也非常重要）就是让Solaris能够成为各种主流
虚拟机软件的宿主系统，包括VMware和Xen。
既然是网桥，那么其功能也就没有什么特别之处了，不过由于Solaris协议栈的实现采用了STREAMS与DLPI，在
Bridge的实现上就有些复杂之处了。譬如说一个很微妙的地方就在于回环（loopback）处理。
关于这个内容，我们的老大，Mike Ditto已经在OpenSolaris的
论坛上发表了意见：http://www.opensolaris.org/jive/message.jspa?messageID=28615
（在该讨论内容的底部）
另外，对这个主题感兴趣的朋友还可以参考GLDv3的源代码：
mac_txloop
与
i_dls_link_ether_loopback
它们一个是GLDv3 mac层的通用函数，另一个是以太网处理的相关函数。
简单点说，我们要解决的主要有以下三点：
1 数据包的发送者不再收到它自己发送的数据包，这一点对于Bridge非常重要，因为Bridge做的就是将数据包
从一个接口“桥接”到另一个（或者多个）接口，而在另一个接口发送这些数据包的时候，在当前的实现中，
这个数据包会被回环给Bridge，增加了额外的处理负担。
2 如果被发送的数据包的目的地址包含了本接口的mac地址（可以是等于，也可能是一个组播地址），就一定要
把该数据包送给合适的接收方。这一点对IP协议栈很重要，因为在当前的实现中，IP栈是没有考虑接受回环
的数据包的，原因很简单，没有需求，发送方只有一个，就是IP自己。但是加入Bridge之后就不同了，我们就
要考虑让IP接收通过Bridge转送过来的，发给本机的，针对当前接口的MAC地址的数据包了。
3 同2，从另一个角度考虑，要不要把这个数据包真正发送到网络上去，这是比较微妙的一个问题，当前还没有
定论，有时间我会再写一篇来专门讨论。
之所以要这么处理这些问题，原因就在于我们选择了做一个“守法”的DLPI公民，将Bridge实现为与IP并行的
DLS用户，而不是像各种BSD与Linux那样将Bridge“插入”到IP与网卡驱动之间，这更多的是一种哲学或者说
美学上的选择，性能的优劣，就等我们做完才知道了。
最后，再借用一下这个我很喜欢的小品的名字：
昨天，我只能在Linux/Windows上使用虚拟机，今天，我们要改变它，明天，明天确实是星期二。
All I have been able to find so far was:
http://blogs.sun.com/roller/page/hdh?anchor=first_one_has_to_be
Is that all?
嗯，这个，我狂汗，是啊，申请了blog接近一年，却是连个坑都没有挖，惭愧
于是下决心，写！
这个决心一下，又是一个月过去了，申请blog已经超过一年了，今天不再下决心了，直接动手吧。
这里借用赵本山、宋丹丹和崔永元的一个著名小品的题目：昨天今天明天：
昨天，我在三层以上写代码，今天，我在二层做研发，明天，明天星期二吧？
好，废话少说，现在我正在参与的项目叫做 Ethernet bridge module for Solaris
这个项目就是在Solaris上实现以太网桥，也就是二层交换的功能。当前的目标很简单，就是实现基本的
桥接功能，包括生成树算法的实现。另外，一个间接的好处（也非常重要）就是让Solaris能够成为各种主流
虚拟机软件的宿主系统，包括VMware和Xen。
既然是网桥，那么其功能也就没有什么特别之处了，不过由于Solaris协议栈的实现采用了STREAMS与DLPI，在
Bridge的实现上就有些复杂之处了。譬如说一个很微妙的地方就在于回环（loopback）处理。
关于这个内容，我们的老大，Mike Ditto已经在OpenSolaris的
论坛上发表了意见：http://www.opensolaris.org/jive/message.jspa?messageID=28615
（在该讨论内容的底部）
另外，对这个主题感兴趣的朋友还可以参考GLDv3的源代码：
mac_txloop
与
i_dls_link_ether_loopback
它们一个是GLDv3 mac层的通用函数，另一个是以太网处理的相关函数。
简单点说，我们要解决的主要有以下三点：
1 数据包的发送者不再收到它自己发送的数据包，这一点对于Bridge非常重要，因为Bridge做的就是将数据包
从一个接口“桥接”到另一个（或者多个）接口，而在另一个接口发送这些数据包的时候，在当前的实现中，
这个数据包会被回环给Bridge，增加了额外的处理负担。
2 如果被发送的数据包的目的地址包含了本接口的mac地址（可以是等于，也可能是一个组播地址），就一定要
把该数据包送给合适的接收方。这一点对IP协议栈很重要，因为在当前的实现中，IP栈是没有考虑接受回环
的数据包的，原因很简单，没有需求，发送方只有一个，就是IP自己。但是加入Bridge之后就不同了，我们就
要考虑让IP接收通过Bridge转送过来的，发给本机的，针对当前接口的MAC地址的数据包了。
3 同2，从另一个角度考虑，要不要把这个数据包真正发送到网络上去，这是比较微妙的一个问题，当前还没有
定论，有时间我会再写一篇来专门讨论。
之所以要这么处理这些问题，原因就在于我们选择了做一个“守法”的DLPI公民，将Bridge实现为与IP并行的
DLS用户，而不是像各种BSD与Linux那样将Bridge“插入”到IP与网卡驱动之间，这更多的是一种哲学或者说
美学上的选择，性能的优劣，就等我们做完才知道了。
最后，再借用一下这个我很喜欢的小品的名字：
昨天，我只能在Linux/Windows上使用虚拟机，今天，我们要改变它，明天，明天确实是星期二。
星期三 三月 23, 2005
Just registered this account, so this rather empty entry was added...
