IS-IS Filtering

IS-IS as a link-state routing protocol is a bit restrictive when it comes to filtering. All routers within an area require a synchronized level 1 database, the same thing applies to all level 2 routers. The level 2 database has to be the same on all routers. Once an LSP is generated, you can’t filter it anymore.

There are two methods how you can filter something:

  • Distribute-list inbound filtering.
  • Filtering between level 1 and level 2.

Inbound filtering is possible, this doesn’t prevent an LSP from being installed in the database but it does prevent an LSP from being installed in the routing table. It is also possible to filter level 1 LSPs from being copied to the level 2 database.

In this lesson, I will show you both examples.

Configuration

Here is the topology we will use:

is-is filtering topology

We have three routers in area 123 and one in area 4. R1 has a loopback interface with a prefix that we will filter.

Configurations

Want to take a look for yourself? Here you will find the startup configuration of each device.

R1

hostname R1
!
ip cef
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip router isis 
!
interface GigabitEthernet0/1
 ip address 192.168.12.1 255.255.255.0
 ip router isis 
!
router isis
 net 49.0123.0000.0000.0001.00
 is-type level-1
 log-adjacency-changes
!
end

R2

hostname R2
!
ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.12.2 255.255.255.0
 ip router isis 
!
interface GigabitEthernet0/2
 ip address 192.168.23.2 255.255.255.0
 ip router isis 
!
router isis
 net 49.0123.0000.0002.00
 is-type level-1
 log-adjacency-changes
!
end

R3

hostname R3
!
ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.34.3 255.255.255.0
 ip router isis 
!
interface GigabitEthernet0/2
 ip address 192.168.23.3 255.255.255.0
 ip router isis 
!
router isis
 net 49.0123.0000.0000.0003.00
 log-adjacency-changes
!
end

R4

hostname R4
!
ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.34.4 255.255.255.0
 ip router isis 
!
router isis
 net 49.0004.0000.0000.0004.00
 is-type level-2-only
 log-adjacency-changes
!
end

Let’s get started.

Distribute-list Inbound filtering

We’ll start with the distribute-list which allows us to prevent something from being installed in the routing table. Let’s take a look at R2:

R2#show ip route isis

      1.0.0.0/32 is subnetted, 1 subnets
i L1     1.1.1.1 [115/20] via 192.168.12.1, 00:38:16, GigabitEthernet0/1
i L1  192.168.34.0/24 [115/20] via 192.168.23.3, 00:37:26, GigabitEthernet0/2

Let’s get rid of the 1.1.1.1/32 prefix. I will use an access-list for this:

R2(config)#ip access-list standard R1_L0
R2(config-std-nacl)#deny host 1.1.1.1
R2(config-std-nacl)#permit any

We can enable the access-list with the distribute-list command:

R2(config)#router isis
R2(config-router)#distribute-list R1_L0 in 

When you look at the level 1 database, you will see that the prefix is still there:

R2#show isis database level-1 verbose R1.00-00


IS-IS Level-1 LSP R1.00-00
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
R1.00-00              0x00000002   0xEA6C        1007              0/0/0
  Area Address: 49.0123
  NLPID:        0xCC 
  Hostname: R1
  Metric: 10         IS R2.01
  IP Address:   1.1.1.1
  Metric: 10         IP 1.1.1.1 255.255.255.255
  Metric: 10         IP 192.168.12.0 255.255.255.0

We can’t remove it from the database but it will be gone from the routing table:

R2#show ip route isis

i*L1  0.0.0.0/0 [115/10] via 192.168.23.3, 00:03:29, GigabitEthernet0/2
i L1  192.168.34.0/24 [115/20] via 192.168.23.3, 00:03:39, GigabitEthernet0/2

Since it’s still in the database, other routers will learn about. For example, here’s R3:

R3#show ip route isis

      1.0.0.0/32 is subnetted, 1 subnets
i L1     1.1.1.1 [115/30] via 192.168.23.2, 00:42:35, GigabitEthernet0/2
i L1  192.168.12.0/24 [115/20] via 192.168.23.2, 00:42:47, GigabitEthernet0/2

This introduces a problem. Since R2 is a transit router, R3 will never be able to reach 1.1.1.1/32. That’s something to keep in mind…

Level 1 to Level 2 filtering

Let’s continue. R3 and R4 still have 1.1.1.1/32 in their routing tables. Let’s see if we can prevent this prefix from being installed on R4. Right now it does have this route in its routing table:

R4#show ip route isis

      1.0.0.0/32 is subnetted, 1 subnets
i L2     1.1.1.1 [115/40] via 192.168.34.3, 00:42:26, GigabitEthernet0/1
i L2  192.168.12.0/24 [115/30] via 192.168.34.3, 00:42:26, GigabitEthernet0/1
i L2  192.168.23.0/24 [115/20] via 192.168.34.3, 00:42:26, GigabitEthernet0/1

R4 has learned this from the level 2 LSP that R3 has generated. We can see it here:

R3#show isis database level-2 verbose R3.00-00


IS-IS Level-2 LSP R3.00-00
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
R3.00-00            * 0x00000003   0x1660        899               0/0/0
  Area Address: 49.0123
  NLPID:        0xCC 
  Hostname: R3
  Metric: 10         IS R3.01
  IP Address:   192.168.23.3
  Metric: 10         IP 192.168.23.0 255.255.255.0
  Metric: 10         IP 192.168.34.0 255.255.255.0
  Metric: 30         IP 1.1.1.1 255.255.255.255
  Metric: 20         IP 192.168.12.0 255.255.255.0

R3 added 1.1.1.1/32 by copying it from its level 1 database to its level 2 database. Let’s see if we can prevent that from happening…

There are two methods. You can use a distribute-list with extended access-list numbers or a route-map. I prefer the route-map since it allows you to use named access-lists. Let’s create an access-list that matches the loopback interface of R1:

R3(config)#ip access-list extended R1_L0
R3(config-ext-nacl)#deny ip host 1.1.1.1 any
R3(config-ext-nacl)#permit ip any any

Let’s add this access-list in a route-map:

R3(config)#route-map L1_L2_FILTER permit 10
R3(config-route-map)#match ip address R1_L0

The only thing left to do is to activate it. This is done with the redistribute command:

R3(config)#router isis
R3(config-router)#redistribute isis ip level-1 into level-2 route-map L1_L2_FILTER

This tells R3 to redistribute everything from level 1 to level 2 except for the things that we added in our route-map. Let’s take another look at R3’s level 2 database:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 655 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

535 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Hi Rene,
    We know that for Link state Routing Protocol "The database within an area has to be same " .I want to know more briefly about this why need the DB synchronized must ?? What issue will raise if not synchronized . Appreciate your very clear explanation as always .Thx

    br//zaman

  2. Hello Zaman

    A fundamental characteristic of Link State routing protocols is that every router constructs a map of the connectivity to the network that indicates which nodes are connected to which other nodes. This map is contained within the database. Based on this map, each router independently calculates the next best logical path from it to every possible destination on the network. These collections of best paths are then used to populate the routing table on the router.

    If the database is not the same in all routers within an area, then there can be sev

    ... Continue reading in our forum

Ask a question or join the discussion by visiting our Community Forum