On 05.12.2013 09:14, Dmitry S. Nikolaev wrote: > Hello. > > Does anyone use OSPFv3 ? > My question is about monitoring. Hello.
Please try an attached patch. > > We use OSPFv3 over tunnels and have more than one tunnel to one endpoint > over different Inet channels (different providers): > So, as example this is config of one of the side: > protocol ospf office { > debug { states, interfaces, events }; > tick 1; > rfc1583compat yes; > area 0.0.0.0 { > stub no; > interface "ng2" { > cost 5; > type pointopoint; > hello 10; > retransmit 3; > transmit delay 5; > dead count 3; > wait 40; > }; > interface "ng0" { > cost 10; > type pointopoint; > hello 10; > retransmit 3; > transmit delay 5; > dead count 3; > wait 40; > }; > interface "ng1" { > cost 30; > type pointopoint; > hello 10; > retransmit 3; > transmit delay 5; > dead count 3; > wait 40; > }; > }; > import filter ospfIN; > export filter ospfOUT; > } > > Show OSPF neighbors: > # birdc6 > BIRD 1.3.11 ready. > bird> show ospf neighbors > office: > Router ID Pri State DTime Interface Router IP > 1.1.1.1 1 full/ptp 00:30 ng1 fe80::224:1dff:feb3:720 > 1.1.1.1 1 full/ptp 00:29 ng2 fe80::224:1dff:feb3:720 > 1.1.1.1 1 full/ptp 00:30 ng0 fe80::224:1dff:feb3:720 > > When any OSPF neighbor goes down/up then in log appear: > Neighbor fe80::224:1dff:feb3:720 changes state from " full" to " > init". > Neighbor fe80::224:1dff:feb3:720 changes state from " init" to " > 2way". > Neighbor fe80::224:1dff:feb3:720 changes state from " 2way" to " > exstart". > Neighbor fe80::224:1dff:feb3:720 changes state from " exstart" to > "exchange". > Neighbor fe80::224:1dff:feb3:720 changes state from "exchange" to " > loading". > Neighbor fe80::224:1dff:feb3:720 changes state from " loading" to " > full". > > But OSPFv3 use link-local address for adjacency and not global IP on the > tunnel, example: > ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 > mtu 1500 > inet 10.255.255.1 --> 10.255.255.2 netmask 0xffffffff > inet6 fe80::224:1dff:feb3:720%ng0 prefixlen 64 scopeid 0x12 > inet6 2001:XXX:XXXX:XXX::1:1 --> 2001:XXX:XXXX:XXX::1:2 > prefixlen 128 > nd6 options=3<PERFORMNUD,ACCEPT_RTADV> > > 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? > Thanks. > > P.S. Sorry for my english. >
diff --git a/proto/ospf/neighbor.c b/proto/ospf/neighbor.c index 61224ec..baf190f 100644 --- a/proto/ospf/neighbor.c +++ b/proto/ospf/neighbor.c @@ -127,8 +127,15 @@ neigh_chstate(struct ospf_neighbor *n, u8 state) n->state = state; - OSPF_TRACE(D_EVENTS, "Neighbor %I changes state from \"%s\" to \"%s\".", - n->ip, ospf_ns[oldstate], ospf_ns[state]); + OSPF_TRACE(D_EVENTS, "Neighbor %I%s%s changes state from \"%s\" to \"%s\".", + n->ip, +#ifdef OSPFv2 + "", "", +#else /* OSPFv3 */ + ipv6_has_link_scope(&n->ip) ? "%" : "", + ipv6_has_link_scope(&n->ip) ? ifa->iface->name : "", +#endif + ospf_ns[oldstate], ospf_ns[state]); if ((state == NEIGHBOR_2WAY) && (oldstate < NEIGHBOR_2WAY)) ospf_iface_sm(ifa, ISM_NEICH);