This commits attempts to fix a problem that occurs when mpls-te gets
removed from ospfd config. Mpls-te has an inter-as option, which can be
set to Off/Area/AS. Whenever the inter-as takes "Area" or "AS" as a
value, this value will not be cleaned after removing mpls-te or after
removing the ospf router. Therefore, if mpls-te is configured with
inter-as AS or Area and we remove mpls-te or the ospf router, the
inter-as will still preserve its value; therefore, next time mpls-te is
enabled, it will automatically inherits the previous inter-as value
(either Area or AS). This leads to wrong configuration, which can be a
problem for frr_reload.py.
The commits forces mpls-te to reset inter-as to Off before it mpls-te
gets removed from the configuration and before the ospf router gets
removed.
Signed-off-by: Carlo Galiotto <carlo@voltanet.io>
Modify code to add JSON format output in show command
"show ipv6 ospf6 interface traffic" with proper formating
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
Modify code to add JSON format output in show command
"show ipv6 ospf6 redistribute" with proper formating
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
The `enum zclient_send_status` enum needs to be extended
throughout the code base to use the new states and
to fix up places where we tested against the return
value being non zero.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add a `enum zclient_send_status` for appropriate handling
of return codes from zclient_send_message. Touch all the places
where we handle this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Have sharpd notice that when sending routes to zebra that the
underlying system has buffered data and to pause sending
more data to zebra until such time we get a callback that
the write was successful to zebra.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
These functions are never called outside of sharp_zebra.c, re-arrange
a little to make the inclusions in sharp_zebra.h not needed and
to also have these functions return whether or not the underlying
buffering system was invoked in stream sending.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When FRR sends data over the ZAPI protocol from the upper levels to zebra, indicate
to the calling functions that we have started buffering data to be sent if the
socket is full underneath it.
Also add a call back function `zebra_buffer_write_ready` that we can call
when an upper level protocol's socket buffer has been drained.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add a command that allows FRR to know it's being used with
an underlying asic offload, from the linux kernel perspective.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The linux kernel is getting RTM_F_OFFLOAD_FAILED for kernel routes
that have failed to offload. Write the code
to receive these notifications from the linux kernel
and store that data for display about the routes.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Update to latest kernel version of rtnetlink.h We are
really bringing in the RTM_F_OFFLOAD_FAILED change.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Convert usage of the attr->evpn_overlay to get/set functionality.
Future commits will allow us to abstract this data to when
we actually need it for the `struct attr`.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Abstract the access of `attr->cluster` to appropriate
accessor/set functionality.
Future commits will allow us to move this data around
to make `struct attr` smaller.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Convert the `struct attr`->ipv6_ecommunity to use
accessor functions. We'll be able to reduce memory
usage in the `struct bgp_attr` by doing this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add an accessor for the bgp_attr.pmsi_tnl_type to allow
us to abstract where it is. Every attribute is paying
the price of this bit of data as part of `struct bgp_attr`
In the future we'll move it elsewhere.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When we delete the bgp_path_info_extra data structure free
the aggr_suppressors data structure that was left dangling.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Move the FOREACH_AFI_SAFI macro from bgpd.h to zebra.h( GLOBAL's YOUALL )
Then convert all the places that have the two level for loop to
iterate over all afi/safis
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
On redistribution into isis we were creating a table for
handling the redistributed routes, but never cleaning them
up on shutdown properly. Do so.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The recent change to use %pFX missed a code path
where we were displaying a buf that was uninited.
Display the prefix as intended.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There exists a code path where the esi would be passed
to a debug without the esi being setup with any values
causing us to display what ever is on the stack.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When isis is being shutdown the area->spf_timer thread has
special data assigned to that was never being freed.
Free this data.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The interface address delete callback from zebra was not
deleting the ifc that was created as per normal work methodologies
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We are temporarily allocing memory to show lcommunity
information. We then immediately drop it. Account for
that memory properly.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When iterating over the bgp_dest table, using this pattern:
for (dest = bgp_table_top(table); dest;
dest = bgp_route_next(dest)) {
If the code breaks or returns in the middle we will not have
properly unlocked the node as that bgp_table_top locks the top
dest and bgp_route_next locks the next dest and unlocks the old
dest.
From code inspection I have found a bunch of places that
we either return in the middle of or a break is issued.
Add appropriate unlocks.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The route_map_object_t was being used to track what protocol we were
being called against. But each protocol was only ever calling itself.
So we had a variable that was only ever being passed in from route_map_apply
that had to be carried against and everyone was testing if that variable
was for their own stack.
Clean up this route_map_object_t from the entire system. We should
speed some stuff up. Yes I know not a bunch but this will add up.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If a route-map in zebra has `set src X` and the interface
X is on has not been configured yet, we are rejecting the command
outright. This is a problem on boot up especially( and where I
found this issue ) in that interfaces *can* and *will* be slow
on startup and config can easily be read in *before* the
interface has an ip address.
Let's modify zebra to just warn to the user we may have a problem
and let the chips fall where they may.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When entering values for maximum-path if the user
has entered a value to respect from the bgp cli `-e X`
that is the maximum value we should use when accepting
values from the user.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
As part of normal processing we allow bgp commands to walk
up the command node chain. We are experiencing this crash:
Thread 1 "bgpd" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
assertion=0x7ffff7f3ba4f "set", file=0x7ffff7f3ba44 "lib/yang.c", line=413, function=<optimized out>)
at assert.c:92
line=413, function=0x7ffff7f3bc50 <__PRETTY_FUNCTION__.9> "yang_dnode_get") at assert.c:101
vty=0x5555561715a0, argc=3, argv=0x555558601620) at bgpd/bgp_vty.c:9568
cmd=0x0) at lib/command.c:937
at lib/command.c:997
matched=0x0, vtysh=0) at lib/command.c:1161
at lib/vty.c:517
(gdb)
9582 bgp_glb_dnode = yang_dnode_get(vty->candidate_config->dnode,
(gdb) p vty->xpath
$8 = {
"/frr-routing:routing/control-plane-protocols/control-plane-protocol[type='frr-bgp:bgp'][name='bgp'][vrf='default']/frr-bgp:bgp", '\000' <repeats 897 times>, '\000' <repeats 1023 times>, '\000' <repeats 1023 times>,
'\000' <repeats 1023 times>, '\000' <repeats 1023 times>, '\000' <repeats 1023 times>, '\000' <repeats 1023 times>,
'\000' <repeats 1023 times>}
(gdb) p vty->xpath_index
$9 = 0
(gdb)
We are effectively sending in an array index based upon vty->xpath_index( which is zero) but
the VTY_CURR_XPATH macro subtracts 1 from that value to find the appropriate xpath to use.
This of course subtracts 1 from 0 and we underflow the array.
The relevant section in a config file is this:
address-family ipv6 flowspec
bgp maxim...
Effectively we were trying to walk up the command chain for flowspec to see
if the command is entered correctly. There is a function vty_check_node_for_xpath_decrement
that was looking at bgp sub-modes to make the decision to allow us to decrement
the vty->xpath_index which did not have the v4 or v6 flowspec bgp sub modes in the
check.
Adding them in fixes the problem.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Some of the `show memory` strings in bgp are longer than the
columns we have allocated for it. Shorten some strings to
make them fit and have the output pleasing to the eye.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
1. Added convergence step just after BGP-GR capablities are exchanged and clear bgp
is performed , reason for this is, in few machine bgp sessions are taking more time
to come up.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
