坚持使用递归路由进行 GRE 故障排除

网络工程 思科 路由 隧道 格雷
2021-07-06 15:36:18

和我的上一个问题一样，我正在为我的 CCNA 考试而学习，目前我正在努力解决“7.2.2.4 GRE 故障排除”的问题。

稍后我将解释拓扑。首先让我记录一下，到目前为止我已经采取了哪些步骤：

  1. t0 和 G0/0 上的 RA 的 Ip 地址被交换了。我纠正了他们
  2. RA 的隧道 0 接口具有错误的源地址和目标地址。我将它们设置为 s:172.31.0.1 d: 192.168.1.1

现在，在 RB 上有这条消息： 

 %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
 %ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of 0 65E900C0 - looped chain attempting to stack
 %TUN-5-RECURDOWN: 0 temporarily disabled due to recursive routing

拓扑：

GRE拓扑

如图所示，每个 IP 地址/网络地址都是正确的。

这是show interface tunnel 0在 RA：

Tunnel0 is up, line protocol is up (connected)
  Hardware is Tunnel
  Internet address is 192.168.1.1/30
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 172.31.0.1 (GigabitEthernet0/0), destination 192.168.1.2
  Tunnel protocol/transport GRE/IP

Show interface tunnel 0 RB：

Tunnel0 is up, line protocol is up (connected)
  Hardware is Tunnel
  Internet address is 192.168.1.1/30
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 172.31.0.1 (GigabitEthernet0/0), destination 192.168.1.2
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled

Show ip route RA：

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     172.31.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       172.31.0.0/24 is directly connected, GigabitEthernet0/0
L       172.31.0.1/32 is directly connected, GigabitEthernet0/0
     192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.1.0/30 is directly connected, Tunnel0
L       192.168.1.1/32 is directly connected, Tunnel0
     209.165.122.0/24 is variably subnetted, 2 subnets, 2 masks
C       209.165.122.0/30 is directly connected, Serial0/0/0
L       209.165.122.2/32 is directly connected, Serial0/0/0
S*   0.0.0.0/0 is directly connected, Serial0/0/0

Show ip route RB：

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     64.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       64.103.211.0/30 is directly connected, Serial0/0/0
L       64.103.211.2/32 is directly connected, Serial0/0/0
     172.31.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       172.31.1.0/24 is directly connected, GigabitEthernet0/0
L       172.31.1.1/32 is directly connected, GigabitEthernet0/0
     192.168.1.0/32 is subnetted, 1 subnets
L       192.168.1.2/32 is directly connected, Tunnel0
S*   0.0.0.0/0 is directly connected, Serial0/0/0

请通过解释我在这里遗漏的内容以及如何解决此问题来帮助我理解此错误。

亲切的问候。

**//EDIT: ** 需要完成的任务是来自双方 172.31.xx 网络的流量需要建立隧道。

//EDIT2：事实证明我在说废话**。以下是迄今为止采取的步骤：

  1. t0 和 G0/0 上的 RA 的 Ip 地址被交换了。我纠正了他们

  2. RA 的隧道 0 接口具有错误的源地址和目标地址。我将它们设置为 s:172.31.0.1 d: 192.168.1.1

  3. 将 RA 上隧道 0 的源地址更改为 172.31.0.1

  4. 将 RB 上隧道 0 的目标地址更改为 209.165.122.2
  5. copy run start 在 RB 上然后 reload
  6. RB 上的隧道 0 现在已启动并已连接。

//编辑3：

我终于解决了。我在我的课程中回到了之前的任务，它确实指导我完成了整个配置任务。

隧道的两个路由器上的源是S0/0/0接口，目的地是其他路由器的S0/0/0接口 IP 地址。这是非常违反直觉的，因为在我的脑海中我的印象是，源是来自本地 LAN（172 个接口）的流量，因为来自那里的流量需要通过隧道传输。

只是为了更好的衡量，我为两个路由器添加了 2 个静态路由，以确保数据包以这种方式路由，以防 OSPF/EIGRP 或 RIP 另有想法。

我对这两个答案都投了赞成票，但接受了 Ron 的答案，因为他首先回答了正确的设置。

3个回答

服务，

您的隧道源地址和目标地址是错误的。它们在 RA 上应该是 209.165.122.2 和 64.103.211.2，在 RB 上应该是相反的。

