In this recipe, we'll look at the situation of a flapping internal OSPF neighbor, possibly caused by a flapping physical layer interface. In contrast with the previous recipe, where we simply trapped multiple instances of a flapping interface and shut the interface down, in this scenario, we'll deal with the situation slightly differently.
What we'll do is trap multiple sequential occurrences of an OSPF neighbor going away --for whatever reason—and, so long as he's the only OSPF neighbor on the link (which is a common situation in large ISP backbones where point-to-point WAN links are the norm), we'll poison the associated OSPF interface cost in order to influence traffic away from the link.
The underlying issue that is causing the degraded communication to the OSPF neighbor will remain, which means that we...
