停止public 网卡 导致业务无法下发

背景
某个 poc 项目中有个io可用性测试没有达到预期
故障如下：

三节点（min_size），故障一个节点的业务网络平面，cosbench 持续跌0，一直没有恢复；恢复业务网络平面后，cosben 恢复水平状态

问题
单节点的故障，应该怎么折腾都可以的，但是为什么停止了单独停止一个网络平面久有问题了? 停止一会能理解，但是 一直停就无法解释了

定位过程
以往有遇到过相关的问题，但是定位到 是 osd 反复重启导致的，pg 一直处于 peering 状态，这个状态 在ceph 中确实会卡io，但是 为什么 会反复重启呢？
那是简单看了下日志，知道是心跳导致的，但没有弄清楚 真的原因….

起初网上搜下了，相关问题，发现x公司有个描述很相似的，但是17年的事情，早就很合入了

家里复现： 测试那边能复现，有时复现很容易，有时候要折腾很多次（为什么 偶现？）

现在停止了 业务网，mon和osd之间走 public 网，故障节点的osd 是无法和mon通讯的
但mon 又可以 更新 osd 状态？ 说明 mon 是收到了 osd 启动的信息？
osd 的心跳机制是要确保两个网络平面都正常才可以， 停了public ，自然会被同个 public 层面的 osd 上报异常，于是mon 把osd 标记为 down
更新osd视图，正常来说 osd tree 就可以看到状态
现在的场景是，mon 把osd 标记为 down后，osd 自身重启重新发 boot信息，目前这也是推测，得看日志才知道。

好在可以复现，于是 把　osd和mon的日志开到15，涉及消息发送，ms 模块也开启
发现 主 mon 既然有收到 故障节点的 boot信息？？？ 奇怪，难道 osd 还能 mon还发送了信息？？？

确认下 osd 是否给 主mon 发送了，可是没发现 成功发送的，但是 发现了给副mon！
于是在 mon 日志看到 副mon 转发的？

难道说 osd 给 副mon 发了 boot 信息，副mon 又给主 mon发送了？
和 主 mon 的节点无法通信，但是可以和 副mon 的能通信，什么情况？ 数据 路由过去了？ （这个问题没定位到）

后来在mon的日志 真的发现了 副mon 转发过来的 msg，从时间点来看就是 osd的boot信息…

理论上来说 ， public 和 cluster 是完全隔离的！

所以停止 public 不会出现这个问题，但是这种场景， public 和 cluster 还存在连接(有路由？)，osd 还能 和mon 通讯？，还能获取 新的osdmap,于是开启走启动流程，但是 ods public 层面是 不通的，所以心跳也会报异常…

为什么 public 网段的网卡已经down了 但是还能和其他节点的通？ 这个让 IT那边人定位了下，目前也没结果