| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 1cc380679e4cbca5c0c4259653c57da1f47dbafe)
|
|
zebra: trim unused tc dplane result values
|
|
Signed-off-by: Siger Yang <siger.yang@outlook.com>
|
|
zebra: fix deadcodes in tc dplane & netlink
|
|
Signed-off-by: Siger Yang <siger.yang@outlook.com>
|
|
zebra: add basic traffic control API
|
|
Coverity spotted 3 places where `int ret = XXX` was
being used and FRR was immediately assigning a different
value.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
This commit implements necessary netlink encoders for traffic control
including QDISC, TCLASS and TFILTER, and adds basic dplane operations.
Co-authored-by: Stephen Worley <sworley@nvidia.com>
Signed-off-by: Siger Yang <siger.yang@outlook.com>
|
|
Allow individual interfaces to turn on/off the mpls subsystem
for it in linux.
sharpd@eva:~/frr9$ sudo sysctl -a | grep enp39s0 | grep mpls
net.mpls.conf.enp39s0.input = 0
sharpd@eva:~/frr9$ vtysh -c "conf" -c "int enp39s0" -c "mpls enable"
sharpd@eva:~/frr9$ sudo sysctl -a | grep enp39s0 | grep mpls
net.mpls.conf.enp39s0.input = 1
sharpd@eva:~/frr9$ vtysh -c "conf" -c "int enp39s0" -c "no mpls enable"
sharpd@eva:~/frr9$ sudo sysctl -a | grep enp39s0 | grep mpls
net.mpls.conf.enp39s0.input = 0
sharpd@eva:~/frr9$
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Just convert all uses of thread_cancel to THREAD_OFF
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
These attributes are needed for dpdk dataplane programming
Signed-off-by: Anuradha Karuppiah <anuradhak@nvidia.com>
|
|
Add the ability to decode the ignore on linkdown nexthop
status for an interface.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
When reading a on the fly change of an interested netconf netlink
message. The ifindex and ns_id for the context was being set for the sub structure
but not for the main context data structure and zebra_if_dplane_result
was dropping the result on the floor because it was expecting the ns_id and
the interface id to be in a different spot.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Multipath route may have mixed nexthops of EVPN and IP unicast. Move
EVPN flag to nexthop to support such cases.
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
|
|
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>
|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Avoid initialization in dplane_ctx_intf_init() so
the compiler can warn us about using unintialized data.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
Only clear protodown reason on shutdown/sweep, retain protodown
state.
This is to retain traditional and expected behavior with daemons
like vrrpd setting protodown. They expet it to be set on shutdown
and retained on bring up to prevent traffic from being dropped.
We must cleanup our reason code though to prevent us from blocking
others.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
Add a helper macro for checking if interface is protodown,
typing this out is annoying.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
Add enums for set/unset of prodown state to handle the mainthread
knowing an update is already queued without actually marking it
as complete.
This is to make the logic confirm a bit more with other parts of the code
where we queue dplane updates and not update our internal structs until
success callback is received.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
Add support for setting the protodown reason code.
https://github.com/torvalds/linux/commit/829eb208e80d6db95c0201cb8fa00c2f9ad87faf
These patches handle all our netlink code for setting the reason.
For protodown reason we only set `frr` as the reason externally
but internally we have more descriptive reasoning available via
`show interface IFNAME`. The kernel only provides a bitwidth of 32
that all userspace programs have to share so this makes the most sense.
Since this is new functionality, it needs to be added to the dplane
pthread instead. So these patches, also move the protodown setting we
were doing before into the dplane pthread. For this, we abstract it a
bit more to make it a general interface LINK update dplane API. This
API can be expanded to support gernal link creation/updating when/if
someone ever adds that code.
We also move a more common entrypoint for evpn-mh and from zapi clients
like vrrpd. They both call common code now to set our internal flags
for protodown and protodown reason.
Also add debugging code for dumping netlink packets with
protodown/protodown_reason.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
Use the dataplane to query and read interface NETCONF data;
add netconf-oriented data to the dplane context object, and
add accessors for it. Add handler for incoming update
processing.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
|
|
Add a new dplane op for interface NETCONF data; add the new
enum value to several switch statements.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
|
|
The int return value is never used. Modify the code
base to just return a void instead.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
zebra: use frr mem apis in dplane
|
|
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>
|
|
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.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Replace a couple of strdup/free with XSTRDUP/XFREE.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
|
|
Currently when we have a route replace operation for v6 routes
with a new nexthop group the order of kernel installation is this:
a) New nexthop group insertion seq 1
b) Route delete operation seq 3
c) Route insertion operation seq 2
Currently the code in nl_batch_read_resp is attempting
to handle this situation by skipping the delete operation.
*BUT* it is enqueuing the context into the zebra dplane
queue before we read the response. Since we create the ctx
with an implied success, success is being reported to the
upper level dplane and the zebra rib thinks the route has
been properly handled.
This is showing up in the zebra_seg6_route test code because
the test code is installing a seg6 route w/ sharpd and it
is failing to install because the route's nexthop is rejected:
First installation:
2021/10/29 09:28:10.218 ZEBRA: [JGWSB-SMNVE] dplane: incoming new work counter: 2
2021/10/29 09:28:10.218 ZEBRA: [Q52A7-211QJ] dplane enqueues 2 new work to provider 'Kernel'
2021/10/29 09:28:10.218 ZEBRA: [JVY1P-93VFY] dplane provider 'Kernel': processing
2021/10/29 09:28:10.218 ZEBRA: [TX9N0-9JKDF] ID (9) Dplane nexthop update ctx 0x56125390a820 op NH_INSTALL
2021/10/29 09:28:10.218 ZEBRA: [PM9ZJ-07RCP] 0:1::1/128 Dplane route update ctx 0x56125390add0 op ROUTE_INSTALL
2021/10/29 09:28:10.218 ZEBRA: [TJ327-ET8HE] netlink_send_msg: >> netlink message dump [sent]
2021/10/29 09:28:10.218 ZEBRA: [JAS4D-NCWGP] nlmsghdr [len=104 type=(104) NEWNEXTHOP flags=(0x0501) {REQUEST,DUMP,(ROOT|REPLACE|CAPPED),(ATOMIC|CREATE)} seq=9 pid=3539131282]
2021/10/29 09:28:10.218 ZEBRA: [WCX94-SW894] nhm [family=(10) AF_INET6 scope=(0) UNIVERSE protocol=(11) ZEBRA flags=0x00000000 {}]
2021/10/29 09:28:10.218 ZEBRA: [KFBSR-XYJV1] rta [len=8 (payload=4) type=(1) ID]
2021/10/29 09:28:10.218 ZEBRA: [Z4E9C-GD9EP] 9
2021/10/29 09:28:10.218 ZEBRA: [KFBSR-XYJV1] rta [len=20 (payload=16) type=(6) GATEWAY]
2021/10/29 09:28:10.218 ZEBRA: [STTSM-27M81] 2001::1
2021/10/29 09:28:10.218 ZEBRA: [KFBSR-XYJV1] rta [len=8 (payload=4) type=(5) OIF]
2021/10/29 09:28:10.218 ZEBRA: [JR4EA-BKPTA] 6
2021/10/29 09:28:10.218 ZEBRA: [KFBSR-XYJV1] rta [len=6 (payload=2) type=(7) ENCAP_TYPE]
2021/10/29 09:28:10.218 ZEBRA: [JR4EA-BKPTA] 5
2021/10/29 09:28:10.218 ZEBRA: [KFBSR-XYJV1] rta [len=36 (payload=32) type=(32776) UNKNOWN]
2021/10/29 09:28:10.218 ZEBRA: [JAS4D-NCWGP] nlmsghdr [len=64 type=(24) NEWROUTE flags=(0x0401) {REQUEST,(ATOMIC|CREATE)} seq=10 pid=3539131282]
2021/10/29 09:28:10.218 ZEBRA: [GCEGC-W8YBF] rtmsg [family=(10) AF_INET6 dstlen=128 srclen=0 tos=0 table=254 protocol=(194) UNKNOWN scope=(0) UNIVERSE type=(1) UNICAST flags=0x0000 {}]
2021/10/29 09:28:10.218 ZEBRA: [KFBSR-XYJV1] rta [len=20 (payload=16) type=(1) DST]
2021/10/29 09:28:10.218 ZEBRA: [STTSM-27M81] 1::1
2021/10/29 09:28:10.218 ZEBRA: [KFBSR-XYJV1] rta [len=8 (payload=4) type=(6) PRIORITY]
2021/10/29 09:28:10.218 ZEBRA: [Z4E9C-GD9EP] 20
2021/10/29 09:28:10.218 ZEBRA: [KFBSR-XYJV1] rta [len=8 (payload=4) type=(30) NH_ID]
2021/10/29 09:28:10.218 ZEBRA: [Z4E9C-GD9EP] 9
2021/10/29 09:28:10.218 ZEBRA: [V8KNF-8EXH8] netlink_recv_msg: << netlink message dump [recv]
2021/10/29 09:28:10.218 ZEBRA: [JAS4D-NCWGP] nlmsghdr [len=76 type=(2) ERROR flags=(0x0300) {DUMP,(ROOT|REPLACE|CAPPED),(MATCH|EXCLUDE|ACK_TLVS)} seq=9 pid=3539131282]
2021/10/29 09:28:10.218 ZEBRA: [KWP1C-6CSXF] nlmsgerr [error=(-22) Invalid argument]
2021/10/29 09:28:10.218 ZEBRA: [HSYZM-HV7HF] Extended Error: Gateway can not be a local address
2021/10/29 09:28:10.218 ZEBRA: [WVJCK-PPMGD][EC 4043309093] netlink-dp (NS 0) error: Invalid argument, type=RTM_NEWNEXTHOP(104), seq=9, pid=3539131282
2021/10/29 09:28:10.218 ZEBRA: [V8KNF-8EXH8] netlink_recv_msg: << netlink message dump [recv]
2021/10/29 09:28:10.218 ZEBRA: [JAS4D-NCWGP] nlmsghdr [len=68 type=(2) ERROR flags=(0x0300) {DUMP,(ROOT|REPLACE|CAPPED),(MATCH|EXCLUDE|ACK_TLVS)} seq=10 pid=3539131282]
2021/10/29 09:28:10.218 ZEBRA: [KWP1C-6CSXF] nlmsgerr [error=(-22) Invalid argument]
2021/10/29 09:28:10.218 ZEBRA: [HSYZM-HV7HF] Extended Error: Nexthop id does not exist
2021/10/29 09:28:10.218 ZEBRA: [WVJCK-PPMGD][EC 4043309093] netlink-dp (NS 0) error: Invalid argument, type=RTM_NEWROUTE(24), seq=10, pid=3539131282
2021/10/29 09:28:10.218 ZEBRA: [VCDW6-A7ZF1] dplane dequeues 2 completed work from provider Kernel
2021/10/29 09:28:10.218 ZEBRA: [JTWAB-1MH4Y] dplane has 2 completed, 0 errors, for zebra main
2021/10/29 09:28:10.218 ZEBRA: [J7K9Z-9M7DT] Nexthop dplane ctx 0x56125390a820, op NH_INSTALL, nexthop ID (9), result FAILURE
2021/10/29 09:28:10.218 ZEBRA: [P2XBZ-RAFQ5][EC 4043309074] Failed to install Nexthop ID (9) into the kernel
2021/10/29 09:28:10.218 ZEBRA: [RMK34-61HV5] default(0:254):1::1/128 Processing dplane result ctx 0x56125390add0, op ROUTE_INSTALL result FAILURE
Note the last line `op ROUTE_INSTALL result FAILURE` because we are attempting to use a
a gw nexthop that is local. This is the result.
Then the test code was installing the route again:
2021/10/29 09:30:00.493 ZEBRA: [JGWSB-SMNVE] dplane: incoming new work counter: 2
2021/10/29 09:30:00.493 ZEBRA: [Q52A7-211QJ] dplane enqueues 2 new work to provider 'Kernel'
2021/10/29 09:30:00.493 ZEBRA: [JVY1P-93VFY] dplane provider 'Kernel': processing
2021/10/29 09:30:00.493 ZEBRA: [TX9N0-9JKDF] ID (9) Dplane nexthop update ctx 0x561253916a00 op NH_INSTALL
2021/10/29 09:30:00.493 ZEBRA: [PM9ZJ-07RCP] 0:1::1/128 Dplane route update ctx 0x561253915f40 op ROUTE_UPDATE
2021/10/29 09:30:00.493 ZEBRA: [TJ327-ET8HE] netlink_send_msg: >> netlink message dump [sent]
2021/10/29 09:30:00.493 ZEBRA: [JAS4D-NCWGP] nlmsghdr [len=104 type=(104) NEWNEXTHOP flags=(0x0501) {REQUEST,DUMP,(ROOT|REPLACE|CAPPED),(ATOMIC|CREATE)} seq=11 pid=3539131282]
2021/10/29 09:30:00.493 ZEBRA: [WCX94-SW894] nhm [family=(10) AF_INET6 scope=(0) UNIVERSE protocol=(11) ZEBRA flags=0x00000000 {}]
2021/10/29 09:30:00.493 ZEBRA: [KFBSR-XYJV1] rta [len=8 (payload=4) type=(1) ID]
2021/10/29 09:30:00.493 ZEBRA: [Z4E9C-GD9EP] 9
2021/10/29 09:30:00.493 ZEBRA: [KFBSR-XYJV1] rta [len=20 (payload=16) type=(6) GATEWAY]
2021/10/29 09:30:00.493 ZEBRA: [STTSM-27M81] 2001::1
2021/10/29 09:30:00.493 ZEBRA: [KFBSR-XYJV1] rta [len=8 (payload=4) type=(5) OIF]
2021/10/29 09:30:00.493 ZEBRA: [JR4EA-BKPTA] 6
2021/10/29 09:30:00.493 ZEBRA: [KFBSR-XYJV1] rta [len=6 (payload=2) type=(7) ENCAP_TYPE]
2021/10/29 09:30:00.493 ZEBRA: [JR4EA-BKPTA] 5
2021/10/29 09:30:00.493 ZEBRA: [KFBSR-XYJV1] rta [len=36 (payload=32) type=(32776) UNKNOWN]
2021/10/29 09:30:00.493 ZEBRA: [JAS4D-NCWGP] nlmsghdr [len=56 type=(25) DELROUTE flags=(0x0401) {REQUEST,(ATOMIC|CREATE)} seq=13 pid=3539131282]
2021/10/29 09:30:00.493 ZEBRA: [GCEGC-W8YBF] rtmsg [family=(10) AF_INET6 dstlen=128 srclen=0 tos=0 table=254 protocol=(194) UNKNOWN scope=(0) UNIVERSE type=(0) UNSPEC flags=0x0000 {}]
2021/10/29 09:30:00.493 ZEBRA: [KFBSR-XYJV1] rta [len=20 (payload=16) type=(1) DST]
2021/10/29 09:30:00.493 ZEBRA: [STTSM-27M81] 1::1
2021/10/29 09:30:00.493 ZEBRA: [KFBSR-XYJV1] rta [len=8 (payload=4) type=(6) PRIORITY]
2021/10/29 09:30:00.493 ZEBRA: [Z4E9C-GD9EP] 20
2021/10/29 09:30:00.493 ZEBRA: [JAS4D-NCWGP] nlmsghdr [len=64 type=(24) NEWROUTE flags=(0x0401) {REQUEST,(ATOMIC|CREATE)} seq=12 pid=3539131282]
2021/10/29 09:30:00.493 ZEBRA: [GCEGC-W8YBF] rtmsg [family=(10) AF_INET6 dstlen=128 srclen=0 tos=0 table=254 protocol=(194) UNKNOWN scope=(0) UNIVERSE type=(1) UNICAST flags=0x0000 {}]
2021/10/29 09:30:00.493 ZEBRA: [KFBSR-XYJV1] rta [len=20 (payload=16) type=(1) DST]
2021/10/29 09:30:00.493 ZEBRA: [STTSM-27M81] 1::1
2021/10/29 09:30:00.493 ZEBRA: [KFBSR-XYJV1] rta [len=8 (payload=4) type=(6) PRIORITY]
2021/10/29 09:30:00.493 ZEBRA: [Z4E9C-GD9EP] 20
2021/10/29 09:30:00.493 ZEBRA: [KFBSR-XYJV1] rta [len=8 (payload=4) type=(30) NH_ID]
2021/10/29 09:30:00.493 ZEBRA: [Z4E9C-GD9EP] 9
2021/10/29 09:30:00.493 ZEBRA: [V8KNF-8EXH8] netlink_recv_msg: << netlink message dump [recv]
2021/10/29 09:30:00.493 ZEBRA: [JAS4D-NCWGP] nlmsghdr [len=76 type=(2) ERROR flags=(0x0300) {DUMP,(ROOT|REPLACE|CAPPED),(MATCH|EXCLUDE|ACK_TLVS)} seq=11 pid=3539131282]
2021/10/29 09:30:00.493 ZEBRA: [KWP1C-6CSXF] nlmsgerr [error=(-22) Invalid argument]
2021/10/29 09:30:00.493 ZEBRA: [HSYZM-HV7HF] Extended Error: Gateway can not be a local address
2021/10/29 09:30:00.493 ZEBRA: [WVJCK-PPMGD][EC 4043309093] netlink-dp (NS 0) error: Invalid argument, type=RTM_NEWNEXTHOP(104), seq=11, pid=3539131282
2021/10/29 09:30:00.493 ZEBRA: [V8KNF-8EXH8] netlink_recv_msg: << netlink message dump [recv]
2021/10/29 09:30:00.493 ZEBRA: [JAS4D-NCWGP] nlmsghdr [len=36 type=(2) ERROR flags=(0x0100) {DUMP,(ROOT|REPLACE|CAPPED)} seq=13 pid=3539131282]
2021/10/29 09:30:00.493 ZEBRA: [KWP1C-6CSXF] nlmsgerr [error=(-3) No such process]
2021/10/29 09:30:00.493 ZEBRA: [V8KNF-8EXH8] netlink_recv_msg: << netlink message dump [recv]
2021/10/29 09:30:00.493 ZEBRA: [JAS4D-NCWGP] nlmsghdr [len=68 type=(2) ERROR flags=(0x0300) {DUMP,(ROOT|REPLACE|CAPPED),(MATCH|EXCLUDE|ACK_TLVS)} seq=12 pid=3539131282]
2021/10/29 09:30:00.493 ZEBRA: [KWP1C-6CSXF] nlmsgerr [error=(-22) Invalid argument]
2021/10/29 09:30:00.493 ZEBRA: [VCDW6-A7ZF1] dplane dequeues 2 completed work from provider Kernel
2021/10/29 09:30:00.493 ZEBRA: [JTWAB-1MH4Y] dplane has 2 completed, 0 errors, for zebra main
2021/10/29 09:30:00.493 ZEBRA: [J7K9Z-9M7DT] Nexthop dplane ctx 0x561253916a00, op NH_INSTALL, nexthop ID (9), result FAILURE
2021/10/29 09:30:00.493 ZEBRA: [P2XBZ-RAFQ5][EC 4043309074] Failed to install Nexthop ID (9) into the kernel
2021/10/29 09:30:00.493 ZEBRA: [RMK34-61HV5] default(0:254):1::1/128 Processing dplane result ctx 0x561253915f40, op ROUTE_UPDATE result SUCCESS
Note that this time we do these three operations
a) nexthop installation seq 11
b) route delete seq 13
c) route add seq 12
Note the last line, we report the install as a success but it clearly failed from the seq=12 decode.
When we look at the v6 rib it thinks it is installed:
unet> r1 show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
D>* 1::1/128 [150/0] via 2001::1, dum0, seg6local unspec unknown(seg6local_context2str), seg6 a::, weight 1, 00:00:17
So let's modify nl_batch_read_resp to not dequeue/enqueue the context until we are sure we have
the right one. This fixes the test code to do the right thing on the second installation.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
The ctx->zd_is_update is being set in various
spots based upon the same value that we are
passing into dplane_ctx_ns_init. Let's just
consolidate all this into the dplane_ctx_ns_init
so that the zd_is_udpate value is set at the
same time that we increment the sequence numbers
to use.
As a note for future me's reading this. The sequence
number choosen for the seq number passed to the
kernel is that each context gets a copy of the
appropriate nlsock to use. Since it's a copy
at a point in time, we know we have a unique sequence
number value.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
In some cases, zebra may install a nexthop-group id that is
different from the id of the nhe struct attached to a
route-entry. This happens for a singleton recursive nexthop,
for example, where a route is installed with the resolving
nexthop's id.
The installed value is the most useful value - that corresponds
to information in the kernel on linux/netlink platforms that
support nhgs. Display both values if they differ in ascii
output, and include both values in the json form.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
|
|
Since f60a1188 we store a pointer to the VRF in the interface structure.
There's no need anymore to store a separate vrf_id field.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
|
|
The dplane_ctx_get_pbr_ipset_entry function only
failed when the caller did not pass in a valid
usable pointer. Change the code to assert on
a pointer not being passed in and remove the
bool return
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
The only time this function ever failed is when
the developer does not pass in a usable pointer
to place the data in. Change it to an assert
to signify to the end developer that is what
we want and then remove all the if checks
for failure
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
The function call dplane_ctx_get_pbr_ipset only
returns false when the calling function fails to
pass in a valid ipset pointer. This should
be an assertion issue since it's a programming
issue as opposed to an actual run time issue.
Change the function call parameter to not return
a bool on success/fail for a compile time decision.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
It is needed for the ipset entry to know for which address family
this ipset entry applies to. Actually, the family is in the original
ipset structure and was not passed as attribute in the dataplane
ipset_info structure. Add it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
When injecting an ipset entry into the zebra dataplane context, the
ipset name is stored in a separate structure. This will permit the
flowspec plugin to be able to know which ipset has to be appended with
relevant ipset entry.
The problem was that the zebra dataplane objects related to ipset entries
is made up of an union between the ipset structure and the ipset info
structure. This was implying that the two structures were on the same
memory zone, and when extracting the data stored, the data were incomplete.
Fix this by replacing the union structure by a defined struct.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
Signed-off-by: Eli Baum <ebaum@mitre.org>
|
|
Read incoming interface address change notifications in the
dplane pthread; enqueue the events to the main pthread
for processing. This is netlink-only for now - the bsd
kernel socket path remains unchanged.
Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
|
|
Add new dplane op values for incoming interface address add
and delete events.
Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
|
|
Add a few more setters for interface data in dplane
contexts.
Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
|
|
Add a new netlink socket for events coming in from the host OS
to the dataplane system for processing. Rename the existing
outbound dplane socket.
Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
|
|
We do not use typedef's to talk about structures as per our standard.
Fixing.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
We do not use typedef's to talk about structures as per our standard.
Fixing.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
We do not use typedef's to talk about structures as per our standard.
Fixing.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
The rib_lookup_and_pushup function, from what I can tell, was
used more when static route processing and connected routes were
more closely integrated in zebra. The goal was when we were adding
a new address to remove the connected route and then allow processing
of the new address. With the re-org a few years ago to seperate
out connected routes as well as static routes, I believe this is
no longer needed.
on BSD, without this code change we have this log:
2021/08/05 14:33:38 ZEBRA: [QEVVE-G3FQQ] rib_meta_queue_add: (0:0):10.40.30.0/24: queued rn 0x802022bb0 into sub-queue 4
2021/08/05 14:33:38 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 200 Type: RTM_DELETE
2021/08/05 14:33:38 ZEBRA: [V3NSB-BPKBD] Kernel: GATEWAY DONE PROTO1
2021/08/05 14:33:38 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 15
2021/08/05 14:33:38 ZEBRA: [MJD4M-0AAAR] Kernel: pid 53305, rtm_addrs {DST,GATEWAY,NETMASK}
2021/08/05 14:33:38 ZEBRA: [Y9Y5K-JJ7NT] rtm_read: got rtm of type 2 (RTM_DELETE) addrs {DST,GATEWAY,NETMASK}
2021/08/05 14:33:38 ZEBRA: [V17DT-1FJEN] kernel_rtm: 10.40.30.0/24: successfully did NH 9.8.6.7
2021/08/05 14:33:38 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 164 Type: RTM_NEWADDR
2021/08/05 14:33:38 ZEBRA: [V3NSB-BPKBD] Kernel:
2021/08/05 14:33:38 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 4664
2021/08/05 14:33:38 ZEBRA: [MJD4M-0AAAR] Kernel: pid 0, rtm_addrs {DST}
2021/08/05 14:33:38 ZEBRA: [M09CX-TKB4N] ifam_read_mesg: ifindex 1, ifname vtnet0, ifam_addrs {NETMASK,IFP,IFA,BRD}, ifam_flags 0x0, addr 10.40.30.1/24 broad 10.40.30.255 dst (unspec) gateway (unspec)
2021/08/05 14:33:38 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:0):10.40.30.0/24: Inserting route rn 0x802022bb0, re 0x8032973a0 (connected) existing 0x0, same_count 0
2021/08/05 14:33:38 ZEBRA: [Q4T2G-E2SQF] rib_add_multipath_nhe: dumping RE entry 0x8032973a0 for 10.40.30.0/24 vrf default(0)
2021/08/05 14:33:38 ZEBRA: [M5M58-9PD2R] 10.40.30.0/24: uptime == 1379355, type == 2, instance == 0, table == 0
2021/08/05 14:33:38 ZEBRA: [RVZMM-N7DME] 10.40.30.0/24: metric == 1, mtu == 0, distance == 0, flags == None status == None
2021/08/05 14:33:38 ZEBRA: [Q1NW5-NWY7P] 10.40.30.0/24: nexthop_num == 1, nexthop_active_num == 0
2021/08/05 14:33:38 ZEBRA: [TFHQ8-TC30H] 10.40.30.0/24: NH vtnet0[1] vrf default(0) with flags
2021/08/05 14:33:38 ZEBRA: [SCETK-GQ9E4] 10.40.30.0/24: dump complete
2021/08/05 14:33:38 ZEBRA: [QEVVE-G3FQQ] rib_meta_queue_add: (0:0):10.40.30.0/24: queued rn 0x802022bb0 into sub-queue 2
2021/08/05 14:33:38 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:?):10.40.30.0/24 (MRIB): Inserting route rn 0x802022f30, re 0x803297340 (connected) existing 0x0, same_count 0
2021/08/05 14:33:38 ZEBRA: [Q4T2G-E2SQF] rib_add_multipath_nhe: dumping RE entry 0x803297340 for 10.40.30.0/24 vrf default(0)
2021/08/05 14:33:38 ZEBRA: [M5M58-9PD2R] 10.40.30.0/24: uptime == 1379355, type == 2, instance == 0, table == 0
2021/08/05 14:33:38 ZEBRA: [RVZMM-N7DME] 10.40.30.0/24: metric == 1, mtu == 0, distance == 0, flags == None status == None
2021/08/05 14:33:38 ZEBRA: [Q1NW5-NWY7P] 10.40.30.0/24: nexthop_num == 1, nexthop_active_num == 0
2021/08/05 14:33:38 ZEBRA: [TFHQ8-TC30H] 10.40.30.0/24: NH vtnet0[1] vrf default(0) with flags
2021/08/05 14:33:38 ZEBRA: [SCETK-GQ9E4] 10.40.30.0/24: dump complete
2021/08/05 14:33:38 ZEBRA: [GCGMT-SQR82] rib_link: (0:?):10.40.30.0/24 (MRIB): rn 0x802022f30 adding dest
2021/08/05 14:33:38 ZEBRA: [QEVVE-G3FQQ] rib_meta_queue_add: (0:0):10.40.30.0/24 (MRIB): queued rn 0x802022f30 into sub-queue 2
2021/08/05 14:33:38 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 240 Type: RTM_ADD
2021/08/05 14:33:38 ZEBRA: [V3NSB-BPKBD] Kernel: UP PINNED
2021/08/05 14:33:38 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 0
2021/08/05 14:33:38 ZEBRA: [MJD4M-0AAAR] Kernel: pid 0, rtm_addrs {DST,GATEWAY,NETMASK}
2021/08/05 14:33:38 ZEBRA: [K0KVE-2GJA1] default(0:0):10.40.30.0/24: Processing rn 0x802022bb0
2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x8032973a0 (connected) status: Changed flags: None dist 0 metric 1
2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x8032970a0 (static) status: None flags: Recursion RR Distance dist 1 metric 0
2021/08/05 14:33:38 ZEBRA: [NYYJJ-0Q8QG] default(0:0):10.40.30.0/24: After processing: old_selected 0x0 new_selected 0x8032973a0 old_fib 0x0 new_fib 0x8032973a0
2021/08/05 14:33:38 ZEBRA: [RT9DY-ZS2KN] default(0:0):10.40.30.0/24: Adding route rn 0x802022bb0, re 0x8032973a0 (connected)
2021/08/05 14:33:38 ZEBRA: [PP3BZ-RABJN] default(0:0):10.40.30.0/24: rn 0x802022bb0 dequeued from sub-queue 2
2021/08/05 14:33:38 ZEBRA: [K0KVE-2GJA1] default(0:0):10.40.30.0/24: Processing rn 0x802022f30
2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x803297340 (connected) status: Changed flags: None dist 0 metric 1
2021/08/05 14:33:38 ZEBRA: [NYYJJ-0Q8QG] default(0:0):10.40.30.0/24: After processing: old_selected 0x0 new_selected 0x803297340 old_fib 0x0 new_fib 0x803297340
2021/08/05 14:33:38 ZEBRA: [RT9DY-ZS2KN] default(0:0):10.40.30.0/24: Adding route rn 0x802022f30, re 0x803297340 (connected)
2021/08/05 14:33:38 ZEBRA: [PP3BZ-RABJN] default(0:0):10.40.30.0/24: rn 0x802022f30 dequeued from sub-queue 2
2021/08/05 14:33:38 ZEBRA: [K0KVE-2GJA1] default(0:0):10.40.30.0/24: Processing rn 0x802022bb0
2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x8032973a0 (connected) status: Queued flags: Selected dist 0 metric 1
2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x8032970a0 (static) status: None flags: Recursion RR Distance dist 1 metric 0
2021/08/05 14:33:38 ZEBRA: [NYYJJ-0Q8QG] default(0:0):10.40.30.0/24: After processing: old_selected 0x8032973a0 new_selected 0x8032973a0 old_fib 0x8032973a0 new_fib 0x8032973a0
2021/08/05 14:33:38 ZEBRA: [PP3BZ-RABJN] default(0:0):10.40.30.0/24: rn 0x802022bb0 dequeued from sub-queue 4
2021/08/05 14:33:38 ZEBRA: [GHWHS-ZKQM5] update_from_ctx: default(0:0):10.40.30.0/24: SELECTED, re 0x8032973a0
2021/08/05 14:33:38 ZEBRA: [TS3SH-1276M] default(0:0):10.40.30.0/24 update_from_ctx(): no fib nhg
2021/08/05 14:33:38 ZEBRA: [HKQXC-4STSK] default(0:0):10.40.30.0/24 update_from_ctx(): rib nhg matched, changed 'false'
2021/08/05 14:33:38 ZEBRA: [HBZNK-5H1X0] (0:0):10.40.30.0/24: Redist update re 0x8032973a0 (connected), old 0x0 (None)
2021/08/05 14:33:38 ZEBRA: [GHWHS-ZKQM5] update_from_ctx: default(0:0):10.40.30.0/24: SELECTED, re 0x8032973a0
2021/08/05 14:33:38 ZEBRA: [TS3SH-1276M] default(0:0):10.40.30.0/24 update_from_ctx(): no fib nhg
2021/08/05 14:33:38 ZEBRA: [HKQXC-4STSK] default(0:0):10.40.30.0/24 update_from_ctx(): rib nhg matched, changed 'false'
2021/08/05 14:33:38 ZEBRA: [HBZNK-5H1X0] (0:0):10.40.30.0/24: Redist update re 0x8032973a0 (connected), old 0x0 (None)
With this code change:
2021/08/05 14:41:24 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:?):10.10.40.0/24: Inserting route rn 0x802022f30, re 0x8021cbe60 (static) existing 0x0, same_count 0
2021/08/05 14:41:24 ZEBRA: [RT9DY-ZS2KN] default(0:0):10.10.40.0/24: Adding route rn 0x802022f30, re 0x8021cbe60 (static)
2021/08/05 14:41:24 ZEBRA: [V17DT-1FJEN] kernel_rtm: 10.10.40.0/24: successfully did NH 9.8.6.7
2021/08/05 14:41:24 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 200 Type: RTM_ADD
2021/08/05 14:41:24 ZEBRA: [V3NSB-BPKBD] Kernel: UP GATEWAY DONE PROTO1
2021/08/05 14:41:24 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 0
2021/08/05 14:41:24 ZEBRA: [MJD4M-0AAAR] Kernel: pid 60818, rtm_addrs {DST,GATEWAY,NETMASK}
2021/08/05 14:41:24 ZEBRA: [Y9Y5K-JJ7NT] rtm_read: got rtm of type 1 (RTM_ADD) addrs {DST,GATEWAY,NETMASK}
2021/08/05 14:41:24 ZEBRA: [TS3SH-1276M] default(0:0):10.10.40.0/24 update_from_ctx(): no fib nhg
2021/08/05 14:41:24 ZEBRA: [HKQXC-4STSK] default(0:0):10.10.40.0/24 update_from_ctx(): rib nhg matched, changed 'true'
2021/08/05 14:41:24 ZEBRA: [HBZNK-5H1X0] (0:0):10.10.40.0/24: Redist update re 0x8021cbe60 (static), old 0x0 (None)
2021/08/05 14:42:06 ZEBRA: [ZJ4AV-JEMJ3] dplane_intf_addr_set
2021/08/05 14:42:06 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 164 Type: RTM_NEWADDR
2021/08/05 14:42:06 ZEBRA: [V3NSB-BPKBD] Kernel:
2021/08/05 14:42:06 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 4664
2021/08/05 14:42:06 ZEBRA: [MJD4M-0AAAR] Kernel: pid 0, rtm_addrs {DST}
2021/08/05 14:42:06 ZEBRA: [M09CX-TKB4N] ifam_read_mesg: ifindex 1, ifname vtnet0, ifam_addrs {NETMASK,IFP,IFA,BRD}, ifam_flags 0x0, addr 10.10.40.3/24 broad 10.10.40.255 dst (unspec) gateway (unspec)
2021/08/05 14:42:06 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:0):10.10.40.0/24: Inserting route rn 0x802022f30, re 0x80308c4c0 (connected) existing 0x0, same_count 0
2021/08/05 14:42:06 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:?):10.10.40.0/24 (MRIB): Inserting route rn 0x802023160, re 0x80308c460 (connected) existing 0x0, same_count 0
2021/08/05 14:42:06 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 240 Type: RTM_ADD
2021/08/05 14:42:06 ZEBRA: [V3NSB-BPKBD] Kernel: UP PINNED
2021/08/05 14:42:06 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 0
2021/08/05 14:42:06 ZEBRA: [MJD4M-0AAAR] Kernel: pid 0, rtm_addrs {DST,GATEWAY,NETMASK}
2021/08/05 14:42:06 ZEBRA: [RG9Y6-E93A0] default(0:0):10.10.40.0/24: Updating route rn 0x802022f30, re 0x80308c4c0 (connected) old 0x8021cbe60 (static)
2021/08/05 14:42:06 ZEBRA: [RT9DY-ZS2KN] default(0:0):10.10.40.0/24: Adding route rn 0x802023160, re 0x80308c460 (connected)
2021/08/05 14:42:06 ZEBRA: [THSYN-E2XFY][EC 100663299] rtm_write: write : Address already in use (48)
2021/08/05 14:42:06 ZEBRA: [RV5F2-MQGZG][EC 100663303] kernel_rtm: 10.10.40.0/24: rtm_write() unexpectedly returned -5 for command RTM_DELETE
2021/08/05 14:42:06 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 200 Type: RTM_DELETE
2021/08/05 14:42:06 ZEBRA: [V3NSB-BPKBD] Kernel: UP PROTO1
2021/08/05 14:42:06 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 1
2021/08/05 14:42:06 ZEBRA: [MJD4M-0AAAR] Kernel: pid 60818, rtm_addrs {DST,GATEWAY,NETMASK}
2021/08/05 14:42:06 ZEBRA: [XASXT-GF69Y] kernel_rtm: No useful nexthops were found in RIB prefix 10.10.40.0/24
2021/08/05 14:42:06 ZEBRA: [TS3SH-1276M] default(0:0):10.10.40.0/24 update_from_ctx(): no fib nhg
2021/08/05 14:42:06 ZEBRA: [HKQXC-4STSK] default(0:0):10.10.40.0/24 update_from_ctx(): rib nhg matched, changed 'false'
2021/08/05 14:42:06 ZEBRA: [HBZNK-5H1X0] (0:0):10.10.40.0/24: Redist update re 0x80308c4c0 (connected), old 0x8021cbe60 (static)
netstat -rn:
10.10.40.0/24 link#1 U vtnet0
10.10.40.3 link#1 UHS lo0
show ip route:
C>* 10.10.40.0/24 [0/1] is directly connected, vtnet0, 00:18:48
S 10.10.40.0/24 [1/0] via 9.8.6.7, vtnet0, weight 1, 00:19:30
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Use strlcpy for safety in dplane rule init api.
Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
|
|
add ability to match on proto to pbr
|
|
Replace a couple of ipaddr2str calls with pIA in the dplane
module.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
|
|
The zebra dplane needs to be taught about the rule ip_proto that can
be installed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
