|
|
<h1><center>路由控制与路由策略</center></h1>
|
|
|
|
|
|
> 作者：行癫
|
|
|
|
|
|
------
|
|
|
|
|
|
<h3>第一节：ACL原理与配置</h3>
|
|
|
|
|
|
<h4>一：ACL技术概述</h4>
|
|
|
|
|
|
<h5>1.技术背景</h5>
|
|
|
|
|
|
某公司为保证财务数据安全，禁止研发部门访问财务服务器，但总裁办公室不受限制
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216195558207.png" alt="image-20220216195558207" style="zoom:80%;" />
|
|
|
|
|
|
**随着网络的飞速发展，网络安全和网络服务质量QoS（Quality of Service）问题日益突出**
|
|
|
|
|
|
园区重要服务器资源被随意访问，园区机密信息容易泄露，造成安全隐患
|
|
|
|
|
|
Internet病毒肆意侵略园区内网，内网环境的安全性堪忧
|
|
|
|
|
|
网络带宽被各类业务随意挤占，服务质量要求最高的语音、视频业务的带宽得不到保障，造成用户体验差
|
|
|
|
|
|
以上种种问题，都对正常的网络通信造成了很大的影响。因此，提高网络安全性和服务质量迫在眉睫，我们需要对网络进行控制。比如，需要借助一个工具帮助实现一些流量的过滤
|
|
|
|
|
|
<h5>2.ACL概述</h5>
|
|
|
|
|
|
ACL是由一系列Permit和Deny语句组成的、有序规则的列表
|
|
|
|
|
|
ACL是一个匹配工具，能够对报文进行匹配和区分
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216195913418.png" alt="image-20220216195913418" style="zoom: 80%;" />
|
|
|
|
|
|
**ACL应用**
|
|
|
|
|
|
匹配IP流量
|
|
|
|
|
|
在Traffic-filter中被调用
|
|
|
|
|
|
在NAT中被调用
|
|
|
|
|
|
在防火墙的策略部署中被调用
|
|
|
|
|
|
在QoS中被调用
|
|
|
|
|
|
通过ACL可以实现对网络中报文流的精确识别和控制，达到控制网络访问行为、防止网络攻击和提高网络带宽利用率的目的，从而切实保障网络环境的安全性和网络服务质量的可靠性
|
|
|
|
|
|
ACL是由permit或deny语句组成的一系列有顺序的规则的集合；它通过匹配报文的相关字段实现对报文的分类
|
|
|
|
|
|
ACL是能够匹配一个IP数据包中的源IP地址、目的IP地址、协议类型、源目的端口等元素的基础性工具；ACL还能够用于匹配路由条目
|
|
|
|
|
|
<h4>二：ACL的基本概念及其工作原理</h4>
|
|
|
|
|
|
<h5>1.ACL的组成</h5>
|
|
|
|
|
|
ACL由若干条permit或deny语句组成，每条语句就是该ACL的一条规则，每条语句中的permit或deny就是与这条规则相对应的处理动作
|
|
|
|
|
|
|
|
|
|
|
|
**ACL的组成：**
|
|
|
|
|
|
ACL编号：在网络设备上配置ACL时，每个ACL都需要分配一个编号，称为ACL编号，用来标识ACL
|
|
|
|
|
|
规则：前面提到了，一个ACL通常由若干条“permit/deny”语句组成，每条语句就是该ACL的一条规则
|
|
|
|
|
|
规则编号：每条规则都有一个相应的编号，称为规则编号，用来标识ACL规则。可以自定义，也可以系统自动分配。ACL规则的编号范围是0～4294967294，所有规则均按照规则编号从小到大进行排序
|
|
|
|
|
|
动作：每条规则中的permit或deny，就是与这条规则相对应的处理动作。permit指“允许”，deny指“拒绝”，但是ACL一般是结合其他技术使用，不同的场景，处理动作的含义也有所不同
|
|
|
|
|
|
匹配项：ACL定义了极其丰富的匹配项。例子中体现的源地址，ACL还支持很多其他规则匹配项。例如，二层以太网帧头信息（如源MAC、目的MAC、以太帧协议类型）、三层报文信息（如目的地址、协议类型）以及四层报文信息（如TCP/UDP端口号）等
|
|
|
|
|
|
<h5>2.规则编号</h5>
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216200458258.png" alt="image-20220216200458258" style="zoom:80%;" />
|
|
|
|
|
|
**规则编号和步长的概念：**
|
|
|
|
|
|
规则编号：每条规则都有一个相应的编号，称为规则编号，用来标识ACL规则。可以自定义，也可以系统自动分配
|
|
|
|
|
|
步长：系统自动为ACL规则分配编号时，每个相邻规则编号之间会有一个差值，这个差值称为“步长”。缺省步长为5，所以规则编号就是5/10/15…以此类推
|
|
|
|
|
|
如果手工指定了一条规则，但未指定规则编号，系统就会使用大于当前ACL内最大规则编号且是步长整数倍的最小整数作为规则编号
|
|
|
|
|
|
步长可以调整，如果将步长改为2，系统则会自动从当前步长值开始重新排列规则编号，规则编号就变成2、4、6…
|
|
|
|
|
|
<h5>3.通配符</h5>
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216200707595.png" alt="image-20220216200707595" style="zoom:80%;" />
|
|
|
|
|
|
当进行IP地址匹配的时候，后面会跟着32位掩码位，这32位称为通配符
|
|
|
|
|
|
通配符，也是点分十进制格式，换算成二进制后，“0”表示“匹配”，“1”表示“不关心”
|
|
|
|
|
|
**具体看下这2条规则：**
|
|
|
|
|
|
rule 5: 拒绝源IP地址为10.1.1.1报文通过——因为通配符为全0，所以每一位都要严格匹配，因此匹配的是主机IP地址10.1.1.1
|
|
|
|
|
|
rule 15:允许源IP地址为10.1.1.0/24网段地址的报文通过——因为通配符：0.0.0.11111111，后8位为1，表示不关心，因此10.1.1.xxxxxxxx 的后8位可以为任意值，所以匹配的是10.1.1.0/24网段
|
|
|
|
|
|
**如果要精确匹配192.168.1.1/24这个IP地址对应的网段地址，通配符是多少**
|
|
|
|
|
|
可以得出：网络位需要严格匹配，主机位无所谓，因此通配符为“0.0.0.255
|
|
|
|
|
|
**匹配192.168.1.0/24这个子网中的奇数IP地址，例如：192.168.1.1、192.168.1.3、192.168.1.5等**
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216200953851.png" alt="image-20220216200953851" style="zoom:80%;" />
|
|
|
|
|
|
如果想匹配192.168.1.0/24网段中的奇数IP地址，通配符该怎么写呢？
|
|
|
|
|
|
我们先来看一看，奇数IP地址都有哪些：192.168.1.1、192.168.1.5、192.168.1.11……
|
|
|
|
|
|
后八位写成二进制：192.168.1.00000001、192.168.1.00000101、192.168.1.00001011……
|
|
|
|
|
|
可以看出共同点：最后8位的高7位是任意值，最低位固定为1，因此答案是：192.168.1.1 0.0.0.254（0.0.0.11111110）
|
|
|
|
|
|
这就得出了通配符的一个特点：通配符中的1或者0是可以不连续的
|
|
|
|
|
|
**还有两个特殊的通配符：**
|
|
|
|
|
|
当通配符全为0来匹配IP地址时，表示精确匹配某个IP地址
|
|
|
|
|
|
当通配符全为1来匹配0.0.0.0地址时，表示匹配了所有IP地址
|
|
|
|
|
|
<h5>4.ACL的分类与标识</h5>
|
|
|
|
|
|
**基本ACL规则定义方式的分类**
|
|
|
|
|
|
|
|
|
|
|
|
**基于ACL标识方法的分类**
|
|
|
|
|
|
|
|
|
|
|
|
**基于ACL规则定义方式的划分，可分为：**
|
|
|
|
|
|
基本ACL、高级ACL、二层ACL、用户自定义ACL和用户ACL
|
|
|
|
|
|
**基于ACL标识方法的划分，则可分为：**
|
|
|
|
|
|
数字型ACL和命名型ACL
|
|
|
|
|
|
**注意：**
|
|
|
|
|
|
用户在创建ACL时可以为其指定编号，不同的编号对应不同类型的ACL。同时，为了便于记忆和识别，用户还可以创建命名型ACL，即在创建ACL时为其设置名称。命名型ACL，也可以是“名称 数字”的形式，即在定义命名型ACL时，同时指定ACL编号。如果不指定编号，系统则会自动为其分配一个数字型ACL的编号
|
|
|
|
|
|
<h5>5.基本ACL与高级ACL</h5>
|
|
|
|
|
|
**基本ACL**
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216201530386.png" alt="image-20220216201530386" style="zoom:80%;" />
|
|
|
|
|
|
主要针对IP报文的源IP地址进行匹配，基本ACL的编号范围是2000-2999
|
|
|
|
|
|
比如这个例子，创建的是acl 2000，就意味着创建的是基本ACL
|
|
|
|
|
|
**高级ACL**
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216201554259.png" alt="image-20220216201554259" style="zoom:80%;" />
|
|
|
|
|
|
可以根据IP报文中的源IP地址、目的IP地址、协议类型，TCP或UDP的源目端口号等元素进行匹配，可以理解为：基本ACL是高级ACL的一个子集，高级ACL可以比基本ACL定义出更精确、更复杂、更灵活的规则
|
|
|
|
|
|
<H5>6.ACL的匹配机制</h5>
|
|
|
|
|
|
|
|
|
|
|
|
**ACL的匹配机制概括来说就是：**
|
|
|
|
|
|
配置ACL的设备接收报文后，会将该报文与ACL中的规则逐条进行匹配，如果不能匹配上，就会继续尝试去匹配下一条规则
|
|
|
|
|
|
一旦匹配上，则设备会对该报文执行这条规则中定义的处理动作，并且不再继续尝试与后续规则匹配
|
|
|
|
|
|
**匹配流程：首先系统会查找设备上是否配置了ACL**
|
|
|
|
|
|
如果ACL不存在，则返回ACL匹配结果为：不匹配
|
|
|
|
|
|
如果ACL存在，则查找设备是否配置了ACL规则
|
|
|
|
|
|
如果规则不存在，则返回ACL匹配结果为：不匹配
|
|
|
|
|
|
如果规则存在，则系统会从ACL中编号最小的规则开始查找
|
|
|
|
|
|
如果匹配上了permit规则，则停止查找规则，并返回ACL匹配结果为：匹配（允许）
|
|
|
|
|
|
如果匹配上了deny规则，则停止查找规则，并返回ACL匹配结果为：匹配（拒绝）
|
|
|
|
|
|
如果未匹配上规则，则继续查找下一条规则，以此循环。如果一直查到最后一条规则，报文仍未匹配上，则返回ACL匹配结果为：不匹配
|
|
|
|
|
|
**从整个ACL匹配流程可以看出，报文与ACL规则匹配后，会产生两种匹配结果：“匹配”和“不匹配”**
|
|
|
|
|
|
匹配（命中规则）：指存在ACL，且在ACL中查找到了符合匹配条件的规则。不论匹配的动作是“permit”还是“deny”，都称为“匹配”，而不是只是匹配上permit规则才算“匹配”
|
|
|
|
|
|
不匹配（未命中规则）：指不存在ACL，或ACL中无规则，再或者在ACL中遍历了所有规则都没有找到符合匹配条件的规则。以上三种情况，都叫做“不匹配”
|
|
|
|
|
|
**匹配原则：一旦命中即停止匹配**
|
|
|
|
|
|
<h5>7.ACL的匹配顺序及匹配结果</h5>
|
|
|
|
|
|
**配置顺序（config模式）**
|
|
|
|
|
|
系统按照ACL规则编号从小到大的顺序进行报文匹配，规则编号越小越容易被匹配
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216203258381.png" alt="image-20220216203258381" style="zoom:80%;" />
|
|
|
|
|
|
一条ACL可以由多条“deny或permit”语句组成，每一条语句描述一条规则，这些规则可能存在包含关系，也可能有重复或矛盾的地方，因此ACL的匹配顺序是十分重要的
|
|
|
|
|
|
华为设备支持两种匹配顺序：自动排序（auto模式）和配置顺序（config模式）。缺省的ACL匹配顺序是config模式
|
|
|
|
|
|
自动排序，是指系统使用“深度优先”的原则，将规则按照精确度从高到低进行排序，并按照精确度从高到低的顺序进行报文匹配
|
|
|
|
|
|
配置顺序，系统按照ACL规则编号从小到大的顺序进行报文匹配，规则编号越小越容易被匹配
|
|
|
|
|
|
如果后面又添加了一条规则，则这条规则会被加入到相应的位置，报文仍然会按照从小到大的顺序进行匹配
|
|
|
|
|
|
**匹配结果：**
|
|
|
|
|
|
首先理解ACL 2000的含义：
|
|
|
|
|
|
rule 1：允许源IP地址为192.168.1.1的报文
|
|
|
|
|
|
rule 2：允许源IP地址为192.168.1.2的报文
|
|
|
|
|
|
rule 3：拒绝源IP地址为192.168.1.2的报文
|
|
|
|
|
|
rule 4：允许其他所有IP地址的报文
|
|
|
|
|
|
当源IP地址为192.168.1.3的报文经过配置了ACL的设备时：
|
|
|
|
|
|
首先查看rule 1，发现不匹配
|
|
|
|
|
|
继续查看rule 2，发现仍不匹配
|
|
|
|
|
|
继续查看rule 3，发现匹配，且是“拒绝”动作
|
|
|
|
|
|
**注意：**
|
|
|
|
|
|
ACL技术总是与其他技术结合在一起使用的，因此，所结合的技术不同，“允许(permit)”及“拒绝 (deny)”的内涵和作用也会不同。例如，当ACL技术与流量过滤技术结合使用时，permit就是“允许通行”的意思，deny就是“拒绝通行”的意思
|
|
|
|
|
|
<h5>8.ACL的匹配位置</h5>
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216203745180.png" alt="image-20220216203745180" style="zoom:80%;" />
|
|
|
|
|
|
**入站（Inbound）及出站（Outbound）方向**
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216203848505.png" alt="image-20220216203848505" style="zoom:80%;" />
|
|
|
|
|
|
<h4>三：ACL的基础配置及应用</h4>
|
|
|
|
|
|
<h5>1.基本ACL的基础配置命令</h5>
|
|
|
|
|
|
|
|
|
|
|
|
**创建基本ACL**
|
|
|
|
|
|
[Huawei] **acl** [ **number** ] *acl-number* [ **match-order config** ]
|
|
|
|
|
|
*acl-number*：指定访问控制列表的编号
|
|
|
|
|
|
**match-order config**：指定ACL规则的匹配顺序，config表示配置顺序
|
|
|
|
|
|
[Huawei] **acl name** *acl-name* { **basic** | *acl-number* } [ **match-order config** ]
|
|
|
|
|
|
*acl-name*：指定创建的ACL的名称
|
|
|
|
|
|
**basic**：指定ACL的类型为基本ACL
|
|
|
|
|
|
**配置基本ACL规则**
|
|
|
|
|
|
[Huawei-acl-basic-2000] **rule** [ *rule-id* ] { **deny** | **permit** } [ **source** { *source-address* *source-wildcard* | **any** } | **time-range** *time-name* ]
|
|
|
|
|
|
*rule-id*：指定ACL的规则ID
|
|
|
|
|
|
**deny**：指定拒绝符合条件的报文
|
|
|
|
|
|
**permit**：指定允许符合条件的报文
|
|
|
|
|
|
**source** { *source-address source-wildcard* | **any** }：指定ACL规则匹配报文的源地址信息。如果不配置，表示报文的任何源地址都匹配
|
|
|
|
|
|
*source-address*：指定报文的源地址
|
|
|
|
|
|
*source-wildcard*：指定源地址通配符
|
|
|
|
|
|
**any**：表示报文的任意源地址。相当于source-address为0.0.0.0或者source wildcard为255.255.255.255
|
|
|
|
|
|
**time-range** *time-name*：指定ACL规则生效的时间段。其中，time-name表示ACL规则生效时间段名称。如果不指定时间段，表示任何时间都生效
|
|
|
|
|
|
<h5>2.使用基本ACL过滤数据流量</h5>
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216204324263.png" alt="image-20220216204324263" style="zoom:80%;" />
|
|
|
|
|
|
**配置需求**
|
|
|
|
|
|
在Router上部署基本ACL后，ACL将试图穿越Router的源地址为192.168.1.0/24网段的数据包过滤掉，并放行其他流量，从而禁止192.168.1.0/24网段的用户访问Router右侧的服务器网络
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216204503469.png" alt="image-20220216204503469" style="zoom:80%;" />
|
|
|
|
|
|
**配置思路：**
|
|
|
|
|
|
配置基本ACL和流量过滤，使设备可以对特定网段的报文进行过滤
|
|
|
|
|
|
**配置步骤：**
|
|
|
|
|
|
如图完成路由器的IP地址和路由相关配置
|
|
|
|
|
|
创建基本ACL 2000并配置ACL规则，拒绝192.168.1.0/24网段的报文通过，允许其他网段的报文通过
|
|
|
|
|
|
配置流量过滤
|
|
|
|
|
|
**注意**
|
|
|
|
|
|
**traffic-filter**命令，用来在接口上配置基于ACL对报文进行过滤
|
|
|
|
|
|
命令格式：**traffic-filter** { **inbound** | **outbound** } **acl** { *acl-number* | **name** acl *name* }
|
|
|
|
|
|
**inbound**：指定在接口入方向上配置报文过滤
|
|
|
|
|
|
**outbound**：指定在接口出方向上配置报文过滤
|
|
|
|
|
|
**acl**：指定基于IPv4 ACL对报文进行过滤
|
|
|
|
|
|
<h5>3.高级ACL的基础配置命令</h5>
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216204719470.png" alt="image-20220216204719470" style="zoom:80%;" />
|
|
|
|
|
|
[Huawei] **acl** [ **number** ] *acl-number* [ **match-order config** ]
|
|
|
|
|
|
*acl-number*：指定访问控制列表的编号
|
|
|
|
|
|
**match-order config**：指定ACL规则的匹配顺序，config表示配置顺序
|
|
|
|
|
|
[Huawei] **acl name** *acl-name* { **advance** | *acl-number* } [ **match-order config** ]
|
|
|
|
|
|
*acl-name*：指定创建的ACL的名称
|
|
|
|
|
|
**advance**：指定ACL的类型为高级ACL
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216204836485.png" alt="image-20220216204836485" style="zoom:80%;" />
|
|
|
|
|
|
**当参数protocol为IP时：**
|
|
|
|
|
|
**rule** [ *rule-id* ] { **deny** | **permit** } **ip** [ **destination** { *destination-address* *destination-wildcard* | **any** } | **source** { *source-address source-wildcard* | **any** } | **time-range** *time-name* | [ **dscp** *dscp* | [ **tos** *tos* | **precedence** *precedence* ] ] ]
|
|
|
|
|
|
**ip** ：指定ACL规则匹配报文的协议类型为IP
|
|
|
|
|
|
**destination** { *destination-address destination-wildcard* | **any** }：指定ACL规则匹配报文的目的地址信息。如果不配置，表示报文的任何目的地址都匹配
|
|
|
|
|
|
**dscp** *dscp*：指定ACL规则匹配报文时，区分服务代码点（Differentiated Services Code Point），取值为：0~63
|
|
|
|
|
|
**tos** *tos*：指定ACL规则匹配报文时，依据服务类型字段进行过滤，取值为：0~15
|
|
|
|
|
|
**precedence** *precedence*：指定ACL规则匹配报文时，依据优先级字段进行过滤。precedence表示优先级字段值，取值为：0~7
|
|
|
|
|
|
**当参数protocol为TCP时：**
|
|
|
|
|
|
**rule** [ *rule-id* ] { **deny** | **permit** } { *protocol-number* | **tcp** } [ **destination**{ *destination-address destination-wildcard* | **any** } | **destination-port** { **eq** *port* | **gt** *port* | **lt** *port* | **range** *port-start port-end* } | **source** { *source-address source*wildcard | **any** } | **source-port** { **eq** port | **gt** port | **lt** port | **range** port-start port *end* } | **tcp-flag** { **ack** | **fin** | **syn** } | **time-range** *time-name* ]
|
|
|
|
|
|
*protocol-number* | **tcp**：指定ACL规则匹配报文的协议类型为TCP。可以采用数值6表示指定TCP协议
|
|
|
|
|
|
**destination-port** { **eq** *port* | **gt** *port* | **lt** *port* | **range** *port-start port-end*}：指定ACL规则匹配报文的UDP或者TCP报文的目的端口，仅在报文协议是TCP或 者UDP时有效。如果不指定，表示TCP/UDP报文的任何目的端口都匹配
|
|
|
|
|
|
− **eq** *port*：指定等于目的端口
|
|
|
|
|
|
− **gt** *port*：指定大于目的端口
|
|
|
|
|
|
− **lt** *port*：指定小于目的端口
|
|
|
|
|
|
− **range** *port-start port-end*：指定源端口的范围
|
|
|
|
|
|
**tcp-flag**：指定ACL规则匹配报文的TCP报文头中SYN Flag
|
|
|
|
|
|
<h5>4.使用高级ACL限制不同网段的用户互访</h5>
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216205247527.png" alt="image-20220216205247527" style="zoom:80%;" />
|
|
|
|
|
|
**配置需求**
|
|
|
|
|
|
某公司通过Router实现各部门之间互连，为方管理网络，管理员为公司的研发部门和市场部门规划了两个网段IP地址
|
|
|
|
|
|
现要求Router能够限制两个网段之间互访，防止公司机密泄露
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216205436841.png" alt="image-20220216205436841" style="zoom:80%;" />
|
|
|
|
|
|
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220216205702224.png" alt="image-20220216205702224" style="zoom:80%;" />
|
|
|
|
|
|
**配置思路：**
|
|
|
|
|
|
配置高级ACL和流量过滤，使设备可以对研发部与市场部互访的报文进行过滤
|
|
|
|
|
|
**配置步骤：**
|
|
|
|
|
|
如图完成路由器的IP地址和路由的相关配置
|
|
|
|
|
|
创建高级ACL 3001并配置ACL规则，拒绝研发部访问市场部的报文通过
|
|
|
|
|
|
创建高级ACL 3002并配置ACL规则，拒绝市场部访问研发部的报文通过
|
|
|
|
|
|
由于研发部和市场部互访的流量分别从接口GE0/0/1和GE0/0/2进入Router，所以在接口GE0/0/1和GE0/0/2的入方向配置流量过滤
|
|
|
|
|
|
**注意：**
|
|
|
|
|
|
**traffic-filter**命令，用来在接口上配置基于ACL对报文进行过滤
|
|
|
|
|
|
命令格式：**traffic-filter** { **inbound** | **outbound** } **acl** { *acl-number* | **name** *acl* *name* }
|
|
|
|
|
|
**inbound**：指定在接口入方向上配置报文过滤
|
|
|
|
|
|
**outbound**：指定在接口出方向上配置报文过滤
|
|
|
|
|
|
**acl**：指定基于IPv4 ACL对报文进行过滤
|
|
|
|
|
|
<h3>第二节：路由策略与路由控制</h3>
|
|
|
|
|
|
<h4>一：路由控制概述</h4>
|
|
|
|
|
|
<h5>1.技术背景</h5>
|
|
|
|
|
|
|
|
|
|
|
|
R1上将业务A、B、C的网段路由引入时希望不引入业务C网段路由，同时R3上将OSPF路由引入到IS-IS中时，同样只希望引入B业务网段路由，此时需要一个工具在引入路由时进行限制
|
|
|
|
|
|
<h5>2.路由控制概述</h5>
|
|
|
|
|
|
路由控制可以通过路由策略（Route-Policy）实现，路由策略应用灵活而广泛，有以下几种常见方式：
|
|
|
|
|
|
控制路由的发布：通过路由策略对发布的路由进行过滤，只发布满足条件的路由
|
|
|
|
|
|
控制路由的接收：通过路由策略对接收的路由进行过滤，只接收满足条件的路由
|
|
|
|
|
|
控制路由的引入：通过路由策略控制从其他路由协议引入的路由条目，只有满足条件的路由才会被引入
|
|
|
|
|
|
|
|
|
|
|
|
<h4>二：路由控制工具</h4>
|
|
|
|
|
|
<h5>1.匹配工具1：访问控制列表</h5>
|
|
|
|
|
|
访问控制列表（Access Control List，ACL）是一个匹配工具，能够对报文及路由进行匹配和区分
|
|
|
|
|
|
ACL由若干条permit或deny语句组成。每条语句就是该ACL的一条规则，每条语句中的permit或deny就是与这条规则相对应的处理动作
|
|
|
|
|
|
|
|
|
|
|
|
**ACL的匹配机制**
|
|
|
|
|
|
|
|
|
|
|
|
**ACL的匹配顺序及匹配结果**
|
|
|
|
|
|
配置顺序（config模式）
|
|
|
|
|
|
系统按照ACL规则编号从小到大的顺序进行报文匹配，规则编号越小越容易被匹配
|
|
|
|
|
|
|
|
|
|
|
|
**常用匹配举例**
|
|
|
|
|
|
|
|
|
|
|
|
<h5>2.匹配工具2：IP前缀列表</h5>
|
|
|
|
|
|
IP前缀列表（IP-Prefix List）是将路由条目的网络地址、掩码长度作为匹配条件的过滤器，可在各路由协议发布和接收路由时使用
|
|
|
|
|
|
不同于ACL，IP-Prefix List能够同时匹配IP地址前缀长度以及掩码长度，增强了匹配的精确度
|
|
|
|
|
|
|
|
|
|
|
|
ip-prefix-name：地址前缀列表名称
|
|
|
|
|
|
序号：本匹配项在地址前缀列表中的序号，匹配时根据序号从小到大进行顺序匹配
|
|
|
|
|
|
动作：permit/deny，地址前缀列表的匹配模式为允许/拒绝，表示匹配/不匹配
|
|
|
|
|
|
IP网段与掩码：匹配路由的网络地址，以及限定网络地址的前多少位需严格匹配
|
|
|
|
|
|
掩码范围：匹配路由前缀长度，掩码长度的匹配范围 mask-length<=greater-equal-value<=less-equal-value<=32
|
|
|
|
|
|
**IP-Prefix的匹配机制**
|
|
|
|
|
|
|
|
|
|
|
|
**IP-Prefix的匹配示例**
|
|
|
|
|
|
|
|
|
|
|
|
**IP-Prefix的基础配置命令**
|
|
|
|
|
|
|
|
|
|
|
|
ip-prefix-name：指定地址前缀列表的名称
|
|
|
|
|
|
index index-number：指定本匹配项在地址前缀列表中的序号
|
|
|
|
|
|
permit：指定地址前缀列表的匹配模式为允许
|
|
|
|
|
|
deny：指定地址前缀列表的匹配模式为拒绝
|
|
|
|
|
|
ipv4-address mask-length：指定IP地址和指定掩码长度
|
|
|
|
|
|
greater-equal greater-equal-value：指定掩码长度匹配范围的下限
|
|
|
|
|
|
less-equal less-equal-value：指定掩码长度匹配范围的上限
|
|
|
|
|
|
**IP-Prefix的配置举例**
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h4>三：路由策略工具</h4>
|
|
|
|
|
|
<h5>1.策略工具1：Filter-Policy</h5>
|
|
|
|
|
|
Filter-Policy（过滤-策略）是一个很常用的路由信息过滤工具，能够对接收、发布、引入的路由进行过滤，可应用于IS-IS、OSPF、BGP等协议
|
|
|
|
|
|
|
|
|
|
|
|
如图所示，R1、R2、R3之间运行BGP路由协议，路由在各个设备之间传递，当需要根据实际需求过滤某些路由信息的时候可以使用Filter-Policy实现
|
|
|
|
|
|
**Filter-Policy在距离矢量路由协议中的应用**
|
|
|
|
|
|
在距离矢量路由协议中，设备之间传递的是路由信息，如果需要对这种路由信息进行某种过滤，可以使用Filter-Policy实现，出方向和入方向的生效位置如图所示
|
|
|
|
|
|
|
|
|
|
|
|
距离矢量协议是基于路由表生成路由的，因此过滤器会影响从邻居接收的路由和向邻居发布的路由
|
|
|
|
|
|
如果要过滤掉上游设备到下游设备的路由，只需要在上游设备配置filter-policy export或者在下游设备上配置filter-policy import
|
|
|
|
|
|
**Filter-Policy在链路状态路由协议中的应用**
|
|
|
|
|
|
在链路状态路由协议中，各路由设备之间传递的是LSA信息，然后设备根据LSA汇总成的LSDB信息计算出路由表。但是Filter-Policy只能过滤路由信息，无法过滤LSA
|
|
|
|
|
|
|
|
|
|
|
|
OSPF把网络中所泛洪的LSA存储到自己的LSDB中，并且运行SPF算法，计算出一颗以自己为根，无环的最短路径树，Filter-Policy对OSPF计算出来的路由（加载到路由表之前）进行过滤，而不会对LSA进行过滤
|
|
|
|
|
|
**Filter-Policy的基础配置命令**
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**OSPF中使用Filter-Policy**
|
|
|
|
|
|
|
|
|
|
|
|
OSPF的路由信息记录在LSDB中，filter-policy import命令实际上是对OSPF计算出来的路由进行过滤，不是对发布和接收的LSA进行过滤
|
|
|
|
|
|
filter-policy export命令通过指定protocol或process-id对特定的某一种协议或某一进程的路由进行过滤。如果没有指定protocol和process-id，则OSPF将对所有引入的路由信息进行过滤
|
|
|
|
|
|
**IS-IS中使用Filter-Policy**
|
|
|
|
|
|
|
|
|
|
|
|
IS-IS的路由表项需要被成功下发到IP路由表中，才能用来指导IP报文转发。如果IS-IS路由表中有到达某个目的网段的路由，但是并不希望将该路由下发到IP路由表中，可以使用filter-policy import命令结合基本ACL、IP-Prefix、路由策略等方式，只将部分IS-IS路由下发到IP路由表中
|
|
|
|
|
|
**BGP中使用Filter-Policy**
|
|
|
|
|
|
|
|
|
|
|
|
<h5>2.策略工具2：Route-Policy</h5>
|
|
|
|
|
|
Route-Policy是一个策略工具，用于过滤路由信息，以及为过滤后的路由信息设置路由属性
|
|
|
|
|
|
一个Route-Policy由一个或多个节点（Node）构成，每个节点都可以是一系列条件语句（匹配条件）以及执行语句（执行动作）的集合，这些集合按照编号从小到大的顺序排列
|
|
|
|
|
|
|
|
|
|
|
|
当使用Route-Policy时，Node的值小的节点先进行匹配。一个节点匹配成功后，路由将不再匹配其他节点。全部节点匹配失败后，路由将被过滤
|
|
|
|
|
|
**Route-Policy的组成**
|
|
|
|
|
|
一个Route-Policy由一个或多个节点构成，每个节点包括多个if-match和apply子句
|
|
|
|
|
|
|
|
|
|
|
|
permit或deny：指定Route-Policy节点的匹配模式为允许或拒绝
|
|
|
|
|
|
node：指定Route-Policy的节点号。整数形式，取值范围是0～65535
|
|
|
|
|
|
if-match子句：定义该节点的匹配条件
|
|
|
|
|
|
apply子句：定义针对被匹配路由执行的操作
|
|
|
|
|
|
**Route-Policy的匹配顺序**
|
|
|
|
|
|
路由策略使用不同的匹配条件和匹配模式选择路由和改变路由属性
|
|
|
|
|
|
|
|
|
|
|
|
个路由策略中包含N（N>=1）个节点（Node）。路由进入路由策略后，按节点序号从小到大依次检查各个节点是否匹配。匹配条件由If-match子句定义
|
|
|
|
|
|
当路由与该节点的所有If-match子句都匹配成功后，进入匹配模式选择，不再匹配其他节点。匹配模式分permit和deny两种，permit：路由将被允许通过，并且执行该节点的apply子句对路由信息的一些属性进行设置，deny：路由将被拒绝通过
|
|
|
|
|
|
当路由与该节点的任意一个If-match子句匹配失败后，进入下一节点。如果和所有节点都匹配失败，路由信息将被拒绝通过
|
|
|
|
|
|
**Route-Policy的基础配置命令**
|
|
|
|
|
|
|
|
|
|
|
|
命令：route-policy route-policy-name { permit | deny } node node
|
|
|
|
|
|
permit：指定Route-Policy节点的匹配模式为允许。如果路由与节点所有的if-match子句匹配成功，则执行此节点apply子句；否则，进行下一节点
|
|
|
|
|
|
deny：指定Route-Policy节点的匹配模式为拒绝。如果路由与节点所有的if-match子句匹配成功，则该路由将被拒绝通过；否则进行下一节点
|
|
|
|
|
|
node node：指定Route-Policy的节点号。当使用Route-Policy时，node的值小的节点先进行匹配。一个节点匹配成功后，路由将不再匹配其他节点。全部节点匹配失败后，路由将被过滤。整数形式，取值范围是0～65535
|
|
|
|
|
|
|
|
|
|
|
|
apply子句用来为路由策略指定动作，用来设置匹配成功的路由的属性。在一个节点中，如果没有配置apply子句，则该节点仅起过滤路由的作用。如果配置一个或多个apply子句，则通过节点匹配的路由将执行所有apply子句
|
|
|
|
|
|
<h4>四：路由控制案例</h4>
|
|
|
|
|
|
<h5>1.对接收的路由进行过滤</h5>
|
|
|
|
|
|
|
|
|
|
|
|
R1、R2、R3运行OSPF，R1将192.168.1.0/24、192.168.2.0/24、192.168.3.0/24和192.168.4.0/24宣告进OSPF
|
|
|
|
|
|
现在要求R2不能访问R1上192.168.1.0/24网段，但是R3可以正常访问
|
|
|
|
|
|
为实现该需求，可以在R2上对接收的路由使用Filter-Policy进行过滤
|
|
|
|
|
|
**配置**
|
|
|
|
|
|
```shell
|
|
|
[R2] ip ip-prefix in index 10 permit 192.168.2.0 24
|
|
|
[R2] ip ip-prefix in index 20 permit 192.168.3.0 24
|
|
|
[R2] ip ip-prefix in index 30 permit 192.168.4.0 24
|
|
|
|
|
|
[R2] ospf
|
|
|
[R2-ospf-1] filter-policy ip-prefix in import
|
|
|
```
|
|
|
|
|
|
通过Filter-Policy进行路由过滤，只影响本地的路由表，因此R3可以正常学习到192.168.1.0/24网段的路由
|
|
|
|
|
|
<h5>2.对发布的路由进行过滤</h5>
|
|
|
|
|
|
|
|
|
|
|
|
R1、R2、R3运行OSPF，R1将直连网段192.168.1.0/24、192.168.2.0/24、192.168.3.0/24和192.168.4.0/24引入OSPF
|
|
|
|
|
|
现在要求R2、R3只能学习到192.168.1.0/24网段的路由，学习不到其他三个网段的路由
|
|
|
|
|
|
为实现该需求，可以在R1上使用Filter-Policy对引入的路由在发布时进行过滤
|
|
|
|
|
|
**配置**
|
|
|
|
|
|
```shell
|
|
|
[R1] ip ip-prefix out index 10 permit 192.168.1.0 24
|
|
|
|
|
|
[R1] ospf
|
|
|
[R1-ospf-1] import-route direct
|
|
|
[R1-ospf-1] filter-policy ip-prefix out export
|
|
|
```
|
|
|
|
|
|
<h5>3.修改路由属性</h5>
|
|
|
|
|
|
|
|
|
|
|
|
R1、R2、R3运行OSPF，R1将直连网段192.168.1.0/24引入OSPF
|
|
|
|
|
|
现在要求R2、R3学到的OSPF路由192.168.1.0/24为external-type 1路由（默认为external-type 2路由）
|
|
|
|
|
|
为实现该需求，可以在R1上使用Route-Policy在引入路由时修改外部路由的类型为external-type 1
|
|
|
|
|
|
**配置**
|
|
|
|
|
|
```shell
|
|
|
[R1] ip ip-prefix external index 10 permit 192.168.1.0 24
|
|
|
|
|
|
[R1] route-policy RP permit node 10
|
|
|
[R1-route-policy] if-match ip-prefix external
|
|
|
[R1-route-policy] apply cost-type type-1
|
|
|
[R1-route-policy] quit
|
|
|
|
|
|
[R1] ospf
|
|
|
[R1-ospf-1] import-route direct route-policy RP
|
|
|
```
|
|
|
|
|
|
<h5>4.双点双向路由重发布</h5>
|
|
|
|
|
|
|
|
|
|
|
|
在边界路由器上把两个路由域的路由相互引入，称之为双向路由重发布
|
|
|
|
|
|
两个路由域存在两个边界路由器，并且都执行双向路由重分发，此时称为双点双向路由重发布
|
|
|
|
|
|
双点双向路由重发布是一种经典的路由模型，因单点的双向路由重发布缺乏冗余性，一旦单点的边界路由器故障，那么两个路由域之间的通信可能就会出现问题，因此在大型网络部署中一般采用双点双向路由重发布
|
|
|
|
|
|
双点双向重路由发布虽然增强了网络的可靠性，但是容易引发：次优路径、路由环路等问题
|
|
|
|
|
|
<h5>5.次优路径问题</h5>
|
|
|
|
|
|
|
|
|
|
|
|
**以10.1.1.0/24为例：**
|
|
|
|
|
|
R1将直连路由10.1.1.0/24引入到OSPF中
|
|
|
|
|
|
R2、R3执行双向路由重发布，R2先将10.1.1.0/24重发布到IS-IS中，R3将会学习到来自R4的IS-IS路由
|
|
|
|
|
|
对R3而言，IS-IS路由（优先级15）优于OSPF外部路由（优先级150），因此优选来自R4的IS-IS路由。后续R3访问10.1.1.0/24网段的路径为：R3->R4->R2->R1，这是次优路径
|
|
|
|
|
|
|
|
|
|
|
|
解决方案一：在R3的IS-IS进程内，通过Filter-Policy禁止来自R4的10.1.1.0/24路由加入本地路由表
|
|
|
|
|
|
**配置**
|
|
|
|
|
|
```shell
|
|
|
[R3] acl 2001
|
|
|
[R3-acl-basic-2001] rule 5 deny source 10.1.1.0 0
|
|
|
[R3-acl-basic-2001] rule 10 permit
|
|
|
|
|
|
[R3] isis
|
|
|
[R3-isis-1] filter-policy 2001 import
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
解决方案二：R3通过ACL匹配10.1.1.0/24路由，在Route-Policy中调用该条ACL，将匹配这条ACL的路由的优先级设置为14（优于IS-IS）。在OSPF视图下使用preference ase命令调用Route-Policy修改外部路由的优先级
|
|
|
|
|
|
**配置**
|
|
|
|
|
|
```shell
|
|
|
[R3]acl 2000
|
|
|
[R3-acl-basic-2000] rule permit source 10.1.1.0 0
|
|
|
[R3-acl-basic-2000] quit
|
|
|
[R3]route-policy hcip permit node 10
|
|
|
[R3-route-policy] if-match acl 2000
|
|
|
[R3-route-policy] apply preference 14
|
|
|
[R3-route-policy] quit
|
|
|
[R3]ospf 1
|
|
|
[R3-ospf-1] preference ase route-policy hcip
|
|
|
```
|
|
|
|
|
|
<h5>6.路由环路问题</h5>
|
|
|
|
|
|
|
|
|
|
|
|
**场景描述：**
|
|
|
|
|
|
R1将直连路由10.1.1.0/24引入到OSPF中
|
|
|
|
|
|
R1、R2、R3运行OSPF协议，10.1.1.0/24网段路由在全OSPF域内通告
|
|
|
|
|
|
R2执行了双向路由重发布
|
|
|
|
|
|
R2、R3、R4运行IS-IS协议， 10.1.1.0/24网段路由在全IS-IS域内通告
|
|
|
|
|
|
R3执行了双向路由重发布
|
|
|
|
|
|
10.1.1.0/24网段路由再次被通告进OSPF域内，形成路由环路
|
|
|
|
|
|
**解决方案：**
|
|
|
|
|
|
解决方案一：在R3的OSPF中引入IS-IS路由时，通过Route-Policy过滤掉10.1.1.0/24路由
|
|
|
|
|
|
**配置**
|
|
|
|
|
|
```shell
|
|
|
[R3] acl 2001
|
|
|
[R3-acl-basic-2001] rule 5 deny source 10.1.1.0 0
|
|
|
[R3-acl-basic-2001] rule 10 permit
|
|
|
|
|
|
[R3] route-policy RP permit node 10
|
|
|
[R3-route-policy] if-match 2001
|
|
|
[R3-route-policy] quit
|
|
|
|
|
|
[R3] ospf
|
|
|
[R3-ospf-1] import-route isis 1 route-policy RP
|
|
|
```
|
|
|
|
|
|
解决方案二：使用Tag实现有选择性地路由引入，在R2上将路由10.1.1.0/24从OSPF引入到IS-IS中时打上Tag 200，在R3上将IS-IS引入到OSPF中时，过滤携带Tag 200的路由
|
|
|
|
|
|
**配置**
|
|
|
|
|
|
```shell
|
|
|
[R2]acl 2000
|
|
|
[R2-acl-basic-2000]rule permit source 10.1.1.0 0
|
|
|
[R2-acl-basic-2000]quit
|
|
|
[R2]route-policy hcip permit node 10
|
|
|
[R2-route-policy]if-match acl 2000
|
|
|
[R2-route-policy]apply tag 200
|
|
|
[R2-route-policy]quit
|
|
|
[R2]isis 1
|
|
|
[R2-isis-1]import-route ospf route-policy hcip
|
|
|
```
|
|
|
|
|
|
```shell
|
|
|
[R3]route-policy hcip deny node 10
|
|
|
[R3-route-policy]if-match tag 200
|
|
|
[R3-route-policy]quit
|
|
|
[R3]route-policy hcip permit node 20
|
|
|
|
|
|
[R3]ospf 1
|
|
|
[R3-ospf-1]import-route isis route-policy hcip
|
|
|
```
|
|
|
|
|
|
在路由重发布的实际应用中，通过IP前缀进行路由匹配固然可行，但当网络规模较大时，配置工作量较大；通过Tag进行路由匹配可以极大简化配置工作量
|
|
|
|
|
|
<h3>第三节：流量过滤与转发路径控制</h3>
|
|
|
|
|
|
<h4>一：策略路由</h4>
|
|
|
|
|
|
<h5>1.策略路由技术背景</h5>
|
|
|
|
|
|
在某些场景中我们希望一些特定用户、特定业务的流量走指定的转发路径，而其余用户或业务的流量则依旧根据路由表进行转发
|
|
|
|
|
|
|
|
|
|
|
|
示例：双ISP接入的企业，想要实现内网网段1访问Internet通过ISP1、内网网段2访问Internet通过ISP2，该需求无法通过传统的路由技术实现
|
|
|
|
|
|
<h5>2.PBR介绍 - 基本概念</h5>
|
|
|
|
|
|
|
|
|
|
|
|
PBR（Policy-Based Routing，策略路由）：PBR使得网络设备不仅能够基于报文的目的IP地址进行数据转发，更能基于其他元素进行数据转发，例如源IP地址、源MAC地址、目的MAC地址、源端口号、目的端口号、VLAN-ID等等
|
|
|
|
|
|
用户还可以使用ACL匹配特定的报文，然后针对该ACL进行PBR部署
|
|
|
|
|
|
若设备部署了PBR，则被匹配的报文优先根据PBR的策略进行转发，即PBR策略的优先级高于传统路由表
|
|
|
|
|
|
<h5>3.PBR介绍 - 结构</h5>
|
|
|
|
|
|
|
|
|
|
|
|
PBR与Route-Policy类似，由多个节点组成，每个节点由匹配条件（条件语句）和执行动作（执行语句）组成
|
|
|
|
|
|
每个节点内可包含多个条件语句
|
|
|
|
|
|
节点内的多个条件语句之间的关系为“与”，即匹配所有条件语句才会执行本节点内的动作
|
|
|
|
|
|
节点之间的关系为“或”，PBR根据节点编号从小到大顺序执行，匹配当前节点将不会继续向下匹配
|
|
|
|
|
|
<h5>4.PBR介绍 - 命令语法</h5>
|
|
|
|
|
|
|
|
|
|
|
|
**PBR的节点匹配模式：**
|
|
|
|
|
|
permit表示对满足匹配条件的报文进行策略路由
|
|
|
|
|
|
deny表示对满足匹配条件的报文不进行策略路由
|
|
|
|
|
|
<h5>5.PBR与路由策略区别</h5>
|
|
|
|
|
|
| **名称** | **操作对象** | **描述** |
|
|
|
| ------------------------ | ------------ | ------------------------------------------------------------ |
|
|
|
| 路由策略（Route-Policy） | 路由信息 | 路由策略是一套用于对路由信息进行过滤、属性设置等操作的方法，通过对路由的操作或控制，来影响数据报文的转发路径 |
|
|
|
| PBR | 数据报文 | PBR直接对数据报文进行操作，通过多种手段匹配感兴趣的报文，然后执行丢弃或强制转发路径等操作 |
|
|
|
|
|
|
<h5>6.PBR的分类</h5>
|
|
|
|
|
|
|
|
|
|
|
|
接口PBR只对转发的报文起作用，对本地始发的报文无效
|
|
|
|
|
|
接口PBR调用在接口下，对接口的入方向报文生效。缺省情况下，设备按照路由表的下一跳进行报文转发，如果配置了接口PBR，则设备按照接口PBR指定的下一跳进行转发
|
|
|
|
|
|
|
|
|
|
|
|
本地PBR对本地始发的流量生效，如：本地始发的ICMP报文
|
|
|
|
|
|
本地PBR在系统视图调用
|
|
|
|
|
|
<h5>7.PBR典型应用场景</h5>
|
|
|
|
|
|
|
|
|
|
|
|
内网防火墙旁挂部署在核心交换机，为防护内网在核心交换机的三层接口上部署PBR，将来自外部网络的流量牵引到防火墙上进行安全检查，检查完的流量再发送回核心交换机，由核心交换机依据路由表转发到内网
|
|
|
|
|
|
将流量牵引到别的设备进行安全检查等类似的行为我们称之为“引流”，PBR是一种常见的引流工具
|
|
|
|
|
|
|
|
|
|
|
|
当企业存在多个网络出口时，若想指定部分网段访问Internet时的网络出口，可以使用PBR：在出口设备的内网接口配置PBR，匹配来自内网的流量，为其指定不同的下一跳公网地址
|
|
|
|
|
|
<h5>8.配置</h5>
|
|
|
|
|
|
|
|
|
|
|
|
**当ACL的rule配置为permit时，设备会对匹配该规则的报文执行本地策略路由的动作：**
|
|
|
|
|
|
本地策略路由中策略点为permit时对满足匹配条件的报文进行策略路由
|
|
|
|
|
|
本地策略路由中策略点为deny时对满足匹配条件的报文不进行策略路由，即根据目的地址查找路由表转发报文
|
|
|
|
|
|
**当ACL配置了rule，如果报文未匹配上任何规则，则根据目的地址查找路由表转发报文**
|
|
|
|
|
|
当ACL的rule配置为deny或ACL未配置规则时，应用该ACL的本地策略路由不生效，即根据目的地址查找路由表转发报文
|
|
|
|
|
|
|
|
|
|
|
|
<h5>9.配置案例 </h5>
|
|
|
|
|
|
|
|
|
|
|
|
**需求：**
|
|
|
|
|
|
内网存在两个网段，网段1：10.1.1.0/24，网段2：10.1.2.0/24，在RTA的GE0/0/0接口部署PBR，实现网段1访问Internet通过ISP1、网段2访问Internet通过ISP2
|
|
|
|
|
|
RTA上旁挂了一台服务器，要求在RTA上部署的策略路由不影响内网用户访问该服务器
|
|
|
|
|
|
**配置**
|
|
|
|
|
|
配置ACL 3000，其中rule 1 deny网段1访问服务器的流量，rule 2匹配网段1访问Internet的流量
|
|
|
|
|
|
```shell
|
|
|
[RTA] acl number 3000
|
|
|
[RTA-acl-adv-3000] rule 1 deny ip source 10.1.1.0 0.0.0.255 destination 10.1.3.254 0
|
|
|
[RTA-acl-adv-3000] rule 2 permit ip source 10.1.1.0 0.0.0.255 destination
|
|
|
0.0.0.0 0
|
|
|
```
|
|
|
|
|
|
配置ACL 3001，其中rule 1 deny网段2访问服务器的流量，rule 2匹配网段2访问Internet的流量
|
|
|
|
|
|
```shell
|
|
|
[RTA] acl number 3001
|
|
|
[RTA-acl-adv-3001] rule 1 deny ip source 10.1.2.0 0.0.0.255 destination 10.1.3.254 0
|
|
|
[RTA-acl-adv-3001] rule 2 permit ip source 10.1.2.0 0.0.0.255 destination
|
|
|
0.0.0.0 0
|
|
|
```
|
|
|
|
|
|
创建PBR hcip，创建节点10，调用ACL 3000，指定其转发下一跳为202.1.2.3
|
|
|
|
|
|
```shell
|
|
|
[RTA] policy-based-route hcip permit node 10
|
|
|
[RTA-policy-based-route-hcip-10] if-match acl 3000
|
|
|
[RTA-policy-based-route-hcip-10] apply ip-address next-hop 202.1.2.3
|
|
|
```
|
|
|
|
|
|
创建PBR hcip节点20，调用ACL 3001，指向其转发下一跳为154.1.2.3
|
|
|
|
|
|
```shell
|
|
|
[RTA] policy-based-route hcip permit node 20
|
|
|
[RTA-policy-based-route-hcip-20] if-match acl 3001
|
|
|
[RTA-policy-based-route-hcip-20] apply ip-address next-hop 154.1.2.3
|
|
|
```
|
|
|
|
|
|
在GE0/0/0接口调用PBR hcip
|
|
|
|
|
|
```shell
|
|
|
[RTA]interface GigabitEthernet 0/0/0
|
|
|
[RTA-GigabitEthernet0/0/0] ip policy-based-route hcip
|
|
|
```
|
|
|
|
|
|
<h4>二：MQC</h4>
|
|
|
|
|
|
<h5>1.MQC介绍</h5>
|
|
|
|
|
|
|
|
|
|
|
|
MQC（Modular QoS Command-Line Interface，模块化QoS命令行）是指通过将具有某类共同特征的数据流划分为一类，并为同一类数据流提供相同的服务，也可以对不同类的数据流提供不同的服务
|
|
|
|
|
|
MQC包含三个要素：流分类（traffic classifier）、流行为（traffic behavior）和流策略（traffic policy）
|
|
|
|
|
|
MQC的流行为支持重定向报文，因此可以使用MQC实现IP单播策略路由
|
|
|
|
|
|
|
|
|
|
|
|
流策略：将流分类和流行为绑定，对分类后的报文执行对应流行为中定义的动作
|
|
|
|
|
|
一个流策略可以绑定多个流分类和流行为
|
|
|
|
|
|
<h5>2.MQC - 流分类</h5>
|
|
|
|
|
|
流分类：定义一组流量匹配规则，以对报文进行分类。流分类支持的匹配项如下所示
|
|
|
|
|
|
|
|
|
|
|
|
**流分类中各规则之间的关系分为：and或or，缺省情况下的关系为or**
|
|
|
|
|
|
and：当流分类中包含ACL规则时，报文必须匹配其中一条ACL规则以及所有非ACL规则；当流分类中没有ACL规则时，报文必须匹配所有非ACL规则
|
|
|
|
|
|
or：报文只要匹配了流分类中的一个规则，设备就认为报文匹配中该流分类
|
|
|
|
|
|
<h5>3.MQC - 流行为</h5>
|
|
|
|
|
|
流行为：用来定义执行的动作，支持报文过滤、重标记优先级、重定向、流量统计等动作
|
|
|
|
|
|
|
|
|
|
|
|
<h5>4.MQC - 流策略</h5>
|
|
|
|
|
|
**流策略：**
|
|
|
|
|
|
流策略支持在接口上调用
|
|
|
|
|
|
流策略存在方向(inbound、outbound)的概念，策略中的流行为匹配入、出方向的报文，对匹配中的报文执行相应的流动作
|
|
|
|
|
|
|
|
|
|
|
|
**注意：**
|
|
|
|
|
|
流策略不同于PBR，PBR只能调用在三层接口，而流策略支持调用在二层接口
|
|
|
|
|
|
<h5>5.配置介绍 </h5>
|
|
|
|
|
|
|
|
|
|
|
|
<h5>6.使用MQC实现策略路由</h5>
|
|
|
|
|
|
|
|
|
|
|
|
**需求：**
|
|
|
|
|
|
内网存在两个网段，网段1：10.1.1.0/24，网段2：10.1.2.0/24，在RTA上通过MQC实现策略路由，实现网段1访问Internet通过ISP1、网段2访问Internet通过ISP2
|
|
|
|
|
|
将MQC调用在RTA的GE0/0/0接口
|
|
|
|
|
|
**配置：**
|
|
|
|
|
|
配置ACL3000、3001分别匹配网段1、网段2访问Internet的流量。
|
|
|
|
|
|
```shell
|
|
|
[RTA] acl number 3000
|
|
|
[RTA-acl-adv-3000] rule 2 permit ip source 10.1.1.0 0.0.0.255 destination 0.0.0.0 0
|
|
|
[RTA] acl number 3001
|
|
|
[RTA-acl-adv-3001] rule 2 permit ip source 10.1.2.0 0.0.0.255 destination 0.0.0.0 0
|
|
|
```
|
|
|
|
|
|
创建流分类1、2分别匹配ACL3000、ACL3001
|
|
|
|
|
|
```shell
|
|
|
[RTA] traffic classifier 1
|
|
|
[RTA-classifier-1] if-match acl 3000
|
|
|
[RTA] traffic classifier 2
|
|
|
[RTA-classifier-2] if-match acl 3001
|
|
|
```
|
|
|
|
|
|
创建流行为1、2分别执行将报文重定向到202.1.2.3、154.1.2.3的动作
|
|
|
|
|
|
```shell
|
|
|
[RTA] traffic behavior 1
|
|
|
[RTA-behavior-1] redirect ip-nexthop 202.1.2.3
|
|
|
[RTA] traffic behavior 2
|
|
|
[RTA-behavior-2] redirect ip-nexthop 154.1.2.3
|
|
|
```
|
|
|
|
|
|
创建流策略Redirect，将流分类1、2与流行为1、2一一绑定
|
|
|
|
|
|
```shell
|
|
|
[RTA] traffic policy Redirect
|
|
|
[RTA-trafficpolicy-Redirect] classifier 1 behavior 1
|
|
|
[RTA-trafficpolicy-Redirect] classifier 2 behavior 2
|
|
|
```
|
|
|
|
|
|
在GE0/0/0接口入方向调用流策略Redirect
|
|
|
|
|
|
```shell
|
|
|
[RTA] interface GigabitEthernet 0/0/0
|
|
|
[RTA-GigabitEthernet0/0/0] traffic-policy Redirect inbound
|
|
|
```
|
|
|
|
|
|
<h4>三：流量过滤</h4>
|
|
|
|
|
|
<h5>1.需求背景</h5>
|
|
|
|
|
|
为提高网络安全性，管理人员需要控制进入网络的流量，将不信任的报文丢弃在网络边界。所谓的不信任报文是指对用户来说存在安全隐患或者不愿意接收的报文。同时保证数据访问安全性，企业网络中经常会要求一些部门之间不能相互访问
|
|
|
|
|
|
|
|
|
|
|
|
<h5>2.流量过滤工具</h5>
|
|
|
|
|
|
Traffic-Filter只能应用在接口视图下，而MQC可以调用在多种视图
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**Traffic-Filter部署位置**
|
|
|
|
|
|
使用Traffic-Filter过滤流量可以灵活地选择部署位置，在流量进入设备或者离开设备的接口上执行过滤动作，双向访问的业务禁止其中一个方向即可实现阻断业务的需求
|
|
|
|
|
|
|
|
|
|
|
|
**使用Traffic-Filter过滤流量**
|
|
|
|
|
|
|
|
|
|
|
|
部门1、2、3的网关都在RTA上，现要求在RTA上使用Traffic-Filter限制部门2与部门3之间的相互访问
|
|
|
|
|
|
**配置：**
|
|
|
|
|
|
配置ACL拒绝部门2访问部门3，并放通其余所有流量
|
|
|
|
|
|
```shell
|
|
|
[RTA] acl number 3000
|
|
|
[RTA-acl-adv-3000] rule 1 deny ip source 10.1.2.0 0.0.0.255 destination
|
|
|
10.1.3.0 0.0.0.255
|
|
|
[RTA-acl-adv-3000] rule 2 permit ip
|
|
|
```
|
|
|
|
|
|
在GE0/0/2接口调用Traffic-Filter
|
|
|
|
|
|
```shell
|
|
|
[RTA] interface GigabitEthernet 0/0/2
|
|
|
[RTA-GigabitEthernet0/0/2] traffic-filter outbound acl 3000
|
|
|
```
|
|
|
|
|
|
**使用MQC过滤流量**
|
|
|
|
|
|
|
|
|
|
|
|
部门1、2、3的网关都在RTA上，现要求在RTA上使用Traffic-Filter限制部门2与部门3之间的相互访问
|
|
|
|
|
|
**配置：**
|
|
|
|
|
|
配置ACL匹配部门2访问部门3的流量
|
|
|
|
|
|
```shell
|
|
|
[RTA] acl number 3000
|
|
|
[RTA-acl-adv-3000] rule 1 permit ip source 10.1.2.0 0.0.0.255 destination
|
|
|
10.1.3.0 0.0.0.255
|
|
|
```
|
|
|
|
|
|
创建流分类2_3、流行为2_3
|
|
|
|
|
|
```shell
|
|
|
[RTA] traffic classifier 2_3
|
|
|
[RTA-classifier-2_3] if-match acl 3000
|
|
|
[RTA] traffic behavior 2_3
|
|
|
[RTA-behavior-2_3] deny
|
|
|
```
|
|
|
|
|
|
为匹配ACL规则的报文指定报文过滤动作时，如果此ACL中的rule规则配置为permit，则设备对此报文采取的动作由流行为中配置的deny或permit决定；如果此ACL中的rule规则配置为deny，则无论流行为中配置了deny或permit，此报文都被丢弃
|
|
|
|
|
|
创建流策略，绑定流分类2_3与流行为2_3
|
|
|
|
|
|
```shell
|
|
|
[RTA] traffic policy 2_3
|
|
|
[RTA-trafficpolicy-2_3] classifier 2_3 behavior 2_3
|
|
|
```
|
|
|
|
|
|
在接口GE0/0/1入向调用流策略2_3
|
|
|
|
|
|
```shell
|
|
|
[RTA] interface GigabitEthernet 0/0/1
|
|
|
[RTA-GigabitEthernet0/0/1] traffic-policy 2_3 inbound
|
|
|
```
|
