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

[steve carell]

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

[xthuijs]

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

[steve carell]

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

[Charles Patrick]

hi

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

charles

[xthuijs · Accepted solution]

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

[steve carell]

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 :-)

[xthuijs]

good to hear you can continue Steve!

yes let us know if you see this again!

cheers!

xander