OSPF: DEEP Dive – Distribute-List vs Filter-List, and reviewing Prefix-Lists as Filter-Lists use Prefixes to filter!

One thing that was lacking from Chris Bryants training that I found in the INE series is explanations between when to use OSPF Filter-list vs a Distribute-list. I have modified the network as reflected in the Topology so Area 34 will no longer be a stub, and Area 15 will only be an NSSA Area.

Fun right? Great! 🙂

I’m going to mark down bullet point style information about distribute-lists and filter-lists for OSPF and how they work / what they effect:

• An inbound Distribute-List DOES NOT prevent a router from learning about an incoming Prefix via LSA, the LSA will stay in the LS Database, however it will prevent it from generating a route for that Prefix on the router

^This is a very important to know, as if you are tasked for a router to have NO knowledge of a certain route, this approach will still allow the router to have knowledge of the route via the LSA but will prevent it from converting that LSA to a route – So the router still learns of the Prefix.

In fact lets put Keith Borgarts money where his mouth is right off the bat, and test this theory of his out, by preventing R3 from learning of network 2.2.2.2/32 from R2:

R4(config-router)#do sh ip route

Gateway of last resort is 172.12.34.3 to network 0.0.0.0

O*E2  0.0.0.0/0 [110/1] via 172.12.34.3, 00:00:03, FastEthernet0/1

      1.0.0.0/32 is subnetted, 1 subnets

One thing I forgot about in the previous lab, was the “default-information originate always” configured on R1, and this is a perfect example of it not just Advertising that default route within its Area 0, but ABR’s flood that default route into all Areas that allow type 5 LSA’s to be flooded – So you will not be seeing that in our NSSA.

I will spare you the “before” output from R3, 2.2.2.2/32 is both in the LS DB and Route Table, but after configuring the ACL and applying it to an inbound Distribute-List:

R3(config)#access-list 2 deny 2.2.2.2
R3(config)#access-list 2 permit any
R3(config)#router ospf 1
R3(config-router)#distribute-list ?
  <1-199>      IP access list number
  <1300-2699>  IP expanded access list number
  WORD         Access-list name
  gateway      Filtering incoming updates based on gateway
  prefix       Filter prefixes in routing updates
  route-map    Filter prefixes based on the route-map

R3(config-router)#distribute-list 2 ?
  in   Filter incoming routing updates
  out  Filter outgoing routing updates

R3(config-router)#distribute-list 2 in ?
  Async              Async interface
  BVI                Bridge-Group Virtual Interface
  CDMA-Ix            CDMA Ix interface
  CTunnel            CTunnel interface
  Dialer             Dialer interface
  FastEthernet       FastEthernet IEEE 802.3
  Lex                Lex interface
  Loopback           Loopback interface
  MFR                Multilink Frame Relay bundle interface
  Multilink          Multilink-group interface
  Null               Null interface
  Port-channel       Ethernet Channel of interfaces
  Serial             Serial
  Tunnel             Tunnel interface
  Vif                PGM Multicast Host interface
  Virtual-PPP        Virtual PPP interface
  Virtual-Template   Virtual Template interface
  Virtual-TokenRing  Virtual TokenRing
  <cr>

I wanted to leave the ending in there, to show that you can actually assign the Distribute-List at certain interfaces, that being said lets see if it worked:

R3(config-router)#distribute-list 2 in
R3(config-router)#do sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 00:00:20, Serial0/2
     100.0.0.0/13 is subnetted, 1 subnets
O IA    100.0.0.0 [110/65] via 172.12.123.1, 00:00:20, Serial0/2
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/2] via 172.12.34.4, 00:00:20, FastEthernet0/1
     55.0.0.0/24 is subnetted, 1 subnets
O E1    55.5.5.0 [110/85] via 172.12.123.1, 00:00:20, Serial0/2
     5.0.0.0/32 is subnetted, 1 subnets
O E1    5.5.5.5 [110/85] via 172.12.123.1, 00:00:20, Serial0/2
     172.12.0.0/24 is subnetted, 4 subnets
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:00:20, Serial0/2
     172.16.0.0/22 is subnetted, 1 subnets
O E1    172.16.8.0 [110/85] via 172.12.123.1, 00:00:20, Serial0/2
     22.0.0.0/32 is subnetted, 1 subnets
O       22.2.2.2 [110/65] via 172.12.123.2, 00:00:20, Serial0/2
     11.0.0.0/32 is subnetted, 1 subnets
O       11.1.1.1 [110/65] via 172.12.123.1, 00:00:20, Serial0/2
O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:00:20, Serial0/2
R3(config-router)#

