[c-nsp] OSPF LSA Type 3 / 5 question ...

[Randy]

Bryan,
<snip>..
is there a clever way for the ABR to detect that the
Type 5 LSA is within the range it's already summarizing (Type 3) and
suppress its upstream announcement?<snip>

The above would break-the-back of OSPF as we know it.


What you are trying to do cannot be accomplished.
While you can use distribute-list out on ASBR to prevent an external-prefix from entering the LSDB, once it is there, you cannot prevent it from propagating to all other areas.


In this case I don't see any reason to run OSPF between your ABR and downstream. A static route on ABR and the IA summary would work.

./Randy







----- Original Message -----
From: Bryan Holloway <bryan at shout.net>
To: Fabio Mendes <fabio.mendes at bsd.com.br>
Cc: Cisco Network Service Providers <cisco-nsp at puck.nether.net>
Sent: Thursday, February 2, 2017 6:53 PM
Subject: Re: [c-nsp] OSPF LSA Type 3 / 5 question ...

It does make sense ... unfortunately the ABR is running IOS-XR and I 
have been unable to find a way to filter outbound LSAs (unless you want 
to filter everything.)


On 2/2/17 8:45 PM, Fabio Mendes wrote:
> If the ABR outer is receiving the /24 from a downstream router on a
> different area  and that ABR is also generating a /8 IA to the backbone,
> you can just filter out the /24 to other areas via a distribute list.
>
> That way you still have the more specific  /24 on the ABR but the other
> routers on area 0 and other areas only see the /8 coming from that ABR.
>
> The /24 will be naturally hidden behind the /8.
>
> I hope it made sense.
>
>
>
> On Feb 2, 2017 9:33 PM, "Bryan Holloway" <bryan at shout.net
> <mailto:bryan at shout.net>> wrote:
>
>     Fabio,
>
>     Thank you for the response! Yes -- that's exactly what I'm trying to
>     do. However, the problem is this:
>
>     If I use the "summary-address" command, it not only masks it on the
>     rest of the backbone, it masks it on the ABR too. Consequently I
>     have to add a static route to the downstream router for *MailScanner
>     warning: numerical links are often malicious:* 10.100.0.0/24
>     <http://10.100.0.0/24>.
>
>     If I have to add statics on the ABR for every downstream
>     redistributed static, it's almost not worth even running OSPF
>     between the two.
>
>     What I'm looking for is a way for the static to appear on the ABR,
>     but not beyond it. (I.e., mask it everywhere except the ABR.)
>
>     Hope that makes sense ... thanks!
>
>                             - bryan
>
>
>     On 2/2/17 8:20 PM, Fabio Mendes wrote:
>
>         the full command to summarize external LSA is summary-address,
>         it wasn't
>         very clear on my last email
>
>         On Thu, Feb 2, 2017 at 9:16 PM, Fabio Mendes
>         <fabio.mendes at bsd.com.br <mailto:fabio.mendes at bsd.com.br>
>         <mailto:fabio.mendes at bsd.com.br
>         <mailto:fabio.mendes at bsd.com.br>>> wrote:
>
>             If I understood correctly you are generating an IA LSA via
>         the area
>             range command on the ABR and are also receiving a E1/2 LSA
>         for a /24
>             that is part of the IA range and want to mask it behind that
>         same IA
>             LSA.
>
>             One simple way to do it is use the summary command under the
>         ospf
>             process, announcing a *MailScanner warning: numerical links are
>             often malicious:* *MailScanner warning: numerical links are
>         often malicious:* 10.0.0.0/8 <http://10.0.0.0/8> <*MailScanner
>         warning: numerical links are often malicious:* http://10.0.0.0/8
>         <http://10.0.0.0/8>> to the backbone area.
>
>             Now the backbone has an IA for *MailScanner warning:
>         numerical links
>             are often malicious:* *MailScanner warning: numerical links
>         are often malicious:* 10.0.0.0/8 <http://10.0.0.0/8>
>         <*MailScanner warning: numerical links are often malicious:*
>        http://10.0.0.0/8 <http://10.0.0.0/8>> and a E1/2 for
>             the same prefix.
>
>             In that case the IA will be preferred.
>
>             Since the 10.100 subnet is behind the same ABR that's
>         generating the

>             *MailScanner warning: numerical links are often malicious:*
>             *MailScanner warning: numerical links are often malicious:*
>         10.0.0.0/8 <http://10.0.0.0/8> <*MailScanner warning: numerical
>         links are often malicious:* http://10.0.0.0/8
>         <http://10.0.0.0/8>> IA into the backbone, you will not
>             have any connectivity problems by doing that.
>
>
>
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/