今天真是实实在在的验证option 61和基于cos的统计一天，原本以为很简单的任务真正上手后才感觉要理清这个测试思路还是需要付出不少，同时也真切的感受到初期负责撰写测试用例的前辈有多少了不起。明天就是周末了，其实我也想放松一下，可是感觉目前好像除了看看书，我还真的没有什么事情可以做，而且，我知道“明天周末”这是对自己找的一个借口，对于学习积累来说，每天都是星期一，我害怕我放松一天就会给自己好不容易下的决心敲出一个裂缝，然后就是决堤。所以哪怕只有10分钟，我也要强迫自己看书，写下今天工作的体会。
dhcp的option字段第一次接触是82，一个用来保护server，防止外部client无秩序的申请ip地址造成混乱的字段，今天接触的option61字段在功能上来说比较简单，只是一个表示dhcp client的client-id的字段，在正常的dhcp申请过程中存在于client向server发送的discovery报文和request报文中，用来向server标识自身身份的一个字段。拿到这个任务的时候我只是单纯的认为只需要搭建一个简单的client---HUB---server的拓扑，查看这两种报文中存在的option61字段的标识是否与client上的client-id相匹配。后来发现原来option 61不仅存在于dhcp client上，而且，它在dhcp snooping上也有很大的用途。
我们知道dhcp snooping是配置在dhcp client与dhcp server之间的一个中继设备，通过option字段可以提供诸多的服务，另外就是针对内网中的arp中间人攻击和arp欺骗，我们常常可以采用dhcp snooping来提供一种安全机制，配合dynamic arp insepection和ip source guard，我们可以动态或者静态的根据dhcp snooping中的注册记录来对arp和source ip进行筛选，过滤掉我们不期望通过的arp报文和ip报文。而在这里，dhcp snooping option 61字段则可以为通过snooping设备的dhcp交互报文提供补充和去除多余字段的作用：为dhcp client发送的不含有client-id（也就是option 61）字段的discovery和request报文添加上snooping的client-id，以方便server对其进行辨识；同时为含有cliend-id（此时不应该含有）的server的offer和ack报文进行服务，去除掉option 61字段。
目前为止，我仍没有理解snooping option 61这种机制的作用，因为正常的client的报文都会包括option61字段，这在dhcp请求的时候就会进行封装，同时正常的server在回应报文中都不会带有该字段，因为回应报文基本都为单播报文，直指client（或者是snooping），难道这种机制是为了安全的考虑？防止外来错误的dhcp报文？这里给自己留下一个疑问吧。
今天工作的另外重点是对基于cos的过滤规则的报文统计做验证，还好这个并不是很困难，仅仅是查看结果是否正确以及设计一下测试方案而已。
不过今天还是做的很辛苦，晚上爸爸妈妈来到了北京，一个老同学也过来了，还是比较开心，更让我开心的，貌似明天可以去打篮球了！呼呼，好像很没出息的样子哦，好啦，今天的感想也写下来了，我希望自己能一直坚持下去，我相信如果我真能坚持下去，一定会有一个好的未来。
12点了，明天是周末了，祝自己能过一个好的周末，也祝我的朋友明天面试成功，去看书了，去啃IPv6了，强迫自己要去看，因为我不能给自己的懒惰开一个头，本来自制力就不强的我可经不住这么一点点的蚕食啊。
