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

Actually I just re-read what I originally wrote and I see what you mean. When I said "those options are not supported" I meant for filtering out the intra-area route to prefer the inter-area one. You can still use the filter, just not for this purpose. The document in question actually talks about this too:

"The distribute-list in command can be configured to prevent routes from being installed in the global Routing Information Base (RIB). Prior to the implementation of OSPF local RIB (for feature information on OSPF local RIB, see OSPFv2 Local RIB), OSPF would attempt to install a less preferred route (e.g. an inter-area route when the intra-area path is filtered). With OSPF local RIB, only the best route is considered (because this is the only route the local RIB maintains). There is no concept of a "second-best" OSPF route. For more information on the routing algorithm used by Cisco OSPF routers, please refer to RFC 2328."

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 11:36 AM
To: Brian McGahan
Cc: ccielab_at_groupstudy.com; Jay McMickle; Narbik Kocharians; ccie99999
Subject: Re: preferring OSPF inter-area compared to intra-area

Brian,
when ccie99999 said:

        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.

you answered:

        That's correct, those options are not supported. A lot of the
        documentation is repeated syntax-wise for features that may not
        be actually applicable. For example the distribute-list with
        match ip next-hop may not work for OSPF even though it is still
        documented under that feature.

and one of Narbick's examples show that indeed they work.

Do this apply to the initial question ? Not as an answer to the problem but yes as colateral info so ccie99999 can understand what the tools are and what they do.

-Carlos

Brian McGahan @ 08/01/2013 14:24 -0300 dixit:
> 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
>

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