简短的回答是：您不需要启用任何调试来将 Traceback 消息发送到系统日志，前提是路由器可以在崩溃时发送这些消息（由于模块化软件设计，有时确实会发生这种情况）。您还应该确保neighbor x.x.x.x soft-reconfiguration关闭BGP ，因为即使路由映射拒绝它们，这也会导致路由器存储 BGP 通告。

更长的答案是这样的：你说几年前路由器内存不足，因为它存储了完整的互联网路由。你说你添加了一个路由映射来拒绝除默认路由之外的所有路由。如果路由器soft-reconfiguration启用了该功能，那么它会将路由存储两次——一次在 BGP 的内存中，一次在常规路由表中。如果是这样，那么路由器现在可能第二次（两年后）内存不足，因为现在互联网路由比以往任何时候都多，并且由于路由，内存第二次被填满BGP 正在缓存，即使路由映射拒绝了它们。

如果soft-reconfiguration不是，那么我们退后一步寻找其他原因。一般来说，可以说路由器崩溃的原因主要有两个——软件错误和内存不足。我们假设您没有遇到任何软件错误，因为您没有提到任何软件更新、配置更改等。通常内存不足仅由以下几种情况引起：1) 路由器的内存比软件少图像需要，2) 内存被某些东西填满，或 3) 内存出现故障。

也许您过去曾遇到过使用 BGP 的第二种情况，但在像您目前这样几乎没有证据可以得出任何结论的情况下，第三种情况似乎最有可能。正如@user56700 所提到的，您应该在日志中查找任何Traceback消息，并在闪存中查找任何crashinfo文件。一旦路由器崩溃，您通常无法查看日志，因此正如您所提到的，让系统日志正常工作是一个很好的第一步。通常，当路由器知道它正在崩溃时，它可以执行一些最终操作，例如发送系统日志消息，并将内存转储写入闪存，因此如果生成了 Traceback 消息，您就有机会捕获它。

不幸的是，该路由器型号已停产，因此让 Cisco 查看一个Traceback或一个crashinfo文件基本上为零。可能是时候升级那个路由器了！

感谢您的建议，问题已解决。

正如我所说，这次我不能责怪BGP，并且第一次后软重配置已经关闭。

在照顾好这个路由器之后，我设法抓住了它几乎死了的时刻，show proc mem sorted allocated并向我展示了“L2TUN 应用程序”服务是罪魁祸首。

然后我用来sh vpdn确认和一些调试来跟踪并发现有人充斥着半开的 pptp 会话（客户端开始调用并忽略任何进一步的协商，可能是邪恶的 ISP 阻止了 PPTP 数据包）。

Radius 计费日志显示了 IP 并确认它是过去 8 天的重复违规者，在 ACL 中阻止它后问题解决了。我认为这是一个坏掉的客户端（或 ISP）而不是攻击者。需要向 Radius 添加一些监控以查看失败尝试的数量是否意外增加，我的主要问题是我根本不看 Radius，也没有将其视为故障排除帮助。

希望我的发现可以帮助任何处于相同情况的人。我仍然不知道为什么这会导致路由器将所有内存泄漏给 VPN 服务，更重要的是 - 如何防止这种洪水（无论是有意还是无意）