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

Please let us all know the end result.

Thanks very much my friend.

On Mon, Jan 7, 2013 at 11:55 PM, ccie99999 <ccie99999_at_gmail.com> wrote:

> Guys, I don't want to be between the devil and the deep blue sea but:
> I'm a INE customer and I did write that in a previous mail. If a INE
> competitor wants to spend his time and help me I'm more than happy. I do
> also think that trainers are not here only for having an implicit
> advertisement of their company.
> Said so I was actually happy with both answers.. route-map thing
> triggered from my 1st question (the one in the subjetc).
> Narbik has is own way to prove result, creating specific practice labs,
> maybe Brian likes going to the point with theory (documentation and rfc).
> This is a free mailing list.. I don't pay anything for it and I
> appreciated everyone takes his time reading my email and helping me in
> understanding where I'm wrong.
> Then.. I will lab what Narbik suggested and see if it matches with what
> Brian wrote. (one is saying the opposite of the other, so it should be easy
> to find who is wrong)
> Then.. I'm a happy INE customer and I heard every day very nice feedback
> from Narbik's customers.. You guys are the best in the market and this
> mailing list should be kept free from personal non-technical
> debates/discussions.
> Thanks for your time Brian and Narbik (and Pete and Carlos).. I will lab
> this asap and get back here if something it's still not clear.
>
>
> On Tue, Jan 8, 2013 at 7:07 AM, Narbik Kocharians <narbikk_at_gmail.com>wrote:
>
>> Let me enlighten you. Read ccie99999's post, his last one.
>>
>> Who ever is reading this post, please let me know if I was out of hand
>> and i was spamming. Don't unicast, send it to all. so you can enlighten
>> this gentleman.
>>
>>
>> On Mon, Jan 7, 2013 at 11:02 PM, Brian McGahan <bmcgahan_at_ine.com> wrote:
>>
>>> The subject title is preferring OSPF inter-area compared to
>>> intra-area. Please enlighten us as to how your input tells us how to
>>> prefer OSPF Inter-Area routes over Intra-Area routes.****
>>>
>>> ** **
>>>
>>> Brian McGahan, CCIE #8593 (R&S/SP/Security)****
>>>
>>> bmcgahan_at_INE.com****
>>>
>>> ** **
>>>
>>> Internetwork Expert, Inc.****
>>>
>>> http://www.INE.com****
>>>
>>> ** **
>>>
>>> *From:* Narbik Kocharians [mailto:narbikk_at_gmail.com]
>>> *Sent:* Tuesday, January 08, 2013 12:41 AM
>>> *To:* Brian McGahan
>>> *Cc:* ccie99999; Carlos G Mendioroz; Cisco certification
>>>
>>> *Subject:* Re: preferring OSPF inter-area compared to intra-area****
>>>
>>> ** **
>>>
>>> WOW....****
>>>
>>> First of all what I wrote is very applicable to the question that
>>> ccie99999 had in this post. Because he was complaining that it does not
>>> work. The following is his post:****
>>>
>>> "*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.*"
>>> Did i miss something?****
>>>
>>> ** **
>>>
>>> What are you referring to? Please be more specific. ****
>>>
>>> These are NOT labs from my book, people that have my books will tell you
>>> that these labs are NOT from my book. I just took my time to respond with
>>> the configuration that clearly shows that the options work correctly.
>>> Besides even if I post something from my book, so what? Are you the
>>> moderator? Why don't we get Paul B involved, because you are totally our
of
>>> hand. ****
>>>
>>> ** **
>>>
>>> BTW, you agreed that these options do not work, or they are not
>>> supported, and the above configuration proves that you are wrong. AGAIN.
>>> ****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> On Mon, Jan 7, 2013 at 10:30 PM, 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 posters question. I could
>>> likewise post output from INEs lab workbooks or from Ciscos
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****
>>>
>>> ****
>>>
>>> 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.*****
>>>
>>> ****
>>>
>>> *Lets 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%28S0/0.21%29R2>
>>> ****
>>>
>>>
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%28S0/0.31%29R3>
>>> ****
>>>
>>>
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%28S0/0.41%29R4>
>>> ****
>>>
>>> ****
>>>
>>> *R2 is running OSPF on its Lo0 and Lo1 with IP addresses of 2.2.2.2/8and
>>> 200.2.2.2/24 respectively.*****
>>>
>>> * *****
>>>
>>> *R3 is running ospf on its Lo0 with an IP address of 3.3.3.3/8*****
>>>
>>> *R4 is running ospf on its Lo0 with an IP address of 4.4.4.4/8*****
>>>
>>> * *****
>>>
>>> *Everything is running in OSPF area 0. Lets begin:*****
>>>
>>> ****
>>>
>>> *On R1*****
>>>
>>> ****
>>>
>>> R1#Show ip route ospf | I O****
>>>
>>> *O 2.0.0.0/8 [110/65] via 12.1.1.2, 00:01:24, Serial0/0.12*****
>>>
>>> O 3.0.0.0/8 [110/65] via 13.1.1.3, 00:00:44, Serial0/0.13****
>>>
>>> O 4.0.0.0/8 [110/65] via 14.1.1.4, 00:00:14, Serial0/0.14****
>>>
>>> *O 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/8and
>>> 200.2.2.0/24.*****
>>>
>>> ****
>>>
>>> *Lets 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 [110/65] via 13.1.1.3, 00:00:38, Serial0/0.13****
>>>
>>> O 4.0.0.0/8 [110/65] via 14.1.1.4, 00:00:38, Serial0/0.14****
>>>
>>> ****
>>>
>>> *Lets remove the previous solution and filter network 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 [110/65] via 12.1.1.2, 00:00:19, Serial0/0.12****
>>>
>>> O 3.0.0.0/8 [110/65] via 13.1.1.3, 00:00:19, Serial0/0.13****
>>>
>>> O 4.0.0.0/8 [110/65] via 14.1.1.4, 00:00:19, Serial0/0.14****
>>>
>>> O 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/8coming 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 [110/65] via 13.1.1.3, 00:00:23, Serial0/0.13****
>>>
>>> O 4.0.0.0/8 [110/65] via 14.1.1.4, 00:00:23, Serial0/0.14****
>>>
>>> O 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.*****
>>>
>>> * *****
>>>
>>> *Lets remove the configuration from the previous solution and filter
>>> network 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 [110/65] via 12.1.1.2, 00:00:29, Serial0/0.12****
>>>
>>> O 3.0.0.0/8 [110/65] via 13.1.1.3, 00:00:29, Serial0/0.13****
>>>
>>> O 4.0.0.0/8 [110/65] via 14.1.1.4, 00:00:29, Serial0/0.14****
>>>
>>> O 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 [110/65] via 12.1.1.2, 00:00:05, Serial0/0.12****
>>>
>>> O 3.0.0.0/8 [110/65] via 13.1.1.3, 00:00:05, Serial0/0.13****
>>>
>>> O 4.0.0.0/8 [110/65] via 14.1.1.4, 00:00:05, Serial0/0.14****
>>>
>>> * *****
>>>
>>> *Now.lets 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 [110/65] via 12.1.1.2, 00:00:34, Serial0/0.12****
>>>
>>> O 3.0.0.0/8 [110/65] via 13.1.1.3, 00:00:34, Serial0/0.13****
>>>
>>> O 4.0.0.0/8 [110/65] via 14.1.1.4, 00:00:34, Serial0/0.14****
>>>
>>> O 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 [110/65] via 12.1.1.2, 00:00:06, Serial0/0.12****
>>>
>>> O 3.0.0.0/8 [110/65] via 13.1.1.3, 00:00:06, Serial0/0.13****
>>>
>>> O 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> 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> 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****
>>>
>>>
>>>
>>> ****
>>>
>>> ** **
>>>
>>> -- ****
>>>
>>> *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****
>>>
>>
>>
>>
>> --
>> *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
>>
>
>
>
> --
> @ccie99999
>

--
*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