Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the complianz-gdpr domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /mnt/web216/a3/47/510846147/htdocs/STRATO-apps/wordpress_01/app/wp-includes/functions.php on line 6114 Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the memberpress domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /mnt/web216/a3/47/510846147/htdocs/STRATO-apps/wordpress_01/app/wp-includes/functions.php on line 6114 Lab 10 – OSPF Filtering with Distance – Devnet Community

Lab 10 – OSPF Filtering with Distance

Prerequisites: CCNP level skills.

Note!
Routers use OSPF configuration from the lab 6.

One thing to remember is that all routers within the same OSPF area share the EXACT same LSA database! This will affect how we can filter OSPF updates.

There are a few filtering methods:

  1. Ingress filtering using a ‘distribute-list’. 
  2. Ingress filtering using a ‘distribute-list’ with a ‘route-map’.
  3. Ingress filtering by changing the Administrative Distance of the prefixes to UNKNOWN (255).
  4. Type 3 LSA filtering using ‘area area-number range’ command (applied on ABR).
  5. Type 3 LSA filtering using ‘filter-list’ command.
  6. LSA Flooding Filtering.

The first three methods (1-3) prevent prefixes from entering the routing table. The LSAs are still going to be present in the LSDB since all routers in OSPF area must be synchronized (the same LSDB). These methods are the intra-area filters.

The last three methods (4-6) are inter-area filters preventing LSAs from entering LSDB.

Topology

Pic. 1 – OSPF Multi-Area Topology.
Task List

Task 1
On R3, check the routing table. Make sure that it shows prefixes: 172.16.101.0/24 and 172.16.102.0/24.

Task 2
Configure R3 so prefixes 172.16.101.0/24 and 172.16.102.0/24 do not show in the routing table but show in the LSDB. Do not use distribute-list to accomplish this. Make sure that you match on the router-id of advertising routers.

Task 3
Check the results. Both prefixes in question should be removed from the routing table but should be still seen in the LSDB.

Lab Solution

Task 1

On R3, check the routing table. Make sure that it shows prefixes: 172.16.101.0/24 and 172.16.102.0/24.
Pic. 2 – R3’s Routing Table.
Task 2

Configure R3 so prefixes 172.16.101.0/24 and 172.16.102.0/24 do not show in the routing table but show in the LSDB. Do not use distribute-list to accomplish this.Make sure that you match on the router-id of advertising routers.

R3 Configuration:

!
ip access-list standard FILTER
 permit 172.16.101.0 0.0.0.255
 permit 172.16.102.0 0.0.0.255
!
router ospf 1
router-id 3.3.3.3
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
distance 255 1.1.1.1 0.0.0.0 FILTER
distance 255 2.2.2.2 0.0.0.0 FILTER
!

Task 3

Check the results. Both prefixes in question should be removed from the routing table but should be still seen in the LSDB.
R3#show ip ospf database router
Pic. 3 – R3’s Routing Table with Filter.

The prefixes 172.16.101.0/24 and 172.16.102.0 are gone!

Pic. 4 – LSDB with the Filter (172.16.101.0/24).
Pic. 4 – LSDB with the Filter (172.16.102.0/24).

Share:

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *