Mailing List Archive

--On Monday, August 4, 2003 9:09 pm +0200 "\"Anders K. Pedersen\" <"
<mailnews+router-quagga-dev@news.cohaesio.com> wrote:

> I recently used the ospf passive-interface in a setup like the following:
>
> zebra.conf:
> interface eth0
> ip address 192.168.0.2/24
> ip address 192.168.0.1/24 secondary
>
> ospfd.conf:
> router ospf
> ospf router-id 192.168.0.2
> passive-interface eth0 192.168.0.1
> network 192.168.0.0/24 area 0

Hmm, I think this is going in the wrong direction. OSPF can either send
HELLOs on an interface or not. It should bear no relation to the addresses
on that interface.

Rick

Rick Payne wrote:
> --On Monday, August 4, 2003 9:09 pm +0200 "\"Anders K. Pedersen\" <"
> <mailnews+router-quagga-dev@news.cohaesio.com> wrote:
>
>> I recently used the ospf passive-interface in a setup like the following:
>>
>> zebra.conf:
>> interface eth0
>> ip address 192.168.0.2/24
>> ip address 192.168.0.1/24 secondary
>>
>> ospfd.conf:
>> router ospf
>> ospf router-id 192.168.0.2
>> passive-interface eth0 192.168.0.1
>> network 192.168.0.0/24 area 0
>
> Hmm, I think this is going in the wrong direction. OSPF can either send
> HELLOs on an interface or not. It should bear no relation to the
> addresses on that interface.

But it does - when an HELLOs are sent out, they have a source IP
address, and I want to force ospfd to use a specific address - this
configuration does the trick.

Similarly when ospfd receives a HELLO, it assigns it to one of the IPs
on the receiving interface (it will choose an IP that is on the same IP
net as the source of the HELLO), and if the chosen IP isn't active, the
HELLO will be ignored. My patch makes sure, that if an active IP is
available, this will be preferred to a non-active.

Regards,
Anders K. Pedersen

--
The From: and Reply-To: addresses are internal news2mail gateway addresses.
Reply to the list or to "Anders K. Pedersen" <akp@cohaesio.com>

--On Monday, August 4, 2003 9:52 pm +0200 "\"Anders K. Pedersen\" <"
<mailnews+router-quagga-dev@news.cohaesio.com> wrote:

> But it does - when an HELLOs are sent out, they have a source IP address,
> and I want to force ospfd to use a specific address - this configuration
> does the trick.

Then the bug is in selecting which address to use - it should be using the
primary one. I'd suggest that fixing this, rather than adding additional
commands to the CLI would be preferable.

Rick

Rick Payne wrote:
>
> --On Monday, August 4, 2003 9:52 pm +0200 "\"Anders K. Pedersen\" <"
> <mailnews+router-quagga-dev@news.cohaesio.com> wrote:
>
>> But it does - when an HELLOs are sent out, they have a source IP address,
>> and I want to force ospfd to use a specific address - this configuration
>> does the trick.
>
>
> Then the bug is in selecting which address to use - it should be using
> the primary one. I'd suggest that fixing this, rather than adding
> additional commands to the CLI would be preferable.

Well, my patch doesn't add any new CLI commands - it fixes the format of
one of them (ospf "passive-interface"), so that it's written out in a
way, that ospfd will accept again as input. And it makes ospfd prefer
active interface IPs over interface IPs designated as passive, when
receiving updates/HELLOs on that interface.

Regards,
Anders K. Pedersen

--
The From: and Reply-To: addresses are internal news2mail gateway addresses.
Reply to the list or to "Anders K. Pedersen" <akp@cohaesio.com>

Rick Payne wrote:
> Then the bug is in selecting which address to use - it should be
> using the primary one. I'd suggest that fixing this, rather than
> adding additional commands to the CLI would be preferable.

There can be many primary ip addresses in most of Unixes AFAIK.


--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator

On Mon, 4 Aug 2003, Rick Payne wrote:

> Then the bug is in selecting which address to use - it should be
> using the primary one. I'd suggest that fixing this, rather than
> adding additional commands to the CLI would be preferable.

OSPF 'interfaces' are subnet based though, not physical interface
based. Hence reason for the netmask in the HELLO.

Being able to disable sending of Hello's only on basis of the entire
physical interface when the actual granularity in the protocol is
'subnets attached to an interface' means the patch does have merit,
no?

the other way around it is to give each subnet on an interface its
own interface label, ie linux 2.2 style address aliasing. but thats a
horrible kludge (and the alias-by-label's stuff has plenty of its own
problems).

> Rick

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
"...[Linux's] capacity to talk via any medium except smoke signals."
(By Dr. Greg Wettstein, Roger Maris Cancer Center)

On Tue, 5 Aug 2003, Hasso Tepper wrote:

> Rick Payne wrote:
> > Then the bug is in selecting which address to use - it should be
> > using the primary one. I'd suggest that fixing this, rather than
> > adding additional commands to the CLI would be preferable.
>
> There can be many primary ip addresses in most of Unixes AFAIK.

Perhaps according to the outout if ifconfig there can be but, the first IP
address configured on the interface is the "primary" address and will be
the address that traffic ORIGINATED from that interface will bear.

--
John Fraizer | High-Security Datacenter Services |
President | Dedicated circuits 64k - 155M OC3 |
EnterZone, Inc | Virtual, Dedicated, Colocation |
http://www.enterzone.net/ | Network Consulting Services |

--On Tuesday, August 5, 2003 1:10 am +0100 Paul Jakma <paul@clubi.ie> wrote:

> OSPF 'interfaces' are subnet based though, not physical interface
> based. Hence reason for the netmask in the HELLO.

Well, not really. OSPF is a link state protocol - it cares about links,
rather than subnets. I think the netmask is needed to prevent blackholing
on ethernet, where the adjacency mesh isn't a full mesh.

> Being able to disable sending of Hello's only on basis of the entire
> physical interface when the actual granularity in the protocol is
> 'subnets attached to an interface' means the patch does have merit,
> no?

I don't think the granularity is 'subnets'. Take a cisco and configure it
with an ip block, and a secondary block - and the cisco will only send
HELLO's from the primary block.

Why do we need to do this differently?

Rick

On Mon, 4 Aug 2003, John Fraizer wrote:

> Perhaps according to the outout if ifconfig there can be but, the
> first IP address configured on the interface is the "primary"
> address and will be the address that traffic ORIGINATED from that
> interface will bear.

not on linux. linux has no concept of a 'primary address', device and
IP selection is done via routes and the 'src' flag on addresses on an
interface.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Love means nothing to a tennis player.

On Tue, 5 Aug 2003, Rick Payne wrote:

> Well, not really. OSPF is a link state protocol - it cares about
> links, rather than subnets.

but those 'links' are subnet orientated.

OSPF packets/adjacencies on different subnets on the same link should
in theory have no impact on each other. And state for them is
completely distinct. (You need to run the whole protocol from Hello
onward for each subnet).

> I think the netmask is needed to prevent blackholing on ethernet,
> where the adjacency mesh isn't a full mesh.

blackholing?

AFAICT, at least by ospfd code, one of the major purposes for the
netmask is to allow receiving routers to match the src/netmask of a
multicast packet to an appropriate ospf_interface.

> I don't think the granularity is 'subnets'. Take a cisco and
> configure it with an ip block, and a secondary block - and the
> cisco will only send HELLO's from the primary block.
>
> Why do we need to do this differently?

Because linux at least does not have concept of a primary address.

And it might be nice to be able to say 'passive-interface on this
subnet' while still allowing OSPF on another subnet.

The other options are: avoid logical subnets - use seperate segments
or VLANs for subnets instead. i think this is the best advice, but
never the less - fact remains you can have OSPF active on distinct
subnets, and it might be nice to have subnet granularity for
passive-interface.

?

> Rick

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
I saw a subliminal advertising executive, but only for a second.
-- Steven Wright

>
> I don't think the granularity is 'subnets'. Take a cisco and configure
> it with an ip block, and a secondary block - and the cisco will only
> send HELLO's from the primary block.
>
> Why do we need to do this differently?

Actually ability to send hello's from both subnets is quite
convinient. We often add secondary subnet to an interface when the
first one runs out.

--
Best Regards,
Vladimir Ivaschenko
Thunderworx - Senior Systems Engineer (RHCE)

>>There can be many primary ip addresses in most of Unixes AFAIK.
>
>
> Perhaps according to the outout if ifconfig there can be but, the first IP
> address configured on the interface is the "primary" address and will be
> the address that traffic ORIGINATED from that interface will bear.

AFAIK in case of Linux the IP address will be selected depending on
the route.

--
Best Regards,
Vladimir Ivaschenko
Thunderworx - Senior Systems Engineer (RHCE)

--On Tuesday, August 5, 2003 9:46 am +0100 Paul Jakma <paul@clubi.ie> wrote:

> OSPF packets/adjacencies on different subnets on the same link should
> in theory have no impact on each other. And state for them is
> completely distinct. (You need to run the whole protocol from Hello
> onward for each subnet).

Yes, I agree - that's possible.

>> I think the netmask is needed to prevent blackholing on ethernet,
>> where the adjacency mesh isn't a full mesh.
>
> blackholing?

Well, if you didn't check it, there'd be the possibility on NBMA and
broadcast networks that routers could reach the DR, but not each other.

> Because linux at least does not have concept of a primary address.

The OSPF config shown did have though. Linux also has the flag
IFA_F_SECONDARY that's sent in the netlink messages (though I've not looked
how this gets set - but the flags in the 'ip addr' command contains a
secondary designator too).

> And it might be nice to be able to say 'passive-interface on this
> subnet' while still allowing OSPF on another subnet.

