OSPF filtering issue when virtual-links are present

Here is the topology I will start off with:


R4 has two INTER-area routes to 1.1.1.1:

R4#sho ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 4, type inter area
  Last update from 192.168.45.5 on Serial1/0, 00:00:11 ago
  Routing Descriptor Blocks:
    192.168.45.5, from 5.5.5.5, 00:00:11 ago, via Serial1/0
      Route metric is 4, traffic share count is 1
  * 192.168.34.3, from 2.2.2.2, 00:00:11 ago, via Serial1/1
      Route metric is 4, traffic share count is 1

If we want to filter the path from R2 through 192.168.34.3 we could do it this way:

R4(config)#access-list 1 permit 1.1.1.1
R4(config)#access-list 2 permit 2.2.2.2
R4(config)#route-map OSPF deny 10
R4(config-route-map)#match ip address 1
R4(config-route-map)#match ip route-source 2
R4(config-route-map)#route-map OSPF permit 20
R4(config-route-map)#router ospf 1
R4(config-router)#distribute-list route-map OSPF in
R4(config-router)#^Z
      
R4#sho ip route 1.1.1.1        
Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 4, type inter area
  Last update from 192.168.45.5 on Serial1/0, 00:00:12 ago
  Routing Descriptor Blocks:
  * 192.168.45.5, from 5.5.5.5, 00:00:12 ago, via Serial1/0
      Route metric is 4, traffic share count is 1

But let's say we have a task that asks us to create a new area attached to R4 as follows:


Now we need two virtual-links and look at was happened to our route 1.1.1.1.

R4(config)#router ospf 1                 
R4(config-router)#area 1 virtual-link 5.5.5.5          
R4(config-router)#area 1 virtual-link 2.2.2.2

*Mar  3 01:31:13.935: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on
OSPF_VL2 from LOADING to FULL, Loading Done
*Mar  3 01:31:16.979: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on
OSPF_VL3 from LOADING to FULL, Loading Done

R4#sho ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 4, type intra area
  Last update from 192.168.34.3 on Serial1/1, 00:00:00 ago
  Routing Descriptor Blocks:
  * 192.168.45.5, from 1.1.1.1, 00:00:00 ago, via Serial1/0
      Route metric is 4, traffic share count is 1
    192.168.34.3, from 1.1.1.1, 00:00:00 ago, via Serial1/1
      Route metric is 4, traffic share count is 1

What gives? Well now we are learning 1.1.1.1 as an INTRA-area route so the router-ID advertising the LSA has changed. We are now learning the route from type-1 LSAs originated by R1 directly in Area 0. If we filter based on router-id we will lose both paths so now we need to filter based on next-hop:

R4(config)#access-list 3 permit 192.168.34.3
R4(config)#no route-map OSPF
R4(config)#route-map OSPF deny 10
R4(config-route-map)#match ip add 1
R4(config-route-map)#match ip next-hop 3
R4(config-route-map)#route-map OSPF pe 20  
R4(config-route-map)#^Z

R4#sho ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 4, type intra area
  Last update from 192.168.45.5 on Serial1/0, 00:00:02 ago
  Routing Descriptor Blocks:
  * 192.168.45.5, from 1.1.1.1, 00:00:02 ago, via Serial1/0
      Route metric is 4, traffic share count is 1

All of this change could of course been prevented had we read ahead :-)