Cisco Support Community
Community Member


Can someone  answer this question


We have a Firewall that runs OSPF on multple interfaces.

One of the interfaces is connected to a 6500 switch which also runs OSPF.

The Firewall Distrubutes routes to the 6500 switch which is corrrect,.

But I dont want the Firewall to receive routes from the 6500 side and distribute them anywhere.


I know I can put an outbound distribute filter on the 6500's FW interface.


If I made the 6500 interface to the FW an OSPF-Passive interface, we would lose neighbor relationships,

but would that prevent routes from going out to the FW and still allow the routes in?  which is what I want.


or will passive-inteface also prevent incoming routes.

Hall of Fame Super Gold

If you make the interface on

If you make the interface on the 6500 passive then it will not form a neighbor relationship with the firewall and will not advertise any routes to the firewall and will not learn any routes from the firewall.


It seems odd that you want the firewall to learn OSPF routes from the 6500 but not to advertise them to other neighbors. And that is contrary to usual OSPF operation. I do have one alternative to suggest. I have not done this on a firewall but it would work on a router and I am guessing that it might work on the firewall as well. You might consider configuring a separate OSPF process to run on the interface connecting to the 6500. You could redistribute from the other OSPF into the OSPF connecting to the 6500 and not redistribute the 6500 routes into the other OSPF.





Hello, I have come across

Hello, I have come across this scenario before and as Rick points out, the way we can achieve this is to create OSPF processes to handle the segregation. Specifically we did this on the ASA.

With regards to the selection of which routes to advertise, the reason why we would do this, would be to stop a device e.g. your Internet edge router learning all internal networks for security reasons. Then a layer of FW or protection will mitigate risks which would then sit behind the Internet edge.

Depending on how you advertise your routes you could make use of an NSSA. I used both separate processes and NSSA's in x2 DC environment whereby using NSSA stopped/filtered the OSPF default route (O E2) being advertised from the other DC's to external zones (and subsequently all E2 routes), while the default route in OSPF was lost in the local DC - therefor stopping internet/DMZ "dirty" traffic traversing the internal networks across to the other DC.

You could also use the area filters if applicable. The distribute-list command works in certain scenario's as well.

Redistribution of processes might be good, you can control what is being redistributed and not...

As stated, passive interface just stops the hello's being sent out the interface, however still advertised in OSPF. If the FW supports inbound filtering of something like TAGs then this could work too.



Please rate useful posts & remember to mark any solved questions as answered. Thank you.
VIP Purple

HelloYou may try prefix


You may try prefix-suppression either of these ways which WILL keep the adjecencies but NOT advertise the routes


router ospf x
( suppress all routes apart from secondaries and passive interfaces))


int x/x
ip ospf prefix-suppression
( interface version takes precedence over the router process command)





Please don't forget to rate any posts that have been helpful. Thanks.
Community Member

Thanks - I guess it's only

Thanks - I guess it's only RIP that still allows incoming routes when one side is set to passive.

Those prefix-suppression commands don't appear in our 6500  as an option.

I dont think we can change the areas or add processes at this point.

After reading this - I see that we can't use a distribute list out to prevent outgoing route updates.




A. The distribute-list commands are supported in OSPF but work differently than distance-vector routing protocols such as Routing Information Protocol (RIP) and Enhanced Interior Gateway Routing Protocol (EIGRP). OSPF routes cannot be filtered from entering the OSPF database. The distribute-list in command only filters routes from entering the routing table; it does not prevent link-state packets from being propagated. Therefore, this command does not help conserve router memory, and it does not prohibit a router from propagating filtered routes to other routers.

caution Caution: Use of the distribute-list in command in OSPF may lead to routing loops in the network if not implemented carefully.

The command distribute-list out works only on the routes being redistributed by the Autonomous System Boundary Routers (ASBRs) into OSPF. It can be applied to external type 2 and external type 1 routes, but not to intra-area and interarea routes.


Community Member

I guess I should provide more

I guess I should provide more information.  The OSPF network that the 6500 is on is on the external side of the Firewall.  The Firewall has a default route out to the 6500.  We want the Firewall to advertise our internal networks to the outside segment.  But since the FW has its default route going out, and all the internal routers have their default routes going out through the same path, we don't want the outside networks to be advertised in.


Does anyone know if this will work  - will it stop ALL LSA's from going out the interface it's applied to and still allow for receiving incoming LSA's from the FW.?


Filter OSPF per Interface

If you wish to prevent LSAs to be sent via particular Interface:

(config-if)#ip ospf database-filter all out

*ALL and OUT are the only options, which means you cannot apply a specific filter on the OSPF interface

What else is your 6500

What else is your 6500 talking OSPF with? or is it just the FW? and just out of interest, which FW is it, and what are the filtering capabilities with that?

Please rate useful posts & remember to mark any solved questions as answered. Thank you.
Community Member

The 6500 is a core switch

The 6500 is a core switch which runs  ospf with several other core switches on the external side.  It's a Palo Alto - they may be able to filter that off on the FW. I was thinking we could prevent the traffic from hitting it.

CreatePlease to create content