Cisco IOS 从两个带有跟踪的 DHCP 接口中选择默认路由

网络工程 思科 路由 思科-ios dhcp
2021-07-31 17:11:25

我计划拥有一个便携式 IOS cisco 路由器,它将有两个来自未知范围的 DHCP 分配的 ISP 地址。然后通过首选 ISP 建立一个隧道到另一个外部。

我想根据优先级设置默认网关,但更重要的是基于可达性。通常,您可能会获得 DHCP 地址,但没有连接。这个想法是一个非技术人员可以将其插入,插入(本地路由器上的端口已经设置),并在可能的情况下获得基于本地 ISP 的连接,或者如果没有,则获得基于本地 ISP 的连接。

当您在配置时知道下一跳的地址时,这很简单 - IP ROUTE ... TRACK 将很好地工作,结合合适的优先级指标。

当您获得 DHCP 地址时,您可以执行 IP ROUTE ... DHCP 但它不会接受带有它的 TRACK 语句。

在 interface IP DHCP 命令中,您可以设置默认路由器距离,因此您可以提供优先级,但不测试可达性。因此,如果一切正常,您可以获得最好的,但如果一个 ISP 不稳定(或变得如此),则不会。

以下是接近的配置的相关部分。如果任一 DHCP 分配的接口无法获取地址,则一切正常,并使用另一个。它还会主动测试以选择正确的隧道源,因此如果一个连接出现故障,它将转移到另一个作为隧道源。但是,如果两者都已启动,则表示通过 gi0/7 连接失败:

  • 最初分配的指标为 gi0/7 的下一跳提供了最佳指标(无连接),并且该指标在接口重新绑定之前不会消失(如果它获得新地址但仍然缺乏连接,则可能不会消失)。
  • ikev2 客户端设置中的轨道将无法选择 7,但也无法获得 6(没有工作网关,因为 gi0/7 指标仍然是最好的)

如果我可以强制一个非常短的租约,接口将重新绑定(如果 dhcp 服务器也无法访问),但服务器通常会覆盖该请求并放入 1 天或更长的时间才能有用。并且 dhcp 服务器可能是半本地的并且不受中断的影响。

从理论上讲,它可以使用 TRACK 放置具有接口目的地(而不是下一跳)的路由,但这取决于提供代理 arp 的 ISP(我认为这就是术语),这远不能确定。如果 proxy-arp 仅在 GSM 路由器上可用,它可能会强制它始终处于开启状态。

问题是:当有两个 DHCP ISP 接口时,当前路由器 IOS CLI(我在 15.6 上进行测试)中是否有办法根据可达性获取和更新正确的默认路由?

我还尝试了各种方法来获得基于策略的路由来强制 SLA 的接口(仍然使用 DHCP 提供的下一跳),但没有任何成功,但到目前为止还没有成功。

感谢您的任何想法。

track 6 ip sla 6 reachability
track 7 ip sla 7 reachability
!         
crypto ikev2 client flexvpn FLEXVPN_IKEV2_CLIENT
  peer 1 9.9.9.2
  source 1 GigabitEthernet0/7 track 7
  source 2 GigabitEthernet0/6 track 6
  client connect Tunnel31
  !
interface Tunnel31
  ip unnumbered Loopback192
  ip nat inside
  tunnel source dynamic
  tunnel mode ipsec ipv4
  tunnel destination dynamic
  tunnel protection ipsec profile IKEV2_IPSEC_PROFILE
!         
interface GigabitEthernet0/6
 description Connection to GSM modem (secondary internet if primary down)
 ip dhcp client default-router distance 200
 ip dhcp client lease 0 0 5
 ip address dhcp
 ip nat outside
!
interface GigabitEthernet0/7
 description Connection to local intenet (if any) 
 ip dhcp client default-router distance 100
 ip dhcp client lease 0 0 5
 ip address dhcp
 ip nat outside

ip sla 6
 icmp-echo 75.75.75.75 source-interface GigabitEthernet0/6
 tag Cellular connection up test 
 frequency 10
