in reply to Strange results from unpack when trying to decode OSPF LSA's from the OSPF MIB

You say that both the LSID and advertising router should have 10 as their first octet when the data is

00 00 22 02 20 01 01 02 20 01 FE 01 80 00 00 10 41 A5 00 20

10 decimal is 0A in hex, but 0A does not appear anywhere in the data. Your statement is either false, or your dump is inaccurate.

In fact, the bytes for the LSID are 20, 01, 01, 02, which corresponds to the decimal numbers 32, 1, 1, 2. That's exactly what your code prints out (32.1.1.2), so there is no error in your code (if your dump is accurate).

  • Comment on Re: Strange results from unpack when trying to decode OSPF LSA's from the OSPF MIB
  • Download Code

Replies are listed 'Best First'.
Re^2: Strange results from unpack when trying to decode OSPF LSA's from the OSPF MIB
by mattedug (Initiate) on Aug 05, 2005 at 00:35 UTC
    Hi,

    Thanks for the reply. I also noticed that but I find it hard to believe that 6 different routers running different operating systems and from two different vendors would give me the same data, i.e. the 32.

    Ethereal has the same hex data for the ospfLsdbAdvertisement from the devices as my dump.

    I've also checked the LSDB's in the routers themselves and they're reporting the correct data, as expected.

    Any other ideas? Do you think the decode looks okay?

    thanks, Matt
      Do you think the decode looks okay?

      I have no idea what OSPF, LSDB or LSA means. All I know is that your data is consistent with your dump.

        Hi,

        Thanks for the reply, it's good to hear some feedback re: valid decoding. I love your scratchpad btw, great stuff.

        Here's a five second OSPF headsup if you're interested:

      • OSPF - Open Shortest Path First, routing protocol that uses the dijkstra algorithm.
      • LSA - Link State Advertisement, topology-related data sent between routers running OSPF.
      • LSDB - The Link-State Database, held by routers running OSPF and describes a topology.

        Thanks once again, Matt.