Git Product home page Git Product logo

ifupdown2's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ifupdown2's Issues

module object has no attribute ethtool

Hello,

I'm trying to use ifupdown2 on a Debian Jessie. I purged the ifupdown(1)-package with apt-get and installed it from the Debian repository. But I get the following error:

ifquery -a
error: 'module' object has no attribute 'ethtool'

Secondly, I tried to build it from git. The deb-package is created, but after the installation, there is no executable in the path nor can I find one on the system.

ifquery leads to command not found.

Do you have any hints for me, how to use ifupdown2 on Debian Jessie?

Regards,
Matthias

address can't be setup on a vlan aware bridge

Hi,
Currently it's not possible to set an address on a bridge with vlan aware

utils.py

    def is_addr_ip_allowed_on(cls, ifaceobj, syntax_check=False):
        msg = ('%s: ignoring ip address. Assigning an IP '
               'address is not allowed on' % ifaceobj.name)
        if (ifaceobj.role & ifaceRole.SLAVE
                and not (ifaceobj.link_privflags & ifaceLinkPrivFlags.VRF_SLAVE)):
            up = None
            if ifaceobj.upperifaces:
                up = ifaceobj.upperifaces[0]
            msg = ('%s enslaved interfaces. %s'
                   % (msg, ('%s is enslaved to %s'
                            % (ifaceobj.name, up)) if up else '')).strip()
            if syntax_check:
                cls.logger.warning(msg)
            else:
                cls.logger.info(msg)
            return False
        elif (ifaceobj.link_kind & ifaceLinkKind.BRIDGE
                and ifaceobj.link_privflags & ifaceLinkPrivFlags.BRIDGE_VLAN_AWARE):
            msg = '%s bridge vlan aware interfaces'
            if syntax_check:
                cls.logger.warning(msg)
            else:
                cls.logger.info(msg)
            return False
        return True

Technically, it's possible to add an ip to a vlan aware bridge, in this case I think it's going to use the default PVID.

any reason to forbid this ?

manual interface, link is not up

Hi,
with a simple

auto eno2
iface eno2 inet manual

the interface link is not up.
on classic ifupdown, it's up.

I think this is because of:

if not a logical interface and addr method is manual,

    # ignore link admin state changes
    if (ifaceobj.addr_method == 'manual' and
        not ifaceobj.link_kind):
        return

The problem is that with something like

auto eno1
iface eno1 inet manual

auto eno1.100
iface eno1.100 inet static
address x.x.x.x

the eno1.100 is also down.

why this behaviour ?

install deb "Breaks existing package 'bridge-utils' that conflict with 'ifupdown"

so what is needed to install ifupdown2_1.0~git20170314-1_all.deb on my HP wx9400
Quad-Core AMD Opteron(tm) Processor 2380 ร— 8
Dual Quadro FX 3700/PCIe/SSE2
32 Gbit RAM
Dual Nvidia MPC55 ethernet
Ubuntu-server + ubuntu-gnome 14.04.5 Linux config-4.4.0-109-generic
because I hate everything done by only terminal CMD (no purity arguments please as this box cooks)
screenshot ifupdown2 2018-01-19 12 37 52

Feature request : multiple gateways (ecmp)

Hi,

it could be great to add support for multiple gateway through ecmp.

maybe simply allow something like

iface eth0

gateway X.X.X.X
gateway Y.Y.Y.Y

(ip route add default nexthop viaX.X.X.X dev eth0 nexthop via Y.Y.Y.Y dev eth0)

or

iface eth0
gateway X.X.X.X

iface eth1
gateway Y.Y.Y.Y

ip route add default nexthop via X.X.X.X dev eth0 nexthop via Y.Y.Y.Y dev eth1

also , maybe add support for selectable hash algorith from recent kernel

https://cumulusnetworks.com/blog/celebrating-ecmp-part-two/

feature request: network namespace support

Hey!

It would be pretty useful to have network namespace support (compatible with ip netns). An interface could be tagged in a network namespace and the configuration would be done in the appropriate namespace.

Currently, VRF could be used as a replacement, but an application cannot easily be bound to a VRF without modification while it is easy to execute in a network namespace (with ip netns exec).

[bug report] not working for tap iface

Linux ovpn 4.15.0-23-generic #25-Ubuntu SMP x86_64
Python 2.7.15rc1
Python 3.6.5
iproute2 4.15.0-2ubuntu1
ifupdown2 1.0~git20170314-1
ifupdown removed


Is it a bug or a feature missing as it appears that ifupdown2 is not working for tap interfaces.

auto tap0
iface tap0 inet manual
  pre-up openvpn --mktun --dev tap0

There are no errors but the iface is not being loaded. No such issue however with ifupdown


In general was wondering whether ifupdown2 is still being actively developed?

CM-12370 Upstream

Hi,

could you upstream the fix for CM-12370?
With the current debian version git20180313 it is not possible to have ipv4 and ipv6 with dhcp:

If you configure an interface so it can to obtain both IPv4 and IPv6 IP addresses via DHCP, ifupdown2 will honor only the first configuration and ignore the second.

Best and thank you
Sven

addons_scripts : interfaces options are keeped in env vars between differents interfaces

Hi,

I'm currently trying to make working openvswitch pre-up addon script, and I have notice something strange.

with this simple exemple:

auto eno1
iface eno1
        testvariable1 test

auto eno1.100
iface eno1.100
        address 10.59.100.231
        netmask 255.255.255.0
        gateway 10.59.100.1

auto vmbr100
iface vmbr100
        ovs_type OVSBridge



auto bridge
iface bridge
        ovs_type OVSBridge
        ovs_ports eno2

auto vmbr101
iface vmbr101
        testvariable2 test

systemctl networking reload

