Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Commit took long time to take effect..approx 20 min in CRS- 4.1.2

Hi,

CRS 4.1.2 after adding some change in interface, Commit took 20 min to take effect. what could be the reason ?

Thanks

Steve

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Commit took long time to take effect..approx 20 min in CRS- 4.1.

aha, ok, that is a bit more detail I can work with. It would be good to know what the show configuration failed comes back with in terms of the actual error.

I did a few searches into the known issues relating to bundle QOS and CRS commits, and there are quite a few that seem to be applicable to the situation you guys report.

Info such as sh fmgr trace all reverse loc all would also help identifying the precise culprit potentially and I see some possible workarounds that have worked on occasion being a proc restart on qos_ea location

Also if you do this and have access to another VTY/terminal, a show process blocked may help to see what it is doing or a debug qos-ea/ma to follow events.

Either case, based on the number of issues I see in the release you are running 4.1 it might be worth considering a different release?

regards

xander

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
6 REPLIES
Cisco Employee

Commit took long time to take effect..approx 20 min in CRS- 4.1.

Hi Steve,

a little too less detail to say for sure. what config change were you trying to make?

there are some scenarios that are knowingly time consuming, like LARGE acl reconfigurations that are applied to multiple itnerfaces for isntance.

xander

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
New Member

Commit took long time to take effect..approx 20 min in CRS- 4.1.

Thanks Alexander.

Basically i was shifting the port in bundle-ether and before that i removed the service policy from bundle-ether interface and re-applied the service policy back and commit which took long time.

RP/0/RP1/CPU0:cala#config t

RP/0/RP1/CPU0:cala(config)#router ospf 2

RP/0/RP1/CPU0:cala(config-ospf)#area 0.0.0.7

RP/0/RP1/CPU0:cala(config-ospf-ar)#interface Bundle-Ether1046

RP/0/RP1/CPU0:cala(config-ospf-ar-if)#cost 12080

RP/0/RP1/CPU0:cala(config-ospf-ar-if)#cost-fallback 40000 threshold 185$

RP/0/RP1/CPU0:cala(config-ospf-ar-if)#exit

RP/0/RP1/CPU0:cala(config-ospf-ar)#exit

RP/0/RP1/CPU0:cala(config-ospf)#!

RP/0/RP1/CPU0:cala(config-ospf)#!

RP/0/RP1/CPU0:cala(config-ospf)#interface Bundle-Ether1046

RP/0/RP1/CPU0:cala(config-if)# service-policy input core_policy_4q_grp_$

RP/0/RP1/CPU0:cala(config-if)# service-policy output core_policy_4q_exp$

RP/0/RP1/CPU0:cala(config-if)#

RP/0/RP1/CPU0:cala(config-if)#show configuration

Building configuration...

!! IOS XR Configuration 4.1.2

interface Bundle-Ether1046

service-policy input core_policy_4q_grp_input

service-policy output core_policy_4q_exp_output

!

router ospf 2

area 0.0.0.7

  interface Bundle-Ether1046

   cost 12080

   cost-fallback 40000 threshold 185000

  !

!

!

end

RP/0/RP1/CPU0:cala(config-if)#commit <<<<<< Console stuck..time out / Commit unsuccessful

Steve

New Member

Commit took long time to take effect..approx 20 min in CRS- 4.1.

hi

I also have this similar problem when i was adding or removing service policy from bundle-ether in crs 4.1.2

charles

Cisco Employee

Commit took long time to take effect..approx 20 min in CRS- 4.1.

aha, ok, that is a bit more detail I can work with. It would be good to know what the show configuration failed comes back with in terms of the actual error.

I did a few searches into the known issues relating to bundle QOS and CRS commits, and there are quite a few that seem to be applicable to the situation you guys report.

Info such as sh fmgr trace all reverse loc all would also help identifying the precise culprit potentially and I see some possible workarounds that have worked on occasion being a proc restart on qos_ea location

Also if you do this and have access to another VTY/terminal, a show process blocked may help to see what it is doing or a debug qos-ea/ma to follow events.

Either case, based on the number of issues I see in the release you are running 4.1 it might be worth considering a different release?

regards

xander

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
New Member

Commit took long time to take effect..approx 20 min in CRS- 4.1.

Thanks Xander.

We finally reloaded the entire router and tried the same .. this time it works fine.

Also , good to know about the captures which you recommended. I have few more routers to do this same job and will consider your recommendation to check.Thanks again for your inputs.

Will come back to you if i will get this error again :-)

Cisco Employee

Commit took long time to take effect..approx 20 min in CRS- 4.1.

good to hear you can continue Steve!

yes let us know if you see this again!

cheers!

xander

Xander Thuijs CCIE #6775 Principal Engineer ASR9000, CRS, NCS6000 & IOS-XR
227
Views
5
Helpful
6
Replies
CreatePlease to create content