PPPoE的封装结构（经典：解释了PPPoE中虚拟网卡的作用）

起因：

昨天跟几个研究生调接入网实验室的设备，
完了后抓了下PPPoE的包，
发现封装很奇特，类似如下：



172.16.1.118和172.16.1.116是两台机器PPPoE拨号后服务器分给的地址。

从理论上来讲，ping一下，抓到的帧的封装应该是这样的：
icmp
ip
ppp
pppoe
mac

感觉这个事情和原理不符合。

又因为之前无意抓过一次，看到了ppp的层。
那次得到的两个地址是不同子网的，
于是得到了一个结论，
说在同一子网的数据包不经过ppp封装。（错）

原理探讨：

ppp拨号前应该有一个地址IP，
拨号有一个地址IP(PPP)。

如果是使用前者通信，
则应该是IP之后直接走到MAC层。
同一内网用户就是这样干的，
所以PPPoE对内网用户缺乏有力的控制。

如果是使用后者通信，
那么不管两台机器的物理位置如何，
都得和服务器建立虚连接，
从服务器那里绕一圈回来通信。

在上面的例子中，
用的是PPPoE服务器给的两个地址来ping。
所以应该是具有PPP封装的才对。

上午和老师讨论过，
认为现象上确实存在问题，
于是下午重新抓了下包。

抓包的操作问题：

这里非常感谢cong哥犀利的眼光，
一来就发现了是选择网卡的问题。
原来选择物理网卡可以抓出这样的包：



注意Wireshark这个是低层次放在上面。
这样出来的结果就是和理论完全符合的了。

--

所以可见昨天的现象纯属巧合了。
当抓不同子网的时候，恰好选到了物理网卡。
当抓同一子网的时候，选到了ppp的虚拟网卡。
这就出现了前面那个别扭的错误结论。

深层次的问题：

在拨号之后，会出现一个ppp的虚拟网卡。
这应该算是系统实现上的巧妙之处吧。

默认路由指向ppp网卡出去的网关，
那么当用户在内网交互的时候，
可以直接走MAC，
除此之外，都从ppp这边交出去。

而实际实现中，并不是像我们想象的，
各个实体从上倒下依次堆叠。
依次堆叠出来的效果将是，
IP实体需要知道某个包应该由哪个下层去交付，
才能够决定给MAC还是ppp。
这样会涉及到改变IP实体的实现，不是很科学。

系统的解决办法是出现一个新的网卡，
从IP的角度来看，他还是交给了一个MAC实体。
就像第一幅抓包出来的图一样，
这里一样看得到一对MAC地址。

该网卡是ppp虚拟出来的网卡，
它很清楚应该怎样封装ppp和pppoe，
然后填上自己的mac和服务器的mac。
所以都准备好后，
这时才交给物理网卡处理。

这样就很好地解释为什么两个网卡上抓出来的不一样了。

这种并列的结构应该是一种巧妙的实现，
相比堆叠的结构，不会导致上层的改变。


cap文件下载。
两种网卡下抓的包，
附带PPPoE连接和断开过程。

引用：http://hi.baidu.com/hplonline/blog/item/0832b63e8f9c6cf6838b13fb.html