I'd want a stronger reason than 'might be nice' - but then I guess the
advantage of open source is that we don't have to support the resulting
network messes that occur from giving someone free reign in the candy store.

Its somewhat amusing that OSPF goes to great lengths to reduce the flooding
costs on broadcast networks and folks want to undo this - when the routers
are on the same bit of string :)

Rick

On Tue, 5 Aug 2003, Rick Payne wrote:

> --On Tuesday, August 5, 2003 9:46 am +0100 Paul Jakma <paul@clubi.ie> wrote:
>
> > completely distinct. (You need to run the whole protocol from Hello
> > onward for each subnet).
>
> Yes, I agree - that's possible.

More than possible - thats the way it works :)

> Well, if you didn't check it, there'd be the possibility on NBMA
> and broadcast networks that routers could reach the DR, but not
> each other.

Ah..

> The OSPF config shown did have though. Linux also has the flag
> IFA_F_SECONDARY that's sent in the netlink messages (though I've
> not looked how this gets set - but the flags in the 'ip addr'
> command contains a secondary designator too).

Gilad clued me up on this before. Linux sets the secondary flag
automatically if and only if an address added to an interface is
already on the same subnet as an existing address on that interface.

(note, addresses which are /included/ by an existing address do /not/
get the secondary flag - differnet subnet)

> I'd want a stronger reason than 'might be nice' - but then I guess
> the advantage of open source is that we don't have to support the
> resulting network messes that occur from giving someone free reign
> in the candy store.

:)

Why: Because OSPF is {link,subnet} orientated, not link orientated.
(thats a historical cisco limitation presumably).

> Its somewhat amusing that OSPF goes to great lengths to reduce the
> flooding costs on broadcast networks and folks want to undo this -
> when the routers are on the same bit of string :)

Indeed, but OSPF routers on different subnets on broadcast networks
will ignore each others Hello's by design. So, those great lengths
only extend as far as 'same subnet' anyway.

Passive interface should have same granularity i think.

> Rick

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Many people are unenthusiastic about your work.

Rick Payne wrote:
> Its somewhat amusing that OSPF goes to great lengths to reduce the
> flooding costs on broadcast networks and folks want to undo this - when
> the routers are on the same bit of string :)

I'd like to note, that the example configuration I used in my original
mail, didn't have to different subnets on the same interface, but two
IPs from the same subnet on one interface.

One of these IPs is also active on another router (together with a third
IP on the same subnet). The point is that the shared IP is used as
default gateway on non-OSPF capable equipment, while the other IP of
each router is used for OSPF and other access to the specific router.

My problem was, that even though the shared IP was marked as secondary
on both routers, ospfd chose this IP when receiving OSPF updates on the
interface, and it sent out HELLOs from both IPs (but with the same
router-id). I then marked this IP with passive-interface in the ospfd
configuration, which made ospfd only send out HELLOs from the private
IP, but ospfd still chose the shared IP for everything received and thus
ignored it.

I realize, that this part of ospfd has changed since I made my original
patch, which looked like (i'm not including the vty_out part, as this
hasn't changed):

--- zebra-0.93b.orig/ospfd/ospf_interface.c Thu Jul 4 07:06:40 2002
+++ zebra-0.93b/ospfd/ospf_interface.c Mon May 12 04:55:19 2003
@@ -403,7 +403,8 @@
else
{
if (prefix_match (oi->address, (struct prefix *) &addr))
- match = oi;
+ if ((OSPF_IF_PARAM (oi, passive_interface) ==
OSPF_IF_ACTIVE) || (!match))
+ match = oi;
}
}

whereas the patch for the current zebra-pj is:

--- zebra-pj/ospfd/ospf_interface.c.orig 2003-08-04
19:46:31.000000000 +0200
+++ zebra-pj/ospfd/ospf_interface.c 2003-08-04 19:46:31.000000000 +0200
@@ -427,7 +427,18 @@
if (prefix_match (oi->address, (struct prefix *) &addr))
{
if ( (match == NULL) ||
- (match->address->prefixlen < oi->address->prefixlen)
+ ( (OSPF_IF_PARAM (match, passive_interface)
+ == OSPF_IF_PASSIVE) &&
+ (OSPF_IF_PARAM (oi, passive_interface)
+ == OSPF_IF_ACTIVE)
+ ) ||
+ ( (match->address->prefixlen < oi->address->prefixlen) &&
+ ( (OSPF_IF_PARAM (match, passive_interface)
+ == OSPF_IF_PASSIVE) ||
+ (OSPF_IF_PARAM (oi, passive_interface)
+ == OSPF_IF_ACTIVE)
+ )
+ )
)
match = oi;
}

As I read it, the original code in zebra 0.93b would choose the last IP,
that matched the prefix (which in my case was the secondary shared IP),
whereas the current zebra-pj chooses the first IP, that matches the
prefix (due to the 'match == NULL' condition - I'm ignoring prefixlen
condition as both IPs in my case have the same netmask).

