| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
const const const your boat, merrily down the stream...
Signed-off-by: David Lamparter <equinox@diac24.net>
|
| |
|
|
|
|
|
| |
Convert the callback of the interface_delete to the new
ifp callback.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
| |
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
|
| |
For all the places we have a zclient->interface_up convert
them to use the interface ifp_up callback instead.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
|
| |
Switch the zclient->interface_add functionality to have everyone
use the interface create callback in lib/if.c
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This macro:
- Marks ZAPI callbacks for readability
- Standardizes argument names
- Makes it simple to add ZAPI arguments in the future
- Ensures proper types
- Looks better
- Shortens function declarations
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
| |
|
|
|
|
|
| |
It's been a year since we added the new optional parameters
to instantiation. Let's switch over to the new name.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Allow the higher level protocol to specify if it would
like to receive notifications about it's routes that
it has installed.
I've purposely made it part of zclient_new_notify because
we need to track the routes on a per daemon basis only.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
| |
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some differences compared to the old API:
* Now the redistributed routes are sent using address-family
independent messages (ZEBRA_REDISTRIBUTE_ROUTE_ADD and
ZEBRA_REDISTRIBUTE_ROUTE_DEL). This allows us to unify the ipv4/ipv6
zclient callbacks in the client daemons and thus remove a lot of
duplicate code;
* Now zebra sends all nexthops of the redistributed routes to the client
daemons, not only the first one. This shouldn't have any noticeable
performance implications and will allow us to remove an ugly exception
we had for ldpd (which needs to know all nexthops of the redistributed
routes). The other client daemons can simply ignore the nexthops if
they want or consult just the first one (e.g. ospfd/ospf6d/ripd/ripngd).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
|
|
| |
Pulled from d917882.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
| |
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
| |
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
|
|
|
| |
Allow vtysh to query every daemon about its
debugging status in one go.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the following crashes:
babeld aborted: vtysh -c "configure terminal" -c "router babel" -c "no redistribute pim"
babeld aborted: vtysh -c "configure terminal" -c "router babel" -c "no redistribute eigrp"
babeld aborted: vtysh -c "configure terminal" -c "router babel" -c "no redistribute nhrp"
babeld aborted: vtysh -c "configure terminal" -c "router babel" -c "no redistribute table"
babeld aborted: vtysh -c "configure terminal" -c "router babel" -c "no redistribute vnc"
babeld aborted: vtysh -c "configure terminal" -c "router babel" -c "redistribute pim"
babeld aborted: vtysh -c "configure terminal" -c "router babel" -c "redistribute eigrp"
babeld aborted: vtysh -c "configure terminal" -c "router babel" -c "redistribute nhrp"
babeld aborted: vtysh -c "configure terminal" -c "router babel" -c "redistribute table"
babeld aborted: vtysh -c "configure terminal" -c "router babel" -c "redistribute vnc"
While here, add an option to chose if we want to redistribute IPv4 or
IPv6 routes (e.g. we might want static IPv4 routes only). Also, join the
"no" version of the command in the same DEFUN (Yes We Can).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |\
| |
| |
| |
| |
| | |
Lots of conflicts from CMD_WARNING_CONFIG_FAILED...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| | |\
| | |
| | | |
vtysh: return non-zero for configuration failures
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
This allows frr-reload.py (or anything else that scripts via vtysh)
to know if the vtysh command worked or hit an error.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Turn on the ability in babel to receive v6 routes when requested.
robot# show babel route
192.168.201.0/24 metric 0 (exported)
2606:a000:111d:803e::/64 metric 0 (exported)
robot# conf t
robot(config)# int enp3s0
robot(config-if)# ipv6 addr 2404:4000:991d:804c:c32:ee94:742c:4d5/73
robot(config-if)# end
robot# show babel route
192.168.201.0/24 metric 0 (exported)
2606:a000:111d:803e::/64 metric 0 (exported)
2404:4000:991d:804c:c00::/73 metric 0 (exported)
robot#
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |/
|
|
| |
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
|
|
| |
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
| |
Saves 400 lines
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
| |
|
|
| |
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
| |
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
| |
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
| |
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a direct copy of:
https://github.com/boutier/quagga-merge
From the branch babel-merge
I copied the babeld directory into FRR and then fixed up everything to
compile.
Babeld at this point in time when run will more than likely crash and burn
in it's interfactions with zebra.
I might have messed up the cli, which will need to be looked at
extract.pl.in and vtysh.c need to be fixed up. Additionally we probably
need to work on DEFUN_NOSH conversion in babeld as well
This code comes from:
Matthieu Boutier <boutier@irif.fr>
Juliusz Chroboczek <jch@irif.fr>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
| |
Ticket: CM-9274
Reviewed By: sharpd@cumulusnetworks.com
Testing Done:
<DETAILED DESCRIPTION (REPLACE)>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
zclient.c depended upon link time inclusion of a
extern struct thread_master *master. This is a violation of the
namespace of the calling daemon. If a library needs the pointer
pass it in and save it for future use.
This code change also makes the zclient code consistent with
the other lib functions that need to schedule work on your behalf
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem is that zclient->redist[ZEBRA_ROUTE_MAX] used for storing a
client’s redist state, has no address-family qualification. This means
a client can only store its interest in a protocol (connected, static etc.),
but cant choose IPv4 or ipv6 with that. This hindered implementation on
client sides to manage redistribution of ipv4 and ipv6 both.
BGP's redistribution of protocols like connected/static is one such place.
One fix could be to overload this and flap the redist connection each time
any new afi is added for redist, but that may have side-effects on the
existing afi redist.
The cleaner way is to modify redist data-structure to also take AFI, and adjust
routines that deal with it, so that a client can register for a protocol
redistribution based on the AFI. BGP already maintains redistribution state
based on afi and protocol (bgp->redist[AFI_MAX][ZEBRA_ROUTE_MAX]). This patch
takes care of filling up the gap in zclient/zserv redistribution state to
also use AFI qualification.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
——————————————-------------
- etc/init.d/quagga is modified to support creating separate ospf daemon
process for each instance. Each individual instance is monitored by
watchquagga just like any protocol daemons.(requires initd-mi.patch).
- Vtysh is modified to able to connect to multiple daemons of the same
protocol (supported for OSPF only for now).
- ospfd is modified to remember the Instance-ID that its invoked with. For
the entire life of the process it caters to any command request that
matches that instance-ID (unless its a non instance specific command).
Routes/messages to zebra are tagged with instance-ID.
- zebra route/redistribute mechanisms are modified to work with
[protocol type + instance-id]
- bgpd now has ability to have multiple instance specific redistribution
for a protocol (OSPF only supported/tested for now).
- zlog ability to display instance-id besides the protocol/daemon name.
- Changes in other daemons are to because of the needed integration with
some of the modified APIs/routines. (Didn’t prefer replicating too many
separate instance specific APIs.)
- config/show/debug commands are modified to take instance-id argument
as appropriate.
Guidelines to start using multi-instance ospf
---------------------------------------------
The patch is backward compatible, i.e for any previous way of single ospf
deamon(router ospf <cr>) will continue to work as is, including all the
show commands etc.
To enable multiple instances, do the following:
1. service quagga stop
2. Modify /etc/quagga/daemons to add instance-ids of each desired
instance in the following format:
ospfd=“yes"
ospfd_instances="1,2,3"
assuming you want to enable 3 instances with those instance ids.
3. Create corresponding ospfd config files as ospfd-1.conf, ospfd-2.conf
and ospfd-3.conf.
4. service quagga start/restart
5. Verify that the deamons are started as expected. You should see
ospfd started with -n <instance-id> option.
ps –ef | grep quagga
With that /var/run/quagga/ should have ospfd-<instance-id>.pid and
ospfd-<instance-id>/vty to each instance.
6. vtysh to work with instances as you would with any other deamons.
7. Overall most quagga semantics are the same working with the instance
deamon, like it is for any other daemon.
NOTE:
To safeguard against errors leading to too many processes getting invoked,
a hard limit on number of instance-ids is in place, currently its 5.
Allowed instance-id range is <1-65535>
Once daemons are up, show running from vtysh should show the instance-id
of each daemon as 'router ospf <instance-id>’ (without needing explicit
configuration)
Instance-id can not be changed via vtysh, other router ospf configuration
is allowed as before.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The primary focus of this commit is to make "show running-config"
command display more current configuration, including some of the bits
previously seen in the output of "show babel running-config". Besides
that, the following commands were renamed for consistency with the
syntax of other components:
"debug *" to "debug babel *" (and moved to top level)
"show babel running-config" to "show babel parameters"
* babel_interface.c
* show_babel_running_config(): rename to show_babel_parameters(),
update syntax pattern, don't call show_babeld_configuration()
* babel_if_init(): update respectively
* babel_enable_if_config_write(): new VTY helper for static
babel_enable_if
* babel_interface.h: add extern declaration
* babel_main.c: unset all debug options by default
* show_babel_main_configuration(): remove debug options decoder
* babel_zebra.c
* babel_debug(): rename to debug_babel(), update syntax pattern
* no_babel_debug(): rename to no_debug_babel(), update syntax pattern
* babelz_zebra_init(): update respectively
* debug_babel_config_write() new VTY helper for static debug_type
* babel_zebra.h: add extern declaration
* babeld.c
* babel_config_write(): add the code to output "debug babel *",
"router babel", "redistribute *" and "network *" statements
* show_babeld_configuration(): dismiss
* babeld.h: remove extern declaration
* babeld.texi: update for renamed commands
* babeld.conf.sample: idem, add debug statements block
|
| |
|
|
|
|
| |
The function was effectively duplicating existing
zclient_redistribute(). This makes no_babel_redistribute_type()
consistent with babel_redistribute_type()
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
* Initial import of the Babel routing protocol, ported to Quagga.
* LICENCE: Update the original LICENCE file to include all known potentially
applicable copyright claims. Ask that any future contributors to babeld/
grant MIT/X11 licence to their work.
* *.{c,h}: Add GPL headers, in according with the SFLC guidance on
dealing with potentially mixed GPL/other licensed work, at:
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
|
