During shutdown, the main pthread stops the dplane pthread
before exiting. Don't try to clean up any events scheduled
to the dplane pthread at that point - just let the thread
exit and clean up.
Signed-off-by: Mark Stapp <mjs@labn.net>
If log-pdu-drops is configured, create an INFO log that displays the PDU type and drop counts when a PDU drop is detected.
Example logs:
2023/03/30 23:54:59.749 ISIS: [VAS9N-1JNNR] PDU drop detected of type: P2P IIH. 1 Total Drops; 0 L1 IIH drops; 0 L2 IIH drops; 1 P2P IIH drops; 0 L1 LSP drops; 0 L2 LSP drops; 0 FS LSP drops; 0 L1 CSNP drops; 0 L2 CSNP drops; 0 L1 PSNP drops; 0 L2 PSNP drops.
2023/03/30 23:54:59.848 ISIS: [VAS9N-1JNNR] PDU drop detected of type: P2P IIH. 2 Total Drops; 0 L1 IIH drops; 0 L2 IIH drops; 2 P2P IIH drops; 0 L1 LSP drops; 0 L2 LSP drops; 0 FS LSP drops; 0 L1 CSNP drops; 0 L2 CSNP drops; 0 L1 PSNP drops; 0 L2 PSNP drops.
Code changes:
Add a new PDU counter function that increments the drop counter and runs the logging functionality if log-pdu-drops is configured.
Signed-off-by: Isabella de Leon <ideleon@microsoft.com>
New config functionality:
r1# conf
r1(config)# router isis 1
r1(config-router)# log-
log-adjacency-changes Log changes in adjacency state
log-pdu-drops Log any dropped PDUs
r1(config-router)# log-pdu-drops
r1(config-router)# end
Signed-off-by: Isabella de Leon <ideleon@microsoft.com>
It is not possible to create an adjacency by using interface
addresses within the `169.254.0.0/24` pool.
When forging the IIH messages, the interface addresses from
that pool are not appended:
> Neither IPv4 nor IPv6 considered usable. Ignoring IIH
Using this network pool is possible on other IS-IS
implementations. Let us authorize to use such network
addresses.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
For multicast pimv6 join and traffic, socat is
used, which was not cleaned up post tests executions,
enhanced kill_socat() API to kill socat join and
traffic specific PIDs during teardown module.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
The parser for extended communities was incorrectly disallowing an
operator from configuring "Route Origin" extended communities
(e.g. RD/RT/SoO) with a 4-byte value matching BGP_AS4_MAX (UINT32_MAX)
and allowed the user to overflow UINT32_MAX. This updates the parser to
read the value as a uint64_t so that we can do proper checks on the
upper bounds (> BGP_AS4_MAX || errno).
before:
```
TORC11(config-router-af)# neighbor uplink-1 soo 4294967296:65
TORC11(config-router-af)# do sh run | include soo
neighbor uplink-1 soo 0:65
TORC11(config-router-af)# neighbor uplink-1 soo 4294967295:65
% Malformed SoO extended community
TORC11(config-router-af)#
```
after:
```
TORC11(config-router-af)# neighbor uplink-1 soo 4294967296:65
% Malformed SoO extended community
TORC11(config-router-af)# neighbor uplink-1 soo 4294967295:65
TORC11(config-router-af)# do sh run | include soo
neighbor uplink-1 soo 4294967295:65
TORC11(config-router-af)#
```
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Enhanced or added new libraries to support
multicast mld local join automation
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
Co-Auther: Vijay Kumar Gupta <vijayg@vmware.com>
Added new test suite to verify functionality
of multicast MLD local join. Added 4 different
test cases in test suite.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
Co-Authored-by: Vijay Kumar Gupta <vijayg@vmware.com>
Currently the process of the `route-map` configuration for `per-vrf-rip`
is wrong.
There are two problems:
1. `ctx->name` for `if_rmap_ctx` is not initialized in `if_rmap_ctx_create()`.
2. The global `if_rmap_ctx_list` is wrongly used for `per-vrf-rip`.
So, two changes for it:
1. Correctly initializes `ctx->name`.
2. Use specific `if_rmap_ctx` for `per-vrf-rip`, not global one.
Note, this related implementation for `route-map` is only for `ripd`.
Before:
```
anlan(config)# route rip vrf vrf1
anlan(config-router)# route-map aa in lan
anlan(config-router)# do show run
!
router rip
route-map aa in lan
exit
!
```
After:
```
anlan(config)# route rip vrf vrf1
anlan(config-router)# route-map aa in lan
anlan(config-router)# do show run
!
router rip vrf vrf1
route-map aa in lan
exit
!
```
Signed-off-by: anlan_cs <vic.lan@pica8.com>
ospf neighbor DR and BDR router-id wrongly displays with interface
ip-address instead of router-id.
It is fixed to display the correct DR & BDR router-id for
JSON and CLI commands.
Commands:
```
show ip ospf vrf <vrf-name> neighbor detail json
show ip ospf vrf <vrf-name> neighbor detail
```
Before Fix:-
```
r1# show ip ospf vrf default neighbor swp1 detail
Neighbor 0.0.0.17, interface address 11.0.0.1
In the area 0.0.0.0 via interface swp1 local interface IP 11.0.0.2
Neighbor priority is 1, State is Full, Role is DR, 6 state changes
Most recent state change statistics:
Progressive change 1d15h05m ago
DR is 11.0.0.1, BDR is 11.0.0.2 ======> DR and BDR shows the intef &
local intf ipaddress
Options 2 *|-|-|-|-|-|E|-
Dead timer due in 35.178s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on
r1#
r1# show ip ospf vrf default neighbor swp1 detail json
{
"0.0.0.17":[
{
"ifaceAddress":"11.0.0.1",
"areaId":"0.0.0.0",
"ifaceName":"swp1",
"localIfaceAddress":"11.0.0.2",
"nbrPriority":1,
"nbrState":"Full",
"role":"DR",
"stateChangeCounter":6,
"lastPrgrsvChangeMsec":141141533,
"routerDesignatedId":"11.0.0.1", =============> interface ip
instead of DR rotuer-id
"routerDesignatedBackupId":"11.0.0.2", =======> lo-interface ip
instead of BDR rotuer-id
"optionsCounter":2,
"optionsList":"*|-|-|-|-|-|E|-",
"routerDeadIntervalTimerDueMsec":32272,
"databaseSummaryListCounter":0,
"linkStateRequestListCounter":0,
"linkStateRetransmissionListCounter":0,
"threadInactivityTimer":"on",
"threadLinkStateRequestRetransmission":"on",
"threadLinkStateUpdateRetransmission":"on"
}
]
}
r1#
```
After Fix:-
```
r1# show ip ospf vrf default neighbor detail json
{
"default":{
"vrfName":"default",
"vrfId":0,
"neighbors":{
"0.0.0.17":[
{
"ifaceAddress":"11.0.0.1",
"areaId":"0.0.0.0",
"ifaceName":"swp1",
"localIfaceAddress":"11.0.0.2",
"nbrPriority":1,
"nbrState":"Full",
"role":"DR",
"stateChangeCounter":6,
"lastPrgrsvChangeMsec":4531505,
"routerDesignatedId":"0.0.0.17", =====> DR Router-Id
"routerDesignatedBackupId":"0.0.0.12", =====> BDR Router-Id
"optionsCounter":2,
"optionsList":"*|-|-|-|-|-|E|-",
"routerDeadIntervalTimerDueMsec":38495,
"databaseSummaryListCounter":0,
"linkStateRequestListCounter":0,
"linkStateRetransmissionListCounter":0,
"threadInactivityTimer":"on",
"threadLinkStateRequestRetransmission":"on",
"threadLinkStateUpdateRetransmission":"on"
}
],
"0.0.0.13":[
{
"ifaceAddress":"11.0.2.2",
"areaId":"0.0.0.0",
"ifaceName":"swp2",
"localIfaceAddress":"11.0.2.1",
"nbrPriority":1,
"nbrState":"Full",
"role":"DR",
"stateChangeCounter":6,
"lastPrgrsvChangeMsec":4522182,
"routerDesignatedId":"0.0.0.13", =====> DR Router-Id
"routerDesignatedBackupId":"0.0.0.12", =====> BDR Router-Id
"optionsCounter":2,
"optionsList":"*|-|-|-|-|-|E|-",
"routerDeadIntervalTimerDueMsec":37840,
"databaseSummaryListCounter":0,
"linkStateRequestListCounter":0,
"linkStateRetransmissionListCounter":0,
"threadInactivityTimer":"on",
"threadLinkStateRequestRetransmission":"on",
"threadLinkStateUpdateRetransmission":"on"
}
],
"0.0.0.14":[
{
"ifaceAddress":"11.0.3.2",
"areaId":"0.0.0.0",
"ifaceName":"swp3",
"localIfaceAddress":"11.0.3.1",
"nbrPriority":1,
"nbrState":"Full",
"role":"DR",
"stateChangeCounter":6,
"lastPrgrsvChangeMsec":4522182,
"routerDesignatedId":"0.0.0.14", =====> DR Router-Id
"routerDesignatedBackupId":"0.0.0.12", =====> BDR Router-Id
"optionsCounter":2,
"optionsList":"*|-|-|-|-|-|E|-",
"routerDeadIntervalTimerDueMsec":37840,
"databaseSummaryListCounter":0,
"linkStateRequestListCounter":0,
"linkStateRetransmissionListCounter":0,
"threadInactivityTimer":"on",
"threadLinkStateRequestRetransmission":"on",
"threadLinkStateUpdateRetransmission":"on"
}
]
}
}
}
r1#
r1# show ip ospf vrf default neighbor swp1 detail
Neighbor 0.0.0.17, interface address 11.0.0.1
In the area 0.0.0.0 via interface swp1 local interface IP 11.0.0.2
Neighbor priority is 1, State is Full, Role is DR, 6 state changes
Most recent state change statistics:
Progressive change 1h18m11s ago
DR is 0.0.0.17, BDR is 0.0.0.12 =======> correct DR and BDR
router-id
Options 2 *|-|-|-|-|-|E|-
Dead timer due in 38.339s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on
r1#
r1# show ip ospf vrf default neighbor swp
swp1 swp2 swp3 swp4
r1# show ip ospf vrf default neighbor swp2 detail
Neighbor 0.0.0.13, interface address 11.0.2.2
In the area 0.0.0.0 via interface swp2 local interface IP 11.0.2.1
Neighbor priority is 1, State is Full, Role is DR, 6 state changes
Most recent state change statistics:
Progressive change 12m02s ago
DR is 0.0.0.13, BDR is 0.0.0.12 =======> correct DR and BDR
router-id
Options 2 *|-|-|-|-|-|E|-
Dead timer due in 37.136s
Database Summary List 0
Link State Request List 0
Link State Retransmission List 0
Thread Inactivity Timer on
Thread Database Description Retransmision off
Thread Link State Request Retransmission on
Thread Link State Update Retransmission on
r1#
```
Ticket:#3395270
Issue:3395270
Testing: UT done
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
When daemons transition to mgmtd they should stop reading their split config
files, and let mgmtd do that, otherwise things can get out of sync.
Signed-off-by: Christian Hopps <chopps@labn.net>
The json structure changes used for 'json detail' show commands are not
very straightforward and might require code analysis to understand.
This addscommentary to the flow to explain the change in structure.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
At this point OSPF NSSA deserves a dedicated topotest given the
latest nerd knobs that were added :)
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Implement NSSA address ranges as specified by RFC 3101:
NSSA border routers may be configured with Type-7 address ranges.
Each Type-7 address range is defined as an [address,mask] pair. Many
separate Type-7 networks may fall into a single Type-7 address range,
just as a subnetted network is composed of many separate subnets.
NSSA border routers may aggregate Type-7 routes by advertising a
single Type-5 LSA for each Type-7 address range. The Type-5 LSA
resulting from a Type-7 address range match will be distributed to
all Type-5 capable areas.
Syntax:
area A.B.C.D nssa range A.B.C.D/M [<not-advertise|cost (0-16777215)>]
Example:
router ospf
router-id 1.1.1.1
area 1 nssa
area 1 nssa range 172.16.0.0/16
area 1 nssa range 10.1.0.0/16
!
Since regular area ranges and NSSA ranges have a lot in common,
this commit reuses the existing infrastructure for area ranges as
much as possible to avoid code duplication.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* Update the "range" helpers to accept an area pointer instead of
an area ID;
* Always call ospf_area_display_format_set() after every "range"
command to ensure consistency.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Add the "default-information-originate" option to the "area X nssa"
command. That option allows the origination of Type-7 default routes
on NSSA ABRs and ASBRs.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Combine all variation of the "area nssa" command into a single
DEFPY to improve code maintainability.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The startup config and how it interacts with explicit commits,
commit databases and implicit commits needs to be worked out
in design first. For now remove the offending code.
Signed-off-by: Christian Hopps <chopps@labn.net>
Prior to this the full retry cycle was run with a "passing" negative
result each time through
Previous runtime ~5 minutes
New runtime ~20 seconds.
Signed-off-by: Christian Hopps <chopps@labn.net>