I guess, that I won't actually need this part of the patch, as zebra-pj
now chooses the first matching IP, but I still think that it makes sense
to be able to specify, which IP ospfd should use - it already works,
when sending out HELLOs, and my patch makes it work for receiving HELLOs
as well.

Regards,
Anders K. Pedersen

--
The From: and Reply-To: addresses are internal news2mail gateway addresses.
Reply to the list or to "Anders K. Pedersen" <akp@cohaesio.com>

"Anders K. Pedersen" < wrote:

> My problem was, that even though the shared IP was marked as secondary
> on both routers, ospfd chose this IP when receiving OSPF updates on the
> interface, and it sent out HELLOs from both IPs (but with the same
> router-id). I then marked this IP with passive-interface in the ospfd
> configuration, which made ospfd only send out HELLOs from the private
> IP, but ospfd still chose the shared IP for everything received and thus
> ignored it.

This is slightly off-topic, but -- also referring to my short previous
experience with ospfd interfaces -- this whole issue of abstract,
subnet-oriented interfaces that refine physical interfaces as of ospfd,
is far from being well-defined; the above mentioned problem is just on
of them -- and, IMO, the suggested solutions don't satisfy, as they are
of a "hacky" nature.

Generally speaking (also related to Rick's questions), I found some
major advantages in going the Cisco way, by which an OSPF interface
equals a system (that is, layer-2) interface (I need to dig them from
the back of my brain, though, but I know they're there ;-> ). I agree
one may want to run multiple distinct logical networks over a single
link, however, that person could always turn those networks to being L2
differentiated (e.g. VLAN tags, on an Ethernet), and keep working with
the Cisco paradigm. Otherwise, if we want to retain the current,
(seemingly) more flexible approach, it needs to be well-defined,
especially with regard to outbound/inbound packet processing by ospfd,
interface management (e.g. how do you define a "passive abstract
interface"??), and so on. Right now, it isn't the case.

(Note: I'm just an OSPF amateur, I mostly relate here to topology and
connectivity aspects.)

Gilad

On Mon, 4 Aug 2003, "Anders K. Pedersen" < wrote:

> Hello,
>
> I recently used the ospf passive-interface in a setup like the following:
>
> zebra.conf:
> interface eth0
> ip address 192.168.0.2/24
> ip address 192.168.0.1/24 secondary
>
> ospfd.conf:
> router ospf
> ospf router-id 192.168.0.2
> passive-interface eth0 192.168.0.1
> network 192.168.0.0/24 area 0
>
> And similar on a another router except, that 192.168.0.2 is
> exchanged with 192.168.0.3. Both routers have uplinks to the world,
> and the idea is that non-OSPF aware systems use 192.168.0.1 as
> default gateway, and if one of the routers should fail, the other
> will take over automatically (after ARP timeout).
>
> I had to make a few changes to the OSPF daemon before this worked though:
>
> First of all, when doing a "write memory" in OSPF, it wrote:
>
> router ospf
> ospf router-id 192.168.0.2
> passive-interface 192.168.0.1
> network 192.168.0.0/24 area 0
>
> But this form of "passive-interface" is not accepted as input, so I
> patched it to include the interface name.

hmmm..

> Second of all, when receiving OSPF updates from neighbours on this
> interface, the passive-interface IP was used to receive them, and
> as it was a passive interface, they were ignored.
>
> The patch below makes ospfd prefer an active interface over a passive,
> when receiving updates.

how do you mean?

> I've just updated it to match the current zebra-pj from CVS. I'm
> not sure if it is necessary to handle all the special cases that
> the patch does, but if not, I'm sure that one of you, who knows
> more about this than me can do so, or given a hint, I'll do it
> myself.

> Regards,
> Anders K. Pedersen
>
> --- zebra-pj/ospfd/ospf_interface.c.orig 2003-08-04
> 19:46:31.000000000 +0200
> +++ zebra-pj/ospfd/ospf_interface.c 2003-08-04 19:46:31.000000000 +0200
> @@ -427,7 +427,18 @@
> if (prefix_match (oi->address, (struct prefix *) &addr))
> {
> if ( (match == NULL) ||
> - (match->address->prefixlen < oi->address->prefixlen)
> + ( (OSPF_IF_PARAM (match, passive_interface)
> + == OSPF_IF_PASSIVE) &&
> + (OSPF_IF_PARAM (oi, passive_interface)
> + == OSPF_IF_ACTIVE)
> + ) ||
> + ( (match->address->prefixlen < oi->address->prefixlen) &&
> + ( (OSPF_IF_PARAM (match, passive_interface)
> + == OSPF_IF_PASSIVE) ||
> + (OSPF_IF_PARAM (oi, passive_interface)
> + == OSPF_IF_ACTIVE)
> + )
> + )

You are testing for:

(foo && bar) || ( (foo || bar) && dongle)

Which, i think might be expressed more clearly as:

(foo && bar) || (foo && dongle) || (bar && dongle)

i cant see a way to reduce it unfortunately.. my boolean algebra is
far too rusty. is the above what you intended, ie:

OSPF_IF_PARAM (match, passive_interface)
&& OSPF_IF_PARAM (oi, passive_interface)
||
OSPF_IF_PARAM (match, passive_interface)
&& match->address->prefixlen < oi->address->prefixlen)
||
OSPF_IF_PARAM (oi, passive_interface)
&& match->address->prefixlen < oi->address->prefixlen)

this is probably slightly clearer.

can you explain whats happening here a bit more?

> )
> match = oi;
> }
> --- zebra-pj/ospfd/ospf_vty.c.orig 2003-08-04 19:27:39.000000000 +0200
> +++ zebra-pj/ospfd/ospf_vty.c 2003-08-04 19:27:39.000000000 +0200
> @@ -7326,7 +7326,8 @@
>
>
> if (OSPF_IF_PARAM_CONFIGURED (oi->params, passive_interface) &&
> oi->params->passive_interface == OSPF_IF_PASSIVE)
> - vty_out (vty, " passive-interface %s%s",
> + vty_out (vty, " passive-interface %s %s%s",
> + oi->ifp->name,
> inet_ntoa (oi->address->u.prefix4), VTY_NEWLINE);
> }

this looks fine.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Nothing will dispel enthusiasm like a small admission fee.
-- Kim Hubbard

On Tue, 5 Aug 2003, Gilad Arnold wrote:

> This is slightly off-topic, but -- also referring to my short
> previous experience with ospfd interfaces -- this whole issue of
> abstract, subnet-oriented interfaces that refine physical
> interfaces as of ospfd, is far from being well-defined; the above
> mentioned problem is just on of them -- and, IMO, the suggested
> solutions don't satisfy, as they are of a "hacky" nature.
>
> Generally speaking (also related to Rick's questions), I found some
> major advantages in going the Cisco way, by which an OSPF interface
> equals a system (that is, layer-2) interface (I need to dig them
> from the back of my brain, though, but I know they're there ;-> ).
> I agree one may want to run multiple distinct logical networks over
> a single link, however, that person could always turn those
> networks to being L2 differentiated (e.g. VLAN tags, on an
> Ethernet), and keep working with the Cisco paradigm.

Yes, the cisco way is simpler and has no difficult issues to deal
with.

> Otherwise, if we want to retain the current, (seemingly) more
> flexible approach, it needs to be well-defined, especially with
> regard to outbound/inbound packet processing by ospfd, interface
> management (e.g. how do you define a "passive abstract
> interface"??), and so on. Right now, it isn't the case.
>
> (Note: I'm just an OSPF amateur, I mostly relate here to topology
> and connectivity aspects.)

Ok, well imo, this can be resolved, and should /first/ be resolved,
by determing what the secondary flag should mean in zebra. Eg does it
mean "the kernel set that flag" or should we go further? eg make it
mean:

this address is either

a) in same subnet as existing address on this interface.

or

b) included by an existing interface on this interface.

If the secondary flag was set for such interface addresses by zebra
it would resolve a few issues, for ospfd at least. (the latter
situation currently makes ospfd behave strangly).

?

> Gilad

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Old soldiers never die. Young ones do.

Paul Jakma wrote:

> You are testing for:
>
> (foo && bar) || ( (foo || bar) && dongle)
>
> Which, i think might be expressed more clearly as:
>
> (foo && bar) || (foo && dongle) || (bar && dongle)
>
> i cant see a way to reduce it unfortunately.. my boolean algebra is
> far too rusty. is the above what you intended, ie:
>
> OSPF_IF_PARAM (match, passive_interface)
> && OSPF_IF_PARAM (oi, passive_interface)
> ||
> OSPF_IF_PARAM (match, passive_interface)
> && match->address->prefixlen < oi->address->prefixlen)
> ||
> OSPF_IF_PARAM (oi, passive_interface)
> && match->address->prefixlen < oi->address->prefixlen)
>
> this is probably slightly clearer.

