PIM-DM中state refresh状态刷新机制

状态刷新机制作为顶替周期性扩散-剪枝来告知网络组播源活跃机制

但是在结合断言机制后，loser是使用180s的定时器来让自己重新获取转发组播报文的能力。

但是在状态刷新机制下，定时器会不断被复位（状态刷新周期为60s，定时器为180s），那意味着

永远都别想着能恢复组播转发能力，除非有组成员发送来的IGMP report报文后出现下游接口从而触发往上游发送嫁接消息。那么也就没有通过重新断言来决一胜负的可能了，那么对于避免winner宕机的情况就不能这么避免了。

通过抓包，发现loser没有发state-refresh报文，全程只有winner发送

而连接着loser的上游R1是有在发送的。

 实验中，尝试将R2（winner）的g0/0/1端口关闭掉，此时R4会向R3（loser）发送嫁接消息

R3的g0/0/1接口抓包：

R1的g0/0/2接口抓包

 

 

对于R3来说，它是有2个邻居的，winner与loser，按照正常来说它肯定需要接收state refresh报文来获知源是活跃的。但是在它经过60s后没有收到state refresh报文后，它就会作出判断：到底源不活跃了还是winner故障了？通过查看邻居，由于R2的g0/0/1端口关闭了，本来30s的hello报文，现在都超过105s都收不到，此邻居不存在了。但是它还有一个R3这个邻居，所以它会给R3发送Graft报文，而R3接收到后立即回复Graft-Ack报文，而且自己没其他下游端口了，就往上游R1发送Graft报文，R1同样回复了Graft-Ack报文。

在上面的基础上，当组播源不再发数据，那么当R6不再发送state refresh报文来保活源的时候，再

 关闭R2的g0/0/1端口，此时R3、R4就不会再60s收到state refresh报文了，R3作为loser的定时器也不会被重置，当180s过后，R3会往R1发送Graft报文，同样，R3发现邻居少了一个，也会往另一个邻居R3发送Graft报文。

这种情景不同在于loser是否是主动察觉winner是否宕机。