Hi @rasmus.elmholt
From the debug output, we can see that because the split-horizon, R1 didn't generate a Summary LSA (Type-3) for the subnet 4.4.4.0/24, in order to avoid a loop, R1 knows that R3 and R4 are ABRs, the Split-Horizon rule tells to the ABR R1: do not generate a Type-3 LSA for 4.4.4.0/24 in area 123, it received already two Type-3 LSAs from R2 and R3 in area 123, no need to create a new one in the same area 123.
In OSPFv2, Capability Transit is enabled by default, this features allows the ABR to select a better route through the transit area rather than the virtual link. In some case you need the ABR to go through the virtual link directly connected to the backbone area 0, therefore you can disable capability transit using the no capability transit command.
R1 chooses R3 as the next-hop to reach 4.4.4.0/24, even if it has a direct path through the virtual link (area 0 connection) with R2. R1 chooses transit area 123. This is due to the Transit Capability turned on by default. So instead of using the virtual link (area 0), R4 uses the path through the transit area 123 since R3 is advertising a better metric.
RFC 2328 defines the transit-capability for stub area in the following section:
TransitCapability
This parameter indicates whether the area can carry data traffic
that neither originates nor terminates in the area itself. This
parameter is calculated when the area's shortest-path tree is
built (see Section 16.1, where TransitCapability is set to TRUE
if and only if there are one or more fully adjacent virtual
links using the area as Transit area), and is used as an input
to a subsequent step of the routing table build process (see
Section 16.3). When an area's TransitCapability is set to TRUE,
the area is said to be a "transit area".
RFC 1583 which is the default RFC implemented by Cisco routers defines the transit-capability for stub area in the following section:
TransitCapability
Set to TRUE if and only if there are one or more active virtual
links using the area as a Transit area. Equivalently, this
parameter indicates whether the area can carry data traffic that
neither originates nor terminates in the area itself. This
parameter is calculated when the area's shortest-path tree is
built (see Section 16.1, and is used as an input to a subsequent
step of the routing table build process (see Section 16.3).
To disable the Split-Horizon, we need to disable capability transit feature on R1:
R1(config)#router osp 1
R1(config-router)#no capability transit
The same debug output confirms that the Split horizon between ABR is no longer applied:
R1# Base
*Sep 6 06:21:22.139: OSPF-1 LSGEN: Build sum 4.4.4.0, mask 255.255.255.0, type 3, age 0, seq 0x80000007 to area 1
*Sep 6 06:21:22.143: OSPF-1 LSGEN: MTID Metric Origin Topology Name
*Sep 6 06:21:22.143: OSPF-1 LSGEN: 0 22 intra-area Base
*Sep 6 06:21:22.147: OSPF-1 LSGEN: Build sum 4.4.4.0, mask 255.255.255.0, type 3, age 0, seq 0x80000001 to area 123
*Sep 6 06:21:22.151: OSPF-1 LSGEN: MTID Metric Origin Topology Name
*Sep 6 06:21:22.151: OSPF-1 LSGEN: 0 22 intra-area Base
*Sep 6 06:21:22.155: OSPF-1 LSGEN: Build sum 34.0.0.0, mask 255.255.255.0, type 3, age 0, seq 0x80000005 to area 1
*Sep 6 06:21:22.159: OSPF-1 LSGEN: MTID Metric Origin Topology Name
*Sep 6 06:21:22.159: OSPF-1 LSGEN: 0 31 intra-area Base
*Sep 6 06:21:22.163: OSPF-1 LSGEN: Build sum 34.0.0.0, mask 255.255.255.0, type 3, age 0, seq 0x80000001 to area 123
