cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1806
Views
0
Helpful
3
Replies
Luciano Vigano'
Beginner

OSPF Route metric

Ciao,

P1R1 is running eBGP

WAN router speaks with eBGP with P1R1 and redistribute it to OSPF process (E1 type); COREx are speaking with WAN via OSPF area 1 (ptp link) and speaking between them via OSPF area 0 (ptp link).

What happened is that CORE2 learn the original eBGP route via WAN and not via CORE1; so I try to add "ip ospf cost" under the interface that link CORE2 via WAN: the cost changed but still learn the route from WAN.

 

CORE2# sh ip route 100.100.100.0

Routing entry for 100.100.100.0/24
  Known via "ospf 10", distance 110, metric 20010
  Tag 5, type extern 1
  Last update from 5.5.5.1 on Ethernet0/3, 00:08:53 ago
  Routing Descriptor Blocks:
  * 5.5.5.1, from 9.9.9.9, 00:08:53 ago, via Ethernet0/3
      Route metric is 20010, traffic share count is 1
      Route tag 5

CORE1#sh ip ro 100.100.100.0
Routing entry for 100.100.100.0/24
  Known via "ospf 10", distance 110, metric 20
  Tag 5, type extern 1
  Last update from 3.3.3.1 on Ethernet0/3, 00:10:50 ago
  Routing Descriptor Blocks:
  * 3.3.3.1, from 9.9.9.9, 00:10:50 ago, via Ethernet0/3
      Route metric is 20, traffic share count is 1
      Route tag 5


When I shut the interface from CORE2 to WAN:

 

CORE2(config-if)#do sh ip ro 100.100.100.0
Routing entry for 100.100.100.0/24
  Known via "ospf 10", distance 110, metric 30
  Tag 5, type extern 1
  Last update from 4.4.4.1 on Ethernet0/2, 00:00:12 ago
  Routing Descriptor Blocks:
  * 4.4.4.1, from 9.9.9.9, 00:00:12 ago, via Ethernet0/2
      Route metric is 30, traffic share count is 1
      Route tag 5


... for sure I'm missing something ... any clues ?

 

Ciao!

L.

3 REPLIES 3
Peter Paluch
Hall of Fame Cisco Employee

Ciao Luciano,

I believe that the "phenomenon" you are experiencing is a direct result of RFC 2328 Section 16.4.1 that discusses preferences of external paths depending on how the ASBR can be reached. Specifically, it says:

            The path preference rules, stated from highest to lowest
            preference, are as follows. Note that as a result of these
            rules, there may still be multiple paths of the highest
            preference. In this case, the path to use must be determined
            based on cost, as described in Section 16.4.

            o   Intra-area paths using non-backbone areas are always the
                most preferred.

            o   The other paths, intra-area backbone paths and inter-
                area paths, are of equal preference.

This would perfectly align with what you see: Because the ASBR, in your case, is the WAN router and it is reachable from Core2 via Area 1 through an intra-area route, the path to external prefixes behind WAN from Core2 will always be preferred via this intra-area route, regardless of its cost.

Best regards,
Peter

 

Dear Peter,

thanks for your suggestion.

Unfortunately it's seems not to be the case. As per your reference it's stated that this behaviour will apply if the RFC1583 check is disabled: I think that on IOS 15.4 it is enabled by default.

