Page MenuHomeVyOS Platform

Create generic abstraction for configuring interfaces e.g. IP address
Closed, ResolvedPublicFEATURE REQUEST

Description

Right now there is no generic way in configuring an interface IP address from within a Python script.

The only occurance right now is in https://github.com/vyos/vyos-1x/blob/current/src/conf_mode/wireguard.py

def add_addr(intf, addr):
  # see https://phabricator.vyos.net/T949
  ret = subprocess.call(['ip a a dev ' + intf + ' ' + addr + ' &>/dev/null'], shell=True)
  sl.syslog(sl.LOG_NOTICE, "ip a a dev " + intf + " " + addr)

def del_addr(intf, addr):
  ret = subprocess.call(['ip a d dev ' + intf + ' ' + addr + ' &>/dev/null'], shell=True)
  sl.syslog(sl.LOG_NOTICE, "ip a d dev " + intf + " " + addr)

We need to make this available in the generic vyos python library or a proper 3rd party library to be reusable from within multiple scripts.

Requirements:

  • add IPv4/IPv6 interface address
  • remove IPv4/IPv6 interface address
  • add DHCP/DHCPv6 interface address
  • remove DHCP/DHCPv6 interface address
  • add interface description /sys/class/net/eth0/ifalias

Details

Difficulty level
Hard (possibly days)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Behavior change

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
c-po claimed this task.Aug 31 2019, 11:14 AM
c-po raised the priority of this task from Normal to High.
c-po set Is it a breaking change? to Behavior change.

@c-po sorry was camping in a remote area without cell coverage. What's the way we go then? I'll look tomorrow, eventually Tuesday next week into the dhcp stuff.

c-po added a comment.Sep 1 2019, 8:03 AM

@hagbard not a problem. Looks like we now go the "our own lib" way as pyroute2 has some flaws. DHCP is already fix and I continue improve the script and remove redundant code before it will be extended to support VLAN/bonding.

c-po closed this task as Resolved.Sep 4 2019, 2:39 PM
c-po moved this task from Need Triage to Finished on the VyOS 1.3 Equuleus board.Oct 13 2019, 3:08 PM
jjakob added a subscriber: jjakob.Apr 23 2020, 12:08 PM

@c-po looking at your commit d80398b6, I don't think that's how the hw-id node was supposed to be used. It was never used as a way to change the interface's mac address, rather it was used to rename the interface with the matching mac address to the name it has in config.boot. This is done by some vyatta scripts at boot time. If we later set the same mac on the interface that it should already have (as it was renamed by the vyatta scripts), that's pretty pointless to do IMO.

In the case that interface renaming fails (which it does sometimes - the vyatta code has a race condition with the kernel so it sometimes renames the interfaces wrongly) this then ends up setting the wrong interface's mac to the mac that another interface should (or already does) have, so we end up with 2 interfaces with the same mac. That's kind of bad if you ask me.

I wouldn't set the mac on the hw_id node at all, just on the mac node. If we want to do anything at all with the hw_id node in the vyos scripts, it should completely replace all vyatta bootup interface renaming code, and do the renaming itself. That's what I would prefer, to get rid of the old vyatta code once and for all.

Of course, it isn't so simple, as there is a race condition between the kernel (which may still be in the process of adding new interfaces with ethX names) and the interface renaming code, which is renaming the interfaces to the same ethX names. This is where the race condition is - if the kernel adds a ethX interface right before we rename some other interface to that same ethX name, the renaming fails and the interface order gets screwed up.

There is no way to know when the kernel has finished adding interfaces, so we need to tell the kernel to use some other interface names that are NOT 'eth' so there's no chance of them clashing. Either that, or we disallow using 'eth' names in vyos, which would be a change in the config syntax and probably not wanted.

In any case, the way it's set up now is not good.

Oh, I see what that's supposed to do - if there was a 'mac' set to change the interface's mac address, it sets that back to the real factory mac. In that case, that's fine (it's done every time if no 'mac' node is there, which is rather pointless, but shouldn't harm anything), the bug with interface renaming is a separate bug that's not applicable here.

runar added a comment.Apr 23 2020, 2:34 PM

thats correct @jjakob , when a mac is changed on a interface the ONLY place to find the original mac address for a interface is using the hw-id, this is because the kernel does not hold track of the original mac anywhere. for now on saving the config it reverts back to the original hw-id mac when the mac node is deleted witch should be quite fine to do. When the old boot interface mapping code is rewritten these pointers also need to match the new scripts. but thats another storry :)