【Cisco】【安全】【CCNA】Cisco Unicast RPF 简单介绍

Cisco Unicast RPF 简单介绍

• Cisco Unicast RPF 简单介绍
  • 介绍
  • 严格uRPF检查
  • 松散的RPF检查
  • 默认路由uRPF检查
  • 使用ACL免uRPF检查
  • GRE Tunnel Keepalives uRPF检查
  • Unicast RPF 实验(视频）
  • 参考文献

介绍

uRPF（Unicast reverse path forwarding），简称单播逆向路由转发，是一种防止IP欺骗的技术，通常情况下网络设备在转发数据的时候关心的是目的（Destination），并不关心源（Source），而uRPF技术就是关心源（Source）的一个技术。即，从某个接口进来的数据包，能否从此接口在返回到源（Source）上，如果可以从入接口返回到源，那么将通过uRPF检查完成数据转发，反之亦然。

1. 严格uRPF检查
2. 松散uRPF检查
3. 默认路由uRPF检查
4. 使用ACL免uRPF检查
5. GRE Tunnel Keepalives uRPF检查
6. Unicast RPF 实验

严格uRPF检查

RPF检查分为两种，一种是严格方式，另外一种是松散方式。严格方式要求，数据包从那个接口进来，那么指向源（Source）的路由下一跳也必须是数据包进来的接口。若不匹配则丢弃。（The rx option enables a Strict Mode uRPF on the router. This mode ensures that the router reaches the source address only via the interface on which the packet was received.）

配置命令：

R1(config-if)#ip verify unicast source reachable-via rx

松散的RPF检查

松散的RPF检查，只关心有没有去往源（Source）的路由，如果有那么就通过检查，如果没有则丢弃。与严格方式不同，严格方程除了关心有没有路由还关心流量进来的接口。（The any option enables a Loose Mode uRPF on the router. This mode allows the router to reach the source address via any interface.
）

配置命令：

R1(config-if)#ip verify unicast source reachable-via any 

默认路由uRPF检查

有的设备上为了避免环路，就会配置ip route 0.0.0.0 0.0.0.0 null 0 来避免网络环路对这样的路由是否也能参与到uRPF检查呢？那么可以通过allow-default 选项来完成。如果配置了此选项，那么默认路由将不适用于uRPF检查，必须使用明细路由来完成uRPF检查，反之亦然。（You can also use the allow-default option, so that the default route can match when checking source address.）

配置命令：

ip verify unicast source reachable-via { any | rx } allow-default 

使用ACL免uRPF检查

如果想让某些源不参与uRPF检查，可以使用挂载ACL，ACL中所匹配的条目不适用于RPF检查。
配置命令：

R1(config)#access-list 100 permit ip host 222.222.222.222 any
R1(config-if)#ip verify unicast reverse-path 100

GRE Tunnel Keepalives uRPF检查

了解GRE Tunnel keepalive机制

tunnel ip 192.168.1.5     +----------------Interface Tunnel----------------+tunnel ip 192.168.1.7     
tunnel source 5.5.5.5     |                                                |tunnel source 7.7.7.7     
tuneel destiantion 7.7.7.7|                                                |tuneel destiantion 5.5.5.5
                          |                                                |                          
                          |                                                |                          
                          |                                                |                          
                          |                                                |                          
                          |                                                |                          
                         +\-----+  56.1.1.0/24 +------+  67.1.1.0/24 +-----\+                         
                         |  R5  |--------------|  R6  |--------------|  R7  |                         
                         +------+.5          .6+------+.6          .7+------+                         

如上图所示。

R5
tunnel source 5.5.5.5
tuneel destiantion 7.7.7.7
R7
tunnel source 7.7.7.7
tuneel destiantion 5.5.5.5

那么以R5为例，R5发送的keepalive内容如下

+-----------++-----------++------------++----------------------------------+
|SRC 5.5.5.5||DST 7.7.7.7||GRE Head(IP)||SRC 7.7.7.7||DST 5.5.5.5||GRE Head|
+-----------++-----------++------------++----------------------------------+


Frame 4: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface 0
Ethernet II, Src: ca:01:1a:64:00:08 (ca:01:1a:64:00:08), Dst: ca:02:02:fc:00:08 (ca:02:02:fc:00:08)
Internet Protocol Version 4, Src: 5.5.5.5, Dst: 7.7.7.7
Generic Routing Encapsulation (IP)
Internet Protocol Version 4, Src: 7.7.7.7, Dst: 5.5.5.5
Generic Routing Encapsulation (Possible GRE keepalive packet)

当R7收到数据包之后对数据包进行检查，观察GRE tunnel 内层的信息，观察到内层的目的IP地址是去往R5的，于是乎就将GRE内层的信息在重新传回到R5上，数据包如下：

+-----------++-----------++--------+
|SRC 7.7.7.7||DST 5.5.5.5||GRE Head|
+-----------++-----------++--------+

Frame 5: 38 bytes on wire (304 bits), 38 bytes captured (304 bits) on interface 0
Ethernet II, Src: ca:02:02:fc:00:08 (ca:02:02:fc:00:08), Dst: ca:01:1a:64:00:08 (ca:01:1a:64:00:08)
Internet Protocol Version 4, Src: 7.7.7.7, Dst: 5.5.5.5
Generic Routing Encapsulation (Possible GRE keepalive packet)

R5收到了这个数据包即认为tunnel 链路还是存活的。就继续保持UP状态，反之亦然。

简单了解了GRE keepalive机制，如果uRPF的检查配置在R7的tunnel接口上会发生什么事情呢？
R7的tunnel 会DOWN掉。DOWN掉的原因就是因为R7在回送keepalive的时候出现了问题，即R7要回送如下报文的时候，进行uRPF检查
发现去往7.7.7.7的出接口并不是tunnel接口，所以RPF检查失败，导致回送的数据R5迟迟收不到，造成R5端认为tunnel keepalive 出现问题，即R5 tunnel 为DOWN状态。

R7#show ip route 7.7.7.7
Routing entry for 7.7.7.7/32
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Loopback1
      Route metric is 0, traffic share count is 1

解决此问题的办法就是需要配置一条ACL,让7.7.7.7免于RPF检查，这样R7正常回送keepalive也就不会导致R5端tunnel为DOWN状态了。

配置命令：

access-list 1 permit 7.7.7.7
ip verify unicast source reachable-via rx 1

Unicast RPF 实验(视频）

参见：https://www.youtube.com/watch?v=a_CodGbH6vA

参考文献

1. Understanding Unicast Reverse Path Forwarding
2. Configuring Unicast Reverse Path Forwarding
3. GRE Keepalive and Unicast RPF
4. Unicast Reverse Path Forwarding(PDF)
5. GRE Tunnel Keepalives
6. GRE Tunnel Keepalives2

2017年10月12日更新