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

Please note we are still using LSA conversion at ABR, then all the routers
will have the route in the DB, however they will not put them in the main
table due to unknown FA. This could be a work around and could be a lab
scenarion but in real life, I would simply filter it at ABR and why take the
chance of having it even in the DB. I guess petr gave a possibility to do it
technically as Lab is not an exam of best practices, however, real life is
test of knowledge and Best practices as well.

Bye the way you can try "area # nssa trans type-7 supp" at ABR (connecting
to area0) and see its affect.

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
>
> 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/
>
> 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 <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
Received on Fri Nov 13 2009 - 13:30:04 ART