| Age | Commit message (Collapse) | Author |
|---|
|
As mgmtd now implements vty for staticd, it's logical to output the
configuration from there as well. Fully-converted backend daemons should
not handle vty commands at all.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
|
|
Provive hooks for srv6 segs SIDs stack yang model.
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
|
|
Done with a combination of regex'ing and banging my head against a wall.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
Implement all BFD integration northbound callbacks and integrate BFD
with `staticd` route installation procedure.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
|
|
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
|
|
Compile with v2.0.0 tag of `libyang2` branch of:
https://github.com/CESNET/libyang
staticd init load time of 10k routes now 6s vs ly1 time of 150s
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
`config.h` has all the defines from autoconf, which may include things
that switch behavior of other included headers (e.g. _GNU_SOURCE
enabling prototypes for additional functions.)
So, the first include in any `.c` file must be either `config.h` (with
the appropriate guard) or `zebra.h` (which includes `config.h` first
thing.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
[yang,staticd]: remove when condition from static nexthop om
|
|
At present, libyang validate api takes longer time to complete
for a transaction to complete if the same config is re-applied.
For instance if set of static routes are reapplied the config
completion takes longer than it took initial time.
One of the solution is to remove when statement from staticd nexthop yang OM.
When condition adds peformance toll on libyang's validate api.
The same when condition checks are done in frr northbound
validation phase (which are must faster).
With this change, if the same static routes are configured
agian and again, the time to completion does not go up and
perfomance does not degrade.
Ticket:CM-32530
Testing Done:
Configure 400 static routes across two vrfs and keep re-applying them.
The time to complete the config remains in few seconds.
Before:
root@bharat:~/stash/frr4# time vtysh -f static_route_cfg
real 0m19.877s
user 0m0.263s
sys 0m0.014s
After:
root@bharat:~/stash/frr4# time vtysh -f static_route_cfg
real 0m3.857s
user 0m0.239s
sys 0m0.034s
Co-developed-by: VishalDhingra <vdhingra@vmware.com>
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
updated callback methods based on autogenerated code.
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
|
|
Configuration example:
ip route 9.9.9.9/32 6.6.6.6 color 123
The SR Policy to be chosen is uniquely identified by the policy
endpoint (6.6.6.6) and the SR-TE color (123). Traffic will be
augmented with an MPLS label stack according to the active
candidate path of that particular policy.
Co-authored-by: GalaxyGorilla <sascha@netdef.org>
Signed-off-by: Sebastien Merle <sebastien@netdef.org>
|
|
1. Modifies the data structs to make the distance, tag and table-id
property of a route, i.e created a hireachical data struct to save
route and nexthop information.
2. Backend northbound implementation
Signed-off-by: VishalDhingra <vdhingra@vmware.com>
|
