Mailing List Archive

> So, what happens when you do 'ping 10.0.0.105'? What source address do
> the packets carry?

it would use the first configured address..

> happens when you remove 10.0.0.102?

what happens? nothing remarkable.. eri0:1 is now the address for eri0
and is used for outgoing packets..

> Solaris or the like -- then the "primality" property is implied to hold
> for non-alias interface, and otherwise for aliases. Am I mistaken?

Most of the primality property is an emulation of BSD behavior, simply
because BSD got there first. The cisco behavior you described was
also exactly the same as bsd behavior.

The secondary flag in linux sounds pretty useful (though I don't
know all the details.. what happens when the primary address is
deleted? does something else get promoted to primary status? Are
routing socket listeners informed about changes?)

Maybe zebra should do some internal management and set the
SECONDARY flag (after we agree on some definition for it) for
OS-es where the kernel does not help us.

Is anyone familiar with the linux kernel code around secondary
flag management, to understand linux semantics for this flag?

--Sowmini

sowmini.varadhan@Sun.COM wrote:

> The secondary flag in linux sounds pretty useful (though I don't
> know all the details.. what happens when the primary address is
> deleted? does something else get promoted to primary status? Are
> routing socket listeners informed about changes?)

When you delete a primary address, it flushes the whole chain of
subsequent secondaries as well. Netlink subscribers are informed of this
bulk address deletion, of course.


> Maybe zebra should do some internal management and set the
> SECONDARY flag (after we agree on some definition for it) for
> OS-es where the kernel does not help us.

On what basis should it set the secondary flag? What about OS's where it
cannot set this flag at all (eg, Linux, and probably BSD as well) What
would be the meaning for an address to be "secondary" in the first
place? And how does it all fit into the restrictive Cisco-like syntax
and semantics? I'm not sure that the zebra daemon can set primary
attributes to addresses in a single, coherent, all-in-one interface.
Therefore, IMO, the better choice would be accurately sticking to what
the underlying kernel defines to be primary/secondary, and for that
sense you'll need to slightly extend the specialized kernel layers for
each such variant, in order to support describing these semantics to zebra.


> Is anyone familiar with the linux kernel code around secondary
> flag management, to understand linux semantics for this flag?

Is there anything unclear beyond what I've stated so far?...

Gilad

>
> > Maybe zebra should do some internal management and set the
> > SECONDARY flag (after we agree on some definition for it) for
> > OS-es where the kernel does not help us.
>
> On what basis should it set the secondary flag?

On the same basis as Linux?

> What about OS's where it
> cannot set this flag at all (eg, Linux, and probably BSD as well) What
> would be the meaning for an address to be "secondary" in the first
> place?

I think there's some misunderstanding here.. I was thinking of just
setting a flag that's internal to zebra [#], so that routing daemons
can behave consistently in sending behavior. As things stand now,
my understanding is that ospfd on bsd would send out packets with
source addresses that would have been marked "secondary" by linux.

[#] Obviously, you can't set/change flags in the kernel if it won't let
you, and you can't (or shouldn't be able to) outsmart the kernel.

--Sowmini

sowmini.varadhan@Sun.COM wrote:

>>On what basis should it set the secondary flag?
>
> On the same basis as Linux?

