Friday, February 13, 2009

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

5 comments:

  1. Very informative tutorial...I learned quite a few things. Thanks!

    DnF

    ReplyDelete
  2. great work buddy..

    ReplyDelete
  3. Why don't u provide ip addresses for router interface..

    ReplyDelete
  4. Very informative post because you were able to present meaningful information and your illustration was very detailed for us to easily understand about it. Great job!

    Ellen
    Cliquez ici to visit my website.

    ReplyDelete

Note: Only a member of this blog may post a comment.