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 :-)

Redistribution filtering with distribute list

This command still gets me because of the "out" keyword but here is it how it works. It might help to remember there is no "in" keyword when you filter from a routing process.

Topology:

R1---OSPF---R2---OSPF---R5---EIGRP---R6---EIGRP---R9

R9 has loopback 9.9.9.9
R2 has loopback 2.2.2.2

We will filter these routes during redistribution but allow all others.

Will start by filtering R9's loopback from EIGRP to OSPF. On R5 we create the prefix-list:

R5(config)#ip prefix-list BLOCK9 deny 9.9.9.9/32
R5(config)#ip prefix-list BLOCK9 permit 0.0.0.0/0 le 32

Then we apply it under the OSPF process. I know it looks weird but just remember there is no "in" direction when you filter this way.

R5(config)#router ospf 1
R5(config-router)#distribute-list prefix BLOCK9 out eigrp 1

Lets' check R2, notice we see R6's loopback but not R9's

R2#show ip route | inc E2
E1 - OSPF external type 1, E2 - OSPF external type 2
O E2 6.6.6.6 [110/20] via 150.100.100.5, 00:00:11, Serial1/0.2
O E2 150.100.69.0/24 [110/20] via 150.100.100.5, 00:07:51, Serial1/0.2
O E2 150.100.56.0/24 [110/20] via 150.100.100.5, 00:07:51, Serial1/0.2

Now let's do the other direction. First Let's check R9's table:

R9#show ip route | inc EX
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
D EX 1.1.1.1 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 2.2.2.2 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 4.4.4.4 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 192.168.100.2 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 150.100.100.2/32
D EX 150.100.24.0/24 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1
D EX 150.100.12.0/24 [170/2560514816] via 150.100.69.6, 00:00:06, Serial1/1

Configure R5. remember this blocks FROM ospf process 1:

R5(config)#ip prefix-list BLOCK2 seq 5 deny 2.2.2.2/32
R5(config)#ip prefix-list BLOCK2 seq 10 permit 0.0.0.0/0 le 32
R5(config)#router eigrp 1
R5(config-router)#distribute-list prefix BLOCK2 out ospf 1

The neighbors will resync:

*Mar 1 00:20:38.571: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 150.100.56.6 (FastEthernet0/0) is resync: route configuration changed

Now check R9 and R2's loopback has been filtered:

R9#show ip route | inc EX
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
D EX 1.1.1.1 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 4.4.4.4 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 192.168.100.2 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 150.100.100.2/32
D EX 150.100.24.0/24 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1
D EX 150.100.12.0/24 [170/2560514816] via 150.100.69.6, 00:02:11, Serial1/1

IPv6: RIPng, traffic filters and split horizon

R5, R6 and R7 all sit on the same LAN. R6 is also connected to R9. R5 must see this network between R6 and R9 with a next hop of R7, not R6. How can we do it?

Well first we need to disable split horizon on R7. For IPv6 RIP, this is done under the routing process:

IPeR7(config)#ipv6 router rip RIP6
IPeR7(config-rtr)#no split-horizon

Next we need to filter routing updates from R6. What do these RIPng packets look like? We can see through "debug ipv6 rip."

IPeR5#debug ipv6 rip
RIP Routing Protocol debugging is on
IPeR5#
*Nov 3 00:45:44.453: RIPng: response received from FE80::6 on FastEthernet0/0 for RIP6
*Nov 3 00:45:44.453: src=FE80::6 (FastEthernet0/0)
*Nov 3 00:45:44.453: dst=FF02::9
*Nov 3 00:45:44.453: sport=521, dport=521, length=52
*Nov 3 00:45:44.453: command=2, version=1, mbz=0, #rte=2
*Nov 3 00:45:44.453: tag=0, metric=1, prefix=2001:200::/64
*Nov 3 00:45:44.453: tag=0, metric=1, prefix=2001:96::/64

Now we know the source and destination, we can create our filter:

IPeR5(config)#ipv6 access-list RIP-FILTER
IPeR5(config-ipv6-acl)#deny ipv6 FE80::6/128 FF02::9/128
IPeR5(config-ipv6-acl)#permit ipv6 any any
IPeR5(config-ipv6-acl)#int f0/0
IPeR5(config-if)#ipv6 access-group RIP-FILTER in
^
% Invalid input detected at '^' marker.

