Friday, June 27, 2014

OSPF Loopback Network Type Advertisement



OSPF uses different types of networks to efficiently form neighbors in respect to the media that connects it to them.

These networks can be categorized as three main types.
  • Broadcast
  • Point to Point
  • Non-Broadcast Multi-Access (NBMA)

Yet one interface isn’t by default categorized as any of the above mentioned which is our beloved loopback address. The reason is Loopback is a logical interface that doesn’t carry transient traffic, it is initially used to route traffic from the router to itself or to terminate incoming traffic to the router itself, Thus; loopback advertisements by default are always generated as an Intra-Area /32 Stub host with a metric of 1

Let’s check the below topology




R3 is advertising the Loopback interface to ospf via a network or interface command directly. The IP configured under the loopback interface is 3.3.3.3/24.
Let’s first check the configuration on R3 and how it generated an LSA for that loopback address

R3#
interface Loopback0
 ip address 3.3.3.3 255.255.255.0
 ip ospf 1 area 1



R3#show ip ospf inter lo0
Loopback0 is up, line protocol is up
  Internet Address 3.3.3.3/24, Area 1
  Process ID 1, Router ID 3.3.3.3, Network Type LOOPBACK, Cost: 1
  Enabled by interface config, including secondary ip addresses
  Loopback interface is treated as a stub Host



R3#show ip ospf database router 3.3.3.3 self-originate

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

                Router Link States (Area 1)

  LS age: 557
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 3.3.3.3
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000003
  Checksum: 0x2387
  Length: 48
  Number of Links: 2

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.0.23.3
     (Link Data) Router Interface address: 10.0.23.3
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 3.3.3.3
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

Let’s also check how the other routers see this network

R1#show ip route 3.3.3.3
Routing entry for 3.3.3.3/32
  Known via "ospf 1", distance 110, metric 21, type inter area
  Last update from 10.0.12.2 on FastEthernet0/0, 00:00:04 ago
  Routing Descriptor Blocks:
  * 10.0.12.2, from 2.2.2.2, 00:00:04 ago, via FastEthernet0/0
      Route metric is 21, traffic share count is 1



R1#show ip ospf database summary 3.3.3.3

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

                Summary Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 77
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 3.3.3.3 (summary Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0x31EC
  Length: 28
  Network Mask: /32
        TOS: 0  Metric: 11



From the above outputs, there are two things to notice here.

·         As stated in OSPF RFC#2328 page 225, the host routes is advertised as a router-LSA stub network with a hexa mask of 0xFFFFFFFF (255.255.255.255) and they indicate the router interfaces or looped router interfaces. Which tells why it was advertised as a /32 subnet
·         The other thing to notice in the output is that it is linked to two networks. A stub network, which we already discussed and to a transient network which is the IP address of the physical interface of the router connected to R3.
This is because if an incoming packet is destined to the router itself through physical interface, the network is attached to the through that physical interface

There are several ways to change this behavior

1.       Change the loopback OSPF network Type à will be advertised as configured mask and propagates in a Router-LSA
2.       Summarize the route to the desired network mask on an ABR à depending if this loopback is in a different area or not, will be propagated in a Summary-LSA
3.       Redistribute the loopback address to OSPF instead of using the network command à will be flooded with it’s configured subnet mask in an External-LSA

Let’s apply each one of the three solutions

1.      Solution 1 – change the OSPF network type under the loopback interface

We’ll begin by configuring the loopback interface as an OSPF point-to-point, one thing to notice here is that the only manual applicable network type is point to point. The broadcast, non-broadcast and point-to-multipoint are not allowed to be configured on loopback interface

interface Loopback0
 ip address 3.3.3.3 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 1

Now let’s do our checks again



R3#show ip ospf inter loopback 0
Loopback0 is up, line protocol is up
  Internet Address 3.3.3.3/24, Area 1
  Process ID 1, Router ID 10.0.23.3, Network Type POINT_TO_POINT, Cost: 1
  Enabled by interface config, including secondary ip addresses
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 0
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)



R3#show ip ospf database router 3.3.3.3 self-originate

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

                Router Link States (Area 1)

  LS age: 32
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 3.3.3.3
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000004
  Checksum: 0xD4D8
  Length: 48
  Number of Links: 2

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.0.23.2
     (Link Data) Router Interface address: 10.0.23.3
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 3.3.3.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

The network is still advertised as a Stub, but notice how the subnet mask is now changed to /24 as configured under the loopback interface.

2.      Solution 2 – Summarize the loopback route to the desired network mask at an ABR

R2 Is an ABR between Area 0 and Area 1, we can summarize the network 3.3.3.3/32 into a bigger network /24. Even though it’s a viable workaroud, but the fact remains that this is a very poor way to resolve the issue and can introduce various problems in your network. Unless you exactly know every little detail about your network architecture, don’t start summarizing single host routes here and there otherwise it will be a mess.

R2#show ip route 3.3.3.3
Routing entry for 3.3.3.3/32
  Known via "ospf 1", distance 110, metric 11, type intra area
  Last update from 10.0.23.3 on FastEthernet0/0, 00:09:25 ago
  Routing Descriptor Blocks:
  * 10.0.23.3, from 3.3.3.3, 00:09:25 ago, via FastEthernet0/0
      Route metric is 11, traffic share count is 1

Now let’s summaries that route into a /24 and propagate it to Area 0

R2(config)#router ospf 1
R2(config-router)#area 1 range 3.3.3.0 255.255.255.0

Checking R2 database after summarization

R2#show ip ospf database summary 3.3.3.0 self-originate

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

                Summary Net Link States (Area 0)

  LS age: 113
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 3.3.3.0 (summary Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0x4FD1
  Length: 28
  Network Mask: /24
        TOS: 0  Metric: 11



R2#show ip route
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/11] via 10.0.12.1, 00:04:01, FastEthernet0/1
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback0
     3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O       3.3.3.3/32 [110/11] via 10.0.23.3, 00:04:01, FastEthernet0/0
O       3.3.3.0/24 is a summary, 00:04:01, Null0
     10.0.0.0/24 is subnetted, 2 subnets
C       10.0.12.0 is directly connected, FastEthernet0/1
C       10.0.23.0 is directly connected, FastEthernet0/0


And here’s what R1 see

R1#show ip route 3.3.3.0
Routing entry for 3.3.3.0/24
  Known via "ospf 1", distance 110, metric 21, type inter area
  Last update from 10.0.12.2 on FastEthernet0/0, 00:03:40 ago
  Routing Descriptor Blocks:
  * 10.0.12.2, from 2.2.2.2, 00:03:40 ago, via FastEthernet0/0
      Route metric is 21, traffic share count is 1


3.      Redistribute the loopback address in OSPF

We’ll go directly under OSPF and redistribute all the connected interfaces since we only have the loopback and the interface towards R2. Of course it’s recommended to filter the undesired networks during the redistribution, but we’ll skip that for the sake of simplicity.

R3#show run int lo0
interface Loopback0
 ip address 3.3.3.3 255.255.255.0

router ospf 1
redistribute connected subnets

and finally, R3 is now flooding an external LSA for 3.3.3.0/24

R3#show ip ospf database external 3.3.3.0 self-originate

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

                Type-5 AS External Link States

  LS age: 139
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 3.3.3.0 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000001
  Checksum: 0x216A
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0


And here’s how R1 see it

R1#show ip route 3.3.3.0
Routing entry for 3.3.3.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20
  Last update from 10.0.12.2 on FastEthernet0/0, 00:04:09 ago
  Routing Descriptor Blocks:
  * 10.0.12.2, from 3.3.3.3, 00:04:09 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1


Notice that by default, OSPF redistributes external network as a Type-2 with a seed metric of 20. So depending on your design, make sure you convert that to Type-1 if you need that metric to increment throughout your network.



OSPF Sham-Link

A common scenario is when a company has two sites and those sites are in the same OSPF area, whilst the two sites has two connections, the first one is through a service provider which is running MPLS and MP-BGP to connect the two sites together and the other connection is a direct connection between the two sites, it’s also called a Backdoor link.

By default, OSPF prefers the Intra-Area LSAs over the Inter-Area LSAs. This can cause traffic to prefer the backdoor link over the one through the provider MPLS because when OSPF is used as a PE-CE routing protocol, the PE router acts as an ABR that is connected to area 0 ( Super Backbone) between the two sites. Even though the two sites might be in the same area and not contiguous because of the super backbone, BGP can handle the information carried from one site to the other without the need for a virtual-link.

The solution to this is the sham-link which is a logical link that is treated as if it’s a normal OSPF link between two routers, which is included in the SPF algorithm calculations and OSPF topology table.

In the below topology, CE-A2 and CE-B2 are both connected to the ISP through E0/0 interfaces with a capacity of 10 Mb and to each other via a  backdoor link through E0/2 interface with a capacity of 5 Mb.





Assuming that OSPF has been fully converged and MP-BGP has propagated the routes between all sites. Let’s first check what CE-A2 sees in its routing table

