[quagga-users 14940] Re: Disable BGP general scanning, BGP SCAN-TIMER

[Nick Hilliard]

William Herrin wrote:
> Should you tinker around with internals for a complicated protocol you
> don't deeply understand? No, no you should not. Doing so invites the
> needless pain of a self-inflicted wound.

This advice should be resolutely ignored.

Tinkering around with the internals of complicated protocols you don't
deeply understand is the best way to deeply understand complicated
protocols.  Occasionally you will burn your fingers.

All the best engineers have burn marks on their fingers.

Nick
___
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

[quagga-users 14939] Re: Disable BGP general scanning, BGP SCAN-TIMER

[William Herrin]

On Fri, Feb 16, 2018 at 5:21 PM,   wrote:
> But still the question. I have 4 bgp-neighbors in the "direct visibility"
> ethernet - for each bgp-connection there is a subnet /30, where is one ip -
> my router, other ip - bgp-neighbor. Does this configuration allow me to
> refuse the "bgp-scan" function in your opinion?

Should you tinker around with internals for a complicated protocol you
don't deeply understand? No, no you should not. Doing so invites the
needless pain of a self-inflicted wound.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 
___
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

[quagga-users 14938] Re: Disable BGP general scanning, BGP SCAN-TIMER

[bg]

2018-02-16 04:12, William Herrin написав:


On Thu, Feb 15, 2018 at 7:05 PM,   wrote:

2018-02-15 22:21, Alexis Rosen написав:

On Feb 15, 2018, at 8:29 AM, b...@it-mark.net wrote:

But once every minute for about 3-10 seconds there is a "BGP general
scanning", which is arbitrarily executed on any of the processor 
cores and

loads it 100% within a specified time.


But can this idea be realized at all? Just by default, bgp-scan occurs 
every
minute and it can only be changed by specifying the interval from 5 - 
60
seconds. And it seems that it's impossible to turn off this feature at 
all?


The BGP scanner performs next-hop validation. Where the next hop is
not your direct eBGP peer, the scanner is what figures out that routes
are no longer reachable and picks new next-hops via which they are.

If you have a trivial configuration where your BGP next hop is always
your single, directly adjacent BGP peer, you can probably tweak the
software to allow a longer timer and recompile it without ill effect.
If you have more than one BGP router, multiple peers, or a multihop
BGP configuration then you should probably leave well enough alone.

If it's causing latency issues for other software on the server, you
can consider running it with the "nice" command.


Thank you Bill for advice.

I thought there is a command that turns off the function bgp-scan. But 
you say that I need to recompile...
I solved the problem by transferring the bgpd process to a separate core 
(taskset command) and changing the priority using "nice".
The problem is resolved, only now the corresponding core is idle :) But 
this is not a problem yet.


But still the question. I have 4 bgp-neighbors in the "direct 
visibility" ethernet - for each bgp-connection there is a subnet /30, 
where is one ip - my router, other ip - bgp-neighbor. Does this 
configuration allow me to refuse the "bgp-scan" function in your 
opinion?




Regards,
Bill Herrin



___
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

[quagga-users 14937] Re: Assertion failed in ospfd 1.2.3

[Paul Jakma]

On Fri, 16 Feb 2018, Ivan Kuznetsov wrote:

2018/02/16 18:32:26 OSPF: Assertion `thread->master != ((void *)0) && thread 
!= ((void *)0)' failed in file thread.c, line 607, function thread_add_unuse



What can be a troubleshooting procedure?


If you 'git revert 5e13840d7f3e7fcdf7e' and then rebuild, does that fix 
it?


I.e. backout:

https://gogs.quagga.net/Quagga/quagga/commit/5e13840d7f3e7fcdf7ecff762c019bb56c88965f

regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Deprive a mirror of its silver and even the Czar won't see his face.
___
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

[quagga-users 14936] Re: Assertion failed in ospfd 1.2.3

[Balaji Gurudoss]

Hi

This should suffice. Will investigate this and resolve this

Thanks
   Balaji

On Fri, 16 Feb 2018 at 22:04, Ivan Kuznetsov  wrote:

> Hello
>
> I try to setup a test software router under Linux (Oracle Linux 6
> x86_64) and Quagga 1.2.3. ospfd being started exited a few seconds after
> with assertion fault. It seems that is a time of first multicast network
> packet received. OSPF configuration is quite simple :
>
> interface eth0
> !
> interface eth0.3
>   ip ospf authentication-key 
> !
> interface eth1
> !
> interface eth2
> !
> interface eth3
> !
> interface lo
> !
> router ospf
>   ospf router-id 172.16.83.71
>   auto-cost reference-bandwidth 1000
>   passive-interface eth0
>   passive-interface eth1
>   passive-interface eth2
>   passive-interface eth3
>   network 172.16.83.71/26 area 172.16.80.0
>   area 172.16.80.0 authentication
> !
> line vty
>
> Quagga 1.2.2 at the same computer and configuration works as desired.
>
> I built 1.2.3 RPM using quagga.spec file from tarball with only cosmetic
> changes. It is near identical against one from 1.2.2. Building
> environment is the same
>
> Here is crashlog:
>
> 2018/02/16 18:32:26 OSPF: Assertion `thread->master != ((void *)0) &&
> thread != ((void *)0)' failed in file thread.c, line 607, function
> thread_add_unuse
> 2018/02/16 18:32:26 OSPF: Backtrace for 12 stack frames:
> 2018/02/16 18:32:26 OSPF: [bt 0]
> /usr/lib64/quagga/libzebra.so.1(zlog_backtrace+0x35) [0x7fbfd7cb2ea5]
> 2018/02/16 18:32:26 OSPF: [bt 1]
> /usr/lib64/quagga/libzebra.so.1(_zlog_assert_failed+0x67) [0x7fbfd7cb3027]
> 2018/02/16 18:32:26 OSPF: [bt 2]
> /usr/lib64/quagga/libzebra.so.1(+0x27cfe) [0x7fbfd7ca1cfe]
> 2018/02/16 18:32:26 OSPF: [bt 3]
> /usr/lib64/quagga/libzebra.so.1(+0x28389) [0x7fbfd7ca2389]
> 2018/02/16 18:32:26 OSPF: [bt 4]
> /usr/lib64/quagga/libzebra.so.1(funcname_thread_execute+0x4c)
> [0x7fbfd7ca30cc]
> 2018/02/16 18:32:26 OSPF: [bt 5]
> /usr/lib64/quagga/libospf.so.0(+0x2f71d) [0x7fbfd7f1d71d]
> 2018/02/16 18:32:26 OSPF: [bt 6]
> /usr/lib64/quagga/libospf.so.0(ospf_read+0x149e) [0x7fbfd7f200be]
> 2018/02/16 18:32:26 OSPF: [bt 7]
> /usr/lib64/quagga/libzebra.so.1(+0x282b2) [0x7fbfd7ca22b2]
> 2018/02/16 18:32:26 OSPF: [bt 8]
> /usr/lib64/quagga/libzebra.so.1(thread_main+0x18) [0x7fbfd7ca3838]
> 2018/02/16 18:32:26 OSPF: [bt 9] ospfd(main+0x337) [0x401b07]
> 2018/02/16 18:32:26 OSPF: [bt 10]
> /lib64/libc.so.6(__libc_start_main+0xfd) [0x3d4f01ed1d]
> 2018/02/16 18:32:26 OSPF: [bt 11] ospfd() [0x401669]
> 2018/02/16 18:32:26 OSPF: Current thread not known/applicable
>
> What can be a troubleshooting procedure?
>
>
> Regards, Ivan Kuznetsov
> SOLVO ltd
>
> ___
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-users
>
___
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