May 10 08:07:02 kvmformation1 networking[375279]: debug: vmbr101: pre-up : running script /etc/network/if-pre-up.d/openvswitch {'LANG': 'en_US.UTF-8', 'ADDRFAM': '', 'IFACE': 'vmbr101', 'JOURNAL_STREAM': '9:29498964', 'SHLVL': '1', 'LOGICAL': 'vmbr101', 'PWD': '/', 'MODE': 'start', '**IF_TESTVARIABLE2**': 'test', 'PHASE': 'pre-up', 'PATH': '/sbin:/bin', 'METHOD': '', '_': '/sbin/ifreload', 'INVOCATION_ID': '5ffcea837bc64759bd0c171b70e22cc2'}

May 10 08:07:02 kvmformation1 networking[375279]: debug: vmbr100: pre-up : running script /etc/network/if-pre-up.d/openvswitch {'LANG': 'en_US.UTF-8', 'ADDRFAM': '', '**IF_OVS_TYPE**': 'OVSBridge', 'IFACE': 'vmbr100', 'JOURNAL_STREAM': '9:29498964', 'SHLVL': '1', 'LOGICAL': 'vmbr100', 'PWD': '/', 'MODE': 'start', '**IF_TESTVARIABLE2**': 'test', 'PHASE': 'pre-up', 'PATH': '/sbin:/bin', 'METHOD': '', '_': '/sbin/ifreload', 'INVOCATION_ID': '5ffcea837bc64759bd0c171b70e22cc2'}

May 10 08:07:02 kvmformation1 networking[375279]: debug: eno1: pre-up : running script /etc/network/if-pre-up.d/openvswitch {'LANG': 'en_US.UTF-8', 'ADDRFAM': '', '**IF_OVS_TYPE**': 'OVSBridge', 'IFACE': 'eno1', 'JOURNAL_STREAM': '9:29498964', 'SHLVL': '1', 'LOGICAL': 'eno1', 'PWD': '/', 'MODE': 'start', '**IF_TESTVARIABLE2**': 'test', '**IF_TESTVARIABLE1**': 'test', 'PHASE': 'pre-up', 'PATH': '/sbin:/bin', 'METHOD': '', '_': '/sbin/ifreload', 'INVOCATION_ID': '5ffcea837bc64759bd0c171b70e22cc2'}

May 10 08:07:02 kvmformation1 networking[375279]: debug: eno1.100: pre-up : running script /etc/network/if-pre-up.d/openvswitch {'LANG': 'en_US.UTF-8', 'ADDRFAM': '', '**IF_OVS_TYPE**': 'OVSBridge', 'IFACE': 'eno1.100', 'JOURNAL_STREAM': '9:29498964', 'SHLVL': '1', 'IF_NETMASK': '255.255.255.0', 'IF_ADDRESS': '10.59.100.231', 'LOGICAL': 'eno1.100', 'IF_GATEWAY': '10.59.100.1', 'PWD': '/', 'MODE': 'start', '**IF_TESTVARIABLE2**': 'test', 'IF_TESTVARIABLE1': 'test', 'PHASE': 'pre-up', 'PATH': '/sbin:/bin', 'METHOD': '', '_': '/sbin/ifreload', 'INVOCATION_ID': '5ffcea837bc64759bd0c171b70e22cc2'}

As you can see,
IF_OVS_TYPE env var from vmbr100, is also called in eno1, eno1.100 (which is doing crap with openvswitch pre-up script).
other testvariable1/2 env vars are also keeped betweend interfaces.

this is coming from ifupdownmain.py

    def generate_running_env(self, ifaceobj, op):
        """ Generates a dictionary with env variables required for
        an interface. Used to support script execution for interfaces.
        """

        cenv = None
        iface_env = ifaceobj.get_env()
        if iface_env:
            **cenv = os.environ
            if cenv:
                cenv.update(iface_env)**
            else:
                cenv = iface_env
        else:
            cenv = {}
        cenv['MODE'] = self._compat_conv_op_to_mode(op)
        cenv['PHASE'] = op

        return cenv

then is scheduler.py

    if ifupdownobj.config.get('addon_scripts_support', '0') == '1':
            # execute /etc/network/ scripts 
            os.environ['IFACE'] = ifaceobj.name if ifaceobj.name else ''
            os.environ['LOGICAL'] = ifaceobj.name if ifaceobj.name else ''
            os.environ['METHOD'] = ifaceobj.addr_method if ifaceobj.addr_method else ''
            os.environ['ADDRFAM'] = ifaceobj.addr_family if ifaceobj.addr_family else ''
            for mname in ifupdownobj.script_ops.get(op, []):
                ifupdownobj.logger.debug('%s: %s : running script %s %s'
                    %(ifacename, op, mname))
                try:
                    utils.exec_command(mname, env=cenv)

Any reason to keep env vars between interfaces ?

ifupdown2 will run all scripts regardless of the execute bit being set

Hello,

I believe I've found a point where ifupdown2 behaviour significantly diverges from ifupdown on debian stretch. I'm using ifupdown2-1.2.1 and I needed to replace the stock /etc/network/if-up.d/openssh-server script with a custom version of it, so I used dpkg-divert to rename the original file and then removed the execute bit from the diverted version.

Original ifupdown uses run-parts which supposedly doesn't run non-executable files in the directory. However, ifupdown2 doesn't seem to make this distinction. Is it possible to make ifupdown2 behave similarly to ifupdown in this respect?

Open vSwitch

This is somewhat related to issues #6 and #30.

in a debian stretch installation:

# uname -a
Linux core02.d01.bm1 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64 GNU/Linux

I have /etc/network/interfaces, amongst other stuff, the following definitions, a bridge, an internal port, and an external port:

# description: main bridge
#auto ovsbr0
allow-ovs ovsbr0
iface ovsbr0
  ovs_type OVSBridge
  ovs_ports enp0s20f3 vlan3510
  pre-up    ip link set dev ovsbr0 up
  post-down ip link set dev ovsbr0 down

# description: et37.leaf02.a18.bm1
allow-ovsbr0 enp0s20f3
iface enp0s20f3
  mtu 9216
  ovs_bridge ovsbr0
  ovs_type OVSPort
  ovs_options trunks=3510
#  pre-up    ip link set dev enp0s20f3 up
#  post-down ip link set dev enp0s20f3 down