CE-A2#show ip route

      20.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O IA     20.2.2.2/32 [110/21] via 40.0.12.1, 00:01:45, Ethernet0/0
      40.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C        40.0.12.0/24 is directly connected, Ethernet0/0
L        40.0.12.2/32 is directly connected, Ethernet0/0
O        40.0.22.0/24 [110/1020] via 50.0.0.2, 00:01:40, Ethernet0/1
C        40.2.2.2/32 is directly connected, Loopback0
O        40.3.3.3/32 [110/1001] via 50.0.0.2, 00:01:40, Ethernet0/1
      50.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        50.0.0.0/24 is directly connected, Ethernet0/1
L        50.0.0.1/32 is directly connected, Ethernet0/1


Also let’s Check how PE2 is handling those routes

PE2#show ip bgp vpnv4 vrf a 
BGP table version is 75, local router ID is 20.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found


     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf a)
 *>  20.2.2.2/32      0.0.0.0                  0         32768 ?
* i 40.0.12.0/24     20.3.3.3              1030    100      0 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  40.0.22.0/24     40.0.12.2             1030         32768 ?
 * i                  20.3.3.3                 0    100      0 ?
 * i 40.2.2.2/32      20.3.3.3              1011    100      0 ?
 *>                   40.0.12.2               11         32768 ?
 *>  40.3.3.3/32      40.0.12.2             1011         32768 ?
 * i                  20.3.3.3                11    100      0 ?
 * i 50.0.0.0/24      20.3.3.3              1010    100      0 ?
 *>                   40.0.12.2             1010         32768 ?

You can also see why BGP preferred the route with a higher metric, since OSPF already preferred the Intra-Area Route with metric 1000. BGP extensions for OSPF as a PE-CE protocol tends to preserve the metrics of the best route found in the OSPF data base, that’s why the weight attribute was increased to the max to make sure that whatever the metric OSPF route has, it will be the one carried through BGP.

