Should we enable allow-service netconf all the time?

[yutashimamura2920]

I understand that when implementing configuration changes from vManage to cEdge/vEdge, the changes are made via NETCONF.
However, even if no allow-service netconf is set under Interface tunnel, the configuration can be changed without any problem.
Why is this?

[balaji.bandi]

Can you post full config of interface -

Do you have under interface  allow-service all (this overrides all other config)

check the below guide what ports used :

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/sdwan-xe-gs-book/cisco-sd-wan-overlay-network-bringup.html

[Kanan Huseynli · Accepted solution]

Hi,

one more good question...

Netconf is mostly used over DTLS/TLS. So, even if you block service network on transport interface, it still works (as you mentioned) because config update is pushed via Netconf over DTLS/TLS.

However, there are certain cases where netconf is "natively" used (netconf directly over TCP830). These cases will not work when you have "no allow-service netconf".

For example, when we add controller to vmanage netconf is natively used. That is the reason on many guides/ blogs etc. it is written that "disable tunnel-interface when you add vbond/smart to vmanage". Disabling tunnel removes that implicit-access list and any checks. In reality if you allow network service while you have tunnel interface, you can still add vbond/smart to vmanage w/o any issue.

Network Configuration Protocol (NETCONF)

The NETCONF protocol defines a mechanism through which network devices are managed and configured. The SD-WAN Manager uses NETCONF for communication with SD-WAN devices, primarily over DTLS/TLS, but there are a few situations where NETCONF is used natively before DTLS/TLS connections are formed:

●     When any control component (SD-WAN Manager, Validator, or Controller) is added to the SD-WAN Manager, an SD-WAN Manager instance uses NETCONF to retrieve information from them and allows them to be added as devices into the GUI. This might be when initially adding controllers to the SD-WAN Manager, or for incremental horizontal scaling deployments, by adding SD-WAN Manager instances to a cluster or adding additional SD-WAN Controllers or Validators.

●     If any control component reloads or crashes, then that control component uses NETCONF to communicate back to the SD-WAN Manager before encrypted DTLS/TLS sessions are re-formed.

●     NETCONF is also used from the SD-WAN Manager when generating Certificate Signing Requests from control components through the SD-WAN Manager GUI before DTLS/TLS connections are formed. 

NETCONF is encrypted SSH using AES-256-GCM and uses TCP destination port 830.

https://www.cisco.com/c/en/us/td/docs/solutions/CVD/SDWAN/cisco-sdwan-design-guide.html#NetworkConfigurationProtocolNETCONF

[MHM Cisco World]

MHM

[MHM Cisco World]

check this photo

MHM