Greetings,
We are developing a service to provision dedicated internet access circuits for customers. The service is using a template and python code to generate the configuration. We're running into an issue on certain ASR920 devices when committing the service. When the service is committed, a required VFI/xconnect used for management is brought down. Through troubleshooting, we determined that the VFI goes down due to the order of commands pushed out by NSO. I am including an excerpt of the dry-run configuration which exhibits the issue.
interface GigabitEthernet0/0/1
description NSO Test 2 (I-NET)
ethernet uni id UNI-SM-METRO-SW1-G0_0_1-9250365
service instance 10 ethernet
description NID Management Service Instance
encapsulation dot1q 10
rewrite ingress tag pop 1 symmetric
exit
exit
bridge-domain 182
member GigabitEthernet0/0/1 service-instance 182
member TenGigabitEthernet0/0/24 service-instance 182
!
interface GigabitEthernet0/0/1
service instance 10 ethernet
bridge-domain 10 split-horizon group 1
exit
exit
When configuring the interface on this device, NSO enters the interface configuration, also entering service instance 10 on said interface. 3/4 of the commands under service instance 10 are applied, and then NSO backs out of the service instance and interface configuration to configure bridge-domain 182. It then goes back into the interface and service instance 10 to apply the split-horizon group. We verified through TACACS logs that this is indeed the order of commands NSO uses.
When tracing through these commands manually, we found that configuring the split-horizon group along with the other 3 commands under the service instance does not bring down the VFI. Configuring the split-horizon group separately as NSO does will bring down the VFI.
At this point we're looking for some direction. Some solutions we discussed:
- TAC case for the equipment due to the VFI being brought down by the split-horizon command
- TAC case for the NED to check the order of the commands produced by NSO
- Probably only necessary if the VFI going down is expected behavior
- Modify the service such that the commands are applied in the correct order.
- We tried doing this by modifying the template, and also by splitting the template, but since everything is done in the same commit this has no effect.
- Split the service such that the NID management configuration is applied through a separate service.
Has anyone run into a similar issue? Any suggestions or topics to research to sort this out?