ip sla schedule 6 life forever start-time now

ip sla 7
 icmp-echo 75.75.75.75 source-interface GigabitEthernet0/7
 tag Local ISP connection up test 
 frequency 10

附注。我省略了大部分隧道内容,因为这实际上是关于路由,而不是隧道;当隧道具有正确的默认网关时,隧道工作正常。

2个回答

我将把它作为一个可能的解决方案来发布,供人们在里面打洞,和/或建议如何清理它。它适用于具有 IOSv 图像的 GNS3 模拟。

首先让我更清楚地解释一下发生在我身上的事情,以及所有复杂性的基本原理。

首先为了清楚起见——我试图跟踪远程 IP,而不是下一跳,因为 (a) 在 DHCP 上不知道下一跳,并且 (b) 有时连接问题出现在下一跳之后。

如果您没有 DHCP,有一些简单的技术可以实现这一点——在单独的语句中使用每个下一跳 IP 显式跟踪远程项目,一切正常,并且您设置了距离的优先级。

我发现没有任何语法可以将 IP ROUTE...TRACK 与 DHCP 结合使用,并将下一跳与不同接口区分开来。我发现的所有变化都以先有鸡还是先有蛋的问题告终——由于 SLA 没有路径让它到达远程 IP,因此轨道无法运行。您可以使用 interface DHCP CLIENT 语句指定 ROUTE T​​RACK,但我无法想出任何方法让 SLA 使用该特定接口的下一跳。与验证可达性相同,至少与我发现的所有语法相同。

如果两个 DHCP 接口的指标不相等,为了给一个优先权,我发现会发生这种情况(在一个简单的设置中):两个 TRACK 语句都出现了,但是尽管它们上有源接口(这只是设置一个地址),两者都走出首选的默认路线。因此,当首选路线被破坏时(即我停止了它的交通),该路线保持为首选路线,并且两条轨道都会下降。源接口未指定出口接口

这可以通过给予他们同等的优先权来部分解决;然后到 0.0.0.0 的两条路由都安装在肋骨中,有时(但不总是)两个 TRACK 将使用它们的接口而不是相反的接口并独立运行。不幸的是,并非总是如此;不知道为什么,但根据观察,有时上面写的两条轨道即使在当时的默认网关上具有相同的偏好,也会出现相同的界面。

因此,这个提议的解决方案使用路由映射来强制每个 SLA(使用不同的目标 IP)的流量到特定的出口接口。如果这是使用不等优先级默认网关完成的,它也会失败——路由映射本身在非优先接口的数据包上失败;我不清楚为什么,它只是拒绝它并说“正常转发”。我认为它正在验证肋骨?但在同等偏好下,sla6 被强制为 gi0/6,而 sla7 被强制为 gi0/7,并且独立工作。

我不知道 SET INTERFACE 的这种使用在这个特定的转换中是否普遍适用,即使用正确的下一跳的数据包还是代理 arp。我尝试用wireshark查看它,但在模拟运行时遇到了一些问题。我稍后再确认。我希望它使用 rib 进行下一跳,并选择由路线图制作的路径。

但它很复杂,有点做作,我真的希望有一个更简单的解决方案。另一个问题是,它只能按照书面形式提供对隧道的偏好,而不是来自内部的一般互联网流量(在这种情况下没关系,因为这不是意图,但我想进一步试验其他路由映射条款,也许基于那里的跟踪,也更喜欢一般交通)。

我肯定希望有人提供更好的方法。和/或如果它不起作用,就在这一个上打洞。

如上,仅显示与路线偏好相关的项目。

附注。所有非私有地址都是模拟的,没有实际使用。

track 6 ip sla 6 reachability
track 7 ip sla 7 reachability

crypto ikev2 client flexvpn FLEXVPN_IKEV2_CLIENT
  peer 1 9.9.9.2
  source 1 GigabitEthernet0/7 track 7       <<< precedence established here, only for tunnels
  source 2 GigabitEthernet0/6 track 6
  client connect Tunnel31

