cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
43
Views
0
Helpful
2
Replies
khgrant
Cisco Employee

Juniper device takes extremely long time to complete transaction

 

Hi experts,

 

 

We’re testing NSO services on both Cisco IOS-XR and Juniper devices.

 

When testing on Juniper, we saw that we were able to deploy the service to the device, but on removal, it seems that we’re being timed out.

 

 

While creating the service didn’t take long, and while removing the configurations directly from the device didn’t take long as well (using rollback), the process of removing the configurations via NSO seems to take a very long time.

 

We eventually raised the device timeout on NSO to 20 minutes, so that a 19 minutes’ transaction could be completed.

 

 

The service itself generates a pretty big rpc call, but as mentioned, the creation of the service didn’t take that long to be applied to the device and didn’t exceed the default timeout.

 

So, it makes us wonder if this 19 minutes’ transaction maybe can be avoided.

 

 

Can anybody think of a reason why a transaction might take so long, and if there are device or RPC parameters that can tweaked in order to mitigate this?

 

 

Thanks,

 

Yftach

 

2 REPLIES 2
khgrant
Cisco Employee

 

Hi Yftach,

 

 

Best to raise this with the NED team.

 

 

Do we know where all the time is being spent? Any clues in the device traces?

 

 

For CLI based NED I’ve seen incorrect modelling may cause timeouts – example for a given node, not enough exits when moving to top node causing the NED to timeout. However, for NETCONF NEDs there isn’t any extra custom logic per NED.

 

 

Thanks,

  Bilal.

 

khgrant
Cisco Employee

 

Hi Bilal,

 

 

I am also involved with the question raised by Yftach. Unfortunately that´s not the case (NED issue) as we tested pushing the config using netconf-console tool (so no NSO/NED involved) with a modified RPC call. That modified RPC call only put the config into candidate state (without pushing it into running) and that process alone took around 18mins (the end device sending its OK for the candidate config). That was the rationale followed by Cisco TAC engineer -> No need to escalate with NED unit.

 

So all points now to the device being slow, putting us in a awkward position as it´s not reasonable that a device takes 18mins just to process a config into candidate state. We tested this on two devices Juniper MX480 and M10i with Junos 13.R3 with the same outcome L

 

Has anyone had similar issues with Juniper or any other device being so slow? Any advice on this, please?

 

 

Thanks in advance

 

Content for Community-Ad

This widget could not be displayed.