I don't think so: the original form verifies a relation between the
"passive" feature of two ospf interfaces, otherwise given their
prefixlen satisfies some condition it suffices to have one of the
features set as required. It's more natural to the ospfd outsider (me,
in this case). If you want a shorter alternative, in terms of expression
evaluation:

if (foo ? bar || dongle : bar && dongle) ...

or (assuming they're either 0 or 1, and you're willing to have this ugly
coding)

if (foo + bar + dongle >= 2) ...

Gilad

Paul Jakma wrote:

>>Otherwise, if we want to retain the current, (seemingly) more
>>flexible approach, it needs to be well-defined, especially with
>>regard to outbound/inbound packet processing by ospfd, interface
>>management (e.g. how do you define a "passive abstract
>>interface"??), and so on. Right now, it isn't the case.
>
> Ok, well imo, this can be resolved, and should /first/ be resolved,
> by determing what the secondary flag should mean in zebra. Eg does it
> mean "the kernel set that flag" or should we go further? eg make it
> mean:
>
> this address is either
>
> a) in same subnet as existing address on this interface.
>
> or
>
> b) included by an existing interface on this interface.
>
> If the secondary flag was set for such interface addresses by zebra
> it would resolve a few issues, for ospfd at least. (the latter
> situation currently makes ospfd behave strangly).

