Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPv6 Network states is incomplete #38672

Closed
valentin2105 opened this issue Jan 11, 2017 · 9 comments

Comments

Projects
None yet
5 participants
@valentin2105
Copy link

commented Jan 11, 2017

Description of Issue/Question

I'm trying to deploy IPv6 Addresses to my minions, but following documentation, it doesn't work.

I have looked at states/modules in develop branch about networking and debian.IP but can't be able to find some usefull thinks for v6.

Setup

networking.sls :

lo:
  network.managed:
    - name: lo
    - type: eth
    - onboot: yes
    - userctl: no
    - ipv6_autoconf: no
    - enable_ipv6: true
    - ipv6addrs:
      - fc00::1/128

The output in /etc/networking/interfaces :

auto lo
iface lo inet6 static
    netmask 64

Steps to Reproduce Issue

(Include debug logs if possible and relevant.)

Versions Report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

Salt Version:
           Salt: 2016.11.1

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.4.2
          gitdb: 0.6.4
      gitpython: 1.0.1
          ioflo: Not Installed
         Jinja2: 2.8
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: 1.0.3
   msgpack-pure: Not Installed
 msgpack-python: 0.4.6
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
         pygit2: Not Installed
         Python: 2.7.12 (default, Nov 19 2016, 06:48:10)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 15.2.0
           RAET: Not Installed
          smmap: 0.9.0
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.1.4

System Versions:
           dist: Ubuntu 16.04 xenial
        machine: x86_64
        release: 4.4.0-57-generic
         system: Linux
        version: Ubuntu 16.04 xenial
@Ch3LL

This comment has been minimized.

Copy link
Contributor

commented Jan 11, 2017

Does it work if you change it to - ipv6ipaddr: fc00::1/128 ?

@Ch3LL Ch3LL added the Info Needed label Jan 11, 2017

@Ch3LL Ch3LL added this to the Blocked milestone Jan 11, 2017

@valentin2105

This comment has been minimized.

Copy link
Author

commented Jan 11, 2017

Hi, Same result here :

auto lo
iface lo inet6 static
    netmask 64
@heinlein-support

This comment has been minimized.

Copy link

commented Feb 16, 2018

We have exactly the same issue here with Salt 2017.7.3.

Is it really not possible to configure IPv6 with Salts? Any known workarounds?

