RE: preferring OSPF inter-area compared to intra-area

How did he show what I said was wrong? None of the methods that Narbik posted can be used in this case to solve the issue. You verify this with a very simple test case:

R2 - R1 - R3

R1 has OSPF neighbors R2 and R3 both in area 0. R3 advertises the prefix 10.10.10.10/32 into area 1, and both R1 and R2 see this as an inter-area route:

R3#sh run int lo10
Building configuration...

Current configuration : 86 bytes
!
interface Loopback10
 ip address 10.10.10.10 255.255.255.255
 ip ospf 1 area 1
end

R1#show ip route 10.10.10.10
Routing entry for 10.10.10.10/32
  Known via "ospf 1", distance 110, metric 2, type inter area
  Last update from 13.0.0.3 on FastEthernet0/0.13, 00:00:14 ago
  Routing Descriptor Blocks:
  * 13.0.0.3, from 3.3.3.3, 00:00:14 ago, via FastEthernet0/0.13
      Route metric is 2, traffic share count is 1
R1#

The next-hop is 13.0.0.3, the link from R1 to R3, and the route-source is 3.3.3.3, R3's router-id. R2 now advertises the same prefix, but into area 0:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int lo10
R2(config-if)#ip address 10.10.10.10 255.255.255.255
R2(config-if)#ip ospf 1 area 0
R2(config-if)#end
R2#

As expected, R1 now prefers 10.10.10.10/32 via R2 because it is an Intra-Area route vs. an Inter-Area route:

R1#show ip route 10.10.10.10
Routing entry for 10.10.10.10/32
  Known via "ospf 1", distance 110, metric 2, type intra area
  Last update from 12.0.0.2 on FastEthernet0/0.12, 00:00:01 ago
  Routing Descriptor Blocks:
  * 12.0.0.2, from 2.2.2.2, 00:00:01 ago, via FastEthernet0/0.12
      Route metric is 2, traffic share count is 1

The next-hop is now 12.0.0.2, the link from R1 to R2, and the route-source is 2.2.2.2, R2's router-id. R1 now applies a filter to remove 10.10.10.10/32 via R2:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip access-list standard R2_ROUTER_ID
R1(config-std-nacl)#permit 2.2.2.2
R1(config-std-nacl)#exit
R1(config)#ip prefix-list TEN_PREFIX permit 10.10.10.10/32
R1(config)#route-map FILTER_TEN_PREFIX_VIA_R2 deny 10
R1(config-route-map)#match ip route-source R2_ROUTER_ID
R1(config-route-map)#match ip address prefix-list TEN_PREFIX
R1(config-route-map)#route-map FILTER_TEN_PREFIX_VIA_R2 permit 20
R1(config-route-map)#exit
R1(config)#router ospf 1
R1(config-router)#distribute-list route-map FILTER_TEN_PREFIX_VIA_R2 in
R1(config-router)#end
R1#

R1#show ip route 10.10.10.10
% Network not in table
R1#

The result is not that R1 prefers the route via R3, but instead that the route is removed from the routing table. The reason why is that only prefix fed to the RIB via the OSPF process was the route via R2. This is because the Intra-Area route is always preferred over the Inter-Area route. The filter doesn't affect the OSPF decision process, it only affects what goes into the routing table.

If R2 withdraws its Intra-Area advertisement, R1's OSPF process can feed the Inter-Area route to the RIB:

R2#config t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int lo10
R2(config-if)#shutdown
R2(config-if)#
*Jan 8 09:38:14.409: %LINK-5-CHANGED: Interface Loopback10, changed state to administratively down
*Jan 8 09:38:15.409: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback10, changed state to down

R1#show ip route 10.10.10.10
Routing entry for 10.10.10.10/32
  Known via "ospf 1", distance 110, metric 2, type inter area
  Last update from 13.0.0.3 on FastEthernet0/0.13, 00:00:08 ago
  Routing Descriptor Blocks:
  * 13.0.0.3, from 3.3.3.3, 00:00:08 ago, via FastEthernet0/0.13
      Route metric is 2, traffic share count is 1

In other words, you cannot use route filtering to prefer one route type over another in OSPF.

Brian McGahan, CCIE #8593 (R&S/SP/Security)
bmcgahan_at_INE.com

Internetwork Expert, Inc.
http://www.INE.com

