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.
right.
> 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
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
The faster I go, the behinder I get.
-- Lewis Carroll
> 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.
right.
> 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
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
The faster I go, the behinder I get.
-- Lewis Carroll