10-02-2018 06:55 AM
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:
Has anyone run into a similar issue? Any suggestions or topics to research to sort this out?
Solved! Go to Solution.
10-02-2018 07:32 AM
The (correct) way forward depends on if the behaivour of the device is the expected one? I mean is it a device bug or is this the way it is supposed to be?
Anyway... the way to change the order of the commands sent from NSO is to update the NED. So I guess that even if it is a device bug the quickest way forward would be to get the NED updated.
10-02-2018 07:32 AM
The (correct) way forward depends on if the behaivour of the device is the expected one? I mean is it a device bug or is this the way it is supposed to be?
Anyway... the way to change the order of the commands sent from NSO is to update the NED. So I guess that even if it is a device bug the quickest way forward would be to get the NED updated.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide