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

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
Received on Tue Jan 08 2013 - 08:28:13 ART