ip ospf database-filter out

I really cant see the point of implementing this command on an interface, you will maintain an adjacency but wont transmit an routing data. The passive-interface does the same job but brings down the adjacency on the port.
So the explanation for the command is that it will avoid flooding lsa's over a redundant serial interface.This will also lose your redundancy, i wouldn't mind if it was a little dynamic as in if the primary serial fails this filtered interface starts forwarding lsa's but this isn't the case.
Can anyone give me a scenario where this command could be useful?

Find more posts tagged with

Comments

Webmaster

EdTheLad wrote:

I really cant see the point of implementing this command on an interface, you will maintain an adjacency but wont transmit any routing data.

Not transmit, but it can still receive the LSAs from neighbor, which is the main outcome difference with the passive int (no adjacency, so obviously no LSAs either way). So even they become each other neighbors the LS advertising is one way. Though not per se relevant to the redundant link, it would allow you to have routerA learn routerB links (hence routes) but not vice versa. I guess in case of the redundant link you could prevent the second link to be advertised (and become available as a route) in only a particular part of the network.

DW [banned]

Thanks

EdTheLad

Webmaster wrote:

Not transmit, but it can still receive the LSAs from neighbor, which is the main outcome difference with the passive int (no adjacency, so obviously no LSAs either way). So even they become each other neighbors the LS advertising is one way. Though not per se relevant to the redundant link, it would allow you to have routerA learn routerB links (hence routes) but not vice versa.

Yes, but still doesn't quite work for me, if i didn't want to send routes to a neighbor, but just wanted to receive them on RA i would only enable ospf on the serial interface without advertising any networks.

Webmaster wrote:

I guess in case of the redundant link you could prevent the second link to be advertised (and become available as a route) in only a particular part of the network.

It will allow redundancy in one direction also load sharing in one direction, i was thinking maybe a multicast application could use this but then reverse path forwarding wouldn't work.I still cant see a need for this implementation, why would you want to use a redundant link in only one direction?

EdTheLad

DarbyWeaver wrote:

Generally speaking we do not use passive interfaces so much in OSPF as we do in RIP and EIGRP.

As for using the command it is used as a filter and that is its purpose.

Typically even with an ACL one still has the OSPF Database to contend with. This command is the equalizer.

I know my "basic" understanding of the matter is probably not technical enough, but the RFC explains it better.

I'll have to check out the rfc, i wouldn't mind if you could use a route-map to filter specific routes with this command its just all or nothing bugs me.

Webmaster

EdTheLad wrote:

Yes, but still doesn't quite work for me, if i didn't want to send routes to a neighbor, but just wanted to receive them on RA i would only enable ospf on the serial interface without advertising any networks.

I'm sure there are several different ways on Cisco OSPF routers to get the same results, but this seems to be the one included in OSPF (regardless of who's implementation). It doesn't seem like this is a frequently used command though.

EdTheLad wrote:

It will allow redundancy in one direction also load sharing in one direction, i was thinking maybe a multicast application could use this but then reverse path forwarding wouldn't work.I still cant see a need for this implementation, why would you want to use a redundant link in only one direction?

Nevermind that part of my reply, I'm configuring a different interface... If you'd configure it on one end of a point to point serial it would prevent the other LSA on that router from going over that link - the link itself is directly attached network and would still be used in both directions, and since the routers on both end will still include include the second link in its own LSAs, it won't make a difference besides the reduced update traffic on that redundant link.

How about using it to allow the neighbor db to be build and still react to missing Hellos? So don't send out updates on this side of the link but still have both sides react to a missing hello (considering it will still now of the second link through LSAs on the main link, it will also want to know it's still alive, but directly, not through the main link).

EdTheLad

Webmaster wrote:

If you'd configure it on one end of a point to point serial it would prevent the other LSA on that router from going over that link - the link itself is directly attached network and would still be used in both directions, and since the routers on both end will still include include the second link in its own LSAs, it won't make a difference besides the reduced update traffic on that redundant link.

So imagine you have,
(RA)s0/0

(RB)s0/0

(RC)s0/1
(RA)s0/1

(RB)s0/1

(RC)s0/1

I enable "ip ospf database-filter" on RA s0/1, Every router a,b,c has its lo0 int 1.1.1.1,2.2.2.2,3.3.3.3 respectively i.e
RA will send LSAs to RB, RB will see it receives via s0/0 so it routes all traffic to 1.1.1.1 via s0/0 never using s0/1, RA will receive route 2.2.2.2 via s0/0,s0/1 so it will load balance.So RB benefits from less updates so more processor available on the router at the expense of the redundancy in one direction.If (RA)s0/0 fails R(B) doesn't receive the 1.1.1.1 route.
Most data applications are symmetrical so why have twice the bandwidth available in one direction and not the other?

Webmaster wrote:

How about using it to allow the neighbor db to be build and still react to missing Hellos? So don't send out updates on this side of the link but still have both sides react to a missing hello (considering it will still now of the second link through LSAs on the main link, it will also want to know it's still alive, but directly, not through the main link).

If the line between (RA)S0/1 and (RB)s0/1 fails,i,.e. no hellos, RA will update its database and delete any routes learned via s0/1 , RB is unaffected route wise as it didn't have any routes learned via its s0/1 interface.

EdTheLad

Ok, i suppose if you had an area consisting of multiple hub type routers making a core each with lots of spoke routers, you could filter the las's to the spokes while still maintaining a route consistency in the core, the spoke routers could have default routes point to the hub routes,kind of like stub eigrp.Thanks Webmaster for helping me rack my brain!

Webmaster

EdTheLad wrote:

Ok, i suppose if you had an area consisting of multiple hub type routers making a core each with lots of spoke routers, you could filter the las's to the spokes while still maintaining a route consistency in the core, the spoke routers could have default routes point to the hub routes,kind of like stub eigrp.Thanks Webmaster for helping me rack my brain!

Glad I could be of some help