RARE user and assistance email list

["mc36" <>]

-------- Forwarded Message --------
Subject: Re: additional lib needed for builds
Date: Wed, 6 Jul 2022 09:07:20 +0200
From: mc36 <>
Reply-To: 
To: 



On 7/4/22 13:09, mc36 wrote:
> > > hi,
> > >
> > > so i started adding that knob when i realized that it's already there:)
> > >
> > > sid#show ipv4 bgp 65535 unicast ecmp
> > > prefix                           alts   ecmp   best     proto             
> > > source
> > > 0.0.0.0/0                     2         true   true     bgp4 65535   10.5.1.10
> > > 0.0.0.0/0                     2         true   false   bgp4 65535   10.26.26.2
> > > 10.1.1.48/30               2         true   true     bgp4 65535   10.5.1.10
> > > 10.1.1.48/30               2         true   false   bgp4 65535   10.26.26.2
> > > 10.1.1.72/30               2         true   true     bgp4 65535   10.5.1.10
> > > 10.1.1.72/30               2         true   false   bgp4 65535   10.26.26.2
> > > 10.1.1.92/30               2         true   true     bgp4 65535   10.5.1.10
> > > 10.1.1.92/30               2         true   false   bgp4 65535   10.26.26.2
> > > 10.1.1.120/30             2         true   true     bgp4 65535   10.5.1.10
> > > 10.1.1.120/30             2         true   false   bgp4 65535   10.26.26.2
> > Why ecmp in this output always true even if ecmp was not enabled in router 
> > bgp?
> so in that config, ecmp is set: 
> https://github.com/rare-freertr/freeRtr/blob/master/rtr-sw.txt#L506
> but, if you disable the ecmp in the config, you still get the same result 
> because that field is defined as:
> https://github.com/rare-freertr/freeRtr/blob/92686d4f765ce249d4727a10c1d851215883fc06/src/net/freertr/tab/tabRouteEntry.java#L481
> so in freerouter, there is the route entry... it can have N alternatives, 
> each holding route attributes...
> there will be always a single best, which is selected based on the regular 
> bgp best path algorithm...
> and those, where !attr.isOtherBetter(prf.best, false), that is, who are not 
> worse than the best after
> relaxing the ecmp criteria (mostly the age:) are all ecmp candidate paths, 
> forwarding will happen through
> them once you configure ecmp...

> i was thinking about it a bit further and i just renamed that column what it 
> is: candidate....

> > Also it is convenient to see as path and bgp best path in one output.
> for tha, there is sho ipv4 bgp 65535 uni data:
> sid#sho ipv4 bgp 65535 uni data
> prefix                           hop                     metric               
>     aspath
> 0.0.0.0/0                     10.10.10.1       200/170/0/12
> 0.0.0.0/0                     10.10.10.1       200/170/0/12
> 10.1.1.48/30               10.10.10.1       200/170/0/0
> 10.1.1.48/30               10.10.10.1       200/170/0/0
> 10.1.1.72/30               10.10.10.1       200/170/0/0
> 10.1.1.72/30               10.10.10.1       200/170/0/0
> 10.1.1.92/30               10.10.10.1       200/170/0/0
> 10.1.1.92/30               10.10.10.1       200/170/0/0
> 10.1.1.120/30             10.10.10.1       200/170/0/0

well, so i know what command you're looking for, but here, once again, 
freerouter works a bit differently...

so all the stuff in freerouter spread to as much threads as it can... this is 
a key to the scaling imho...

in case of bgp, you have the bgp speaker thread / neighbor, who does the bgp 
update in/out processing...
(btw under the hood, i could easily split these two to 2 threads, but at the 
moment, im fine with the current)

((then you have the per bgp session tcp thread who deals with the tcp related 
work, mostly the transmission))
((all the above happens over a pipe connecting the two components: 
http://www.freertr.org/design.html))

but there is a thing... if i used the single per afi bgp table (to have the 
output you're asking for)
i had to use a kind of locking, so all the above would get invalidated... 
instead, there is the per
neighbor sent table, who keeps a link to the original route entry from the 
update group....
and there is a per neighbor received table...

the per neighbor transmission path uses a thing called recently changed table 
per update group to speed up the operation
per neighbor... this one is the single point which could get locked by a 
given neighbor part of the update group..
but this table is very small, mostly under 10 entries, and never saw it above 
1000, and as soon as a neighbor cannot
cope with the updates (that could result gain size of this table) then it 
gets kicked off from the update group,
that is, the recently changed table kept small...
until the neighbor is kicked off from the incremental update sending, it 
sometimes accesses the update
group's to-be-sent table, when it have enough buffer space, but it is done in 
batches until it can fill
up the inetrnal tcp pipes... and finally, if the given peer's pipes are 
empty, and the lockless sending
found nothing, then it could enter back the update group: it stores the 
tabver does a big fat clone on
the update groups to-be-sent, does the update, and if everything went fine 
then he's back to the group...
(if not, then he's still out, and goto 1

the per neighbor receiving so then stores the updates (after decoding the 
update)... when it changed from
the previous one, then a link placed to the recently changed table if not 
already there (check-before-lock)

the above could be checked by the sho ipv4/6 bgp neigh x.x.x.x afi sent/rece, 
and sho ipv4/6 bgp group 0 uni

and finally, there is the per process bestpath thread (which could be divided 
to per afi) which, if waken,
walks and empties the recent changes table and calculate bestpath for the 
prefixes found there...
it simply populates then the per update group to-be-sent, and recently 
changed tables...

this is how the incremental computation works within the bgp processes in 
freerouter...
and in case of catastrophic events like igp computed changes or so, which 
could affect everything,
there is a big fat full computation round, which, completely rewrites the 
whole per afi bestpath
table by linking all the neighbor's received tables into a single one, best 
table...
(this is what you query by sh ipv4/6 bgp afi data) after doing so, it also 
recomputes all the
update groups to-be-sent tables, and finally vrf/vpls/evpn imports/exports 
involved in the current bgp process..
this latter could be observed by sho ipv4/6 bgp best



after a given process concluded, it wakes the per vrf rib computation....
in case of full recomputation, the fib will also have to do a full 
import/export per safi...
these coudl be observed by sho router ospf4 1 com/red uni
in case of incremental one, it'll also deal with the changes per safi...
this could be observed by sho ipv4/6 proto

br,
cs


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#371): https://groups.io/g/freertr/message/371
Mute This Topic: https://groups.io/mt/92201825/6413194
Group Owner: 
Unsubscribe: https://groups.io/g/freertr/unsub []
-=-=-=-=-=-=-=-=-=-=-=-