Information about IOS XR Bug

[yansenyansen]

Hi,

i would like to ask about the detail about IOS XR bug infomation. i found some unclear detail stated on IOS bug toolkit.

[Quote]

1.

CSCub95284 : enable bfd in racetrack path on typ

detail : enable bfd in racetrack path on typ

symptoms:

bfd was not implemented in racetrack path causing bfd drops at line rate traffic.

Conditions:

when traffic is sent at line rate.

Question : what does ractrack path on typ mean? 

                 does the line rate traffic refer the througput of the interface ?

[/quote]

[yansenyansen]

Another question :

CSCud58454

"

BGP process crash on Active RSP while commiting scale config.

Question : what does scale config means ?

[Nicolas Fevrier]

Hi,

I'm not sure the support forum is the best place to cover DDTS details.

I advise you contact your Cisco representatives to discuss it.

Kind regards,

N.

[yansenyansen]

Hi,

Yes you are right. i just want to know if anoyone can share some explanations, do not to be detail. Thanks.

BR.

[Nicolas Fevrier · Accepted solution]

Hello,

in this case, large scale means "removing a very large quantity of VRFs config and BGP sessions config in one single commit" and the DDTS specifies that it is under very rare conditions, so, very likely unreproducible for most of the situations.

KR,

N.

[yansenyansen]

Hi Nicholas,

Thanks for Your explanation . Do you have any idea about " bfd in racetrack path on typ" ?

BR

[xthuijs]

when packets are received by the NPU there is a decission to be made, whether to forward or locally consume.

When locally consumed it can be directed via the process level switching (aka netio) or it get be sent directly to a "handler" on say the LC CPU (which is the case for PPP keeps, netflow, bfd, arp, cfm for instance). This is what IOS called interupt switching.

Now when the NPU is running near max performance, in terms of pps it can handle, we need to maintain priority for these important packets, especially BFD, as it is timing sensitive and doesn't deal with packet loss that well .

This is for the receive path.

For the inject path of BFD we call it inject to wire, what IOS called pak priority.

still the packet goes through the pipeline, just features are not applied. Still if the pipeline is clogged, we need to ensure

priority treatment for those packets.

That is what this ddts ensures. Good treatment for those BFD packets under high load conditions.

Make sure you read the write up on BFD we have on the support forums. Echo requires QOS config, as the responses are going through the fabric and ARE subject to fetures (including QOS).

The BFD story I had above, mainly applies to async.

regards

xander

[yansenyansen]

Hi Xander,

Thanks for Your explanation. in this case, do we need to implement Qos To prioritize BFD . last time i tested using traffic generator and created around 400 bfd session. for those sessions consumed around 6 Mpbs.

BR

[xthuijs]

For async no need for qos, but for echo you need QOS configured to prioritize the incoming echo responses and egress to prioritize the echo replies also.

ASYNC natively is "protected" by the punt path with inject to wire and interrupt punt. Same for the echo request (injected same deal)

Mind you that BFD is mainly limited by the LPTS policer of I thought it was 9600 pps in earlier releases, 14k something in alter releases (check the lpts policers). Yuo will want to make sure that hte number of sessions with multiplier/interval remains within that pps limit.

bps is not a factor.

regards

xander

[yansenyansen]

can i know what is the reason we don't need qos for async. my understanding the async mode will transmits periodically BFD Control packets, if we don't configure QoS, those packets could be dropped if the link congested.

btw, Thanks for Your kind sharing for Cisco Live. i am waiting Your presentation on Ciscolive365 .

[xthuijs]

You're most welcome!! Nice to hear you enjoyed it! Yeah the video and preso should be posted sometime soon I was told!

Say for your question, good one by the way, the echo replies are sent via the fabric, async is locally consumed.

I have a picture that hopefully clarifies where QOS is needed in general.

Ingress QOS is optional, and useful when the pipeline is getting clogged, so we prioritize and wont drop incoming async or echo.

egress QOS is not needed for echo requests or async injection, as they are done to wire (pak priority).

regards

xander

[yansenyansen]

Awesome! This makes me more understand about bfd

Thanks