No route to 2.2.2.2/32, however the LS DB:

R3#sh ip ospf data

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

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
22.2.2.2        22.2.2.2        1239        0x80000004 0x009686 2
33.3.3.3        33.3.3.3        773         0x80000002 0x008A6B 2
100.7.0.1       100.7.0.1       1308        0x80000003 0x00CDBE 2

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.123.1    100.7.0.1       1308        0x80000002 0x00FEE1

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         100.7.0.1       1563        0x80000002 0x009D2D
2.2.2.2         22.2.2.2        1239        0x80000002 0x0044D2

3.3.3.3         33.3.3.3        796         0x80000001 0x009F66
4.4.4.4         33.3.3.3        786         0x80000001 0x007B85
100.0.0.0       100.7.0.1       1563        0x80000002 0x0096DA
172.12.15.0     100.7.0.1       1308        0x80000005 0x00CA39
172.12.34.0     33.3.3.3        800         0x80000001 0x005DD9

So that is absolutely correct, the router will learn about it, it just won’t make a route entry for it. Also an important note, checking on R4, there is no route or LS DB entry for 2.2.2.2, so it will not flood 2.2.2.2 in it’s LSA to any downstream routers as well.

So back to not wanting a router to know ANYTHING about 2.2.2.2/32, lets give it another try using the “filter-list” option in OSPF and see if that works!

We will use a filter-list to prevent R5 from seeing 2.2.2.2 this time, only with a filter-list, and there are a couple different approaches to it and an important note that it is not done on the router itself we are preventing from learning about the network like on R3.

So we will have to configure this one of two different ways:

• We will need to do configurations on R1 instead of R5 to block the LSA from getting to R5
• We will need to configure a Prefix-List rather than an Access-List as Filter-List’s use Prefix’s instead of Access-Lists
• You can either configure it as Area 0 going outbound, or Area 15 coming inbound

So to that last point, you want to configure either the Area with “in” that it is coming in on, or the Area # that it is going “out” to.

So about that Prefix-List:

R1(config)#ip prefix-list ?
  WORD             Name of a prefix list
  sequence-number  Include/exclude sequence numbers in NVGEN

R1(config)#ip prefix-list FilterList ?
  deny         Specify packets to reject
  description  Prefix-list specific description
  permit       Specify packets to forward
  seq          sequence number of an entry

R1(config)#ip prefix-list FilterList deny ?
  A.B.C.D/nn  IP prefix <network>/<length>, e.g., 35.0.0.0/8

R1(config)#ip prefix-list FilterList deny 2.2.2.2/32 ?
  ge  Minimum prefix length to be matched
  le  Maximum prefix length to be matched
  <cr>

R1(config)#ip prefix-list FilterList deny 2.2.2.2/32
R1(config)#ip prefix-list FilterList permit 0.0.0.0/32 le 32

% Invalid prefix range for 0.0.0.0/32, make sure: len < ge-value <= le-value

R1(config)#ip prefix-list FilterList permit 0.0.0.0/32 ?
  ge  Minimum prefix length to be matched
  le  Maximum prefix length to be matched
  <cr>

R1(config)#ip prefix-list FilterList permit 0.0.0.0/32
R1(config)#

I am a bit confused by the highlighted portion, I do not remember that when using Prefix-Lists in BGP, I will have to re-visit that in another DEEP Dive – However I believe we have our Prefix-List built correctly so time to apply it!

A quick note on Prefix-Lists, note that when creating ACL’s you “permit” the network 2.2.2.2 and the Distribute-List does the dirty work, but with Prefix-Lists you need to deny it on the list and like with an ACL make a catch-all permit line for all other traffic to flow.

So because we want this to filter the route / LSA to R5, we will specify Area 15, and use the “in” command at the end as you will see worded in the command modifiers here:

R1(config)#router ospf 1
R1(config-router)#area 15 filter-list ?
  prefix  Filter prefixes between OSPF areas

R1(config-router)#area 15 filter-list prefix ?
  WORD  Name of an IP prefix-list

R1(config-router)#area 0 filter-list prefix FilterList ?
  in   Filter networks sent to this area
  out  Filter networks sent from this area

R1(config-router)#area 15 filter-list prefix FilterList in ?
  <cr>

R1(config-router)#area 15 filter-list prefix FilterList in
R1(config-router)#

It is so weird to think of it this way, but you are filtering networks from going “in”to Area 15, whereas on R1 we would configure “out” for Area 0 to block a route Advertisement.

Note that you need to ID the filter list, which to get it run the following command:

