2023-02-08 13:17:09 +01:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2002-12-13 21:15:29 +01:00
|
|
|
/* Redistribution Handler
|
|
|
|
* Copyright (C) 1998 Kunihiro Ishiguro
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <zebra.h>
|
|
|
|
|
|
|
|
#include "vector.h"
|
|
|
|
#include "vty.h"
|
|
|
|
#include "command.h"
|
|
|
|
#include "prefix.h"
|
|
|
|
#include "table.h"
|
|
|
|
#include "stream.h"
|
|
|
|
#include "zclient.h"
|
|
|
|
#include "linklist.h"
|
|
|
|
#include "log.h"
|
2015-05-22 11:39:56 +02:00
|
|
|
#include "vrf.h"
|
2016-12-05 20:05:30 +01:00
|
|
|
#include "srcdest_table.h"
|
2023-11-04 09:47:46 +01:00
|
|
|
#include "frrdistance.h"
|
2002-12-13 21:15:29 +01:00
|
|
|
|
|
|
|
#include "zebra/rib.h"
|
2019-01-11 19:38:19 +01:00
|
|
|
#include "zebra/zebra_router.h"
|
2016-04-14 15:20:47 +02:00
|
|
|
#include "zebra/zebra_ns.h"
|
|
|
|
#include "zebra/zebra_vrf.h"
|
2016-05-11 17:47:02 +02:00
|
|
|
#include "zebra/zebra_routemap.h"
|
2002-12-13 21:15:29 +01:00
|
|
|
#include "zebra/redistribute.h"
|
|
|
|
#include "zebra/debug.h"
|
2004-10-03 20:18:34 +02:00
|
|
|
#include "zebra/router-id.h"
|
2018-04-22 22:01:20 +02:00
|
|
|
#include "zebra/zapi_msg.h"
|
2017-06-28 10:51:10 +02:00
|
|
|
#include "zebra/zebra_vxlan.h"
|
2018-08-24 19:14:09 +02:00
|
|
|
#include "zebra/zebra_errors.h"
|
2023-10-31 16:09:48 +01:00
|
|
|
#include "zebra/zebra_neigh.h"
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2015-05-20 02:40:44 +02:00
|
|
|
#define ZEBRA_PTM_SUPPORT
|
|
|
|
|
2015-05-20 03:03:42 +02:00
|
|
|
/* array holding redistribute info about table redistribution */
|
|
|
|
/* bit AFI is set if that AFI is redistributing routes from this table */
|
2016-09-27 17:57:56 +02:00
|
|
|
static int zebra_import_table_used[AFI_MAX][ZEBRA_KERNEL_TABLE_MAX];
|
2018-03-27 21:13:34 +02:00
|
|
|
static uint32_t zebra_import_table_distance[AFI_MAX][ZEBRA_KERNEL_TABLE_MAX];
|
2015-05-20 03:03:42 +02:00
|
|
|
|
2019-06-25 23:07:30 +02:00
|
|
|
int is_zebra_import_table_enabled(afi_t afi, vrf_id_t vrf_id, uint32_t table_id)
|
2015-05-20 03:03:42 +02:00
|
|
|
{
|
2017-08-25 14:07:58 +02:00
|
|
|
/*
|
|
|
|
* Make sure that what we are called with actualy makes sense
|
|
|
|
*/
|
|
|
|
if (afi == AFI_MAX)
|
|
|
|
return 0;
|
|
|
|
|
2018-03-16 05:02:56 +01:00
|
|
|
if (is_zebra_valid_kernel_table(table_id) &&
|
|
|
|
table_id < ZEBRA_KERNEL_TABLE_MAX)
|
2016-09-27 17:57:56 +02:00
|
|
|
return zebra_import_table_used[afi][table_id];
|
2015-05-20 03:03:42 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
*: 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
|
|
|
static void zebra_redistribute_default(struct zserv *client, vrf_id_t vrf_id)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
2016-10-06 14:18:41 +02:00
|
|
|
int afi;
|
|
|
|
struct prefix p;
|
2002-12-13 21:15:29 +01:00
|
|
|
struct route_table *table;
|
|
|
|
struct route_node *rn;
|
2017-06-01 13:26:25 +02:00
|
|
|
struct route_entry *newre;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2016-10-06 14:18:41 +02:00
|
|
|
for (afi = AFI_IP; afi <= AFI_IP6; afi++) {
|
2020-03-08 23:48:20 +01:00
|
|
|
|
2023-04-19 14:13:18 +02:00
|
|
|
if (!vrf_bitmap_check(&client->redist_default[afi], vrf_id))
|
2020-03-08 23:48:20 +01:00
|
|
|
continue;
|
|
|
|
|
2016-10-06 14:18:41 +02:00
|
|
|
/* Lookup table. */
|
|
|
|
table = zebra_vrf_table(afi, SAFI_UNICAST, vrf_id);
|
|
|
|
if (!table)
|
|
|
|
continue;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2016-10-06 14:18:41 +02:00
|
|
|
/* Lookup default route. */
|
|
|
|
memset(&p, 0, sizeof(p));
|
|
|
|
p.family = afi2family(afi);
|
|
|
|
rn = route_node_lookup(table, &p);
|
|
|
|
if (!rn)
|
|
|
|
continue;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-09-15 17:47:35 +02:00
|
|
|
RNODE_FOREACH_RE (rn, newre) {
|
zebra: Allow redistribution for routes selected
Current code has an inconsistent behavior with redistribute routes.
Suppose you have a kernel route that is being read w/ a distance
of 255:
eva# show ip route kernel
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, 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
K>* 0.0.0.0/0 [0/100] via 192.168.161.1, enp39s0, 00:06:39
K>* 4.4.4.4/32 [255/8192] via 192.168.161.1, enp39s0, 00:01:26
eva#
If you have redistribution already turned on for kernel routes
you will be notified of the 4.4.4.4/32 route. If you turn
on kernel route redistribution watching after the 4.4.4.4/32 route
has been read by zebra you will never learn of it.
There is no need to look for infinite distance in the redistribution
code. Either we are selected or not. In other words non kernel routes
with an 255 distance are never installed so the checks were pointless.
So let's just remove the distance checking and tell interested parties
about the 255 kernel route if it exists.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-05-04 01:53:12 +02:00
|
|
|
if (CHECK_FLAG(newre->flags, ZEBRA_FLAG_SELECTED))
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
zsend_redistribute_route(ZEBRA_REDISTRIBUTE_ROUTE_ADD,
|
|
|
|
client, rn, newre, false);
|
2017-09-11 19:13:17 +02:00
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2016-10-06 14:18:41 +02:00
|
|
|
route_unlock_node(rn);
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Redistribute routes. */
|
2018-03-27 21:13:34 +02:00
|
|
|
static void zebra_redistribute(struct zserv *client, int type,
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
unsigned short instance, struct zebra_vrf *zvrf,
|
2018-03-27 21:13:34 +02:00
|
|
|
int afi)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
2017-06-01 13:26:25 +02:00
|
|
|
struct route_entry *newre;
|
2002-12-13 21:15:29 +01:00
|
|
|
struct route_table *table;
|
|
|
|
struct route_node *rn;
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
bool is_table_direct = false;
|
|
|
|
vrf_id_t vrf_id = zvrf_id(zvrf);
|
|
|
|
|
|
|
|
if (type == ZEBRA_ROUTE_TABLE_DIRECT) {
|
|
|
|
if (vrf_id == VRF_DEFAULT) {
|
|
|
|
table = zebra_router_find_table(zvrf, instance, afi,
|
|
|
|
SAFI_UNICAST);
|
|
|
|
type = ZEBRA_ROUTE_ALL;
|
|
|
|
is_table_direct = true;
|
|
|
|
} else
|
|
|
|
return;
|
|
|
|
} else
|
|
|
|
table = zebra_vrf_table(afi, SAFI_UNICAST, vrf_id);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-05-17 01:58:34 +02:00
|
|
|
if (!table)
|
|
|
|
return;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-08-22 15:57:55 +02:00
|
|
|
for (rn = route_top(table); rn; rn = srcdest_route_next(rn))
|
2017-09-15 17:47:35 +02:00
|
|
|
RNODE_FOREACH_RE (rn, newre) {
|
2019-08-23 14:28:43 +02:00
|
|
|
if (IS_ZEBRA_DEBUG_RIB)
|
2017-05-17 01:58:34 +02:00
|
|
|
zlog_debug(
|
2023-02-12 18:28:10 +01:00
|
|
|
"%s: client %s %pRN(%u:%u) checking: selected=%d, type=%s, instance=%u, distance=%d, metric=%d zebra_check_addr=%d",
|
2017-05-18 12:15:04 +02:00
|
|
|
__func__,
|
2022-01-14 17:26:51 +01:00
|
|
|
zebra_route_string(client->proto), rn,
|
|
|
|
vrf_id, newre->instance,
|
2022-01-03 18:11:37 +01:00
|
|
|
!!CHECK_FLAG(newre->flags,
|
|
|
|
ZEBRA_FLAG_SELECTED),
|
2023-02-12 18:28:10 +01:00
|
|
|
zebra_route_string(newre->type),
|
|
|
|
newre->instance,
|
|
|
|
newre->distance,
|
2022-01-14 17:26:51 +01:00
|
|
|
newre->metric,
|
|
|
|
zebra_check_addr(&rn->p));
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-06-01 13:26:25 +02:00
|
|
|
if (!CHECK_FLAG(newre->flags, ZEBRA_FLAG_SELECTED))
|
2017-05-17 01:58:34 +02:00
|
|
|
continue;
|
|
|
|
if ((type != ZEBRA_ROUTE_ALL
|
2017-06-01 13:26:25 +02:00
|
|
|
&& (newre->type != type
|
|
|
|
|| newre->instance != instance)))
|
2017-05-17 01:58:34 +02:00
|
|
|
continue;
|
2022-01-14 17:26:51 +01:00
|
|
|
if (!zebra_check_addr(&rn->p))
|
2017-05-17 01:58:34 +02:00
|
|
|
continue;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-08-21 03:10:50 +02:00
|
|
|
zsend_redistribute_route(ZEBRA_REDISTRIBUTE_ROUTE_ADD,
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
client, rn, newre, is_table_direct);
|
2017-05-17 01:58:34 +02:00
|
|
|
}
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
/*
|
|
|
|
* Function to return a valid table id value if table-direct is used
|
|
|
|
* return 0 otherwise
|
|
|
|
* This function can be called only if zebra_redistribute_check returns TRUE
|
|
|
|
*/
|
|
|
|
static bool zebra_redistribute_is_table_direct(const struct route_entry *re)
|
|
|
|
{
|
|
|
|
struct zebra_vrf *zvrf;
|
|
|
|
|
|
|
|
zvrf = zebra_vrf_lookup_by_id(re->vrf_id);
|
|
|
|
if (re->vrf_id == VRF_DEFAULT && zvrf->table_id != re->table)
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2020-04-07 16:02:21 +02:00
|
|
|
/*
|
|
|
|
* Function to check if prefix is candidate for
|
|
|
|
* redistribute.
|
|
|
|
*/
|
2022-01-14 17:18:48 +01:00
|
|
|
static bool zebra_redistribute_check(const struct route_node *rn,
|
|
|
|
const struct route_entry *re,
|
|
|
|
struct zserv *client)
|
2020-04-07 16:02:21 +02:00
|
|
|
{
|
2021-07-20 01:52:43 +02:00
|
|
|
struct zebra_vrf *zvrf;
|
2022-01-14 17:18:48 +01:00
|
|
|
afi_t afi;
|
2021-07-20 01:52:43 +02:00
|
|
|
|
2020-04-07 16:02:21 +02:00
|
|
|
/* Process only if there is valid re */
|
|
|
|
if (!re)
|
|
|
|
return false;
|
|
|
|
|
2022-01-14 17:18:48 +01:00
|
|
|
afi = family2afi(rn->p.family);
|
2023-03-28 21:49:50 +02:00
|
|
|
zvrf = zebra_vrf_lookup_by_id(re->vrf_id);
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
if (re->vrf_id == VRF_DEFAULT && zvrf->table_id != re->table) {
|
|
|
|
if (re->table &&
|
|
|
|
redist_check_instance(&client->mi_redist
|
|
|
|
[afi][ZEBRA_ROUTE_TABLE_DIRECT],
|
|
|
|
re->table)) {
|
|
|
|
/* table-direct redistribution only for route entries which
|
|
|
|
* are on the default vrf, and that have table id different
|
|
|
|
* from the default table.
|
|
|
|
*/
|
|
|
|
return true;
|
|
|
|
}
|
2021-07-20 01:52:43 +02:00
|
|
|
return false;
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
}
|
2021-07-20 01:52:43 +02:00
|
|
|
|
2020-04-07 16:02:21 +02:00
|
|
|
/* If default route and redistributed */
|
2022-01-14 17:18:48 +01:00
|
|
|
if (is_default_prefix(&rn->p) &&
|
2023-04-19 14:13:18 +02:00
|
|
|
vrf_bitmap_check(&client->redist_default[afi], re->vrf_id))
|
2020-04-07 16:02:21 +02:00
|
|
|
return true;
|
|
|
|
|
|
|
|
/* If redistribute in enabled for zebra route all */
|
2023-04-19 14:13:18 +02:00
|
|
|
if (vrf_bitmap_check(&client->redist[afi][ZEBRA_ROUTE_ALL], re->vrf_id))
|
2020-04-07 16:02:21 +02:00
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If multi-instance then check for route
|
|
|
|
* redistribution for given instance.
|
|
|
|
*/
|
zebra: Do not allow instance redistribution to happen no matter what
If you have this setup:
router ospf 3
redistribute sharp
!
and then install:
sharp install route 4.5.6.7 nexthop 192.168.100.1 1
sharp install route 4.5.6.8 nexthop 192.168.100.1 1 instance 3
sharp install route 4.5.6.9 nexthop 192.168.100.1 1 instance 4
The .8 and .9 routes are auto redistributed into ospf instance 3:
eva# show ip ospf data
OSPF Instance: 3
OSPF Router with ID (192.168.122.1)
AS External Link States
Link ID ADV Router Age Seq# CkSum Route
4.5.6.7 192.168.122.1 13 0x80000001 0x477c E2 4.5.6.7/32 [0x0]
4.5.6.8 192.168.122.1 5 0x80000001 0x3d85 E2 4.5.6.8/32 [0x0]
4.5.6.9 192.168.122.1 5 0x80000001 0x338e E2 4.5.6.9/32 [0x0]
This cannot be correct behavior. When redistributing in the absense
of an instance number the default instance of 0 should be used and should
be the only route redistributed. Here is the correct behavior:
eva# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, 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
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:00:28
D>* 4.5.6.7/32 [150/0] via 192.168.100.1, virbr1, weight 1, 00:00:02
D[3]>* 4.5.6.8/32 [150/0] via 192.168.100.1, virbr1, weight 1, 00:00:02
D[4]>* 4.5.6.9/32 [150/0] via 192.168.100.1, virbr1, weight 1, 00:00:02
C>* 192.168.100.0/24 is directly connected, virbr1, 00:00:28
C>* 192.168.110.0/24 is directly connected, virbr2, 00:00:28
C>* 192.168.119.0/24 is directly connected, enp39s0, 00:00:28
C>* 192.168.122.0/24 is directly connected, virbr0, 00:00:28
eva# show ip ospf data
OSPF Instance: 3
OSPF Router with ID (192.168.122.1)
AS External Link States
Link ID ADV Router Age Seq# CkSum Route
4.5.6.7 192.168.122.1 6 0x80000001 0x477c E2 4.5.6.7/32 [0x0]
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-01-04 12:57:53 +01:00
|
|
|
if (re->instance) {
|
|
|
|
if (redist_check_instance(&client->mi_redist[afi][re->type],
|
|
|
|
re->instance))
|
|
|
|
return true;
|
|
|
|
else
|
|
|
|
return false;
|
|
|
|
}
|
2020-04-07 16:02:21 +02:00
|
|
|
|
|
|
|
/* If redistribution is enabled for give route type. */
|
2023-04-19 14:13:18 +02:00
|
|
|
if (vrf_bitmap_check(&client->redist[afi][re->type], re->vrf_id))
|
2020-04-07 16:02:21 +02:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-10-21 06:52:52 +02:00
|
|
|
/* Either advertise a route for redistribution to registered clients or */
|
|
|
|
/* withdraw redistribution if add cannot be done for client */
|
2022-01-14 16:00:01 +01:00
|
|
|
void redistribute_update(const struct route_node *rn,
|
2019-08-14 19:30:24 +02:00
|
|
|
const struct route_entry *re,
|
|
|
|
const struct route_entry *prev_re)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
2005-04-07 Paul Jakma <paul.jakma@sun.com>
* (global): Fix up list loops to match changes in lib/linklist,
and some basic auditing of usage.
* configure.ac: define QUAGGA_NO_DEPRECATED_INTERFACES
* HACKING: Add notes about deprecating interfaces and commands.
* lib/linklist.h: Add usage comments.
Rename getdata macro to listgetdata.
Rename nextnode to listnextnode and fix its odd behaviour to be
less dangerous.
Make listgetdata macro assert node is not null, NULL list entries
should be bug condition.
ALL_LIST_ELEMENTS, new macro, forward-referencing macro for use
with for loop, Suggested by Jim Carlson of Sun.
Add ALL_LIST_ELEMENTS_RO for cases which obviously do not need the
"safety" of previous macro.
LISTNODE_ADD and DELETE macros renamed to ATTACH, DETACH, to
distinguish from the similarly named functions, and reflect their
effect better.
Add a QUAGGA_NO_DEPRECATED_INTERFACES define guarded section
with the old defines which were modified above,
for backwards compatibility - guarded to prevent Quagga using it..
* lib/linklist.c: fix up for linklist.h changes.
* ospf6d/ospf6_abr.c: (ospf6_abr_examin_brouter) change to a single
scan of the area list, rather than scanning all areas first for
INTER_ROUTER and then again for INTER_NETWORK. According to
16.2, the scan should be area specific anyway, and further
ospf6d does not seem to implement 16.3 anyway.
2005-04-07 09:30:20 +02:00
|
|
|
struct listnode *node, *nnode;
|
2002-12-13 21:15:29 +01:00
|
|
|
struct zserv *client;
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
bool is_table_direct;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2020-10-18 13:33:54 +02:00
|
|
|
if (IS_ZEBRA_DEBUG_RIB)
|
2017-06-01 13:26:25 +02:00
|
|
|
zlog_debug(
|
2022-01-14 16:00:01 +01:00
|
|
|
"(%u:%u):%pRN(%u): Redist update re %p (%s), old %p (%s)",
|
|
|
|
re->vrf_id, re->table, rn, re->instance, re,
|
2020-10-18 13:33:54 +02:00
|
|
|
zebra_route_string(re->type), prev_re,
|
2019-01-30 03:35:07 +01:00
|
|
|
prev_re ? zebra_route_string(prev_re->type) : "None");
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2022-01-14 16:00:01 +01:00
|
|
|
if (!zebra_check_addr(&rn->p)) {
|
2019-08-14 09:18:43 +02:00
|
|
|
if (IS_ZEBRA_DEBUG_RIB)
|
2022-01-14 16:00:01 +01:00
|
|
|
zlog_debug("Redist update filter prefix %pRN", rn);
|
2019-08-14 09:18:43 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2019-01-11 19:38:19 +01:00
|
|
|
for (ALL_LIST_ELEMENTS(zrouter.client_list, node, nnode, client)) {
|
2022-01-14 17:18:48 +01:00
|
|
|
if (zebra_redistribute_check(rn, re, client)) {
|
2019-08-23 14:28:43 +02:00
|
|
|
if (IS_ZEBRA_DEBUG_RIB) {
|
2018-04-23 14:26:33 +02:00
|
|
|
zlog_debug(
|
2022-01-14 16:00:01 +01:00
|
|
|
"%s: client %s %pRN(%u:%u), type=%d, distance=%d, metric=%d",
|
2020-08-19 16:11:06 +02:00
|
|
|
__func__,
|
2022-01-14 16:00:01 +01:00
|
|
|
zebra_route_string(client->proto), rn,
|
2020-08-19 16:11:06 +02:00
|
|
|
re->vrf_id, re->table, re->type,
|
|
|
|
re->distance, re->metric);
|
2018-04-23 14:26:33 +02:00
|
|
|
}
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
is_table_direct = zebra_redistribute_is_table_direct(re);
|
2017-08-21 03:10:50 +02:00
|
|
|
zsend_redistribute_route(ZEBRA_REDISTRIBUTE_ROUTE_ADD,
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
client, rn, re,
|
|
|
|
is_table_direct);
|
|
|
|
} else if (zebra_redistribute_check(rn, prev_re, client)) {
|
|
|
|
is_table_direct = zebra_redistribute_is_table_direct(prev_re);
|
2017-08-21 03:10:50 +02:00
|
|
|
zsend_redistribute_route(ZEBRA_REDISTRIBUTE_ROUTE_DEL,
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
client, rn, prev_re,
|
|
|
|
is_table_direct);
|
|
|
|
}
|
2015-10-21 06:52:52 +02:00
|
|
|
}
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
2019-08-14 19:30:24 +02:00
|
|
|
/*
|
|
|
|
* During a route delete, where 'new_re' is NULL, redist a delete to all
|
|
|
|
* clients registered for the type of 'old_re'.
|
|
|
|
* During a route update, redist a delete to any clients who will not see
|
|
|
|
* an update when the new route is installed. There are cases when a client
|
|
|
|
* may have seen a redist for 'old_re', but will not see
|
|
|
|
* the redist for 'new_re'.
|
|
|
|
*/
|
2022-01-14 15:48:00 +01:00
|
|
|
void redistribute_delete(const struct route_node *rn,
|
2019-08-14 19:30:24 +02:00
|
|
|
const struct route_entry *old_re,
|
|
|
|
const struct route_entry *new_re)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
2005-04-07 Paul Jakma <paul.jakma@sun.com>
* (global): Fix up list loops to match changes in lib/linklist,
and some basic auditing of usage.
* configure.ac: define QUAGGA_NO_DEPRECATED_INTERFACES
* HACKING: Add notes about deprecating interfaces and commands.
* lib/linklist.h: Add usage comments.
Rename getdata macro to listgetdata.
Rename nextnode to listnextnode and fix its odd behaviour to be
less dangerous.
Make listgetdata macro assert node is not null, NULL list entries
should be bug condition.
ALL_LIST_ELEMENTS, new macro, forward-referencing macro for use
with for loop, Suggested by Jim Carlson of Sun.
Add ALL_LIST_ELEMENTS_RO for cases which obviously do not need the
"safety" of previous macro.
LISTNODE_ADD and DELETE macros renamed to ATTACH, DETACH, to
distinguish from the similarly named functions, and reflect their
effect better.
Add a QUAGGA_NO_DEPRECATED_INTERFACES define guarded section
with the old defines which were modified above,
for backwards compatibility - guarded to prevent Quagga using it..
* lib/linklist.c: fix up for linklist.h changes.
* ospf6d/ospf6_abr.c: (ospf6_abr_examin_brouter) change to a single
scan of the area list, rather than scanning all areas first for
INTER_ROUTER and then again for INTER_NETWORK. According to
16.2, the scan should be area specific anyway, and further
ospf6d does not seem to implement 16.3 anyway.
2005-04-07 09:30:20 +02:00
|
|
|
struct listnode *node, *nnode;
|
2002-12-13 21:15:29 +01:00
|
|
|
struct zserv *client;
|
2019-08-14 19:30:24 +02:00
|
|
|
vrf_id_t vrfid;
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
bool is_table_direct;
|
2019-08-14 19:30:24 +02:00
|
|
|
|
|
|
|
if (old_re)
|
|
|
|
vrfid = old_re->vrf_id;
|
|
|
|
else if (new_re)
|
|
|
|
vrfid = new_re->vrf_id;
|
|
|
|
else
|
|
|
|
return;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2015-11-20 17:48:32 +01:00
|
|
|
if (IS_ZEBRA_DEBUG_RIB) {
|
2022-01-14 19:16:17 +01:00
|
|
|
uint8_t old_inst, new_inst;
|
|
|
|
uint32_t table = 0;
|
|
|
|
|
|
|
|
old_inst = new_inst = 0;
|
|
|
|
|
|
|
|
if (old_re) {
|
|
|
|
old_inst = old_re->instance;
|
|
|
|
table = old_re->table;
|
|
|
|
}
|
|
|
|
if (new_re) {
|
|
|
|
new_inst = new_re->instance;
|
|
|
|
table = new_re->table;
|
|
|
|
}
|
|
|
|
|
2023-07-10 15:42:14 +02:00
|
|
|
zlog_debug("(%u:%u):%pRN: Redist del: re %p (%u:%s), new re %p (%u:%s)",
|
|
|
|
vrfid, table, rn, old_re, old_inst,
|
|
|
|
old_re ? zebra_route_string(old_re->type) : "None",
|
|
|
|
new_re, new_inst,
|
|
|
|
new_re ? zebra_route_string(new_re->type) : "None");
|
2015-11-20 17:48:32 +01:00
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2019-08-14 19:30:24 +02:00
|
|
|
/* Skip invalid (e.g. linklocal) prefix */
|
2022-01-14 15:48:00 +01:00
|
|
|
if (!zebra_check_addr(&rn->p)) {
|
2019-08-14 19:30:24 +02:00
|
|
|
if (IS_ZEBRA_DEBUG_RIB) {
|
|
|
|
zlog_debug(
|
2022-01-14 15:48:00 +01:00
|
|
|
"%u:%pRN: Redist del old: skipping invalid prefix",
|
|
|
|
vrfid, rn);
|
2019-08-14 19:30:24 +02:00
|
|
|
}
|
2019-08-14 09:18:43 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-01-11 19:38:19 +01:00
|
|
|
for (ALL_LIST_ELEMENTS(zrouter.client_list, node, nnode, client)) {
|
2020-03-06 16:33:40 +01:00
|
|
|
/* Do not send unsolicited messages to synchronous clients. */
|
|
|
|
if (client->synchronous)
|
|
|
|
continue;
|
2020-04-07 16:02:21 +02:00
|
|
|
/*
|
|
|
|
* Skip this client if it will receive an update for the
|
|
|
|
* 'new' re
|
|
|
|
*/
|
2022-01-14 17:18:48 +01:00
|
|
|
if (zebra_redistribute_check(rn, new_re, client))
|
2020-04-07 16:02:21 +02:00
|
|
|
continue;
|
2019-08-14 19:30:24 +02:00
|
|
|
|
|
|
|
/* Send a delete for the 'old' re to any subscribed client. */
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
if (zebra_redistribute_check(rn, old_re, client)) {
|
|
|
|
is_table_direct = zebra_redistribute_is_table_direct(old_re);
|
2017-08-21 03:10:50 +02:00
|
|
|
zsend_redistribute_route(ZEBRA_REDISTRIBUTE_ROUTE_DEL,
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
client, rn, old_re,
|
|
|
|
is_table_direct);
|
|
|
|
}
|
2005-04-07 Paul Jakma <paul.jakma@sun.com>
* (global): Fix up list loops to match changes in lib/linklist,
and some basic auditing of usage.
* configure.ac: define QUAGGA_NO_DEPRECATED_INTERFACES
* HACKING: Add notes about deprecating interfaces and commands.
* lib/linklist.h: Add usage comments.
Rename getdata macro to listgetdata.
Rename nextnode to listnextnode and fix its odd behaviour to be
less dangerous.
Make listgetdata macro assert node is not null, NULL list entries
should be bug condition.
ALL_LIST_ELEMENTS, new macro, forward-referencing macro for use
with for loop, Suggested by Jim Carlson of Sun.
Add ALL_LIST_ELEMENTS_RO for cases which obviously do not need the
"safety" of previous macro.
LISTNODE_ADD and DELETE macros renamed to ATTACH, DETACH, to
distinguish from the similarly named functions, and reflect their
effect better.
Add a QUAGGA_NO_DEPRECATED_INTERFACES define guarded section
with the old defines which were modified above,
for backwards compatibility - guarded to prevent Quagga using it..
* lib/linklist.c: fix up for linklist.h changes.
* ospf6d/ospf6_abr.c: (ospf6_abr_examin_brouter) change to a single
scan of the area list, rather than scanning all areas first for
INTER_ROUTER and then again for INTER_NETWORK. According to
16.2, the scan should be area specific anyway, and further
ospf6d does not seem to implement 16.3 anyway.
2005-04-07 09:30:20 +02:00
|
|
|
}
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
2020-04-07 16:02:21 +02:00
|
|
|
|
2018-03-06 23:57:33 +01:00
|
|
|
void zebra_redistribute_add(ZAPI_HANDLER_ARGS)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
2017-11-10 14:51:34 +01:00
|
|
|
afi_t afi = 0;
|
|
|
|
int type = 0;
|
2018-03-27 21:13:34 +02:00
|
|
|
unsigned short instance;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2018-03-07 00:08:37 +01:00
|
|
|
STREAM_GETC(msg, afi);
|
|
|
|
STREAM_GETC(msg, type);
|
|
|
|
STREAM_GETW(msg, instance);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2018-03-09 16:53:32 +01:00
|
|
|
if (IS_ZEBRA_DEBUG_EVENT)
|
|
|
|
zlog_debug(
|
2020-02-14 14:41:04 +01:00
|
|
|
"%s: client proto %s afi=%d, wants %s, vrf %s(%u), instance=%d",
|
2018-03-09 16:53:32 +01:00
|
|
|
__func__, zebra_route_string(client->proto), afi,
|
2020-02-14 14:41:04 +01:00
|
|
|
zebra_route_string(type), VRF_LOGNAME(zvrf->vrf),
|
|
|
|
zvrf_id(zvrf), instance);
|
2018-03-09 16:53:32 +01:00
|
|
|
|
2018-07-02 16:30:40 +02:00
|
|
|
if (afi == 0 || afi >= AFI_MAX) {
|
2018-09-13 21:21:05 +02:00
|
|
|
flog_warn(EC_ZEBRA_REDISTRIBUTE_UNKNOWN_AF,
|
2020-03-05 19:17:54 +01:00
|
|
|
"%s: Specified afi %d does not exist", __func__, afi);
|
2009-08-27 00:27:40 +02:00
|
|
|
return;
|
2017-11-10 14:51:34 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (type == 0 || type >= ZEBRA_ROUTE_MAX) {
|
2018-08-16 22:10:32 +02:00
|
|
|
zlog_debug("%s: Specified Route Type %d does not exist",
|
2020-03-05 19:17:54 +01:00
|
|
|
__func__, type);
|
2017-11-10 14:51:34 +01:00
|
|
|
return;
|
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2016-10-06 15:38:55 +02:00
|
|
|
if (instance) {
|
|
|
|
if (!redist_check_instance(&client->mi_redist[afi][type],
|
|
|
|
instance)) {
|
|
|
|
redist_add_instance(&client->mi_redist[afi][type],
|
|
|
|
instance);
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
zebra_redistribute(client, type, instance, zvrf, afi);
|
2017-07-17 14:03:14 +02:00
|
|
|
}
|
2017-05-17 01:58:34 +02:00
|
|
|
} else {
|
2023-04-19 14:13:18 +02:00
|
|
|
if (!vrf_bitmap_check(&client->redist[afi][type],
|
2021-05-09 21:28:36 +02:00
|
|
|
zvrf_id(zvrf))) {
|
|
|
|
if (IS_ZEBRA_DEBUG_EVENT)
|
|
|
|
zlog_debug(
|
|
|
|
"%s: setting vrf %s(%u) redist bitmap",
|
|
|
|
__func__, VRF_LOGNAME(zvrf->vrf),
|
|
|
|
zvrf_id(zvrf));
|
2023-04-19 14:13:18 +02:00
|
|
|
vrf_bitmap_set(&client->redist[afi][type],
|
2021-05-09 21:28:36 +02:00
|
|
|
zvrf_id(zvrf));
|
zebra: add redistribute table-direct support
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-06-17 14:11:35 +02:00
|
|
|
zebra_redistribute(client, type, 0, zvrf, afi);
|
2021-05-09 21:28:36 +02:00
|
|
|
}
|
2016-10-06 15:38:55 +02:00
|
|
|
}
|
2017-11-10 14:51:34 +01:00
|
|
|
|
|
|
|
stream_failure:
|
|
|
|
return;
|
2009-08-27 00:27:40 +02:00
|
|
|
}
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-03-06 23:57:33 +01:00
|
|
|
void zebra_redistribute_delete(ZAPI_HANDLER_ARGS)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
2017-11-10 14:51:34 +01:00
|
|
|
afi_t afi = 0;
|
|
|
|
int type = 0;
|
2018-03-27 21:13:34 +02:00
|
|
|
unsigned short instance;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2018-03-07 00:08:37 +01:00
|
|
|
STREAM_GETC(msg, afi);
|
|
|
|
STREAM_GETC(msg, type);
|
|
|
|
STREAM_GETW(msg, instance);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2021-04-23 10:49:07 +02:00
|
|
|
if (IS_ZEBRA_DEBUG_EVENT)
|
|
|
|
zlog_debug(
|
|
|
|
"%s: client proto %s afi=%d, no longer wants %s, vrf %s(%u), instance=%d",
|
|
|
|
__func__, zebra_route_string(client->proto), afi,
|
|
|
|
zebra_route_string(type), VRF_LOGNAME(zvrf->vrf),
|
|
|
|
zvrf_id(zvrf), instance);
|
|
|
|
|
|
|
|
|
2018-07-02 16:30:40 +02:00
|
|
|
if (afi == 0 || afi >= AFI_MAX) {
|
2018-09-13 21:21:05 +02:00
|
|
|
flog_warn(EC_ZEBRA_REDISTRIBUTE_UNKNOWN_AF,
|
2020-03-05 19:17:54 +01:00
|
|
|
"%s: Specified afi %d does not exist", __func__, afi);
|
2009-08-27 00:27:40 +02:00
|
|
|
return;
|
2017-11-10 14:51:34 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (type == 0 || type >= ZEBRA_ROUTE_MAX) {
|
2018-08-16 22:10:32 +02:00
|
|
|
zlog_debug("%s: Specified Route Type %d does not exist",
|
2020-03-05 19:17:54 +01:00
|
|
|
__func__, type);
|
2017-11-10 14:51:34 +01:00
|
|
|
return;
|
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2016-10-06 15:38:55 +02:00
|
|
|
/*
|
|
|
|
* NOTE: no need to withdraw the previously advertised routes. The
|
|
|
|
* clients
|
|
|
|
* themselves should keep track of the received routes from zebra and
|
|
|
|
* withdraw them when necessary.
|
|
|
|
*/
|
|
|
|
if (instance)
|
2016-10-13 18:06:10 +02:00
|
|
|
redist_del_instance(&client->mi_redist[afi][type], instance);
|
2016-10-06 15:38:55 +02:00
|
|
|
else
|
2023-04-19 14:13:18 +02:00
|
|
|
vrf_bitmap_unset(&client->redist[afi][type], zvrf_id(zvrf));
|
2017-11-10 14:51:34 +01:00
|
|
|
|
|
|
|
stream_failure:
|
|
|
|
return;
|
2009-08-27 00:27:40 +02:00
|
|
|
}
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-03-06 23:57:33 +01:00
|
|
|
void zebra_redistribute_default_add(ZAPI_HANDLER_ARGS)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
2019-01-11 22:20:13 +01:00
|
|
|
afi_t afi = 0;
|
|
|
|
|
|
|
|
STREAM_GETC(msg, afi);
|
|
|
|
|
|
|
|
if (afi == 0 || afi >= AFI_MAX) {
|
|
|
|
flog_warn(EC_ZEBRA_REDISTRIBUTE_UNKNOWN_AF,
|
2020-03-05 19:17:54 +01:00
|
|
|
"%s: Specified afi %u does not exist", __func__, afi);
|
2019-01-11 22:20:13 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2023-04-19 14:13:18 +02:00
|
|
|
vrf_bitmap_set(&client->redist_default[afi], zvrf_id(zvrf));
|
2016-10-30 22:50:26 +01:00
|
|
|
zebra_redistribute_default(client, zvrf_id(zvrf));
|
2019-01-11 22:20:13 +01:00
|
|
|
|
|
|
|
stream_failure:
|
|
|
|
return;
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
2018-03-06 23:57:33 +01:00
|
|
|
void zebra_redistribute_default_delete(ZAPI_HANDLER_ARGS)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
2019-01-11 22:20:13 +01:00
|
|
|
afi_t afi = 0;
|
|
|
|
|
|
|
|
STREAM_GETC(msg, afi);
|
|
|
|
|
|
|
|
if (afi == 0 || afi >= AFI_MAX) {
|
|
|
|
flog_warn(EC_ZEBRA_REDISTRIBUTE_UNKNOWN_AF,
|
2020-03-05 19:17:54 +01:00
|
|
|
"%s: Specified afi %u does not exist", __func__, afi);
|
2019-01-11 22:20:13 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2023-04-19 14:13:18 +02:00
|
|
|
vrf_bitmap_unset(&client->redist_default[afi], zvrf_id(zvrf));
|
2019-01-11 22:20:13 +01:00
|
|
|
|
|
|
|
stream_failure:
|
|
|
|
return;
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Interface up information. */
|
|
|
|
void zebra_interface_up_update(struct interface *ifp)
|
|
|
|
{
|
2005-04-07 Paul Jakma <paul.jakma@sun.com>
* (global): Fix up list loops to match changes in lib/linklist,
and some basic auditing of usage.
* configure.ac: define QUAGGA_NO_DEPRECATED_INTERFACES
* HACKING: Add notes about deprecating interfaces and commands.
* lib/linklist.h: Add usage comments.
Rename getdata macro to listgetdata.
Rename nextnode to listnextnode and fix its odd behaviour to be
less dangerous.
Make listgetdata macro assert node is not null, NULL list entries
should be bug condition.
ALL_LIST_ELEMENTS, new macro, forward-referencing macro for use
with for loop, Suggested by Jim Carlson of Sun.
Add ALL_LIST_ELEMENTS_RO for cases which obviously do not need the
"safety" of previous macro.
LISTNODE_ADD and DELETE macros renamed to ATTACH, DETACH, to
distinguish from the similarly named functions, and reflect their
effect better.
Add a QUAGGA_NO_DEPRECATED_INTERFACES define guarded section
with the old defines which were modified above,
for backwards compatibility - guarded to prevent Quagga using it..
* lib/linklist.c: fix up for linklist.h changes.
* ospf6d/ospf6_abr.c: (ospf6_abr_examin_brouter) change to a single
scan of the area list, rather than scanning all areas first for
INTER_ROUTER and then again for INTER_NETWORK. According to
16.2, the scan should be area specific anyway, and further
ospf6d does not seem to implement 16.3 anyway.
2005-04-07 09:30:20 +02:00
|
|
|
struct listnode *node, *nnode;
|
2002-12-13 21:15:29 +01:00
|
|
|
struct zserv *client;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
if (IS_ZEBRA_DEBUG_EVENT)
|
2021-10-22 00:17:40 +02:00
|
|
|
zlog_debug("MESSAGE: ZEBRA_INTERFACE_UP %s vrf %s(%u)",
|
|
|
|
ifp->name, ifp->vrf->name, ifp->vrf->vrf_id);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2015-05-20 02:40:44 +02:00
|
|
|
if (ifp->ptm_status || !ifp->ptm_enable) {
|
2019-01-11 19:38:19 +01:00
|
|
|
for (ALL_LIST_ELEMENTS(zrouter.client_list, node, nnode,
|
2019-02-04 17:45:31 +01:00
|
|
|
client)) {
|
2020-03-06 16:33:40 +01:00
|
|
|
/* Do not send unsolicited messages to synchronous
|
|
|
|
* clients.
|
|
|
|
*/
|
|
|
|
if (client->synchronous)
|
|
|
|
continue;
|
|
|
|
|
2019-02-04 17:45:31 +01:00
|
|
|
zsend_interface_update(ZEBRA_INTERFACE_UP,
|
|
|
|
client, ifp);
|
|
|
|
zsend_interface_link_params(client, ifp);
|
|
|
|
}
|
Update Traffic Engineering Support for OSPFD
NOTE: I am squashing several commits together because they
do not independently compile and we need this ability to
do any type of sane testing on the patches. Since this
series builds together I am doing this. -DBS
This new structure is the basis to get new link parameters for
Traffic Engineering from Zebra/interface layer to OSPFD and ISISD
for the support of Traffic Engineering
* lib/if.[c,h]: link parameters struture and get/set functions
* lib/command.[c,h]: creation of a new link-node
* lib/zclient.[c,h]: modification to the ZBUS message to convey the
link parameters structure
* lib/zebra.h: New ZBUS message
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add support for IEEE 754 format
* lib/stream.[c,h]: Add stream_get{f,d} and stream_put{f,d}) demux and muxers to
safely convert between big-endian IEEE-754 single and double binary
format, as used in IETF RFCs, and C99. Implementation depends on host
using __STDC_IEC_559__, which should be everything we care about. Should
correctly error out otherwise.
* lib/network.[c,h]: Add ntohf and htonf converter
* lib/memtypes.c: Add new memeory type for Traffic Engineering support
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add link parameters support to Zebra
* zebra/interface.c:
- Add new link-params CLI commands
- Add new functions to set/get link parameters for interface
* zebra/redistribute.[c,h]: Add new function to propagate link parameters
to routing daemon (essentially OSPFD and ISISD) for Traffic Engineering.
* zebra/redistribute_null.c: Add new function
zebra_interface_parameters_update()
* zebra/zserv.[c,h]: Add new functions to send link parameters
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add support of new link-params CLI to vtysh
In vtysh_config.c/vtysh_config_parse_line(), it is not possible to continue
to use the ordered version for adding line i.e. config_add_line_uniq() to print
Interface CLI commands as it completely break the new LINK_PARAMS_NODE.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Update Traffic Engineering support for OSPFD
These patches update original code to RFC3630 (OSPF-TE) and add support of
RFC5392 (Inter-AS v2) & RFC7471 (TE metric extensions) and partial support
of RFC6827 (ASON - GMPLS).
* ospfd/ospf_dump.[c,h]: Add new dump functions for Traffic Engineering
* ospfd/ospf_opaque.[c,h]: Add new TLV code points for RFC5392
* ospfd/ospf_packet.c: Update checking of OSPF_OPTION
* ospfd/ospf_vty.[c,h]: Update ospf_str2area_id
* ospfd/ospf_zebra.c: Add new function ospf_interface_link_params() to get
Link Parameters information from the interface to populate Traffic Engineering
metrics
* ospfd/ospfd.[c,h]: Update OSPF_OPTION flags (T -> MT and new DN)
* ospfd/ospf_te.[c,h]: Major modifications to update the code to new
link parameters structure and new RFCs
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
tmp
2016-04-19 16:21:46 +02:00
|
|
|
}
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Interface down information. */
|
|
|
|
void zebra_interface_down_update(struct interface *ifp)
|
|
|
|
{
|
2005-04-07 Paul Jakma <paul.jakma@sun.com>
* (global): Fix up list loops to match changes in lib/linklist,
and some basic auditing of usage.
* configure.ac: define QUAGGA_NO_DEPRECATED_INTERFACES
* HACKING: Add notes about deprecating interfaces and commands.
* lib/linklist.h: Add usage comments.
Rename getdata macro to listgetdata.
Rename nextnode to listnextnode and fix its odd behaviour to be
less dangerous.
Make listgetdata macro assert node is not null, NULL list entries
should be bug condition.
ALL_LIST_ELEMENTS, new macro, forward-referencing macro for use
with for loop, Suggested by Jim Carlson of Sun.
Add ALL_LIST_ELEMENTS_RO for cases which obviously do not need the
"safety" of previous macro.
LISTNODE_ADD and DELETE macros renamed to ATTACH, DETACH, to
distinguish from the similarly named functions, and reflect their
effect better.
Add a QUAGGA_NO_DEPRECATED_INTERFACES define guarded section
with the old defines which were modified above,
for backwards compatibility - guarded to prevent Quagga using it..
* lib/linklist.c: fix up for linklist.h changes.
* ospf6d/ospf6_abr.c: (ospf6_abr_examin_brouter) change to a single
scan of the area list, rather than scanning all areas first for
INTER_ROUTER and then again for INTER_NETWORK. According to
16.2, the scan should be area specific anyway, and further
ospf6d does not seem to implement 16.3 anyway.
2005-04-07 09:30:20 +02:00
|
|
|
struct listnode *node, *nnode;
|
2002-12-13 21:15:29 +01:00
|
|
|
struct zserv *client;
|
|
|
|
|
|
|
|
if (IS_ZEBRA_DEBUG_EVENT)
|
2021-10-22 00:17:40 +02:00
|
|
|
zlog_debug("MESSAGE: ZEBRA_INTERFACE_DOWN %s vrf %s(%u)",
|
|
|
|
ifp->name, ifp->vrf->name, ifp->vrf->vrf_id);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2019-01-11 19:38:19 +01:00
|
|
|
for (ALL_LIST_ELEMENTS(zrouter.client_list, node, nnode, client)) {
|
2020-03-06 16:33:40 +01:00
|
|
|
/* Do not send unsolicited messages to synchronous clients. */
|
|
|
|
if (client->synchronous)
|
|
|
|
continue;
|
|
|
|
|
2015-05-20 02:47:22 +02:00
|
|
|
zsend_interface_update(ZEBRA_INTERFACE_DOWN, client, ifp);
|
|
|
|
}
|
2023-10-31 16:09:48 +01:00
|
|
|
|
|
|
|
zebra_neigh_del_all(ifp);
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Interface information update. */
|
|
|
|
void zebra_interface_add_update(struct interface *ifp)
|
|
|
|
{
|
2005-04-07 Paul Jakma <paul.jakma@sun.com>
* (global): Fix up list loops to match changes in lib/linklist,
and some basic auditing of usage.
* configure.ac: define QUAGGA_NO_DEPRECATED_INTERFACES
* HACKING: Add notes about deprecating interfaces and commands.
* lib/linklist.h: Add usage comments.
Rename getdata macro to listgetdata.
Rename nextnode to listnextnode and fix its odd behaviour to be
less dangerous.
Make listgetdata macro assert node is not null, NULL list entries
should be bug condition.
ALL_LIST_ELEMENTS, new macro, forward-referencing macro for use
with for loop, Suggested by Jim Carlson of Sun.
Add ALL_LIST_ELEMENTS_RO for cases which obviously do not need the
"safety" of previous macro.
LISTNODE_ADD and DELETE macros renamed to ATTACH, DETACH, to
distinguish from the similarly named functions, and reflect their
effect better.
Add a QUAGGA_NO_DEPRECATED_INTERFACES define guarded section
with the old defines which were modified above,
for backwards compatibility - guarded to prevent Quagga using it..
* lib/linklist.c: fix up for linklist.h changes.
* ospf6d/ospf6_abr.c: (ospf6_abr_examin_brouter) change to a single
scan of the area list, rather than scanning all areas first for
INTER_ROUTER and then again for INTER_NETWORK. According to
16.2, the scan should be area specific anyway, and further
ospf6d does not seem to implement 16.3 anyway.
2005-04-07 09:30:20 +02:00
|
|
|
struct listnode *node, *nnode;
|
2002-12-13 21:15:29 +01:00
|
|
|
struct zserv *client;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
if (IS_ZEBRA_DEBUG_EVENT)
|
2021-10-22 00:17:40 +02:00
|
|
|
zlog_debug("MESSAGE: ZEBRA_INTERFACE_ADD %s vrf %s(%u)",
|
|
|
|
ifp->name, ifp->vrf->name, ifp->vrf->vrf_id);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2019-02-04 17:45:31 +01:00
|
|
|
for (ALL_LIST_ELEMENTS(zrouter.client_list, node, nnode, client)) {
|
2020-03-06 16:33:40 +01:00
|
|
|
/* Do not send unsolicited messages to synchronous clients. */
|
|
|
|
if (client->synchronous)
|
|
|
|
continue;
|
|
|
|
|
2019-02-04 17:45:31 +01:00
|
|
|
client->ifadd_cnt++;
|
|
|
|
zsend_interface_add(client, ifp);
|
|
|
|
zsend_interface_link_params(client, ifp);
|
|
|
|
}
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void zebra_interface_delete_update(struct interface *ifp)
|
|
|
|
{
|
2005-04-07 Paul Jakma <paul.jakma@sun.com>
* (global): Fix up list loops to match changes in lib/linklist,
and some basic auditing of usage.
* configure.ac: define QUAGGA_NO_DEPRECATED_INTERFACES
* HACKING: Add notes about deprecating interfaces and commands.
* lib/linklist.h: Add usage comments.
Rename getdata macro to listgetdata.
Rename nextnode to listnextnode and fix its odd behaviour to be
less dangerous.
Make listgetdata macro assert node is not null, NULL list entries
should be bug condition.
ALL_LIST_ELEMENTS, new macro, forward-referencing macro for use
with for loop, Suggested by Jim Carlson of Sun.
Add ALL_LIST_ELEMENTS_RO for cases which obviously do not need the
"safety" of previous macro.
LISTNODE_ADD and DELETE macros renamed to ATTACH, DETACH, to
distinguish from the similarly named functions, and reflect their
effect better.
Add a QUAGGA_NO_DEPRECATED_INTERFACES define guarded section
with the old defines which were modified above,
for backwards compatibility - guarded to prevent Quagga using it..
* lib/linklist.c: fix up for linklist.h changes.
* ospf6d/ospf6_abr.c: (ospf6_abr_examin_brouter) change to a single
scan of the area list, rather than scanning all areas first for
INTER_ROUTER and then again for INTER_NETWORK. According to
16.2, the scan should be area specific anyway, and further
ospf6d does not seem to implement 16.3 anyway.
2005-04-07 09:30:20 +02:00
|
|
|
struct listnode *node, *nnode;
|
2002-12-13 21:15:29 +01:00
|
|
|
struct zserv *client;
|
|
|
|
|
|
|
|
if (IS_ZEBRA_DEBUG_EVENT)
|
2021-10-22 00:17:40 +02:00
|
|
|
zlog_debug("MESSAGE: ZEBRA_INTERFACE_DELETE %s vrf %s(%u)",
|
|
|
|
ifp->name, ifp->vrf->name, ifp->vrf->vrf_id);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2019-01-11 19:38:19 +01:00
|
|
|
for (ALL_LIST_ELEMENTS(zrouter.client_list, node, nnode, client)) {
|
2020-03-06 16:33:40 +01:00
|
|
|
/* Do not send unsolicited messages to synchronous clients. */
|
|
|
|
if (client->synchronous)
|
|
|
|
continue;
|
|
|
|
|
2016-04-22 02:12:26 +02:00
|
|
|
client->ifdel_cnt++;
|
|
|
|
zsend_interface_delete(client, ifp);
|
|
|
|
}
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Interface address addition. */
|
|
|
|
void zebra_interface_address_add_update(struct interface *ifp,
|
|
|
|
struct connected *ifc)
|
|
|
|
{
|
2005-04-07 Paul Jakma <paul.jakma@sun.com>
* (global): Fix up list loops to match changes in lib/linklist,
and some basic auditing of usage.
* configure.ac: define QUAGGA_NO_DEPRECATED_INTERFACES
* HACKING: Add notes about deprecating interfaces and commands.
* lib/linklist.h: Add usage comments.
Rename getdata macro to listgetdata.
Rename nextnode to listnextnode and fix its odd behaviour to be
less dangerous.
Make listgetdata macro assert node is not null, NULL list entries
should be bug condition.
ALL_LIST_ELEMENTS, new macro, forward-referencing macro for use
with for loop, Suggested by Jim Carlson of Sun.
Add ALL_LIST_ELEMENTS_RO for cases which obviously do not need the
"safety" of previous macro.
LISTNODE_ADD and DELETE macros renamed to ATTACH, DETACH, to
distinguish from the similarly named functions, and reflect their
effect better.
Add a QUAGGA_NO_DEPRECATED_INTERFACES define guarded section
with the old defines which were modified above,
for backwards compatibility - guarded to prevent Quagga using it..
* lib/linklist.c: fix up for linklist.h changes.
* ospf6d/ospf6_abr.c: (ospf6_abr_examin_brouter) change to a single
scan of the area list, rather than scanning all areas first for
INTER_ROUTER and then again for INTER_NETWORK. According to
16.2, the scan should be area specific anyway, and further
ospf6d does not seem to implement 16.3 anyway.
2005-04-07 09:30:20 +02:00
|
|
|
struct listnode *node, *nnode;
|
2002-12-13 21:15:29 +01:00
|
|
|
struct zserv *client;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2022-01-14 18:59:50 +01:00
|
|
|
if (IS_ZEBRA_DEBUG_EVENT)
|
2020-10-18 13:33:54 +02:00
|
|
|
zlog_debug(
|
2021-10-22 00:17:40 +02:00
|
|
|
"MESSAGE: ZEBRA_INTERFACE_ADDRESS_ADD %pFX on %s vrf %s(%u)",
|
2022-01-14 18:59:50 +01:00
|
|
|
ifc->address, ifp->name, ifp->vrf->name,
|
|
|
|
ifp->vrf->vrf_id);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2013-01-24 15:04:47 +01:00
|
|
|
if (!CHECK_FLAG(ifc->conf, ZEBRA_IFC_REAL))
|
2018-08-16 22:10:32 +02:00
|
|
|
flog_warn(
|
2018-09-13 21:21:05 +02:00
|
|
|
EC_ZEBRA_ADVERTISING_UNUSABLE_ADDR,
|
2021-03-12 02:57:47 +01:00
|
|
|
"advertising address to clients that is not yet usable.");
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-06-28 10:51:10 +02:00
|
|
|
zebra_vxlan_add_del_gw_macip(ifp, ifc->address, 1);
|
|
|
|
|
2004-10-03 20:18:34 +02:00
|
|
|
router_id_add_address(ifc);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2020-03-06 16:33:40 +01:00
|
|
|
for (ALL_LIST_ELEMENTS(zrouter.client_list, node, nnode, client)) {
|
|
|
|
/* Do not send unsolicited messages to synchronous clients. */
|
|
|
|
if (client->synchronous)
|
|
|
|
continue;
|
|
|
|
|
2016-04-22 02:12:26 +02:00
|
|
|
if (CHECK_FLAG(ifc->conf, ZEBRA_IFC_REAL)) {
|
2015-05-20 02:47:22 +02:00
|
|
|
client->connected_rt_add_cnt++;
|
|
|
|
zsend_interface_address(ZEBRA_INTERFACE_ADDRESS_ADD,
|
|
|
|
client, ifp, ifc);
|
|
|
|
}
|
2020-03-06 16:33:40 +01:00
|
|
|
}
|
2023-04-19 20:35:25 +02:00
|
|
|
/* interface associated NHGs may have been deleted,
|
|
|
|
* re-sync zebra -> dplane NHGs
|
|
|
|
*/
|
|
|
|
zebra_interface_nhg_reinstall(ifp);
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Interface address deletion. */
|
|
|
|
void zebra_interface_address_delete_update(struct interface *ifp,
|
|
|
|
struct connected *ifc)
|
|
|
|
{
|
2005-04-07 Paul Jakma <paul.jakma@sun.com>
* (global): Fix up list loops to match changes in lib/linklist,
and some basic auditing of usage.
* configure.ac: define QUAGGA_NO_DEPRECATED_INTERFACES
* HACKING: Add notes about deprecating interfaces and commands.
* lib/linklist.h: Add usage comments.
Rename getdata macro to listgetdata.
Rename nextnode to listnextnode and fix its odd behaviour to be
less dangerous.
Make listgetdata macro assert node is not null, NULL list entries
should be bug condition.
ALL_LIST_ELEMENTS, new macro, forward-referencing macro for use
with for loop, Suggested by Jim Carlson of Sun.
Add ALL_LIST_ELEMENTS_RO for cases which obviously do not need the
"safety" of previous macro.
LISTNODE_ADD and DELETE macros renamed to ATTACH, DETACH, to
distinguish from the similarly named functions, and reflect their
effect better.
Add a QUAGGA_NO_DEPRECATED_INTERFACES define guarded section
with the old defines which were modified above,
for backwards compatibility - guarded to prevent Quagga using it..
* lib/linklist.c: fix up for linklist.h changes.
* ospf6d/ospf6_abr.c: (ospf6_abr_examin_brouter) change to a single
scan of the area list, rather than scanning all areas first for
INTER_ROUTER and then again for INTER_NETWORK. According to
16.2, the scan should be area specific anyway, and further
ospf6d does not seem to implement 16.3 anyway.
2005-04-07 09:30:20 +02:00
|
|
|
struct listnode *node, *nnode;
|
2002-12-13 21:15:29 +01:00
|
|
|
struct zserv *client;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2022-01-14 18:59:50 +01:00
|
|
|
if (IS_ZEBRA_DEBUG_EVENT)
|
2020-10-18 13:33:54 +02:00
|
|
|
zlog_debug(
|
2021-10-22 00:17:40 +02:00
|
|
|
"MESSAGE: ZEBRA_INTERFACE_ADDRESS_DELETE %pFX on %s vrf %s(%u)",
|
2022-01-14 18:59:50 +01:00
|
|
|
ifc->address, ifp->name, ifp->vrf->name,
|
|
|
|
ifp->vrf->vrf_id);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-06-28 10:51:10 +02:00
|
|
|
zebra_vxlan_add_del_gw_macip(ifp, ifc->address, 0);
|
|
|
|
|
2004-10-03 20:18:34 +02:00
|
|
|
router_id_del_address(ifc);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2020-03-06 16:33:40 +01:00
|
|
|
for (ALL_LIST_ELEMENTS(zrouter.client_list, node, nnode, client)) {
|
|
|
|
/* Do not send unsolicited messages to synchronous clients. */
|
|
|
|
if (client->synchronous)
|
|
|
|
continue;
|
|
|
|
|
2016-04-22 02:12:26 +02:00
|
|
|
if (CHECK_FLAG(ifc->conf, ZEBRA_IFC_REAL)) {
|
2015-05-20 02:47:22 +02:00
|
|
|
client->connected_rt_del_cnt++;
|
|
|
|
zsend_interface_address(ZEBRA_INTERFACE_ADDRESS_DELETE,
|
|
|
|
client, ifp, ifc);
|
|
|
|
}
|
2020-03-06 16:33:40 +01:00
|
|
|
}
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
2015-05-20 02:47:23 +02:00
|
|
|
|
2016-02-25 20:30:53 +01:00
|
|
|
/* Interface VRF change. May need to delete from clients not interested in
|
|
|
|
* the new VRF. Note that this function is invoked *prior* to the VRF change.
|
|
|
|
*/
|
|
|
|
void zebra_interface_vrf_update_del(struct interface *ifp, vrf_id_t new_vrf_id)
|
|
|
|
{
|
|
|
|
struct listnode *node, *nnode;
|
|
|
|
struct zserv *client;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2016-02-25 20:30:53 +01:00
|
|
|
if (IS_ZEBRA_DEBUG_EVENT)
|
2022-03-04 14:52:27 +01:00
|
|
|
zlog_debug("MESSAGE: ZEBRA_INTERFACE_DELETE %s VRF Id %u -> %u",
|
|
|
|
ifp->name, ifp->vrf->vrf_id, new_vrf_id);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2019-01-11 19:38:19 +01:00
|
|
|
for (ALL_LIST_ELEMENTS(zrouter.client_list, node, nnode, client)) {
|
2020-03-06 16:33:40 +01:00
|
|
|
/* Do not send unsolicited messages to synchronous clients. */
|
|
|
|
if (client->synchronous)
|
|
|
|
continue;
|
|
|
|
|
2016-04-22 02:12:26 +02:00
|
|
|
/* Need to delete if the client is not interested in the new
|
|
|
|
* VRF. */
|
|
|
|
zsend_interface_update(ZEBRA_INTERFACE_DOWN, client, ifp);
|
|
|
|
client->ifdel_cnt++;
|
|
|
|
zsend_interface_delete(client, ifp);
|
2016-02-25 20:30:53 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Interface VRF change. This function is invoked *post* VRF change and sends an
|
|
|
|
* add to clients who are interested in the new VRF but not in the old VRF.
|
|
|
|
*/
|
|
|
|
void zebra_interface_vrf_update_add(struct interface *ifp, vrf_id_t old_vrf_id)
|
|
|
|
{
|
|
|
|
struct listnode *node, *nnode;
|
|
|
|
struct zserv *client;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2016-02-25 20:30:53 +01:00
|
|
|
if (IS_ZEBRA_DEBUG_EVENT)
|
2022-03-04 14:52:27 +01:00
|
|
|
zlog_debug("MESSAGE: ZEBRA_INTERFACE_ADD %s VRF Id %u -> %u",
|
|
|
|
ifp->name, old_vrf_id, ifp->vrf->vrf_id);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2019-01-11 19:38:19 +01:00
|
|
|
for (ALL_LIST_ELEMENTS(zrouter.client_list, node, nnode, client)) {
|
2020-03-06 16:33:40 +01:00
|
|
|
/* Do not send unsolicited messages to synchronous clients. */
|
|
|
|
if (client->synchronous)
|
|
|
|
continue;
|
|
|
|
|
2016-02-25 20:30:53 +01:00
|
|
|
/* Need to add if the client is interested in the new VRF. */
|
|
|
|
client->ifadd_cnt++;
|
|
|
|
zsend_interface_add(client, ifp);
|
|
|
|
zsend_interface_addresses(client, ifp);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-25 23:07:30 +02:00
|
|
|
int zebra_add_import_table_entry(struct zebra_vrf *zvrf, struct route_node *rn,
|
|
|
|
struct route_entry *re, const char *rmap_name)
|
2015-05-20 03:03:42 +02:00
|
|
|
{
|
2017-06-01 13:26:25 +02:00
|
|
|
struct route_entry *newre;
|
|
|
|
struct route_entry *same;
|
2016-08-24 08:20:47 +02:00
|
|
|
struct prefix p;
|
2019-11-22 21:30:53 +01:00
|
|
|
struct nexthop_group *ng;
|
lib: Introducing a 3rd state for route-map match cmd: RMAP_NOOP
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
State1:
If match cmd returns RMAP_MATCH then, keep existing behaviour.
If routemap type is PERMIT, execute set cmds or call cmds if applicable,
otherwise PERMIT!
Else If routemap type is DENY, we DENYMATCH right away
State2:
If match cmd returns RMAP_NOMATCH, continue on to next route-map. If there
are no other rules or if all the rules return RMAP_NOMATCH, return DENYMATCH
We require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Also, this rule should be applicable for routes with VNI label only, and
not for routes without labels. For example, type 3 and type 4 EVPN routes
do not have labels, so, this match cmd should let them through.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
As a result we have a 3rd state:
State3:
If match cmd returned RMAP_NOOP
Then, proceed to other route-map, otherwise if there are no more
rules or if all the rules return RMAP_NOOP, then, return RMAP_PERMITMATCH.
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
2019-06-19 23:04:36 +02:00
|
|
|
route_map_result_t ret = RMAP_PERMITMATCH;
|
2017-08-31 22:07:36 +02:00
|
|
|
afi_t afi;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-08-31 22:07:36 +02:00
|
|
|
afi = family2afi(rn->p.family);
|
2016-05-11 17:47:02 +02:00
|
|
|
if (rmap_name)
|
2023-08-11 17:15:06 +02:00
|
|
|
ret = zebra_import_table_route_map_check(afi, re, &rn->p,
|
zebra: import table match against interface name could fail
If an import table route-map is trying to match against
a particular interface, The code is matching against
the actual vrf the route entry is in -vs- the vrf
the nexthop entry is in. Let's modify the code
to actually allow the import table entry to match
against the nexthops vrf.
Not working:
ip import-table 91
ip import-table 93 route-map FOO
no service integrated-vtysh-config
!
debug zebra events
!
interface green
ip address 192.168.4.3/24
exit
!
route-map FOO permit 10
match interface green
exit
eva# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, 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
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp13s0, 1d10h07m
T[91]>* 1.2.3.5/32 [15/0] via 192.168.119.1, enp13s0, 00:00:05
K>* 169.254.0.0/16 [0/1000] is directly connected, virbr0 linkdown, 1d16h34m
C>* 192.168.44.0/24 is directly connected, virbr1, 01:30:51
C>* 192.168.45.0/24 is directly connected, virbr2, 01:30:51
C>* 192.168.119.0/24 is directly connected, enp13s0, 1d16h34m
C>* 192.168.122.0/24 is directly connected, virbr0 linkdown, 01:30:51
eva# show ip route table 91
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, 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
VRF default table 91:
K>* 1.2.3.5/32 [0/0] via 192.168.119.1, enp13s0, 00:00:15
eva# show ip route table 93
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, 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
VRF default table 93:
K * 1.2.3.4/32 [0/0] via 192.168.4.5, green (vrf green), 00:03:05
Working:
eva# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, 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
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp13s0, 00:03:09
T[93]>* 1.2.3.4/32 [15/0] via 192.168.4.5, green (vrf green), 00:02:21
T[91]>* 1.2.3.5/32 [15/0] via 192.168.119.1, enp13s0, 00:02:26
K>* 169.254.0.0/16 [0/1000] is directly connected, virbr0, 00:03:09
C>* 192.168.44.0/24 is directly connected, virbr1, 00:03:09
C>* 192.168.45.0/24 is directly connected, virbr2, 00:03:09
C>* 192.168.119.0/24 is directly connected, enp13s0, 00:03:09
C>* 192.168.122.0/24 is directly connected, virbr0, 00:03:09
eva# show ip route table 91
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, 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
VRF default table 91:
K * 1.2.3.5/32 [0/0] via 192.168.119.1, enp13s0, 00:03:12
eva# show ip route table 93
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, 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
VRF default table 93:
K * 1.2.3.4/32 [0/0] via 192.168.4.5, green (vrf green), 00:03:14
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-11 16:18:41 +02:00
|
|
|
re->nhe->nhg.nexthop,
|
2023-08-11 17:21:03 +02:00
|
|
|
rmap_name);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
lib: Introducing a 3rd state for route-map match cmd: RMAP_NOOP
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
State1:
If match cmd returns RMAP_MATCH then, keep existing behaviour.
If routemap type is PERMIT, execute set cmds or call cmds if applicable,
otherwise PERMIT!
Else If routemap type is DENY, we DENYMATCH right away
State2:
If match cmd returns RMAP_NOMATCH, continue on to next route-map. If there
are no other rules or if all the rules return RMAP_NOMATCH, return DENYMATCH
We require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Also, this rule should be applicable for routes with VNI label only, and
not for routes without labels. For example, type 3 and type 4 EVPN routes
do not have labels, so, this match cmd should let them through.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
As a result we have a 3rd state:
State3:
If match cmd returned RMAP_NOOP
Then, proceed to other route-map, otherwise if there are no more
rules or if all the rules return RMAP_NOOP, then, return RMAP_PERMITMATCH.
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
2019-06-19 23:04:36 +02:00
|
|
|
if (ret != RMAP_PERMITMATCH) {
|
2018-04-17 19:48:30 +02:00
|
|
|
UNSET_FLAG(re->flags, ZEBRA_FLAG_SELECTED);
|
2019-06-25 23:07:30 +02:00
|
|
|
zebra_del_import_table_entry(zvrf, rn, re);
|
2017-08-31 21:25:54 +02:00
|
|
|
return 0;
|
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-08-31 22:07:36 +02:00
|
|
|
prefix_copy(&p, &rn->p);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-09-15 17:47:35 +02:00
|
|
|
RNODE_FOREACH_RE (rn, same) {
|
|
|
|
if (CHECK_FLAG(same->status, ROUTE_ENTRY_REMOVED))
|
2017-08-31 22:07:36 +02:00
|
|
|
continue;
|
2017-08-31 21:25:54 +02:00
|
|
|
|
*: Introduce Local Host Routes to FRR
Create Local routes in FRR:
S 0.0.0.0/0 [1/0] via 192.168.119.1, enp39s0, weight 1, 00:03:46
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:03:51
O 192.168.119.0/24 [110/100] is directly connected, enp39s0, weight 1, 00:03:46
C>* 192.168.119.0/24 is directly connected, enp39s0, 00:03:51
L>* 192.168.119.224/32 is directly connected, enp39s0, 00:03:51
O 192.168.119.229/32 [110/100] via 0.0.0.0, enp39s0 inactive, weight 1, 00:03:46
C>* 192.168.119.229/32 is directly connected, enp39s0, 00:03:46
Create ability to redistribute local routes.
Modify tests to support this change.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-01-05 00:32:43 +01:00
|
|
|
if (same->type == re->type && same->instance == re->instance &&
|
|
|
|
same->table == re->table &&
|
|
|
|
(same->type != ZEBRA_ROUTE_CONNECT &&
|
|
|
|
same->type != ZEBRA_ROUTE_LOCAL))
|
2017-08-31 22:07:36 +02:00
|
|
|
break;
|
|
|
|
}
|
2017-08-31 21:25:54 +02:00
|
|
|
|
2018-04-15 21:25:24 +02:00
|
|
|
if (same) {
|
|
|
|
UNSET_FLAG(same->flags, ZEBRA_FLAG_SELECTED);
|
2019-06-25 23:07:30 +02:00
|
|
|
zebra_del_import_table_entry(zvrf, rn, same);
|
2018-04-15 21:25:24 +02:00
|
|
|
}
|
2017-08-31 22:07:36 +02:00
|
|
|
|
2023-07-06 22:40:50 +02:00
|
|
|
UNSET_FLAG(re->flags, ZEBRA_FLAG_RR_USE_DISTANCE);
|
|
|
|
|
2022-08-10 01:56:08 +02:00
|
|
|
newre = zebra_rib_route_entry_new(
|
|
|
|
0, ZEBRA_ROUTE_TABLE, re->table, re->flags, re->nhe_id,
|
|
|
|
zvrf->table_id, re->metric, re->mtu,
|
|
|
|
zebra_import_table_distance[afi][re->table], re->tag);
|
2017-10-04 15:41:49 +02:00
|
|
|
|
2019-11-22 21:30:53 +01:00
|
|
|
ng = nexthop_group_new();
|
2020-02-25 14:29:46 +01:00
|
|
|
copy_nexthops(&ng->nexthop, re->nhe->nhg.nexthop, NULL);
|
2019-11-22 21:30:53 +01:00
|
|
|
|
2021-06-24 18:23:33 +02:00
|
|
|
rib_add_multipath(afi, SAFI_UNICAST, &p, NULL, newre, ng, false);
|
2023-10-10 11:13:09 +02:00
|
|
|
nexthop_group_delete(&ng);
|
2017-10-04 15:41:49 +02:00
|
|
|
|
2015-05-20 03:03:42 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-06-25 23:07:30 +02:00
|
|
|
int zebra_del_import_table_entry(struct zebra_vrf *zvrf, struct route_node *rn,
|
|
|
|
struct route_entry *re)
|
2015-05-20 03:03:42 +02:00
|
|
|
{
|
2016-08-24 07:39:08 +02:00
|
|
|
struct prefix p;
|
2017-08-31 22:07:36 +02:00
|
|
|
afi_t afi;
|
2015-05-20 03:03:42 +02:00
|
|
|
|
2017-08-31 22:07:36 +02:00
|
|
|
afi = family2afi(rn->p.family);
|
|
|
|
prefix_copy(&p, &rn->p);
|
2015-05-20 03:03:42 +02:00
|
|
|
|
2019-06-25 23:07:30 +02:00
|
|
|
rib_delete(afi, SAFI_UNICAST, zvrf->vrf->vrf_id, ZEBRA_ROUTE_TABLE,
|
2020-02-25 14:29:46 +01:00
|
|
|
re->table, re->flags, &p, NULL, re->nhe->nhg.nexthop,
|
2019-11-22 21:30:53 +01:00
|
|
|
re->nhe_id, zvrf->table_id, re->metric, re->distance,
|
2020-12-10 16:24:47 +01:00
|
|
|
false);
|
2015-05-20 03:03:42 +02:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Assuming no one calls this with the main routing table */
|
2019-06-25 23:07:30 +02:00
|
|
|
int zebra_import_table(afi_t afi, vrf_id_t vrf_id, uint32_t table_id,
|
|
|
|
uint32_t distance, const char *rmap_name, int add)
|
2015-05-20 03:03:42 +02:00
|
|
|
{
|
|
|
|
struct route_table *table;
|
2017-06-01 13:26:25 +02:00
|
|
|
struct route_entry *re;
|
2015-05-20 03:03:42 +02:00
|
|
|
struct route_node *rn;
|
2019-06-25 23:07:30 +02:00
|
|
|
struct zebra_vrf *zvrf = zebra_vrf_lookup_by_id(vrf_id);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2015-05-20 03:03:42 +02:00
|
|
|
if (!is_zebra_valid_kernel_table(table_id)
|
2023-08-22 13:27:59 +02:00
|
|
|
|| (table_id == rt_table_main_id))
|
2020-02-09 13:21:56 +01:00
|
|
|
return -1;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2016-05-11 17:47:02 +02:00
|
|
|
if (afi >= AFI_MAX)
|
2020-02-09 13:21:56 +01:00
|
|
|
return -1;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2019-11-01 20:52:47 +01:00
|
|
|
table = zebra_vrf_get_table_with_table_id(afi, SAFI_UNICAST, vrf_id,
|
|
|
|
table_id);
|
2016-05-11 17:47:02 +02:00
|
|
|
if (table == NULL) {
|
|
|
|
return 0;
|
|
|
|
} else if (IS_ZEBRA_DEBUG_RIB) {
|
2015-05-20 03:03:42 +02:00
|
|
|
zlog_debug("%s routes from table %d",
|
|
|
|
add ? "Importing" : "Unimporting", table_id);
|
|
|
|
}
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
if (add) {
|
2017-06-01 13:26:25 +02:00
|
|
|
if (rmap_name)
|
2016-05-11 17:47:02 +02:00
|
|
|
zebra_add_import_table_route_map(afi, rmap_name,
|
2015-05-20 03:03:42 +02:00
|
|
|
table_id);
|
2017-07-17 14:03:14 +02:00
|
|
|
else {
|
2016-05-11 17:47:02 +02:00
|
|
|
rmap_name =
|
2015-05-20 03:03:42 +02:00
|
|
|
zebra_get_import_table_route_map(afi, table_id);
|
2018-04-19 23:04:05 +02:00
|
|
|
if (rmap_name) {
|
2016-05-11 17:47:02 +02:00
|
|
|
zebra_del_import_table_route_map(afi, table_id);
|
2018-04-19 23:04:05 +02:00
|
|
|
rmap_name = NULL;
|
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
}
|
2015-05-20 03:03:42 +02:00
|
|
|
|
2015-05-20 03:04:26 +02:00
|
|
|
zebra_import_table_used[afi][table_id] = 1;
|
|
|
|
zebra_import_table_distance[afi][table_id] = distance;
|
2017-07-17 14:03:14 +02:00
|
|
|
} else {
|
2015-05-20 03:04:26 +02:00
|
|
|
zebra_import_table_used[afi][table_id] = 0;
|
|
|
|
zebra_import_table_distance[afi][table_id] =
|
|
|
|
ZEBRA_TABLE_DISTANCE_DEFAULT;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-06-01 13:26:25 +02:00
|
|
|
rmap_name = zebra_get_import_table_route_map(afi, table_id);
|
2018-04-19 23:04:05 +02:00
|
|
|
if (rmap_name) {
|
2017-06-01 13:26:25 +02:00
|
|
|
zebra_del_import_table_route_map(afi, table_id);
|
2018-04-19 23:04:05 +02:00
|
|
|
rmap_name = NULL;
|
|
|
|
}
|
2015-05-20 03:03:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
for (rn = route_top(table); rn; rn = route_next(rn)) {
|
|
|
|
/* For each entry in the non-default routing table,
|
|
|
|
* add the entry in the main table
|
2017-07-17 14:03:14 +02:00
|
|
|
*/
|
2015-05-20 03:03:42 +02:00
|
|
|
if (!rn->info)
|
2016-05-11 17:47:02 +02:00
|
|
|
continue;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-09-15 17:47:35 +02:00
|
|
|
RNODE_FOREACH_RE (rn, re) {
|
2016-05-11 17:47:02 +02:00
|
|
|
if (CHECK_FLAG(re->status, ROUTE_ENTRY_REMOVED))
|
|
|
|
continue;
|
2017-07-17 14:03:14 +02:00
|
|
|
break;
|
2015-05-20 03:03:42 +02:00
|
|
|
}
|
2016-05-11 17:47:02 +02:00
|
|
|
|
|
|
|
if (!re)
|
|
|
|
continue;
|
|
|
|
|
2017-07-13 19:04:25 +02:00
|
|
|
if (((afi == AFI_IP) && (rn->p.family == AF_INET))
|
2016-05-11 17:47:02 +02:00
|
|
|
|| ((afi == AFI_IP6) && (rn->p.family == AF_INET6))) {
|
2017-07-17 14:03:14 +02:00
|
|
|
if (add)
|
2019-06-25 23:07:30 +02:00
|
|
|
zebra_add_import_table_entry(zvrf, rn, re,
|
|
|
|
rmap_name);
|
2017-07-17 14:03:14 +02:00
|
|
|
else
|
2019-06-25 23:07:30 +02:00
|
|
|
zebra_del_import_table_entry(zvrf, rn, re);
|
2017-07-17 14:03:14 +02:00
|
|
|
}
|
|
|
|
}
|
2015-05-20 03:03:42 +02:00
|
|
|
return 0;
|
2017-07-17 14:03:14 +02:00
|
|
|
}
|
|
|
|
|
2019-06-25 23:07:30 +02:00
|
|
|
int zebra_import_table_config(struct vty *vty, vrf_id_t vrf_id)
|
2017-07-17 14:03:14 +02:00
|
|
|
{
|
|
|
|
int i;
|
2015-05-20 03:03:42 +02:00
|
|
|
afi_t afi;
|
|
|
|
int write = 0;
|
2016-09-27 17:57:56 +02:00
|
|
|
char afi_str[AFI_MAX][10] = {"", "ip", "ipv6", "ethernet"};
|
2016-05-11 17:47:02 +02:00
|
|
|
const char *rmap_name;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2015-05-20 03:03:42 +02:00
|
|
|
for (afi = AFI_IP; afi < AFI_MAX; afi++) {
|
2016-05-11 17:47:02 +02:00
|
|
|
for (i = 1; i < ZEBRA_KERNEL_TABLE_MAX; i++) {
|
2019-06-25 23:07:30 +02:00
|
|
|
if (!is_zebra_import_table_enabled(afi, vrf_id, i))
|
2017-08-31 21:25:54 +02:00
|
|
|
continue;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-08-31 21:25:54 +02:00
|
|
|
if (zebra_import_table_distance[afi][i]
|
|
|
|
!= ZEBRA_TABLE_DISTANCE_DEFAULT) {
|
|
|
|
vty_out(vty, "%s import-table %d distance %d",
|
|
|
|
afi_str[afi], i,
|
|
|
|
zebra_import_table_distance[afi][i]);
|
|
|
|
} else {
|
|
|
|
vty_out(vty, "%s import-table %d", afi_str[afi],
|
|
|
|
i);
|
2015-05-20 03:03:42 +02:00
|
|
|
}
|
2017-08-31 21:25:54 +02:00
|
|
|
|
|
|
|
rmap_name = zebra_get_import_table_route_map(afi, i);
|
|
|
|
if (rmap_name)
|
|
|
|
vty_out(vty, " route-map %s", rmap_name);
|
|
|
|
|
|
|
|
vty_out(vty, "\n");
|
|
|
|
write = 1;
|
2017-07-17 14:03:14 +02:00
|
|
|
}
|
2015-05-20 03:03:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return write;
|
|
|
|
}
|
2016-05-11 17:47:02 +02:00
|
|
|
|
2019-06-25 23:07:30 +02:00
|
|
|
static void zebra_import_table_rm_update_vrf_afi(struct zebra_vrf *zvrf,
|
|
|
|
afi_t afi, int table_id,
|
|
|
|
const char *rmap)
|
2016-05-11 17:47:02 +02:00
|
|
|
{
|
|
|
|
struct route_table *table;
|
2017-06-01 13:26:25 +02:00
|
|
|
struct route_entry *re;
|
2016-05-11 17:47:02 +02:00
|
|
|
struct route_node *rn;
|
|
|
|
const char *rmap_name;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2019-06-25 23:07:30 +02:00
|
|
|
rmap_name = zebra_get_import_table_route_map(afi, table_id);
|
|
|
|
if ((!rmap_name) || (strcmp(rmap_name, rmap) != 0))
|
|
|
|
return;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2019-11-01 20:52:47 +01:00
|
|
|
table = zebra_vrf_get_table_with_table_id(afi, SAFI_UNICAST,
|
|
|
|
zvrf->vrf->vrf_id, table_id);
|
2019-06-25 23:07:30 +02:00
|
|
|
if (!table) {
|
|
|
|
if (IS_ZEBRA_DEBUG_RIB_DETAILED)
|
|
|
|
zlog_debug("%s: Table id=%d not found", __func__,
|
|
|
|
table_id);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (rn = route_top(table); rn; rn = route_next(rn)) {
|
|
|
|
/*
|
|
|
|
* For each entry in the non-default routing table,
|
|
|
|
* add the entry in the main table
|
|
|
|
*/
|
|
|
|
if (!rn->info)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
RNODE_FOREACH_RE (rn, re) {
|
|
|
|
if (CHECK_FLAG(re->status, ROUTE_ENTRY_REMOVED))
|
2018-08-17 17:47:48 +02:00
|
|
|
continue;
|
2019-06-25 23:07:30 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!re)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (((afi == AFI_IP) && (rn->p.family == AF_INET))
|
|
|
|
|| ((afi == AFI_IP6) && (rn->p.family == AF_INET6)))
|
|
|
|
zebra_add_import_table_entry(zvrf, rn, re, rmap_name);
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void zebra_import_table_rm_update_vrf(struct zebra_vrf *zvrf,
|
|
|
|
const char *rmap)
|
|
|
|
{
|
|
|
|
afi_t afi;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (afi = AFI_IP; afi < AFI_MAX; afi++) {
|
|
|
|
for (i = 1; i < ZEBRA_KERNEL_TABLE_MAX; i++) {
|
|
|
|
if (!is_zebra_import_table_enabled(
|
|
|
|
afi, zvrf->vrf->vrf_id, i))
|
2019-05-16 23:34:05 +02:00
|
|
|
continue;
|
|
|
|
|
2019-06-25 23:07:30 +02:00
|
|
|
zebra_import_table_rm_update_vrf_afi(zvrf, afi, i,
|
|
|
|
rmap);
|
2016-05-11 17:47:02 +02:00
|
|
|
}
|
|
|
|
}
|
2019-06-25 23:07:30 +02:00
|
|
|
}
|
2016-05-11 17:47:02 +02:00
|
|
|
|
2019-06-25 23:07:30 +02:00
|
|
|
void zebra_import_table_rm_update(const char *rmap)
|
|
|
|
{
|
|
|
|
struct vrf *vrf;
|
|
|
|
struct zebra_vrf *zvrf;
|
|
|
|
|
|
|
|
RB_FOREACH (vrf, vrf_name_head, &vrfs_by_name) {
|
|
|
|
zvrf = vrf->info;
|
|
|
|
|
|
|
|
if (!zvrf)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
zebra_import_table_rm_update_vrf(zvrf, rmap);
|
|
|
|
}
|
2016-05-11 17:47:02 +02:00
|
|
|
}
|
Update Traffic Engineering Support for OSPFD
NOTE: I am squashing several commits together because they
do not independently compile and we need this ability to
do any type of sane testing on the patches. Since this
series builds together I am doing this. -DBS
This new structure is the basis to get new link parameters for
Traffic Engineering from Zebra/interface layer to OSPFD and ISISD
for the support of Traffic Engineering
* lib/if.[c,h]: link parameters struture and get/set functions
* lib/command.[c,h]: creation of a new link-node
* lib/zclient.[c,h]: modification to the ZBUS message to convey the
link parameters structure
* lib/zebra.h: New ZBUS message
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add support for IEEE 754 format
* lib/stream.[c,h]: Add stream_get{f,d} and stream_put{f,d}) demux and muxers to
safely convert between big-endian IEEE-754 single and double binary
format, as used in IETF RFCs, and C99. Implementation depends on host
using __STDC_IEC_559__, which should be everything we care about. Should
correctly error out otherwise.
* lib/network.[c,h]: Add ntohf and htonf converter
* lib/memtypes.c: Add new memeory type for Traffic Engineering support
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add link parameters support to Zebra
* zebra/interface.c:
- Add new link-params CLI commands
- Add new functions to set/get link parameters for interface
* zebra/redistribute.[c,h]: Add new function to propagate link parameters
to routing daemon (essentially OSPFD and ISISD) for Traffic Engineering.
* zebra/redistribute_null.c: Add new function
zebra_interface_parameters_update()
* zebra/zserv.[c,h]: Add new functions to send link parameters
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add support of new link-params CLI to vtysh
In vtysh_config.c/vtysh_config_parse_line(), it is not possible to continue
to use the ordered version for adding line i.e. config_add_line_uniq() to print
Interface CLI commands as it completely break the new LINK_PARAMS_NODE.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Update Traffic Engineering support for OSPFD
These patches update original code to RFC3630 (OSPF-TE) and add support of
RFC5392 (Inter-AS v2) & RFC7471 (TE metric extensions) and partial support
of RFC6827 (ASON - GMPLS).
* ospfd/ospf_dump.[c,h]: Add new dump functions for Traffic Engineering
* ospfd/ospf_opaque.[c,h]: Add new TLV code points for RFC5392
* ospfd/ospf_packet.c: Update checking of OSPF_OPTION
* ospfd/ospf_vty.[c,h]: Update ospf_str2area_id
* ospfd/ospf_zebra.c: Add new function ospf_interface_link_params() to get
Link Parameters information from the interface to populate Traffic Engineering
metrics
* ospfd/ospfd.[c,h]: Update OSPF_OPTION flags (T -> MT and new DN)
* ospfd/ospf_te.[c,h]: Major modifications to update the code to new
link parameters structure and new RFCs
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
tmp
2016-04-19 16:21:46 +02:00
|
|
|
|
|
|
|
/* Interface parameters update */
|
|
|
|
void zebra_interface_parameters_update(struct interface *ifp)
|
|
|
|
{
|
|
|
|
struct listnode *node, *nnode;
|
|
|
|
struct zserv *client;
|
|
|
|
|
|
|
|
if (IS_ZEBRA_DEBUG_EVENT)
|
2021-10-22 00:17:40 +02:00
|
|
|
zlog_debug("MESSAGE: ZEBRA_INTERFACE_LINK_PARAMS %s vrf %s(%u)",
|
|
|
|
ifp->name, ifp->vrf->name, ifp->vrf->vrf_id);
|
Update Traffic Engineering Support for OSPFD
NOTE: I am squashing several commits together because they
do not independently compile and we need this ability to
do any type of sane testing on the patches. Since this
series builds together I am doing this. -DBS
This new structure is the basis to get new link parameters for
Traffic Engineering from Zebra/interface layer to OSPFD and ISISD
for the support of Traffic Engineering
* lib/if.[c,h]: link parameters struture and get/set functions
* lib/command.[c,h]: creation of a new link-node
* lib/zclient.[c,h]: modification to the ZBUS message to convey the
link parameters structure
* lib/zebra.h: New ZBUS message
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add support for IEEE 754 format
* lib/stream.[c,h]: Add stream_get{f,d} and stream_put{f,d}) demux and muxers to
safely convert between big-endian IEEE-754 single and double binary
format, as used in IETF RFCs, and C99. Implementation depends on host
using __STDC_IEC_559__, which should be everything we care about. Should
correctly error out otherwise.
* lib/network.[c,h]: Add ntohf and htonf converter
* lib/memtypes.c: Add new memeory type for Traffic Engineering support
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add link parameters support to Zebra
* zebra/interface.c:
- Add new link-params CLI commands
- Add new functions to set/get link parameters for interface
* zebra/redistribute.[c,h]: Add new function to propagate link parameters
to routing daemon (essentially OSPFD and ISISD) for Traffic Engineering.
* zebra/redistribute_null.c: Add new function
zebra_interface_parameters_update()
* zebra/zserv.[c,h]: Add new functions to send link parameters
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add support of new link-params CLI to vtysh
In vtysh_config.c/vtysh_config_parse_line(), it is not possible to continue
to use the ordered version for adding line i.e. config_add_line_uniq() to print
Interface CLI commands as it completely break the new LINK_PARAMS_NODE.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Update Traffic Engineering support for OSPFD
These patches update original code to RFC3630 (OSPF-TE) and add support of
RFC5392 (Inter-AS v2) & RFC7471 (TE metric extensions) and partial support
of RFC6827 (ASON - GMPLS).
* ospfd/ospf_dump.[c,h]: Add new dump functions for Traffic Engineering
* ospfd/ospf_opaque.[c,h]: Add new TLV code points for RFC5392
* ospfd/ospf_packet.c: Update checking of OSPF_OPTION
* ospfd/ospf_vty.[c,h]: Update ospf_str2area_id
* ospfd/ospf_zebra.c: Add new function ospf_interface_link_params() to get
Link Parameters information from the interface to populate Traffic Engineering
metrics
* ospfd/ospfd.[c,h]: Update OSPF_OPTION flags (T -> MT and new DN)
* ospfd/ospf_te.[c,h]: Major modifications to update the code to new
link parameters structure and new RFCs
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
tmp
2016-04-19 16:21:46 +02:00
|
|
|
|
2020-03-06 16:33:40 +01:00
|
|
|
for (ALL_LIST_ELEMENTS(zrouter.client_list, node, nnode, client)) {
|
|
|
|
/* Do not send unsolicited messages to synchronous clients. */
|
|
|
|
if (client->synchronous)
|
|
|
|
continue;
|
|
|
|
|
2019-02-04 17:45:31 +01:00
|
|
|
zsend_interface_link_params(client, ifp);
|
2020-03-06 16:33:40 +01:00
|
|
|
}
|
Update Traffic Engineering Support for OSPFD
NOTE: I am squashing several commits together because they
do not independently compile and we need this ability to
do any type of sane testing on the patches. Since this
series builds together I am doing this. -DBS
This new structure is the basis to get new link parameters for
Traffic Engineering from Zebra/interface layer to OSPFD and ISISD
for the support of Traffic Engineering
* lib/if.[c,h]: link parameters struture and get/set functions
* lib/command.[c,h]: creation of a new link-node
* lib/zclient.[c,h]: modification to the ZBUS message to convey the
link parameters structure
* lib/zebra.h: New ZBUS message
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add support for IEEE 754 format
* lib/stream.[c,h]: Add stream_get{f,d} and stream_put{f,d}) demux and muxers to
safely convert between big-endian IEEE-754 single and double binary
format, as used in IETF RFCs, and C99. Implementation depends on host
using __STDC_IEC_559__, which should be everything we care about. Should
correctly error out otherwise.
* lib/network.[c,h]: Add ntohf and htonf converter
* lib/memtypes.c: Add new memeory type for Traffic Engineering support
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add link parameters support to Zebra
* zebra/interface.c:
- Add new link-params CLI commands
- Add new functions to set/get link parameters for interface
* zebra/redistribute.[c,h]: Add new function to propagate link parameters
to routing daemon (essentially OSPFD and ISISD) for Traffic Engineering.
* zebra/redistribute_null.c: Add new function
zebra_interface_parameters_update()
* zebra/zserv.[c,h]: Add new functions to send link parameters
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add support of new link-params CLI to vtysh
In vtysh_config.c/vtysh_config_parse_line(), it is not possible to continue
to use the ordered version for adding line i.e. config_add_line_uniq() to print
Interface CLI commands as it completely break the new LINK_PARAMS_NODE.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Update Traffic Engineering support for OSPFD
These patches update original code to RFC3630 (OSPF-TE) and add support of
RFC5392 (Inter-AS v2) & RFC7471 (TE metric extensions) and partial support
of RFC6827 (ASON - GMPLS).
* ospfd/ospf_dump.[c,h]: Add new dump functions for Traffic Engineering
* ospfd/ospf_opaque.[c,h]: Add new TLV code points for RFC5392
* ospfd/ospf_packet.c: Update checking of OSPF_OPTION
* ospfd/ospf_vty.[c,h]: Update ospf_str2area_id
* ospfd/ospf_zebra.c: Add new function ospf_interface_link_params() to get
Link Parameters information from the interface to populate Traffic Engineering
metrics
* ospfd/ospfd.[c,h]: Update OSPF_OPTION flags (T -> MT and new DN)
* ospfd/ospf_te.[c,h]: Major modifications to update the code to new
link parameters structure and new RFCs
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
tmp
2016-04-19 16:21:46 +02:00
|
|
|
}
|