Mailing List Archive

Hasso Tepper wrote:

> If no one objects (with patch, please :), I will commit [quagga-dev
> 825].

No objection, it obviously fixes an incorrect behavior. Although, I have
sent a patch which revises the whole secondary behavior of quagga, for
reference by Paul/Sowmini/Greg. I'm attaching it for your reference as
well, although there were some implementation decisions taken that I'm
not really satisfied with. Whatsoever, my patch totally deprecates the
use of 'secondary' in VTY.


> Btw, to warm up discussion and to solve situation finally in proper
> way, info how Junos handles situation. It has two separate keywords -
> "primary" and "preferred".

Aha, I recalled I came by this paradigm a while ago, but couldn't find
it later when I wanted to check the details! Let's see...


> Primary
> *******
>
> Configure this address to be the primary address of the protocol on
> the interface. If the logical unit has more than one address, the
> primary address is used by default as the source address when packets
> originate from the interface and the destination does not indicate
> the subnet.
>
> Default
>
> For unicast traffic, the primary address is the lowest non-127
> preferred address on the unit.
>
> Preferred
> *********
>
> Configure this address to be the preferred address on the interface.
> If you configure more than one address on the same subnet, the
> preferred source address is chosen by default as the source address
> when you originate packets to destinations on the subnet.
>
> Default
>
> The lowest numbered address on the subnet is the preferred address.

Okay, the definition is clear, but I have one point unclarified
regarding "primary" (Junos-wise): what are the cases where a
"destination does not indicate the subnet"? Isn't a destination always
routing via some connected nexthop, in which case the "preferred"
address of that nexthop's subnet can be used? Do "preferred" addresses
relate to connected destinations only, while all remote destinations are
considered to "not indicate the subnet"? I'm quite curious.

Anyway, trying to compare this with the Linux/BSD behavior we've figured
lately, I would say that: the "preferred" notation (Junos) is parallel
in meaning to the "primary" notation in Linux and BSD, just that (1) the
defaults are different, namely the first address defined of a subnet is
the primary address (Linux/BSD), and (2) the selection of primary cannot
be changed in neither of them; the "primary" notation (Junos) has no
equivalent as of Linux, and is possibly equivalent to BSD's non-alias
address -- as such, it may possibly be redefined by SIOCSIFADDR (rather
than SIOCAIFADDR) in BSD.

Nonetheless, it seems the Junos' scheme is the finest and so far most
tunable one we've seen, while IOS is at the other edge of the scale,
isn't it?

Gilad


(patch is attached, with some text as well...)

Gilad Arnold wrote:
> Hasso Tepper wrote:
> > If no one objects (with patch, please :), I will commit
> > [quagga-dev 825].
>
> No objection, it obviously fixes an incorrect behavior. Although, I
> have sent a patch which revises the whole secondary behavior of
> quagga, for reference by Paul/Sowmini/Greg. I'm attaching it for
> your reference as well, although there were some implementation
> decisions taken that I'm not really satisfied with. Whatsoever, my
> patch totally deprecates the use of 'secondary' in VTY.

Aha. But ... unified patch (diff -u), please? :)

[snip]

> Okay, the definition is clear, but I have one point unclarified
> regarding "primary" (Junos-wise): what are the cases where a
> "destination does not indicate the subnet"? Isn't a destination
> always routing via some connected nexthop, in which case the
> "preferred" address of that nexthop's subnet can be used? Do
> "preferred" addresses relate to connected destinations only, while
> all remote destinations are considered to "not indicate the
> subnet"? I'm quite curious.

I don't know how it affects forwarding, but sure it is used by routing
protocols in case there is need to choose ONE ip address from
interface. For sure it is used by rip - rip is enabled in interface
and primary address is used as source address for packets.

> Anyway, trying to compare this with the Linux/BSD behavior we've
> figured lately, I would say that: the "preferred" notation (Junos)
> is parallel in meaning to the "primary" notation in Linux and BSD,
> just that (1) the defaults are different, namely the first address
> defined of a subnet is the primary address (Linux/BSD), and (2) the
> selection of primary cannot be changed in neither of them; the
> "primary" notation (Junos) has no equivalent as of Linux, and is
> possibly equivalent to BSD's non-alias address -- as such, it may
> possibly be redefined by SIOCSIFADDR (rather than SIOCAIFADDR) in
> BSD.