PE2#show ip bgp vpnv4 vrf a 40.3.3.3
BGP routing table entry for 1:1:40.3.3.3/32, version 97
Paths: (2 available, best #1, table a)
  Advertised to update-groups:
     1        
  Refresh Epoch 1
  Local
    40.0.12.2 from 0.0.0.0 (20.2.2.2)
      Origin incomplete, metric 1011, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x0000000A0200
        OSPF RT:0.0.0.1:2:0 OSPF ROUTER ID:20.2.2.2:0
      mpls labels in/out 19/nolabel
  Refresh Epoch 1
  Local
    20.3.3.3 (metric 20) from 20.3.3.3 (20.3.3.3)
      Origin incomplete, metric 11, localpref 100, valid, internal
      Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x0000000A0200
        OSPF RT:0.0.0.1:2:0 OSPF ROUTER ID:40.0.22.1:0
      mpls labels in/out 19/29

Even though the cost of the backdoor link is 1000, which is way more than the link to the MPLS core, it is still preferred since that LSAs received from the CE neighbor is an Intra-Area LSA.

The problem here is that the backdoor link can only handle very little traffic and it’s created in case the service provider suffered an outage or some sort of network failure, which makes it a backup link. So it doesn’t make any sense for it to handle all the traffic in normal network operation.

To solve this issue, let’s create a sham-link between the two PE routers. But before we do that there’s a caveat that has to be considered for the sham-link to be activated properly.

Sham-link identifier IPs must be advertised through MP-iBGP neighbors only and it must be a /32 IPs, the reason for that is OSPF has a lower administrative distance that iBGP, so if it is advertised through OSPF, PE router will prefer the route to the sham-link peering IP through OSPF which by turn will makes the sham-link goes down, then PE routers will again revert to the sham-links identifier IPs through BGP and as soon it comes up, it will prefer the OSPF which will result in a continuous flapping of the sham link. That’s why you should never advertise the sham-link through OSPF.

PE2#

interface Loopback20
 ip vrf forwarding a
 ip address 20.22.22.22 255.255.255.255

router bgp 1
 address-family ipv4 vrf a
   network 20.22.22.22 mask 255.255.255.255
   redistribute ospf 10 match internal external 1 external 2 nssa-external 1 nssa-external 2

router ospf 10 vrf a
 area 1 sham-link 20.22.22.22 20.33.33.33
 redistribute bgp 1 subnets  


PE3#

interface Loopback20
 ip vrf forwarding a
 ip address 20.33.33.33 255.255.255.255
end

router bgp 1
 address-family ipv4 vrf a
  network 20.33.33.33 mask 255.255.255.255
  redistribute ospf 10 match internal external 1 external 2 nssa-external 1 nssa-external 2
!       
router ospf 10 vrf a
 area 1 sham-link 20.33.33.33 20.22.22.22
 redistribute bgp 1 subnets


As soon as the configuration is applied, the sham-link should come up

*Jun 26 01:46:56.400: %OSPF-5-ADJCHG: Process 10, Nbr 20.2.2.2 on OSPF_SL0 from LOADING to FULL, Loading Done

Notice that in the interface section in the log message, OSPF_SL0 is there instead of normal physical Ethernet or POS interface.

Let’s verify that sham-link status
PE2#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
40.0.22.1         0   FULL/  -           -        20.33.33.33     OSPF_SL0
40.2.2.2          1   FULL/BDR        00:00:39    40.0.12.2       Ethernet0/2
PE2#show ip ospf sham-links
Sham Link OSPF_SL0 to address 20.33.33.33 is up
Area 1 source address 20.22.22.22
  Run as demand circuit
  DoNotAge LSA allowed. Cost of using 1 State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40,
    Hello due in 00:00:04
    Adjacency State FULL (Hello suppressed)
    Index 1/1, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

Notice also that the hellos are suppressed, this is due to the fact that there’s no actual hellos being sent between PE2 and PE3, BGP is already handling the peering signalling between the two PEs.

Now let’s check CE-A2 routing table again

CE-A2#show ip route

      20.0.0.0/32 is subnetted, 3 subnets
O IA     20.2.2.2 [110/21] via 40.0.12.1, 00:37:33, Ethernet0/0
O E2     20.22.22.22 [110/1] via 40.0.12.1, 00:11:06, Ethernet0/0
O E2     20.33.33.33 [110/1] via 40.0.12.1, 00:10:49, Ethernet0/0
      40.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C        40.0.12.0/24 is directly connected, Ethernet0/0
L        40.0.12.2/32 is directly connected, Ethernet0/0
O        40.0.22.0/24 [110/31] via 40.0.12.1, 00:10:43, Ethernet0/0
C        40.2.2.2/32 is directly connected, Loopback0
O        40.3.3.3/32 [110/32] via 40.0.12.1, 00:10:43, Ethernet0/0
      50.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        50.0.0.0/24 is directly connected, Ethernet0/1
L        50.0.0.1/32 is directly connected, Ethernet0/1

The loopback of CE-B2 now is preferred through the MPLS core since it’s seen as an Intra-Area and the tie breaker between the PE-CE link and the backdoor link is the metric, obviously the metric through the PE-CE link is much lower.

Let’s just confirm that we always need to make the backdoor link metric higher than the PE-CE link.

CE-A2#interface Ethernet0/1
CE-A2(config-if)#no ip ospf cost 1000



CE-A2#show ip route

      20.0.0.0/32 is subnetted, 3 subnets
O IA     20.2.2.2 [110/21] via 40.0.12.1, 00:42:18, Ethernet0/0
O E2     20.22.22.22 [110/1] via 40.0.12.1, 00:15:51, Ethernet0/0
O E2     20.33.33.33 [110/1] via 40.0.12.1, 00:15:34, Ethernet0/0
      40.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C        40.0.12.0/24 is directly connected, Ethernet0/0
L        40.0.12.2/32 is directly connected, Ethernet0/0
O        40.0.22.0/24 [110/30] via 50.0.0.2, 00:00:09, Ethernet0/1
C        40.2.2.2/32 is directly connected, Loopback0
O        40.3.3.3/32 [110/11] via 50.0.0.2, 00:00:09, Ethernet0/1
      50.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        50.0.0.0/24 is directly connected, Ethernet0/1
     L        50.0.0.1/32 is directly connected, Ethernet0/1

It seems that CE-A2 now is preferring the Intra-Area route through the backdoor link again, but this time because the metric is lower. It is always a best practice to increase the backdoor link OSPF cost to a very high number to make sure that whatever the metric received by the PE routers, it will always be much lower than the backdoor link.

OSPF sham-link can also be adjusted from PE routers and will be calculated in SPF algorithm as if it was a point-to-point link with the configured value

PE2(config)#router ospf 10 vrf a
PE2(config-router)#area 1 sham-link 20.22.22.22 20.33.33.33 cost 1


Hopefully that wraps up the sham-link, if you have comments, please share them in the comments section below


Friday, June 20, 2014

OSPF Summary Address Cost

By default, OSPF route summarization  generate  the summary route metric based on lowest metric of the more specific routes present in its routing table.


Let’s check this topology



R3 is an Area Border Router that receives two route from R1 and R2, Assuming that we manually adjust the OSPF cost of the link towards R1 to 2000 and the link to R2 to 3000.

Let’s check R3 routing table

R3#show ip route

     100.0.0.0/24 is subnetted, 2 subnets
O       100.0.1.0 [110/2001] via 10.1.3.1, 00:00:03, FastEthernet0/0
O       100.0.2.0 [110/3001] via 10.2.3.2, 00:00:03, FastEthernet0/1
     3.0.0.0/32 is subnetted, 1 subnets
C       3.3.3.3 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 3 subnets
C       10.1.3.0 is directly connected, FastEthernet0/0
C       10.2.3.0 is directly connected, FastEthernet0/1
C       10.3.4.0 is directly connected, FastEthernet1/0

Now let’s enable summarization of the 100.0.0.0/8 route from area 5

R3(config)#router ospf 1
R3(config-router)#area 5 range 100.0.0.0 255.0.0.0

Let’s check R3 routing table again

R3#show ip route

     100.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O       100.0.0.0/8 is a summary, 00:10:01, Null0
O       100.0.1.0/24 [110/2001] via 10.1.3.1, 00:00:06, FastEthernet0/0
O       100.0.2.0/24 [110/3001] via 10.2.3.2, 00:00:23, FastEthernet0/1
     3.0.0.0/32 is subnetted, 1 subnets
C       3.3.3.3 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 3 subnets
C       10.1.3.0 is directly connected, FastEthernet0/0
C       10.2.3.0 is directly connected, FastEthernet0/1
C       10.3.4.0 is directly connected, FastEthernet1/0

The summary route has been generated and its next hop is Null0 since R3 is the originator of the summary route.



Checking the OSPF Database for self-originated summary LSAs

R3#show ip ospf database summary 100.0.0.0 self-originate

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

                Summary Net Link States (Area 0)

  LS age: 245
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 100.0.0.0 (summary Network Number)
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000001
  Checksum: 0x876C
  Length: 28
  Network Mask: /8
        TOS: 0  Metric: 2001

It’s seems that The R3 Generated the summary route with the lowest metric after comparing between the 100.0.1.1/24 and 100.0.2.2/24  metrics.


Now let’s check what R4 is receiving

R4#show ip route

O IA 100.0.0.0/8 [110/2002] via 10.3.4.3, 00:00:05, FastEthernet0/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/2] via 10.3.4.3, 00:40:39, FastEthernet0/0
     4.0.0.0/32 is subnetted, 1 subnets
