Changed interaction between zebra and routing protocols so that they correctly
fill in the vrf_iflist even for vrfs they're not responsible for. In that way,
when they get callbacks from zebra they can correctly understand whether they need
to create them or not.
Ticket: CM-10427
Signed-off-by: Don Slice
Reviewed-by:
Change-Id: Iff33d70089d1393bf3e9c757d9e9faf134699121
Signed-off-by: kitty <khiruthigai.balasubramanian@hpe.com>
Tested-by: NetDEF CI System <cisystem@netdef.org>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
The file if.c has a iflist that had the list of interfaces
in the default vrf. Remove this variable and replace
with a vrf_iflist lookup on the default vrf where it
was used.
Additionally, modify ptm code to iterate over all vrf's
when enabling ptm.
Ticket: CM-10338
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Radhika Mahankali <radhika@cumulusnetworks.com>
bfd was receiving a callback with an interface name string
but was ignoring the passed in vrf to find the ifp pointer.
This commit fixes that code path in bfd.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Radhika Mahankali <radhika@cumulusnetworks.com>
This reverts commit a7928d3ac4.
This code change breaks allot of tests that have hard coded the
distance. We'll unrevert this after the 3.0 release window.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
All daemons changed to flag an interface that has been moved to a vrf as DELETED instead of INTERNAL.
When they were flagged as IFINDEX_INTERNAL, ospf, rip, and isis would re-install them in the default
assuming that they were being "pre-defined" before the kernel definitions.
Ticket: CM-9265
Signed-off-by: Don Slice
Reviewed-by: Donald Sharp
Change-Id: Iff33d70089d1393bf3e9c757d9e9faf134699121
Signed-off-by: kitty <khiruthigai.balasubramanian@hpe.com>
Tested-by: NetDEF CI System <cisystem@netdef.org>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
This construct:
struct ospf *ospf = vty->index;
if (!ospf)
return CMD_SUCCESS;
Is present throughout the entire ospfd code base. The command:
distance ospf external 255
Is not protected by this construct. I added this construct
to the command and in addition did a quick search to find
any others not protected and to protect them.
Ticket: CM-9725
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-7615, CM-7773
Reviewed By: CCR-3610, CCR-3708
Testing Done: Unit, BGP Smoke and OSPF Smoke
Changes (70790261926b17200c8c9377c4576cd3b486fcef) ported from 2.5
Issue (related to CM-7615): 1. CM-7615: There is mismatch in the client name between ptm display of client BFD sessions and the zebra logs. For example, if bgpd added BFD session, zebra logs will show the client as “bgp” but the ptm display will show it as “quagga”
2. Bigger problem is when 2 clients (for example OSPF and BGP) from Quagga register for same BFD session and only one client de-registers the BFD session. This results in BFD session deletion from PTM even though other client still has the BFD registration.
Root Cause: Even though BGP, OSPF and OSPF6 are 3 different clients from Quagga that are trying to register/deregister BFD sessions with PTM, all 3 are represented as one client “quagga” from zebra. This makes it hard for PTM/BFD to distinguish between all three when BFD peer registration/deregistration happens from the clients.
Fix: Send the actual client name bgp, ospf or ospf6 from zebra with BFD reg/dereg messages instead of one unified client name “quagga”
CM-7773: BFD sessions are not getting cleaned from PTM even though no BGP peering exists in Quagga.
Root Cause: PTM cleans up stale BFD sessions from a client when it finds a change in seq id advertised by the client. But, if PTM never detects a change in the seq id then the stale BFD sessions never get cleaned up. The test restarts the quagga without saving the configuration, which results in no BGP peering. No BGP peers are registered with PTM after restart and PTM does not detect a client seq id change resulting in stale BFD sessions.
Fix: New client registration message was added in PTM. Every client that is interested in BFD monitoring will register with PTM with the client seq id. Client will register with a different seq id (typically pid) every time it restarts. This will help in detecting the change in seq id and cleanup of stale BFD sessions for a client.
Code Changes: To support the new client registration message following changes have been made
- Added support for client registration messaging in zebra for sending messages to PTM.
- Added support for client registration messaging between zebra and clients (BGP, OSPF and OSPF6) in BFD library.
- Expanded the reg/de reg peer messaging between zebra and clients to support client specific seq id to distinguish between multiple clients registering for BFD peer rather than one “quagga” client.
- Changes in bgpd, ospfd and ospf6d to send client registrations at the time of daemon initialization and on receiving BFD peer replay message.
If we are attempting to redistribute from a MI ospf
then when should only check for the non MI case if
instance was not passed in.
Ticket: CM-9543
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
A recent modification accidently removed the 'no XXXX'
form of some commands that cl-ospf depended on.
Tickets: CM-9481
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-9285
Clients (BGP, OSPF etc.) register with Zebra for information about
a VRF such as Router ID, interfaces and redistribution. Add API to
support unregister also which is required for the non-default VRF.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-9128
Reviewed By: CCR-4098
Testing Done: Manual testing
Modify the daemons to integrate with systemd, if it is enabled via configure,
and to notify systemd that they are running/stopping and to send watch
notifications.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
During CR for nexthop upstream it was noticed that usage
of prefix2str was not consistent. This fixes this problem
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The json keyword was being read incorrectly.
Basically some commands read a variable # of arguments
and in ospf the command values were being placed into
argc and argv. With a variable # of arguments their
existed a possibility that less arguments would be read
from the cli than were being tested for in the command function
handler. This caused core dumps in some situations.
All code to read to decide to use the json keyword has
been centralized through a function and all code
converted to use it, irrelevant if it exhibited the bug
Ticket: CM-8278
Reviewed by: CCR-3830
Testing: OSPF no longer crashes and all other test suites still run
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Zebra already knows if an interface is unnumbered or not. This
is communicated to OSPF.
OSPF would only send a NEXTHOP_TYPE_IPV4_ONLINK *if* the path
was unnumbered, which it learns from Zebra.
As such, Have OSPF use the normal NEXTHOP_TYPE_IPV4_IFINDEX
type for unnumbered paths. In Zebra, if the ifindex recieved
is unnumbered then assume that the link is NEXTHOP_FLAG_ONLINK.
Ticket: CM-8145
Reviewed-by: CCR-3771
Testing: See bug
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When there is an OSPF missconfiguration, do not zlog_warn the fact
as that it would quickly overwhelm any log file.
Ticket: CM-7534
Reviewed by: CCR-3756
Testing: See bug
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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
These are about to be touched and there's no point in other code
touching into prefix list's internas. Add some isolation.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Later, an interface will belong to a specific VRF, and the interface
initialization will be a part of the VRF initialization. So now call
if_init() from vrf_init(), and if_terminate() from vrf_terminate().
Daemons have the according changes:
- if if_init() was called or "iflist" was initialized, now call
vrf_init() instead;
- if if_terminate() was called or "iflist" was destroyed, now call
vrf_terminate() instead.
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: Vincent JARDIN <vincent.jardin@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Conflicts:
bgpd/bgp_main.c
pimd/pim_iface.c
pimd/pim_iface.h
pimd/pim_main.c
pimd/pimd.c
Ticket: CM-6768
Reviewed By: CCR-3207
Testing Done: bgpsmoke, smoke, topo to create failure
Redistributing routes goes through a del/add cycle whenever a redistributed
is updated. This del/add cycle causes disruption by causing traffic loss
for brief/long periods of time(6-8 s in case of OSPF). The modifications in
this patch remove the del/add cycle to ensure that this disruption doesn't
happen.
Also fixed sending no forwarding address when announcing IPv4 routes with IPv6
nexthops, and sending nexthop only when there is a single path.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-7388
Reviewed By: Donald, Vivek
Testing Done: Cherry picking from 2.5.4, no testing on 3.0 yet
OSPF needs to handle the previously added redist update/raplace semantics.
Update has no new message type, it comes as ADD message.
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>
Ticket:
Reviewed By: CCR-3335
Testing Done: bgpsmoke, ENHE tests etc.
Add support for filtering routes from upper layer protocols to zebra
via route-maps for IPv6. The same functionality already existed for
IPv4.
In addition, add support for setting source of routes via IPv6 protocol
map.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Reviewed-by: Vipin Kumar <vipin@cumulusnetworks.com>
Ticket:CM-6802, CM-6952
Reviewed By: Donald, Kanna
Testing Done:
Double commit of b76943235e09472ec174edcf7204fc82d27fe966 from br2.5. But, manually resolved all the compilation errors. Also, modified the shows to support the json format which was not supported in br2.5.
CM-6802 – Currently, BFD session status can be monitored only through ptmctl. There is no way to check the BFD status of a peer/neighbor through Quagga. Debugging becomes easier if BFD status is shown in Quagga too. BFD status is relevant when it is shown against the BGP peer/OSPF neighbor. For, this following code changes have been done:
- Only down messages from PTM were being propagated from Zebra daemon to clients (bgpd, ospfd and ospf6d). Now, both up and down messages are redistributed to the clients from zebra. BFD status field has been added to the messaging. Handling of BFD session up messages has been added to the client code. BGP/OSPF neighbor is brought down only if the old BFD session status is ‘Up’ to handle extra/initial down messages.
- BFD status and last update timestamp fields have been added to the common BFD info structure. Also, common show functions for showing BFD information have been added to BFD lib.
- Modified the BGP neighbor show functions to call common BFD lib functions.
- For ospf and ospf6, BFD information was maintained only at interface level. To show BFD status per neighbor, BFD information has been added at neighbor level too. “show ip ospf interface”, “show ip ospf neighbor detail”, “show ipv6 ospf6 interface” and “show ipv6 ospf6 neighbor detail” output have been modified to show BFD information.
CM-6952 - IBGP peers were always assumed to be multi-hop since there was no easy way to determine whether an IBGP peer was single hop or multihop unlike EBGP. But, this is causing problem with IBGP link local peers since BFD doesn't allow multihop BFD session with link local IP addresses. Link local peers were discovered when the interface peering was enabled. Interface peering is always singlehop. So, added checks to treat all interface based peers as single hop irrespective of whether the peer is IBGP or EBGP.
Ticket: CM-6520
Reviewed By: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed By: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-By: Morgan Stewart <morgan@cumulusnetworks.com>
Testing Done: Manual testing and smoketested
Whenever some sort of output is encountered, added a json version with
proper logic as well.
Allow configuration of faster OSPF convergence via the
min_ls_interval and min_ls_arrival timer lengths.
This patch was originated by Michael, and cross-ported
to Cumulus's Quagga.
Signed-off-by: Michael Rossberg <michael.rossberg@tu-ilmenau.de>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: Trivial
Reviewed by: Trivial
Testing: arm/powerpc/amd64 targets now build
Apparently we have a arm build. Who knew? This fixes the compile warnings/errors
produced when you compile a arm build with -Werror.
OSPF BFD command enhancement to configure BFD parameters (detect multiplier, min rx and min tx).
interface <if-name>
ip ospf bfd <detect mult> <min rx> <min tx>
This patch also adds BFD support for IPv6 OSPF. ospf6d will dynamically register/deregister IPv6 neighbors with BFD for monitoring the connectivity of the neighbor. Neighbor is registered with BFD when 2-way adjacency is established and deregistered when adjacency goes down if the BFD is enabled on the interface through which the neighbor was discovered.
OSPF6 BFD command added to configure BFD and parameters (detect multiplier, min rx and min tx).
interface <if-name>
ipv6 ospf6 bfd <detect mult> <min rx> <min tx>
Signed-off-by: Radhika Mahankali <radhika@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Kanna Rajagopal <kanna@cumulusnetworks.com>
This patch also adds BFD multihop support for BGP. Whether a peer is multi-hop or single hop is determined internally. All IGP peers are considered as multi-hop peers. EBGP peers are considered as single hop unless configured as multi-hop.
BGP BFD command enhancement to configure BFD parameters (detect multiplier, min rx and min tx).
router bgp <as-number>
neighbor <name/ip-address> bfd <detect mult> <min rx> <min tx>
Signed-off-by: Radhika Mahankali <radhika@cumulusnetworks.com>
Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Kanna Rajagopal <kanna@cumulusnetworks.com>
Table-id argument support wasnt complete, used the [proto, instance]
combination changes that were done for OSPF multi-instance. In this case
its 'table <table-id>' just like it was 'ospf <instance-id>'
ospfd: virtual links fix
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by:
Basically ZEBRA_INTERFACE_LINKDETECTION is set to on by default now.
Virtual links are failing to identify as up because of this code change.
Modify ospf to set the flag as appropriate