# description: enp2s0.wan03.d01.bm1.qvs.bm
# description: vlan3510.enp0s20f3
allow-ovsbr0 vlan3510
iface vlan3510
  address 10.35.10.1/29
  ovs_bridge ovsbr0
  ovs_type OVSIntPort
  ovs_options tag=3510
#  pre-up    ip link set dev vlan3510 up
#  post-down ip link set dev vlan3510 down

During boot, I get the following in /var/log/daemon.log:

Feb  6 14:33:58 core02 networking[397]: info: processing interfaces file /etc/network/interfaces
Feb  6 14:33:58 core02 networking[397]: debug: processing sourced line ..'source /etc/network/interfaces.d/*'
Feb  6 14:33:58 core02 networking[397]: debug: populate_dependency_info: deleting blacklisted interface ovsbr0
Feb  6 14:33:58 core02 networking[397]: debug: populate_dependency_info: deleting blacklisted interface enp0s20f3
Feb  6 14:33:58 core02 networking[397]: debug: populate_dependency_info: deleting blacklisted interface vlan3510
Feb  6 14:33:58 core02 networking[397]: debug: scheduling '['pre-up', 'up', 'post-up']' for ['lo', 'enp2s0', 'enp4s0f2', 'enp3s0f0', 'enp4s0f0', 'enp1s0', 'enp4s0f1', 'enp0s20f1', 'enp0s20f0', 'enp0s20f2']
Feb  6 14:33:58 core02 networking[397]: debug: dependency graph {
Feb  6 14:33:58 core02 networking[397]: #011lo : []
Feb  6 14:33:58 core02 networking[397]: #011enp2s0 : []
Feb  6 14:33:58 core02 networking[397]: #011enp4s0f2 : []
Feb  6 14:33:58 core02 networking[397]: #011enp3s0f0 : []
Feb  6 14:33:58 core02 networking[397]: #011enp4s0f0 : []
Feb  6 14:33:58 core02 networking[397]: #011enp1s0 : []
Feb  6 14:33:58 core02 networking[397]: #011enp4s0f1 : []
Feb  6 14:33:58 core02 networking[397]: #011enp0s20f1 : []
Feb  6 14:33:58 core02 networking[397]: #011enp0s20f0 : []
Feb  6 14:33:58 core02 networking[397]: #011enp0s20f2 : []
Feb  6 14:33:58 core02 networking[397]: }
Feb  6 14:33:58 core02 networking[397]: debug: graph roots (interfaces that dont have dependents): ['lo', 'enp2s0', 'enp4s0f2', 'enp3s0f0', 'enp4s0f0', 'enp1s0', 'enp4s0f1', 'enp0s20f1', 'enp0s20f0', 'enp0s20f2']

ovs should be started somewhere, even via pre-up

# ls -alt /etc/network/if-pre-up.d/
total 12
drwxr-xr-x 8 root root 4096 Feb  6 14:33 ..
drwxr-xr-x 2 root root 4096 Jan 31 11:38 .
lrwxrwxrwx 1 root root   42 Aug  4  2017 openvswitch -> /usr/share/openvswitch/scripts/ifupdown.sh
lrwxrwxrwx 1 root root   29 Jul  2  2017 bridge -> /lib/bridge-utils/ifupdown.sh
-rwxr-xr-x 1 root root  344 Jun 30  2016 ethtool

but the service isn't started until later:

Feb  6 14:34:04 core02 openvswitch-switch[660]: Inserting openvswitch module.
Feb  6 14:34:04 core02 openvswitch-switch[660]: Starting ovsdb-server.
Feb  6 14:34:05 core02 openvswitch-switch[660]: Configuring Open vSwitch system IDs.
Feb  6 14:34:05 core02 openvswitch-switch[660]: Starting ovs-vswitchd.
Feb  6 14:34:05 core02 openvswitch-switch[660]: Enabling remote OVSDB managers.
Feb  6 14:34:05 core02 openvswitch-switch[660]: '--allow' option is mutually exclusive with interface list and '-a'

and the interfaces are created afterwords:

2018-02-06T18:34:05.177Z|00029|bridge|INFO|bridge ovsbr0: added interface vlan3510 on port 1
2018-02-06T18:34:05.180Z|00030|bridge|INFO|bridge ovsbr0: added interface ovsbr0 on port 65534
2018-02-06T18:34:05.181Z|00031|bridge|INFO|bridge ovsbr0: added interface enp0s20f3 on port 2

And therefore the interrfaces don't come up during the pre-up processing from 14:33:58 time frame:

# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

5: enp0s20f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop master ovs-system state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:90:0b:49:96:0d brd ff:ff:ff:ff:ff:ff
16: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 16:3f:3e:85:e0:63 brd ff:ff:ff:ff:ff:ff
17: vlan3510: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 0a:88:72:7b:f0:24 brd ff:ff:ff:ff:ff:ff
18: ovsbr0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:90:0b:49:96:0d brd ff:ff:ff:ff:ff:ff

So the question: if the blacklist can be removed, then then the interfaces should start with the main ifupdown2 processing of /etc/network/interfaces.

Is is the special 'allow-ovs' which is causing the block? This is part of the definition from open-vswitch:

https://github.com/openvswitch/ovs/blob/master/debian/openvswitch-switch.README.Debian

Does one of the ifupdown 2 configuration items clear this block?

mako template : include variable from other file ?

Hi, I'm trying to generate vxlan from a variable located in another file,
I don't know if it's possible currently ?

something like

/etc/network/vlan.list

<% vxlan_range = [200,220,260] %>

/etc/network/interfaces

`
<%include file="vlan.list"/>

% for v in vxlan_range:
auto vxlan${v}
iface vxlan${v} inet manual
vxlan-id ${v}
...
% endfor
`

ifup -a

error: /etc/network/interfaces: failed to render template (Cant locate template for uri u'./vlan.list'). Continue without template rendering ...

Multicast VXLAN

Are multicast VXLANs supported?

(ip link add $IFACE type vxlan id 10 group 239.1.1.1 dev ens18)

If no, support for it would be great :-)

/bin/bridge path instead /sbin/bridge