C       4.4.4.4 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 4 subnets
O IA    10.1.3.0 [110/2001] via 10.3.4.3, 00:40:39, FastEthernet0/0
C       10.4.5.0 is directly connected, FastEthernet0/1
O IA    10.2.3.0 [110/3001] via 10.3.4.3, 00:39:51, FastEthernet0/0
C       10.3.4.0 is directly connected, FastEthernet0/0


Indeed R4 is receiving the summary route with a metric of 2002

A point that needs to be clarified, this behavior was based on RFC1583, in a later implementation of RFC2328 the behavior was changed to the highest metric instead of the lowest metric. You can refer to that in RFC2328 section 3.5

Area border routers then summarize the area
 contents (for distribution to the backbone) by advertising a
 single route for each address range.  The cost of the route is
 the maximum cost to any of the networks falling in the specified
 range.”


You can disable OSPF compatibility to the old RFC1583 and make the normal behavior as stated in RFC2328

R3(config)#router ospf 1
R3(config-router)#no compatible rfc1583


Now let’s check R3 self-originated summary routes again


R3#show ip ospf database summary 100.0.0.0 self-originate

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

                Summary Net Link States (Area 0)

  LS age: 8
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 100.0.0.0 (summary Network Number)
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000004
  Checksum: 0xB450
  Length: 28
  Network Mask: /8
        TOS: 0  Metric: 3001


And R4 for a final check

R4#show ip route

Gateway of last resort is not set

O IA 100.0.0.0/8 [110/3002] via 10.3.4.3, 00:02:16, FastEthernet0/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/2] via 10.3.4.3, 00:15:31, FastEthernet0/0
     4.0.0.0/32 is subnetted, 1 subnets
C       4.4.4.4 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 4 subnets
O IA    10.1.3.0 [110/2001] via 10.3.4.3, 00:12:36, FastEthernet0/0
C       10.4.5.0 is directly connected, FastEthernet0/1
O IA    10.2.3.0 [110/3001] via 10.3.4.3, 00:12:46, FastEthernet0/0
C       10.3.4.0 is directly connected, FastEthernet0/0


Hopefully that clears up how OSPF ABR summarization works