Strange OSPF LSA Behavior Question

user101111 · ‎12-13-2018

Can somebody please help me understand why the below LSA doesn't have the "Adv Router is not-reachable" message above it? The Advertising Router IP (172.26.100.2) is in a separate VRF and not in the same RIB as the OSPF process.

router#show ip ospf database external 192.168.100.0

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Type-5 AS External Link States

  LS age: 65
  Options: (No TOS-capability, No DC, Upward)
  LS Type: AS External Link
  Link State ID: 192.168.100.0 (External Network Number )
  Advertising Router: 172.26.100.2
  LS Seq Number: 80001C78
  Checksum: 0x1A4B
  Length: 36
  Network Mask: /26
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 100
        Forward Address: 0.0.0.0
        External Route Tag: 0
		
router#show ip route 172.26.100.2
% Subnet not in table

router#show ip route vrf MANAGEMENT 172.26.100.2

Routing Table: MANAGEMENT
Routing entry for 172.26.100.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via GigabitEthernet0/0/2
      Route metric is 0, traffic share count is 1

Renan Abreu · ‎12-13-2018

You do not need the IP used as the router-id / advertisement router to be reachable.

You can check if that device is reachable by checking show ip ospf border-router.

user101111 · ‎12-13-2018

user101111 · ‎12-13-2018

I'm sorry, I still don't understand how the SPF tree is built to reach 172.26.100.2. How is this node located withing the SPF tree to build a path to the networks attached to it?

router#show ip ospf border-routers detail

            OSPF Router with ID (1.1.1.1) (Process ID 1)


                Base Topology (MTID 0)

Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route

i 172.26.100.2 [2] via 10.10.10.1, TenGigabitEthernet1/0/0, ASBR, Area 0, SPF 33
     Source 172.26.100.2, PDB SPF 34, path flag: none
     Flags: PathList

router#show ip route 10.10.10.1
Routing entry for 10.10.10.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via TenGigabitEthernet1/0/0
      Route metric is 0, traffic share count is 1

Renan Abreu · ‎12-13-2018

You are receiving a Type 4 LSA for that device. If you were to advertise that router-id inside the OSPF process, you would see an LSA Type 1 (or even a 5 depending how you are advertising it), but you would still need to know how to access an external route, thus the information on how to access the ASBR injecting external routes into the network.

user101111 · ‎12-13-2018

All the routers are in Area 0. No other areas are used. I don't see any Type 4 LSAs (ASBR Summary LSA):

router#show ip ospf database asbr-summary

            OSPF Router with ID (1.1.1.1) (Process ID 1)

router#

Renan Abreu · ‎12-13-2018

If you have External routes you need to let the database know how to access them, even though you are only using area 0.

If you only have area 0 you won't see an LSA Type 4, you are right about that, you can disregard the generation of type 4 as you only have that one area.

We still need to do the calculation to find the device injecting the external routes though.

The router-id could have been set if there was an interface with that IP when the OSPF process was created, later on that interface was moved to a VRF but the process will still have that router-id unless you clear it.

As this is not generated by a type 4, I guess you could see something if you run show ip ospf database router 172.26.100.2.

Can you check that?

user101111 · ‎12-13-2018

The IP 172.26.100.2 has always been in VRF MANAGEMENT even before reloads for software upgrades. Here is the requested output:

router#show ip ospf database router 172.26.100.2

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Router Link States (Area 0)

  LS age: 38
  Options: (No TOS-capability, No DC)
  LS Type: Router Links
  Link State ID: 172.26.100.2
  Advertising Router: 172.26.100.2
  LS Seq Number: 8000912A
  Checksum: 0x1ED
  Length: 60
  AS Boundary Router
  Number of Links: 1
  
   Link connected to: a Transit Network
     (Link ID) Designated Router address: 20.20.20.2
     (Link Data) Router Interface address: 20.20.20.1
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

Simon Darlington · ‎12-13-2018

So connected route 172.26.100.2 is in the MANAGEMENT vrf and is therefore not candidate to be selected as the router-id of LSAs (visible as Advertising Router) for the ospf process relating to the global routing table.

This suggests that 172.26.100.2 must also exist on an interface somewhere in the global ospf domain for it to have been selected as a router-id. As Renan has pointed out, router-id 172.26.100.2 need not necessarily be reachable via ospf. This is because a router-id has nothing to do with ospf reachability - it's just a unique identifier for the ospf speaker. Hence why the advertising router doesn't show as unreachable.

Hope this helps. Please rate if it does.

user101111 · ‎12-13-2018

So connected route 172.26.100.2 is in the MANAGEMENT vrf and is therefore not candidate to be selected as the router-id of LSAs (visible as Advertising Router) for the ospf process relating to the global routing table.

I agree with this statement 100%. Yet this is what I am seeing as the output I am providing in this thread shows.

This suggests that 172.26.100.2 must also exist on an interface somewhere in the global ospf domain for it to have been selected as a router-id.

It is 100% not in the global OSPF domain as this output shows:

router#show ip route 172.26.100.2
% Subnet not in table

As Renan has pointed out, router-id 172.26.100.2 need not necessarily be reachable via ospf. This is because a router-id has nothing to do with ospf reachability - it's just a unique identifier for the ospf speaker.

Then how is the "172.26.100.2" node identified/located in the SPF tree in order for 192.168.100.0 to be located and added to the route table of other routers in the OSPF domain as shown below:

router#show ip route 192.168.100.0
Routing entry for 192.168.100.0/26
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
  Last update from 10.10.10.1 on TenGigabitEthernet1/0/0, 4w0d ago
  Routing Descriptor Blocks:
  * 10.10.10.1, from 172.26.100.2, 4w0d ago, via TenGigabitEthernet1/0/0
      Route metric is 20, traffic share count is 1
router#

Simon Darlington · ‎12-13-2018

This suggests that 172.26.100.2 must also exist on an interface somewhere in the global ospf domain for it to have been selected as a router-id.

It is 100% not in the global OSPF domain as this output shows:

router#show ip route 172.26.100.2
% Subnet not in table

> You're absolutely correct it's not in the routing table from ospf. The point being that 172.26.100.2 may be configured on an interface in the global routing table and installed as an ospf router-id (which we're deducing from the cli output of the ospf database you've posted), yet that interface identified 172.26.100.2 is not necessarily advertised into ospf, hence it's not in global routing table as an ospf route.

The distinction we're making between ospf using an IP address for a router-id, separate from any ospf routing advertisement for that same subnet. These are two different mechanisms.