When trying to track down a MTYPE_TMP memory leak
it's harder to search for it when you happen to
have some usage of ttable_dump. Let's just give
it it's own memory type so that we can avoid
confusion in the future.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If the link-params are set when the circuit not yet up, the link-params
are never updated.
isis_link_params_update() is called from isis_circuit_up() but returns
immediately because circuit->state != C_STATE_UP. circuit->state is
updated in isis_csm_state_change after isis_circuit_up().
> struct isis_circuit *isis_csm_state_change(enum isis_circuit_event event,
> struct isis_circuit *circuit,
> void *arg)
> {
> [...]
> if (isis_circuit_up(circuit) != ISIS_OK) {
> isis_circuit_deconfigure(circuit, area);
> break;
> }
> circuit->state = C_STATE_UP;
> isis_event_circuit_state_change(circuit, circuit->area,
> 1);
Do not return isis_link_params_update() if circuit->state != C_STATE_UP.
Fixes: 0fdd8b2b11 ("isisd: update link params after circuit is up")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The adj_process_threeway() api may call the adj_state_change()
api, which may delete the adj struct being examined. Change the
signature so that callers pass a ptr-to-ptr so that they will
see that deletion.
Signed-off-by: Mark Stapp <mjs@cisco.com>
Fixed the problem that physical interfaces can establish isis neighbor
relationships with vlan subinterfaces
Signed-off-by: JosiahMg <JosiahMg@163.com>
When an color affinity is set on an interface before configuring the
flex-algorithm, the ASLA (Application Specific Link-Attribute) sub-TLV
is not build. Flex-algo fails to build the paths when a affinity
constraint is required because of the lacking of information contained
in ASLA. There are no problems when the configuration order is reversed.
For example:
> affinity-map red bit-position 1
>
> interface eth2
> link-params
> affinity red
>
> router isis 1
> mpls-te on
> flex-algo 129
> dataplane sr-mpls
> advertise-definition
> affinity include-any green
In isis_link_params_update_asla(), the ASLA sub-TLV is not build when
the list of flex-algos is empty.
Update ASLA when the first flex-algorithm is configured.
Fixes: 893882ee20 ("isisd: add isis flex-algo configuration backend")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Move flex_algo_delete() content into isis_instance_flex_algo_destroy()
because it is called only once.
Rename _flex_algo_delete to flex_algo_free()
Cosmetic change.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
According to draft-ietf-lsr-isis-srv6-extensions draft,
the End SID should be available in link state prefix
information.
Add the SID information in the link state prefix, by
getting the END SID from the locator TLV information.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
1. When the root IS regenerates an LSP, it calls lsp_build() -> lsp_clear_data() to free the TLV memory of the first fragment and all other fragments. If the number of fragments in the regenerated LSP decreases or if no fragmentation is needed, the extra LSP fragments are not immediately deleted. Instead, lsp_seqno_update() -> lsp_purge() is called to set the remaining time to zero and start aging, while also notifying other IS nodes to age these fragments. lsp_purge() usually does not reset lsp->hdr.seqno to zero because the LSP might recover during the aging process.
2. When other IS nodes receive an LSP, they always call process_lsp() -> isis_unpack_tlvs() to allocate TLV memory for the LSP. This does not differentiate whether the received LSP has a remaining lifetime of zero. Therefore, it is rare for an LSP of a non-root IS to have empty TLVs. Of course, if an LSP with a remaining time of zero and already corrupted is received, lsp_update() -> lsp_purge() will be called to free the TLV memory of the LSP, but this scenario is rare.
3. In LFA calculations, neighbors of the root IS are traversed, and each neighbor is taken as a new root to compute the neighbor SPT. During this process, the old root IS will serve as a neighbor of the new root IS, triggering a call to isis_spf_process_lsp() to parse the LSP of the old root IS and obtain its IP vertices and neighboring IS vertices. However, isis_spf_process_lsp() only checks whether the TLVs in the first fragment of the LSP exist, and does not check the TLVs in the fragmented LSP. If the TLV memory of the fragmented LSP of the old root IS has been freed, it can lead to a null pointer access, causing the current crash.
Additionally, for the base SPT, there are only two places where the LSP of the root IS is parsed:
1. When obtaining the UP neighbors of the root IS via spf_adj_list_parse_lsp().
2. When preloading the IP vertices of the root IS via isis_lsp_iterate_ip_reach().
Both of these checks ensure that frag->tlvs is not null, and they do not subsequently call isis_spf_process_lsp() to parse the root IS's LSP. It is very rare for non-root IS LSPs to have empty TLVs unless they are corrupted LSPs awaiting deletion. If it happens, a crash will occur.
The backtrace is as follows:
(gdb) bt
#0 0x00007f3097281fe1 in raise () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f30973a2972 in core_handler (signo=11, siginfo=0x7ffce66c2870, context=0x7ffce66c2740) at ../lib/sigevent.c:261
#2 <signal handler called>
#3 0x000055dfa805512b in isis_spf_process_lsp (spftree=0x55dfa950eee0, lsp=0x55dfa94cb590, cost=10, depth=1, root_sysid=0x55dfa950ef6c "", parent=0x55dfa952fca0)
at ../isisd/isis_spf.c:898
#4 0x000055dfa805743b in isis_spf_loop (spftree=0x55dfa950eee0, root_sysid=0x55dfa950ef6c "") at ../isisd/isis_spf.c:1688
#5 0x000055dfa805784f in isis_run_spf (spftree=0x55dfa950eee0) at ../isisd/isis_spf.c:1808
#6 0x000055dfa8037ff5 in isis_spf_run_neighbors (spftree=0x55dfa9474440) at ../isisd/isis_lfa.c:1259
#7 0x000055dfa803ac17 in isis_spf_run_lfa (area=0x55dfa9477510, spftree=0x55dfa9474440) at ../isisd/isis_lfa.c:2300
#8 0x000055dfa8057964 in isis_run_spf_with_protection (area=0x55dfa9477510, spftree=0x55dfa9474440) at ../isisd/isis_spf.c:1827
#9 0x000055dfa8057c15 in isis_run_spf_cb (thread=0x7ffce66c38e0) at ../isisd/isis_spf.c:1889
#10 0x00007f30973bbf04 in thread_call (thread=0x7ffce66c38e0) at ../lib/thread.c:1990
#11 0x00007f309735497b in frr_run (master=0x55dfa91733c0) at ../lib/libfrr.c:1198
#12 0x000055dfa8029d5d in main (argc=5, argv=0x7ffce66c3b08, envp=0x7ffce66c3b38) at ../isisd/isis_main.c:273
(gdb) f 3
#3 0x000055dfa805512b in isis_spf_process_lsp (spftree=0x55dfa950eee0, lsp=0x55dfa94cb590, cost=10, depth=1, root_sysid=0x55dfa950ef6c "", parent=0x55dfa952fca0)
at ../isisd/isis_spf.c:898
898 ../isisd/isis_spf.c: No such file or directory.
(gdb) p te_neighs
$1 = (struct isis_item_list *) 0x120
(gdb) p lsp->tlvs
$2 = (struct isis_tlvs *) 0x0
(gdb) p lsp->hdr
$3 = {pdu_len = 27, rem_lifetime = 0, lsp_id = "\000\000\000\000\000\001\000\001", seqno = 4, checksum = 59918, lsp_bits = 1 '\001'}
The backtrace provided above pertains to version 8.5.4, but it seems that the same issue exists in the code of the master branch as well.
I have reviewed the process for calculating the SPT based on the LSP, and isis_spf_process_lsp() is the only function that does not check whether the TLVs in the fragments are empty. Therefore, I believe that modifying this function alone should be sufficient. If the TLVs of the current fragment are already empty, we do not need to continue processing subsequent fragments. This is consistent with the behavior where we do not process fragments if the TLVs of the first fragment are empty.
Of course, one could argue that lsp_purge() should still retain the TLV memory, freeing it and then reallocating it if needed. However, this is a debatable point because in some scenarios, it is permissible for the LSP to have empty TLVs. For example, after receiving an SNP (Sequence Number PDU) message, an empty LSP (with lsp->hdr.seqno = 0) might be created by calling lsp_new. If the corresponding LSP message is discarded due to domain or area authentication failure, the TLV memory wouldn't be allocated.
Test scenario:
In an LFA network, importing a sufficient number of static routes to cause LSP fragmentation, and then rolling back the imported static routes so that the LSP is no longer fragmented, can easily result in this issue.
Signed-off-by: zhou-run <zhou.run@h3c.com>
1. The lsp_update_data() function will check for the presence of the ISIS_TLV_DYNAMIC_HOSTNAME in the LSP, and then call isis_dynhn_insert() to add a hostname entry corresponding to the LSP ID. However, when the ISIS_TLV_DYNAMIC_HOSTNAME is not present in the LSP, the hostname entry corresponding to the LSP ID should also be deleted.
2. The command “show isis neighbor” invokes isis_adj_name() to display the System ID or hostname, but it does not check the area->dynhostname flag.
3. When the LSP expires and is removed, the corresponding hostname entry should also be deleted.
4. The TLV for LSP fragmentation will not contain the hostname and should be skipped.
Signed-off-by: zhou-run <zhou.run@h3c.com>
When a neighbor connection is disconnected, it may trigger LSP re-generation as a timer task, but this process may be delayed. As a result, the list of neighbors in area->adjacency_list may be inconsistent with the neighbors in lsp->tlvs->oldstyle_reach/extended_reach. For example, the area->adjacency_list may lack certain neighbors even though they are present in the LSP. When computing SPF, the call to isis_spf_build_adj_list() generates the spftree->sadj_list, which reflects the real neighbors in the area->adjacency_list. However, in the case of LAN links, spftree->sadj_list may include additional pseudo neighbors.
The pre-loading of tents through the call to isis_spf_preload_tent involves two steps:
1. isis_spf_process_lsp() is called to generate real neighbor vertices based on the root LSP and pseudo LSP.
2. isis_spf_add_local() is called to add corresponding next hops to the vertex->Adj_N list for the real neighbor vertices.
In the case of LAN links, the absence of corresponding real neighbors in the spftree->sadj_list prevents the execution of the second step. Consequently, the vertex->Adj_N list for the real neighbor vertices lacks corresponding next hops. This leads to a null pointer access when isis_lfa_compute() is called to calculate LFA.
As for P2P links, since there are no pseudo neighbors, only the second step is executed, which does not create real neighbor vertices and therefore does not encounter this issue.
The backtrace is as follows:
(gdb) bt
#0 0x00007fd065277fe1 in raise () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007fd065398972 in core_handler (signo=11, siginfo=0x7ffc5c0636b0, context=0x7ffc5c063580) at ../lib/sigevent.c:261
#2 <signal handler called>
#3 0x00005564d82f8408 in isis_lfa_compute (area=0x5564d8b143f0, circuit=0x5564d8b21d10, spftree=0x5564d8b06bf0, resource=0x7ffc5c064410) at ../isisd/isis_lfa.c:2134
#4 0x00005564d82f8d78 in isis_spf_run_lfa (area=0x5564d8b143f0, spftree=0x5564d8b06bf0) at ../isisd/isis_lfa.c:2344
#5 0x00005564d8315964 in isis_run_spf_with_protection (area=0x5564d8b143f0, spftree=0x5564d8b06bf0) at ../isisd/isis_spf.c:1827
#6 0x00005564d8315c15 in isis_run_spf_cb (thread=0x7ffc5c064590) at ../isisd/isis_spf.c:1889
#7 0x00007fd0653b1f04 in thread_call (thread=0x7ffc5c064590) at ../lib/thread.c:1990
#8 0x00007fd06534a97b in frr_run (master=0x5564d88103c0) at ../lib/libfrr.c:1198
#9 0x00005564d82e7d5d in main (argc=5, argv=0x7ffc5c0647b8, envp=0x7ffc5c0647e8) at ../isisd/isis_main.c:273
(gdb) f 3
#3 0x00005564d82f8408 in isis_lfa_compute (area=0x5564d8b143f0, circuit=0x5564d8b21d10, spftree=0x5564d8b06bf0, resource=0x7ffc5c064410) at ../isisd/isis_lfa.c:2134
2134 ../isisd/isis_lfa.c: No such file or directory.
(gdb) p vadj_primary
$1 = (struct isis_vertex_adj *) 0x0
(gdb) p vertex->Adj_N->head
$2 = (struct listnode *) 0x0
(gdb) p (struct isis_vertex *)spftree->paths->l.list->head->next->next->next->next->data
$8 = (struct isis_vertex *) 0x5564d8b5b240
(gdb) p $8->type
$9 = VTYPE_NONPSEUDO_TE_IS
(gdb) p $8->N.id
$10 = "\000\000\000\000\000\002"
(gdb) p $8->Adj_N->count
$11 = 0
(gdb) p (struct isis_vertex *)spftree->paths->l.list->head->next->next->next->next->next->data
$12 = (struct isis_vertex *) 0x5564d8b73dd0
(gdb) p $12->type
$13 = VTYPE_NONPSEUDO_TE_IS
(gdb) p $12->N.id
$14 = "\000\000\000\000\000\003"
(gdb) p $12->Adj_N->count
$15 = 0
(gdb) p area->adjacency_list->count
$16 = 0
The backtrace provided above pertains to version 8.5.4, but it seems that the same issue exists in the code of the master branch as well.
The scenario where a vertex has no next hop is normal. For example, the "clear isis neighbor" command invokes isis_vertex_adj_del() to delete the next hop of a vertex. Upon reviewing all the instances where the vertex->Adj_N list is used, I found that only isis_lfa_compute() lacks a null check. Therefore, I believe that modifying this part will be sufficient. Additionally, the vertex->parents list for IP vertices is guaranteed not to be empty.
Test scenario:
Setting up LFA for LAN links and executing the "clear isis neighbor" command easily reproduces the issue.
Signed-off-by: zhou-run <zhou.run@h3c.com>
d5879267aa ("isisd: fix show database json format") renamed JSON keys to
a standard format but forgot to rename the neighbor-id key.
Fixes: d5879267aa ("isisd: fix show database json format")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The variable flags_json was incorrectly named, leading to confusion and
causing the bug fixed in the previous commit.
Rename the variable to refer to SRv6 End SID instead. Cosmetic change.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The json format for json routes should be compliant with caml format.
Before:
> "Prefix|Metric|Interface|Nexthop|SID|LabelOp|Algo":
> "Prefix|Metric|Interface|Nexthop|Label(s)");
After:
> "prefix|metric|interface|nextHop|segmentIdentifier|labelOperation|Algorithm":
> "prefix|metric|interface|nextHop|label(s)");
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The command "show isis topology" calls print_sys_hostname() to display the system ID or hostname, but it does not check the area->dynhostname flag.
Signed-off-by: zhou-run <zhou.run@h3c.com>
In the near future, some daemons may only register SIDs. This may be
the case for the pathd daemon when creating SRv6 binding SIDs.
When a locator is getting deleted at ZEBRA level, the daemon may have
an easy way to find out the SIds to unregister to.
This commit proposes to add the locator name to the SID_SRV6_NOTIFY
message whenever possible. Only case when an allocation failure happens,
the locator will not be present. In all other places, the notify API
at procol levels has the locator name extra-parameter.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Zebra sends a SRV6_SID_NOTIFY notification to inform clients about the
result of a SID alloc/release operation. This commit adds a handler to
process a SRV6_SID_NOTIFY notification received from zebra.
If the notification indicates that a SID allocation operation was
successful, then it stores the allocated SID in the SRv6 database,
installs the SID into the RIB, and advertises the SID to the other IS-IS
routers.
If the notification indicates that an operation has failed, it logs the
error.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Currently, IS-IS allocates SIDs without interacting with Zebra.
Recently, the SRv6 implementation has been improved. Now, the daemons
need to interact with Zebra through ZAPI to obtain and release SIDs.
This commit extends IS-IS to release SIDs to Zebra when they are no
longer needed.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Currently, IS-IS allocates SIDs without interacting with Zebra.
Recently, the SRv6 implementation has been improved. Now, the daemons
need to interact with Zebra through ZAPI to obtain and release SIDs.
This commit extends IS-IS to request SIDs from Zebra instead of
allocating the SIDs on its own.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
This commit extends IS-IS to process locator information received from
SRv6 Manager (zebra) and save the locator info in the SRv6 database.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Currently, when SRv6 is enabled in IS-IS, IS-IS requests a locator chunk
from Zebra. Zebra assigns a locator chunk to IS-IS, and then IS-IS can
allocate SIDs from the locator chunk.
Recently, the implementation of SRv6 in Zebra has been improved, and a
new API has been introduced for obtaining/releasing the SIDs.
Now, the daemons no longer need to request a chunk.
Instead, the daemons interact with Zebra to obtain information about the
locator and subsequently to allocate/release the SIDs.
This commit extends IS-IS to use the new SRv6 API. In particular, it
removes the chunk throughout the IS-IS code and modifies IS-IS to
request/save/advertise the locator instead of the chunk.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Add an API to request information from the SRv6 SID Manager (zebra)
regarding a specific SRv6 locator.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
1. Router A is configured with "is-type level-1-2", while Router B is configured with "is-type level-1". Only level 1 neighbor entries are present on Router A.
2. After configuring Router B with "is-type level-2-only", both level 1 and level 2 neighbor entries exist on Router A. The state of these entries is UP, and the level 1 neighbor entry is currently aging.
3. Before the level 1 neighbor entry on Router A ages out, configuring Router B with "is-type level-1", both level 1 and level 2 neighbor entries exist on Router A. The level 2 neighbor entry is UP and will age out normally. However, the level 1 neighbor entry remains in the Initializing state, preventing the establishment of level 1 neighbor adjacency between Router A and Router B.
When the adjacency type of the link is switched in function isis_circuit_is_type_set, the function circuit_resign_level() is called to delete the old level's circuit->u.bc.lan_neighs linked list. If the old level is not level-1-2, the function circuit_commence_level() is called to create a new level's circuit->u.bc.lan_neighs linked list, but neither of these functions handle the circuit->u.bc.adjdb linked list. This leads to a situation where upon receiving hello packets again before the circuit->u.bc.adjdb linked list entries age out, the circuit->u.bc.lan_neighs linked list is not constructed based on the circuit->u.bc.adjdb linked list. As a result, the hello packets sent will consistently lack an SNPA, causing the neighbor to remain unable to establish an adjacency upon receiving the hello packets.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
1. When the command "no <ip|ipv6> router isis WORD" is executed on the interface, it invokes list_delete_all_node to iterate and release the memory of all nodes in the cirtcuit->u.bc.adjdb[1] linked list. However, the nodes are not unlinked during this traversal process, leading to the call of *list->del to delete the data of the linked list nodes.
2. For ISIS, deleting the data of the linked list nodes is done by calling isis_delete_adj. Subsequently, isis_level2_adj_up will be called to iterate and query the cirtcuit->u.bc.adjdb[1] linked list. If there are many neighbors on this interface, accessing the memory of the released linked list nodes may occur.
3. Not limited to ISIS, if the linked list is not unlinked during the deletion of all nodes in process 1, *list->del should not be allowed to iterate through the list again.
The backtrace is as follows:
(gdb) bt
at isisd/isis_csm.c:196
context=<optimized out>) at lib/northbound.c:1131
errmsg_len=errmsg_len@entry=8192) at lib/northbound.c:1356
at lib/northbound.c:1473
errmsg=errmsg@entry=0x7ffc0ced38d0 "", errmsg_len=errmsg_len@entry=8192) at lib/northbound.c:906
comment=comment@entry=0x0, transaction_id=transaction_id@entry=0x0, errmsg=errmsg@entry=0x7ffc0ced38d0 "", errmsg_len=8192) at lib/northbound.c:938
filter=FILTER_RELAXED) at lib/command.c:971
at lib/command.c:1030
vtysh=vtysh@entry=0) at lib/command.c:1198
at isisd/isis_csm.c:196
context=<optimized out>) at lib/northbound.c:1131
errmsg_len=errmsg_len@entry=8192) at lib/northbound.c:1356
at lib/northbound.c:1473
errmsg=errmsg@entry=0x7ffc0ced38d0 "", errmsg_len=errmsg_len@entry=8192) at lib/northbound.c:906
comment=comment@entry=0x0, transaction_id=transaction_id@entry=0x0, errmsg=errmsg@entry=0x7ffc0ced38d0 "", errmsg_len=8192) at lib/northbound.c:938
filter=FILTER_RELAXED) at lib/command.c:971
at lib/command.c:1030
vtysh=vtysh@entry=0) at lib/command.c:1198
0 0x00007f7d6e541fe1 in raise () from /lib/x86_64-linux-gnu/libpthread.so.0
1 0x00007f7d6e63188c in core_handler (signo=11, siginfo=0x7ffc0ced2630, context=<optimized out>) at lib/sigevent.c:262
2 <signal handler called>
3 0x00005647f5b11568 in isis_level2_adj_up (area=area@entry=0x5647f7c89830) at isisd/isis_lsp.c:423
4 0x00005647f5b14073 in isis_reset_attach_bit (adj=0x5647f7cad690) at isisd/isis_lsp.c:474
5 lsp_handle_adj_state_change (adj=0x5647f7cad690) at isisd/isis_lsp.c:2162
6 0x00005647f5b53675 in hook_call_isis_adj_state_change_hook (adj=adj@entry=0x5647f7cad690) at isisd/isis_adjacency.c:152
7 0x00005647f5b536f3 in isis_delete_adj (arg=0x5647f7cad690) at isisd/isis_adjacency.c:167
8 0x00007f7d6e5fe003 in list_delete_all_node (list=0x5647f7c88060) at lib/linklist.c:316
9 0x00007f7d6e5fe069 in list_delete (list=list@entry=0x5647f7c84708) at lib/linklist.c:326
10 0x00005647f5b0872e in isis_circuit_down (circuit=0x5647f7c84620) at isisd/isis_circuit.c:835
11 0x00005647f5b09f81 in isis_csm_state_change (event=event@entry=IF_DOWN_FROM_Z, circuit=circuit@entry=0x5647f7c84620, arg=arg@entry=0x5647f7c7f7a0)
at isisd/isis_csm.c:196
12 0x00005647f5b083b0 in isis_circuit_disable (circuit=0x5647f7c84620) at isisd/isis_circuit.c:100
13 isis_circuit_del (circuit=0x5647f7c84620) at isisd/isis_circuit.c:200
14 0x00005647f5b434f5 in lib_interface_isis_destroy (args=<optimized out>) at isisd/isis_nb_config.c:2612
15 0x00007f7d6e61347a in nb_callback_destroy (errmsg_len=2, errmsg=0x7ffc0ced38d0 "", dnode=0x5647f7c948f0, event=NB_EV_APPLY, nb_node=<optimized out>,
context=<optimized out>) at lib/northbound.c:1131
16 nb_callback_configuration (context=<optimized out>, event=event@entry=NB_EV_APPLY, change=change@entry=0x5647f7cb6680, errmsg=errmsg@entry=0x7ffc0ced38d0 "",
errmsg_len=errmsg_len@entry=8192) at lib/northbound.c:1356
17 0x00007f7d6e6138b7 in nb_transaction_process (errmsg_len=8192, errmsg=0x7ffc0ced38d0 "", transaction=0x5647f7c94080, event=NB_EV_APPLY)
at lib/northbound.c:1473
18 nb_candidate_commit_apply (transaction=0x5647f7c94080, save_transaction=save_transaction@entry=true, transaction_id=transaction_id@entry=0x0,
errmsg=errmsg@entry=0x7ffc0ced38d0 "", errmsg_len=errmsg_len@entry=8192) at lib/northbound.c:906
19 0x00007f7d6e61403d in nb_candidate_commit (context=context@entry=0x7ffc0ced38c0, candidate=<optimized out>, save_transaction=save_transaction@entry=true,
comment=comment@entry=0x0, transaction_id=transaction_id@entry=0x0, errmsg=errmsg@entry=0x7ffc0ced38d0 "", errmsg_len=8192) at lib/northbound.c:938
20 0x00007f7d6e616ec9 in nb_cli_classic_commit (vty=0x5647f7cae160) at lib/northbound_cli.c:64
21 0x00007f7d6e6176a8 in nb_cli_apply_changes (vty=0x5647f7cae160, xpath_base_fmt=<optimized out>) at lib/northbound_cli.c:268
22 0x00007f7d6e5d918e in cmd_execute_command_real (vline=vline@entry=0x5647f7cae140, vty=vty@entry=0x5647f7cae160, cmd=cmd@entry=0x0, up_level=up_level@entry=0,
filter=FILTER_RELAXED) at lib/command.c:971
23 0x00007f7d6e5d951d in cmd_execute_command (vline=vline@entry=0x5647f7cae140, vty=vty@entry=0x5647f7cae160, cmd=cmd@entry=0x0, vtysh=vtysh@entry=0)
at lib/command.c:1030
24 0x00007f7d6e5d9770 in cmd_execute (vty=vty@entry=0x5647f7cae160, cmd=cmd@entry=0x5647f7cb48a0 "no ip router isis 10", matched=matched@entry=0x0,
vtysh=vtysh@entry=0) at lib/command.c:1198
25 0x00007f7d6e6485e6 in vty_command (vty=vty@entry=0x5647f7cae160, buf=0x5647f7cb48a0 "no ip router isis 10") at lib/vty.c:483
26 0x00007f7d6e648d01 in vty_execute (vty=vty@entry=0x5647f7cae160) at lib/vty.c:1246
27 0x00007f7d6e64ba40 in vtysh_read (thread=<optimized out>) at lib/vty.c:2090
28 0x00007f7d6e64348d in thread_call (thread=thread@entry=0x7ffc0ced8310) at lib/thread.c:1958
29 0x00007f7d6e5fd4a8 in frr_run (master=0x5647f79a43d0) at lib/libfrr.c:1184
30 0x00005647f5b050f3 in main (argc=5, argv=<optimized out>, envp=<optimized out>) at isisd/isis_main.c:273
(gdb) f 3
423 isisd/isis_lsp.c: No such file or directory.
(gdb) p node
$1 = (struct listnode *) 0x110
(gdb) f 8
316 lib/linklist.c: No such file or directory.
(gdb) p list->head->data
$2 = (void *) 0x5647f7cabf20
(gdb) p list->head->next->data
$3 = (void *) 0x5647f7c9bb60
(gdb) p list->head->next->next->data
Cannot access memory at address 0x120
(gdb) p list->head->next->next
$4 = (struct listnode *) 0x110
The backtrace provided above pertains to version 8.2.2, but it seems that the same issue exists in the code of the master branch as well.
isis_reset_attach_bit() is useless because lsp_handle_adj_state_change() unconditionally calls lsp_regenerate_schedule.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
The IPv4 directly connected route prefix exists in both the root LSP and the root's neighbor LSP:
1. When generating vertices for directly connected route prefixes with a metric of 0 based on the root LSP, the isis_spf_preload_tent_ip_reach_cb function only generates vertices of type VTYPE_IPREACH_INTERNAL without distinguishing between area->oldmetric and area->newmetric.
2. When generating vertices for the directly connected route prefix based on the neighbor LSP, the isis_spf_process_lsp function will generate vertices of type VTYPE_IPREACH_INTERNAL and VTYPE_IPREACH_TE based on area->oldmetric and area->newmetric, where the vertex metric is the sum of the metric from the root IS to the neighbor IS and from the neighbor IS to the root IS, respectively.
If area->newmetric=1, the same directly connected route prefix will have both VTYPE_IPREACH_INTERNAL vertices with a metric of 0 and VTYPE_IPREACH_TE vertices with a non-zero metric. During route generation, the isis_spf_loop function will prioritize selecting VTYPE_IPREACH_TE vertices, leading to incorrect metrics for the directly connected routes.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
fix frrbot styling issues found.
1）fix frrbot styling issues found.
2）Roll back the modifications to TE.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
Maintain code factorization and avoid duplicating code.
Maintain code factorization and avoid duplicating code.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: fix frrbot styling issues found
fix frrbot styling issues found
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: fix frrbot styling issues found
fix frrbot styling issues found
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: Resolve compilation issues.
Resolve compilation issues.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: Resolve compilation issues.
Resolve compilation issues.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: fix frrbot styling issues found
fix frrbot styling issues found
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: fix frrbot styling issues found
fix frrbot styling issues found
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: Resolve compilation issues.
Resolve compilation issues.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
When clearing the net in one of the areas, the system ID is unconditionally cleared, even if the net does not include the current system ID.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: When operating multiple areas, the system ID behaves abnormally.
When deleting one of the areas, even if the net under the area includes the current system ID, the system ID still remains.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: fix frrbot styling issues found
fix frrbot styling issues found
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: fix frrbot styling issues found
fix frrbot styling issues found
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: Resolve compilation issues.
The higher version updates 'struct area_addr' to 'struct iso_address'.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
isisd: fix frrbot styling issues found
fix frrbot styling issues found
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
"show isis database [detail] json" returns invalid or incorrect JSON
that is difficult to parse.
Fix key with '-' characters, add booleans and null data when possible.
Deprecate the old format.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When a level is not present in show isis database detail json, {} is
displayed.
Display nothing for non present level.
Fixes: a2cac12a63 ("isisd: Add json to show isis database command.")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix display of srv6 subsubtlvs
Fixes: 648a158802 ("isisd: Add SRv6 End.X SID to Sub-TLV format func")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Only the MT ID is displayed.
Display the MT description as well.
Fixes: a2cac12a63 ("isisd: Add json to show isis database command.")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Some keys are wrongly displayed at the JSON parent level.
Add the key at the current level.
Fixes: a2cac12a63 ("isisd: Add json to show isis database command.")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Multiple occurrences of the same (sub-)TLVs are mixed into a single JSON
object. Last values replaces the previous.
Display all the occurrences in an array for the following (sub-)TLVs:
- is-reach
- ip-reach
- ext-reach
- ext-ip-reach
- ipv6-reach
- MT
- prefix-SID
Fixes: a2cac12a63 ("isisd: Add json to show isis database command.")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Display information about a particular router in show isis database in
an single value array for compatibility with the display of all routers.
Fixes: a2cac12a63 ("isisd: Add json to show isis database command.")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When receiving a hello packet, if the neighbor state transitions directly from a non-ISIS_ADJ_UP state (such as ISIS_ADJ_INITIALIZING) to ISIS_ADJ_DOWN state, the neighbor entry cannot be deleted. If the neighbor is removed or the neighbor's System ID changes, it may result in memory leakage in the neighbor entry.
Test Scenario:
LAN link between Router A and Router B is established. Router A does not configure neighbor authentication, while Router B is configured with neighbor authentication. When the neighbor entry on Router B ages out, the neighbor state on Router A transitions to INIT. If Router B is then removed, the neighbor state on Router A transitions to DOWN and persists.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
fix frrbot styling issues found.
fix frrbot styling issues found.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
Fix crash with "show isis route algorithm X" command.
Fixes: 88e368b4dc ("isisd: make optional algorithm id in 'show isis route'")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
> ==2334217==ERROR: AddressSanitizer: heap-use-after-free on address 0x61000001d0a0 at pc 0x563828c8de6f bp 0x7fffbdaee560 sp 0x7fffbdaee558
> READ of size 1 at 0x61000001d0a0 thread T0
> #0 0x563828c8de6e in prefix_sid_cmp isisd/isis_spf.c:187
> #1 0x7f84b8204f71 in hash_get lib/hash.c:142
> #2 0x7f84b82055ec in hash_lookup lib/hash.c:184
> #3 0x563828c8e185 in isis_spf_prefix_sid_lookup isisd/isis_spf.c:209
> #4 0x563828c90642 in isis_spf_add2tent isisd/isis_spf.c:598
> #5 0x563828c91cd0 in process_N isisd/isis_spf.c:824
> #6 0x563828c93852 in isis_spf_process_lsp isisd/isis_spf.c:1041
> #7 0x563828c98dde in isis_spf_loop isisd/isis_spf.c:1821
> #8 0x563828c998de in isis_run_spf isisd/isis_spf.c:1983
> #9 0x563828c99c7b in isis_run_spf_with_protection isisd/isis_spf.c:2009
> #10 0x563828c9a60d in isis_run_spf_cb isisd/isis_spf.c:2090
> #11 0x7f84b835c72d in event_call lib/event.c:2011
> #12 0x7f84b8236d93 in frr_run lib/libfrr.c:1217
> #13 0x563828c21918 in main isisd/isis_main.c:346
> #14 0x7f84b7e4fd09 in __libc_start_main ../csu/libc-start.c:308
> #15 0x563828c20df9 in _start (/usr/lib/frr/isisd+0xf5df9)
>
> 0x61000001d0a0 is located 96 bytes inside of 184-byte region [0x61000001d040,0x61000001d0f8)
> freed by thread T0 here:
> #0 0x7f84b88a9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123
> #1 0x7f84b8263bae in qfree lib/memory.c:130
> #2 0x563828c8e433 in isis_vertex_del isisd/isis_spf.c:249
> #3 0x563828c91c95 in process_N isisd/isis_spf.c:811
> #4 0x563828c93852 in isis_spf_process_lsp isisd/isis_spf.c:1041
> #5 0x563828c98dde in isis_spf_loop isisd/isis_spf.c:1821
> #6 0x563828c998de in isis_run_spf isisd/isis_spf.c:1983
> #7 0x563828c99c7b in isis_run_spf_with_protection isisd/isis_spf.c:2009
> #8 0x563828c9a60d in isis_run_spf_cb isisd/isis_spf.c:2090
> #9 0x7f84b835c72d in event_call lib/event.c:2011
> #10 0x7f84b8236d93 in frr_run lib/libfrr.c:1217
> #11 0x563828c21918 in main isisd/isis_main.c:346
> #12 0x7f84b7e4fd09 in __libc_start_main ../csu/libc-start.c:308
>
> previously allocated by thread T0 here:
> #0 0x7f84b88aa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
> #1 0x7f84b8263a6c in qcalloc lib/memory.c:105
> #2 0x563828c8e262 in isis_vertex_new isisd/isis_spf.c:225
> #3 0x563828c904db in isis_spf_add2tent isisd/isis_spf.c:588
> #4 0x563828c91cd0 in process_N isisd/isis_spf.c:824
> #5 0x563828c93852 in isis_spf_process_lsp isisd/isis_spf.c:1041
> #6 0x563828c98dde in isis_spf_loop isisd/isis_spf.c:1821
> #7 0x563828c998de in isis_run_spf isisd/isis_spf.c:1983
> #8 0x563828c99c7b in isis_run_spf_with_protection isisd/isis_spf.c:2009
> #9 0x563828c9a60d in isis_run_spf_cb isisd/isis_spf.c:2090
> #10 0x7f84b835c72d in event_call lib/event.c:2011
> #11 0x7f84b8236d93 in frr_run lib/libfrr.c:1217
> #12 0x563828c21918 in main isisd/isis_main.c:346
> #13 0x7f84b7e4fd09 in __libc_start_main ../csu/libc-start.c:308
>
> SUMMARY: AddressSanitizer: heap-use-after-free isisd/isis_spf.c:187 in prefix_sid_cmp
> Shadow bytes around the buggy address:
> 0x0c207fffb9c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
> 0x0c207fffb9d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
> 0x0c207fffb9e0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
> 0x0c207fffb9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
> 0x0c207fffba00: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
> =>0x0c207fffba10: fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd fa
> 0x0c207fffba20: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
> 0x0c207fffba30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
> 0x0c207fffba40: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
> 0x0c207fffba50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
> 0x0c207fffba60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
> Addressable: 00
> Partially addressable: 01 02 03 04 05 06 07
> Heap left redzone: fa
> Freed heap region: fd
> Stack left redzone: f1
> Stack mid redzone: f2
> Stack right redzone: f3
> Stack after return: f5
> Stack use after scope: f8
> Global redzone: f9
> Global init order: f6
> Poisoned by user: f7
> Container overflow: fc
> Array cookie: ac
> Intra object redzone: bb
> ASan internal: fe
> Left alloca redzone: ca
> Right alloca redzone: cb
> Shadow gap: cc
> ==2334217==ABORTING
Fixes: 2f7cc7bcd3 ("isisd: detect Prefix-SID collisions and handle them appropriately")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
1. When both Router A and Router B are configured with "is-type level-1," the area->is_type will be assigned the value IS_LEVEL_1, and circuit->is_type will also be assigned the value IS_LEVEL_1.
2. Configuring the circuit type "isis circuit-type level-1-2" for the interface of Router A will inadvertently call lib_interface_isis_circuit_type_modify to assign circuit->is_type the value IS_LEVEL_1_AND_2. This causes the hello packets reception and transmission, as well as the reception of LSP/SNP packets, to check circuit->is_type, allowing the level-2 hello packets to be sent and received normally, and level-2 LSP/SNP packets to be received normally.
3. When Router B modifies the configuration to "is-type level-2," and Router A and Router B establish a level-2 neighbor relationship, Router B sends level-2 LSP packets to Router A. Upon receiving these, Router A calls isis_spf_schedule to calculate the level-2 SPT, which results in accessing a null pointer.
When defining the behavior of the ISIS router, the call to isis_area_is_type_set will check that area->is_type is not IS_LEVEL_1_AND_2, and it disallows circuit->is_type_config from overriding circuit->is_type. Therefore, when configuring the circuit type for the interface of Router A, it should also check that area->is_type is not IS_LEVEL_1_AND_2 and disallow circuit->is_type_config from overriding circuit->is_type.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
If you had a situation where an operator turned on
ospfd with snmp but not ospf6d and agentx was configured
then you get into a situation where ospf6d would complain
that the config for agentx did not exist. Let's modify
the code to allow this situation to happen.
Fixes: #15896
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The current json display lost a lot of LSPs, added them.
Fixed the json format for two commands:
"show isis database detail json"
"show isis database json"
Signed-off-by: anlan_cs <anlan_cs@tom.com>
Before:
```
anlan# show isis neighbor
Area xx:
System Id Interface L State Holdtime SNPA
0023.0000.0000 enp1s0 2 Down Expiring2c53.4a30.0820
```
After:
```
anlan# show isis neighbor
Area xx:
System Id Interface L State Holdtime SNPA
0023.0000.0000 enp1s0 2 Down Expiring 2c53.4a30.0820
```
The `-` display format caused by no hello packet in `isis_adj_print_vty()`
is same as that of above "Expiring".
Signed-off-by: anlan_cs <anlan_cs@tom.com>
The define has inheritated from a wrong naming in sr-mpls.
Fix this by renaming ISIS_SRV6_LAN_BACKUP to ISIS_SRV6_ADJ_BACKUP.
Fixes: 2566656a6f ("isisd: Add data structure for SRv6 Adjacency SIDs")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
isisd/isis_spf.c: In function ‘show_isis_route_common’:
isisd/isis_spf.c:3034:39: warning: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 2 [-Wformat-truncation=]
snprintf(key, sizeof(key), "level-%d", level);
^~
isisd/isis_spf.c:3034:32: note: directive argument in the range [1, 2147483646]
snprintf(key, sizeof(key), "level-%d", level);
^~~~~~~~~~
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The hold time filled in the hello packets of a P2P link is calculated based on the level 1 configuration, while the hello timer is based on the level 2 configuration. If the hello interval times in level 1 and level 2 configurations are inconsistent, it may lead to neighbor establishment failure.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
The ISIS_SR_LAN_BACKUP should be renamed to ISIS_SR_ADJ_BACKUP.
Fixes: 26f6acafc3 ("isisd: add support for segment routing")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Don't allocate subtlvs container if there's nothing to add to it. If the
container is allocated, the "sub-TLVs presence" bit is set in the TLVs
even if there's no actual sub-TLVs, what violates the RFC.
Fixes#14514.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The following two isis commands have now the algorithm id
optional:
> # show isis segment-routing node algorithm
> # show isis topology algorithm
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When walking over all the flex-algorithm routes, it is
difficult to know which route is associated to which
algorithm: add "algorithm" attribute to the json object.
Output example:
> ubuntu2004(config-router)# do show isis route algorithm json
> [
> {
> "area":"1",
> "algorithm":128,
> "level-1":{
> ]
> },
> "level-2":{
> "area":"1"
> },
> "vrf_id":0
> },
> {
> "area":"1",
> "algorithm":129,
> "level-1":{
> "area":"1",
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
To avoid calling for each algorithm the 'show isis route'
command, the algorithm id is optional. The below command
will dump the routes for all the algorithms:
> show isis route algorithm
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Create a single registry of default port values that daemons
are using. Most of these are vty ports, but there are some
others for features like ospfapi and zebra FPM.
Signed-off-by: Mark Stapp <mjs@labn.net>
This belongs in `/var/lib`, not `/var/run`. Also the filename was
typo'd (`isid-restart.json`).
Change to proper location and fall back to previous in case it's the
first restart after an FRR update from a version with the bugged path.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
clang-format doesn't understand FRR_DAEMON_INFO is a long macro where
laying out items semantically makes sense.
(Also use only one `FRR_DAEMON_INFO(` in isisd so editors don't get
confused with the mismatching `( ( )`.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Currently, when editing a leaf-list, `nb_candidate_edit` expects to
receive it's xpath without a predicate and the value in a separate
argument, and then creates the full xpath. This hack is complicated,
because it depends on the operation and on the caller being a backend or
not. Instead, let's require to always include the predicate in a
leaf-list xpath. Update all the usages in the code accordingly.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Change the type of affinity leaf-list in frr-zebra to a leafref with
"require-instance" property set to true. This change tells libyang to
automatically check that affinity-map exists before usage and doesn't
allow it to be deleted if it's referenced. It allows us to remove all
the manual code that is doing the same thing.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
