GREENSTACK

Energy optimization of OpenStack-based cloud data center infrastructures

openstack底层技术-netfilter框架

Author: Jian Li Source: Planet OpenStack netfilter框架 conntrack Bridge与netfilter netfilter与LVS openstack安全组实现 netfilter框架 netfilter是linux内核中的一个数据包过滤框架,用于替代原有的ipfwadm和ipchains等数据包处理程序。netfilter的功能包括数据包过滤,修改,NAT等。netfilter在内核协议栈的不同位置实现了5个钩子函数(hooks),不同类型的网络数据包会通过不同的hook点(比如数据包是要forward,或是localin),用户层工具iptables/ebtables通过操作不同的hook点以实现对通过此hook点的数据包的处理 下面这张图来自维基百科netfilter, 它展示了netfilter注册的hook点在内核协议栈的分布,以及packet在通过内核协议栈时,所经过的hook点,你们可能发现这张图在我的博客中出现多次了,那是因为这张图太经典了。图中有清晰的网络模型划分,因此很容易看到数据包在经过某条链时所处的层次 我们知道iptables只处理IP数据包(IP/PORT/SNAT/DNAT/…),而ebtables只工作在链路层Link Layer处理以太网帧(比如修改源/目mac地址)。图中用有颜色的长方形方框表示iptables或ebtables的表和链,绿色小方框表示network level,即iptables的表和链。蓝色小方框表示bridge level,即ebtables的表和链,由于处理以太网帧相对简单,因此链路层的蓝色小方框相对较少。 我们还注意到一些代表iptables表和链的绿色小方框位于链路层,这是因为bridge_nf代码的作用(从2.6 kernel开始),bridge_nf的引入是为了解决在链路层Bridge中处理IP数据包的问题(默认不会处理,需要通过内核参数开启),那为什么要在链路层Bridge中处理IP数据包,而不等数据包通过网络层时候再处理呢,这是因为不是所有的数据包都一定会通过网络层,那些目的地址非localhost的需要被Bridge转发的数据包就不会进入网络层。bridge_nf代码有时候会引起困惑,就像我们在图中看到的那样,iptables的表和链(绿色小方框)跑到了链路层,netfilter文档ebtables/iptables interaction on a Linux-based bridge对此也有说明 The br-nf code makes […]