And, no, even adding the netmask doesn`t help!

Our example:

lo:test
  network.managed:
    - enabled: true
    - type: eth
    - proto: static
    - ipv6_autoconf: no
    - enable_ipv6: true
    - ipv6addrs:
      - xx:xx:xx:xx/128
@Ch3LL

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2018

ping @MTecknology or @garethgreenaway looks like you have done some work here mind taking a look here? Do you have an example for configuring ipv6 on debian/ubuntu? Is this just a documentation bug?

Also to note I found this issue related to debian networking that has a state included if you want to give that a go: #37942

@MTecknology

This comment has been minimized.

Copy link
Contributor

commented Mar 8, 2018

@valentin2105 You said it "doesn't work" but I'm not sure you clearly indicated what that means. Is the problem simply that the netmask isn't making it's way to the configuration file when written, or are there other things that do not behave as expected?

If it's just the netmask, that probably shouldn't be too terrible to track down.

@valentin2105

This comment has been minimized.

Copy link
Author

commented Mar 8, 2018

@MTecknology
By it doesn't work, as I writed, the generated file of this SLS is /etc/network/interfaces :

auto lo
iface lo inet6 static
    netmask 64

There is no IP in the generated output unlike in the yaml file.
I will see if I can solve in Salt's code, but nothing sure :)

@MTecknology

This comment has been minimized.

Copy link
Contributor

commented Mar 8, 2018

If you said so, I still don't see it. However, I also had a very hard time trying to comprehend what I read so it's possible I'm still missing it.

Anyway... it's not just the IP address that is not being included. The netmask is also missed. This is happening because the debian_ip module and templates have no logic for how to handle the data you're trying to throw at it.

If you look at the sample I provided in the bug @Ch3LL mentioned, you'll see that ipaddrs/ipv6addrs (should be ipv6ipaddrs*) was never considered during testing. However, many configurations /were/ considered, and a few included IPv6. If you're only trying to assign one IPv6 address to the interface, then that bit of information has you covered.

If you actually need multiple addresses per interface, then that is something the debian_ip module does not support. You will need to add this support.

To add support for multiple addresses per interface, you'll want to look around _parse_settings_eth() _write_file_ifaces(), and build_interface() of debian_ip. Ultimately, the data structure you build will be parsed by templates/debian_ip/debian_eth.jinja.

I also noticed another snafu... for opt in opts: has some poor logic for deciding v6only. There's also likely to be some issues with "ipv6_$opt" instead of "ipv6$opt".

@cmusser

This comment has been minimized.

Copy link

commented Aug 10, 2018

I'm having a similar issue with trying to configure a single IPv6 address on an interface. In this case, the interface is a "dummy" interface and already has an IPv4 address. The managed system is Ubuntu 18.04 and the salt version is salt 2018.3.2 (Oxygen).

The state I tried was:

dummy0:                                                                                                                                
  network.managed:                                                                                                                     
    - enabled: True                                                                                                                    
    - type: eth                                                                                                                        
    - proto: none                                                                                                                      
    - ipaddr: {{ pillar['anycast_ipv4'] }}                                                                                             
    - broadcast: {{ pillar['broadcast_ipv4'] }}                                                                                        
    - netmask: {{ pillar['netmask_ipv4'] }}                                                                                            
    - ipv6_enabled: True                                                                                                               
    - ipv6proto: static                                                                                                                
    - ipv6ipaddr: {{ pillar['anycast_ipv6'] }}                                                                                         
    - ipv6netmask: {{ pillar['anycast_ipv6_prefix_len'] }}                                                                             
    - require:                                                                                                                         
      - kmod: dummy                                                                                                                    
      - cmd: ip link add dummy0 type dummy

That seemed to not put anything into the /etc/network/interfaces for the IPv6 stuff

auto dummy0
iface dummy0 inet static
    address 45.54.64.53
    netmask 255.255.255.0
    broadcast 45.54.64.255

I'm not sure if this is supported or if I'm just doing it wrong.

@MTecknology

This comment has been minimized.

Copy link
Contributor

commented Aug 27, 2018

After digging into the source a bit, I'm realizing that there's no way to configure a loopback device via salt. I'm working on a PR that fixes this mistake and updates documentation.

When the PR is complete, a loopback interface will be configurable with:

lo:
  network.managed:
    - type: eth
    - proto: loopback

gitebra pushed a commit to gitebra/salt that referenced this issue Aug 31, 2018

Merge remote-tracking branch 'upstream/develop' into develop
* upstream/develop: (101 commits)
  Fix unit test
  Add support to avoid calling refresh_db in opkg.del_repo
  Use a temp file instead of /etc/network/interfaces for unit tests.
  Increase run_script timeout to fix failing test
  Fix git state test
  Fix SaltCloud init in map
  Implement gtmanfred's suggestion
  Don't make a new CloudClient, don't crash on no existing hosts
  Use CloudClient to determine master IP
  Support reading multiple addresses from interface files.
  Support unicode in space-delimited list; fixes unit tests in py2.
  Honor make_master also if master already exists
  Added documentation about debian interfaces.d/*. (Fixes: saltstack#40262)
  Removed python lint.
  Fix tests that use timed_subprocess for py3
  Finished adding support for multiple IP addresses.
  Cleaned up documentation/examples in states.network:
  Added support for -ipaddrs and -ipv6ipaddrs to modules.debian_ip().
  Added support for loopback devices to modules.debian_ip(). (Fixes: saltstack#38672)
  Added a bunch of unit tests for modules.debian_ip.build_interface().
  ...

Ch3LL added a commit to Ch3LL/salt that referenced this issue Dec 10, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.