ip_conntrack缓存neighbour-阿里云开发者社区

开发者社区> 云计算> 正文

ip_conntrack缓存neighbour

简介:
在我的ip_conntrack版本中,它目前已经可以缓存路由,filter规则等,还可以平滑生效最新配置的NAT,它越来越像真正的SDN了,唯一有待完善的就是将5元组的tuple进化成N元组的tuple了,其余的更新及修正都是些不会引发质变的量变。
   现在看一下,ip_conntrack还能缓存什么?当然了,在我的"路由cache in conntrack"版本中,我只是将dst_entry简单的从skb中拷贝到了ip_conntrack中,类似IPMARK那样,可以在skb和conntrack之间save和restore。数据包进入协议栈被处理的流程依然没变,优化掉的仅仅是一个路由缓存和路由表的查找过程。虽然迈出了决定性的一步,但是在编程接口上确实没有什么吸引人的地方,因此你也就不想基于此去写一些代码了。比如说,数据包依然要经过ip_rcv函数的处理,依然要经过FORWARD这个HOOK链,一切都像往常一样,不同的只是在查找路由之前,路由已经被从conntrack结构体里面restore到skb了。
   如果想实现真正的流式转发,并且基于硬卡实现这种逻辑,那么就必然要对真正负责转发的链路层以及物理层动手术,比如在PREROUTING中直接将数据包注入硬卡,然后由硬卡实现以下policy:
由tuple查找conntrack;
取出route;
取出neighbour;
直接ASIC转发。
返回HOOK NF_STOLEN

对了,正是这个逻辑,它不但解放了BOX的CPU,而且还使得转发更加灵活。我们已经可以取出route,并且由于neighbour就保存在route中(Linux网络栈如此设计真的很妙!),只要将此neighbour hold on,它就能保持一直不被释放,脱离ARP的timer管理,类似static设置的ARP映射一样。
   这个neighbour的cache很关键,它直接cache了“需要最终落实的信息”,那就是下一跳的MAC地址,它甚至可以cache上一跳的MAC地址,如此一来网络上的数据转发就真正退化(也许是进化)成了“基于流头的路由,策略匹配,MAC地址的下一跳解析"了!属于同一流的后续包无需做任何协议栈里面的常规操作,所有信息都可以从conntrack中取得,这难道不就是SDN的核心吗?
   从最开始完成”完全桥接“版本的conntrack(即那个不需要配置返回包路由的那个版本,直接将上一跳的MAC进行cache,返回包直接封装其MAC地址的版本),到接触到SDN,然后陆续完成各种基于SDN核心思想的conntrack版本,其间两个月有余,然而代码很不规范,也没有提交到任何地方...
   看看所做的这一切,通过iptables,通过自己编写HOOK函数,来实现自动路由,自动封装MAC地址,一切都是基于conntrack,这是什么行为?这其实正是在逐渐架空传统协议栈的路由逻辑,ARP解析逻辑啊!一个转发BOX竟然没有路由逻辑,没有ARP逻辑,这是不可想象的,它成了什么?或者问什么东西没有这些复杂的逻辑?答案显而易见!switch!对了,就是switch,终于,BOX退化成了一个交换机!仅仅负责数据的转发,而控制逻辑从哪里来?或者问,一个傻瓜switch究竟是如何知道该如何转发数据的,我的版本是预配置,这当然只是我的一种方式而已!标准做法是通过一个通信协议,从另一台机器上获取,这个所谓的另一台机器是什么?我把它称为控制器。也就是说,路由逻辑等控制模块全部移到了这个控制器中了。

   这便是我的SDN版本!一个不同于OpenFlow的,但是完全体现SDN思想的非标准化的SDN实现。接下来要证实的是,IP路由并不是根本,根本是什么?根本是”可以落实的“东西,那就是有封装以太帧的目标MAC地址!!!(走火入魔了!!!)


 本文转自 dog250 51CTO博客,原文链接:http://blog.51cto.com/dog250/1275707


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
云计算
使用钉钉扫一扫加入圈子
+ 订阅

时时分享云计算技术内容,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。

其他文章