Page MenuHomeVyOS Platform

Difference in config file after interface MAC changed
Open, NormalPublicBUG

Description

When the interface MAC changes, the config has the other view.
How to reproduce.
VM in GNS3
Initial config

interfaces {
    ethernet eth0 {
        address dhcp
        hw-id 0c:66:c5:29:00:00
    }
    ethernet eth2 {
        hw-id 0c:66:c5:29:00:02
    }
    ethernet eth3 {
        hw-id 0c:66:c5:29:00:03
    }
    ethernet eth4 {
        hw-id 0c:66:c5:29:00:01
    }
    loopback lo {
    }
    tunnel tun0 {
        address 10.0.0.1/30
        encapsulation gre
        remote 192.168.0.5
        source-interface eth0
    }
}
protocols {
    static {
        interface-route 192.168.100.0/24 {
            next-hop-interface tun0 {
            }
        }
    }
}
service {
    ssh {
        port 22
    }
}
system {
    config-management {
        commit-revisions 100
    }
    conntrack {
        modules {
            ftp
            h323
            nfs
            pptp
            sip
            sqlnet
            tftp
        }
    }
    host-name vyos
    login {
        user vyos {
            authentication {
                encrypted-password $6$MjV2YvKQ56q$QbL562qhRoyUu8OaqrXagicvcsNpF1HssCY06ZxxghDJkBCfSfTE/4FlFB41xZcd/HqYyVBuRt8Zyq3ozJ0dc.
                plaintext-password ""
            }
        }
    }
    name-server 8.8.8.8
    ntp {
        server time1.vyos.net {
        }
        server time2.vyos.net {
        }
        server time3.vyos.net {
        }
    }
    syslog {
        global {
            facility all {
                level notice
            }
            facility protocols {
                level debug
            }
        }
    }
}

Then stop VM and change MAC of any ethernet interface.
After boot

interfaces {
    ethernet eth0 {
        address dhcp
        hw-id 0c:66:c5:29:00:00
    }
    ethernet eth2 {
        hw-id 0c:66:c5:29:00:02
    }
    ethernet eth3 {
        hw-id 0c:66:c5:29:00:03
    }
    ethernet eth4 {
        hw-id 0c:66:c5:29:00:01
    }
    loopback lo
    tunnel tun0 {
        address 10.0.0.1/30
        encapsulation gre
        remote 192.168.0.5
        source-interface eth0
    }
}
protocols {
    static {
        interface-route 192.168.100.0/24 {
            next-hop-interface tun0
        }
    }
}
service {
    ssh {
        port 22
    }
}
system {
    config-management {
        commit-revisions 100
    }
    conntrack {
        modules {
            ftp {
            }
            h323 {
            }
            nfs {
            }
            pptp {
            }
            sip {
            }
            sqlnet {
            }
            tftp {
            }
        }
    }
    host-name vyos
    login {
        user vyos {
            authentication {
                encrypted-password $6$MjV2YvKQ56q$QbL562qhRoyUu8OaqrXagicvcsNpF1HssCY06ZxxghDJkBCfSfTE/4FlFB41xZcd/HqYyVBuRt8Zyq3ozJ0dc.
                plaintext-password ""
            }
        }
    }
    name-server 8.8.8.8
    ntp {
        server time1.vyos.net
        server time2.vyos.net
        server time3.vyos.net
    }
    syslog {
        global {
            facility all {
                level notice
            }
            facility protocols {
                level debug
            }
        }
    }
}

Difference
Before

protocols {
    static {
        interface-route 192.168.100.0/24 {
            next-hop-interface tun0 {
            }
        }
    }
}

After

protocols {
    static {
        interface-route 192.168.100.0/24 {
            next-hop-interface tun0
        }
    }
}
  1. Before
conntrack {
        modules {
            ftp
            h323
            nfs
            pptp
            sip
            sqlnet
            tftp
        }
    }

After

conntrack {
    modules {
        ftp {
        }
        h323 {
        }
        nfs {
        }
        pptp {
        }
        sip {
        }
        sqlnet {
        }
        tftp {
        }
    }
}

After saving the config returns to normal state.
One of the problems is when you try to migrate to 1.4.
https://github.com/vyos/vyos-1x/blob/current/src/migration-scripts/quagga/8-to-9#L37
The interface route will disappear after migration.

Details

Difficulty level
Unknown (require assessment)
Version
VyOS 1.3.3
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Perfectly compatible
Issue type
Bug (incorrect behavior)

Event Timeline

This is an artifact of the remaining use in 1.3 of the legacy XorpConfigParser: the last use of that legacy piece was removed from 1.4 in Sep 2021, but is still called by 'vyatta_interface_rescan' in 1.3, so will be seen after changing MAC addresses if the config is not saved. A quick summary of the history is here and quoted below:

https://github.com/vyos/vyos1x-config/blob/master/src/vyos1x_lexer.mll#L130

(*

If you are curious how the original parsers from Vyatta handled the issue: they did not.

The CStore parser cheated by reading data from command definitions to resolve
the ambiguities, which made it impossible to use in standalone config
manipulation programs like migration scripts.

The XorpConfigParser could not tell tag nodes' name and tag from
a leaf node with a value, which made it impossible to manipulate
tag nodes or change values properly.

*)

A simple reproducer, below, can be run on a 1.3 image to demonstrate the issue, but it is clearly described above: XorpConfigParser can not tell tag nodes from a leaf node with value; consequently, the modern lexer does not find the braces after 'next-hop-interface value' to interpret as a tag node.

#!/usr/bin/perl

use strict;
use lib "/opt/vyatta/share/perl5/";
use XorpConfigParser;

my $TMPFILE  = "./config.boot";
my $BOOTFILE = "/opt/vyatta/etc/config/config.boot";

my $xcp = new XorpConfigParser();
$xcp->parse($BOOTFILE);

open (my $tmp, '>', $TMPFILE)
  or die "No $TMPFILE : $!";

select $tmp;
$xcp->output(0);
select STDOUT;
close $tmp;

So, how to fix ? the simplest workaround is to save after change, so the CStore parser (which can tell the difference) will restore the correct braces. Backporting the rewrite of vyatta_net_name/vyatta_interface_rescan without the various workarounds for interface renaming is a possibility (as one would expect no functional change), but would need careful consideration.

Viacheslav triaged this task as Normal priority.Jan 20 2024, 1:26 PM

Added child/related task T6300; the issue is explained in the above comment and in that task. As has been discussed, the easiest workaround is to save the config on the source image before migrating --- backporting the rewrite of vyatta_net_name/vyatta_interface_rescan to 1.3.x will not resolve the issue for earlier images, so a workaround is needed in those cases.