Whoa! what gives!? This stupid things doesn't let me apply my ACL.

IPeR5(config-if)#ipv6 acc?
% Unrecognized command

Well that's because traffic filtering in IPv6 uses a whole different syntax:

IPeR5(config-if)#ipv6 traffic-filter RIP-FILTER in
IPeR5(config-if)#

BAM!

Let's clear the route table then check our next hop:

IPeR5#show ipv6 route rip | sec exclude Codes:
IPv6 Routing Table - 7 entries
R 2001:96::/64 [120/3]
via FE80::7, FastEthernet0/0
IPeR5#

BGP - prefix-based outbound route filtering

Prefix-based outbound route filtering is used so a local router can tell it's peer what routes it should send/filter. This prevents unnecessary resources from being used. There is no sense in a router sending a bunch of route updates, if they are only going to get filtered anyway.

In this example we have EBGP peers R4 and R3:

[R4]---[R3]

R3 is receiving a bunch of routes from R4:

R3#show ip bgp Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 1.0.1.0/24 172.12.34.4 0 400 65000 i
*> 1.0.2.0/24 172.12.34.4 0 400 65000 i
*> 1.0.3.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i
*> 2.0.1.0/24 172.12.34.4 0 400 65000 i
*> 2.0.2.0/24 172.12.34.4 0 400 65000 i
*> 2.0.3.0/24 172.12.34.4 0 400 65000 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
*> 4.0.0.0/24 172.12.34.4 0 0 400 i
*> 4.0.1.0/24 172.12.34.4 0 0 400 i
*> 4.0.2.0/24 172.12.34.4 0 0 400 i
*> 4.0.3.0/24 172.12.34.4 0 0 400 i

R3 only wants to receive 3 routes:

1.0.0.0/24
2.0.0.0/24
4.0.0.0/24

R3 can create a prefix-list allowing these 3 routes only and advertise this to R4. R4 will use this list as a outbound filter. Let's configure it. First you need enable the advertisement of the orf capability. R3 is the one sending the prefix-list so use the send keyword. R4 is receiving the prefix-list.

R3(config)#router bgp 65003
R3(config-router)#neighbor 172.12.34.4 capability orf prefix-list send

R4(config)#router bgp 400
R4(config-router)#neighbor 172.12.34.3 capability orf prefix-list receive

Now configure the prefix-list and apply it to the neighbor:

R3(config)#ip prefix-list ZERO seq 5 permit 1.0.0.0/24
R3(config)#ip prefix-list ZERO seq 10 permit 2.0.0.0/24
R3(config)#ip prefix-list ZERO seq 15 permit 4.0.0.0/24
R3(config)#router bgp 65003
R3(config-router)#neighbor 172.12.34.4 prefix-list ZERO in

R3#clear ip bgp * soft in prefix-filter

Here is the final result:

R3#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
*> 4.0.0.0/24 172.12.34.4 0 0 400 i

Here are some captures I took in dynamips. The first shows the advertisement of the orf capability. The second shows the actually prefix-list R3 is sending. Wireshark shows this as "route-refresh" message. Pretty cool, eh?



Restrictions:

I used the bgp upgrade-cli command to configure these neighbors in AF mode.
Also, prefix-lists must be used, not ACL or distribute lists

For more info go here:

BGP Prefix-Based Outbound Route Filtering

Prefix-lists vs ACLs

Many people prefer prefixes-lists over ACLs because they give you more preciseness over which routes to allow. This blogs goes over some examples between the two methods using RIP and distribute-lists.

The Network:

R1----R2----R3

Each router is connected to its own LAN, call them LAN1,LAN2 and LAN3

Addressing:

R1-R2 = 12.0.0.0/8
R2-R3 = 13.0.0.0/8
LAN1 = 1.0.0.1/8
LAN2 = 2.0.0.2/8
LAN3 = 3.0.0.0/16

R3 also has 4 loopbacks:

3.1.0.3/16
3.2.0.3/16
3.3.0.3/16
3.4.0.3/16

RIP is enabled everywhere so that R1 has the following route table:

R1#show ip route | begin Ga
Gateway of last resort is not set