I'm tryning ifupdown2 on debian jessie, and it seem that iproute2 package have /sbin/brige path,

but ifupdown2 use /bin/bridge.
(I don't use cumulus linux, maybe it's using a different path)

def bridge_port_vids_get(self, bridgeportname):
617 self.exec_command('/bin/bridge vlan show %s' %bridgeportname)
618 bridgeout = self.exec_command('/bin/bridge vlan show dev %s'
619 %bridgeportname)

lo assigned ip-address not active

Linux server 4.15.0-22-generic #24-Ubuntu SMP Wed May 16 12:15:17 UTC 2018 x86_64
Python 2.7.15rc1
Python 3.6.5
iproute2 4.15.0-2ubuntu1
ifupdown2 1.0~git20170314-1
ifupdown removed


Having set an ip-address for the lo iface the ip-address is ping-able but otherwise not active in a sense that services like ssh cannot be bound/tied to it albeit it showing

root@server:~# ip a s lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 172.23.120.98/32 scope global lo
valid_lft forever preferred_lft forever


auto lo
iface lo inet loopback
	address 172.23.120.98/32
	scope host

Do I suffer from a misconception eventually? Trying to bind the webmin server gui to the assigned ip returns

Failed to change address : The IP address 172.23.120.98 is not active on this system, and so cannot be used

Noticable though is that the set scope host appears as not applied

000resolvconf and $ADDRFAM

Does ifupdown2 pass $ADDRFAM to the command scripts?

I have found that my /etc/resolv.conf is not being updated by resolvconf due to a missing $ADDRFAM that /etc/network/if-up.d/000resolvconf needs...

To debug, I modified 000resolvconf as such:

#!/bin/sh -x
exec 1>>/tmp/resolvconf.log 2>&1
echo foo
set | sort
echo bar

case "$ADDRFAM" in
  inet|inet6) : ;;
  *) exit 0 ;;
esac
[...]

It stops dead every time at the case statement's 'exit 0'

#====
[...]
auto lzfs69
iface lzfs69 inet static
  vlan-raw-device bond0
  vlan-id 69
  address 10.2.1.22/16
  dns-search example.com
  dns-nameservers 10.2.6.9 10.2.6.10
#====

I am running:
Ubuntu-16.04
https://launchpad.net/ubuntu/yakkety/amd64/ifupdown2/1.0~git20160525-1

I'm using the latest debian package as I had the same problem as referenced in: #10