[quagga-users 14935] Assertion failed in ospfd 1.2.3

[Ivan Kuznetsov]

Hello

I try to setup a test software router under Linux (Oracle Linux 6 
x86_64) and Quagga 1.2.3. ospfd being started exited a few seconds after 
with assertion fault. It seems that is a time of first multicast network 
packet received. OSPF configuration is quite simple :


interface eth0
!
interface eth0.3
 ip ospf authentication-key 
!
interface eth1
!
interface eth2
!
interface eth3
!
interface lo
!
router ospf
 ospf router-id 172.16.83.71
 auto-cost reference-bandwidth 1000
 passive-interface eth0
 passive-interface eth1
 passive-interface eth2
 passive-interface eth3
 network 172.16.83.71/26 area 172.16.80.0
 area 172.16.80.0 authentication
!
line vty

Quagga 1.2.2 at the same computer and configuration works as desired.

I built 1.2.3 RPM using quagga.spec file from tarball with only cosmetic 
changes. It is near identical against one from 1.2.2. Building 
environment is the same


Here is crashlog:

2018/02/16 18:32:26 OSPF: Assertion `thread->master != ((void *)0) && 
thread != ((void *)0)' failed in file thread.c, line 607, function 
thread_add_unuse

2018/02/16 18:32:26 OSPF: Backtrace for 12 stack frames:
2018/02/16 18:32:26 OSPF: [bt 0] 
/usr/lib64/quagga/libzebra.so.1(zlog_backtrace+0x35) [0x7fbfd7cb2ea5]
2018/02/16 18:32:26 OSPF: [bt 1] 
/usr/lib64/quagga/libzebra.so.1(_zlog_assert_failed+0x67) [0x7fbfd7cb3027]
2018/02/16 18:32:26 OSPF: [bt 2] 
/usr/lib64/quagga/libzebra.so.1(+0x27cfe) [0x7fbfd7ca1cfe]
2018/02/16 18:32:26 OSPF: [bt 3] 
/usr/lib64/quagga/libzebra.so.1(+0x28389) [0x7fbfd7ca2389]
2018/02/16 18:32:26 OSPF: [bt 4] 
/usr/lib64/quagga/libzebra.so.1(funcname_thread_execute+0x4c) 
[0x7fbfd7ca30cc]
2018/02/16 18:32:26 OSPF: [bt 5] 
/usr/lib64/quagga/libospf.so.0(+0x2f71d) [0x7fbfd7f1d71d]
2018/02/16 18:32:26 OSPF: [bt 6] 
/usr/lib64/quagga/libospf.so.0(ospf_read+0x149e) [0x7fbfd7f200be]
2018/02/16 18:32:26 OSPF: [bt 7] 
/usr/lib64/quagga/libzebra.so.1(+0x282b2) [0x7fbfd7ca22b2]
2018/02/16 18:32:26 OSPF: [bt 8] 
/usr/lib64/quagga/libzebra.so.1(thread_main+0x18) [0x7fbfd7ca3838]

2018/02/16 18:32:26 OSPF: [bt 9] ospfd(main+0x337) [0x401b07]
2018/02/16 18:32:26 OSPF: [bt 10] 
/lib64/libc.so.6(__libc_start_main+0xfd) [0x3d4f01ed1d]

2018/02/16 18:32:26 OSPF: [bt 11] ospfd() [0x401669]
2018/02/16 18:32:26 OSPF: Current thread not known/applicable

What can be a troubleshooting procedure?


Regards, Ivan Kuznetsov
SOLVO ltd

___
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users