set metric shows -metric and +metric I have no idea how to use that, with IOS you can use the + or - with the metric number to either add to the existing metric or subtract I cant seem to duplicate that effect using the available syntax, in any event, I would think that configuration syntax compatibility in this instant would be a plus.
On Sun, 28 Feb 2021 at 08:34, Joe Maimon <jmaimon@jmaimon.com> wrote:
set metric shows -metric and +metric
I have no idea how to use that, with IOS you can use the + or - with the metric number to either add to the existing metric or subtract
And the docs do not adequately explain the use of metric +/-, either? - https://docs.frrouting.org/en/latest/search.html?q=set+metric&check_keywords... - https://docs.frrouting.org/en/latest/routemap.html#clicmd-setmetric%3C[+|-](1-4294967295)|rtt|+rtt|-rtt%3E
I can't seem to duplicate that effect using the available syntax, in any event, I would think that configuration syntax compatibility in this instant would be a plus.
Specifically, what are you trying to do? Configuration examples (+ FRR version) would help me and other users understanding your "test case" ;) -- Chriztoffer
Chriztoffer Hansen wrote:
On Sun, 28 Feb 2021 at 08:34, Joe Maimon <jmaimon@jmaimon.com> wrote:
set metric shows -metric and +metric
I have no idea how to use that, with IOS you can use the + or - with the metric number to either add to the existing metric or subtract And the docs do not adequately explain the use of metric +/-, either?
- https://docs.frrouting.org/en/latest/search.html?q=set+metric&check_keywords... - https://docs.frrouting.org/en/latest/routemap.html#clicmd-setmetric%3C[+|-](1-4294967295)|rtt|+rtt|-rtt%3E
Yes, but 1) vtysh does not show the +- symbol 2) the code does not contain the +- symbol with the number range 3) entering +- symbol with a number fails. This much appears to have been fixed between 7.4 and 7.7 so lets put it to rest. -metric and +metric appear to have been removed and - now appears in the configuration parser and is accepted.
Chriztoffer Hansen wrote:
Specifically, what are you trying to do?
I am trying to run a cloud VM for targetted BGP route optimization with nhrp gre tunnels running OSPF for an igp and BGP to hopefully carry full tables. I have gotten pretty far along on this project, but a couple sticking points remain. - BGP full tables loading/kernel-route syncing can easily lock up the processes to the point where they dont respond properly, and more problematic, watchfrr kills them. Rinse, repeat. In other words, it may not be enough to log SLOW THREAD: task zserv_process_messages (55f1e2bb0750) ran for 7819ms (cpu time 253ms) but actually implement some sort of time based thread yielding right in middle of large batch operations, such as loading 800000 routes or so. - zebra protocol import route-map is strangely one sided. It would be ever so much more powerful to control both what protocols export to zebra and what they import from zebra, as well as allowing protocols to distinguish the source of the route from zebra.
On Sun, 28 Feb 2021 at 19:04, Joe Maimon <jmaimon@jmaimon.com> wrote:
- zebra protocol import route-map is strangely one sided. It would be ever so much more powerful to control both what protocols export to zebra and what they import from zebra, as well as allowing protocols to distinguish the source of the route from zebra.
... IP protocol cmd *might* be something you can take a look for filtering route im-/export between zebra & daemons https://docs.frrouting.org/en/latest/zebra.html#zebra-route-filtering -- Chriztoffer
Joe Maimon wrote:
points remain.
- BGP full tables loading/kernel-route syncing can easily lock up the processes to the point where they dont respond properly, and more problematic, watchfrr kills them. Rinse, repeat. This hidden gem looks like it might work crudely, but effectively.
zebra zapi-packets 250 Initial tests are promising. I can run out of memory on the tiny VM before processes lock up or slow thread to death, so far so good.
In other words, it may not be enough to log SLOW THREAD: task zserv_process_messages (55f1e2bb0750) ran for 7819ms (cpu time 253ms) but actually implement some sort of time based thread yielding right in middle of large batch operations, such as loading 800000 routes or so.
- zebra protocol import route-map is strangely one sided. It would be ever so much more powerful to control both what protocols export to zebra and what they import from zebra, as well as allowing protocols to distinguish the source of the route from zebra.
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
Somewhat surprised you are seeing 7-8 second runtime as the default number of messages to process before yielding is relatively small at 1000. But yes, lowering that number via zapi-packets is appropriate.
zebra protocol import route-map is strangely one sided. It would be ever so much more powerful to control both what protocols export to zebra and what they import from zebra, as well as allowing protocols to distinguish the source of the route from zebra
Quite possible I am misunderstanding but it sounds like you're talking about redistribution, e.g. https://docs.frrouting.org/en/latest/bgp.html#redistribution ________________________________ From: frog <frog-bounces@lists.frrouting.org> on behalf of Joe Maimon <jmaimon@jmaimon.com> Sent: Sunday, February 28, 2021 11:45 PM To: Chriztoffer Hansen <ch@ntrv.dk> Cc: FRRouting Operator Group - Users List <frog@lists.frrouting.org> Subject: Re: [FROG] route-map set metric External email: Use caution opening links or attachments Joe Maimon wrote:
points remain.
- BGP full tables loading/kernel-route syncing can easily lock up the processes to the point where they dont respond properly, and more problematic, watchfrr kills them. Rinse, repeat. This hidden gem looks like it might work crudely, but effectively.
zebra zapi-packets 250 Initial tests are promising. I can run out of memory on the tiny VM before processes lock up or slow thread to death, so far so good.
In other words, it may not be enough to log SLOW THREAD: task zserv_process_messages (55f1e2bb0750) ran for 7819ms (cpu time 253ms) but actually implement some sort of time based thread yielding right in middle of large batch operations, such as loading 800000 routes or so.
- zebra protocol import route-map is strangely one sided. It would be ever so much more powerful to control both what protocols export to zebra and what they import from zebra, as well as allowing protocols to distinguish the source of the route from zebra.
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
Not surprising. Its a cloud VM with 512Mb ram and 8gb disk, single CPU, 2gb swapfile. Quentin Young wrote:
Somewhat surprised you are seeing 7-8 second runtime as the default number of messages to process before yielding is relatively small at 1000. But yes, lowering that number via zapi-packets is appropriate.
zebra protocol import route-map is strangely one sided. It would be ever so much more powerful to control both what protocols export to zebra and what they import from zebra, as well as allowing protocols to distinguish the source of the route from zebra
Quite possible I am misunderstanding but it sounds like you're talking about redistribution, e.g. https://docs.frrouting.org/en/latest/bgp.html#redistribution
------------------------------------------------------------------------ *From:* frog <frog-bounces@lists.frrouting.org> on behalf of Joe Maimon <jmaimon@jmaimon.com> *Sent:* Sunday, February 28, 2021 11:45 PM *To:* Chriztoffer Hansen <ch@ntrv.dk> *Cc:* FRRouting Operator Group - Users List <frog@lists.frrouting.org> *Subject:* Re: [FROG] route-map set metric External email: Use caution opening links or attachments
Joe Maimon wrote:
points remain.
- BGP full tables loading/kernel-route syncing can easily lock up the processes to the point where they dont respond properly, and more problematic, watchfrr kills them. Rinse, repeat. This hidden gem looks like it might work crudely, but effectively.
zebra zapi-packets 250
Initial tests are promising. I can run out of memory on the tiny VM before processes lock up or slow thread to death, so far so good.
In other words, it may not be enough to log SLOW THREAD: task zserv_process_messages (55f1e2bb0750) ran for 7819ms (cpu time 253ms) but actually implement some sort of time based thread yielding right in middle of large batch operations, such as loading 800000 routes
or so.
- zebra protocol import route-map is strangely one sided. It would be ever so much more powerful to control both what protocols export to zebra and what they import from zebra, as well as allowing protocols to distinguish the source of the route from zebra.
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
Not surprising. Its a cloud VM with 512 MB Ram and 8 GB disk, single CPU, 2 GB swapfile.
... Can't say I am surprised. Cheap HW/VPS :( Have you tried to rerun your tests on higher-spec VPS? E.g. >= 2 GB Memory, >= 15 GB disk space, >= 2 (v)Cores? https://github.com/masonr/yet-another-bench-script/blob/master/yabs.sh <-- *if* you want to get a feel for the performance of it (the VPS). -- Chriztoffer
Chriztoffer Hansen wrote:
Not surprising. Its a cloud VM with 512 MB Ram and 8 GB disk, single CPU, 2 GB swapfile. ... Can't say I am surprised. Cheap HW/VPS :( Have you tried to rerun your tests on higher-spec VPS?
E.g. >= 2 GB Memory, >= 15 GB disk space, >= 2 (v)Cores?
https://github.com/masonr/yet-another-bench-script/blob/master/yabs.sh <-- *if* you want to get a feel for the performance of it (the VPS).
I specifically want to be able to run this on the lowest common denominator. Joe
participants (3)
-
Chriztoffer Hansen -
Joe Maimon -
Quentin Young