1.0.0.0/16 is subnetted, 1 subnets
C 1.0.0.0 is directly connected, FastEthernet0/0
R 2.0.0.0/8 [120/2] via 13.0.0.3, 00:00:06, Serial1/1
3.0.0.0/16 is subnetted, 5 subnets
R 3.3.0.0 [120/1] via 13.0.0.3, 00:00:06, Serial1/1
R 3.2.0.0 [120/1] via 13.0.0.3, 00:00:06, Serial1/1
R 3.1.0.0 [120/1] via 13.0.0.3, 00:00:06, Serial1/1
R 3.0.0.0 [120/1] via 13.0.0.3, 00:00:06, Serial1/1
R 3.4.0.0 [120/1] via 13.0.0.3, 00:00:06, Serial1/1
R 23.0.0.0/8 [120/1] via 13.0.0.3, 00:00:06, Serial1/1
R 12.0.0.0/8 [120/2] via 13.0.0.3, 00:00:06, Serial1/1
C 13.0.0.0/8 is directly connected, Serial1/1

Let's say I create a prefix-list like this:

R3(config)#ip prefix-list NET3 permit 3.0.0.0/8

Then apply the distribute list:

R3(config)#router rip
R3(config-router)#distribute-list prefix NET3 out

R1 will have no routes to any of the 3 networks:

R1# show ip route | begin Ga
Gateway of last resort is not set

1.0.0.0/16 is subnetted, 1 subnets
C 1.0.0.0 is directly connected, FastEthernet0/0
C 13.0.0.0/8 is directly connected, Serial1/1

But if we use the same matching principle (3.0.0.0/8) in an ACL, then R3 has all the 3.0.0.0 routes:

R3(config)#router rip
R3(config-router)#no distribute-list prefix NET3 out
R3(config-router)#exit
R3(config)#access-list 3 permit 3.0.0.0 0.255.255.255
R3(config)#router rip
R3(config-router)#distribute-list 3 out

R1#clear ip route *
R1# show ip route | begin Ga
Gateway of last resort is not set

1.0.0.0/16 is subnetted, 1 subnets
C 1.0.0.0 is directly connected, FastEthernet0/0
3.0.0.0/16 is subnetted, 5 subnets
R 3.3.0.0 [120/1] via 13.0.0.3, 00:00:01, Serial1/1
R 3.2.0.0 [120/1] via 13.0.0.3, 00:00:01, Serial1/1
R 3.1.0.0 [120/1] via 13.0.0.3, 00:00:01, Serial1/1
R 3.0.0.0 [120/1] via 13.0.0.3, 00:00:01, Serial1/1
R 3.4.0.0 [120/1] via 13.0.0.3, 00:00:01, Serial1/1
C 13.0.0.0/8 is directly connected, Serial1/1

The reason this happens is because prefix-lists match on the exact route subnet length unless the ge or le arguments are added. To make the prefix-list perform like the ACL we can do this:

R3(config)#router rip
R3(config-router)#no distribute-list 3 out
R3(config-router)#exit
R3(config)#no ip prefix-list NET3 permit 3.0.0.0/8
R3(config)#ip prefix-list NET3 permit 3.0.0.0/8 ge 9
R3(config)#router rip
R3(config-router)#distribute-list prefix NET3 out

R1#clear ip route *
R1# show ip route | begin Ga
Gateway of last resort is not set

1.0.0.0/16 is subnetted, 1 subnets
C 1.0.0.0 is directly connected, FastEthernet0/0
3.0.0.0/16 is subnetted, 5 subnets
R 3.3.0.0 [120/1] via 13.0.0.3, 00:00:00, Serial1/1
R 3.2.0.0 [120/1] via 13.0.0.3, 00:00:00, Serial1/1
R 3.1.0.0 [120/1] via 13.0.0.3, 00:00:00, Serial1/1
R 3.0.0.0 [120/1] via 13.0.0.3, 00:00:00, Serial1/1
R 3.4.0.0 [120/1] via 13.0.0.3, 00:00:00, Serial1/1
C 13.0.0.0/8 is directly connected, Serial1/1

The prefix-lists matches the first 8 bits of a prefix and then matches any of those prefixes that have masks of 9 bits or longer. If we wanted the ACL to perform like the prefix-list we could do this:

