Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Community Member

Area range not-advertise command !

hi all, if we use area range x.x.x.x y.y.y.y not-advertise command on ABR, it will filter type 1 lsa to be originated as type 3 in the attatched non backbone area, what is the reason behind it ? can some one tell me where is it defined in the ospfv2 RFC ?, and also correct me in my assumption that RFC tell us all !! i mean cisco and other vendors follow RFC to implement protocols so every action or result we see from our configuration shouldnt it be defined in the RFC somewhere ?

Kindly guide me

Hall of Fame Super Silver

Re: Area range not-advertise command !

Hello Ovais,

that command is a way to implement a route filter at area boundary.

If you want create an aggregate a summarized route and you want it to be advertised just remove the not-advertise option.

About RFC for OSPFv2 look at RFC2328

List of area address ranges

In order to aggregate routing information at area boundaries,

area address ranges can be employed. Each address range is

specified by an [address,mask] pair and a status indication of

either Advertise or DoNotAdvertise (see Section 12.4.3).

When the

range's status indicates DoNotAdvertise, the Type 3

summary-LSA is suppressed and the component networks

remain hidden from other areas.

So this is a standard behaviour

Hope to help


Hall of Fame Super Gold

Re: Area range not-advertise command !


This is an excellent response from Giuseppe and worth the rating that I give it.

I would like to address this part of your post:

"and also correct me in my assumption that RFC tell us all".

I do not think that it is true that the RFC tells us all. The RFC gives a common basis on which different vendors implement something (like OSPF). The RFC specifies things that the protocol should do and sometimes specifies things that the protocol should not do. The vendor should follow the directives provided in the RFC. But the vendor is not limited to only the things directed in the RFC. Many vendors will implement proprietary extensions to the protocol. So there may very well be parts of your config that are not something defined in the RFC but are provided by the vendor who wants to go above and beyond the specifics of the RFC to make it work better.



CreatePlease to create content