OSPFv3 and logging (debug)
Hello. Does anyone use OSPFv3 ? My question is about monitoring. 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. -- With best regards, Dmitry S. Nikolaev Moscow, Russia
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.
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. 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? BTW, you can use '%J' as a shorthand for %iface (see e.g. bgp_start_locked() in proto/bgp/bgp.c). -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello You say about replacing in bird or bird6 ? if in bird6 than it does not help in my case, because router id is also the same as ip`s: 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 Thanks for your reply Ondrej. i don`t know "c" code as good as you, easier to say i don`t know "c" at all. you are you're talking about this string in bgp.c ? log(L_ERR "%s: Invalid remote address %I%J", p->p.name, cf->remote_ip, cf->iface); It is doubtful that I can by myself make patch proto/ospf/neighbor.c for right use of cf->iface in neigh_chstate() function. With best regards, Dmitry S. Nikolaev Moscow, Russia phone: +7 (499) 678 8007 [ext. 6003] fax: +7 (499) 678 8007 [ext. 7777] www: http://www.mega-net.ru mail: dnikolaev@mega-net.ru On 07.12.2013 02:48, Ondrej Zajicek wrote:
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.
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?
BTW, you can use '%J' as a shorthand for %iface (see e.g. bgp_start_locked() in proto/bgp/bgp.c).
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 :)
On Sat, Dec 07, 2013 at 02:49:20PM +0400, Alexander V. Chernikov wrote:
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).
Yes, something like 'neighbor X.X.X.X on ethX'.
Just for history purposes, what others currently do:
Thanks for the review. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Thanks ! The patch, it`s working: Dec 7 08:49:15 office bird6: office: Neighbor fe80::3640:b5ff:fe8d:85a0%ng0 changes state from " down" to " init". Dec 7 08:49:15 office bird6: office: Neighbor fe80::3640:b5ff:fe8d:85a0%ng0 changes state from " init" to " 2way". Dec 7 08:49:15 office bird6: office: Neighbor fe80::3640:b5ff:fe8d:85a0%ng0 changes state from " 2way" to " exstart". Dec 7 08:49:20 office bird6: office: Neighbor fe80::3640:b5ff:fe8d:85a0%ng0 changes state from " exstart" to "exchange". Dec 7 08:49:20 office bird6: office: Neighbor fe80::3640:b5ff:fe8d:85a0%ng0 changes state from "exchange" to " loading". Dec 7 08:49:21 office bird6: office: Neighbor fe80::3640:b5ff:fe8d:85a0%ng0 changes state from " loading" to " full". Dec 7 08:49:12 office bird6: office: Neighbor fe80::21a:64ff:fe21:ad3a%ng1 changes state from " down" to " init". Dec 7 08:49:12 office bird6: office: Neighbor fe80::21a:64ff:fe21:ad3a%ng1 changes state from " init" to " 2way". Dec 7 08:49:12 office bird6: office: Neighbor fe80::21a:64ff:fe21:ad3a%ng1 changes state from " 2way" to " exstart". Dec 7 08:49:17 office bird6: office: Neighbor fe80::21a:64ff:fe21:ad3a%ng1 changes state from " exstart" to "exchange". Dec 7 08:49:17 office bird6: office: Neighbor fe80::21a:64ff:fe21:ad3a%ng1 changes state from "exchange" to " loading". Dec 7 08:49:18 office bird6: office: Neighbor fe80::21a:64ff:fe21:ad3a%ng1 changes state from " loading" to " full". Now we can understand on what tunnel OSPF goes down. So I will go to append our monitoring system code and this task is solved. Thanks again. With best regards, Dmitry S. Nikolaev Moscow, Russia phone: +7 (499) 678 8007 [ext. 6003] fax: +7 (499) 678 8007 [ext. 7777] www: http://www.mega-net.ru mail: dnikolaev@mega-net.ru On 06.12.2013 14:04, Alexander V. Chernikov wrote:
Please try an attached patch.
participants (3)
-
Alexander V. Chernikov -
Dmitry S. Nikolaev -
Ondrej Zajicek