[quagga-dev 10149] Re: Opaque LSA question
equinox at opensourcerouting.org
Mon Jan 7 14:15:31 GMT 2013
On Thu, Dec 20, 2012 at 05:52:42PM -0800, Certain, Andrew wrote:
> According to the OSPF Opaque LSA RFC (http://tools.ietf.org/html/rfc5250), the O-bit in the options field should only be set for database description packets:
> A neighbor is opaque-capable if and only
> if it sets the O-bit in the Options field of its Database Description
> packets; the O-bit SHOULD NOT be set and MUST be ignored when
> received in packets other than Database Description packets. Using
> the O-bit in OSPF packets other than Database Description packets
> will result in interoperability issues. The setting of the O-bit is
> a "SHOULD NOT" rather than a "MUST NOT" to remain compatible with
> earlier specifications.
> Even the earlier RFC (http://tools.ietf.org/html/rfc2370) reads, "A neighbor is opaque-capable if and only if it sets the O-bit in the Options field of its Database Description packets; the O-bit is not set in packets other than Database Description packets." So I'm not sure what "earlier specifications" RFC5250 is trying to remain compatible with.
> But Quagga sets the O-Bit in LSAs for all opaque LSAs (see ospf_apiserver.c: ospf_apiserver_opaque_lsa_new() and ospf_te.c: ospf_mpls_te_lsa_new()) and expects it set (under STRICT_OBIT_USAGE_CHECK) for incoming opaque LSAs (see ospf_packet.c: ospf_ls_upd_list_lsa()). Am I misinterpreting the spec (e.g. do LSAs not count as "packets?") or is this a bug?
I think you're reading this right, and I think I actually hit this as an
interop bug between Force10 and Quagga, where the former was dropping
the latter's OSPF Hellos since they had the O bit set...
Thanks for the report. This should be rather easy to fix...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 230 bytes
Desc: Digital signature
More information about the Quagga-dev