I'm not sure it has directly to do with primary/secondary attributes: in
the Cisco case, as well as *nix case, primary/secondary originally are
meant to specificy which self-address is used as source address for
outgoing packets on some interface, with varying degrees of freedom
involved wrt to each OS's conceptions. In Cisco, IOS uses this
primary/secondary attribute under various other circumstances, e.g.
determining which interfaces become OSPF-active, and about a million
other cases (like cable-modem provisioning in CMTSs, would you
believe?...). This isn't the case with zebra/quagga, of course: since it
hasn't strict control over primary/secondary attribute (this is a
kernel's matter), it cannot take advantage of those attributes for other
purposes. And that, to me, seems as the main problem.

(PS: I still didn't get any answer for my question -- what impact does
the 'secondary' keyword in zebra have on OSs other than Linux? What
primary/secondary paradigms do other OSs use? And consequently, why
would we want to retain the 'secondary' keyword at all?)

> ?

?? ;->

Gilad

On Wed, 6 Aug 2003, Gilad Arnold wrote:

> (PS: I still didn't get any answer for my question -- what impact does
> the 'secondary' keyword in zebra have on OSs other than Linux? What
> primary/secondary paradigms do other OSs use? And consequently, why
> would we want to retain the 'secondary' keyword at all?)
>

How about this. It doesn't hurt anything and if you take it away, it
will break a whole hell of a lot of configs out there. Did
"secondary" have an affair with your girlfriend or something? Why the
boner for the secondary keyword?

--
John Fraizer | High-Security Datacenter Services |
President | Dedicated circuits 64k - 155M OC3 |
EnterZone, Inc | Virtual, Dedicated, Colocation |
http://www.enterzone.net/ | Network Consulting Services |

Paul Jakma wrote:
> On Mon, 4 Aug 2003, "Anders K. Pedersen" < wrote:
>>Second of all, when receiving OSPF updates from neighbours on this
>>interface, the passive-interface IP was used to receive them, and
>>as it was a passive interface, they were ignored.
>>
>>The patch below makes ospfd prefer an active interface over a passive,
>>when receiving updates.
>
>
> how do you mean?

When an OSPF packet arrives, ospf_read (ospf_packet.c) calls
ospf_if_lookup_recv_if (ospf_interface.c), which the patch below
modifies, to find out, which OSPF interface (a specific pair of physical
net interface and IP on that interface) to associate the packet with.
This is necessary, because OSPF packets are sent to a multicast address,
and thus the source IP of the packet has to be compared with the local
interface addresses to determine which one matches the IP net of the
source. The state of this interface is then used to decide how to handle
the packet.

As I mentioned in [quagga-dev 73] ospf_if_lookup_recv_if has changed
between Zebra 0.93b (where I made the patch originally) and Zebra-pj
from current CVS - ospfd now uses the first matching interface whereas
0.93b used the last, which was my passive interface. This change
probably makes my patch unnecessary for my specific setup, as the first
matching IP will be the primary address of the physical interface.

However, I still think that it makes sense to be able to specify, which
IP ospfd should use - it already works, when sending out HELLOs, and my
patch makes it work for receiving HELLOs as well.

>>--- zebra-pj/ospfd/ospf_interface.c.orig 2003-08-04
>>19:46:31.000000000 +0200
>>+++ zebra-pj/ospfd/ospf_interface.c 2003-08-04 19:46:31.000000000 +0200
>>@@ -427,7 +427,18 @@
>> if (prefix_match (oi->address, (struct prefix *) &addr))
>> {
>> if ( (match == NULL) ||
>>- (match->address->prefixlen < oi->address->prefixlen)
>>+ ( (OSPF_IF_PARAM (match, passive_interface)
>>+ == OSPF_IF_PASSIVE) &&
>>+ (OSPF_IF_PARAM (oi, passive_interface)
>>+ == OSPF_IF_ACTIVE)
>>+ ) ||
>>+ ( (match->address->prefixlen < oi->address->prefixlen) &&
>>+ ( (OSPF_IF_PARAM (match, passive_interface)
>>+ == OSPF_IF_PASSIVE) ||
>>+ (OSPF_IF_PARAM (oi, passive_interface)
>>+ == OSPF_IF_ACTIVE)
>>+ )
>>+ )
>
>
> You are testing for:
>
> (foo && bar) || ( (foo || bar) && dongle)
>
> Which, i think might be expressed more clearly as:
>
> (foo && bar) || (foo && dongle) || (bar && dongle)
>
> i cant see a way to reduce it unfortunately.. my boolean algebra is
> far too rusty. is the above what you intended, ie:
>
> OSPF_IF_PARAM (match, passive_interface)
> && OSPF_IF_PARAM (oi, passive_interface)
> ||
> OSPF_IF_PARAM (match, passive_interface)
> && match->address->prefixlen < oi->address->prefixlen)
> ||
> OSPF_IF_PARAM (oi, passive_interface)
> && match->address->prefixlen < oi->address->prefixlen)
>
> this is probably slightly clearer.