Okay, I get your point, but that isn't necessarily correct under all
circumstances, take for instance the case of primary (a-la Linux)
address removal: does it imply deletion of all dependent secondaries, or
else? (in BSD, according to your witness, it isn't mandatory) So, my
conclusion would be that zebra must correspond with the kernel in order
to get this configuration right.

I generally agree that correctly observing "secondary" addresses (again,
the Linux way, meaning subsequent addresses of a single subnet) and
reporting to protocols is important, in order to avoid duplicate,
unnecessary advertisements.


> I think there's some misunderstanding here.. I was thinking of just
> setting a flag that's internal to zebra [#], so that routing daemons
> can behave consistently in sending behavior. As things stand now,
> my understanding is that ospfd on bsd would send out packets with
> source addresses that would have been marked "secondary" by linux.

Let alone, it would do the same on Linux as well... ;-> (as ospfd uses
raw sockets, it can transmit with whatever source address it chooses)
Furthermore, zebra's ospfd implement an even-more-complicated approach
of abstract "OSPF interfaces", namely stand for <prefix,real-interface>
pairs, and applied a separate state machine for each; in this case, we'd
probably need to revise this abstraction so as to correctly handle
primary/secondary bundles, isn't it?...

(Is there anybody else listening here? Paul?)


> [#] Obviously, you can't set/change flags in the kernel if it won't let
> you, and you can't (or shouldn't be able to) outsmart the kernel.

Elementary... but what about correctly understanding your kernel? ;->

Gilad

In my dictionary, yes.. To me, an interface is a physical card,
link is what Greg calls "prefix/subnet". Therefore, you can
have multiple interfaces on the same link/prefix/subnet, one
interface on multiple links/prefixes/subnets.

interface is a port on a card.

link is a medium that a port plugs into, such as a 100 Mb/s
hub/switch.

It is possible to plug two or more interfaces into a link.

prefix/subnet is an address/mask (with no bits set in the 'host'
portion) that denotes a logical network. Each subnet is associated
with one link, but a link may have more than one subnet.

At least that's how I use the terms.

> It remains to be seen whether this is what ZEBRA_IFA_SECONDARY really
> means, though.

In fact, it does not: this goes back to historical discussions about the
meaning of the term "secondary" in zebra/quagga (for example, see
[quagga-dev 72] and follow-ups). Briefly speaking, I believe the
original need emerged from Cisco compatibility, where a secondary
address is any non-primary address assigned to an interface, and each
interface may have exactly one primary address.

So we have an architectural choice. Do we declare that of all
addresses with the 'prefix_cmp'-same prefixes, that all but the first
one we saw (or whatever) are 'secondfooary', for some term foo, and
choose to assign a new flag to denote this? Or, do we let each
protocol which has to make such tests (which ripd apparently should)
do this test on its own.

I don't see this as intimately connected with any particular kernel
flags, and is sensible in the absence of special kernel support.

Out of curiosity I tried this umm, pathological case on a spare nic on
linux 2.4.23:

# ip addr add 10.0.0.1/24 dev eth1
# ip addr add 10.0.0.2/24 dev eth1
# ip addr add 10.0.0.3/25 dev eth1
# ip addr add 10.0.0.4/23 dev eth1
# ip addr show dev eth1

5: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 00:02:44:4c:04:c8 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 scope global eth1
inet 10.0.0.3/25 scope global eth1
inet 10.0.0.4/23 scope global eth1
inet 10.0.0.2/24 scope global secondary eth1

# ip addr del 10.0.0.1/24 dev eth1
# ip addr show dev eth1

5: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 00:02:44:4c:04:c8 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.3/25 scope global eth1
inet 10.0.0.4/23 scope global eth1

Further tests confirmed that the netmask must comply and that the
secondary flag is up for all except the firstly added address with
that netmask, independent of the IP address.

--
Frank

Frank van Maarseveen wrote:

> Further tests confirmed that the netmask must comply and that the
> secondary flag is up for all except the firstly added address with
> that netmask, independent of the IP address.

This was reported and discussed previously, see [zebra 18516] and [zebra
18531]. In fact, it's quite an understandable behavior, if we assume
that secondary is aimed to tie break the decision as for which address
to use as source address: for addresses (therefore implied connected
routes) of different netmask, it will be chosen based on prefix longest
match paradigm, as it is for any outbound IP packet; so, the problem
only exists for addresses residing on the same IP subnet with the same
netmask.

(You also implicitly confirmed the flushing behavior of secondary chains
when a primary address is deleted.)

Gilad

Greg Troxel wrote:

> So we have an architectural choice. Do we declare that of all
> addresses with the 'prefix_cmp'-same prefixes, that all but the first
> one we saw (or whatever) are 'secondfooary', for some term foo, and
> choose to assign a new flag to denote this? Or, do we let each
> protocol which has to make such tests (which ripd apparently should)
> do this test on its own.

As long as a protocol doesn't require any notion of which of a subnet's
addresses is the "primary" one (meaning, the one that is used as source
address for sending packets), then it's probably a good solution that is
independant of what zebra and/or kernel believes those addresses to be.


> I don't see this as intimately connected with any particular kernel
> flags, and is sensible in the absence of special kernel support.

I think this is generally a healthy approach, but one thing still needs
to be addressed sometime -- fixing zebra's 'secondary' flag for IP
addresses, so as to correlate with some real kernel property applied to
those addresses (currently it has nothing to do with actual forwarding,
although the code attempts to set those secondary attributes). My own
proposal: eliminate the use of 'secondary' in VTY, and that's it... what
do you think?

Gilad

As long as a protocol doesn't require any notion of which of a subnet's
addresses is the "primary" one (meaning, the one that is used as source
address for sending packets), then it's probably a good solution that is
independant of what zebra and/or kernel believes those addresses to be.

I think one just has to be chosen and it doesn't matter which.
We can do this cheesily by making the first found address the one that
doesn't get marked as a dup; this will do 'the right' thing by most
people's stadards.

I think this is generally a healthy approach, but one thing still needs
to be addressed sometime -- fixing zebra's 'secondary' flag for IP
addresses, so as to correlate with some real kernel property applied to
those addresses (currently it has nothing to do with actual forwarding,
although the code attempts to set those secondary attributes). My own
proposal: eliminate the use of 'secondary' in VTY, and that's it... what
do you think?

Someone needs to understand exactly what that command does on a cisco
- or is it there to support the Linux secondary notion? I would be ok
with removing it, or at least making it conditional on
--enable-secondary.

Greg Troxel wrote:

> As long as a protocol doesn't require any notion of which of a subnet's
> addresses is the "primary" one (meaning, the one that is used as source
> address for sending packets), then it's probably a good solution that is
> independant of what zebra and/or kernel believes those addresses to be.
>
> I think one just has to be chosen and it doesn't matter which.
> We can do this cheesily by making the first found address the one that
> doesn't get marked as a dup; this will do 'the right' thing by most
> people's stadards.

In fact I was promoting your idea of letting each protocol daemon manage
its own bundling of IP addresses on an interface, thus totally letting
go of any "secondary" property that may apply with regard to
forwarding... (did I misunderstand?)


> Someone needs to understand exactly what that command does on a cisco
> - or is it there to support the Linux secondary notion? I would be ok
> with removing it, or at least making it conditional on
> --enable-secondary.

I think that all relevant information is known, isn't it?

Gilad

> Greg Troxel wrote:
>
> > As long as a protocol doesn't require any notion of which of a subnet's
> > addresses is the "primary" one (meaning, the one that is used as source
> > address for sending packets), then it's probably a good solution that is
> > independant of what zebra and/or kernel believes those addresses to be.
> >
> > I think one just has to be chosen and it doesn't matter which.
> > We can do this cheesily by making the first found address the one that
> > doesn't get marked as a dup; this will do 'the right' thing by most
> > people's stadards.
>
> In fact I was promoting your idea of letting each protocol daemon manage
> its own bundling of IP addresses on an interface, thus totally letting
> go of any "secondary" property that may apply with regard to
> forwarding... (did I misunderstand?)

This solution is unavoidably OS-dependant. Sometimes, as in the case
of Linux or Solaris (when IP multipathing is enabled), the OS will
pass up flags to indicate which address is "primary" (the rest
being secondary/deprecated/back-up) and the daemon has to be in step
with the kernel. Otherwise, the daemon could end up picking a deprecated
address as source address, and misleading/confusing listeners into
using the deprecated address for the destination.

> > Someone needs to understand exactly what that command does on a cisco
> > - or is it there to support the Linux secondary notion? I would be ok
> > with removing it, or at least making it conditional on
> > --enable-secondary.

that sounds reasonable.

--Sowmini

sowmini.varadhan@sun.com wrote:

> This solution is unavoidably OS-dependant. Sometimes, as in the case
> of Linux or Solaris (when IP multipathing is enabled), the OS will
> pass up flags to indicate which address is "primary" (the rest
> being secondary/deprecated/back-up) and the daemon has to be in step
> with the kernel. Otherwise, the daemon could end up picking a deprecated
> address as source address, and misleading/confusing listeners into
> using the deprecated address for the destination.

I agree it would be ideal given that one comes up with an approach
that's general enough to cover all possible breeds of kernel behaviors,
and one can also implement it successfully in quagga (I believe it takes
some change in architecture, since it will require tying all address
redistribution to the event of address reflection from the kernel layer,
eg netlink).

By the way, for the sake of this particular problem -- what could be the
harm in using a secondary/deprecated/back-up address as destination by
neighbors? I mean, any secondary address is always valid for receiving,
isn't it?

Gilad

>
> By the way, for the sake of this particular problem -- what could be the
> harm in using a secondary/deprecated/back-up address as destination by
> neighbors? I mean, any secondary address is always valid for receiving,
> isn't it?
>

Let's take the deprecated case.. the kernel is probably marking the
address as deprecated because the address is going to be timed out/deleted
soon, and should not be used as the source addr for new connections..
the daemons should pay attention to that.. another case is when
there are multiple connections/interfaces to the link, and some interfaces
are "better" (faster? more reliable?) than others and therefore
being marked primary, while the "worse" interfaces are backup. If
we use the address on the backup as the source address, the return
packet is going to potentially take the wrong path back (down the slow
connection). To make this clearer, consider the setup below ("..." represents
some random set of routers):


-------- connection 1 --------
| |-------...----------| |
| A | | B |
| |-------...----------| |
-------- connection 2 --------

If connection_1 is the "better" link, and A marks A1 (its addr on
connection_1) as primary, but sends out packets with source A2, then
B, in its returned packets could use A2 as the dest addr, and end up
sending the packets down the "worse" link.

No harm is done, but likely to cause some dissatisfaction in the audience.

--Sowmini

sowmini.varadhan@Sun.COM wrote:

> -------- connection 1 --------
> | |-------...----------| |
> | A | | B |
> | |-------...----------| |
> -------- connection 2 --------
>
> If connection_1 is the "better" link, and A marks A1 (its addr on
> connection_1) as primary, but sends out packets with source A2, then
> B, in its returned packets could use A2 as the dest addr, and end up
> sending the packets down the "worse" link.

I don't quite seems to get it: are A1 and A2 in your example associated
with different physical links? Or the other way round, if those are two
addresses assigned to a single "interface" (the Linux way, some layer-2
entity that's used to send/receive datagrams), don't they inherit the
same link characteristics? (as they are going down the same driver with
the same control block, etc?)

Otherwise, if they are associated with different interfaces, they aren't
primary/secondary related in the first place.

Gilad

>
> > -------- connection 1 --------
> > | |-------...----------| |
> > | A | | B |
> > | |-------...----------| |
> > -------- connection 2 --------
> >
> I don't quite seems to get it: are A1 and A2 in your example associated
> with different physical links? Or the other way round, if those are two

Yes, I was talking about something like Solaris multipathing, or
when you have multiple interfaces on thes same link.

> Otherwise, if they are associated with different interfaces, they aren't
> primary/secondary related in the first place.

True, but with Solaris multipathing, the kernel is doing failover
management and has its notion of a preferred interface. If that is
the case, the daemons should probably be in sync with the kernel.

--Sowmini

On Tue, 13 Jan 2004 sowmini.varadhan@Sun.COM wrote:

> One possibility is for zebra to notice that B and C are really
> duplicate addresses on the network N, and to flag them as
> ZEBRA_IFA_DUP (leaving ZEBRA_IFA_SECONDARY as designed).

What would be the difference between ZEBRA_IFA_DUP and
ZEBRA_IFA_SECONDARY though? Arent they same thing to all intents and
purposes?

I had this discussion with Gilad a long time ago. I argued that
perhaps zebra should do detection of duplicate and included subnets
and set the secondary flag accordingly. Discussion was inconclusive
(though in the case of linux, kernel sets secondary flag, and its
reflected on).

> This would require some changes to functions like connected_up_ipv4
> (which I'm investigating currently)- they will have to call
> prefix_match instead of prefix_same, and do some work to identify
> the difference between an exact match and a prefix match (so that
> addresses don't get configured twice etc.)

What about included subnets? Eg,

eth0:
1.1.1.0/24
1.1.1.x/25
1.1.1.y/32

> This solution is non-trivial, because the daemons now have to
> recognize when to fail-over, when to promote something from DUP to
> primary etc.

Hmmm... this brings us back to kernel behaviour:

# ip -4 addr show dev usb0
# ip add add 192.168.100.1/24 dev usb0
# ip -4 addr show dev usb0
2: usb0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.100.1/24 scope global usb0
# ip add add 192.168.100.2/24 dev usb0
# ip -4 addr show dev usb0
2: usb0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.100.1/24 scope global usb0
inet 192.168.100.2/24 scope global secondary usb0
# ip add del 192.168.100.1/24 dev usb0
# ip -4 addr show dev usb0
#

ie, in the case of linux, removing the primary address removes the
DUP (or secondary) addresses too.

I would argue the issue of promotion or removal of addresses is one
for the kernel, that zebra simply needs to be kept informed.

> --Sowmini

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Your computer account is overdrawn. Please see Big Brother.

On Tue, 13 Jan 2004, Greg Troxel wrote:

> like it might well be the right thing, but I'd like to see the
> semantics for ZEBRA_IFA_SECONDARY documented.

At the moment it reflects the netlink IFA_F_SECONDARY flag.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
A diplomat's life consists of three things: protocol, Geritol, and alcohol.
-- Adlai Stevenson

What would be the difference between ZEBRA_IFA_DUP and
ZEBRA_IFA_SECONDARY though? Arent they same thing to all intents and
purposes?

They might be. It remains to add comments to the code that define
precisely the semantics of the flag _without_ using the words "is set
if Linux kernel says so". Or, IFA_SECONDARY can be defined to be set
if Linux says so, but then that becomes a Linux-specific feature, and
we can define DUP to be 'there is another address on this interface
which is not marked DUP which has the prefix-cmp-same prefix'. I
suppose SECONDARY can be defined just like that, with the added
restriction that the address which doesn't get SECONDARY is chosen to
be the one that the kernel does not label secondary, on kernels which
do such any kind of secondary labeling.

I had this discussion with Gilad a long time ago. I argued that
perhaps zebra should do detection of duplicate and included subnets
and set the secondary flag accordingly. Discussion was inconclusive
(though in the case of linux, kernel sets secondary flag, and its
reflected on).

It's really a question of whether zebra should provide this
abstraction. Since it is a bit hard, it might make sense to
centralize it.


I would argue the issue of promotion or removal of addresses is one
for the kernel, that zebra simply needs to be kept informed.

I agree.

eth0:
1.1.1.0/24
1.1.1.x/25
1.1.1.y/32

I'd say we should look at all the routing protocols which deal with
this, and see what def would be most useful for them.
I consider the above example pathological; while two nonoverlapping
prefixes are sometimes reasonble, as is having two addrs in the same
prefix, having overlapping nonequal prefixes to me is a sign of a
confused network design. This case is likely to be underspecified in
routing daemons. So it may not matter much how we handle it (but of
course we have to be clear and consistent).

On Wed, 14 Jan 2004, Greg Troxel wrote:

> What would be the difference between ZEBRA_IFA_DUP and
> ZEBRA_IFA_SECONDARY though? Arent they same thing to all intents and
> purposes?
>
> They might be. It remains to add comments to the code that define
> precisely the semantics of the flag _without_ using the words "is set
> if Linux kernel says so".

Sorry, the exact meaning at the moment is "Linux kernel set the
secondary flag".

What I'm asking is the more abstract question of whether the IFA_DUP
flag, which some BSD kernels have, is notionally equivalent to
Linux's IFA_F_SECONDARY flag? If so, ZEBRA_IFA_SECONDARY is then what
we should set internally inside zebra. (ospfd already looks for this
flag).

Further questions:

- are there kernels which can have multiple addresses attached to an
interface which do not have or do not set a 'duplicate' or
'secondary' flag?

- for kernels which set such flags, do these kernel's properly notify
zebra of events relating to change in status of duplicate/secondary
addresses? eg, if the primary address is removed, what does the
kernel do for secondary addresses and does it inform zebra
appropriately?


> Or, IFA_SECONDARY can be defined to be set if Linux says so, but
> then that becomes a Linux-specific feature, and we can define DUP
> to be 'there is another address on this interface which is not
> marked DUP which has the prefix-cmp-same prefix'.

Do BSD kernels have IFA_F_SECONDARY? :)

> I suppose SECONDARY can be defined just like that, with the added
> restriction that the address which doesn't get SECONDARY is chosen
> to be the one that the kernel does not label secondary, on kernels
> which do such any kind of secondary labeling.

Absence of 'secondary' implies 'primary', at least on linux.

> It's really a question of whether zebra should provide this
> abstraction. Since it is a bit hard, it might make sense to
> centralize it.

Well, first we should ask ourselves whether kernel's already handle
this for us, eg linux does.

One other thing we do need to consider is 'included' subnets - linux
allows this and there is no flag to distinguish such.

> eth0:
> 1.1.1.0/24
> 1.1.1.x/25
> 1.1.1.y/32
>
> I'd say we should look at all the routing protocols which deal with
> this, and see what def would be most useful for them. I consider
> the above example pathological;

So do i. I would consider it admin error. Another example is:

eth0:
1.1.1.x/24
eth1:
1.1.1.y/25

where the two interfaces are on completely seperate networks, if must
associate an address (eg source addr of a packet) with an interface
and that address fals within 1.1.1.y/25 which interface do you pick?

ospfd gets very confused by such setups, it'd be nice if it could
detect such cases. However it is still a case of admin error - dont
do that.

> having two addrs in the same prefix, having overlapping nonequal
> prefixes to me is a sign of a confused network design.

yep.

> This case is likely to be underspecified in routing daemons. So it
> may not matter much how we handle it (but of course we have to be
> clear and consistent).

at present ospfd gets confused. So we might wish to consider adding a
ZEBRA_IFA_INCLUDED flag and having zebra do inclusion detection for
interface addresses and setting the flag appropriately.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
If God had intended Man to program, we'd be born with serial I/O ports.

On Tue, 13 Jan 2004 sowmini.varadhan@sun.com wrote:

> Seems like ospfd does something to this effect too-

Yes.

> Paul tells me that it will not send packets on ZEBRA_IFA_SECONDARY
> networks, which strikes me as behavior in the same spirit?

Yep, however, ZEBRA_IFA_SECONDARY at present is only set on netlink
platforms (ie linux).

> --Sowmini

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
The founding fathers tried to set up a judicial system where the accused
received a fair trial, not a system to insure an acquittal on technicalities.

Sorry, the exact meaning at the moment is "Linux kernel set the
secondary flag".

Fine for now, but before we can go setting it in other systems we need
a real semantics def.

What I'm asking is the more abstract question of whether the IFA_DUP
flag, which some BSD kernels have, is notionally equivalent to
Linux's IFA_F_SECONDARY flag? If so, ZEBRA_IFA_SECONDARY is then what
we should set internally inside zebra. (ospfd already looks for this
flag).

NetBSD does not seem to have IFA_DUP. There is a notion of aliases,
but I think that is really to differentiate 'change the addr' from
'add this addr'. It seems to be a v4 thing only; I think v6 always
adds a new one. /sbin/ifconfig prints alias, but this is AFAICT not a
property of the address.

So yes, I think that we can define a sensible general behavior.

I had one addr, and added an alias. ifconfig showed the new one as an
alias. I deleted the first, and added it back as an alias. Now the
original address shows as an alias.

- are there kernels which can have multiple addresses attached to an
interface which do not have or do not set a 'duplicate' or
'secondary' flag?

NetBSD does this, I think. ifconfig loops over the addrs, and
addresses which are not equal to the 'primary' addr (what SIOCGIFADDR
returns) are printed with the word alias.

So zebra would have to keep track of such designations. This is
probably hairy, but it is pretty easy to write an invariant checker
and call it often.

- for kernels which set such flags, do these kernel's properly notify
zebra of events relating to change in status of duplicate/secondary
addresses? eg, if the primary address is removed, what does the
kernel do for secondary addresses and does it inform zebra
appropriately?

On Linux, the secondary address seems to vanish too.

Do BSD kernels have IFA_F_SECONDARY? :)

no

> I suppose SECONDARY can be defined just like that, with the added
> restriction that the address which doesn't get SECONDARY is chosen
> to be the one that the kernel does not label secondary, on kernels
> which do such any kind of secondary labeling.

Absence of 'secondary' implies 'primary', at least on linux.

sure, but I was trying to say how labels could get assigned when the
kernel doesn't.

> It's really a question of whether zebra should provide this
> abstraction. Since it is a bit hard, it might make sense to
> centralize it.

Well, first we should ask ourselves whether kernel's already handle
this for us, eg linux does.

Some do, but it isn't clear that this is a service that the kernel
needs to provide. AFAICT, the only thing the kernel does with the
flag is delete the secondary addrs when the primary is deleted.

Is it an error (on Linux) to have two addrs in the same prefix with
neither marked secondary?

One other thing we do need to consider is 'included' subnets - linux
allows this and there is no flag to distinguish such.

Right, so we would need another flag that says that this address is on
a subnet that is included in another (larger) subnet. If anyone
cares, and I'm not clear.

So do i. I would consider it admin error. Another example is:

eth0:
1.1.1.x/24
eth1:
1.1.1.y/25

This is also a broken setup.

where the two interfaces are on completely seperate networks, if must
associate an address (eg source addr of a packet) with an interface
and that address fals within 1.1.1.y/25 which interface do you pick?

Do you mean use the source addr to find the interface? One shouldn't
do that, but instead set SO_RECVIF so that the kernel will tell you
the interface that the packet came in on.

ospfd gets very confused by such setups, it'd be nice if it could
detect such cases. However it is still a case of admin error - dont
do that.

One could add code to zebra to intersect all the configured prefixes
and if a, b are found s.t. a != b and intersect(a,b) then issue a
warning.

at present ospfd gets confused. So we might wish to consider adding a
ZEBRA_IFA_INCLUDED flag and having zebra do inclusion detection for
interface addresses and setting the flag appropriately.

across a single interface, or across all configured addresses? (two
flags: INCLUDED_IF and INCLUDED .... :-)

Many of the questions that Paul asked were answered (or discussed)
in this thread yesterday, but

> where the two interfaces are on completely seperate networks, if must
> associate an address (eg source addr of a packet) with an interface
> and that address fals within 1.1.1.y/25 which interface do you pick?

To find the source address of the packet, it can use IP_RECVIF, right?
For outgoing packets, there are multiple choices- either first available,
or explicitly set outgoing interface with some suitable system
call.. right?

--Sowmini

On Wed, 14 Jan 2004 sowmini.varadhan@sun.com wrote:

> To find the source address of the packet, it can use IP_RECVIF,
> right?

Not on linux, its IP_PKTINFO, slightly different. Iirc, ospfd uses
source address of incoming packets to lookup appropriate ospf
interface struct.

> --Sowmini

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
"The identical is equal to itself, since it is different."
-- Franco Spisani

Not on linux, its IP_PKTINFO, slightly different.

I suppose we should have an abstraction layer to hide this then.

Iirc, ospfd uses source address of incoming packets to lookup
appropriate ospf interface struct.

That's too bad, since it can be wrong and is more subject to spoofing.