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

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