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);
