Add the `IS-IS SRv6 SID Structure Sub-Sub-TLV Codepoint` as defined in the
`IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs` IANA registry. This codepoint
will be used as the Sub-Sub-TLV Type to advertise the SRv6 SID Structure
Sub-Sub-TLV in the SRv6 End SID, SRv6 End.X SID, and SRv6 LAN End.X SID
Sub-TLVs.
Add the `IS-IS SRv6 End SID Sub-TLV Codepoint` as defined in the
`IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability` IANA registry.
This codepoint will be used as the Sub-TLV
Type to advertise the SRv6 End SID Sub-TLV in the SRv6 Locator TLV.
Add a new TLV context value for the SRv6 Locator TLV. It will be needed
to support unpacking of the Sub-TLVs of the SRv6 Locator TLV in future
commits.
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.
projects / mirror / frr.git / log