Anyway I applied the "no compatibility rfc1583" command under ospf process and nothing changed :(

 

Ciao!

Luciano

Peter Paluch
Hall of Fame Cisco Employee

Ciao Luciano,

You're right. I probably approached the entire issue from an unnecessarily complex angle.

I have recreated your topology in my Dynamips and I can confirm I am observing the same behavior, regardless of the compatibility setting with RFC 1583.

What I now believe happens is actually much simpler than what I supposed is happening. Put very briefly, it all revolves about the fact that the path toward the external network is basically a path toward its advertising ASBR, and from Core2's perspective, the intra-area path to WAN (the ASBR) is always preferred to inter-area path over Core1, just like with any other path in OSPF.

Let's see this in closer detail. In Section 16.4 Step (3), RFC 2328 says (abbreviated):

 

        (3) Call the destination described by the LSA N.  N's address is
            obtained by masking the LSA's Link State ID with the
            network/subnet mask contained in the body of the LSA.  Look
            up the routing table entries (potentially one per attached
            area) for the AS boundary router (ASBR) that originated the
            LSA. [ ... cut ... ]

            Examine the forwarding address specified in the AS-
            external-LSA.  This indicates the IP address to which
            packets for the destination should be forwarded.

            If the forwarding address is set to 0.0.0.0, packets should
            be sent to the ASBR itself. Among the multiple routing table
            entries for the ASBR, select the preferred entry as follows.

 

Notice the underlined words: They require OSPF to look up the already computed path to the ASBR in the internal OSPF RIB. Only if there are multiple already computed paths to the ASBR in the RIB, additional rules from our previous discussion start to apply. Also notice that first, you need to have a path to the ASBR, only then you start building the path to the external networks behind that ASBR.

Now, the route to the ASBR has been computed during intra-area and inter-area route calculation. Recall that if the ASBR is in the same area as the calculating router, the fact that the router is an ASBR is indicated in its LSA-1 using the 'E' bit. If the ASBR is in a different area than the calculating router then its existence will be advertised by means of an LSA-4 originated by an ABR. From the Core2 viewpoint, it has two options of reaching the WAN as an ASBR: Either via an intra-area route, or via an inter-area route via Core1. However, intra-area routes are always preferred, no matter what their cost is. As a result, to Core2, the intra-area path toward WAN as an ASBR is always preferred to the inter-area path via Core1. That is why the OSPF RIB on Core2 will always contain only a single route toward WAN as an ASBR, as also evidenced by the show ip ospf border-routers command output:

 

C2# show ip ospf border-routers

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

        Base Topology (MTID 0)

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

i 192.0.2.2 [50000] via 10.0.23.3, Ethernet2/0, ASBR, Area 1, SPF 19
i 10.0.13.1 [50010] via 10.0.23.3, Ethernet2/0, ABR, Area 1, SPF 19
i 10.0.13.1 [10] via 10.0.12.1, Ethernet2/1, ABR, Area 0, SPF 14


Here, 192.0.2.2 is my WAN router, while 10.0.13.1 is my Core1. Notice the high cost (50000) and the fact that it is labeled as an intra-area route. If I deactivate E2/0 toward WAN, this output will change:

 

C2# show ip ospf border-routers

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

        Base Topology (MTID 0)

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

I 192.0.2.2 [20] via 10.0.12.1, Ethernet2/1, ASBR, Area 0, SPF 15
i 10.0.13.1 [10] via 10.0.12.1, Ethernet2/1, ABR, Area 0, SPF 15

 

Now the route towards 192.0.2.2 has changed to an inter-area route that is significantly cheaper, yet the Core2 did not prefer that option in the past because intra-area routes are always strictly preferred. If I activate E2/0 toward WAN again, this output from RIB will change back to the former output.

It is also noteworthy to observe the output of debug ip ospf spf while reactivating the E2/0. Unfortunately, that output is very large and I cannot paste it here in its entirety but this would be something that you would see there:

*Jun 23 21:07:48.727: %OSPF-5-ADJCHG: Process 1, Nbr 192.0.2.2 on Ethernet2/0 from LOADING to FULL, Loading Done
*Jun 23 21:07:49.259: OSPF-1 SPF  : Detect change in LSA type 1, LSID 192.0.2.2 from 192.0.2.2 area 1      
*Jun 23 21:07:53.843: OSPF-1 INTRA: Running SPF for area 1, SPF-type Full
*Jun 23 21:07:53.847: OSPF-1 INTRA: Initializing to run spf
*Jun 23 21:07:53.851: OSPF-1 INTRA: spf_intra() - rebuilding the tree
*Jun 23 21:07:53.851: OSPF-1 INTRA:  It is a router LSA 10.0.23.2. Link Count 2
*Jun 23 21:07:53.855: OSPF-1 INTRA:   Processing link 0, id 192.0.2.2, link data 10.0.23.2, type 1
*Jun 23 21:07:53.859: OSPF-1 SPF  :    Add better path to LSA ID 192.0.2.2, gateway 10.0.23.3, dist 50000
*Jun 23 21:07:53.863: OSPF-1 INTRA:    Putting LSA on the clist LSID 192.0.2.2, Type 1, Adv Rtr. 192.0.2.2
*Jun 23 21:07:53.867: OSPF-1 SPF  :    Add path: next-hop 10.0.23.3, interface Ethernet2/0

[ ... cut ... ]

*Jun 23 21:07:53.871: OSPF-1 INTRA: Update ASBR Router Route 192.0.2.2 via Ethernet2/0/10.0.23.3, metric 50000, area 1
*Jun 23 21:07:53.871: OSPF-1 SPF  : Added ASBR path to router 192.0.2.2 via 10.0.23.3, area 1, Area SPF 22, PDB SPF 37, Type Full

[ ... cut ... ]

*Jun 23 21:07:53.895: OSPF-1 INTER: Start processing: type 4, LSID 192.0.2.2, mask 0.0.0.0,
*Jun 23 21:07:53.895: OSPF-1 INTER:   adv_rtr 10.0.13.1, age 1932, seq 0x80000003, area 0
*Jun 23 21:07:53.895: OSPF-1 SPF  : Delete  path to router 192.0.2.2 via 10.0.12.1, Area 0, Area SPF 16, PDB SPF 36, SPF Type Prefix Recalculation
*Jun 23 21:07:53.895: OSPF-1 INTER: Entered inter-area route sync for area 0
*Jun 23 21:07:53.895: OSPF-1 INTER: Entered inter-area route sync for area 0
*Jun 23 21:07:53.895: OSPF-1 EXTER: Started Building Type 5 External Routes
*Jun 23 21:07:53.895: OSPF-1 EXTER: Start processing Type 5 External LSA 223.255.255.0, mask 255.255.255.0
*Jun 23 21:07:53.895: OSPF-1 EXTER:  adv_rtr 192.0.2.2, age 1818, seq 0x80000003, metric 1, metric-type 1, fw-addr 0.0.0.0
*Jun 23 21:07:53.895: OSPF-1 SPF  :    Add better path to LSA ID 223.255.255.0, gateway 10.0.23.3, dist 50001
*Jun 23 21:07:53.895: OSPF-1 SPF  :    Add path: next-hop 10.0.23.3, interface Ethernet2/0
*Jun 23 21:07:53.895: OSPF-1 EXTER: Route update succeeded for 223.255.255.0/255.255.255.0, next-hop Ethernet2/0/10.0.23.3

 

Notice how here Core2 says that the intra-area route is "a better path" although the cost is vastly larger. The 223.255.255.0 was my external network.

Because Core2 always has only a single path to the WAN (ASBR) and there are no alternative LSA-5 from different ASBRs that would advertise the same network, there is basically no choice to make: Just one ASBR advertising the external network, just one path toward that ASBR - so that one path takes it all, and because OSPF prefers intra-area paths to inter-area paths, the path toward that ASBR will always go inside the common area between Core2 and WAN.

Would all of this make sense?

Best regards,
Peter