R3(config)#access-list 13 permit 3.0.0.0 0.0.0.0
R3(config)#router rip
R3(config-router)#no distribute-list prefix NET3 out
R3(config-router)#distribute-list 13 out

R1# show ip route | begin Ga
Gateway of last resort is not set

1.0.0.0/16 is subnetted, 1 subnets
C 1.0.0.0 is directly connected, FastEthernet0/0
3.0.0.0/16 is subnetted, 1 subnets
R 3.0.0.0 [120/1] via 13.0.0.3, 00:00:02, Serial1/1
C 13.0.0.0/8 is directly connected, Serial1/1

Now R1 has the route to 3.0.0.0, but notice it has no regard for the subnet length as the prefix-lists does. In other words, the above ACL 13 would match 3.0.0.0/8, 3.0.0.0/9, etc.

OSPF - Limiting number of redistributed routes

This short lab uses the topology of previous OSPF posts:

R2 ---> R5 in area 25
R5 ---> R4 in area 0
R4 ---> R3 in area 345

Area 25 is an NSSA.
R2 is an ASBR redistruting connected and static routes into OSPF:

R2#show run | section router ospf
router ospf 1
log-adjacency-changes
area 25 nssa
redistribute connected subnets tag 100
redistribute static metric-type 1 subnets tag 200
network 172.12.25.0 0.0.0.255 area 25

static: 1.1.1.1, 192.168.254.0
connected 2.2.2.2-5, 172.12.123.0

These routes are tagged with 100 and 200 respectively for easy filtering. Below is the database on R4, we have 7 LSA's:

R4#show ip ospf database | inc 100|200
1.1.1.1 5.5.5.5 48 0x80000001 0x00BD82 200
2.2.2.2 5.5.5.5 48 0x80000001 0x00041C 100
2.2.2.3 5.5.5.5 48 0x80000001 0x00F925 100
2.2.2.4 5.5.5.5 48 0x80000001 0x00EF2E 100
2.2.2.5 5.5.5.5 48 0x80000001 0x00E537 100
172.12.123.0 5.5.5.5 48 0x80000001 0x00BC37 100
192.168.254.0 5.5.5.5 48 0x80000001 0x004596 200

Let's configure a redistribution limit on R2:

R2(config)#router ospf 1

R2(config-router)#redistribute maximum-prefix ?
<1-4294967295> Maximum number of IP prefixes redistributed

R2(config-router)#redistribute maximum-prefix 4 ?
<1-100> Threshold value (%) at which to generate a warning message
warning-only Only give warning message when limit is exceeded

R2(config-router)#redistribute maximum-prefix 4 50

Now wait a few moments and the following message appears on R2:

Mar 1 02:21:01.775: %IPRT-4-REDIST_THR_PFX: Redistribution prefix threshold has been reached "ospf 1" - 2 prefixes
Mar 1 02:21:01.783: %IPRT-4-REDIST_MAX_PFX: Redistribution prefix limit has been reached "ospf 1" - 4 prefixes

The threshold was reached at 50% of 4 (2 routes). The maximum limit was reached shortly thereafter. Let's check R4 to see how many external LSA's it has now:

R4#show ip ospf database | inc 100|200
1.1.1.1 5.5.5.5 92 0x80000001 0x00BD82 200
2.2.2.2 5.5.5.5 92 0x80000001 0x00041C 100
2.2.2.3 5.5.5.5 92 0x80000001 0x00F925 100
2.2.2.4 5.5.5.5 92 0x80000001 0x00EF2E 100

Only 4 show up the rest have been filtered. We can also set up R2 to only give a warning and not actually limit the redistribution of the routes:

R2(config-router)#redistribute maximum-prefix 4 50 warning-only
Mar 1 02:23:53.487: %IPRT-4-REDIST_THR_PFX: Redistribution prefix threshold has been reached "ospf 1" - 2 prefixes
Mar 1 02:23:53.495: %IPRT-4-REDIST_MAX_PFX: Redistribution prefix limit has been reached "ospf 1" - 4 prefixes

Warning only, no filtering:

R4#show ip ospf database | inc 100|200
1.1.1.1 5.5.5.5 43 0x80000001 0x00BD82 200
2.2.2.2 5.5.5.5 43 0x80000001 0x00041C 100
2.2.2.3 5.5.5.5 43 0x80000001 0x00F925 100
2.2.2.4 5.5.5.5 43 0x80000001 0x00EF2E 100
2.2.2.5 5.5.5.5 43 0x80000001 0x00E537 100
172.12.123.0 5.5.5.5 43 0x80000001 0x00BC37 100
192.168.254.0 5.5.5.5 43 0x80000001 0x004596 200

Note that this command doesn't require you to clear ospf but it can take a few moments (20+ seconds) if you don't.

OSPF - Filtering type 3 LSAs

R3 and R4 share the same Ethernet segment 172.12.34.0 via their fastethernet0/1 interfaces

Router IDs:
R3 = 3.3.3.3
R4 = 4.4.4.4

The link between R3 and R4 is in area 345 and R4 is an ABR connected to area 0.

Below is a snapshot of the area 345 LSDB. You can see the type 3 LSAs that R3 is getting from R4:

R3#show ip ospf database | begin Summary Net Link States

Summary Net Link States (Area 345)

Link ID ADV Router Age Seq# Checksum
6.6.6.6 4.4.4.4 545 0x80000001 0x00884B
172.12.25.0 4.4.4.4 545 0x80000001 0x00AC2E
172.12.45.4 4.4.4.4 555 0x80000001 0x00A2A0
172.12.45.5 4.4.4.4 545 0x80000001 0x001BE6
172.12.45.6 4.4.4.4 545 0x80000001 0x0011EF

(output omitted)

Suppose we want to filter the host route LSAs (#1,3,4 and 5 in the list above). Here's how we could do it:

On R4:

R4(config)#ip prefix-list BLOCK32 deny 0.0.0.0/0 ge 32
R4(config)#ip prefix-list BLOCK32 permit 0.0.0.0/0 le 32
R4(config-router)#area 0 filter-list prefix BLOCK32 out

Clear the OSPF process on R3 and now let's have a look:

R3#show ip ospf database | begin Summary Net
Summary Net Link States (Area 345)

Link ID ADV Router Age Seq# Checksum
172.12.25.0 4.4.4.4 1074 0x80000001 0x00AC2E

(output omitted)

You can verify on R4 like this:

R4#show ip ospf | section Area
Area BACKBONE(0)
Area has no authentication
Area ranges are
Area-filter BLOCK32 out
Area 345
Area has no authentication
Area ranges are
R4#

Of course this did break some connectivity in my lab, so be careful when you use this :)

OSPF - Filtering LSAs (intra-area)

R3 and R4 share the same Ethernet segment 172.12.34.0 via their fastethernet0/1 interfaces

Router IDs:
R3 = 3.3.3.3
R4 = 4.4.4.4

R4 has the following LSAs from R3:

R4# show ip ospf database adv-router 3.3.3.3

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

Router Link States (Area 345)

Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 7 0x80000012 0x00C568 2

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
172.12.123.0 3.3.3.3 550 0x8000000C 0x00D381 0

On R3 we enter the following command:

R3(config)#int f0/1
R3(config-if)#ip ospf database-filter all out
R3(config-if)#
*Mar 1 04:41:41.162: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on FastEthernet0/1
from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar 1 04:41:41.382: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on FastEthernet0/1
from LOADING to FULL, Loading Done

Notice the adjacency bounced. However, R4 still has LSAs from R3 in it's database (they haven't been aged):

R4# show ip ospf database adv-router 3.3.3.3

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

Router Link States (Area 345)

Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 59 0x80000012 0x00C568 2

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
172.12.123.0 3.3.3.3 603 0x8000000C 0x00D381 0

We must clear the ospf process on R4:

R4#clear ip ospf process
Reset ALL OSPF processes? [no]: yes
Mar 1 04:52:47.442: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 f
rom FULL to DOWN, Neighbor Down: Interface down or detached
Mar 1 04:52:47.806: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 f
rom LOADING to FULL, Loading Done

Now the type 1 router LSA from R3 is gone from R4's LSDB:

R4# show ip ospf database adv-router 3.3.3.3

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

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
172.12.123.0 3.3.3.3 674 0x8000000C 0x00D381 0

But the type 5 LSA still exists...Why? Don't know yet, stay tuned...