interface Tunnel31
 ip unnumbered Loopback192
 ip nat inside
 tunnel source dynamic
 tunnel mode ipsec ipv4
 tunnel destination dynamic
 tunnel protection ipsec profile IKEV2_IPSEC_PROFILE
!

interface GigabitEthernet0/6
 ip dhcp client default-router distance 100  << must be the same as below or omitted
 ip address dhcp
 ip nat outside
!
interface GigabitEthernet0/7
 ip dhcp client default-router distance 100     << must be the same as above or omitted
 ip address dhcp
 ip nat outside
!
ip local policy route-map CHOOSE-ISP

ip sla 6
 icmp-echo 74.74.74.74 source-interface GigabitEthernet0/6
 tag Cellular connection up test 
 frequency 10
ip sla schedule 6 life forever start-time now

ip sla 7
 icmp-echo 75.75.75.75 source-interface GigabitEthernet0/7
 tag Local ISP connection up test 
 frequency 10
ip sla schedule 7 life forever start-time now
!
route-map CHOOSE-ISP permit 10
 match ip address 106
 set interface GigabitEthernet0/6   <<< give warning 
!
route-map CHOOSE-ISP permit 20
 match ip address 107
 set interface GigabitEthernet0/7   <<< give warning 
!
access-list 6 permit 74.74.74.74
access-list 7 permit 75.75.75.75

过去几周我一直在研究如何使用 DHCP 实现 WAN 故障转移,并找到了许多有用的文章和配置指南,但没有任何效果。在深入挖掘并继续搜索之后,我遇到了您的问题和您的创造性解决方案。尽管如此,我还是无法想象加密地图是解决这个问题的唯一方法。

我发现这篇 Cisco 文章为 ISR 路由器上的双 ISP 故障转移配置“ip dhcp 客户端路由跟踪”,描述了如何实现双 WAN 故障转移。尽管是 Cisco 发布的技术说明,但它不仅对我不起作用,而且失败的方式与您在上述问题中描述的方式相同!

玩了一圈,发现默认网关主路由中的接口要省掉了。这是一个简化的配置:

track 40 ip sla 30 reachability

ip sla 30
 icmp-echo 8.8.4.4 source-interface GigabitEthernet0/0
 timeout 6000
 frequency 10

ip sla schedule 30 life forever start-time now

interface GigabitEthernet0/0
 description DHCP WAN, primary
 ip dhcp client route track 40
 ip address dhcp

interface GigabitEthernet0/1
 description DHCP WAN, secondary
 ip address dhcp

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/1 dhcp 200
ip route 0.0.0.0 0.0.0.0 dhcp

我已经通过重启调制解调器和shut/no shut接口 0/0对此进行了多次测试一旦路由器注意到网关不会连接到远程 IP(sh tracksh ip sla summary),我就可以运行sh ip route | i 0\.0\.0\.0并看到辅助默认路由接管。然后我稍等片刻,主链接又弹出了。但是,如果我改为将主默认网关指定为ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0 dhcp- 也就是说,使用接口 - 轨道和 ip sla 保持关闭,并且主路由永远不会自行返回。

编辑

我不知道为什么在默认网关路由中指定接口会阻止 SLA 重置,而不指定它允许重置。但是,我怀疑是因为在接口中,路由规则非常具体,直接匹配 SLA。我还怀疑在内部规则并没有从路由器中删除,而是标记为被忽略或跳过。然后,如果规则存在,因为它与 SLA icmp-echo 完全匹配,该操作将被删除。然而,当它是没有接口的默认网关规则时,即使将 dhcp 标记为忽略,也会使用辅助接口的地址解释 dhcp,因此没有任何路由表规则完全匹配并且 icmp-echo 通过。

也许具有 cisco 调试和日志记录技能的人(即不是我)可能能够准确地告诉我们这里发生了什么。