Yes, this should do the same as my code; I can't really which is
clearer. Gilad has some comments on this issue though.

However (as I noted in my original mail), I wanted to make sure, that
all eight cases for the three boolean tests where handled properly, but
maybe some of them can be ignored to simplify the code.

The three tests are:
prefixlen: match->address->prefixlen < oi->address->prefixlen
match_passive: OSPF_IF_PARAM (match, passive_interface) ==
OSPF_IF_PASSIVE
oi_passive: OSPF_IF_PARAM (oi, passive_interface) == OSPF_IF_PASSIVE

This gives eigth cases:

prefixlen | match_passive | oi_passive || result
F F F match
F F T match
F T F oi
F T T match
T F F oi
T F T match
T T F oi
T T T oi

Clearly, if only one of the interfaces is active, this interface should
be chosen. This leaves the cases where both interfaces are in the same
state, and the one with the largest prefixlen will be chosen (which is
the only test zebra-pj current does). But does it actually matter which
interface is chosen if both are passive? If not, this could simplify the
code a bit.

Regards,
Anders K. Pedersen

--
The From: and Reply-To: addresses are internal news2mail gateway addresses.
Reply to the list or to "Anders K. Pedersen" <akp@cohaesio.com>

On Wed, 6 Aug 2003, "Anders K. Pedersen" < wrote:

> When an OSPF packet arrives, ospf_read (ospf_packet.c) calls
> ospf_if_lookup_recv_if (ospf_interface.c), which the patch below
> modifies, to find out, which OSPF interface (a specific pair of
> physical net interface and IP on that interface) to associate the
> packet with.

yes, a fun process. I think it was amir who modified it - he was
having problems with interface aliases.

> This is necessary, because OSPF packets are sent to a multicast
> address, and thus the source IP of the packet has to be compared
> with the local interface addresses to determine which one matches
> the IP net of the source. The state of this interface is then used
> to decide how to handle the packet.

ok.

> As I mentioned in [quagga-dev 73] ospf_if_lookup_recv_if has changed
> between Zebra 0.93b (where I made the patch originally) and Zebra-pj
> from current CVS - ospfd now uses the first matching interface whereas
> 0.93b used the last, which was my passive interface.

aha. Sure it uses the first though? It looks to me like it matches
the last still:

<for every ospf_interface)
if (prefix_match (oi->address, (struct prefix *) &addr))
{
if ( (match == NULL) ||
(match->address->prefixlen < oi->address->prefixlen)
)
match = oi;
}

return match;

surely its still last match in zebra-pj^Wquagga?

> This change probably makes my patch unnecessary for my specific
> setup, as the first matching IP will be the primary address of the
> physical interface.

yes. but it can still go wrong though, cant it? ie it still needs
your patch i think. Eg, first matched interface could be passive.

> However, I still think that it makes sense to be able to specify, which
> IP ospfd should use - it already works, when sending out HELLOs, and my
> patch makes it work for receiving HELLOs as well.

yes.

> Yes, this should do the same as my code;

it should yes, its just your code with the prefixlen condition
distributed into the previous ||.

> I can't really which is clearer.

question of taste i guess.

> However (as I noted in my original mail), I wanted to make sure,
> that all eight cases for the three boolean tests where handled
> properly, but maybe some of them can be ignored to simplify the
> code.
>
> The three tests are:
> prefixlen: match->address->prefixlen < oi->address->prefixlen
> match_passive: OSPF_IF_PARAM (match, passive_interface) ==
> OSPF_IF_PASSIVE
> oi_passive: OSPF_IF_PARAM (oi, passive_interface) == OSPF_IF_PASSIVE
>
> This gives eigth cases:
>
> prefixlen | match_passive | oi_passive || result
> F F F match
> F F T match
> F T F oi
> F T T match
> T F F oi
> T F T match
> T T F oi
> T T T oi

ok...

prefixlen = A, match_passive = B, oi_passive = C,
match = 0, oi = 1.

A\BC 00 01 11 10
0 0 0 0 1
1 1 0 1 1

which is:

B(!C) + A(!C) + AB


ie the following should be equivalent to your truth table above:

( (!oi_passive)
&& (prefixlen || match_passive)
)
||
(prefixlen && match_passive)

make sense? its reminiscent of your original patch, but slightly
different. ie code would be:

if ( ((!oi_passive) && (prefixlen || match_passive))
|| (prefixlen && match_passive))
match = oi;

(cue gilad)

(NB: code will really want your table above commented above it to
explain it :) )

Note though that the above will still return the first/last (i think
last surely?) oi to match. Though, if it passes the tests, hey.. its
a suitable oi to use. (see below about impossiblity of knowing which
interface a multicast addressed packet actually was received on).

