On Thu, Sep 16, 2010 at 1:31 PM, Mohan Nanduri <mohan.nand...@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.vern...@gmail.com> > wrote: >> >> On Wed, Sep 15, 2010 at 8:50 PM, Richard A Steenbergen <r...@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: >> >> dan...@xxx.xxx> show configuration protocols mpls traceoptions >> file mpls-log size 1m files 10 world-readable; >> flag state; >> flag error; >> flag connection; >> >> dan...@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 >> >> >> dan...@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 <r...@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@puck.nether.net >> > https://puck.nether.net/mailman/listinfo/juniper-nsp >> > >> >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
