When creating an initial tree trunk for oper data walk, if the xpath
represents a leaf, the leaf is created with an incorrect empty value.
If it doesn't actually exist in daemon's oper data, its value is not
overwritten later and an empty value is returned in the result.
For example, when requesting
`/frr-interface:lib/interface[name='eth0']/description`, the result is:
```
{
"frr-interface:lib": {
"interface": [
{
"name": "eth0",
"description": ""
}
]
}
}
```
instead of an empty JSON that it should be.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Like in RESTCONF GET request and NETCONF get-data request, make it
possible to request state-only, config-only, or all data.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Currently it's the same as get-tree request for the backend, but it is
going to be expanded in the following commits.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
mgmtd has to know if netns is used as the vrf backend to correctly
process interface names in northbound.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Technically changing a leaf from uint16 to uint32 is a NBC change; however,
increasing this to uint32 should not break anyone in reality.
Signed-off-by: Christian Hopps <chopps@labn.net>
Also change `be_client_xpaths` to `be_client_config_xpaths` referred in the doc
to make much clearer it's use (since there's a separate `be_client_oper_xpaths`.
Signed-off-by: Christian Hopps <chopps@labn.net>
next_phase is always curr_phase + 1. It's not necessary to maintain it
separately. Also rename curr_phase to phase.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Setting this variable to true makes NB ignore only configuration-related
callbacks. CLI-related callbacks are still loaded and executed, so
rename the variable to make it clearer.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When determining the interested backend clients for a configuration
change, don't consider disconnected clients. This fixes a crash in
`mgmt_txn_send_be_txn_create` when trying to send data to a non-existing
adapter.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
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>
When turning on debug pim trace, there are lots of messages
surrounding the timing of rpf lookup. 99% of the time
no-one cares about these anymore. Let's make them
not seen unless we turn up debugs
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The Join or Prune messages require you to turn on `trace`
but this is part of Join/Prune processing of the packet
let's use PIM_DEBUG_PIM_J_P instead of TRACE here.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
