2002-12-13 21:15:29 +01:00
|
|
|
/*
|
2004-05-18 20:57:06 +02:00
|
|
|
* Copyright (C) 2003 Yasuhiro Ohara
|
2002-12-13 21:15:29 +01:00
|
|
|
*
|
|
|
|
* This file is part of GNU Zebra.
|
|
|
|
*
|
|
|
|
* GNU Zebra is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License as published by the
|
|
|
|
* Free Software Foundation; either version 2, or (at your option) any
|
|
|
|
* later version.
|
|
|
|
*
|
|
|
|
* GNU Zebra is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* General Public License for more details.
|
|
|
|
*
|
2017-05-13 10:25:29 +02:00
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
* with this program; see the file COPYING; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
2002-12-13 21:15:29 +01:00
|
|
|
*/
|
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
#include <zebra.h>
|
|
|
|
|
|
|
|
#include "log.h"
|
|
|
|
#include "vty.h"
|
|
|
|
#include "command.h"
|
|
|
|
#include "prefix.h"
|
|
|
|
#include "stream.h"
|
|
|
|
#include "zclient.h"
|
|
|
|
#include "memory.h"
|
2016-06-21 12:39:58 +02:00
|
|
|
#include "lib/bfd.h"
|
2018-06-18 15:46:19 +02:00
|
|
|
#include "lib_errors.h"
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
#include "ospf6_proto.h"
|
|
|
|
#include "ospf6_top.h"
|
2002-12-13 21:15:29 +01:00
|
|
|
#include "ospf6_interface.h"
|
2004-05-18 20:57:06 +02:00
|
|
|
#include "ospf6_route.h"
|
|
|
|
#include "ospf6_lsa.h"
|
2004-08-04 22:02:13 +02:00
|
|
|
#include "ospf6_lsdb.h"
|
2002-12-13 21:15:29 +01:00
|
|
|
#include "ospf6_asbr.h"
|
2004-05-18 20:57:06 +02:00
|
|
|
#include "ospf6_zebra.h"
|
2004-08-04 22:02:13 +02:00
|
|
|
#include "ospf6d.h"
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
DEFINE_MTYPE_STATIC(OSPF6D, OSPF6_DISTANCE, "OSPF6 distance")
|
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
unsigned char conf_debug_ospf6_zebra = 0;
|
2002-12-13 21:15:29 +01:00
|
|
|
|
|
|
|
/* information about zebra. */
|
|
|
|
struct zclient *zclient = NULL;
|
|
|
|
|
2004-10-03 20:18:34 +02:00
|
|
|
/* Router-id update message from zebra. */
|
2019-05-03 21:42:59 +02:00
|
|
|
static int ospf6_router_id_update_zebra(ZAPI_CALLBACK_ARGS)
|
2004-10-03 20:18:34 +02:00
|
|
|
{
|
|
|
|
struct prefix router_id;
|
|
|
|
struct ospf6 *o = ospf6;
|
|
|
|
|
|
|
|
zebra_router_id_update_read(zclient->ibuf, &router_id);
|
|
|
|
|
2018-02-27 20:24:16 +01:00
|
|
|
om6->zebra_router_id = router_id.u.prefix4.s_addr;
|
|
|
|
|
2005-03-02 23:43:26 +01:00
|
|
|
if (o == NULL)
|
|
|
|
return 0;
|
|
|
|
|
2018-02-12 22:22:04 +01:00
|
|
|
o->router_id_zebra = router_id.u.prefix4;
|
2018-02-27 20:24:16 +01:00
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(RECV)) {
|
|
|
|
char buf[INET_ADDRSTRLEN];
|
|
|
|
|
2020-03-05 19:17:54 +01:00
|
|
|
zlog_debug("%s: zebra router-id %s update", __func__,
|
|
|
|
inet_ntop(AF_INET, &router_id.u.prefix4, buf,
|
|
|
|
INET_ADDRSTRLEN));
|
2018-02-27 20:24:16 +01:00
|
|
|
}
|
2018-02-12 22:22:04 +01:00
|
|
|
|
2018-02-27 20:24:16 +01:00
|
|
|
ospf6_router_id_update();
|
2004-10-03 20:18:34 +02:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
/* redistribute function */
|
2020-09-01 10:31:49 +02:00
|
|
|
void ospf6_zebra_redistribute(int type, vrf_id_t vrf_id)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
2020-09-01 10:31:49 +02:00
|
|
|
if (vrf_bitmap_check(zclient->redist[AFI_IP6][type], vrf_id))
|
2002-12-13 21:15:29 +01:00
|
|
|
return;
|
2020-09-01 10:31:49 +02:00
|
|
|
vrf_bitmap_set(zclient->redist[AFI_IP6][type], vrf_id);
|
*: 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
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
if (zclient->sock > 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
|
|
|
zebra_redistribute_send(ZEBRA_REDISTRIBUTE_ADD, zclient,
|
2020-09-01 10:31:49 +02:00
|
|
|
AFI_IP6, type, 0, vrf_id);
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
2020-09-01 10:31:49 +02:00
|
|
|
void ospf6_zebra_no_redistribute(int type, vrf_id_t vrf_id)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
2020-09-01 10:31:49 +02:00
|
|
|
if (!vrf_bitmap_check(zclient->redist[AFI_IP6][type], vrf_id))
|
2002-12-13 21:15:29 +01:00
|
|
|
return;
|
2020-09-01 10:31:49 +02:00
|
|
|
vrf_bitmap_unset(zclient->redist[AFI_IP6][type], vrf_id);
|
2002-12-13 21:15:29 +01:00
|
|
|
if (zclient->sock > 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
|
|
|
zebra_redistribute_send(ZEBRA_REDISTRIBUTE_DELETE, zclient,
|
2020-09-01 10:31:49 +02:00
|
|
|
AFI_IP6, type, 0, vrf_id);
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
2019-05-03 21:42:59 +02:00
|
|
|
static int ospf6_zebra_if_address_update_add(ZAPI_CALLBACK_ARGS)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
|
|
|
struct connected *c;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
*: 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
|
|
|
c = zebra_interface_address_read(ZEBRA_INTERFACE_ADDRESS_ADD,
|
|
|
|
zclient->ibuf, vrf_id);
|
2002-12-13 21:15:29 +01:00
|
|
|
if (c == NULL)
|
|
|
|
return 0;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(RECV))
|
2020-10-14 19:17:36 +02:00
|
|
|
zlog_debug("Zebra Interface address add: %s %5s %pFX",
|
2004-12-24 07:00:11 +01:00
|
|
|
c->ifp->name, prefix_family_str(c->address),
|
2020-10-14 19:17:36 +02:00
|
|
|
c->address);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
if (c->address->family == AF_INET6) {
|
2012-12-13 16:11:16 +01:00
|
|
|
ospf6_interface_state_update(c->ifp);
|
|
|
|
ospf6_interface_connected_route_update(c->ifp);
|
|
|
|
}
|
2002-12-13 21:15:29 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-05-03 21:42:59 +02:00
|
|
|
static int ospf6_zebra_if_address_update_delete(ZAPI_CALLBACK_ARGS)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
|
|
|
struct connected *c;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
*: 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
|
|
|
c = zebra_interface_address_read(ZEBRA_INTERFACE_ADDRESS_DELETE,
|
|
|
|
zclient->ibuf, vrf_id);
|
2002-12-13 21:15:29 +01:00
|
|
|
if (c == NULL)
|
|
|
|
return 0;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(RECV))
|
2020-10-14 19:17:36 +02:00
|
|
|
zlog_debug("Zebra Interface address delete: %s %5s %pFX",
|
2004-12-24 07:00:11 +01:00
|
|
|
c->ifp->name, prefix_family_str(c->address),
|
2020-10-14 19:17:36 +02:00
|
|
|
c->address);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
if (c->address->family == AF_INET6) {
|
2012-12-13 16:11:16 +01:00
|
|
|
ospf6_interface_connected_route_update(c->ifp);
|
|
|
|
ospf6_interface_state_update(c->ifp);
|
2017-07-17 14:03:14 +02:00
|
|
|
}
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2019-10-30 01:16:28 +01:00
|
|
|
connected_free(&c);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2004-12-24 07:00:11 +01:00
|
|
|
return 0;
|
2017-07-17 14:03:14 +02:00
|
|
|
}
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2019-05-03 21:42:59 +02:00
|
|
|
static int ospf6_zebra_read_route(ZAPI_CALLBACK_ARGS)
|
2017-07-17 14:03:14 +02:00
|
|
|
{
|
2017-08-21 03:10:50 +02:00
|
|
|
struct zapi_route api;
|
2002-12-13 21:15:29 +01:00
|
|
|
unsigned long ifindex;
|
|
|
|
struct in6_addr *nexthop;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
if (ospf6 == NULL)
|
2016-02-18 16:25:09 +01:00
|
|
|
return 0;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-08-21 03:10:50 +02:00
|
|
|
if (zapi_route_decode(zclient->ibuf, &api) < 0)
|
|
|
|
return -1;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-08-21 03:10:50 +02:00
|
|
|
/* we completely ignore srcdest routes for now. */
|
|
|
|
if (CHECK_FLAG(api.message, ZAPI_MESSAGE_SRCPFX))
|
2015-07-08 19:48:51 +02:00
|
|
|
return 0;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2019-02-22 16:20:51 +01:00
|
|
|
if (IN6_IS_ADDR_LINKLOCAL(&api.prefix.u.prefix6))
|
|
|
|
return 0;
|
|
|
|
|
2017-08-21 03:10:50 +02:00
|
|
|
ifindex = api.nexthops[0].ifindex;
|
|
|
|
nexthop = &api.nexthops[0].gate.ipv6;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2012-12-13 16:11:16 +01:00
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(RECV)) {
|
|
|
|
char prefixstr[PREFIX2STR_BUFFER], nexthopstr[128];
|
2020-04-08 07:57:15 +02:00
|
|
|
|
|
|
|
prefix2str(&api.prefix, prefixstr, sizeof(prefixstr));
|
2017-08-25 02:43:29 +02:00
|
|
|
inet_ntop(AF_INET6, nexthop, nexthopstr, sizeof(nexthopstr));
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2016-10-01 06:41:40 +02:00
|
|
|
zlog_debug(
|
2012-12-13 16:11:16 +01:00
|
|
|
"Zebra Receive route %s: %s %s nexthop %s ifindex %ld tag %" ROUTE_TAG_PRI,
|
2019-05-03 21:42:59 +02:00
|
|
|
(cmd == ZEBRA_REDISTRIBUTE_ROUTE_ADD ? "add"
|
|
|
|
: "delete"),
|
2012-12-13 16:11:16 +01:00
|
|
|
zebra_route_string(api.type), prefixstr, nexthopstr,
|
|
|
|
ifindex, api.tag);
|
|
|
|
}
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2019-05-03 21:42:59 +02:00
|
|
|
if (cmd == ZEBRA_REDISTRIBUTE_ROUTE_ADD)
|
2017-08-21 03:10:50 +02:00
|
|
|
ospf6_asbr_redistribute_add(api.type, ifindex, &api.prefix,
|
2016-06-27 13:34:32 +02:00
|
|
|
api.nexthop_num, nexthop, api.tag);
|
|
|
|
else
|
2017-08-21 03:10:50 +02:00
|
|
|
ospf6_asbr_redistribute_remove(api.type, ifindex, &api.prefix);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2015-07-08 19:48:51 +02:00
|
|
|
return 0;
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
DEFUN (show_zebra,
|
2017-05-18 17:03:21 +02:00
|
|
|
show_ospf6_zebra_cmd,
|
|
|
|
"show ipv6 ospf6 zebra",
|
2002-12-13 21:15:29 +01:00
|
|
|
SHOW_STR
|
2017-05-18 17:03:21 +02:00
|
|
|
IPV6_STR
|
|
|
|
OSPF6_STR
|
2017-10-25 16:52:24 +02:00
|
|
|
ZEBRA_STR)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
|
|
|
int i;
|
2004-05-18 20:57:06 +02:00
|
|
|
if (zclient == NULL) {
|
2017-07-13 19:12:39 +02:00
|
|
|
vty_out(vty, "Not connected to zebra\n");
|
2004-05-18 20:57:06 +02:00
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2019-08-19 16:12:30 +02:00
|
|
|
vty_out(vty, "Zebra Information\n");
|
2017-08-19 16:38:47 +02:00
|
|
|
vty_out(vty, " fail: %d\n", zclient->fail);
|
2017-07-13 19:42:42 +02:00
|
|
|
vty_out(vty, " redistribute default: %d\n",
|
2019-01-11 22:20:13 +01:00
|
|
|
vrf_bitmap_check(zclient->default_information[AFI_IP6],
|
|
|
|
VRF_DEFAULT));
|
2004-05-18 20:57:06 +02:00
|
|
|
vty_out(vty, " redistribute:");
|
2002-12-13 21:15:29 +01:00
|
|
|
for (i = 0; i < ZEBRA_ROUTE_MAX; i++) {
|
*: 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
|
|
|
if (vrf_bitmap_check(zclient->redist[AFI_IP6][i], VRF_DEFAULT))
|
2005-10-01 Andrew J. Schorr <ajschorr@alumni.princeton.edu>
* zebra.h: Declare new functions zebra_route_string() and
zebra_route_char().
* log.c: (zroute_lookup,zebra_route_string,zebra_route_char) New
functions to map zebra route numbers to strings.
* zebra_vty.c: (route_type_str) Remove obsolete function: use new
library function zebra_route_string() instead. Note that there
are a few differences: for IPv6 routes, we now get "ripng" and
"ospf6" instead of the old behavior ("rip" and "ospf").
(route_type_char) Remove obsolete function: ues new library function
zebra_route_char() instead. Note that there is one difference:
the old function returned 'S' for a ZEBRA_ROUTE_SYSTEM route,
whereas the new one returns 'X'.
(vty_show_ip_route_detail,vty_show_ipv6_route_detail) Replace
route_type_str() with zebra_route_string().
(vty_show_ip_route,vty_show_ipv6_route) Replace route_type_char()
with zebra_route_char().
* bgp_vty.c: (bgp_config_write_redistribute) Use new library function
zebra_route_string instead of a local hard-coded table.
* ospf6_asbr.c: Remove local hard-coded tables zroute_name and
zroute_abname. Change the ZROUTE_NAME macro to use new library
function zebra_route_string(). Remove the ZROUTE_ABNAME macro.
(ospf6_asbr_external_route_show): Replace ZROUTE_ABNAME() with
a call to zebra_route_char(), and be sure to fix the format string,
since we now have a char instead of a char *.
* ospf6_zebra.c: Remove local hard-coded tables zebra_route_name and
zebra_route_abname. Note that the zebra_route_name[] table
contained mixed-case strings, whereas the zebra_route_string()
function returns lower-case strings.
(ospf6_zebra_read_ipv6): Change debug message to use new library
function zebra_route_string() instead of zebra_route_name[].
(show_zebra): Use new library function zebra_route_string() instead
of zebra_route_name[].
* ospf_dump.c: Remove local hard-coded table ospf_redistributed_proto.
(ospf_redist_string) New function implemented using new library
function zebra_route_string(). Note that there are a few differences
in the output that will result: the new function returns strings
that are lower-case, whereas the old table was mixed case. Also,
the old table mapped ZEBRA_ROUTE_OSPF6 to "OSPFv3", whereas the
new function returns "ospf6".
* ospfd.h: Remove extern struct message ospf_redistributed_proto[],
and add extern const char *ospf_redist_string(u_int route_type)
instead.
* ospf_asbr.c: (ospf_external_info_add) In two messages, use
ospf_redist_string instead of LOOKUP(ospf_redistributed_proto).
* ospf_vty.c: Remove local hard-coded table distribute_str.
(config_write_ospf_redistribute,config_write_ospf_distribute): Use
new library function zebra_route_string() instead of distribute_str[].
* ospf_zebra.c: (ospf_redistribute_set,ospf_redistribute_unset,
ospf_redistribute_default_set,ospf_redistribute_check)
In debug messages, use ospf_redist_string() instead of
LOOKUP(ospf_redistributed_proto).
* rip_zebra.c: (config_write_rip_redistribute): Remove local hard-coded
table str[]. Replace str[] with calls to new library function
zebra_route_string().
* ripd.c: Remove local hard-coded table route_info[].
(show_ip_rip) Replace uses of str[] with calls to new library
functions zebra_route_char and zebra_route_string.
* ripng_zebra.c: (ripng_redistribute_write) Remove local hard-coded
table str[]. Replace str[i] with new library function
zebra_route_string(i).
* ripngd.c: Remove local hard-coded table route_info[].
(show_ipv6_ripng) Use new library function zebra_route_char() instead
of table route_info[].
2005-10-01 19:38:06 +02:00
|
|
|
vty_out(vty, " %s", zebra_route_string(i));
|
2004-05-18 20:57:06 +02:00
|
|
|
}
|
2017-07-13 19:12:39 +02:00
|
|
|
vty_out(vty, "\n");
|
2002-12-13 21:15:29 +01:00
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define ADD 0
|
2004-05-18 20:57:06 +02:00
|
|
|
#define REM 1
|
|
|
|
static void ospf6_zebra_route_update(int type, struct ospf6_route *request)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
2017-08-21 02:19:07 +02:00
|
|
|
struct zapi_route api;
|
2015-11-23 21:44:34 +01:00
|
|
|
char buf[PREFIX2STR_BUFFER];
|
2004-05-18 20:57:06 +02:00
|
|
|
int nhcount;
|
2015-05-20 03:03:39 +02:00
|
|
|
int ret = 0;
|
2017-08-21 02:19:07 +02:00
|
|
|
struct prefix *dest;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(SEND)) {
|
|
|
|
prefix2str(&request->prefix, buf, sizeof(buf));
|
2004-12-24 07:00:11 +01:00
|
|
|
zlog_debug("Send %s route: %s",
|
|
|
|
(type == REM ? "remove" : "add"), buf);
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
if (zclient->sock < 0) {
|
2004-05-18 20:57:06 +02:00
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(SEND))
|
2004-12-24 07:00:11 +01:00
|
|
|
zlog_debug(" Not connected to Zebra");
|
2002-12-13 21:15:29 +01:00
|
|
|
return;
|
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
if (request->path.origin.adv_router == ospf6->router_id
|
|
|
|
&& (request->path.type == OSPF6_PATH_TYPE_EXTERNAL1
|
|
|
|
|| request->path.type == OSPF6_PATH_TYPE_EXTERNAL2)) {
|
2004-05-18 20:57:06 +02:00
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(SEND))
|
2004-12-24 07:00:11 +01:00
|
|
|
zlog_debug(" Ignore self-originated external route");
|
2002-12-13 21:15:29 +01:00
|
|
|
return;
|
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
/* If removing is the best path and if there's another path,
|
|
|
|
treat this request as add the secondary path */
|
|
|
|
if (type == REM && ospf6_route_is_best(request) && request->next
|
|
|
|
&& ospf6_route_is_same(request, request->next)) {
|
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(SEND))
|
2004-12-24 07:00:11 +01:00
|
|
|
zlog_debug(
|
2020-03-14 00:08:48 +01:00
|
|
|
" Best-path removal resulted Secondary addition");
|
2004-05-18 20:57:06 +02:00
|
|
|
type = ADD;
|
|
|
|
request = request->next;
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
/* Only the best path will be sent to zebra. */
|
|
|
|
if (!ospf6_route_is_best(request)) {
|
|
|
|
/* this is not preferred best route, ignore */
|
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(SEND))
|
2004-12-24 07:00:11 +01:00
|
|
|
zlog_debug(" Ignore non-best route");
|
2004-05-18 20:57:06 +02:00
|
|
|
return;
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2015-05-20 03:03:39 +02:00
|
|
|
nhcount = ospf6_route_num_nexthops(request);
|
2004-05-18 20:57:06 +02:00
|
|
|
if (nhcount == 0) {
|
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(SEND))
|
2004-12-24 07:00:11 +01:00
|
|
|
zlog_debug(" No nexthop, ignore");
|
2002-12-13 21:15:29 +01:00
|
|
|
return;
|
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-08-21 02:19:07 +02:00
|
|
|
dest = &request->prefix;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-08-21 02:19:07 +02:00
|
|
|
memset(&api, 0, sizeof(api));
|
2020-09-01 10:31:49 +02:00
|
|
|
api.vrf_id = ospf6->vrf_id;
|
2002-12-13 21:15:29 +01:00
|
|
|
api.type = ZEBRA_ROUTE_OSPF6;
|
2011-12-05 13:35:14 +01:00
|
|
|
api.safi = SAFI_UNICAST;
|
2017-08-21 02:19:07 +02:00
|
|
|
api.prefix = *dest;
|
2002-12-13 21:15:29 +01:00
|
|
|
SET_FLAG(api.message, ZAPI_MESSAGE_NEXTHOP);
|
2017-09-21 14:49:31 +02:00
|
|
|
api.nexthop_num = MIN(nhcount, MULTIPATH_NUM);
|
|
|
|
ospf6_route_zebra_copy_nexthops(request, api.nexthops, api.nexthop_num);
|
2004-05-18 20:57:06 +02:00
|
|
|
SET_FLAG(api.message, ZAPI_MESSAGE_METRIC);
|
|
|
|
api.metric = (request->path.metric_type == 2 ? request->path.u.cost_e2
|
2015-05-20 03:03:39 +02:00
|
|
|
: request->path.cost);
|
2016-10-01 06:41:40 +02:00
|
|
|
if (request->path.tag) {
|
|
|
|
SET_FLAG(api.message, ZAPI_MESSAGE_TAG);
|
|
|
|
api.tag = request->path.tag;
|
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
SET_FLAG(api.message, ZAPI_MESSAGE_DISTANCE);
|
2017-08-21 02:19:07 +02:00
|
|
|
api.distance =
|
|
|
|
ospf6_distance_apply((struct prefix_ipv6 *)dest, request);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
if (type == REM)
|
2017-08-21 02:19:07 +02:00
|
|
|
ret = zclient_route_send(ZEBRA_ROUTE_DELETE, zclient, &api);
|
2002-12-13 21:15:29 +01:00
|
|
|
else
|
2017-08-21 02:19:07 +02:00
|
|
|
ret = zclient_route_send(ZEBRA_ROUTE_ADD, zclient, &api);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
if (ret < 0)
|
2018-09-13 21:34:28 +02:00
|
|
|
flog_err(EC_LIB_ZAPI_SOCKET,
|
2018-09-13 21:38:57 +02:00
|
|
|
"zclient_route_send() %s failed: %s",
|
|
|
|
(type == REM ? "delete" : "add"),
|
|
|
|
safe_strerror(errno));
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
void ospf6_zebra_route_update_add(struct ospf6_route *request)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
2004-05-18 20:57:06 +02:00
|
|
|
ospf6_zebra_route_update(ADD, request);
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
void ospf6_zebra_route_update_remove(struct ospf6_route *request)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
2004-05-18 20:57:06 +02:00
|
|
|
ospf6_zebra_route_update(REM, request);
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
2015-05-20 03:03:39 +02:00
|
|
|
void ospf6_zebra_add_discard(struct ospf6_route *request)
|
|
|
|
{
|
2017-08-21 02:19:07 +02:00
|
|
|
struct zapi_route api;
|
|
|
|
struct prefix *dest = &request->prefix;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-08-12 18:03:29 +02:00
|
|
|
if (!CHECK_FLAG(request->flag, OSPF6_ROUTE_BLACKHOLE_ADDED)) {
|
2017-08-21 02:19:07 +02:00
|
|
|
memset(&api, 0, sizeof(api));
|
2020-09-01 10:31:49 +02:00
|
|
|
api.vrf_id = ospf6->vrf_id;
|
2017-08-12 18:03:29 +02:00
|
|
|
api.type = ZEBRA_ROUTE_OSPF6;
|
|
|
|
api.safi = SAFI_UNICAST;
|
2017-08-21 02:19:07 +02:00
|
|
|
api.prefix = *dest;
|
2012-04-11 23:52:46 +02:00
|
|
|
zapi_route_set_blackhole(&api, BLACKHOLE_NULL);
|
2017-08-12 18:03:29 +02:00
|
|
|
|
2017-08-21 02:19:07 +02:00
|
|
|
zclient_route_send(ZEBRA_ROUTE_ADD, zclient, &api);
|
2017-08-12 18:03:29 +02:00
|
|
|
|
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(SEND))
|
2020-10-14 19:17:36 +02:00
|
|
|
zlog_debug("Zebra: Route add discard %pFX", dest);
|
2017-08-12 18:03:29 +02:00
|
|
|
|
|
|
|
SET_FLAG(request->flag, OSPF6_ROUTE_BLACKHOLE_ADDED);
|
|
|
|
} else {
|
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(SEND))
|
|
|
|
zlog_debug(
|
2020-10-14 19:17:36 +02:00
|
|
|
"Zebra: Blackhole route present already %pFX",
|
|
|
|
dest);
|
2015-05-20 03:03:39 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void ospf6_zebra_delete_discard(struct ospf6_route *request)
|
|
|
|
{
|
2017-08-21 02:19:07 +02:00
|
|
|
struct zapi_route api;
|
|
|
|
struct prefix *dest = &request->prefix;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-08-12 18:03:29 +02:00
|
|
|
if (CHECK_FLAG(request->flag, OSPF6_ROUTE_BLACKHOLE_ADDED)) {
|
2017-08-21 02:19:07 +02:00
|
|
|
memset(&api, 0, sizeof(api));
|
2020-09-01 10:31:49 +02:00
|
|
|
api.vrf_id = ospf6->vrf_id;
|
2017-08-12 18:03:29 +02:00
|
|
|
api.type = ZEBRA_ROUTE_OSPF6;
|
|
|
|
api.safi = SAFI_UNICAST;
|
2017-08-21 02:19:07 +02:00
|
|
|
api.prefix = *dest;
|
2012-04-11 23:52:46 +02:00
|
|
|
zapi_route_set_blackhole(&api, BLACKHOLE_NULL);
|
2017-08-12 18:03:29 +02:00
|
|
|
|
2017-08-21 02:19:07 +02:00
|
|
|
zclient_route_send(ZEBRA_ROUTE_DELETE, zclient, &api);
|
2017-08-12 18:03:29 +02:00
|
|
|
|
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(SEND))
|
2020-10-14 19:17:36 +02:00
|
|
|
zlog_debug("Zebra: Route delete discard %pFX", dest);
|
2017-08-12 18:03:29 +02:00
|
|
|
|
|
|
|
UNSET_FLAG(request->flag, OSPF6_ROUTE_BLACKHOLE_ADDED);
|
|
|
|
} else {
|
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(SEND))
|
|
|
|
zlog_debug(
|
2020-10-14 19:17:36 +02:00
|
|
|
"Zebra: Blackhole route already deleted %pFX",
|
|
|
|
dest);
|
2015-05-20 03:03:39 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
static struct ospf6_distance *ospf6_distance_new(void)
|
|
|
|
{
|
|
|
|
return XCALLOC(MTYPE_OSPF6_DISTANCE, sizeof(struct ospf6_distance));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ospf6_distance_free(struct ospf6_distance *odistance)
|
|
|
|
{
|
|
|
|
XFREE(MTYPE_OSPF6_DISTANCE, odistance);
|
|
|
|
}
|
|
|
|
|
|
|
|
int ospf6_distance_set(struct vty *vty, struct ospf6 *o,
|
|
|
|
const char *distance_str, const char *ip_str,
|
|
|
|
const char *access_list_str)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
struct prefix_ipv6 p;
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t distance;
|
2014-03-05 09:13:43 +01:00
|
|
|
struct route_node *rn;
|
|
|
|
struct ospf6_distance *odistance;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
ret = str2prefix_ipv6(ip_str, &p);
|
|
|
|
if (ret == 0) {
|
2017-07-13 17:49:13 +02:00
|
|
|
vty_out(vty, "Malformed prefix\n");
|
2017-07-13 21:56:08 +02:00
|
|
|
return CMD_WARNING_CONFIG_FAILED;
|
2014-03-05 09:13:43 +01:00
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
distance = atoi(distance_str);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
/* Get OSPF6 distance node. */
|
|
|
|
rn = route_node_get(o->distance_table, (struct prefix *)&p);
|
|
|
|
if (rn->info) {
|
|
|
|
odistance = rn->info;
|
|
|
|
route_unlock_node(rn);
|
|
|
|
} else {
|
|
|
|
odistance = ospf6_distance_new();
|
|
|
|
rn->info = odistance;
|
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
/* Set distance value. */
|
|
|
|
odistance->distance = distance;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
/* Reset access-list configuration. */
|
|
|
|
if (odistance->access_list) {
|
|
|
|
free(odistance->access_list);
|
|
|
|
odistance->access_list = NULL;
|
|
|
|
}
|
|
|
|
if (access_list_str)
|
|
|
|
odistance->access_list = strdup(access_list_str);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ospf6_distance_unset(struct vty *vty, struct ospf6 *o,
|
|
|
|
const char *distance_str, const char *ip_str,
|
|
|
|
const char *access_list_str)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
struct prefix_ipv6 p;
|
|
|
|
struct route_node *rn;
|
|
|
|
struct ospf6_distance *odistance;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
ret = str2prefix_ipv6(ip_str, &p);
|
|
|
|
if (ret == 0) {
|
2017-07-13 17:49:13 +02:00
|
|
|
vty_out(vty, "Malformed prefix\n");
|
2017-07-13 21:56:08 +02:00
|
|
|
return CMD_WARNING_CONFIG_FAILED;
|
2014-03-05 09:13:43 +01:00
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
rn = route_node_lookup(o->distance_table, (struct prefix *)&p);
|
|
|
|
if (!rn) {
|
2017-07-13 17:49:13 +02:00
|
|
|
vty_out(vty, "Cant't find specified prefix\n");
|
2017-07-13 21:56:08 +02:00
|
|
|
return CMD_WARNING_CONFIG_FAILED;
|
2014-03-05 09:13:43 +01:00
|
|
|
}
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
odistance = rn->info;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
if (odistance->access_list)
|
|
|
|
free(odistance->access_list);
|
|
|
|
ospf6_distance_free(odistance);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
rn->info = NULL;
|
|
|
|
route_unlock_node(rn);
|
|
|
|
route_unlock_node(rn);
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ospf6_distance_reset(struct ospf6 *o)
|
|
|
|
{
|
|
|
|
struct route_node *rn;
|
|
|
|
struct ospf6_distance *odistance;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2014-03-05 09:13:43 +01:00
|
|
|
for (rn = route_top(o->distance_table); rn; rn = route_next(rn))
|
|
|
|
if ((odistance = rn->info) != NULL) {
|
|
|
|
if (odistance->access_list)
|
|
|
|
free(odistance->access_list);
|
|
|
|
ospf6_distance_free(odistance);
|
|
|
|
rn->info = NULL;
|
|
|
|
route_unlock_node(rn);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t ospf6_distance_apply(struct prefix_ipv6 *p, struct ospf6_route * or)
|
2014-03-05 09:13:43 +01:00
|
|
|
{
|
|
|
|
struct ospf6 *o;
|
|
|
|
|
|
|
|
o = ospf6;
|
|
|
|
if (o == NULL)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (o->distance_intra)
|
|
|
|
if (or->path.type == OSPF6_PATH_TYPE_INTRA)
|
|
|
|
return o->distance_intra;
|
|
|
|
|
|
|
|
if (o->distance_inter)
|
|
|
|
if (or->path.type == OSPF6_PATH_TYPE_INTER)
|
|
|
|
return o->distance_inter;
|
|
|
|
|
|
|
|
if (o->distance_external)
|
|
|
|
if (or->path.type == OSPF6_PATH_TYPE_EXTERNAL1 ||
|
|
|
|
or->path.type == OSPF6_PATH_TYPE_EXTERNAL2)
|
|
|
|
return o->distance_external;
|
|
|
|
|
|
|
|
if (o->distance_all)
|
|
|
|
return o->distance_all;
|
|
|
|
|
|
|
|
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 ospf6_zebra_connected(struct zclient *zclient)
|
|
|
|
{
|
2016-06-21 12:39:58 +02:00
|
|
|
/* Send the client registration */
|
2019-03-26 14:29:13 +01:00
|
|
|
bfd_client_sendmsg(zclient, ZEBRA_BFD_CLIENT_REGISTER, VRF_DEFAULT);
|
2016-06-21 12:39:58 +02:00
|
|
|
|
2016-02-12 20:37:33 +01:00
|
|
|
zclient_send_reg_requests(zclient, VRF_DEFAULT);
|
*: 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
|
|
|
}
|
|
|
|
|
2015-09-23 22:26:56 +02:00
|
|
|
void ospf6_zebra_init(struct thread_master *master)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
|
|
|
/* Allocate zebra structure. */
|
2018-11-02 13:54:58 +01:00
|
|
|
zclient = zclient_new(master, &zclient_options_default);
|
2017-10-11 16:37:20 +02:00
|
|
|
zclient_init(zclient, ZEBRA_ROUTE_OSPF6, 0, &ospf6d_privs);
|
*: 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
|
|
|
zclient->zebra_connected = ospf6_zebra_connected;
|
2004-10-03 20:18:34 +02:00
|
|
|
zclient->router_id_update = ospf6_router_id_update_zebra;
|
2002-12-13 21:15:29 +01:00
|
|
|
zclient->interface_address_add = ospf6_zebra_if_address_update_add;
|
|
|
|
zclient->interface_address_delete =
|
|
|
|
ospf6_zebra_if_address_update_delete;
|
2017-08-21 03:10:50 +02:00
|
|
|
zclient->redistribute_route_add = ospf6_zebra_read_route;
|
|
|
|
zclient->redistribute_route_del = ospf6_zebra_read_route;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
/* Install command element for zebra node. */
|
2017-05-18 17:03:21 +02:00
|
|
|
install_element(VIEW_NODE, &show_ospf6_zebra_cmd);
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
/* Debug */
|
2014-06-04 06:53:35 +02:00
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
DEFUN (debug_ospf6_zebra_sendrecv,
|
|
|
|
debug_ospf6_zebra_sendrecv_cmd,
|
2016-09-30 03:27:05 +02:00
|
|
|
"debug ospf6 zebra [<send|recv>]",
|
2004-05-18 20:57:06 +02:00
|
|
|
DEBUG_STR
|
|
|
|
OSPF6_STR
|
|
|
|
"Debug connection between zebra\n"
|
|
|
|
"Debug Sending zebra\n"
|
|
|
|
"Debug Receiving zebra\n"
|
|
|
|
)
|
|
|
|
{
|
2016-09-23 21:56:31 +02:00
|
|
|
int idx_send_recv = 3;
|
2004-05-18 20:57:06 +02:00
|
|
|
unsigned char level = 0;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2016-09-30 03:27:05 +02:00
|
|
|
if (argc == 4) {
|
|
|
|
if (strmatch(argv[idx_send_recv]->text, "send"))
|
2004-05-18 20:57:06 +02:00
|
|
|
level = OSPF6_DEBUG_ZEBRA_SEND;
|
2016-09-30 03:27:05 +02:00
|
|
|
else if (strmatch(argv[idx_send_recv]->text, "recv"))
|
2004-05-18 20:57:06 +02:00
|
|
|
level = OSPF6_DEBUG_ZEBRA_RECV;
|
|
|
|
} else
|
|
|
|
level = OSPF6_DEBUG_ZEBRA_SEND | OSPF6_DEBUG_ZEBRA_RECV;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
OSPF6_DEBUG_ZEBRA_ON(level);
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
DEFUN (no_debug_ospf6_zebra_sendrecv,
|
|
|
|
no_debug_ospf6_zebra_sendrecv_cmd,
|
2016-09-30 03:27:05 +02:00
|
|
|
"no debug ospf6 zebra [<send|recv>]",
|
2004-05-18 20:57:06 +02:00
|
|
|
NO_STR
|
|
|
|
DEBUG_STR
|
|
|
|
OSPF6_STR
|
|
|
|
"Debug connection between zebra\n"
|
|
|
|
"Debug Sending zebra\n"
|
|
|
|
"Debug Receiving zebra\n"
|
|
|
|
)
|
|
|
|
{
|
2016-09-23 21:56:31 +02:00
|
|
|
int idx_send_recv = 4;
|
2004-05-18 20:57:06 +02:00
|
|
|
unsigned char level = 0;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2016-09-30 03:27:05 +02:00
|
|
|
if (argc == 5) {
|
|
|
|
if (strmatch(argv[idx_send_recv]->text, "send"))
|
2004-05-18 20:57:06 +02:00
|
|
|
level = OSPF6_DEBUG_ZEBRA_SEND;
|
2016-09-30 03:27:05 +02:00
|
|
|
else if (strmatch(argv[idx_send_recv]->text, "recv"))
|
2004-05-18 20:57:06 +02:00
|
|
|
level = OSPF6_DEBUG_ZEBRA_RECV;
|
|
|
|
} else
|
|
|
|
level = OSPF6_DEBUG_ZEBRA_SEND | OSPF6_DEBUG_ZEBRA_RECV;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2004-05-18 20:57:06 +02:00
|
|
|
OSPF6_DEBUG_ZEBRA_OFF(level);
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
int config_write_ospf6_debug_zebra(struct vty *vty)
|
|
|
|
{
|
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(SEND) && IS_OSPF6_DEBUG_ZEBRA(RECV))
|
2017-07-13 19:12:39 +02:00
|
|
|
vty_out(vty, "debug ospf6 zebra\n");
|
2004-05-18 20:57:06 +02:00
|
|
|
else {
|
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(SEND))
|
2017-07-13 19:12:39 +02:00
|
|
|
vty_out(vty, "debug ospf6 zebra send\n");
|
2004-05-18 20:57:06 +02:00
|
|
|
if (IS_OSPF6_DEBUG_ZEBRA(RECV))
|
2017-07-13 19:12:39 +02:00
|
|
|
vty_out(vty, "debug ospf6 zebra recv\n");
|
2004-05-18 20:57:06 +02:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-08-15 14:45:30 +02:00
|
|
|
void install_element_ospf6_debug_zebra(void)
|
2002-12-13 21:15:29 +01:00
|
|
|
{
|
2004-05-18 20:57:06 +02:00
|
|
|
install_element(ENABLE_NODE, &debug_ospf6_zebra_sendrecv_cmd);
|
|
|
|
install_element(ENABLE_NODE, &no_debug_ospf6_zebra_sendrecv_cmd);
|
|
|
|
install_element(CONFIG_NODE, &debug_ospf6_zebra_sendrecv_cmd);
|
|
|
|
install_element(CONFIG_NODE, &no_debug_ospf6_zebra_sendrecv_cmd);
|
2002-12-13 21:15:29 +01:00
|
|
|
}
|