Prior to this fix, restarting the client just failed b/c the code tried to
"refresh" the existing LSA being added, except that code checked for meta-data
to exist, which was deleted when the client disconnected previously (or had
never connected and the LSA state was picked up from the network).
Signed-off-by: Christian Hopps <chopps@labn.net>
Reachable router information is used by OSPF opaque clients in order
to determine if the router advertising the opaque LSA data is
reachable (i.e., 2-way conectivity check).
Signed-off-by: Christian Hopps <chopps@labn.net>
The reachable router table is used by OSPF opaque clients in order to
determine if the router advertising the opaque LSA data is
reachable (i.e., 2-way conectivity check).
Signed-off-by: Christian Hopps <chopps@labn.net>
And drop checkout action - not needed.
Due to the dangers inherent to automatic processing of PRs, GitHub’s standard
pull_request workflow trigger by default prevents write permissions and
secrets access to the target repository. However, in some scenarios such
access is needed to properly process the PR.
To this end the pull_request_target workflow trigger was introduced.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Should solve this:
```
Error: HttpError: Resource not accessible by integration
Error: Resource not accessible by integration
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The usage of zebra dplane makes the job asyncronous which implies
that a given job will try to add an iptable, while the second job
will not know that its iptable is the same as the former one.
The below exabgp rules stand for two bgp flowspec rules sent to
the bgp device:
flow {
route {match {
source 185.228.172.73/32;
destination 0.0.0.0/0;
source-port >=49156&<=49159;
}then {redirect 213.242.114.113;}}
route {match {
source 185.228.172.73/32;
destination 0.0.0.0/0;
source-port >=49160&<=49163;
}then {redirect 213.242.114.113;}}
}
This rule creates a single iptable, but in fact, the same iptable
name is appended twice. This results in duplicated entries in the
iptables context. This also results in contexts not flushed, when
BGP session or 'flush' operation is performed.
iptables-save:
[..]
-A PREROUTING -m set --match-set match0x55baf4c25cb0 src,src -g match0x55baf4c25cb0
-A PREROUTING -m set --match-set match0x55baf4c25cb0 src,src -g match0x55baf4c25cb0
-A match0x55baf4c25cb0 -j MARK --set-xmark 0x100/0xffffffff
-A match0x55baf4c25cb0 -j ACCEPT
-A match0x55baf4c25cb0 -j MARK --set-xmark 0x100/0xffffffff
-A match0x55baf4c25cb0 -j ACCEPT
[..]
This commit addresses this issue, by checking that an iptable
context is not already being processed. A flag is added in the
original iptable context, and a check is done if the iptable
context is not already being processed for install or uinstall.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This is already handled by a separate command `show rpki cache-server`.
Probably just copy/paste error.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The cspf_topo1 test is comparing the adj-sid value that is
assigned dynamically based upon bring up order. Under very
large scale this order changes causing the test to fail.
Since the adj-sid is dynamically allocated and appears to
be tested elsewhere, let's remove it from the grab all check.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This test is sometimes failing under severe load. Give some time
for the linux rule installation to actually be registered by the
system before declaring failure.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Seems replacement is not working when referenced, only when used directly
in the text |PACKAGE_URL|.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Move a few things into places they actually belong, and reduce the
number of places we have `#ifdev HAVE_RTADV`. Just overall code
prettification.
... I had actually done this quite a while ago while doing some other
random hacking and thought it more useful to not be sitting on it on my
disk...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Allowing only 4 seconds for a bfd test to synchronize is going
to run into problems on extremely loaded systems. The test
system should value it actually converged over it actually
converged in a reasonable time, especially on test systems
that are loaded because of many multiples of tests running
at the same time. If it is important to actually test
that something got done by the RFC, the CI system as it
is currently written is not the correct place for this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
