2023-02-08 13:17:09 +01:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2015-05-20 02:40:34 +02:00
|
|
|
/*
|
|
|
|
|
* Zebra next hop tracking header
|
|
|
|
|
* Copyright (C) 2013 Cumulus Networks, Inc.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _ZEBRA_RNH_H
|
|
|
|
|
#define _ZEBRA_RNH_H
|
|
|
|
|
|
|
|
|
|
#include "prefix.h"
|
|
|
|
|
#include "vty.h"
|
|
|
|
|
|
2019-03-25 15:11:55 +01:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
extern "C" {
|
|
|
|
|
#endif
|
|
|
|
|
|
2018-04-22 23:03:52 +02:00
|
|
|
extern void zebra_rnh_init(void);
|
|
|
|
|
|
2021-10-21 15:16:21 +02:00
|
|
|
extern struct rnh *zebra_add_rnh(struct prefix *p, vrf_id_t vrfid, safi_t safi,
|
2021-09-24 17:04:03 +02:00
|
|
|
bool *exists);
|
2021-09-24 22:36:27 +02:00
|
|
|
extern struct rnh *zebra_lookup_rnh(struct prefix *p, vrf_id_t vrfid,
|
|
|
|
|
safi_t safi);
|
2016-10-31 18:15:16 +01:00
|
|
|
extern void zebra_free_rnh(struct rnh *rnh);
|
*: add VRF ID in the API message header
The API messages are used by zebra to exchange the interfaces, addresses,
routes and router-id information with its clients. To distinguish which
VRF the information belongs to, a new field "VRF ID" is added in the
message header. And hence the message version is increased to 3.
* The new field "VRF ID" in the message header:
Length (2 bytes)
Marker (1 byte)
Version (1 byte)
VRF ID (2 bytes, newly added)
Command (2 bytes)
- Client side:
- zclient_create_header() adds the VRF ID in the message header.
- zclient_read() extracts and validates the VRF ID from the header,
and passes the VRF ID to the callback functions registered to
the API messages.
- All relative functions are appended with a new parameter "vrf_id",
including all the callback functions.
- "vrf_id" is also added to "struct zapi_ipv4" and "struct zapi_ipv6".
Clients need to correctly set the VRF ID when using the API
functions zapi_ipv4_route() and zapi_ipv6_route().
- Till now all messages sent from a client have the default VRF ID
"0" in the header.
- The HELLO message is special, which is used as the heart-beat of
a client, and has no relation with VRF. The VRF ID in the HELLO
message header will always be 0 and ignored by zebra.
- Zebra side:
- zserv_create_header() adds the VRF ID in the message header.
- zebra_client_read() extracts and validates the VRF ID from the
header, and passes the VRF ID to the functions which process
the received messages.
- All relative functions are appended with a new parameter "vrf_id".
* Suppress the messages in a VRF which a client does not care:
Some clients may not care about the information in the VRF X, and
zebra should not send the messages in the VRF X to those clients.
Extra flags are used to indicate which VRF is registered by a client,
and a new message ZEBRA_VRF_UNREGISTER is introduced to let a client
can unregister a VRF when it does not need any information in that
VRF.
A client sends any message other than ZEBRA_VRF_UNREGISTER in a VRF
will automatically register to that VRF.
- lib/vrf:
A new utility "VRF bit-map" is provided to manage the flags for
VRFs, one bit per VRF ID.
- Use vrf_bitmap_init()/vrf_bitmap_free() to initialize/free a
bit-map;
- Use vrf_bitmap_set()/vrf_bitmap_unset() to set/unset a flag
in the given bit-map, corresponding to the given VRF ID;
- Use vrf_bitmap_check() to test whether the flag, in the given
bit-map and for the given VRF ID, is set.
- Client side:
- In "struct zclient", the following flags are changed from
"u_char" to "vrf_bitmap_t":
redist[ZEBRA_ROUTE_MAX]
default_information
These flags are extended for each VRF, and controlled by the
clients themselves (or with the help of zclient_redistribute()
and zclient_redistribute_default()).
- Zebra side:
- In "struct zserv", the following flags are changed from
"u_char" to "vrf_bitmap_t":
redist[ZEBRA_ROUTE_MAX]
redist_default
ifinfo
ridinfo
These flags are extended for each VRF, as the VRF registration
flags. They are maintained on receiving a ZEBRA_XXX_ADD or
ZEBRA_XXX_DELETE message.
When sending an interface/address/route/router-id message in
a VRF to a client, if the corresponding VRF registration flag
is not set, this message will not be dropped by zebra.
- A new function zread_vrf_unregister() is introduced to process
the new command ZEBRA_VRF_UNREGISTER. All the VRF registration
flags are cleared for the requested VRF.
Those clients, who support only the default VRF, will never receive
a message in a non-default VRF, thanks to the filter in zebra.
* New callback for the event of successful connection to zebra:
- zclient_start() is splitted, keeping only the code of connecting
to zebra.
- Now zclient_init()=>zclient_connect()=>zclient_start() operations
are purely dealing with the connection to zbera.
- Once zebra is successfully connected, at the end of zclient_start(),
a new callback is used to inform the client about connection.
- Till now, in the callback of connect-to-zebra event, all clients
send messages to zebra to request the router-id/interface/routes
information in the default VRF.
Of corse in future the client can do anything it wants in this
callback. For example, it may send requests for both default VRF
and some non-default VRFs.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
Conflicts:
lib/zclient.h
lib/zebra.h
zebra/zserv.c
zebra/zserv.h
Conflicts:
bgpd/bgp_nexthop.c
bgpd/bgp_nht.c
bgpd/bgp_zebra.c
isisd/isis_zebra.c
lib/zclient.c
lib/zclient.h
lib/zebra.h
nhrpd/nhrp_interface.c
nhrpd/nhrp_route.c
nhrpd/nhrpd.h
ospf6d/ospf6_zebra.c
ospf6d/ospf6_zebra.h
ospfd/ospf_vty.c
ospfd/ospf_zebra.c
pimd/pim_zebra.c
pimd/pim_zlookup.c
ripd/rip_zebra.c
ripngd/ripng_zebra.c
zebra/redistribute.c
zebra/rt_netlink.c
zebra/zebra_rnh.c
zebra/zebra_rnh.h
zebra/zserv.c
zebra/zserv.h
2014-10-16 03:52:36 +02:00
|
|
|
extern void zebra_add_rnh_client(struct rnh *rnh, struct zserv *client,
|
2021-09-24 17:04:03 +02:00
|
|
|
vrf_id_t vrfid);
|
2020-07-20 13:43:54 +02:00
|
|
|
extern int zebra_send_rnh_update(struct rnh *rnh, struct zserv *client,
|
2021-09-24 17:04:03 +02:00
|
|
|
vrf_id_t vrf_id, uint32_t srte_color);
|
2020-05-27 18:10:30 +02:00
|
|
|
extern void zebra_register_rnh_pseudowire(vrf_id_t, struct zebra_pw *, bool *);
|
2017-06-30 17:26:04 +02:00
|
|
|
extern void zebra_deregister_rnh_pseudowire(vrf_id_t, struct zebra_pw *);
|
2021-09-24 17:04:03 +02:00
|
|
|
extern void zebra_remove_rnh_client(struct rnh *rnh, struct zserv *client);
|
2019-01-21 15:30:36 +01:00
|
|
|
extern void zebra_evaluate_rnh(struct zebra_vrf *zvrf, afi_t afi, int force,
|
2022-03-11 12:47:46 +01:00
|
|
|
const struct prefix *p, safi_t safi);
|
2021-10-21 15:17:41 +02:00
|
|
|
extern void zebra_print_rnh_table(vrf_id_t vrfid, afi_t afi, safi_t safi,
|
zebra: json support for show ip nht
show ip/ipv6 nht vrf <all | name> json support added.
Commands enhanced with JSON:
----------------------------
show ip nht json
show ip nht <addr> json
show ipv6 nht json
show ipv6 nht <addr> json
show ip nht vrf <name> json
show ip nht vrf all json
show ipv6 nht vrf <name> json
show ipv6 nht vrf all json
show ip nht vrf default <addr> json
show ipv6 nht vrf default <addr> json
Sample JSON output:
-------------------
tor-1# show ip nht vrf default json
{
"default":{
"nexthops":{
"27.0.0.5":{
"nhtConnected":false,
"clientList":[
{
"protocol":"bgp",
"socket":70,
"protocolFiltered":"none"
}
],
"gates":[
{
"ip":"fe80::202:ff:fe00:2b",
"interface":"uplink_1"
},
{
"ip":"fe80::202:ff:fe00:35",
"interface":"uplink_2"
}
],
"resolvedProtocol":"bgp"
},
"27.0.0.6":{
"nhtConnected":false,
"clientList":[
{
"protocol":"bgp",
"socket":70,
"protocolFiltered":"none"
}
],
"gates":[
{
"ip":"fe80::202:ff:fe00:2b",
"interface":"uplink_1"
},
{
"ip":"fe80::202:ff:fe00:35",
"interface":"uplink_2"
}
],
"resolvedProtocol":"bgp"
}
}
}
}
tor-1# show ipv6 nht vrf default json
{
"default": {
"nexthops": {
"fe80::202:ff:fe00:25": {
"nhtConnected": true,
"clientList": [
{
"protocol": "bgp",
"socket": 45,
"protocolFiltered": "none"
}
],
"gates": [
{
"interface": "swp1",
"directlyConnected": true
}
],
"resolvedProtocol": "connected"
},
"fe80::202:ff:fe00:2b": {
"nhtConnected": true,
"clientList": [
{
"protocol": "bgp",
"socket": 45,
"protocolFiltered": "none"
}
],
"gates": [
{
"interface": "swp1",
"directlyConnected": true
}
],
"resolvedProtocol": "connected"
}
}
}
}
tor-1# show ipv6 nht vrf all json
{
"default": {
"nexthops": {
"fe80::202:ff:fe00:25": {
"nhtConnected": true,
"clientList": [
{
"protocol": "bgp",
"socket": 45,
"protocolFiltered": "none"
}
],
"gates": [
{
"interface": "swp1",
"directlyConnected": true
}
],
"resolvedProtocol": "connected"
},
"fe80::202:ff:fe00:2b": {
"nhtConnected": true,
"clientList": [
{
"protocol": "bgp",
"socket": 45,
"protocolFiltered": "none"
}
],
"gates": [
{
"interface": "swp1",
"directlyConnected": true
}
],
"resolvedProtocol": "connected"
}
}
},
"mgmt": {
"nexthops": {}
},
"sym_1": {
"nexthops": {}
}
}
Ticket:#3229013
Issue:3229013
Testing Done: Unit test completed.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Signed-off-by: Sindhu Parvathi Gopinathan <sgopinathan@nvidia.com>
2022-11-15 04:33:56 +01:00
|
|
|
struct vty *vty, const struct prefix *p,
|
|
|
|
|
json_object *json);
|
2019-03-25 15:11:55 +01:00
|
|
|
|
2019-08-28 16:01:38 +02:00
|
|
|
extern int rnh_resolve_via_default(struct zebra_vrf *zvrf, int family);
|
|
|
|
|
|
2021-07-07 22:52:24 +02:00
|
|
|
extern bool rnh_nexthop_valid(const struct route_entry *re,
|
|
|
|
|
const struct nexthop *nh);
|
|
|
|
|
|
2021-03-01 16:48:05 +01:00
|
|
|
/* UI control to avoid notifications if backup nexthop status changes */
|
|
|
|
|
void rnh_set_hide_backups(bool hide_p);
|
|
|
|
|
bool rnh_get_hide_backups(void);
|
|
|
|
|
|
zebra: fix JSON fields for "show ip/ipv6 nht"
1. Renamed "gates" to "nexthops"
2. Displaying afi of the nexthops being dispalyed in place of
"nexthops" JSON object in the old JSON output
3. Calling show_route_nexthop_helper() and show_nexthop_json_helper()
instead of print_nh() inorder to keeps the fields in "nexthops"
JSON object in sync with "nexthops" JSON object of
"show nexthop-group rib json".
Updated vtysh:
r1# show ip nht
192.168.0.2
resolved via connected
is directly connected, r1-eth0 (vrf default)
Client list: static(fd 28)
192.168.0.4
resolved via connected
is directly connected, r1-eth0 (vrf default)
Client list: static(fd 28)
Updated JSON:
r1# show ip nht json
{
"default":{
"ipv4":{
"192.168.0.2":{
"nhtConnected":false,
"clientList":[
{
"protocol":"static",
"socket":28,
"protocolFiltered":"none"
}
],
"nexthops":[
{
"flags":3,
"fib":true,
"directlyConnected":true,
"interfaceIndex":2,
"interfaceName":"r1-eth0",
"vrf":"default",
"active":true
}
],
"resolvedProtocol":"connected"
}
}
}
}
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
2023-01-25 03:15:36 +01:00
|
|
|
void show_nexthop_json_helper(json_object *json_nexthop,
|
|
|
|
|
const struct nexthop *nexthop,
|
2024-05-14 16:28:17 +02:00
|
|
|
const struct route_node *rn,
|
zebra: fix JSON fields for "show ip/ipv6 nht"
1. Renamed "gates" to "nexthops"
2. Displaying afi of the nexthops being dispalyed in place of
"nexthops" JSON object in the old JSON output
3. Calling show_route_nexthop_helper() and show_nexthop_json_helper()
instead of print_nh() inorder to keeps the fields in "nexthops"
JSON object in sync with "nexthops" JSON object of
"show nexthop-group rib json".
Updated vtysh:
r1# show ip nht
192.168.0.2
resolved via connected
is directly connected, r1-eth0 (vrf default)
Client list: static(fd 28)
192.168.0.4
resolved via connected
is directly connected, r1-eth0 (vrf default)
Client list: static(fd 28)
Updated JSON:
r1# show ip nht json
{
"default":{
"ipv4":{
"192.168.0.2":{
"nhtConnected":false,
"clientList":[
{
"protocol":"static",
"socket":28,
"protocolFiltered":"none"
}
],
"nexthops":[
{
"flags":3,
"fib":true,
"directlyConnected":true,
"interfaceIndex":2,
"interfaceName":"r1-eth0",
"vrf":"default",
"active":true
}
],
"resolvedProtocol":"connected"
}
}
}
}
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
2023-01-25 03:15:36 +01:00
|
|
|
const struct route_entry *re);
|
2024-05-14 16:28:17 +02:00
|
|
|
void show_route_nexthop_helper(struct vty *vty, const struct route_node *rn,
|
|
|
|
|
const struct route_entry *re,
|
zebra: fix JSON fields for "show ip/ipv6 nht"
1. Renamed "gates" to "nexthops"
2. Displaying afi of the nexthops being dispalyed in place of
"nexthops" JSON object in the old JSON output
3. Calling show_route_nexthop_helper() and show_nexthop_json_helper()
instead of print_nh() inorder to keeps the fields in "nexthops"
JSON object in sync with "nexthops" JSON object of
"show nexthop-group rib json".
Updated vtysh:
r1# show ip nht
192.168.0.2
resolved via connected
is directly connected, r1-eth0 (vrf default)
Client list: static(fd 28)
192.168.0.4
resolved via connected
is directly connected, r1-eth0 (vrf default)
Client list: static(fd 28)
Updated JSON:
r1# show ip nht json
{
"default":{
"ipv4":{
"192.168.0.2":{
"nhtConnected":false,
"clientList":[
{
"protocol":"static",
"socket":28,
"protocolFiltered":"none"
}
],
"nexthops":[
{
"flags":3,
"fib":true,
"directlyConnected":true,
"interfaceIndex":2,
"interfaceName":"r1-eth0",
"vrf":"default",
"active":true
}
],
"resolvedProtocol":"connected"
}
}
}
}
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
2023-01-25 03:15:36 +01:00
|
|
|
const struct nexthop *nexthop);
|
|
|
|
|
|
2019-03-25 15:11:55 +01:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2015-05-20 02:40:34 +02:00
|
|
|
#endif /*_ZEBRA_RNH_H */
|