Mailing List Archive

On Feb 15, 2018, at 8:29 AM, bg@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.
>
> 2018/02/14 18:40:41 BGP: Performing BGP general scanning
> 2018/02/14 18:40:42 BGP: scanning IPv4 Unicast routing tables
>
> Question:
>
> 1) Can I turn off (disable) "BGP general scanning" (command 'bgp scan-time <5-60>') ? Is this a good idea in my case ?

That seems unlikely to be a good idea.

> 2) Can I perform "BGP general scanning" on a specific processor core, not chaotic ?

IIRC, bgpd is entirely single-threaded. It should be trivial to bind it to a single core using taskset on Linux (or the equivalent, on another OS). You can do this while it's running, or you can start it that way - modify the rc file that starts quagga & bgpd (or whatever you're using to get it started on boot).

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

2018-02-15 22:21, Alexis Rosen ???????:
> On Feb 15, 2018, at 8:29 AM, bg@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.
>>
>> 2018/02/14 18:40:41 BGP: Performing BGP general scanning
>> 2018/02/14 18:40:42 BGP: scanning IPv4 Unicast routing tables
>>
>> Question:
>>
>> 1) Can I turn off (disable) "BGP general scanning" (command 'bgp
>> scan-time <5-60>') ? Is this a good idea in my case ?
>
> That seems unlikely to be a good idea.

Thank you Alex.

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?


>
>> 2) Can I perform "BGP general scanning" on a specific processor core,
>> not chaotic ?
>
> IIRC, bgpd is entirely single-threaded. It should be trivial to bind
> it to a single core using taskset on Linux (or the equivalent, on
> another OS). You can do this while it's running, or you can start it
> that way - modify the rc file that starts quagga & bgpd (or whatever
> you're using to get it started on boot).
>
> /a
> _______________________________________________
> 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

On Thu, Feb 15, 2018 at 7:05 PM, <bg@it-mark.net> wrote:
> 2018-02-15 22:21, Alexis Rosen ???????:
>> On Feb 15, 2018, at 8:29 AM, bg@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.

Regards,
Bill Herrin


--
William Herrin ................ herrin@dirtside.com bill@herrin.us
Dirtside Systems ......... Web: <http://www.dirtside.com/>

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

2018-02-16 04:12, William Herrin ???????:

> On Thu, Feb 15, 2018 at 7:05 PM, <bg@it-mark.net> wrote:
>> 2018-02-15 22:21, Alexis Rosen ???????:
>>> On Feb 15, 2018, at 8:29 AM, bg@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

On Fri, Feb 16, 2018 at 5:21 PM, <bg@it-mark.net> 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 ................ herrin@dirtside.com bill@herrin.us
Dirtside Systems ......... Web: <http://www.dirtside.com/>
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

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

2018-02-17 01:39, 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.

:)

Universal software is good, but the software is configured to adapt my
specific conditions and circumstances better and more productive. That
was already so.
Although agreeing this way may turn out to be difficult. And so it was
already :)


Thank you for your attention to my questions.


>
> Nick


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