交换机调用ACL时候的inbound和outbound该怎么用
我们知道，简单的ACL（访问控制列表）配置以后，通常在物理接口或者vlanif虚接口下调用，但是我们时常不明白，到底什么时候该用inbound，什么时候该用outbound，下面是我自己简单的理解。
一：物理接口下调用
[CORE1]acl 3001
[CORE1-acl-adv-3001]rule deny ip source 192.168.10.253 0 destination 192.168.10.
252 0
[CORE1-acl-adv-3001]quit
[CORE1]interface GigabitEthernet 0/0/2
[CORE1-GigabitEthernet0/0/2]display this
#
interface GigabitEthernet0/0/2
port link-type access
port default vlan 10
traffic-filter outbound acl 3000
#
[CORE1-GigabitEthernet0/0/2]traffic-filter inbound acl 3001
[CORE1-GigabitEthernet0/0/2]
我们总是要结合源地址和目的地址来分析，先看ACL，ip soure 192.168.10.0的网段，如果在G0/0/2接口调用，就是入方向，也就是inbound。因为源地址和我终端的接口是一致的，所以我数据要通过接口去访问其他端口。
如果outbound方向呢？如果我想调用在G0/0/3下面呢？
现在我们更改策略，然后在G0/0/3下outbound方向调用，结果也是可以的 。
为什么会这样呢？
总结
我们虽然改变了端口，改变了inbound或者outbound，但是策略没变。这是根本原因，也就是说破判断这个流量出入方向我们总是结合源地址和目的地址来看的。
ACL是这样的：
rule 5 deny ip source 192.168.10.253 0 destination 192.168.10.252 0
在G 0/0/2下面，2端口的终端也是源地址，那么我的终端通过我这个2接口这里过滤，那么就是inbound。
在G0/0/3下面，我变了出方向，但是规则，还是源地址这个访问目的这个，也就是只有出方向的时候，还是源地址访问这个目的地址才会被过滤。其实和inbound还是一样的。
只有10.253访问10.252的时候，在G2端口是数据进入的方向，在G3反而是出的方向，所以使用outbound。
二：vlanif下调用
vlanif下调用其实和物理端口调用有异曲同工之妙，不同vlan隔离互访的时候，
举个简单例子，有两个vlan，10，20,假如地址分别是10.1 20.1
规则是，rule deny ip sou 10.1 dest 20.1
在vlan10下面调用就是inbound
相反，想实现同样的目的，规则不变的情况下，我们在vlan20下面调用就是outbound。
你看，也是结合源和目的来看的，
vlan10下面调用，源地址也是10.1，所以是inbound
vlan20下面调用，源地址还是10.1，所以是outbound（因为只有源是10.1访问目的20.1，在vlan20那侧，才算是出方向）
成果
有以下规则，我们还是依然根据源地址和目的来判断
一：调用acl的源和目的地址全是一个网段的时候，且只有ACL中，只有source或者只有destnation时，如下。
rule 5 deny ip source 192.168.10.0 0.0.0.255
rule 10 deny ip destination 192.168.10.0 0.0.0.255
此时，无论在哪个接口，哪个vlanif下调用，inbound和outbound都可以实现访问控制
二：源和目的不是同一个网段的时候，且只有ACL中，只有source或者只有destnation时，举个例子
rule 5 deny ip source 192.168.10.0 0.0.0.255
//如果调用在10网段所属的vlan或者接口下，那么就是inbound
//如果调用在其他网段，都是outbound
rule 10 deny ip destination 192.168.20.0 0.0.0.255
//如果调用在20网段所属的vlan或者接口下，那么就是outbound
//如果调用在其他不论哪个网段，都是inbound
三：含有源地址和目的地址的acl规则，我们就按他的出入方向来判断调用的方向即可。
————————————————
版权声明：本文为CSDN博主「疏散一小生」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/NeverGUM/article/details/105400087
