The following subcodes are defined for the Cease NOTIFICATION
message:
Subcode Symbolic Name
1 Maximum Number of Prefixes Reached
2 Administrative Shutdown
3 Peer De-configured
4 Administrative Reset
5 Connection Rejected
6 Other Configuration Change
7 Connection Collision Resolution
8 Out of Resources
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
With the current code, in a topology like this:
r1 ---- 0.0.0.0 ---- r2(ABR) ---- 1.1.1.1 -----r3(ASBR)
NSSA
where r3 is redistributing statics within the NSSA area, the ABR (r2)
is translating type-7 lsa to type-5.
Everytime the function ospf6_abr_nssa_task() is executed all translated
type-5 are aged out and refreshed for no reason. So for instance having 3
lsas already advertised:
r1# sh ipv6 os database
AS Scoped Link State Database
Type LSId AdvRouter Age SeqNum Payload
ASE 0.0.0.1 2.2.2.2 39 80000001 3:3::3/128
ASE 0.0.0.2 2.2.2.2 39 80000001 4:4::4/128
ASE 0.0.0.3 2.2.2.2 39 80000001 5:5::5/128
Adversting a new route from r3:
r3(config)# ipv6 route 6:6::6/128 Null0
r1# sh ipv6 os database
AS Scoped Link State Database
Type LSId AdvRouter Age SeqNum Payload
ASE 0.0.0.1 2.2.2.2 124 80000001 3:3::3/128
ASE 0.0.0.2 2.2.2.2 124 80000001 4:4::4/128
ASE 0.0.0.3 2.2.2.2 124 80000001 5:5::5/128
ASE 0.0.0.4 2.2.2.2 8 80000001 6:6::6/128
That seems okay, however a few seconds later we see all prefixes refreshed
r1# sh ipv6 os database
AS Scoped Link State Database
Type LSId AdvRouter Age SeqNum Payload
ASE 0.0.0.1 2.2.2.2 3600 80000001 3:3::3/128
ASE 0.0.0.2 2.2.2.2 3600 80000001 4:4::4/128
ASE 0.0.0.3 2.2.2.2 3600 80000001 5:5::5/128
ASE 0.0.0.4 2.2.2.2 3600 80000001 6:6::6/128
ASE 0.0.0.5 2.2.2.2 3 80000001 3:3::3/128
ASE 0.0.0.6 2.2.2.2 3 80000001 4:4::4/128
ASE 0.0.0.7 2.2.2.2 3 80000001 5:5::5/128
ASE 0.0.0.8 2.2.2.2 3 80000001 6:6::6/128
This PR prevents the LSA of being refreshed by unsetting the OSPF6_LSA_UNAPPROVED
flag so advertising the last prefix will not refresh all of them:
r1# sh ipv6 os database
AS Scoped Link State Database
Type LSId AdvRouter Age SeqNum Payload
ASE 0.0.0.1 2.2.2.2 90 80000001 3:3::3/128
ASE 0.0.0.2 2.2.2.2 47 80000001 4:4::4/128
ASE 0.0.0.3 2.2.2.2 35 80000001 5:5::5/128
ASE 0.0.0.4 2.2.2.2 7 80000001 6:6::6/128
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
Add ability to set your own env for the version of the docker
container alpine image. This is useful for applications like GNS3
who pin a specific version to look for when they boot up. When you build
locally to test your code you can just set the version to 0 so you don't
have to update configs/scripts looking for a specific image version.
Also fix a shebang in docker start for alpine.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
This function is sure to return correct value by "assert", so the
checking its return value should be removed.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
Updating babel default configuration parameters rtt-min and
max-rtt-penalty according to the actual implementation.
Signed-off-by: Adriano Marto Reis <adrianomarto@gmail.com>
* Presenting the configuration parameters enable-timestamps,
max-rtt-penalty, rtt-min, and rtt-max.
* Using #defines for the default configuration values instead of magic
numbers.
* rtt-max and rtt-min are entered and presented in milliseconds, but
stored and internally used in microseconds.
Signed-off-by: Adriano Marto Reis <adrianomarto@gmail.com>
Currently, it is possible to rename the default VRF either by passing
`-o` option to zebra or by creating a file in `/var/run/netns` and
binding it to `/proc/self/ns/net`.
In both cases, only zebra knows about the rename and other daemons learn
about it only after they connect to zebra. This is a problem, because
daemons may read their config before they connect to zebra. To handle
this rename after the config is read, we have some special code in every
single daemon, which is not very bad but not desirable in my opinion.
But things are getting worse when we need to handle this in northbound
layer as we have to manually rewrite the config nodes. This approach is
already hacky, but still works as every daemon handles its own NB
structures. But it is completely incompatible with the central
management daemon architecture we are aiming for, as mgmtd doesn't even
have a connection with zebra to learn from it. And it shouldn't have it,
because operational state changes should never affect configuration.
To solve the problem and simplify the code, I propose to expand the `-o`
option to all daemons. By using the startup option, we let daemons know
about the rename before they read their configs so we don't need any
special code to deal with it. There's an easy way to pass the option to
all daemons by using `frr_global_options` variable.
Unfortunately, the second way of renaming by creating a file in
`/var/run/netns` is incompatible with the new mgmtd architecture.
Theoretically, we could force daemons to read their configs only after
they connect to zebra, but it means adding even more code to handle a
very specific use-case. And anyway this won't work for mgmtd as it
doesn't have a connection with zebra. So I had to remove this option.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Always free the locally allocated attribute not the one we are using for
return. This fixes a memory leak and a crash when AS Path is set with
route-map.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Currently the Wait for Install code ( bgp_suppress_fib ) does
not properly handle two states from zebra: ROUTE_INSTALL_FAILED
and BETTER_ADMIN_DISTANCE_WON. Pre this change the WFI code
would just never notify our peers about a route install failure
but more is needed. In the ROUTE_INSTALL_FAILED and the
BETTER_ADMIN_DISTANCE_WON we need to notify our peers with
a withdrawal about the route, else we will continue to
draw traffic to us when we cannot legally do so.
Why is this needed? In either case imagine that we've already
received a bgp route, installed it and sent to our peers.
In the Better admin distance won case, say a static route is installed
at this point in time we must stop advertising the route through
us since we are not installed. As such a withdrawal must be sent.
In the ROUTE_INSTALL_FAILED case, the code was not properly handling
the situation where we have Route A, it was successfully installed
and then we received a update to Route A that was attempted to be
installed but failed. In this case we also need to send a withdrawal
Finally update the bgp_suppress_fib topotest to test both of these
situations.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If soft-reconfiguration is enabled, bgp_adj_in_set will be called
from bgp_update and bgp_adj_in_set will call bgp_attr_intern to intern
attr pointer. If given attr isn't found in attrhash, hash_get will call
bgp_attr_hash_alloc to allocate new attr structure. In
bgp_attr_hash_alloc, NULL will be assigned to srv6_vpn field and
srv6_l3vpn field in origin attr pointer. attr->srv6_vpn and
attr->srv6_l3vpn are interned in bgp_attr_intern, so NULL assignment
isn't needed.
And, these fields are used later in bgp_update to set SRv6 information
to bgp_path_info. If bgp_attr_hash_alloc assign NULL to these fields,
SRv6 information will be lost and incorrect routes are inserted into
data-plane.
Signed-off-by: Ryoga Saito <contact@proelbtn.com>
