When zebra assigns a chunk to IS-IS, zebra sends a
ZEBRA_SRV6_MANAGER_GET_LOCATOR_CHUNK notification to IS-IS.
IS-IS invokes the `isis_zebra_process_srv6_locator_chunk()` callback to
process the received notification.
Actually, `isis_zebra_process_srv6_locator_chunk()` iterates over all
areas of the current IS-IS instance and looks for an area for which the
received chunk was requested.
If a match is found, the new chunk is added to the area's chunk list and
`lsp_regenerate_schedule()` is called to regenerate the LSPs to
advertise the new SRv6 locator.
This commit extends the `isis_zebra_process_srv6_locator_chunk()`
function to automatically allocate an SRv6 End SID from the received
chunk and install it in the data plane.
The SRv6 End SID is the instantiation of a Prefix-SID (RFC 8986 section
In some cases, IS-IS may attempt to remove routes that have not been
installed before. We can prevent IS-IS from doing this by aborting
`isis_zebra_route_del_route` when the ISIS_ROUTE_FLAG_ZEBRA_SYNCED flag
is unset, meaning that the route is not installed in the kernel.
zebra: Resolve default values for SRv6 flavor attr
When zebra receives a Netlink message containing a seg6local nexthop,
let's use the default values for optional attributes `lcblock_len` and
`lcnode_fn_len`, if they are not specified.
zebra: Resolve default values for SRv6 flavor attr
When zebra receives a Netlink message containing a seg6local nexthop,
let's use the default values for optional attributes `lcblock_len` and
`lcnode_fn_len`, if they are not specified.
When installing a local SID in the Linux kernel, `lcblock_len` and
`lcnode_fn_len` Netlink attributes are optional. When omitted, the
kernel uses the default values: lcblock_len=32 and lcnode_fn_len=16.
Let's use the same default values in FRR.
`struct seg6local_context` contains a `struct seg6local_flavors_info`
that carries SRv6 flavors information. The `seg6local_flavors_info`
data structure contains a field `flv_ops` that indicates which flavors
are enabled for the `seg6local` nexthop. `flv_ops` is a bit-map where
each bit indicates if a particular SRv6 flavor is enabled (bit set to
1) or not (bit set to 0).
This commit defines some macros that can be used to manipulate the SRv6
flavors bit-map:
* CHECK_SRV6_FLV_OP(OPS,OP) - check if a particular flavor is enabled;
* SET_SRV6_FLV_OP(OPS,OP) - enable a particular flavor (OP);
* UNSET_SRV6_FLV_OP(OPS,OP) - disable a particular flavor (OP);
* RESET_SRV6_FLV_OP(OPS) - disable all SRv6 flavors.
The RFC 8986 defines the SRv6 Network Programming concept and specifies
the base set of SRv6 behaviors that enables the creation of
interoperable overlays with underlay optimization. In addition, the RFC
8986 introduces the concept of "flavors", additional operations that can
modify or extend the existing SRv6 behaviors.
In the Linux kernel and in FRR, an SRv6 SID is implemented as a route
associated with a `seg6local` nexthop. A `seg6local` nexthop represents
an SRv6 behavior bound to a SID.
The Linux kernel already supports the ability to add a set of flavors
to a `seg6local` nexthop to modify or extend the associated behavior.
This commit aligns the `seg6local` nexthop implementation of FRR to the
Linux kernel. It extends the `seg6local` nexthop implementation by
adding a struct `seg6local_flavors_info` that encodes the SRv6
flavors information.
Currently, the `seg6local_flavors_info` data structure has three
members:
- `tlv_ops` indicates which flavors are enabled for the `seg6local`
nexthop;
- `lcblock_len`is the length of the Locator-Block part of the SID;
- `lcnode_func_len` is the length of the combined Node and Function
parts of the SID.
`lcblock_len` and `lcnode_func_len` define the SID structure. They are
required for some behaviors (e.g. NEXT-C-SID and REPLACE-C-SID). For
other flavors (e.g. PSP, USP, USD) these parameters are not required and
can be omitted.
The RFC 8986 defines the SRv6 Network Programming concept and specifies
the base set of SRv6 behaviors that enables the creation of
interoperable overlays with underlay optimization. In addition, the RFC
8986 introduces the concept of "flavors", additional operations that can
modify or extend the existing SRv6 behaviors.
This commit adds a new enum type `seg6local_flavor_op` to represent the
SRv6 flavors operations. Currently we define the following flavor
operations:
- PSP (defined in RFC 8986 section #4.16.1)
- USP (defined in RFC 8986 section #4.16.2)
- USD (defined in RFC 8986 section #4.16.3)
- NEXT-C-SID (defined in draft-ietf-spring-srv6-srh-compression-03 #4.1)
Add a function to allocate an SRv6 SID from an SRv6 locator chunk owned
by IS-IS. The chunk must be allocated by a previous call to
`isis_zebra_srv6_manager_get_locator_chunk()`.
Add the list of SRv6 SIDs allocated by the IS-IS instance to the per-area
SRv6 configuration. The list is area-specific. Each IS-IS area has its
own SRv6 SIDs list. The list is initialized when an IS-IS area is
created and freed when an IS-IS area is destroyed.
Add `struct isis_srv6_sid_structure` data structure to represent an SRv6
SID structure (as defined in RFC 8986 section #3.1).
The struct has the following members:
* loc_block_len: locator block length
* loc_node_len: locator node length
* func_len: function length
* arg_len: argument length
Add `struct isis_srv6_sid` data structure to represent an SRv6 SID.
The struct has the following members:
* next: pointer to the next SID, used to build linked lists of SRv6 SIDs
* flags: SID flags
* behavior: the behavior bound to the SRv6 SID (as defined in RFC 8986)
* value: the SID value (i.e., an IPv6 address)
* locator: a backpointer to the parent locator from which the SID has
been allocated.
isisd: Add nb command to configure an SRv6 locator
Add a northbound command to configure an SRv6 locator for a specific
IS-IS area.
After configuring a locator, `isis_zebra_srv6_manager_get_locator_chunk`
is called to ask zebra to allocate a chunk from the configured locator.
The allocated chunk will be owned by IS-IS. IS-IS can allocate SIDs from
its chunk.
Currently, we support only one locator per-area. Therefore, before
configuring a locator we unset the previously configured locator, if
there was any.
Add a function to unset the SRv6 locator for a specific IS-IS area.
This function calls `isis_zebra_srv6_manager_release_locator_chunk()` to
ask zebra to release the locator chunk owned by IS-IS and removes the
chunk from the area's chunks list.
Add a callback function `isis_zebra_process_srv6_locator_delete()` that
is called when an SRv6 locator is deleted in zebra.
When an existing SRv6 locator is deleted in zebra, zebra sends a
ZEBRA_SRV6_LOCATOR_DELETE notification to all daemons informing them of
the deleted locator.
In IS-IS, we register the new `isis_zebra_process_srv6_locator_delete()`
callback as the handler for ZEBRA_SRV6_LOCATOR_DELETE.
This callback iterates over all areas of the current IS-IS instance and
looks for an area for which the deleted locator was configured.
If a match is found, we remove
the locator's chunks from the area's chunks list and call
`lsp_regenerate_schedule` to remove the locator from the SRv6 Locator
TLV advertised in the LSPs and regenerate the LSPs.
If no match is found, we do nothing.
isisd: Add func to process a received SRv6 locator
Add a callback function `isis_zebra_process_srv6_locator_add()` that is
called upon receiving an SRv6 locator from zebra.
When a new SRv6 locator is created in zebra, zebra sends a
ZEBRA_SRV6_LOCATOR_ADD notification to all daemons informing them of the
new locator.
In IS-IS, we register the new `isis_zebra_process_srv6_locator_add()`
callback as the handler for ZEBRA_SRV6_LOCATOR_ADD.
This callback iterates over all areas of the current IS-IS instance and
looks for an area for which the new locator was configured.
If a match is found, we call
`isis_zebra_srv6_manager_get_locator_chunk()` to ask zebra a chunk from
the locator.
If no match is found, we do nothing.
isisd: Add function to process received SRv6 chunk
Add a callback function that is called upon receiving an SRv6 locator
chunk from zebra.
This function iterates over all areas of the current IS-IS instance and
looks for an area for which the received chunk was requested.
If a match is found, the new chunk is added to the area's chunk list and
`lsp_regenerate_schedule()` is called to regenerate the LSPs to
advertise the new SRv6 locator.
If no match is found, we free the allocated resources and do nothing.
Add a list of SRv6 locator chunks allocated to a specific IS-IS area.
The list is initialized when the IS-IS area is created and freed when
the IS-IS area is destroyed. Subsequent commits will introduce the
possibility to allocate and release locator chunks.
isisd: Add SRv6 locator name to SRv6 configuration
Add the name of the SRv6 locator to use with IS-IS to the per-area SRv6
configuration. If an SRv6 locator is not configured for an IS-IS
instance, the locator name is an empty string. When an IS-IS instance is
configured to use an SRv6 locator, the locator name stores the name of
the selected locator.
Subsequent commits will add the possibility to set and unset an SRv6
locator for a specific IS-IS instance.
Add a CLI command to print SRv6 capabilities, algorithms and MSDs
supported by the IS-IS nodes.
Example:
r1# show isis segment-routing srv6 node
Area FOO:
IS-IS L1 SRv6-Nodes:
IS-IS L2 SRv6-Nodes:
System ID Algorithm SRH Max SL SRH Max End Pop SRH Max H.encaps SRH Max End D
-----------------------------------------------------------------------------------------
1111.1111.1111 SPF 16 0 1 2
2222.2222.2222 SPF 16 0 1 2
Update the `isis_router_cap_tlv_size` function to take into account the
SRv6 Capabilities Sub-TLV and SRv6-related MSDs when calculating the
size needed to pack the Router Capabilities TLV.
`isis_srv6_area_term()` cleans up SRv6 information for a specific
IS-IS area. This commit adds a new function `isis_srv6_term()` that will
be used to perform global SRv6 cleanup.
`isis_srv6_area_init()` initializes SRv6 information for a specific
IS-IS area. This commit adds a new function `isis_srv6_init()` that will
be used to perform global SRv6 initialization.
bgpd: Fix session reset issue caused by malformed core attributes
RCA:
On encountering any attribute error for core attributes in update message,
the error handling is set to 'treat as withdraw' and
further parsing of the remaining attributes is skipped.
But the stream pointer is not being correctly adjusted to
point to the next NLRI field skipping the rest of the attributes.
This leads to incorrect parsing of the NLRI field,
which causes BGP session to reset.
Fix:
The stream pointer offset is rightly adjusted to point to the NLRI field correctly
when the malformed attribute is encountered and remaining attribute parsing is skipped.
Signed-off-by: Samanvitha B Bhargav <bsamanvitha@vmware.com>
Donald Sharp [Mon, 31 Jul 2023 12:45:50 +0000 (08:45 -0400)]
tests: Convert d1 and d2 to output and expected in gen_json_diff_report
The output of gen_json_diff_report is used all over the place and
it outputs d1 and d2. Let's change this to output and expected
as that is how it is used. Should help with debugging.
Problem:
-------
- Send IGMP/MLD join and traffic.
LHR: (S,G) mroute is created with reference count = 2
and set the flag SRC_STREAM.
(Code flow: pim_mroute_msg_wholepkt -> pim_upstream_add,
pim_upstream_sg_running_proc -> pim_upstream_ref)
- Send IGMP/MLD prune.
LHR: removes (*,G) entry and it tries to remove childen (S,G) entries.
But (S,G) is having reference count = 2. So after prune,
(S,G) entry reference count becomes 1 and will be present
until KAT expires.
Fix:
---
Don't set SRC_STREAM flag for LHR.
In LHR, (S,G) should be maintained, until (*,G) is present.
When prune receives delete (*,G) and children (S,G).
When traffic stops, delete (S,G) after KAT expires.
Donald Sharp [Thu, 27 Jul 2023 19:36:33 +0000 (15:36 -0400)]
tests: Convert isis to use 1 and 10 for hello/multiplier
Current isis tests use a variety of hello timers as well
as hello-multiplier, let's modify all of the isis test
cases to use 1 and 10. This cleans up some spurious test
failures I was seeing locally. As an example without
these changes running isis_tilfa_topo1 2r6 times I would
see 5-10 test failures now I am seeing ~2 test failures.
In any event part of the problem was that some tests were
not fully converged when looking at them under heavy
system load. Changing this to 1/10 gives us 10 chances
to see the incoming packet.
Donald Sharp [Sat, 29 Jul 2023 17:26:26 +0000 (13:26 -0400)]
tests: bfd_bgp_cbit_topo3 allow bgp to converge before testing
This test was failing upstream a bunch of times. Upon examining
the log files as well as the test script it was noticed that
the bfd peers were checked to see that they had come up. But
both the timers used for bgp as well as not checking that bgp
has actually come up would cause the test to fail in subsuquent
steps if bgp has not come up. Test that bgp peering is actually
established before testing link down events. It's possible
this test might need to be revisited to ensure that the routes
are actually installed and ready to go before as well, but I am
not seeing that right now.
Donald Sharp [Sat, 29 Jul 2023 17:24:55 +0000 (13:24 -0400)]
tests: Fix zebra_seg6_route to give more time for routes to be installed
This test is failing upstream regularly, when inspecting the log
files we see that the route being looked for is in a queued state
when the test fails. Give this test more time for when the
system is under severe load.
Donald Sharp [Sat, 29 Jul 2023 17:22:39 +0000 (13:22 -0400)]
tests: isis_te_topo1 can fail occassionally
Upstream ( and locally ) this test fails. The adj-sid value
being looked for in the testing is a dynamic value that is
assigned based upon how the network comes up. The reality
is that there is no enforced order of what the adj-sid
can be. As such this test looking for this value makes
no sense. Let's remove that from the test.
Additionally bring the isis hello-interval to 1 down
from 3 to make things converge faster.
Donald Sharp [Fri, 28 Jul 2023 14:31:30 +0000 (10:31 -0400)]
tests: zebra_netlink ensure the address is installed
Ran test under high load and system rejected the sharp
install of routes. Only reason that that would happen
would be if the address had not been set by the kernel
yet. The test log files had timestamp precision and the
addition of the sharp routes was under 1/10 of a second
after the address was attempted to be installed.
Starting from step 11, this topotest focuses on validating the TI-LFA
switchover functionality, where the backup nexthops are activated
after an adjacency expires, either with or without BFD.
Currently, the test checks the RIB shortly after the switchover using
a tight 5 seconds interval to ensure that the RIB update is due to the
switchover and not an SPF update (which is configured with an initial
delay of 15 seconds). However, it was observed that the kernel might
take longer than 5 seconds to install routes when the system is under
heavy load. To account for that, double the wait interval so that
this topotest will succeed even in those conditions.
tests: ensure BFD session is up before proceeding to the next step
In this topotest, BFD is configured at the end of step 13. However,
in certain cases where the testing machine is exceptionally fast (e.g.,
Donald's quantum computer), there is a possibility that the interface
shutdown event from step 14 may occur before BFD has had sufficient
time to establish the session, which leads to a test failure. To fix
this problem, ensure the BFD session is up before proceeding to the
next step.
Node-SIDs refer to Prefix-SIDs associated with host prefixes of
loopback addresses. As such, whenever an interface address is added
or deleted, all configured Prefix-SIDs must be reevaluated to check
if the N-flag needs to be set or unset.
This change fixes some race conditions in the TI-LFA topotest where
specific sequence of events could cause Prefix-SIDs to not have the
N-flag set when they should, resulting in various failures.
projects / mirror / frr.git / log