有许多不同的方法可以解释这一点，但本质上，到隧道端点的路由不能通过隧道。在您的情况下，为了将数据包（从 RA）发送到 192.168.1.2，RA 必须将其封装在 GRE 数据包中，然后将其发送到隧道目的地。但是到隧道目的地的路由是通过隧道本身。这是不允许的，因为您将无限封装数据包。

另一种解释（比喻）：

想像一座横跨河流的桥梁。桥梁工程师需要知道在河的每一边放置桥梁的位置。一旦他们建造了这座桥，你就可以引导人们使用这座桥到达另一边。但这与必须建造桥梁的地方是分开的。

桥（隧道）是从 RA 的 s0/0/0 接口到 RB s0/0/0 构建的。一旦隧道启动，您就可以通过隧道路由来自 172.31.xx 的流量。换句话说，建立隧道与通过隧道路由流量是分开的。

您不能拥有尚未建立的 GRE 隧道的目的地。

RA：

Tunnel0 is up, line protocol is up (connected)
  Hardware is Tunnel
  Internet address is 192.168.1.1/30
  ! Can't have the same IP on the GRE tunnel on both ends
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 209.165.122.2 (Serial0/0/0), destination 64.103.211.2
  ! Assuming S0/0/0 is 209.165.122.2

RB：

Tunnel0 is up, line protocol is up (connected)
  Hardware is Tunnel
  Internet address is 192.168.1.2/30
  ! Can't have the same IP on the GRE tunnel on both ends
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 64.103.211.2 (Serial0/0/0), destination 209.165.122.2 
  ! Assuming S0/0/0 is 64.103.211.2

编辑

让我分解一下如何更好地工作。您的目标是通过您在RA和RB之间建立的隧道在 172.31.xx 网络上建立隧道。

RA 不知道172.31.1.0/24; 因此，您在 RIB 中看不到它。RB 不知道172.31.0.0/24; 你也可以在他的肋骨中看到。

如果 RA 尝试联系 172.31.1.0/24 中的任何内容，数据包将被发送到其默认路由器（我们假设是S0/0/0）。一旦云获得该地址，他就会删除它，因为除了209.165.122.0/30和之外，他对任何网络都不了解64.103.211.1/30。

GRE 隧道需要一个有效的目的地来构建隧道，并且该隧道将穿越广域网。您的 RA 隧道将从源209.165.122.2到目的地64.103.211.2，虚拟 IP 为192.168.1.1. 您的 RB 将具有虚拟 IP 的源64.103.211.2和目标。209.165.122.2192.168.1.2

然后，您可以在 RA 中设置一个默认路由，该路由生效172.31.1.0/24 via 192.168.1.2。
然后，您可以在 RB 中设置一个默认路由，该路由生效172.31.0.0/24 via 192.168.1.1。

这些默认路由将强制它们各自的流量通过 GRE 隧道到达它们的端点。

这个问题的基本答案在于%TUN-5-RECURDOWN: 0 temporarily disabled due to recursive routing错误消息。当路由进程需要决定将特定数据包路由到哪里时，它本质上需要找出将数据包从哪个接口发送出去。在 GRE 隧道的情况下，递归路由会在通过隧道自身获知到隧道端点的更有利的路由（较低的度量）时发生。当这种情况发生时，我们将最终得到一个递归循环，其中流量被识别为通过隧道路由，隧道被识别为通过以太网（或串行）接口路由，该接口再次被识别为通过隧道路由；导致不定式循环：

入口接口 -> Tun。接口 -> Eth。界面 -> Tun。界面 -> 等

如果需要在隧道上启用动态路由，则可以通过多种方式之一解决这种情况（可能存在更多选项）：

  1. 将静态路由添加到网络掩码为 /32 的隧道端点，以确保这些路由始终是首选路由。
  2. 在隧道接口上应用出站分发列表（在路由协议配置下配置）以过滤隧道端点地址，使其不被通告。
  3. 通过更改隧道接口的属性（延迟/带宽）来更改通过隧道获知的路由的度量，导致这些路由不如通过以太网（或串行）接口获知的相同路由有吸引力。
  4. 使用 FVRF 创建逻辑路由表隔离（请参阅有关通过 FVRF 解决递归路由的更多信息：http : //www.packetu.com/2013/10/15/using-gre-tunnel-vrf-separate-physical-interface/
其它你可能感兴趣的问题
上一篇惠普采购 HP-5406zl 日志 下一篇高效的加密 ACL？