problem with ospf mib and ospf interfaces

[Arnold, Gilad]

Hi,

I'm reporting a problem with OSPF MIB Interface Table, but in fact this
problem implies an inconsistency between Zebra ospfd design and OSPF
MIB, rather than a MIB implementation bug:

- OSPF MIB, and ospf_snmp.c implementing it, relate to an OSPF interface
  as such that matches a router's interface, just from OSPF
  point-of-view. That is, the OSPF Interface Table should have a single
  entry per each physical system interface that participates in OSPF,
  and that entry is identified by a single IP address, specifically the
  interface's primary IP address (or the ifindex in case of un-numbered
  links, what implies that OSPF designers indeed meant this table to be
  link-oriented).

  In the code, this can be seen by the definition of 'struct
  ospf_snmp_if', and the interface list 'ospf_snmp_iflist': This list
  has one element for each system reported interface, with one of its IP
  addresses (connected network source address) as identifier.
  
- On the other hand, Zebra ospfd uses a finer resolution for OSPF
  interfaces, one that associates an interface with IP prefix (and not
  necessarily an interface). This way, it is possible to have OSPF
  running for one of the prefixes of an interface (that is, have an
  "abstract OSPF interface" with this prefix as identifier) while other
  prefixes may or may not participate in OSPF (that is, not have an
  "abstract OSPF interface").

  BTW, I believe this feature was added somewhere between versions 0.91a
  and 0.92a of Zebra. Cisco, for example, sticks to the resolution of
  physical interfaces identified by their primary IP address, when
  defining OSPF interfaces (or so it is understood from Cisco IOS
  documentation).

Sample instance of the problem arises when we use OSPF for an
interface's alias IP prefix, but not for its primary prefix. Clearly,
performing snmpget for the OSPF Interface Table with the alias IP
address as index results in nothing, since there's no interface
associated with that address in ospf_snmp_iflist. Moreover, performing
snmpget for the OSPF Interface Table with the _primary_ IP address as
index results in...  nothing; Indeed, this time an ospf_snmp_if element
is found, but there's no matching "abstract OSPF interface" ('struct
ospf_interface') with the same IP address. Hence, there's no way of
accessing the interface entry.

Apparently, this problem can be "solved" if we extend ospf_snmp_if to
hold a _list_ of interface IP addresses, and try to match any of those
addresses against any ospf_interface held under ospf_top; however, it
may be in Zebra ospfd that more than one "abstract OSPF interface" is
associated with a physical interface, so there's the question of which
interface entry should the index return?

Another solution could be adjusting the Interface Table implementation
to Zebra ospfd "abstract interfaces" behavior: Extend ospf_snmp_iflist
to include one element for each ospf_interface element, instead of
physical interface, this way producing a table entry for each "abstract
OSPF interface".  However, this misses the intended nature of the
Interface Table, as presented in OSPFv2 definition (RFC2328, Appendix
C.3) and OSPFv2 MIB.


Zebra version: CVS update as of 2002-01-23 (today).
OS: RedHat Linux 2.2.16-22 on i686 machine.

I hope the description above is correct and accurate enough to
understand (I can get closer to the code, as necessary, to demonstrate
what I'm talking about). Your comments and welcome.

Regards, G.