Donald Sharp [Tue, 15 Feb 2022 20:53:30 +0000 (15:53 -0500)]
bgpd: Convert bgp error codes for cli input to an enum
Conversion of bgp error codes returned for cli input into
an enum and then properly handling all the error cases
in bgp_vty_return.
Because not all error codes returned were properly handled
in this function there existed configuration examples that
were accepted on the cli without an error message but not
saved.
Fixes: #10589 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Donald Sharp [Tue, 15 Feb 2022 21:04:50 +0000 (16:04 -0500)]
bgpd: Move some error codes to bgp_vty_return handling
BGP_ERR_PEER_GROUP_MEMBER and BGP_ERR_PEER_GROUP_PEER_TYPE_DIFFERENT
both are not handled by bgp_vty_return, but both can be handled by
this function as that there is nothing special going on here.
Donald Sharp [Tue, 15 Feb 2022 20:54:53 +0000 (15:54 -0500)]
bgpd: Remove impossible invalid state
confederations are checking to see that the bgp pointer
is non-null. But it's impossible to have a null pointer
in the cli and in all paths we have already deref'ed the bgp
pointer. Let's remove that error code as that it is impossible
to happen.
Donald Sharp [Mon, 14 Feb 2022 12:57:45 +0000 (07:57 -0500)]
bgp: Add a 15 minute warning to missing policy
Add a 15 minute warning to the logging system when
bgp policy is not setup properly. Operators keep asking
about the missing policy( on upgrade typically ). Let's
try to give them a bit more of a hint when something is
going wrong as that they are clearly missing the other
various places FRR tells them about it.
David Lamparter [Wed, 5 Jan 2022 18:38:17 +0000 (19:38 +0100)]
pim6d: prepare/stub pim_rp_* functions for IPv6
These are sprinkled relatively widely through the PIM codebase, so for
the time being reduce the "compiler warning surface" by moving them
forward to proper types without actual implementations.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Igor Ryzhov [Wed, 9 Feb 2022 23:51:49 +0000 (02:51 +0300)]
tools: fix frr-reload context keywords
There are singline-line commands inside `router bgp` that start with
`vnc ` or `bmp `. Those commands are currently treated as node-entering
commands. We need to specify such commands more precisely.
Igor Ryzhov [Wed, 9 Feb 2022 22:43:37 +0000 (01:43 +0300)]
bgpd: remove bgp_attr_undup
bgp_attr_undup does the same thing as bgp_attr_flush – frees the
temporary data that might be allocated when applying a route-map. There
is no need to have two separate functions for that.
Igor Ryzhov [Wed, 9 Feb 2022 22:23:41 +0000 (01:23 +0300)]
bgpd: fix aspath memleak on error in vnc_direct_bgp_add_nve
bgp_attr_default_set creates a new empty aspath. If family error happens,
this aspath is not freed. Move attr initialization after we checked the
family.
Have added topotest to verify below combination.
Auth support for md5
Auth support for hmac-sha-256
Auth support with keychain for md5
Auth support with keychain for hmac-sha-256
Have sussessfully run all 4 test cases in my local setup.
Abhinay Ramesh [Tue, 8 Jun 2021 07:54:18 +0000 (07:54 +0000)]
ospf6d: Documentation for authentication trailer support.
Problem Statement:
=================
This commit is to add document support for OSPF6 authentication
trailer feature, which is adding support for RFC7166.
RCA:
====
NA
Fix:
====
To add detailed description for feature support.
This document caputres
Configuration CLI
Show commands
Debug commands
Clear command
That are added as part of the feature with examples.
It supports below show commands:
--------------------------------
frr# show ipv6 ospf6 interface ens192
ens192 is up, type BROADCAST
Interface ID: 5
Number of I/F scoped LSAs is 2
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication trailer is enabled with manual key ==> new info added
Packet drop Tx 0, Packet drop Rx 0 ==> drop counters
frr# show ipv6 ospf6 neighbor 2.2.2.2 detail
Neighbor 2.2.2.2%ens192
Area 1 via interface ens192 (ifindex 3)
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header present ==> new info added
hello DBDesc LSReq LSUpd LSAck
Higher sequence no 0x0 0x0 0x0 0x0 0x0
Lower sequence no 0x242E 0x1DC4 0x1DC3 0x23CC 0x1DDA
frr# show ipv6 ospf6
OSPFv3 Routing Process (0) with Router-ID 2.2.2.2
Number of areas in this router is 1
Authentication Sequence number info ==> new info added
Higher sequence no 3, Lower sequence no 1656
Risk:
=====
Low risk
Tests Executed:
===============
Have executed the combination of commands.
Abhinay Ramesh [Sun, 30 May 2021 16:22:41 +0000 (16:22 +0000)]
ospf6d: Auth trailer CLI implementation.
Problem Statement:
==================
RFC 7166 support for OSPF6 in FRR code.
RCA:
====
This feature is newly supported in FRR
Fix:
====
Changes are done to add support for two new CLIs to configure
ospf6 authentication trailer feature.
One CLI is to support manual key configuration.
Other CLI is to configure key using keychain.
below CLIs are implemented as part of this commit. this configuration
is applied on interface level.
Without openssl:
ipv6 ospf6 authentication key-id (1-65535) hash-algo <md5|hmac-sha-256> key WORD
With openssl:
ipv6 ospf6 authentication key-id (1-65535) hash-algo <md5|hmac-sha-256|hmac-sha-1|hmac-sha-384|hmac-sha-512> key WORD
With keychain support:
ipv6 ospf6 authentication keychain KEYCHAIN_NAME
Running config for these command:
frr# show running-config
Building configuration...
Abhinay Ramesh [Tue, 11 May 2021 12:50:05 +0000 (12:50 +0000)]
ospf6d: support keychain for ospf6 authentication
Problem Statement:
==================
As of now there is no support for ospf6 authentication.
To support ospf6 authentication need to have keychain support for
managing the auth key.
RCA:
====
New support
Fix:
====
Enabling keychain for ospf6 authentication feature.
Risk:
=====
Low risk
Tests Executed:
===============
Have verified the support for ospf6 auth trailer feature.
Donald Sharp [Wed, 2 Feb 2022 18:28:42 +0000 (13:28 -0500)]
zebra: Make netlink buffer reads resizeable when needed
Currently when the kernel sends netlink messages to FRR
the buffers to receive this data is of fixed length.
The kernel, with certain configurations, will send
netlink messages that are larger than this fixed length.
This leads to situations where, on startup, zebra gets
really confused about the state of the kernel. Effectively
the current algorithm is this:
read up to buffer in size
while (data to parse)
get netlink message header, look at size
parse if you can
The problem is that there is a 32k buffer we read.
We get the first message that is say 1k in size,
subtract that 1k to 31k left to parse. We then
get the next header and notice that the length
of the message is 33k. Which is obviously larger
than what we read in. FRR has no recover mechanism
nor is there a way to know, a priori, what the maximum
size the kernel will send us.
Modify FRR to look at the kernel message and see if the
buffer is large enough, if not, make it large enough to
read in the message.
This code has to be per netlink socket because of the usage
of pthreads. So add to `struct nlsock` the buffer and current
buffer length. Growing it as necessary.
Fixes: #10404 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Donald Sharp [Wed, 2 Feb 2022 18:21:52 +0000 (13:21 -0500)]
zebra: Remove `struct nlsock` from dataplane information and use `int fd`
Store the fd that corresponds to the appropriate `struct nlsock` and pass
that around in the dplane context instead of the pointer to the nlsock.
Modify the kernel_netlink.c code to store in a hash the `struct nlsock`
with the socket fd as the key.
Why do this? The dataplane context is used to pass around the `struct nlsock`
but the zebra code has a bug where the received buffer for kernel netlink
messages from the kernel is not big enough. So we need to dynamically
grow the receive buffer per socket, instead of having a non-dynamic buffer
that we read into. By passing around the fd we can look up the `struct nlsock`
that will soon have the associated buffer and not have to worry about `const`
issues that will arise.
Donald Sharp [Tue, 8 Feb 2022 14:47:24 +0000 (09:47 -0500)]
zebra: Store the sequence number to use as part of the dp_info
Store and use the sequence number instead of using what is in
the `struct nlsock`. Future commits are going away from storing
the `struct nlsock` and the copy of the nlsock was guaranteeing
unique sequence numbers per message. So let's store the
sequence number to use instead.
projects / mirror_frr.git / log