On 07.12.2013 02:48, Ondrej Zajicek wrote:
On Fri, Dec 06, 2013 at 02:04:17PM +0400, Alexander V. Chernikov wrote:
On 05.12.2013 09:14, Dmitry S. Nikolaev wrote:
Hello.
Thus it is impossible to understand exactly what neighbor (over what tunnel) change it`s state because there is no iface name in log. So monitoring system can say that some neighbor down/up but can`t say over what tunnel this neighbor was working :(
Who faced with the same task ? How to solve? Please try an attached patch. Hello
Although adding an iface scope to link-local addresses helps a bit, link-local addresses are still confusing when there are many neighbors on one iface. Yes, definitely.
I am thinking about replacing IPs with router IDs as a primary neighbor description in most OSPF log messages. Any comments/opinions to such change? Router id is much better identifier, yes. However it is worth adding interface name as well (at least if given OSPF instance has several different interfaces). Btw, there is IS-IS-like id-to-hostname TLV mapping described in RFC 5642 but I'm not sure if any vendor supports it..
Just for history purposes, what others currently do: Juniper: RPD_OSPF_NBRDOWN: OSPF neighbor fe80::92e2:baff:fe0d:7591 (realm ipv6-unicast irb.801 area 0.0.0.0) state changed from Full to Down due to KillNbr (event reason: interface passive mode status changed) Cisco (IOS XR): %ROUTING-OSPFv3-5-ADJCHG : Process 1, Nbr 87.250.XXX.XXX on Bundle-Ether4 from FULL to DOWN, Neighbor Down: Interface down or detached Cisco (Regular IOS): %OSPFv3-5-ADJCHG: Process 1, Nbr 87.250.XXX.XXX on GigabitEthernet3/21 from FULL to DOWN, Neighbor Down: Too many retransmits Huawei: %%01OSPF/3/NBR_DOWN_REASON(l)[423]:Neighbor state leaves full or changed to Down. (ProcessId=100, NeighborRouterId=87.250.XXX.XXX, NeighborAreaId=0, NeighborInterface=Vlanif1603,NeighborDownImmediate reason=Neighbor Down Due to Inactivity, NeighborDownPrimeReason=Hello Not Seen, NeighborChangeTime=2013-10-31 17:58:19+04:00)
BTW, you can use '%J' as a shorthand for %iface (see e.g. bgp_start_locked() in proto/bgp/bgp.c).
Thanks for the hint :)