Mailing List Archive

1 2  View All
Re: OSPF passive-interface problem [ In reply to ]
On Thu, 7 Aug 2003, "Anders K. Pedersen" < wrote:

> Well, the example configuration I used had two different IPs on the
> same subnet (i.e. same prefixlen), and as the interface list is
> tested from first to last, the first match is initially assigned to
> "match". When the next interface is tested, it will pass the
> prefix_match test, but "match" isn't NULL anymore and prefixlen is
> the same for both interfaces, these tests fail, and "match" stays
> at the first interface.

aha... ok. But yes, its using the last matching interface which
passes those tests.

> > (cue gilad)
> >
> > (NB: code will really want your table above commented above it to
> > explain it :) )
> Yes, it's getting rather hairy ;-)


> Seems fair enough. What I meant with simplifying it further though,
> was that if both interfaces are passive, it shouldn't really matter
> which one has the largest prefixlen as the packet will be ignored
> by both of them.


> If we assume this is the case, it would give the following tables
> (where * = don't care):
> prefixlen | match_passive | oi_passive || result
> F F F match
> F F T match
> F T F oi
> F T T *
> T F F oi
> T F T match
> T T F oi
> T T T *
> prefixlen = A, match_passive = B, oi_passive = C,
> match = 0, oi = 1.
> A\BC 00 01 11 10
> 0 0 0 * 1
> 1 1 0 * 1

ah, much simpler.

> which is: B + A(!C)
> which gives:
> if ( match_passive || ((!oi_passive) && prefixlen) )
> match = oi;
> It's simpler,

indeed, far nicer.

> but is it acceptable to just pick a more-or-less
> random interface (in this case the last one) if all interfaces are
> passive?

yes, it is. because as i said previously, the attempt to source IP to
appropriate ospf_interface is merely a heuristic anyway - as long as
the heuristic is a good one, thats all we can do.

want to knock up a new version of your patch to reflect your
conditions above, test it and send it on (presuming it works - it
should do i think)?

in the longer term, it might be better to add a socket fd field to
struct ospf_interface and open one socket per oi. then we dont need
the above games trying to figure out which oi to use for a given
received packet - the kernel will already have made that decision for
us. (be an interesting experiment anyway.. wonder whether rest of
ospfd would notice such a change - hopefully not.)

> Regards,
> Anders K. Pedersen

Paul Jakma Key ID: 64A2FF6A
warning: do not ever send email to
The faster I go, the behinder I get.
-- Lewis Carroll

1 2  View All