stevenlee's blog

stevenlee's picture

Symantec 急招两名测试工程师

急招两名测试工程师,要是懂网络,TCP、IP,如果能够用c++写测试工具更佳, 熟悉802.1x优先。

要求工作经验1-2年,待遇自己谈。

工作地点: 北京

可以发简历到steven.li0628@gmail.com

 

 

stevenlee's picture

Symantec is looking for a strong Principle Engineer Program Manager

Symantec is urgently looking for a strong Principle Engineer Program Manager to manage our first fully owned SNAC project and some feature teams in coming mainline projects.

Here is the JD for a Principle Program Manager.

Responsibilities
We are looking for a Principle program manager, who will own multiple security products.
You will manage junior program manager(s) and/or a few software engineers (Dev & QA).
You will be coordinating with Product Manager, Sales, Support, Dev, QA, and all other stakeholders across the world in owned product lines.
You will be coordinating with local engineering team and global program managers for US owned product lines.
You will be responsible for working with all stakeholders to generate product roadmap and collect requirements from all global product team and local sales/supporting team.
You will be responsible for PLC, including requirement management, scheduling & planning, status monitoring, risk assessment & mitigation plan, etc.
You will lead the whole team to deliver high-quality and on-time schedule releases.
You will be responsible for quick/accurate responses to customer cases & hot escalations globally.

stevenlee's picture

os中预留客户端时,测试注意事项

1. 安装删除成功,里面的信息(公司信息,version,log 等等)准确
2. 安装后,软件本事功能,界面易用性
3. 在不同os上安装,删除
4. 跟不同杀毒软件的兼容性,会不会被认为是病毒或者木马
5. 如果有心跳,可以把DUT搞死,然后client是否还能继续使用,进程能否自己kill
6. 覆盖安装或者删除安装,或者删除的同时安装
7. 卸载后进程检查
8. 安装成功后,安装目录中关于公司信息的检查,尤其如果有OEM的情况
9. 注册表中关于公司信息的检查。
10. 悬浮信息的检查。
11. 。。。。。。。。。。。

stevenlee's picture

通过在防火墙OS中保存client端,用户容易接受吗?

在防火墙os中保存客户端,然后用户如果想使用某个feature的功能时,会自动提示用户需要下载一个在os中已经存在的客户端,这样方式用户喜欢接受吗? 他就不会担心该客户端会不会有后门程序?

stevenlee's picture

使用linux和routeos搭建pppoe server

文章中介绍使用两种方式搭建pppoe server, 以及在linux和routeos上启用SNAT功能。

在linux上打架pppoe server比较简单。

routeos是一个可以在VMware上运行的os,里面的功能非常全。

http://www.mikrotik.com/testdocs/ros/3.0/

这个网站上有文档。

stevenlee's picture

性能测试

吞吐量
吞吐量是衡量一款设备转发数据包能力的测试。这个数据是衡量一款防火墙或者路由交换设备的最重要的指标。

测试吞吐量首先根据标称性能确定被测试设备的可能吞吐量大小,这样来决定我们测试一款设备所需要的测试仪端口数量。如果一块设备标称性能达到8Gbps,那么通常我们需要8个1000Mbps的测试仪端口来测试。

吞吐量的测试通常会选用测试仪所对应的RFC测试套件进行测试。测试的数据包长包括64Bytes,128Bytes,256Bytes,512Bytes,1024Bytes,1240Bytes,1518Bytes。或者使用特定包长或者混合包长(IMIX)进行测试。IMIX流量通常是指用几种数据包混合流量来测试防火墙的吞吐量。我们测试用的比例为64Bytes*58%+570Bytes*34%+1518Bytes*8%,也就是7:4:1。如果需要测试VPN的吞吐量,不能使用1518Bytes,因为会分片,一般改用1400字节测试。

吞吐量一般采用UDP数据包进行测试。测试通常采用双向各一条流或者多条流的方式测试。测试流量通常是A<->B,C<->D双向对打的流量。也存在使用单向流量测试的情况。比如使用3个端口测试,那么流量就是A->B->C->A这样的环形流量。

测试仪会采用二分迭代法进行测试。比如测试仪会首先使用100%的流量发包(1st trial),如果发现丢包,则会采用50%((100%+0)/2)的流量进行测试(2nd trial),如果发现没有丢包,会采用75%((50%+100%)/2)的流量进行测试(3rd trial)。通过这种二分迭代的测试最终测试出设备的最大吞吐量数据。测试每一个trial的标准时间为2分钟,每个包长通常会进行10-30个trial的测试(取决于测试仪设置的精确度)。由于测试仪会严格判断是否有丢包,即使有一个包没有收到,都会用二分法往下降。但是这个丢包可能不是设备(网线质量,中间的交换机或者其他原因)造成。因此对于这种情况,测试仪都会有一个loss tolerance的设定,通过设定一个恰当的数值来避免其它原因造成丢包对测试结果的影响。

在进行对一款设备的吞吐性能测试时,通常会纪录一组从64Bytes到1518Bytes的测试数据,每一个测试结果均有相对应的pps数。64Bytes的pps数最大,基本上可以反映出设备处理数据包的最大能力。仅仅从64Bytes的这个数我们基本上可以推算出系统最大能处理的吞吐量是多少。因为通常衡量一款网络设备的CPU/NP/ASIC的最大处理能力的极限就是64Bytes的pps数。很多路由设备的性能指标有一点就是宣称xxMpps,所指的就是设备处理64Bytes的pps数。比如64Bytes的pps为100000pps,吞吐量为100000*(64+20)*8/1000000= 67.2Mbps,拿这个结果计算1518Bytes的数据为100000*(1518+20)*8/100000=1230.4Mbps。其中的20Bytes是指12Bytes的帧间距(IPG)以及8Bytes的前导码(7Bytes同步+1Bytes起始),测试每一个字节的吞吐量都需要将这20字节计算在内。通过前面的算式可以看出,我们即使不测试1518Bytes的吞吐量也能够大致推算出设备最大的吞吐量是多少。而最终的结果只能<=这个结果。

时延
时延所测试的是系统处理数据包所需要的时间。防火墙的时延测试的是其存储转发(Store and Forward)的性能(另一种是Cut and Through)。

时延的测试通常会选用测试仪所对应的RFC测试套件进行测试。测试的数据包长包括64Bytes,128Bytes,256Bytes,512Bytes,1024Bytes,1240Bytes,1518Bytes。或者使用特定包长或者混合包长进行测试。采用UDP数据包进行测试。测试通常采用双向各一条流的方式测试。

时延的测试通常是建立在测试完吞吐量的基础上进行的测试。测试时延之前需要先测出每个包长得吞吐量大小,使用每个包长的吞吐量结果的 100%-90%作为时延测试的流量大小。一般时延的测试要求不能够有任何的丢包。因为如果丢包,会造成时延非常大,结果不准确。我们测试一般使用最大吞吐量的95%或者90%进行测试。测试结果包括最大时延,最小时延,平均时延,一般记录平均时延。

如果测试得比较精细,也可以测试在不同负载下的时延。比如可以测试在10%,20%...直到最大负载的结果下的时延。

测试时长通常是设置2分钟的流量,然后测试几次取平均值最为最终结果。

丢包率
丢包率是测试系统在一定负载的情况下丢包数量多少的测试。这个测试实际上和吞吐量测试类似。测试的意义在于通过过载的流量来考查对设备正常转发性能的影响。

丢包率的测试通常会选用测试仪所对应的RFC测试套件进行测试。测试的数据包长包括64Bytes,128Bytes,256Bytes,512Bytes,1024Bytes,1240Bytes,1518Bytes。或者使用特定包长或者混合包长进行测试。采用UDP数据包进行测试。测试通常采用双向各一条流的方式测试。

测试方法通常是采用10%--100%的流量分别测试被测系统的丢包情况。当测试100%负载的情况事,对于NP/ASIC架构的防火墙来说,丢包率=1-吞吐量(%)。因为NP和ASIC转发更依靠硬件的性能,而硬件的性能通常比较稳定。而对于多核和x86架构的防火墙来说,转发依靠CPU的计算,性能相对硬件转发来说相对较弱,所以100%负载的丢包率>1-吞吐量(%)。比如我们测试出NP墙的吞吐量是80%,那么100%的丢包率基本上可以推算出等于20%,而多核和x86架构的防火墙的丢包率大多数情况>20%。所以,丢包率的测试对于我们产品的测试不是很有利。不过丢包率的测试在一般的对外测试中并不常见。

背靠背缓冲测试
背靠背缓冲测试主要测试被测设备缓冲处理burst数据的能力。考验的是被测设备处理突发数据流缓存数据并快速处理的能力。这个测试在一般的测试中并不常见。

测试方法和结果和吞吐量有很多相似的地方。测试仪向背测试设备发送一定流量大小的数据包,发送时间通常为1-2秒,然后看接收端能够收到多少的数据包。通常线速转发的设备的背靠缓冲能力和吞吐量的pps相一致。比如,一台设备能够线速转发双向2Gbps的流量,那么背靠背缓冲性能(发送时间为2秒)基本上可以确定是148万*2*2 pps。

系统恢复时间
系统恢复时间的测试在一般的对外测试中不太常见,但是电信客户还是比较关注这个性能。这个测试包括:系统重起的时间测试,系统断电重起的时间测试,HA倒换时间测试,HA恢复时间测试,系统过载恢复测试(这个一般很少见)。

系统重起的时间测试,系统断电重起的时间测试通常会纪录系统重新启动所需要的时间。

HA倒换时间测试,HA恢复时间测试对于电信运营商来说是一个很重要的指标,测试包括主备切换时间测试,备主恢复时间测试。

通用的测试方法为:使用测试仪发送恒定速率的流量穿过DUT,DUT进行reset,或者断电操作,直到流量恢复正常。恢复时间=丢包数量/发包速率。另外一种测试方法是通过ping包丢弃的数量来衡量倒换的时间。

stevenlee's picture

bypass介绍

为了支持在DUT断电是DUT可以正常转发,需要bypass的功能:就是在DUT工作正常时正常的转发,当DUT断电或者出现异常时进入bypass模式。一般可以分为内置和外置。 内置比较简单。

这里介绍一下外置。

外置分有电源和无电源,介绍1路和多路,单模和多模

1路的情况,bypass盒子需要两条线跟DUT相连,bypass还需要两条线跟外面相连,然后从外面收发包。

(我怎么不能贴个图呢?要是有个图就更形象和容易理解了。呵呵)

在bypass盒子和DUT之间有一心跳线,正常是bypass盒子是normal。如果DUT断电或者bypass自己断电,bypass盒子就进入bypass模式,这样流量就不会断, 当bypass盒子,DUT上电回复后,bypass盒子又回到normal状态。正常转发。 可以通过心跳线,watchdog。如果做的好,可以通过监控端口来做。如果相连端口松动或者down了也可以切换。

这个需要DUT在二层模式。目前在二层模式下也可以做很多事情,比如av,qos等。

stevenlee's picture

都是license惹得祸

今天在用IXIA时发现license过期了, 呵呵, 然后有些功能就不能用了(原来人家给的就是个trial license). 开始跟IXIA的人联系, 希望能再给license试用, 那边人说可以争取, 然后一家人就看着IXIA在那里不能使用了. 当然基本的功能还是可以使用.

由此想到一个问题, 现在随着功能的增多, 很多厂商都在做自己认为有特色的feature的license, 开始给个试用,感觉不错, 等过期了. 呵呵. 想用? 可以! 交钱...然后就是money的问题了.

其实license确实是一个好东东, 可以限制一些功能, 可以给个试用期, 可以扩展session, 内存数目. 但是当自己是用户的时候却感觉很不爽. 所以这个问题的看站在谁的角度来考虑了.

stevenlee's picture

IPSec VPN 介绍.

里面对ikev1, ikev2, ipsec, ah, esp, 以及nat-t, dpd都介绍比较清楚. 可以参考一下.

当然最好还是看相关的RFC.

Ipsec.pdf

stevenlee's picture

ixload 使用总结1

以前习惯使用ixload都是比较简单的测试. 每次使用或者load以前的配置, 或者自己重新构造相应的server/client.
其实ixload中很多都是tcl写的, 而且也提供了很多API. 可以利用里面的API自己构造脚步, 实现自动化的测试.

附件中提供了一个例子测试http.该例子使用在windows上. 有兴趣的可以参考一下.

目前只是把测试http的数据提取出来, 放到一个excl文件中, 可以在里面扩充, 把数据从excl中提取出来, 算一些自己需要的数据. 这样比手工测试会节省很多时间.

还存在一个问题就是在
set test [::IxLoad new ixTest \
-name "my_test" \
-statsRequired 1 \
-enableResetPorts 1
]

3.0和3.3中如果把-statsRequired 设置为0, 在3.3的版本中就出不来结果, 但是在3.0的版本中就有结果. 目前还不知道为什么?

附件中把ixload_http.txt ixload_setup.txt改为后缀是.tcl文件. runall.txt改为.bat文件

Syndicate content