Re: Filtering external OSPF routes on ABR in direction of area

Petr gives an excellent explanation above. To add to that, I just completed
a two part blog series related to the topic of type-4 LSAs and the
forwarding address which I think you might find useful. It is on our blog if
you are interested.

On Fri, Nov 13, 2009 at 12:19 PM, Tom Solski <tom.solski_at_gmail.com> wrote:

> Thanks Petr for great reading. It works exactly as you described it.
> Manipulating FA here does the trick :)
>
>
>
> -----Original Message-----
> From: petrsoft_at_gmail.com [mailto:petrsoft_at_gmail.com] On Behalf Of Petr
> Lapukhov
> Sent: 13-Nov-09 04:27
> To: Tom Solski
> Cc: S Malik; Miroslav Kosut; Cisco certification
> Subject: Re: Filtering external OSPF routes on ABR in direction of area 0.
>
> Tom,
>
> filtering OSPF external routing information is not easy, as it is
> being conveyed in type-5 LSAs, which have the flooding scope of the
> whole OSPF AS, with the exception to stub areas. You cannot filter the
> information "en-route" as LSAs must be flooded per normal OSPF
> behavior. You may, however, resort to "local" filtering, blocking the
> routing information from entering the local RIB. Another good advice,
> mentioned previously, is converting the area into NSSA, bringing
> type-7 LSAs to life. These have the flooding scope of a single area,
> and tranlsate to type-5 LSA on the respective ABR, allowing for
> filtering at area boundaries.
>
> There is yet another, somewhat obscure, method, which requires minimum
> changes to the existing infrastructure. It is based on the fact that
> type-5 LSAs may have non-zero FA under "some conditions". If a
> non-zero FA is present in LSA, every OSPF router need to have this FA
> reachable via it's local RIB, prior to installing the external prefix
> in the routing table. Normally, the FA is being propagated outside the
> area using summary-LSAs, and you may filter the respective routing
> information using OSPF inter-area prefix filters (area X filter-list).
> Once the routers outside the area containing ASBR lose the route to
> the FA, they will ignore the information in type-5 LSAs and will not
> install the routes into the RIB - this might be used as a "filtering
> solution". Notice, however, that they will still retain the LSAs in
> their databases.
>
> As mentioned, the FA is non-mandatory in type-5 LSA (unless they have
> been translated from type-7). In order to make the LSAs have the FA,
> you need to satisfy the conditions described in this article:
>
>
> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009405a
> .shtml<http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009405a%0A.shtml>
>
> Namely:
>
> - OSPF is enabled on the ASBR's next hop interface AND
> - ASBR's next hop interface is non-passive under OSPF AND
> - ASBR's next hop interface is not point-to-point AND
> - ASBR's next hop interface is not point-to-multipoint AND
> - ASBR's next hop interface address falls under the network range
> specified in the router ospf command.
>
> If you may tolerate some of the security drawbacks and satisfy these
> conditions, all your type-5 LSAs will have the FA pointing to the
> source of external routes. Notice that you may need to enforce the
> network type "Broadcast" or "non-broadcast" on the link connecting to
> the external router. After this, all you have to do is to use
> inter-area route filters at the ABR to filter out the network prefix
> corresponding to the link connected to the external router. Then, all
> routers outside your "private" area will ignore the information in
> type-5 LSAs.
>
> Im currently working on a blog post with a detailed example for this
> particular scenario. You may read some condensed information on OSPF
> routing filter in this blog post:
>
>
> http://blog.internetworkexpert.com/2009/08/17/ospf-route-filtering-demystifi
> ed/<http://blog.internetworkexpert.com/2009/08/17/ospf-route-filtering-demystifi%0Aed/>
>
> Note however, that the method of "hiding" information is not very
> secure. It would be better to invest some time and probably money and
> come up with a VPN-based solution for information isolation.
>
> HTH,
> --
> Petr Lapukhov, petr_at_INE.com
> CCIE #16379 (R&S/Security/SP/Voice)
>
> Internetwork Expert, Inc.
> http://www.INE.com
> Toll Free: 877-224-8987
> Outside US: 775-826-4344
>
> 2009/11/12 Tom Solski <tom.solski_at_gmail.com>:
> > Perhaps I was not clear...
> >
> > Conditions are :
> >
> > R1------area1-----R2-----area0------R3--------area2--------R4
> >
> > ALL routers must see and have connectivity to network 4.0.0.0
> redistributed on R4
> > ONLY router R1 and R2 can see and have connectivity to network 1.0.0.0
> redistributed on R1.
> > No other router in the domain can see 1.0.0.0 in its routing table.
> > Filtering must be done on R2
> >
> > This is a challenge on a real network. Area 1 is a branch that has
> connectivity to a partner, major car manufacturer, who requires maximum
> security, including hiding his routes from the rest of our network. I know
> that I could configure b distribute-list inb on R3 and achieve required
> result. The problem is that there is over 100 remote sites where every site
> is an area and we cannot reconfigure that many routers manually. So
> basically filtering must be done on R2 in outbound direction, toward Area
> 0.
> >
> > If nothing else works I will configure area 1 as NSSA and then use
> summary
> address on R2 but I prefer not to.
> > I just cannot believe that an area must be an NSSA to be able to filter
> external routes in outbound direction (toward area 0).
> >
> > I will wait for Narbikb s videos next week so maybe this will clarify
> something for me b :
> >
> > ===================================================================
> >
> > From: S Malik [mailto:ccie.09_at_gmail.com]
> > Sent: 11-Nov-09 22:56
> > To: Tom Solski
> > Cc: Miroslav Kosut; Cisco certification
> > Subject: Re: How to filter external OSPF routes from database ?
> >
> > I am not sure if there is any condition associated with the task. With
> the
> provided info, I think, you can configure A1&2 as normal areas, and use "ip
> os database-filter all out" on R2's interface connected to R3.
> > On Wed, Nov 11, 2009 at 3:31 PM, Tom Solski <tom.solski_at_gmail.com>
> wrote:
> > It works in my lab too. On R2 there is a config which filters out route
> > 1.0.0.0 from being propagated into Area 0:
> >
> > <<<
> > area 1 nssa no-summary
> > summary-address 1.0.0.0 255.0.0.0 not-advertise
> >>>>
> >
> > So far the only way I found to filter external routes out of an area is
> to
> > convert it to NSSA. In the same time area 1 will not see any outside
> > routes...
> >
> > So let me define the new challenge, just for the heck of it:
> >
> > R1------area1-----R2-----area0------R3--------area2--------R4
> > R1 redistributes external network 1.0.0.0/8 into area1.
> > R4 redistributes external network 4.0.0.0/8 into area2.
> >
> > Route 1.0.0.0 must be visible only inside area 1 (i.e. on router R1 and
> R2
> > only)
> > Route 2.0.0.0 must be visible on ALL routers in the domain.
> >
> > Is that possible ?
> >
> >
> > -----Original Message-----
> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> S
> > Malik
> > Sent: 11-Nov-09 11:02
> > To: Tom Solski
> > Cc: Miroslav Kosut; Cisco certification
> > Subject: Re: How to filter external OSPF routes from database ?
> >
> > Tom,
> > I checked,if area is nssa, then you can filter either on actual ASBR or
> ABR
> > by using the same cmd (pl test and verify). in ASBR case, it take lsa
> type-7
> > out from DB and at ABR it takes lsa-5 out of database but lsa-7 still
> > remains in DB which means that nssa will have this route and rest of the
> > areas will not. If we run it on actual ASBR then whole ospf domain will
> not
> > have the routes which were re-distributed.
> >
> >
> >
> > On Tue, Nov 10, 2009 at 7:27 PM, Tom Solski <tom.solski_at_gmail.com>
> wrote:
> >
> >> Thanks Miroslav. Summary address on R2 works if area 1 is configured as
> > not
> >> so stubby (NSSA). I am referring to this topology:
> >>
> >> R1------area1-----R2-----area0------R3--------area2--------R4
> >> R1 redistributes external 1.0.0.0/8 into area1.
> >>
> >> IOS appears to me really inconsistent here. Why summary-address works
> for
> >> N2
> >> routes and does not for E2 routes?
> >>
> >>
> >> -----Original Message-----
> >> From: Miroslav Kosut [mailto:miroslav.kosut_at_gmail.com]
> >> Sent: 10-Nov-09 16:22
> >> To: Tomasz Solski
> >> Cc: Cisco certification
> >> Subject: Re: How to filter external OSPF routes from database ?
> >>
> >> Stubby area :-)
> >>
> >> External LSAs (LSA5) can be filtered on ASBRs using summary-address
> >> NET MASK not-advertise. I don't know about any other way of filtering
> >> them on ABRs except using stubby areas.
> >>
> >> Regards,
> >> Miroslav
> >>
> >> On Nov 10, 2009, at 10:15 PM, Martin Hogan wrote:
> >>
> >> > What does the Cisco Doc tell you about that command?
> >> >
> >> > Hint: It's only effective on a particular LSA type.
> >> >
> >> >
> >> >
> >> > On Tue, Nov 10, 2009 at 7:44 AM, Tomasz Solski
> >> > <tom.solski_at_gmail.com> wrote:
> >> >
> >> >> How to filter external OSPF routes from database ?
> >> >>
> >> >> Here is an example:
> >> >>
> >> >> R1------Ar0------R2------Ar1-------R3
> >> >>
> >> >> R1 redistributes routes into Area 0.
> >> >>
> >> >> I want ot configure R2 so R3 does not have a specific external
> >> >> route in its
> >> >> database.
> >> >>
> >> >> I tried on R2:
> >> >> <<<
> >> >> ip prefix-list R1toR3 seq 5 deny 1.1.12.0/24
> >> >> ip prefix-list R1toR3 seq 10 permit 0.0.0.0/0 le 32
> >> >> router ospf 1
> >> >> area 1 filter-list prefix R1toR3 in
> >> >>>>>
> >> >>
> >> >> but it looks like external routes can not be filtered with filter
> >> >> list. As
> >> >> soon as I advertise 1.1.12.0/24 on R1, instead of redistributing
> >> >> it, it
> >> >> disappears from R3's database and routing table.
> >> >>
> >> >>
> >> >> 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
> >>
> >>
> >> 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
> >
> >
> > 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
>
>
>
>
>
>
>
>

-- 
Regards,
Joe Astorino CCIE #24347 (R&S)
Sr. Technical Instructor - IPexpert
Mailto: jastorino_at_ipexpert.com
Telephone: +1.810.326.1444
Live Assistance, Please visit: www.ipexpert.com/chat
eFax: +1.810.454.0130
IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA (R&S,
Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice, Security & Service
Provider) Certification Training with locations throughout the United
States, Europe and Australia. Be sure to check out our online communities at
www.ipexpert.com/communities and our public website at www.ipexpert.com
Blogs and organic groups at http://www.ccie.net