[j-nsp] interface-range inheritance change in 14.1X53 and 15.1

[Thomas Bellman]

On 2018-12-21 23:22 UTC, Anderson, Charles R wrote:

> Can anyone shed some light on WHY this change was made?  I much prefer
> the old behavior.
> 
> From PR1281947:
> 
> "The behavior of the "interface-range" configuration statement changed
> in 14.1X53 and 15.1. Prior to 14.1X53 and 15.1, more specific configuration
> on the interface would supersede what was configured in the interface-range.
> In 14.1X53 or 15.1, if there was specific interface configuration, the
> configuration in "interface-range" will append to it. For example, if there
> is a mismatch of VLAN assignment between the interface-range and the direct
> interface configuration, it will append the configured VLAN and cause an
> invalid configuration in 14.1X53 or 15.1."

I don't know Juniper's motivations, but the new behaviour *allows* you
to append, which could be useful for trunk mode interfaces.  The old
behaviour didn't.  (I don't use this myself for interface ranges, but I
do use it for groups/apply-groups; I don't know if groups also changed
chnaged their behaviour.)

To, kind of, emulate the old behaviour, you could use multiple ranges:

    interface-range all-hosts {
        member-range xe-0/0/4 to xe-0/0/23;
        mtu 9216;
        unit 0 {
            family ethernet-switching {
                interface-mode access;
            }
        }
    }
    interface-range most-hosts {
        member-range xe-0/0/4 to xe-0/0/14;
        member-range xe-0/0/16 to xe-0/0/23;
        unit 0 {
            family ethernet-switching {
                vlan { members HostVLAN; }
            }
        }
    }
    xe-0/0/15 {
        unit 0 {
            family ethernet-switching {
                vlan { members OtherVLAN; }
            }
        }
    }

Admittedly, a fair bit more clumsy, but it *is* possible to express.

Maybe there should have been a 'except-interface-range <name>'
statement, similar to 'apply-groups-except'?


(A nicer way of expressing VLAN assignments, would be to throw out
the 'interface-mode' statement, and replace 'vlan members' with two
statements: 'untagged-vlan <name>' and 'tagged-vlans <list>'.  I
suppose that would also have solved your practical problems, since
singletons are still overridden by more specific declarations, and I
guess you want this for access-mode interfaces.)


	/Bellman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20181221/13cf3a3c/attachment.sig>