failing traceroutes with unix

Unix Traceroute uses a set of UDP ports starting at 33434 (33434 to 33534) the reply can be desination unreachable. There can be an issue were they trace fails on certain packets because the target system has some program listening on one of the UDP ports in queston, you see this with the Nth trace packet always failing. Some systems let you override the UDP range. The specific issue occured when 1 packet failed on a trace route to a system on the same subnet, 1000s of pings worked without a problem. So use ICMP ping if you can, if UDP traceroutes fail at the last hop for no reason, this can be considered

IBGP can cycle between established and available

IF you have a configuration where you have 2 routers to 2 separate ISPs if you run IBGP on the loopback interface and you do not cover that with an IBGP network statement, BUT put a BGP network statement this bouncing can happen. Router B does not have its loopback statement covered by OSPF, router A learns the loopback via eBGP. An IBGP session comes up going through the providers. Since most IBGP sessions have next hop self you get a recursive route situation. Adding router Bs loopback into the IGP fixes this. The first part of IBGP debugging is making sure that the peers match (if router A peers to router Bs loopback, then router B needs update source loop 0), after that you check that you have a route to the loopback address. You have to check were that route came from (make sure not eBGP).