R1#sh ip prefix-list
ip prefix-list FilterList: 2 entries
   seq 5 deny 2.2.2.2/32
   seq 10 permit 0.0.0.0/32
R1#

So finally, lets take a look at R1 for the Route / LS DB entry, then R5 (I will remove any unnecessary output for clarity:

Yeeeah.

So I must have goofed that Prefix-List, and I know it has to do with the part highlighted, as Area 15 has almost no LSA Type 3 entries on R1, and R5 itself has no outside OSPF routes. So now to re-visit what the deal is with my Prefix-List.

After a quick googling, I found that in my haste, I forgot we are using a Wild Card mask for Prefix lists, so this is how I correct that:

R1(config)#no ip prefix-list FilterList seq 10 permit 0.0.0.0/32
R1(config)#ip prefix-list FilterList seq 10 permit 0.0.0.0/0 le 32
R1(config)#do sh ip ospf data

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

                Summary Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         100.7.0.1       14          0x80000001 0x004580
3.3.3.3         100.7.0.1       14          0x80000001 0x006B12
4.4.4.4         100.7.0.1       14          0x80000001 0x004731
11.1.1.1        100.7.0.1       14          0x80000001 0x00C2F8
22.2.2.2        100.7.0.1       14          0x80000001 0x0094D8
33.3.3.3        100.7.0.1       14          0x80000001 0x00E37B
100.0.0.0       100.7.0.1       14          0x80000001 0x003E2E
172.12.34.0     100.7.0.1       14          0x80000001 0x002985
172.12.123.0    100.7.0.1       14          0x80000001 0x00480E

Whoop there it is 🙂

To finish this topic off, lastly I will finish the ‘out’ portion, and first I want to see if it can be applied to not directly connected to the router:

R1(config)#ip prefix-list Filtering2 deny 5.5.5.5/32
R1(config)#ip prefix-list Filtering2 permit 0.0.0.0/0 le 32
R1(config)#router ospf 1
R1(config-router)#area 34 filter-list ?
  prefix  Filter prefixes between OSPF areas

R1(config-router)#area 34 filter-list prefix ?
  WORD  Name of an IP prefix-list

R1(config-router)#area 34 filter-list prefix Filtering2 ?
  in   Filter networks sent to this area
  out  Filter networks sent from this area

R1(config-router)#area 15 filter-list prefix Filtering2 out

I’ll spare the output, but after checking R3 and R4, Area 34 still see’s both the route and LSA for 5.5.5.5/32, so that is what we call in the business (of studying) as a no go.

So let’s see if we can block it from entering our summary route Area 100:

R1(config-router)#no area 34 filter-list prefix Filtering2 out
R1(config-router)#area 100 filter-list prefix Filtering2 out
R1(config-router)#do sh ip ospf data

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

                Summary Net Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         100.7.0.1       1456        0x80000001 0x009F2C
2.2.2.2         100.7.0.1       981         0x80000001 0x00F393
3.3.3.3         100.7.0.1       1104        0x80000001 0x00C5BD
4.4.4.4         100.7.0.1       1104        0x80000001 0x00A1DC
11.1.1.1        100.7.0.1       1456        0x80000001 0x001DA4
22.2.2.2        100.7.0.1       981         0x80000001 0x00EE84
33.3.3.3        100.7.0.1       1104        0x80000001 0x003E27
172.12.15.0     100.7.0.1       1114        0x80000005 0x00CA39
172.12.34.0     100.7.0.1       1104        0x80000001 0x008331
172.12.123.0    100.7.0.1       1456        0x80000001 0x00A2B9

Success! So when you use “out” with your filter-list you must specify the Area # the route is broadcast “out” to, while “in” means where the route is being sent into.

It’s weird, but you really need to remember that difference, but exam points may depend on it, so review this topic and configure it yourself a few times if you don’t get it initially.

So to summarize this DEEP Dive into Filter vs Distribute Lists (and Prefix-Lists):

• A Distribute-list uses an ACL, whereas a filter-list uses an “ip prefix-list”
• “ip prefix-list (word) permit 0.0.0.0/0 le 32” is equivalent to an ACL “permit any”
• Distribute-Lists will store the route in its LS DB for the Area it was received in, but it will not create a route, and it will not flood that network into other Areas
• A filter-list will prevent the LS DB from holding the route for the defined Area, but flood it to all other Areas
• With filter-lists, think of defining traffic going “in”to a specified area, or “out” to a specific Area
• Both Distribute-Lists and Filter-Lists affect only Area’s local to them, so these would be configured on ABR’s and ASBR’s when filtering route Redistribution