I'm seeing crashes in ospf6_write on the `assert(node)`. The only
sequence of events that I see that could possibly cause this to happen
is this:
a) Someone has scheduled a outgoing write to the ospf6->t_write and
placed item(s) on the ospf6->oi_write_q
b) A decision is made in ospf6_send_lsupdate() to send an immediate
packet via a event_execute(..., ospf6_write,....).
c) ospf6_write is called and the oi_write_q is cleaned out.
d) the t_write event is now popped and the oi_write_q is empty
and FRR asserts on the `assert(node)` <crash>
When event_execute is called for ospf6_write, just cancel the t_write
event. If ospf6_write has more data to send at the end of the function
it will reschedule itself. I've only seen this crash one time and am
unable to reliably reproduce this at all. But this is the only mechanism
that I can see that could make this happen, given how little the oi_write_q
is actually touched in code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When we pass an unknown/wrong command and do `systemctl reload frr`, all processes
are killed, and not started up.
Like doing with frr-reload.py, all good:
```
$ /usr/lib/frr/frr-reload.py --reload /etc/frr/frr.conf
vtysh failed to process new configuration: vtysh (mark file) exited with status 2:
b'line 20: % Unknown command: neighbor 192.168.10.123 bfd 300 300\n\n'
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When no ip pim is performed subsequent pim related
configs under the interface also implicitly deleted.
When doing this via frr-reload requires to remove any
explicit no ip pim <blah> lines so delete list.
Testing Done:
running-config:
interface lo
ip pim
ip pim use-source 6.0.0.1
exit
frr.conf:
remove two pim config lines.
interface lo
exit
Before fix:
2023-06-29 23:44:26,062 INFO: Failed to execute interface lo no ip pim use-source 6.0.0.1
2023-06-29 23:44:26,142 INFO: Failed to execute interface lo no ip pim use-source
2023-06-29 23:44:26,221 INFO: Executed "interface lo no ip pim"
After fix:
Only no ip pim executed and rest of the other lines removed from delete
list.
2023-06-30 01:07:32,618 INFO: Executed "interface lo no ip pim"
Signed-off-by: Chirag Shah <chirag@nvidia.com>
When using asic_offload with an asynchronous notification the
rib_route_match_ctx function is testing for distance and tag
being correct against the re.
Normal route notification for static routes is this(well really all routes):
a) zebra dplane generates a ctx to send to the dplane for route install
b) dplane installs it in the kernel
c) if the dplane_fpm_nl.c module is being used it installs it.
d) The context's success code is set to it worked and passes the context
back up to zebra for processing.
e) Zebra master receives this and checks the distance and tag are correct
for static routes and accepts the route and marks it installed.
If the operator is using a wait for install mechansim where the dplane
is asynchronously sending the result back up at a future time *and*
it is using the dplane_fpm_nl.c code where it uses the rt_netlink.c
route parsing code, then there is no way to set distance as that we
do not pass distance to the kernel.
As such static routes were never being properly handled since the re and
context would not match and the route would still be marked as queued.
Modify the code such that the asynchronous path notification for static
routes ignores the distance and tag's as that there is no way to test
for this data from that path at this point in time.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There is no route-map set action to replace any ASN,
or a part of an ASN, with a configured ASN.
The current commit adds a new command to use a configured
ASN as replacement, instead of using the local as number.
> set as-path replace any 65500
Update the 'bgp_set_aspath_replace' test.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
In case the full label stack is used, there may be
a table overrun happening. Avoid it by increasing the
size of the table.
Fixes: 27f4deed0a ("bgpd: update the mpls entry to handle return traffic")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The bmnc pointer is never null. Do not keep the test
on the pointer.
Fixes: 1069425868 ("bgpd: allocate label bound to received mpls vpn routes")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add support for "[no] ip ospf capbility opaque" at the interface
level with the default being capability opaque enabled. The command
"no ip ospf capability opaque" will disable opaque LSA database
exchange and flooding on the interface. A change in configuration
will result in the interface being flapped to update our options
for neighbors but no attempt will be made to purge existing LSAs
as in dense topologies, these may received by neighbors through
different interfaces.
Topotests are added to test both the configuration and the LSA
opaque flooding suppression.
Signed-off-by: Acee <aceelindem@gmail.com>
Crash with empty `ip-protocol`:
```
anlan(config-pbr-map)# match ip-protocol
vtysh: error reading from pbrd: Resource temporarily unavailable (11)Warning: closing connection to pbrd because of an I/O error!
```
So, give warning for empty `ip-protocol`.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
With these changes,
the code ensures that the peer data-structures are accessed
only after it knows that BGPD is not terminating.
Authored-by: Naveen Thanikachalam <nthanikachal@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
Imagine the following scenario:
when a neighbor has an inbound policy set to modify the next hop, but no outbound route-map is configured.
In this case, if(!post_attr && (ROUTE_MAP_OUT_NAME(filter) || bgp_path_suppressed(pi))) returns false, causing rmap_in_change_flag to not be correctly cleared, and mistakenly identified as rmap_out_change_flag, leading to the failure of the subsequent neighbor-nexthop-self command.
Signed-off-by: Jack.zhang <hanyu.zly@alibaba-inc.com>
If this an error, we should use zlog_err, not zlog_info as this is literally
not an information, but an error.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