Thank you for writing ifupdown2 and making my life easier working with bonded (LACP) + vlan interfaces... I was losing my sanity trying to get it to work reliably with the stock ifupdown... :(

pppoe Interface

Is it possible to bring up a pppoe Interface on a cumulus Linux switch to terminate a DSL Line Directly?

gretap tunnel cann't be created

When creating a gretap interface on Debian 9 with kernel 4.18.0-0.bpo.1-amd64 with ifupdown from branch master-next and debian-prep2 i get the following error:

warning: cmd 'ip tunnel add tap0 mode gretap local 78.46.193.234 remote 195.201.223.194 dev eth0 ttl 64' failed: returned 255 (Unknown tunnel mode "gretap")

The ip command would be right for a gre tunnel, but for a gretap tunnel the command should look like this ip link add tap0 type gretap local 78.46.193.234 remote 195.201.223.194 dev eth0 ttl 64

can't update an vxlan interface with vxlan-local-tunnelip

Hi,

auto vxlan4
iface vxlan4
        vxlan-id 4
        vxlan-local-tunnelip 10.59.100.231

ifup vxlan4 -v

info: vxlan4: running ops ...
info: netlink: ip link show
info: netlink: ip addr show
info: vxlan4: netlink: ip link add vxlan4 type vxlan id 4 dstport 4789 local 10.59.100.231 noremote
info: vxlan4: netlink: ip link set dev vxlan4 up
info: reading '/proc/sys/net/mpls/conf/vxlan4/input'
info: executing /sbin/sysctl net.mpls.conf.vxlan4.input=0
info: reading '/proc/sys/net/ipv4/conf/vxlan4/forwarding'
info: executing /sbin/sysctl net.ipv4.conf.vxlan4.forwarding=0
info: reading '/proc/sys/net/ipv6/conf/vxlan4/forwarding'
info: executing /sbin/sysctl net.ipv6.conf.vxlan4.forwarding=0
info: executing /bin/ip -force -batch - [link set dev vxlan4 mtu 1500

then, again to update (no config change):

ifup vxlan4 -v

info: vxlan4: running ops ...
info: netlink: ip link show
info: netlink: ip addr show
info: vxlan4: netlink: ip link add vxlan4 type vxlan id 4 dstport 4789 local 10.59.100.231 ageing 300 noremote
info: executing /bin/ip link set dev vxlan4 type vxlan dstport 4789 ageing 300 local 10.59.100.231
warning: vxlan4: vxlan add/set failed: cmd '/bin/ip link set dev vxlan4 type vxlan dstport 4789 ageing 300 local 10.59.100.231' failed: returned 2 (RTNETLINK answers: Operation not supported
)
info: vxlan4: netlink: ip link set dev vxlan4 up

then with changing vxlan-local-tunnelip to 10.59.100.232

info: vxlan4: running ops ...
info: netlink: ip link show
info: netlink: ip addr show
info: vxlan4: netlink: ip link add vxlan4 type vxlan id 4 dstport 4789 local 10.59.100.232 ageing 300 noremote
info: executing /bin/ip link set dev vxlan4 type vxlan dstport 4789 ageing 300 local 10.59.100.232
warning: vxlan4: vxlan add/set failed: cmd '/bin/ip link set dev vxlan4 type vxlan dstport 4789 ageing 300 local 10.59.100.232' failed: returned 2 (RTNETLINK answers: Operation not supported
)
info: vxlan4: netlink: ip link set dev vxlan4 up

(debian 9, kernel 4.15, iproute 4.15, cl3u18 tag)

error: 'NoneType' object has no attribute '__getitem__'

I get the following error using ifreload -a:

(zrh2)root@vms1:~# ifreload -a
error: 'NoneType' object has no attribute '__getitem__'

Config:

auto lo
iface lo

auto vmbr0
iface vmbr0
  alias Core: External Switch
  bridge-vlan-aware yes
  bridge-vids 400 401
  bridge-ports eno7 eno8

auto vmbr1
iface vmbr1
  alias Core: Core Switch
  bridge-vlan-aware yes
  bridge-vids 427

auto vmbr2
iface vmbr2
  alias Core: Access Switch
  bridge-vlan-aware yes
  bridge-vids 450 451

auto eno6
iface eno6
  alias Core: Mgmt
  address v4/29
  address v6/29
  gateway v4gw
  gateway v6gw

auto eno7
iface eno7
  alias Core: XYZ
  bridge-access 401
  link-speed 1000
  link-duplex full
  link-autoneg off

auto eno8
iface eno8
  alias Core: XYZ
  bridge-access 400
  link-speed 1000
  link-duplex full
  link-autoneg off

Log:

info: vmbr0: processing bridge config for port eno8
info: vmbr0: processing bridge config for port eno7
info: eno7: netlink: ip link set dev eno7 up
error: 'NoneType' object has no attribute '__getitem__'
info: vmbr0: netlink: ip link set dev vmbr0 up

ifquery parses files under /etc/network/interfaces.d/

Repro steps

  1. Create /etc/network/interfaces file with below contents
auto eth0
iface eth0 inet static
  address 10.6.16.216
  netmask 255.255.255.0
  gateway 10.6.16.1
  dns-nameservers 1.1.1.1
  1. Have /etc/network/interfaces.d/eth0 file with below contents
auto eth0
iface eth0 inet dhcp
  1. Run ifquery -x eth0

Expected:

auto eth0
iface eth0 inet static
  address 10.6.16.216
  netmask 255.255.255.0
  gateway 10.6.16.1
  dns-nameservers 1.1.1.1

Actual:

auto eth0
iface eth0 inet static
  address 10.6.16.216
  netmask 255.255.255.0
  gateway 10.6.16.1
  dns-nameservers 1.1.1.1

auto eth0
iface eth0 inet dhcp

ifquery shouldn't process /etc/network/interfaces.d/eth0 as that directory is not sourced from /etc/network/interfaces file. The ifreload, ifup, ifdown in above setup use static config and not dhcp config - so ifquery is not consistent.

Version info

# ifquery -V
ifupdown2:ifquery 20170314
# uname -a
Linux leaf-1 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-14) x86_64 GNU/Linux

iproute2 groups

I'm using iproute2 groups for firewall purposes. At the moment I need to set the group with an up command.

ip link set $IFACE group internal
It would be very useful if ifupdown2 would have such feature, like

auto eno7
iface eno7
  address 192.0.2.1/24
  ifgroup internal

mstpd upstream treeprio

Hi,

mstpd upstream uses a new range for:

mstpctl-treeportprio
and
mstpctl-treeprio

The range is 0 - 15.

ifupdown2 uses the old values.

Best
Sven

error in ifreload -a

I have installed apt-get install ifupdown2

The OS version is :

cat /proc/version
Linux version 4.4.36-nn3-server (root@ubuntu) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #nn3 SMP PREEMPT Thu Apr 13 08:23:18 PDT 2017

cat /etc/network/interfaces

This file describes the network interfaces available on your system

and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

The loopback network interface

auto lo
iface lo inet loopback

The primary network interface

auto ens160
iface ens160 inet dhcp

This is an autoconfigured IPv6 interface

iface ens160 inet6 auto

auto ens192
iface ens192 inet static
address 192.0.2.37
netmask 255.255.255.252

Getting error with ifreload command

ifreload -a
warning: /etc/network/interfaces: cannot find source file /etc/network/interfaces.d/*
error: /etc/network/interfaces: iface ens160: unsupported address method 'auto'

How to resolve the issue

VXLAN error

Config:

auto vxlan10
iface vxlan10
  mtu 1400
  vxlan-id 10
  vxlan-remoteip 1.2.3.4
  address 2001:db8:1::1/64
  up ip link set $IFACE group customer

First ifreload -a works, from the second one:

(zrh1)root@cr1:~# ifreload -a
error: netlink: vxlan10: cannot create vxlan 10: Operation failed with 'Operation not supported'

qinq (802.1ad) support ?

Hi,

is it planned to add qinq (802.1ad) support ?

It should be easy,

for interface :
ip link add link eth0 name eth0.10 type vlan id 10 protocol 802.1ad

for vlanaware bridge:
echo 0x88a8 > /sys/class/net/br0/bridge/vlan_protocol

ifreload does not fall back to default stp priority when configured value is deleted

I set mstpctl-treeprio 4096 on a bridge, which made it the root bridge in my topology. I verified the priority by looking at the stp packets sent

tshark -t u -r stp.290.4096.pcap
  1 08:47:31.007457 BrocadeC_7c:93:00 -> PVST+        STP 70 RST. Root = 4096/0/44:38:39:ff:00:01  Cost = 40000  Port = 0x8001

Then I deleted the mstpctl-treeprio line from /etc/network/interfaces, ran ifreload -a and looked at tcpdump again. I found that 4096 is still the bridge prio and the intended topology change did not happen (because the prio was not changed)

tshark -t u -r stp.290.noprio.pcap
  1 08:48:17.007568 BrocadeC_7c:93:00 -> PVST+        STP 70 RST. Root = 4096/0/44:38:39:ff:00:01  Cost = 40000  Port = 0x8001

If I configure a different priority (say 32768), and run ifreload, the configuration is adapted (and a topology change happens, so another device on the network (with prio 8192 in this case) becomes root bridge and this is the stp packet I see in tcpdump)

tshark -t u -r stp.290.32768.pcap
  1 08:55:27.008696 BrocadeC_7c:93:00 -> PVST+        STP 70 RST. Root = 8192/0/00:0c:db:7c:93:00  Cost = 0  Port = 0x8001

I think it is reasonable to expect ifreload to set the default value for stp prio when prio is not explicitly configued.

MTU value after ifreload

If I set the MTU to 9216 and do a ifreload -a it looks fine. After removing the line and ifreload -a, the MTU remains on 9216. I think it should be set back to 1500.

link-kind issues leading to ifquery errors

Hi @julienfortin and @roopa-prabhu

While hunting down all red flags in our Icinga2, I stumbled across a unhappy ifupdown2 (checked by https://exchange.icinga.com/barbarossatm/check_ifupdown2 fwiw :-)). The problem is an veth interface which is assigned into a VRF:

lnx02.pad.in.ffho.net:~# ifquery -c veth_ext2int
auto veth_ext2int
iface veth_ext2int                                                [[FAIL]]
	link-type veth                                            [[FAIL]]
	vrf vrf_external                                          [[ OK ]]
	mtu 1500                                                  [[ OK ]]
        address [...]

which looks like this in iproute

lnx02.pad.in.ffho.net:/usr/share/ifupdown2/ifupdownaddons# ip -d link show dev veth_ext2int
12: veth_ext2int@veth_int2ext: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vrf_external state UP mode DEFAULT group default qlen 1000
    link/ether 4e:c1:85:d2:d3:6a brd ff:ff:ff:ff:ff:ff promiscuity 0 
    veth 
    vrf_slave table 1023 addrgenmode eui64 numtxqueues 1 numrxqueues 1 

Wondering why the link-type is bad I dug through the code and found this within ifupdownaddons/iproute2.py:

elif citems[i] == 'veth':
    linkattrs['kind'] = 'veth'
[...]
elif citems[i] == 'vrf_slave':
    linkattrs['kind'] = 'vrf_slave'

If I comment out the vrf_slave stanza, ifquery is happy.

Now I'm wondering why a vrf_slave interface is an own link-kind (which is odd in my mind), which only seems to be used within addons/vrf.py:

def _query_running(self, ifaceobjrunning, ifaceobj_getfunc=None):
[...]
elif kind == 'vrf_slave':
    vrf = self.ipcmd.link_get_master(ifaceobjrunning.name)
    if vrf:
        ifaceobjrunning.update_config('vrf', vrf)

As this breaks config checking, I'd think it might be worth giving a thought to redesign this part?

What do you think?

Best
Max

Will break virt-manager networking for virtual machines

When virt-manager is started it creates (for instance):
virbr0 8000.52540082495f yes virbr0-nic

Subsequently, starting up an existing Debian virtual machine will spur the creation of:
vnet0

But vnet0 (routine) does not expect to find /sbin/ifupdown;
it expects to find /sbin/ifup and /sbin/ifdown (as logged in /var/log/syslog).
Consequently, the booted Debian virtual machine will not be assigned an IP and cannot communicate with peers or outside its contained environment.

I had a couple of Debian instances to trace the issue: one with your ifupdown2 utility and the other one with ifupdown from DEB repositories.

Best Professional Regards.

Metztli IT

Debian, service networking stop/start/restart

Hi,
I have build packages for Debian 7.6 and installed it.
When server boots or "/usr/sbin/service networking stop/start/restart" i have an error :

root@debian-vm:~# service networking restart
[....] Reconfiguring network interfaces...error: no ifaces found matching given allow lists (interfaces were probably never up)
warning: unable to set template lookup path /etc/network/ifupdown2/templates ('NoneType' object is not callable)
error: no ifaces found matching given allow lists

If i comment lines about templates in "/etc/network/ifupdown2/ifupdown2.conf", this is the error i get :

root@debian-vm:~# service networking restart
[....] Reconfiguring network interfaces...error: no ifaces found matching given allow lists (interfaces were probably never up)

If i do manual start (ifup eth0) it is OK.
My /etc/network/interfaces has only lo and eth0 (dhcp).

Could you point me to what i've missed in conf ?

Thanks,
Thomas

Vlan devices with vlan1234 schema don't work

Hi,

thanks for your awesome tool and making it Open Source! I really like your ideas!

While playing aroud with ifupdown2 last night, I stumbled across a problem with a vlan interface named after the vlan1234 schema. The addon help instructs the user to specify a vlan-raw-device and a vlan-id to the interface for this to work.

So I initially ended up doing this (I know the eth2.1005 isn't clever, it's a test :))

auto eth0
iface eth0 inet static
        address 172.30.1.3
        netmask 24

auto eth2.1005
iface eth2.1005
        address 10.132.253.11/31
        address fdca:ffee:ff12:fe06::1/64

auto bond0
iface bond0 inet manual
        bond-slaves eth1 eth2
        bond-mode 802.3ad
        bond-min-links 1
        bond-xmit-hash-policy layer2+3

auto vlan1007
iface vlan1007
        vlan-raw-device bond0
        vlan-id 1007
        #
        address 10.132.253.15/31

This works great for everything but the vlan1007 device which can't be configured. If I add a vlan-id statement to the last block, I end up with:

root@bbr-upb:~# ifup -d vlan1007
[...]
Traceback (most recent call last):
  File "/sbin/ifup", line 496, in <module>
    main(sys.argv)
  File "/sbin/ifup", line 474, in main
    handlers.get(op)(args)
  File "/sbin/ifup", line 62, in run_up
    skipupperifaces=args.skipupperifaces)
  File "/usr/share/ifupdown2/ifupdown/ifupdownmain.py", line 938, in up
    self.populate_dependency_info(ops)
  File "/usr/share/ifupdown2/ifupdown/ifupdownmain.py", line 509, in populate_dependency_info
    dlist, ops)
  File "/usr/share/ifupdown2/ifupdown/ifupdownmain.py", line 435, in preprocess_dependency_list
    if self.is_iface_builtin_byname(d):
  File "/usr/share/ifupdown2/ifupdown/ifupdownmain.py", line 363, in is_iface_builtin_byname
    return '.' in ifacename
TypeError: argument of type 'NoneType' is not iterable

Digging through the code I found out that this happens due to a [None] list of depended interfaces somewhere along the path for interface 1007. To my surprise there were two interfaces, one vlan1007 and one 1007.

Removing the vlan-id will make the error and interface 1007 go away, but vlan1007 still can't be configured because the interface isn't there and isn't created (failing silenty with any visible error, only observeable with -d).

Digging further for the root cause revealed that the vlan-raw-device line is ignored in the network interface parser (networkinterfaces.py) by the following block which stops the parser (around line 240):

def parse_iface(self, lines, cur_idx, lineno, ifaceobj):
[...]
    attrs = re.split(self._ws_split_regex, l, 1)
    if self._is_keyword(attrs[0]):
        line_idx -= 1
        break

because (in the same file, further below)

network_elems = { 'source'      : process_source,
                  'allow'      : process_allow,
                  'auto'        : process_auto,
                  'iface'       : process_iface,
                  'vlan'       : process_vlan}

def _is_keyword(self, str):
    # The additional split here is for allow- keyword
    tmp_str = str.split('-')[0]
    if tmp_str in self.network_elems.keys():
        return 1
    return 0

matches on vlan-raw-device :-/

Adding

    if str == 'vlan-raw-device':
        return 0

to _is_keyword() fixes this issue for me, but I don't know what it might break or what the reason for doing this was/is. There seems to be another issue, though as ifquery -c vlan1007 shows some FAIL lines:

root@bbr-upb:~# ifquery -c vlan1007
auto vlan1007
iface vlan1007                                                      [fail]
    vlan-raw-device                                             [fail]
    vlan-id                                                     [pass]
    address 10.132.253.15/31                                    [pass]

I hope this report helps identifying and fixing the underlying problem. I'd be happy to test any patches if requested.

Thanks!
Max

Static Routes

Hi,

I am wondering if there is a way to configure static routes with ifupdown2, besides the well known post-up|post-down ip route ....

My wish would be something like:

auto eth0
iface eth0 inet static
address 192.168.100.1/24
route 10.10.10.0/24 192.168.100.13

It should recognize changes within the config and apply them (eg. with ifreload -a) to the running config.

For example: If you have applied the config above you would have a static route that looks like this:

10.10.10.0/24 via 192.168.100.13 dev eth0 src 192.168.100.1

If you now change the config to this:

auto eth0
iface eth0 inet static
address 192.168.100.1/24
route 10.10.10.0/24 192.168.100.14

and do a ifreload -a the route above vanishes and you get a new one like this:

10.10.10.0/24 via 192.168.100.14 dev eth0 src 192.168.100.1

And in case you remove the route entry from the config the route will be fully removed.

Best Regards

Jan

Boot problems on Debian

Hello,

using ifupdown2 on Debian (Stretch and Jessie) I needed to add override to provided systemd service in order to pull in network.target. This is normally done by Debian's default networking service and nothing else do it. So some services (like ssh) crashing on binding, because they are dependent (After=, not Wants=) on network.target which is not started and therefore they are attempted to start before network is available.

Also the start up script doesn't wait for DAD, systemd starts services depending on usable interfaces right away and they fail to bind, because addresses are in tentative state. I solved it dirty at the moment: added ExecStartPost=/bin/sleep 2 to my overrides, but I love to see more elegant option. Maybe adding an interface option so ifup wait for DAD could do the trick.

PS. I basically created the drop-in after the Debian default networking.service file, but I can PR if you want.

Order of interfaces in e/n/i

Hi all, running ifupdown2 on an Ubuntu 16.04 LXC container on an 18.04 host system. The ordering of how I define interfaces in e/n/i, seems to affect which interfaces actually are brought up. Should this be happening in this case with ifupdown2?

The following configuration doesn't work,

allow-hotplug eth0
iface eth0 inet manual

#LAN 1
auto eth0.10
iface eth0.10 inet static
    address 172.28.10.1
    netmask 255.255.255.0

#WAN
auto eth0.20
allow-hotplug eth0.20
iface eth0.20 inet dhcp

#LAN 2
auto eth0.40
iface eth0.40 inet static
    address 172.28.40.1
    netmask 255.255.255.0

#LAN 3
auto eth0.50
iface eth0.50 inet static
    address 172.28.50.1
    netmask 255.255.255.0

#LAN 4
auto eth0.60
iface eth0.60 inet static
    address 172.28.60.1
    netmask 255.255.252.0

only two interfaces are brought up:

ubuntu:~$ lxc list
+-------+---------+--------------------------------+------+------------+-----------+
| NAME  |  STATE  |              IPV4              | IPV6 |    TYPE    | SNAPSHOTS |
+-------+---------+--------------------------------+------+------------+-----------+
| first | RUNNING | 172.28.10.1 (eth0.10)          |      | PERSISTENT | 0         |
|       |         | 10.0.3.15 (eth0.20)            |      |            |           |
+-------+---------+--------------------------------+------+------------+-----------+

However, changing the order to:

allow-hotplug eth0
iface eth0 inet manual

#LAN 1
auto eth0.10
iface eth0.10 inet static
    address 172.28.10.1
    netmask 255.255.255.0

#LAN 2
auto eth0.40
iface eth0.40 inet static
    address 172.28.40.1
    netmask 255.255.255.0

#LAN 3
auto eth0.50
iface eth0.50 inet static
    address 172.28.50.1
    netmask 255.255.255.0

#LAN 4
auto eth0.60
iface eth0.60 inet static
    address 172.28.60.1
    netmask 255.255.252.0

#WAN
auto eth0.20
allow-hotplug eth0.20
iface eth0.20 inet dhcp

Brings up all the interfaces:

ubuntu:~$ lxc list
+-------+---------+--------------------------------+------+------------+-----------+
| NAME  |  STATE  |              IPV4              | IPV6 |    TYPE    | SNAPSHOTS |
+-------+---------+--------------------------------+------+------------+-----------+
| first | RUNNING | 172.28.60.1 (eth0.60)          |      | PERSISTENT | 0         |
|       |         | 172.28.50.1 (eth0.50)          |      |            |           |
|       |         | 172.28.40.1 (eth0.40)          |      |            |           |
|       |         | 172.28.10.1 (eth0.10)          |      |            |           |
|       |         | 10.0.3.15 (eth0.20)            |      |            |           |
+-------+---------+--------------------------------+------+------------+-----------+

Documentation: how do I run it?

The install instructions say use ./build.sh but there is no such file.

I installed it by running python setup.py install.

I can't see now how to run it? What file do I need to run after installation?

thanks

IPv6 disabled on bridge iface if any VXLAN port

ifupdown2 release 1.0~git20161101-1 added feature:

  • New. Enabled: bridge: disabling ipv6 on bridge if any VXLAN port

This however blocks our use-case where we have anycast ipv6 gateway active on hypervisor for VM's attached to this bridge. As a workaround we applied separate "up" rules. Please re-evaluate this feature.

non-working:

auto br-vlan260
iface br-vlan260
   bridge-ports vxlan10260
   bridge-stp off
   bridge-fd 0
   ip6-forward on
   ip-forward on
   address 2001:7b8:2:3::bbbb/64
   gateway 2001:7b8:2:3::1

working:

auto br-vlan260
iface br-vlan260
   bridge-ports vxlan10260
   bridge-stp off
   bridge-fd 0
   ip6-forward on
   ip-forward on
   up echo 0 > /proc/sys/net/ipv6/conf/br-vlan260/disable_ipv6
   up ip -6 addr add 2001:7b8:2:3::bbbb/64 dev br-vlan260
   up ip -6 route add default via 2001:7b8:2:3::1

feature request: bonding support for numeric modes

ifenslave-2.6 supports numeric bond modes (e.g. mode 1 is active-backup.

Configuring a numeric bond mode under ifupdown2:all=1.0~git20151029-1 results in an error:

root@sheriff:~# ifquery bond0
auto bond0
iface bond0
        bond-slaves eth0 wlan0
        bond-mode 1
root@sheriff:~# ifup bond0
warning: bond0: invalid value 1 for attr bond-mode. Valid values are ['balance-rr', 'active-backup', 'balance-xor', 'broadcast', '802.3ad', 'balance-tlb', 'balance-alb']

sysvinit initscript missing

Hello,

as long as debian leaves the choice between init systems, it would be great to support them.
For sysvinit, this requires an init script.
Even the existing /usr/share/ifupdown2/sbin/start-networking would work when placed/symlinked in /etc/init.d/ trivially amended by the tags the the networking script of ifupdown:

### BEGIN INIT INFO
# Provides:          networking ifupdown
# Required-Start:    mountkernfs $local_fs urandom
# Required-Stop:     $local_fs
# Default-Start:     S
# Default-Stop:      0 6
# Short-Description: Raise network interfaces.
# Description:       Prepare /run/network directory, ifstate file and raise network interfaces, or take them down.
### END INIT INFO

Thanks for considering.

Bye,

Joerg

feature request: bonding support bond-primary

ifenslave-2.6 supports bond-primary for specifying the primary member of an active-backup bond.

ifupdown2:all=1.0~git20151029-1 does not currently respect bond-primary. This can be worked around with an up statement:

auto bond0
iface bond0 inet dhcp
        bond-slaves eth0 wlan0
        bond-mode active-backup
        up echo eth0 > /sys/class/net/$IFACE/bonding/primary

[bug report] iface gateway negelected

Linux server 4.15.0-22-generic #24-Ubuntu SMP Wed May 16 12:15:17 UTC 2018 x86_64
Python 2.7.15rc1
Python 3.6.5
iproute2 4.15.0-2ubuntu1
ifupdown2 1.0~git20170314-1
ifupdown removed


Not sure whether it might be the kernel or python or perhaps a combination of those but unfortunately ifupdown2 is neglecting the iface's (ens3) gateway, i.e. whenever the iface is brought up the gateway is gone.

There is one error though I am not sure whether/how it could play into the matter. ipv6 is disabled in the kernel and the error thus a logical consequence

info: executing /sbin/ip -6 rule show
warning: vrf: cache v6: cmd '/sbin/ip -6 rule show' failed: returned 255 (RNETLINK answers: Address family not supported by protocol Dump terminated)


The issue does not occur with ifupdown

Test Issue

This is not an actual issue.
This is just a test of the issue notification system.

VXLAN add support for netlink ipv6 attributes (workaround available) (old title: VXLAN Creation Error)

My goal is to replace ip link add $IFACE type vxlan id 1234 group ff02::15c dev ens6 with the following config, which leads into an error with netlink.

auto ens6
iface ens6
        mtu 9000
        accept_ra 0
        autoconf 0
        dad-attempts 0

auto ffm_city-tp
iface ffm_city-tp
        vxlan-id 1234
        mtu 1312
        vxlan-svcnodeip ff02::15c
        vxlan-physdev ens6

But I get this error and I also think that the "info: " output is incorrect, with printing out remote while using group everywhere else.

info: ffm_city-tp: netlink: ip link add ffm_city-tp type vxlan id 1234 dstport 4789 remote ff02::15c dev ens6
debug: TXed  RTM_GETLINK, pid 9608, seq 1, 40 bytes
debug: Attribute 40 is not defined in Link.attribute_to_class, assuming AttributeGeneric
debug: Attribute 41 is not defined in Link.attribute_to_class, assuming AttributeGeneric
debug: Attribute 43 is not defined in Link.attribute_to_class, assuming AttributeGeneric
debug: Add support for decoding IFLA_AF_SPEC sub-attribute type UNKNOWN (10), length 608, padded to 608
debug: RXed  NLMSG_ERROR, pid 9608, seq 1, 36 bytes code NLE_SUCCESS...this is an ACK
error: netlink: ffm_city-tp: cannot create vxlan 1234: ff02::15c

I assume that it is connected to the use of IPv6 Multicast Groups.

IPv6 token support

Hi,

it would be nice if ifupdown2 could add support for IPv6Tokens like systemd-networkd.
https://systemd.network/systemd.network.html#IPv6Token=

The idea is, that in environments that have unstable prefixes (like cpe's with dhcpv6-pd), devices will always roll a stable, configurable interface identifier when configured using slaac. This helps establishing firewall rules for global ips of clients in my network.

Thanks!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.