> Clearly, if only one of the interfaces is active, this interface
> should be chosen. This leaves the cases where both interfaces are
> in the same state, and the one with the largest prefixlen will be
> chosen (which is the only test zebra-pj current does). But does it
> actually matter which interface is chosen if both are passive?

if the prefixes match, it doesnt matter. indeed there is no absolute
way to tell with certainty which interface the packet came in from -
we can only guess really - ospfd opens just one raw socket on
IN_ADDRANY iirc - if it opened a socket per interface it would be
possible to tell with absolute certainty. first match appears to
produce best results afaict.

> If not, this could simplify the code a bit.

what do you think of the example above derived from your table?

> 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 cost of living hasn't affected its popularity.

Paul Jakma wrote:
> On Wed, 6 Aug 2003, "Anders K. Pedersen" < wrote:
>>As I mentioned in [quagga-dev 73] ospf_if_lookup_recv_if has changed
>>between Zebra 0.93b (where I made the patch originally) and Zebra-pj
>>from current CVS - ospfd now uses the first matching interface whereas
>>0.93b used the last, which was my passive interface.
>
>
> aha. Sure it uses the first though? It looks to me like it matches
> the last still:
>
> <for every ospf_interface)
> if (prefix_match (oi->address, (struct prefix *) &addr))
> {
> if ( (match == NULL) ||
> (match->address->prefixlen < oi->address->prefixlen)
> )
> match = oi;
> }
>
> return match;
>
> surely its still last match in zebra-pj^Wquagga?

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.

>>This change probably makes my patch unnecessary for my specific
>>setup, as the first matching IP will be the primary address of the
>>physical interface.
>
> yes. but it can still go wrong though, cant it? ie it still needs
> your patch i think. Eg, first matched interface could be passive.

Indeed.

>>However, I still think that it makes sense to be able to specify, which
>>IP ospfd should use - it already works, when sending out HELLOs, and my
>>patch makes it work for receiving HELLOs as well.
>
> yes.

>>However (as I noted in my original mail), I wanted to make sure,
>>that all eight cases for the three boolean tests where handled
>>properly, but maybe some of them can be ignored to simplify the
>>code.
>>
>>The three tests are:
>>prefixlen: match->address->prefixlen < oi->address->prefixlen
>>match_passive: OSPF_IF_PARAM (match, passive_interface) ==
>> OSPF_IF_PASSIVE
>>oi_passive: OSPF_IF_PARAM (oi, passive_interface) == OSPF_IF_PASSIVE
>>
>>This gives eigth cases:
>>
>>prefixlen | match_passive | oi_passive || result
>> F F F match
>> F F T match
>> F T F oi
>> F T T match
>> T F F oi
>> T F T match
>> T T F oi
>> T T T oi
>
>
> ok...
>
> prefixlen = A, match_passive = B, oi_passive = C,
> match = 0, oi = 1.
>
> A\BC 00 01 11 10
> 0 0 0 0 1
> 1 1 0 1 1
>
> which is:
>
> B(!C) + A(!C) + AB
>
> => (!C)(A+B) + AB
>
> ie the following should be equivalent to your truth table above:
>
> ( (!oi_passive)
> && (prefixlen || match_passive)
> )
> ||
> (prefixlen && match_passive)
>
> make sense? its reminiscent of your original patch, but slightly
> different. ie code would be:
>
> if ( ((!oi_passive) && (prefixlen || match_passive))
> || (prefixlen && match_passive))
> match = oi;
>
> (cue gilad)
>
> (NB: code will really want your table above commented above it to
> explain it :) )

Yes, it's getting rather hairy ;-)

> Note though that the above will still return the first/last (i think
> last surely?) oi to match. Though, if it passes the tests, hey.. its
> a suitable oi to use. (see below about impossiblity of knowing which
> interface a multicast addressed packet actually was received on).
>
>>Clearly, if only one of the interfaces is active, this interface
>>should be chosen. This leaves the cases where both interfaces are
>>in the same state, and the one with the largest prefixlen will be
>>chosen (which is the only test zebra-pj current does). But does it
>>actually matter which interface is chosen if both are passive?
>
> if the prefixes match, it doesnt matter. indeed there is no absolute
> way to tell with certainty which interface the packet came in from -
> we can only guess really - ospfd opens just one raw socket on
> IN_ADDRANY iirc - if it opened a socket per interface it would be
> possible to tell with absolute certainty. first match appears to
> produce best results afaict.
>
>>If not, this could simplify the code a bit.
>
> what do you think of the example above derived from your table?

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

which is: B + A(!C)

which gives:

if ( match_passive || ((!oi_passive) && prefixlen) )
match = oi;

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

Regards,
Anders K. Pedersen

--
The From: and Reply-To: addresses are internal news2mail gateway addresses.
Reply to the list or to "Anders K. Pedersen" <akp@cohaesio.com>