A macvlan interface can have its underlying link-interface in another
namespace (aka. netns). However, by default, zebra does not know the
interface from the other namespaces. It results in a crash the pointer
to the link interface is NULL.
> 6 0x0000559d77a329d3 in zebra_vxlan_macvlan_up (ifp=0x559d798b8e00) at /root/frr/zebra/zebra_vxlan.c:4676
> 4676 link_zif = link_ifp->info;
> (gdb) list
> 4671 struct interface *link_ifp, *link_if;
> 4672
> 4673 zif = ifp->info;
> 4674 assert(zif);
> 4675 link_ifp = zif->link;
> 4676 link_zif = link_ifp->info;
> 4677 assert(link_zif);
> 4678
> (gdb) p zif->link
> $2 = (struct interface *) 0x0
> (gdb) p zif->link_ifindex
> $3 = 15
Fix the crash by returning when the macvlan link-interface is in another
namespace. No need to go further because any vxlan under the macvlan
interface would not be accessible by zebra.
Link: https://github.com/FRRouting/frr/issues/15370
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit 44e6e3868d)
Iggy Frankovic discovered an ospfd crash when perfomring fuzzing of OSPF LSA
packets. The crash occurs in ospf_te_parse_te() function when attemping to
create corresponding egde from TE Link parameters. If there is no local
address, an edge is created but without any attributes. During parsing, the
function try to access to this attribute fields which has not been created
causing an ospfd crash.
The patch simply check if the te parser has found a valid local address. If not
found, we stop the parser which avoid the crash.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
(cherry picked from commit a73e66d073)
adding a tests about:
"no bgp as-path access-list" command.
the folloxing "clear bgp *" command leads to the
crash exhibited above.
a sleep had been added to capture the crash befor the end of scenario.
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f5f05cbb9c0 (LWP 1371086))]
(gdb) bt
context=0x7ffcf2c216c0) at lib/sigevent.c:248
acl_list=0x55c976ec03c0) at bgpd/bgp_aspath.c:1688
dummy=0x7ffcf2c22340, object=0x7ffcf2c21e70) at bgpd/bgp_routemap.c:2401
match_object=0x7ffcf2c21e70, set_object=0x7ffcf2c21e70, pref=0x0)
at lib/routemap.c:2687
attr=0x7ffcf2c220b0, afi=AFI_IP, safi=SAFI_UNICAST, rmap_name=0x0, label=0x0,
num_labels=0, dest=0x55c976ebeaf0) at bgpd/bgp_route.c:1807
addpath_id=0, attr=0x7ffcf2c22450, afi=AFI_IP, safi=SAFI_UNICAST, type=10,
sub_type=0, prd=0x0, label=0x0, num_labels=0, soft_reconfig=0, evpn=0x0)
at bgpd/bgp_route.c:4424
packet=0x7ffcf2c22410) at bgpd/bgp_route.c:6266
packet=0x7ffcf2c22410, mp_withdraw=false) at bgpd/bgp_packet.c:341
peer=0x55c976e89ed0, size=43) at bgpd/bgp_packet.c:2414
at bgpd/bgp_packet.c:3899
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
(cherry picked from commit 324fa21015)
Convert only when this is really needed, e.g. `match ip address prefix-list ...`.
Otherwise, we can't have mixed match clauses, like:
```
match ip address prefix-list p1
match evpn route-type prefix
```
This won't work, because the prefix is already converted, and we can't extract
route type, vni, etc. from the original EVPN prefix.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 439b739495)
where null lladdr recieved from zebra before nhrp next hop
is installed.
Signed-off-by: Lou Berger <lberger@labn.net>
(cherry picked from commit 5d9ebe6181)
Topology:
TOR11 (FHR) --- LEAF-11---SPINE1 (RP)MSDP SPINE-2(RP)MSDP --- LEAF-12 -- TOR12 (LHR)
| | | | |
| -----------------------------------------------------(ECMP) |
| | | |
-----------------------------------------------------------------------(ECMP)
Issue:
In some triggers, S,G upstream is preserved even with the PP timer expiry, resulting
in S,G with NULL OILS. This could be because we create a dummy S,G upstream and
dummy channel_oif for *,G, where RPF is UNKNOWN. As a result, PIM+VXLAN traffic is never
forwarded downstream to LHR.
Fix:
when the S,G stream is running, Determine if a reevaluation of the outgoing interface
list (OIL) is required. S,G upstream should then inherit the OIL from *,G.
Testing:
- Evpn pim tests - TestEvpnPimSingleVtepOneMdt.test_02_broadcast_traffic_spt_zero
- pim-smoke
Ticket: #
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit 071d43a052)
frr-reload.py will walk through all config contexts and prepend no to the CLI
command. This requires that the vtysh shell code accepts a full command.
To Reproduce
vtysh -c "conf t" -c "router ospf" -c "router-info area"
vtysh -c "conf t" -c "router ospf" -c "no router-info area"
% Unknown command: no router-info area
vtysh -c "conf t" -c "router ospf" -c "no router-info"
Signed-off-by: Christian Breunig <christian@breunig.cc>
(cherry picked from commit e744db5098)
This fixes the initial implementation of commit 7743f2f8c0 ("OSPFd: Update
Segment Routing PR following review") where it wsa not possible to remove
the "segment-routing node-msd" CLI nodes via vtysh once segment-routing got
disabled.
Closes#14910
Signed-off-by: Christian Breunig <christian@breunig.cc>
(cherry picked from commit ba45aa62e7)
Just avoid calling for TCP MSS socket option if it's not in use.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 65497556ed)
BGP static routes are defined using the network statement, e.g.:
> router bgp XXX
> address-family ipv4 unicast
> network 192.168.0.0/24
When "no bgp network import-check" is set, it is impossible to
successfully import the static routes into the BGP VPN table. The prefix
is present in the table but is not marked as valid. This issue applies
regardless of whether or not routes are present in the router's RIB.
Always mark as valid the nexthops of BGP static routes when "no bgp
network import-check" is set.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 45bf46441a)
Issue:
Previously, the PBR common was updated for every rule update or deletion
example:
let say we have three rule 11, 12, 13 and if we are removing rule 12. in the current code
we are making the entire map "valid" to false.
pbr-map MAP1 seq 11
match src-ip 90.1.1.2/32
set nexthop 20.1.1.2 swp1
pbr-map MAP1 seq 12
match src-ip 90.1.1.3/32
set nexthop 20.1.1.2 swp1
pbr-map MAP1 seq 13
match src-ip 90.1.1.4/32
set nexthop 20.1.1.2 swp1
no pbr-map MAP1 seq 12 ==> turns whole map valid to false.
r1(config)# end
r1# show pbr map
pbr-map MAP1 valid: no
Seq: 11 rule: 310
Installed: yes Reason: Valid
SRC IP Match: 90.1.1.2/32
nexthop 20.1.1.2 swp1
Installed: yes Tableid: 10002
Seq: 13 rule: 312
Installed: yes Reason: Valid
SRC IP Match: 90.1.1.4/32
nexthop 20.1.1.2 swp1
Installed: yes Tableid: 10004
Fix:
Now, the PBR common will only be updated when the last rule is being deleted.
This change ensures that we only send a delete request to Zebra once, and only
set the valid and installed flags to false when the last rule is deleted.
This optimizes the handling of PBR rules and reduces unnecessary interactions with Zebra
Testing: UT in MR notes
Ticket: #
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit aa12c72c2a)
Use enum instead of int, and make the compiler happy when using -format-overflow.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 2c69b4b516)
Command: `ip ssmpingd 1.1.1.1`
Backtrace:
```
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
0x00007fd1d3b02859 in __GI_abort () at abort.c:79
0x00007fd1d3e323e1 in yang_dnode_xpath_get_canon (dnode=<optimized out>, xpath_fmt=<optimized out>, ap=<optimized out>) at lib/yang_wrappers.c:61
0x00007fd1d3e34f41 in yang_dnode_get_ipv4 (addr=addr@entry=0x7ffc368554d4, dnode=<optimized out>, xpath_fmt=xpath_fmt@entry=0x5556af8680d4 "./source-addr") at lib/yang_wrappers.c:826
0x00005556af8216d3 in routing_control_plane_protocols_control_plane_protocol_pim_address_family_ssm_pingd_source_ip_create (args=0x7ffc36855530) at pimd/pim_nb_config.c:925
0x00007fd1d3dec13f in nb_callback_create (nb_node=0x5556b197ea40, nb_node=0x5556b197ea40, errmsg_len=8192, errmsg=0x7ffc36855a90 "", resource=0x5556b18fa6f8, dnode=0x5556b1ad7a10, event=NB_EV_APPLY, context=0x5556b1ad75c0) at lib/northbound.c:1260
nb_callback_configuration (context=0x5556b1ad75c0, event=NB_EV_APPLY, change=<optimized out>, errmsg=0x7ffc36855a90 "", errmsg_len=8192) at lib/northbound.c:1648
0x00007fd1d3deca6c in nb_transaction_process (event=event@entry=NB_EV_APPLY, transaction=transaction@entry=0x5556b1ad75c0, errmsg=errmsg@entry=0x7ffc36855a90 "", errmsg_len=errmsg_len@entry=8192) at lib/northbound.c:1779
0x00007fd1d3decdd6 in nb_candidate_commit_apply (transaction=0x5556b1ad75c0, save_transaction=save_transaction@entry=true, transaction_id=transaction_id@entry=0x0, errmsg=errmsg@entry=0x7ffc36855a90 "", errmsg_len=errmsg_len@entry=8192) at lib/northbound.c:1129
0x00007fd1d3decf15 in nb_candidate_commit (context=..., candidate=<optimized out>, save_transaction=save_transaction@entry=true, comment=comment@entry=0x0, transaction_id=transaction_id@entry=0x0, errmsg=0x7ffc36855a90 "", errmsg_len=8192) at lib/northbound.c:1162
0x00007fd1d3ded4af in nb_cli_classic_commit (vty=vty@entry=0x5556b1ada2a0) at lib/northbound_cli.c:50
0x00007fd1d3df025f in nb_cli_apply_changes_internal (vty=vty@entry=0x5556b1ada2a0, xpath_base=xpath_base@entry=0x7ffc36859b50 ".", clear_pending=clear_pending@entry=false) at lib/northbound_cli.c:177
0x00007fd1d3df06ad in nb_cli_apply_changes (vty=vty@entry=0x5556b1ada2a0, xpath_base_fmt=xpath_base_fmt@entry=0x0) at lib/northbound_cli.c:233
0x00005556af80fdd5 in pim_process_ssmpingd_cmd (vty=0x5556b1ada2a0, operation=NB_OP_CREATE, src_str=0x5556b1ad9630 "1.1.1.1") at pimd/pim_cmd_common.c:3423
0x00007fd1d3da7b0e in cmd_execute_command_real (vline=vline@entry=0x5556b1ac9520, vty=vty@entry=0x5556b1ada2a0, cmd=cmd@entry=0x0, up_level=up_level@entry=0) at lib/command.c:982
0x00007fd1d3da7cb1 in cmd_execute_command (vline=vline@entry=0x5556b1ac9520, vty=vty@entry=0x5556b1ada2a0, cmd=0x0, vtysh=vtysh@entry=0) at lib/command.c:1040
0x00007fd1d3da7e50 in cmd_execute (vty=vty@entry=0x5556b1ada2a0, cmd=cmd@entry=0x5556b1ae0a30 "ip ssmpingd 1.1.1.1", matched=matched@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1207
0x00007fd1d3e278be in vty_command (vty=vty@entry=0x5556b1ada2a0, buf=<optimized out>) at lib/vty.c:591
0x00007fd1d3e27afd in vty_execute (vty=0x5556b1ada2a0) at lib/vty.c:1354
0x00007fd1d3e2bb23 in vtysh_read (thread=<optimized out>) at lib/vty.c:2362
0x00007fd1d3e22254 in event_call (thread=thread@entry=0x7ffc3685cd80) at lib/event.c:2003
0x00007fd1d3dce9e8 in frr_run (master=0x5556b183c830) at lib/libfrr.c:1218
0x00005556af803653 in main (argc=6, argv=<optimized out>, envp=<optimized out>) at pimd/pim_main.c:162
```
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
(cherry picked from commit 8ffc3640f0)
Add missing break. Currently, lib_route_map_entry_match_destroy is
called on every commit stage, but it should run only on APPLY.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
(cherry picked from commit 7006880bc2)
In an EBGP multihop configuration with dynamic neighbors, the TTL configured is not being updated for the socket.
Issue:
Assume the following topology:
Host (Dynamic peer to spine - 192.168.1.100) - Leaf - Spine (192.168.1.1)
When the host establishes a BGP multihop session to the spine,
the connection uses the MAXTTL value instead of the configured TTL (in this case, 2).
This issue is only observed with dynamic peers.
Logs: look at the TTL is still MAXTTL, instead of “2” configured.
18:13:18.872395 48:b0:2d:0c:58:0b > 48:b0:2d:66:64:6b, ethertype IPv4 (0x0800), length 85: (tos 0xc0, ttl 255, id 32078, offset 0, flags [DF], proto TCP (6), length 71)
192.168.1.100.179 > 192.168.1.1.40967: Flags [P.], cksum 0xfe89 (correct), seq 28406:28425, ack 28424, win 255, options [nop,nop,TS val 4192664793 ecr 2814447051], length 19: BGP
Keepalive Message (4), length: 19
Fix:
Whenever a dynamic peer is created, the socket TTL should be updated with the configured TTL, in this case 2.
19:13:24.894890 48:b0:2d:0c:58:0b > 48:b0:2d:66:64:6b, ethertype IPv4 (0x0800), length 85: (tos 0xc0, ttl 2, id 1131, offset 0, flags [DF], proto TCP (6), length 71)
192.168.1.100.179 > 192.168.1.1.41937: Flags [P.], cksum 0x7a67 (correct), seq 2046150759:2046150778, ack 4286110599, win 255, options [nop,nop,TS val 4196270815 ecr 2818051226], length 19: BGP
Keepalive Message (4), length: 19
Testing: UT
UT logs:
2023-12-29T19:13:21.892205+00:00 host bgpd[1591425]: [WWPV7-YSZB5] Dynamic Neighbor 192.168.1.1/32 matches group test listen range 192.168.1.0/30
2023-12-29T19:13:21.892654+00:00 host bgpd[1591425]: [GBPAR-M31QF] 192.168.1.1 Dynamic Neighbor added, group test count 1
2023-12-29T19:13:21.892993+00:00 host bgpd[1591425]: [GPE2H-K9QRE] bgp_set_socket_ttl: set TxTTL on peer (rtrid 0.0.0.0) socket, err = 2, peer ttl 2
Conflicts:
bgpd/bgp_network.c
Ticket: #
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit 68573c34d4)
Fix the following heap-buffer-overflow:
> ==3901635==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020003a5940 at pc 0x56260067bb48 bp 0x7ffe8a4f3840 sp 0x7ffe8a4f3838
> READ of size 4 at 0x6020003a5940 thread T0
> #0 0x56260067bb47 in ecommunity_fill_pbr_action bgpd/bgp_ecommunity.c:1587
> #1 0x5626007a246e in bgp_pbr_build_and_validate_entry bgpd/bgp_pbr.c:939
> #2 0x5626007b25e6 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2933
> #3 0x562600909d18 in bgp_zebra_announce bgpd/bgp_zebra.c:1351
> #4 0x5626007d5efd in bgp_process_main_one bgpd/bgp_route.c:3528
> #5 0x5626007d6b43 in bgp_process_wq bgpd/bgp_route.c:3641
> #6 0x7f450f34c2cc in work_queue_run lib/workqueue.c:266
> #7 0x7f450f327a27 in event_call lib/event.c:1970
> #8 0x7f450f21a637 in frr_run lib/libfrr.c:1213
> #9 0x56260062fc04 in main bgpd/bgp_main.c:540
> #10 0x7f450ee2dd09 in __libc_start_main ../csu/libc-start.c:308
> #11 0x56260062ca29 in _start (/usr/lib/frr/bgpd+0x2e3a29)
>
> 0x6020003a5940 is located 0 bytes to the right of 16-byte region [0x6020003a5930,0x6020003a5940)
> allocated by thread T0 here:
> #0 0x7f450f6aa1f8 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164
> #1 0x7f450f244f8a in qrealloc lib/memory.c:112
> #2 0x562600673313 in ecommunity_add_val_internal bgpd/bgp_ecommunity.c:143
> #3 0x5626006735bc in ecommunity_uniq_sort_internal bgpd/bgp_ecommunity.c:193
> #4 0x5626006737e3 in ecommunity_parse_internal bgpd/bgp_ecommunity.c:228
> #5 0x562600673890 in ecommunity_parse bgpd/bgp_ecommunity.c:236
> #6 0x562600640469 in bgp_attr_ext_communities bgpd/bgp_attr.c:2674
> #7 0x562600646eb3 in bgp_attr_parse bgpd/bgp_attr.c:3893
> #8 0x562600791b7e in bgp_update_receive bgpd/bgp_packet.c:2141
> #9 0x56260079ba6b in bgp_process_packet bgpd/bgp_packet.c:3406
> #10 0x7f450f327a27 in event_call lib/event.c:1970
> #11 0x7f450f21a637 in frr_run lib/libfrr.c:1213
> #12 0x56260062fc04 in main bgpd/bgp_main.c:540
> #13 0x7f450ee2dd09 in __libc_start_main ../csu/libc-start.c:308
Fixes: dacf6ec120 ("bgpd: utility routine to convert flowspec actions into pbr actions")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit 6001c765e2)
Fix the following heap-use-after-free
> ==82961==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020001e4750 at pc 0x55a8cc7f63ac bp 0x7ffd6948e340 sp 0x7ffd6948e330
> READ of size 8 at 0x6020001e4750 thread T0
> #0 0x55a8cc7f63ab in isis_route_node_cleanup isisd/isis_route.c:335
> #1 0x7ff25ec617c1 in route_node_free lib/table.c:75
> #2 0x7ff25ec619fc in route_table_free lib/table.c:111
> #3 0x7ff25ec61661 in route_table_finish lib/table.c:46
> #4 0x55a8cc800d83 in _isis_spftree_del isisd/isis_spf.c:397
> #5 0x55a8cc800e45 in isis_spftree_clear isisd/isis_spf.c:414
> #6 0x55a8cc80bd9a in isis_run_spf isisd/isis_spf.c:2020
> #7 0x55a8cc80c370 in isis_run_spf_with_protection isisd/isis_spf.c:2076
> #8 0x55a8cc80cf52 in isis_run_spf_cb isisd/isis_spf.c:2165
> #9 0x7ff25ec7c4dc in event_call lib/event.c:1970
> #10 0x7ff25eb64423 in frr_run lib/libfrr.c:1213
> #11 0x55a8cc7799da in main isisd/isis_main.c:318
> #12 0x7ff25e623d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
> #13 0x7ff25e623e3f in __libc_start_main_impl ../csu/libc-start.c:392
> #14 0x55a8cc778e44 in _start (/usr/lib/frr/isisd+0x109e44)
>
> 0x6020001e4750 is located 0 bytes inside of 16-byte region [0x6020001e4750,0x6020001e4760)
> freed by thread T0 here:
> #0 0x7ff25f000537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127
> #1 0x7ff25eb9012e in qfree lib/memory.c:130
> #2 0x55a8cc7f6485 in isis_route_table_info_free isisd/isis_route.c:351
> #3 0x55a8cc800cf4 in _isis_spftree_del isisd/isis_spf.c:395
> #4 0x55a8cc800e45 in isis_spftree_clear isisd/isis_spf.c:414
> #5 0x55a8cc80bd9a in isis_run_spf isisd/isis_spf.c:2020
> #6 0x55a8cc80c370 in isis_run_spf_with_protection isisd/isis_spf.c:2076
> #7 0x55a8cc80cf52 in isis_run_spf_cb isisd/isis_spf.c:2165
> #8 0x7ff25ec7c4dc in event_call lib/event.c:1970
> #9 0x7ff25eb64423 in frr_run lib/libfrr.c:1213
> #10 0x55a8cc7799da in main isisd/isis_main.c:318
> #11 0x7ff25e623d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> previously allocated by thread T0 here:
> #0 0x7ff25f000a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
> #1 0x7ff25eb8ffdc in qcalloc lib/memory.c:105
> #2 0x55a8cc7f63eb in isis_route_table_info_alloc isisd/isis_route.c:343
> #3 0x55a8cc80052a in _isis_spftree_init isisd/isis_spf.c:334
> #4 0x55a8cc800e51 in isis_spftree_clear isisd/isis_spf.c:415
> #5 0x55a8cc80bd9a in isis_run_spf isisd/isis_spf.c:2020
> #6 0x55a8cc80c370 in isis_run_spf_with_protection isisd/isis_spf.c:2076
> #7 0x55a8cc80cf52 in isis_run_spf_cb isisd/isis_spf.c:2165
> #8 0x7ff25ec7c4dc in event_call lib/event.c:1970
> #9 0x7ff25eb64423 in frr_run lib/libfrr.c:1213
> #10 0x55a8cc7799da in main isisd/isis_main.c:318
> #11 0x7ff25e623d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Fixes: 7153c3cabf ("isisd: update struct isis_route_info has multiple sr info by algorithm")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit 9fa9a9d865)
Ensure that 0.0.0.0/1 route can be advertised along with
default-originate.
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
(cherry picked from commit 4538247c99)
The OSPF TE topotest is using switches to interconnect router. During the test,
interfaces are shutdown on some routers to simulate link failure and check that
the TED is correctly updated. However, the switche between router avoid the
detection by the neighbor router that the interface is down i.e. the interface
line remains up as it is conneted to the switch and not to the router.
This patch update the tested topology by removing the switch and connect
directly the router excepted the inter AS link on R3. Interface are also
renamed accordingly.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
(cherry picked from commit 55ad785753)
Traffic Engineering Database (TED) is fulfill from the various LSA advertised
and received by the router. To remove information on the TED, 2 mechanisms are
used: i) parse TE Opaque LSA when there are flushed and ii) compare the list of
prefixes advertised in the Router LSA with the list of corresponding edges and
subnets contained in the TED. However, this second mechanism assumes that the
Router LSA is unique and contains all prefixes of the advertised router.
But, this is wrong. Prefixes could be advertised with several Router LSA.
This conduct to remove edge and subnet in the TED while it should be maintained.
The result is a faulty test with ospf_sr_te_topo1 topotest when server is heavy
loaded.
This simple patch removed deletion of edges and subnets when parsing the Router
LSA and only removed them when the corresponding TE Opaque LSA is flushed. In
addition, TE Opaque LSA are not flushed when OSPF ajacency goes down. This
patch also correct this second problem.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
(cherry picked from commit a3230323f7)
