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

Brian,

*Actually I just re-read what I originally wrote and I see what you mean.*

This is why I prefer the IOS versus talking about the theory and the RFC.
With IOS there is no misunderstanding. When I read what ccie99999 wrote, I
saw a student that was asking for help in configuring a route-map that
matches on "IP Source-route" and/or "IP Next-hop", so I posted a lab that
showed him how to configure these options.
It was after my post when you wrote:

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

*You will actually find that a lot of documentation examples are flat out
wrong
once you try to implement them. However as a CCIE candidate it's up to you
to
*
*actually implement these and find out what's right and wrong ;) *

What you wrote had nothing to do with Intra versus Inter-area routes,
actually there was no mention of it in your post, and I have never seen a
mention of it anywhere in Cisco Doc about using these to prefer one route
versus another, they are tools that we use to filter.

I speak few languages and no matter how I read this, it says what it said,
and what it said was wrong.

So I sugest exercising some professionalism and keeping this forum to
technical matters and NOT showing how insecure some of us are. To err is
human. No one said that you were less knowledgable, no one here thinks that
you are a bad instructor, and no one (Including me) feels that you don't
know what you are talking about. It is NOT the end of the world because we
make a mistake, but to continue and justify and say things like "*This is
what i meant*" especially coming from a person that interprets RFCs and
gets into the semantics, is not a good thing to do.

Do I use this forum as a source of business, IF ANYONE SAYS NO, THEY ARE
NOT TRUTHFUL. This is why our signatures are used for, and this is why I
said let's remove our signatures, INE, IPX, Micronics are who they are
because of GS, so let's not hide this fact.

Have a good day and God Bless sir

On Tue, Jan 8, 2013 at 9:56 AM, Brian McGahan <bmcgahan_at_ine.com> wrote:

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

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