在我的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究竟是如何知道该如何转发数据的，我的版本是预配置，这当然只是我的一种方式而已！标准做法是通过一个通信协议，从另一台机器上获取，这个所谓的另一台机器是什么？我把它称为控制器。也就是说，路由逻辑等控制模块全部移到了这个控制器中了。
现在看一下，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
