[j-nsp] logging cspf/bandwidth reservation failures

[Danny Vernals]

On Thu, Sep 16, 2010 at 1:31 PM, Mohan Nanduri <mohan.nanduri at gmail.com> wrote:
> There was an ER opened a while back to identify the node/interface from
> where the requetsed BW is unavailable message is being generated from at the
> head-end to aid better troubleshooting, not sure if it was ever implemented.
>
>

IIRC all of this is local to the ingress LSR, it is a result of a CSPF
calculation failing to find a suitable path rather than a downstream
node notifying upstream of a lack of bandwidth on a requested path.

When CSPF runs, all links that don't fit the specified constraints are
removed and then a simple SPF calculation is performed on the
remaining links.  If there is no valid path to the destination found
you get the "CSPF: no route to " or "bandwidth unavailable" messages.
Presumably the only difference in these messages is what called CSPF
(optimize timer expiry for "CSPF: no route to " and auto-bandwidth
adjust-interval or overflow for "bandwidth unavailable").

To me anyway it seems a non trivial task to equate a CSPF failure to a
single link or network element.

Cheers!

Danny

> On Thu, Sep 16, 2010 at 4:36 AM, Danny Vernals <danny.vernals at gmail.com>
> wrote:
>>
>> On Wed, Sep 15, 2010 at 8:50 PM, Richard A Steenbergen <ras at e-gerbil.net>
>> wrote:
>> > Is there a way to syslog a cspf or rsvp bandwidth reservation failure?
>> > Maybe I'm just being really blind here, but I can't find a way to do it.
>> > You can see these events in the cspf logs if you look at individual LSPs
>> > with "show mplslsp NAME detail":
>> >
>> >   1119 Sep 15 19:32:11.635 CSPF failed: no route toward x.x.x.x[87
>> > times]
>> >   1118 Sep 15 18:50:14.902 Clear Call: CSPF computation failed
>> >   1117 Sep 15 18:50:14.895 Deselected as active
>> >   1116 Sep 15 18:50:14.895 x.x.x.x: Requested bandwidth unavailable
>> >
>> > But this seems like it should be syslog worthy, especially considering
>> > it's already sysloging worthless stuff like bandwidth changes by default
>> > too. Am I missing a sensible way to do this, or is this just in need of
>> > a feature request? Cisco definitely does it:
>> >
>> > Sep 15 19:40:36.458 UTC: %MPLS_TE-5-LSP: LSP x.x.x.x 20554_1024: Path
>> > Error from x.x.x.x: Admission control Failure (code 1, value 2, flag
>> >
>>
>> Not exactly what you're after but you can achieve this kind of
>> verbosity with traceoptions.  We have the below on all the time:
>>
>> dannyv at xxx.xxx> show configuration protocols mpls traceoptions
>> file mpls-log size 1m files 10 world-readable;
>> flag state;
>> flag error;
>> flag connection;
>>
>> dannyv at xxx.xxx> show mpls lsp extensive | grep unavaila
>>   8181 Sep 16 07:33:40.487 x.x.x.x Requested bandwidth unavailable:
>> re-optimized path
>>   8179 Sep 16 07:33:40.487 x.x.x.x: Requested bandwidth unavailable
>>
>>
>> dannyv at xxx.xxx> show log mpls-log | grep unavaila
>> Sep 16 07:33:40.487521 mpls lsp LSP-NAME primary x.x.x.x: Requested
>> bandwidth unavailable
>> Sep 16 07:33:40.487586 mpls lsp LSP-NAME primary x.x.x.x Requested
>> bandwidth unavailable: re-optimized path
>>
>>
>> > --
>> > Richard A Steenbergen <ras at e-gerbil.net>
>> > http://www.e-gerbil.net/ras
>> > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
>> > 2CBC)
>> > _______________________________________________
>> > juniper-nsp mailing list juniper-nsp at puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>