We have way to leave primary/secondary stuff alone in cli, let OS
handle this (we don't have even chance to change this behavior if I
understood correctly) and choose one keyword to behave a la "primary"
in Junos - just for quagga context.

> Nonetheless, it seems the Junos' scheme is the finest and so far
> most tunable one we've seen, while IOS is at the other edge of the
> scale, isn't it?

Seems so :).

--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator

Hasso Tepper wrote:

> Aha. But ... unified patch (diff -u), please? :)

As context and unified formats are completely equivalent info-wise, you
can convert from one to another using patchutil goodies, eg:

filterdiff -v --format=unified < patch.context.diff

(But I'm attaching a unified version whatsoever ;-> )


> I don't know how it affects forwarding, but sure it is used by routing
> protocols in case there is need to choose ONE ip address from
> interface. For sure it is used by rip - rip is enabled in interface
> and primary address is used as source address for packets.

Ah, obviously, broadcast/multicast destinations... In this case, I'd say
the notion of "primary" is indeed necessary; for our case, how about
using the oldest interface address as primary? Makes more sense speaking
BSD-like terms, as the first address gets a special treatment. In Linux
this is apparently seemless/non-existent, but I think that we can decide
this as an internal policy -- what do you think?

In other words, assuming "primary" and "secondary" as we've defined them
earlier in last thread, I'd say that Junos-wise "primary" in quagga
would be the oldest kernel/quagga-wise "primary" as we've defined it.
All there needs to be defined, is proper terminology and/or flags, to
distinguish those addresses.


> We have way to leave primary/secondary stuff alone in cli, let OS
> handle this (we don't have even chance to change this behavior if I
> understood correctly) and choose one keyword to behave a la "primary"
> in Junos - just for quagga context.

I'm not sure that there's any use in manual selection of "primary" a-la
Junos: as "primary" is most likely to be a "preferred" address, and
since our "preferred" addresses are computed internally wrt kernel, I'd
say that "primary" should be the same -- as mentioned above, let it be
the oldest "preferred" address of an interface. It can be handled quite
easily I guess.


> Seems so :).

What a surprise... ;->

Gilad

Silly me...


Gilad Arnold wrote:

> (But I'm attaching a unified version whatsoever ;-> )

Here it is... ;o>

Gilad

Gilad Arnold wrote:
> Hasso Tepper wrote:
> > Aha. But ... unified patch (diff -u), please? :)
>
> As context and unified formats are completely equivalent info-wise,
> you can convert from one to another using patchutil goodies, eg:
>
> filterdiff -v --format=unified < patch.context.diff

Aha! Nice ...

> (But I'm attaching a unified version whatsoever ;-> )

Where? ;) OK, thanks to hint I have it already.

> > I don't know how it affects forwarding, but sure it is used by
> > routing protocols in case there is need to choose ONE ip address
> > from interface. For sure it is used by rip - rip is enabled in
> > interface and primary address is used as source address for
> > packets.
>
> Ah, obviously, broadcast/multicast destinations... In this case,
> I'd say the notion of "primary" is indeed necessary; for our case,
> how about using the oldest interface address as primary? Makes more
> sense speaking BSD-like terms, as the first address gets a special
> treatment. In Linux this is apparently seemless/non-existent, but I
> think that we can decide this as an internal policy -- what do you
> think?

How quagga ripd behaves if you enable ripd in interface with multiple
ip addresses? Is there need for "primary" aadress? Maybe it's still
good idea to have way to choose "primary" (Junos meaning) address. At
least I remember some arguments in favor of having this in past
discussions. Someone refresh memory of old man? ;)

> In other words, assuming "primary" and "secondary" as we've defined
> them earlier in last thread, I'd say that Junos-wise "primary" in
> quagga would be the oldest kernel/quagga-wise "primary" as we've
> defined it. All there needs to be defined, is proper terminology
> and/or flags, to distinguish those addresses.

And it would be good to get comments regarding patch from
Solaris/HP-UX /whatever users as well.

--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator