无忧启动论坛

 找回密码
 注册
搜索
系统gho:最纯净好用系统下载站广告联系 微信:wuyouceo QQ:184822951
楼主: zhaohj
打印 上一主题 下一主题

[讨论] VLAN划分后,pxe启动win7/8PE加载速度问题

[复制链接]
跳转到指定楼层
1#
发表于 2013-5-2 11:33:51 | 只看该作者 |只看大图 回帖奖励 |倒序浏览 |阅读模式
本帖最后由 zhaohj 于 2013-5-2 12:10 编辑

PXE启动问题:
单位纯千兆网络环境(交换机或路由器、网卡都是千兆、6类网线),在单一网段下pxe加载win7/8pe使用一起正常。
设置bcd的ramdisktftpblocksize=8192,200兆的WIM文件大概20秒不到就加载完毕。
-----------------
最近单位划分了VLAN,服务器单独一个vlan网段,其他各部门划分不同的vlan网段,各网段之间可以相互访问。
问题来了,客户端pxe启动win7/8pe,在加载wim文件时卡死不动。
查找原因是ramdisktftpblocksize问题,取消这个选项就可以了,但速度慢很多了。

主交换机是思科ws-c4503,其他交换机是华为s5700。
请教大家有什么办法?
现在肯定是路由转发的时候,超过blocksize默认值就截断了,怎样修改交换机参数?

Snap1.jpg (40.89 KB, 下载次数: 57)

Snap1.jpg

Snap2.jpg (18.57 KB, 下载次数: 63)

Snap2.jpg
2#
发表于 2013-5-2 22:32:01 | 只看该作者
本帖最后由 bluetooth 于 2013-5-2 22:50 编辑

请问跨vlan,dhcp只要一台服务器就可以吗?
我不懂网络,也没有权限,现在用esx下面搭建了一台dhcp服务器,加了10块虚拟网卡,9块负责9个vlan的dhcp,一块网卡用于远程连接。
pxe用了grub\pxelinux\ipxe三种方式,速度上面ipxe有较大优势,ipxe需要获得两次地址,有的vlan不好使。兼容性\pxelinux\ipxe较好,pxelinux修改blocksize后,速度也不错,但是有的vlan经常加载到一点点出错。
楼主用ipxe试试,速度不错。
回复

使用道具 举报

3#
发表于 2013-5-2 23:17:33 | 只看该作者
是三层交换机吗?进去配置或者查下说明书,看有没有修改的。
回复

使用道具 举报

4#
 楼主| 发表于 2013-5-3 07:49:36 | 只看该作者
bluetooth 发表于 2013-5-2 22:32
请问跨vlan,dhcp只要一台服务器就可以吗?
我不懂网络,也没有权限,现在用esx下面搭建了一台dhcp服务器, ...

我是在服务器上做dhcp(当然一台dhcp服务器就可),三层路由交换机上做dhcp中继代理。
----------------------
现在的问题是pxe启动grldr,pxeboot.n12(mootmgr)接管以后,已经与grub4dos无关了。
我在与服务器同一网段上测试也一样,难道是核心交换机(cisco-ws-c4503-e)的问题?
----------------
未划分vlan前,用的是华为s5700核心,一起正常。
回复

使用道具 举报

5#
发表于 2013-5-3 08:34:39 | 只看该作者
zhaohj 发表于 2013-5-3 07:49
我是在服务器上做dhcp(当然一台dhcp服务器就可),三层路由交换机上做dhcp中继代理。
---------------- ...

那跨vlan访问dhcp那台服务器,下载镜像,还得写路由吧。
我是没有交换机的权限,只是让网管给我开了trunck,自己在esx下面的VM折腾呢。
修改blocksize后的pxelinux试过在直接接到核心上面的网络没有问题,在汇聚上面就有问题。后来大的镜像直接用ipxe启动了。
您试试ipxe吧,也是方便,http下载镜像,速度相当不错。
回复

使用道具 举报

6#
 楼主| 发表于 2013-5-3 09:51:05 | 只看该作者
现在讨论技术,目前的问题是grldr->pxeboot.12->bootmge.exe->boot.sid->bcd->win8pe.wim(这里卡住了)->winload.exe
不是没有加载,wim镜像(120M)大约加载到35%,大概42M左右。ramdisktftpblocksize大小不同,百分数有区别;但同一ramdisktftpblocksize大小,加载的百分比是一样的。
这个问题已经与启动无关了,纯win8的pxe启动问题。
简单测试了一下,用pxeboot.n12做启动文件,只要ramdisktftpblocksize不是默认值,跨VLAN下都会卡住。
问题范围缩小了:速度与缓存是正比关系,bootmgr.exe跨网段的缓存不够。我想这个应该在交换机中配置。思科的交换机没资料查看。
回复

使用道具 举报

7#
发表于 2013-5-3 11:08:57 | 只看该作者
也有可能是相关硬件或软件的 bug。我觉得 bug 的可能性大。虽然不是 grub4dos 的 bug,但有可能是硬件以及 bootmgr.exe 的 bug。

在解决 grub4dos 的 PXE 问题时,发现,blocksize 的大小,对于不同的 BIOS,以及不同的 TFTP 服务器软件,都有影响。有的 PXE BIOS 认死了 blksize=512,不管你按照 PXE 协议通知它改变 blksize 为多少,它实际上都不改变。也就是说,它根本就不严格遵守 PXE 协议。此时,如果你按照协议,认为 blksize 已经改变成你设定的值(比如 1408),那就错了。当你读 1408 字节的时候,它给你返回 512 字节,其余的(1408 - 512 )个字节是未填充的(未初始化的)。当你接下来再读下一个 1408 字节块的时候,它返回第二个 512 字节,后面同样有 (1408 - 512)个字节是空洞。这样一来,整个文件的内容读出来就全乱套了,根本不是原来的文件,连文件的大小都变了。

像这样糟糕的客户端 PXE BIOS,无论服务器端多么优秀,都解决不了问题。而在客户端上运行的的应用程序(即 grub4dos 等启动软件)必须设法探测这种情况,并能够适应这个糟糕的客户端 PXE BIOS。

虽然 bootmgr 不一定使用 PXE BIOS,但它可能遇到了类似的差错。就是说,bootmgr 自己的驱动程序遇到了不适应的(或者不规范的、有 bug 的)硬件。而采用默认值之所以安全,大概是因为此时 bootmgr 能够自动探测出正确的 blksize 值,也或者可能是服务器和客户端都支持的最安全值(协议之外的、未公开的约定,各方都遵守,比如说,512 字节就可能是一个各方都支持的 blksize 值,同时也可能是最小的允许值)。

回复

使用道具 举报

8#
 楼主| 发表于 2013-5-6 11:28:41 | 只看该作者
搞了几天,还没有搞定。难道是cisco与huawei的交换机不兼容引起的?
等待高手解决问题!
回复

使用道具 举报

9#
 楼主| 发表于 2013-5-14 10:38:32 | 只看该作者
BcdDeviceObjectElementTypes enumeration
Specifies the device object element types.

Syntax

typedef enum BcdDeviceObjectElementTypes {
  BcdDeviceInteger_RamdiskImageOffset            = 0x35000001,
  BcdDeviceInteger_TftpClientPort                = 0x35000002,
  BcdDeviceInteger_SdiDevice                     = 0x31000003,
  BcdDeviceInteger_SdiPath                       = 0x32000004,
  BcdDeviceInteger_RamdiskImageLength            = 0x35000005,
  BcdDeviceBoolean_RamdiskExportAsCd             = 0x36000006,
  BcdDeviceInteger_RamdiskTftpBlockSize          = 0x36000007,
  BcdDeviceInteger_RamdiskTftpWindowSize         = 0x36000008,
  BcdDeviceBoolean_RamdiskMulticastEnabled       = 0x36000009,
  BcdDeviceBoolean_RamdiskMulticastTftpFallback  = 0x3600000A,
  BcdDeviceBoolean_RamdiskTftpVarWindow          = 0x3600000B
} BcdDeviceObjectElementTypes;
Constants
BcdDeviceInteger_RamdiskImageOffset
The RAM disk image offset. The element data format is BcdIntegerElement.

BcdDeviceInteger_TftpClientPort
The IP port number to be used for Trivial File Transfer Protocol (TFTP) reads. The element data format is BcdIntegerElement.

If this value is not specified, the default TFTP protocol port is used.

BcdDeviceInteger_SdiDevice
The device that contains the SDI object. The element data format is BcdDeviceElement.

BcdDeviceInteger_SdiPath
The path from the root of the SDI device to the RAM disk file. The element data format is BcdStringElement.

BcdDeviceInteger_RamdiskImageLength
The length of the image for the RAM disk. The element data format is BcdIntegerElement.

BcdDeviceBoolean_RamdiskExportAsCd
Enables exporting the RAM disk as a CD. The element data format is BcdBooleanElement.

BcdDeviceInteger_RamdiskTftpBlockSize
Defines the TFTP block size for the RAM disk Windows Imaging (WIM) file. The element data format is BcdIntegerElement.

BcdDeviceInteger_RamdiskTftpWindowSize
Defines the TFTP window size for the RAM disk WIM file. The element data format is BcdIntegerElement.

BcdDeviceBoolean_RamdiskMulticastEnabled
Enables or disables multicast for the RAM disk WIM file. The element data format is BcdBooleanElement.

BcdDeviceBoolean_RamdiskMulticastTftpFallback
Enables fallback to TFTP if multicast fails. The element data format is BcdBooleanElement.

BcdDeviceBoolean_RamdiskTftpVarWindow
Enables or disables the TFTP variable window size extension. The element data format is BcdBooleanElement.

Note  This value is supported starting in Windows 8 and Windows Server 2012.
=======================
上面有关TFTP的其它定义,不知怎处理?
回复

使用道具 举报

10#
发表于 2013-9-5 08:17:09 | 只看该作者
曾经有过类似问题。不过不是在vlan中发生的。也是下载镜像的中途timeout了。

http://bbs.wuyou.net/forum.php?mod=viewthread&tid=199122

这个应该是一个tftp下载相关的问题。
最后怎么 解决的问题我记不起来了。反正是解决了。
回复

使用道具 举报

11#
发表于 2014-4-4 12:11:58 | 只看该作者
标记下,学习了。vlan的确方便,但也带来很多应用的麻烦。比如acl控制就很复杂
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|手机版|Archiver|捐助支持|无忧启动 ( 闽ICP备05002490号-1 )

闽公网安备 35020302032614号

GMT+8, 2024-4-27 05:18

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表