OSPF NSSA router is receiving summary routes when no-summaries has been configured on ASBR

[chrisp]

Hi,

I’m using the following OSPF configuration on a MX240. I expected that neighbours in area 10 would only receive a default route, however they are getting all the summary routes too. I assume it has something to do with the OSPF export policy I’m using but not sure why. Could anyone advise what the problem is and how it can be resolved.

Thanks in advance,
Chris

[edit logical-systems N4-TRANSIT protocols ospf]
cp@DRY-MX240-02# show
}
export OSPF-EXPORT;
reference-bandwidth 10g;
area 0.0.0.0 {
    interface xe-1/2/0.2 {
        bfd-liveness-detection {
            minimum-interval 500;
            multiplier 3;
        }
    }
    interface xe-1/3/0.2 {
        bfd-liveness-detection {
            minimum-interval 500;
            multiplier 3;
        }
    }
    interface ge-1/1/7.2 {
        bfd-liveness-detection {
            minimum-interval 500;
            multiplier 3;
        }
    }
    interface all {
        passive;
    }
}
area 10.0.0.0 {
    nssa {
        default-lsa {
            default-metric 10;
            metric-type 1;
            type-7;
        }
        no-summaries;
    }
    interface ge-1/0/8.0 {
        metric 100;
        bfd-liveness-detection {
            minimum-interval 500;
            multiplier 3;

[edit logical-systems N4-TRANSIT policy-options policy-statement OSPF-EXPORT]
cp@DRY-MX240-02# show
term default-route {
    from {
        protocol static;
        route-filter 0.0.0.0/0 exact;
    }
    then {
        metric 1;
        external {
            type 1;
        }
        accept;
    }
}
term static-routes {
    from protocol static;
    then {
        metric 25;
        external {
            type 2;
        }
        accept;
    }
}
term ospf-routes {
    from protocol ospf;
    then accept;
}
term everything-else {
    then reject;
}

Router within NSSA.....

cp@DC2-H1-FE-SW-02> show route

inet.0: 43 destinations, 43 routes (43 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[OSPF/150] 10:57:24, metric 110, tag 0
                    > to 99.166.164.53 via ge-0/0/0.0
89.170.40.176/32   *[OSPF/150] 10:57:14, metric 25, tag 0
                    > to 99.166.164.53 via ge-0/0/0.0
99.166.164.52/30   *[Direct/0] 11:02:49
                    > via ge-0/0/0.0
99.166.164.54/32   *[Local/0] 12:05:51
                      Local via ge-0/0/0.0
99.166.164.58/32   *[Direct/0] 12:05:59
                    > via lo0.0
99.166.164.62/32   *[Local/0] 12:05:53
                      Reject
99.166.165.112/28  *[OSPF/150] 10:57:00, metric 25, tag 0
                    > to 99.166.164.53 via ge-0/0/0.0
99.166.165.160/29  *[OSPF/150] 10:57:00, metric 25, tag 0
                    > to 99.166.164.53 via ge-0/0/0.0
99.166.165.168/29  *[OSPF/150] 10:57:00, metric 25, tag 0
                    > to 99.166.164.53 via ge-0/0/0.0
99.166.168.112/29  *[OSPF/150] 10:57:00, metric 25, tag 0
                    > to 99.166.164.53 via ge-0/0/0.0
99.166.168.192/27  *[OSPF/150] 10:56:50, metric 25, tag 0
<snip>

cp@DC2-H1-FE-SW-02> show ospf database

    OSPF database, Area 10.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   99.166.164.2     99.166.164.2     0x8000001c   674  0x20 0x6c3   36
Router  *99.166.164.58    99.166.164.58    0x80000022   210  0x20 0x81d1  36
Network *99.166.164.54    99.166.164.58    0x80000013  1735  0x20 0xb352  32
NSSA     0.0.0.0          99.166.164.2     0x8000001e   491  0x20 0xf971  36
NSSA     79.170.40.176    99.166.164.2     0x80000015   418  0x20 0x7e93  36
NSSA    *99.166.164.58    99.166.164.58    0x80000016   956  0x28 0xb25c  36
NSSA     99.166.165.112   99.166.164.2     0x8000000f   345  0x20 0x4a9f  36
NSSA     99.166.165.160   99.166.164.2     0x8000000f   271  0x20 0x9819  36
NSSA     99.166.165.168   99.166.164.2     0x8000000f   198  0x20 0x4861  36
NSSA     99.166.168.112   99.166.164.2     0x8000000f   125  0x20 0x5985  36
NSSA     99.166.168.192   99.166.164.2     0x8000000e  1113  0x20 0xa7ff  36
NSSA     99.166.172.8     99.166.164.2     0x8000000f    52  0x20 0x4102  36
NSSA     99.166.172.16    99.166.164.2     0x8000000e  2942  0x20 0xb2d   36
NSSA     99.166.172.32    99.166.164.2     0x8000000e  2869  0x20 0xc182  36
NSSA     99.166.172.64    99.166.164.2     0x8000000e  2796  0x20 0x80a3  36
NSSA     99.166.176.0     99.166.164.2     0x8000000e  2723  0x20 0x91af  36
NSSA     99.166.180.0     99.166.164.2     0x8000000e  2649  0x20 0x56e9  36
NSSA     99.166.180.255   99.166.164.2     0x8000000e  2576  0x20 0x65d7  36
NSSA     99.166.181.0     99.166.164.2     0x8000000e  2503  0x20 0x5ae1  36
NSSA     99.166.182.0     99.166.164.2     0x8000000e  2430  0x20 0x4feb  36
<snip>

[aarseniev]

"no-summaries" means no LSA3 are sent into this area by ABR.

I don't see LSA3 in "show ospf database" from DC2-H1-FE-SW2.

Or do I misinterpret your requirement?

[davidjdv]

According to the output of 'show ospf database', we are not seeing summaries in the NSSA as expected.

I assume you're referring to the "NSSA" LSAs which are Type-7 LSAs created for each external route. These come from the fact that your router is configured as an ABR (between areas 0 and 10) and ASBR (injecting external routes as type 5 into area 0 and type 7 into area 10).

As for you OSPF export policy:

- you don't need to match on the default-route: this is done via the default-lsa command

- you don't need to match on OSPF routes: this is also handled by the OSPF protocol (and the default import/export policy rules)

Regards,

/david 

[chrisp]

Hi,

thanks for your reply. OK I should have looked at this more before making this posting. You are correct there are no type-3 LSA's.

Those that are shown are the statics that have been redistributed by the export policy - how can I provent these from going in to area 10 so that area 10 just has a default route?

Thanks agin,

Chris

[davidjdv]

Hi Chris,

You can achieve this with the 'no-nssa-abr' command under the [ospf] stanza:

 http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/disabling-nssa-support-on-an...

Regards,

/david 

Message Edited by davidjdv on 10-07-2009 02:47 PM

[chrisp]

OK thanks for your response. I will look at configuring no-nssa-abr.

Regards,

Chris

[netccie2246]

Just a question to clear up my own understanding

Based on this statement  "Note: Type 7 LSAs are not exported into an NSSA if there is only one NSSA and backbone area connected to the ABR." (per that link provided)

and since it seems the above configuration has area 10 NSSA and area backbone "0"

I would therefore not have expected to see the type 7 LSA's in the first place.

Message Edited by netccie2246 on 10-14-2009 05:41 AM

[aarseniev]

The OP admitted this:

---

chrisp wrote on 07-10-2009 01:30 PM

Those that are shown are the statics that have been redistributed by the export policy

---

To me that's perfectly fine that Area 10 has Type-7 LSA.

Cheers

Alex

[davidjdv]

To be honest, this line in the documentation does not really make sense to me...

I may be missing something but I do not see what the difference would be for being an ABR for more then 2 NSSA areas as opposed to a single one and why that should influence the injection of type 7 LSAs into the area.

The only argument I see is that which has to do with the backbone area: If we lose the connection to the backbone area, we typically stop advertising the default-route. In this case, it might still be interesting to advertise the type 7 LSAs. 

Regards,

/david