-----Original Message-----
From: Carlos G Mendioroz [mailto:tron_at_huapi.ba.ar]
Sent: Tuesday, January 08, 2013 9:30 AM
To: Jay McMickle
Cc: Brian McGahan; Narbik Kocharians; ccie99999
Subject: Re: preferring OSPF inter-area compared to intra-area

Against what I usually do (refrain from geting involved in stupid vendor
wars) I do pick side here: Brian is clearly out of line and sending the otherwise technical discussion into worthless arena.

BTW, Narbik did show that what Brian said was wrong.
The problem with being instructor of CCIE courses here, is that you feel that being wrong is the end of the world... too bad.

-Carlos

Jay McMickle @ 08/01/2013 11:28 -0300 dixit:
> Not to pick sides, but whether or not this was a copy and paste from a workbook, I didn't see Narbik selling workbooks here. I thought it helped as it did help me remember these points. I don't work with OSPF so I find these useful.
>
> Now, had he mentioned "that all of this can be found on my workbooks", I would have thought that to be out of bounds.
>
> Regards,
> Jay McMickle- CCIE #35355 (RS)
> Sent from my iPhone 5
>
> On Jan 8, 2013, at 12:30 AM, Brian McGahan <bmcgahan_at_ine.com> wrote:
>
>> Hi Narbik,
>>
>> I would argue that your response is spam, and is not
>> applicable to the list. Once again you are posting out of context "free lab"
>> material without answering the original poster's question. I could likewise
>> post output from INE's lab workbooks or from Cisco's documentation
>> but that is not productive. If you have technology discussion input
>> to give we are more than happy to accept it.
>>
>> Thanks,
>>
>> Brian McGahan, CCIE #8593 (R&S/SP/Security)
>> bmcgahan_at_INE.com<mailto:bmcgahan_at_INE.com>
>>
>> Internetwork Expert, Inc.
>> http://www.INE.com
>>
>> From: Narbik Kocharians [mailto:narbikk_at_gmail.com]
>> Sent: Monday, January 07, 2013 11:15 PM
>> To: ccie99999
>> Cc: Brian McGahan; Carlos G Mendioroz; Cisco certification
>> Subject: Re: preferring OSPF inter-area compared to intra-area
>>
>> SORRY FOR THE LONG POST.
>>
>> Let's say we have a hub and spoke topology, where R1 is the hub
>> router, and R2, R3, and R4 are the spoke routers. All the links are
>> configured as P2P using the following IP addressing scheme:
>>
>> R1(S0/0.12)12.1.1.1/24--------------12.1.1.2(S0/0.21)R2<http://12.1.1
>> .1/24---
>> -----------12.1.1.2(S0/0.21)R2>
>> R1(S0/0.13)13.1.1.1/24--------------13.1.1.3(S0/0.31)R3<http://13.1.1
>> .1/24---
>> -----------13.1.1.3(S0/0.31)R3>
>> R1(S0/0.14)14.1.1.1/24--------------14.1.1.4(S0/0.41)R4<http://14.1.1
>> .1/24---
>> -----------14.1.1.4(S0/0.41)R4>
>>
>> R2 is running OSPF on its Lo0 and Lo1 with IP addresses of
>> 2.2.2.2/8<http://2.2.2.2/8> and 200.2.2.2/24<http://200.2.2.2/24>
>> respectively.
>>
>> R3 is running ospf on its Lo0 with an IP address of
>> 3.3.3.3/8<http://3.3.3.3/8>
>> R4 is running ospf on its Lo0 with an IP address of
>> 4.4.4.4/8<http://4.4.4.4/8>
>>
>> Everything is running in OSPF area 0. Let's begin:
>>
>> On R1
>>
>> R1#Show ip route ospf | I O
>> O 2.0.0.0/8<http://2.0.0.0/8> [110/65] via 12.1.1.2, 00:01:24,
>> Serial0/0.12
>> O 3.0.0.0/8<http://3.0.0.0/8> [110/65] via 13.1.1.3, 00:00:44,
>> Serial0/0.13
>> O 4.0.0.0/8<http://4.0.0.0/8> [110/65] via 14.1.1.4, 00:00:14,
>> Serial0/0.14
>> O 200.2.2.0/24<http://200.2.2.0/24> [110/65] via 12.1.1.2, 00:01:24,
>> Serial0/0.12
>>
>> You can see that R1 is receiving two routes from R2, networks
>> 2.0.0.0/8<http://2.0.0.0/8> and 200.2.2.0/24<http://200.2.2.0/24>.
>>
>> Let's filter all routes coming through S0/0.12:
>>
>> On R1
>>
>> R1(config)#Route-map tst deny 10
>> R1(config-route-map)#match interface s0/0.12 R1(config)#route-map tst
>> permit 90
>>
>> R1(config-route-map)#router ospf 1
>> R1(config-router)#distribute-list route-map tst in
>>
>> R1#Show ip route ospf | I O
>> O 3.0.0.0/8<http://3.0.0.0/8> [110/65] via 13.1.1.3, 00:00:38,
>> Serial0/0.13
>> O 4.0.0.0/8<http://4.0.0.0/8> [110/65] via 14.1.1.4, 00:00:38,
>> Serial0/0.14
>>
>> Let's remove the previous solution and filter network
>> 2.0.0.0/8<http://2.0.0.0/8> coming through S0/0.21 sub-interface:
>>
>> R1(config)#No route-map tst
>>
>> R1(config)#router ospf 1
>> R1(config-router)#No distribute-list route-map tst in
>>
>> R1#Show ip route ospf | I O
>> O 2.0.0.0/8<http://2.0.0.0/8> [110/65] via 12.1.1.2, 00:00:19,
>> Serial0/0.12
>> O 3.0.0.0/8<http://3.0.0.0/8> [110/65] via 13.1.1.3, 00:00:19,
>> Serial0/0.13
>> O 4.0.0.0/8<http://4.0.0.0/8> [110/65] via 14.1.1.4, 00:00:19,
>> Serial0/0.14
>> O 200.2.2.0/24<http://200.2.2.0/24> [110/65] via 12.1.1.2, 00:00:19,
>> Serial0/0.12
>>
>> The previous solution will NOT work here; to filter network
>> 2.0.0.0/8<http://2.0.0.0/8> coming through S0/0.21 we need to do the
>> following:
>>
>> R1(config)#access-list 2 permit 2.0.0.0 0.255.255.255
>>
>> R1(config)#route-map tst deny 10
>> R1(config-route-map)#match interface s0/0.12
>> R1(config-route-map)#match ip addr 2 R1(config)#route-map tst permit
>> 90
>>
>> R1(config-route-map)#router ospf 1
>> R1(config-router)#distribute-list route-map tst in
>>
>> R1#Show ip route ospf | I O
>> O 3.0.0.0/8<http://3.0.0.0/8> [110/65] via 13.1.1.3, 00:00:23,
>> Serial0/0.13
>> O 4.0.0.0/8<http://4.0.0.0/8> [110/65] via 14.1.1.4, 00:00:23,
>> Serial0/0.14
>> O 200.2.2.0/24<http://200.2.2.0/24> [110/65] via 12.1.1.2, 00:00:23,
>> Serial0/0.12
>>
>> Perfect it worked, obviously the same task can be configured using
>> another method.
>>
>> Let's remove the configuration from the previous solution and filter
>> network 200.2.2.0/24<http://200.2.2.0/24> coming from R2, but this
>> time we are going to use the "IP Next-hop" option:
>>
>> R1(config)#No route-map tst
>> R1(config)#No access-list 2
>>
>> R1(config)#router ospf 1
>> R1(config-router)#No distribute-list route-map tst in
>>
>> R1#Show ip route ospf | I O
>> O 2.0.0.0/8<http://2.0.0.0/8> [110/65] via 12.1.1.2, 00:00:29,
>> Serial0/0.12
>> O 3.0.0.0/8<http://3.0.0.0/8> [110/65] via 13.1.1.3, 00:00:29,
>> Serial0/0.13
>> O 4.0.0.0/8<http://4.0.0.0/8> [110/65] via 14.1.1.4, 00:00:29,
>> Serial0/0.14
>> O 200.2.2.0/24<http://200.2.2.0/24> [110/65] via 12.1.1.2, 00:00:29,
>> Serial0/0.12
>>
>> To filter using the "IP next-hop" option:
>>
>>
>> R1(config)#access-list 1 permit 200.2.2.0 0.0.0.255
>>
>> R1(config)#access-list 10 permit host 12.1.1.2
>>
>> R1(config)#route-map tst deny 10
>> R1(config-route-map)#match ip addr 1
>> R1(config-route-map)#match ip next-hop 10 R1(config)#route-map tst
>> permit 90
>>
>> R1(config-route-map)#router ospf 1
>> R1(config-router)#distribute-list route-map tst in
>>
>> R1#Show ip route ospf | I O
>> O 2.0.0.0/8<http://2.0.0.0/8> [110/65] via 12.1.1.2, 00:00:05,
>> Serial0/0.12
>> O 3.0.0.0/8<http://3.0.0.0/8> [110/65] via 13.1.1.3, 00:00:05,
>> Serial0/0.13
>> O 4.0.0.0/8<http://4.0.0.0/8> [110/65] via 14.1.1.4, 00:00:05,
>> Serial0/0.14
>>
>> Now....let's remove the previous solution and use the "route-source" option:
>>
>> R1(config)#No access-list 1
>> R1(config)#No access-list 10
>> R1(config)#No route-map tst
>> R1(config)#router ospf 1
>> R1(config-router)#No distribute-list route-map tst in
>>
>> R1#Show ip route ospf | I O
>> O 2.0.0.0/8<http://2.0.0.0/8> [110/65] via 12.1.1.2, 00:00:34,
>> Serial0/0.12
>> O 3.0.0.0/8<http://3.0.0.0/8> [110/65] via 13.1.1.3, 00:00:34,
>> Serial0/0.13
>> O 4.0.0.0/8<http://4.0.0.0/8> [110/65] via 14.1.1.4, 00:00:34,
>> Serial0/0.14
>> O 200.2.2.0/24<http://200.2.2.0/24> [110/65] via 12.1.1.2, 00:00:34,
>> Serial0/0.12
>>
>>
>> To use the route-source option, we MUST use the RID of R2 in the access-list.
>> To find out the RID of R2:
>>
>> R2#Show ip ospf | I ID
>> Routing Process "ospf 1" with ID 0.0.0.2
>>
>> R1(config)#access-list 3 permit 0.0.0.2 R1(config)#access-list 30
>> permit 200.2.2.0 0.0.0.255
>>
>> R1(config)#route-map tst deny 10
>> R1(config-route-map)#match ip addr 30 R1(config-route-map)#match ip
>> route-source 3 R1(config)#route-map tst permit 90
>> R1(config-route-map)#router ospf 1 R1(config-router)#distribute-list
>> route-map tst in
>>
>> R1#Show ip route ospf | I O
>> O 2.0.0.0/8<http://2.0.0.0/8> [110/65] via 12.1.1.2, 00:00:06,
>> Serial0/0.12
>> O 3.0.0.0/8<http://3.0.0.0/8> [110/65] via 13.1.1.3, 00:00:06,
>> Serial0/0.13
>> O 4.0.0.0/8<http://4.0.0.0/8> [110/65] via 14.1.1.4, 00:00:06,
>> Serial0/0.14
>>
>>
>> I hope this helped.
>>
>> On Mon, Jan 7, 2013 at 7:09 PM, ccie99999
>> <ccie99999_at_gmail.com<mailto:ccie99999_at_gmail.com>> wrote:
>> Thanks for your reply Brian..
>>
>> I see your point about filtering the RIB and not what OSPF chooses. (
>> I didn't realize this before actually)
>>
>> What I was complaining is that route-map matching ip next-hop or
>> matching ip route-source is not working when applied with a
>> distribute list inbound to ospf.
>> Strange I don't find any official reference on this scenario.
>>
>>
>> On Mon, Jan 7, 2013 at 6:08 PM, Brian McGahan
>> <bmcgahan_at_ine.com<mailto:bmcgahan_at_ine.com>> wrote:
>>
>>> This filters the RIB (routing table), not the OSPF decision process.
>>> By the time you apply this OSPF has already chosen the intra area
>>> route over the inter area one, so all you can do is permit or deny the intra area one.
>>>
>>> The only way to really accomplish this is to make the two route
>>> types equal. If you were to change the inter area route to intra
>>> area with something like a virtual link or tunnel then you can
>>> modify which path is preferred.
>>
>>
>> --
>> @ccie99999
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _____________________________________________________________________
>> __ Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Narbik Kocharians
>> CCSI#30832, CCIE# 12410 (R&S, SP, Security)
>> www.MicronicsTraining.com<http://www.micronicstraining.com/>
>> Sr. Technical Instructor
>> YES! We take Cisco Learning Credits!
>> A Cisco Learning Partner
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _____________________________________________________________________
>> __ Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>

--
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net