Page MenuHomePhabricator

Bonding interface MAC address missmatch after reboot
Closed, ResolvedPublicBUG

Description

24 hours later: See last comment. The MACs of bonded interfaces are not being set correctly when the machine is booted. Making any change to the bond applies the macs correctly, and everything starts working.

  • Original Post ---

I realise this is an awfully broad swathe of changes, but as I couldn't find any older versions, I'm unable to bisect it any further.

The symptoms are that nothing is received by the device when two interfaces are up. Shutting down one of the interfaces restores traffic flow.

I've done a massive amount of debugging and I can not figure out what the problem is. The only change in the config is that in 201910 the bonding moved

vyos@mke-fw1# compare 6
[edit interfaces bonding bond0]
+member {
+    interface eth0
+    interface eth1
+}
[edit interfaces ethernet eth0]
-bond-group bond0 {
-}
[edit interfaces ethernet eth1]
-bond-group bond0 {
-}
[edit]
vyos@mke-fw1#

I've checked /proc/net/bonding/bond0 and there's no difference between a working system and a non working system, except for the ordering of the interfaces (eth0 is first on 1.2.0, eth1 is first on 1.2)

I can shut down eth1 on either the switch or the router and everything starts working.

It may be related to an accidental enabling of rp filtering, as I get a bunch of dmesg's about martians, so it appears that traffic IS being received, but being dropped somewhere.

The visibility is that vrrp ip addresses become MASTER, and ospf instances get stuck in Establishing. As soon as eth1 is turned off, everything starts working perfectly.

Here's the Cisco (NXOS) Config:

interface port-channel3
  description fw1
  switchport mode trunk
  no lacp graceful-convergence
  spanning-tree port type edge trunk
  speed 1000
  vpc 3


interface Ethernet1/2
  description fw1
  switchport mode trunk
  spanning-tree port type edge trunk
  speed 1000
  channel-group 3 mode passive

The switch sees LACPDUs from both interfaces, and brings up both interfaces, but as soon as it does, data flow goes crazy.

set interfaces bonding bond0 description 'po3'
set interfaces bonding bond0 hash-policy 'layer2'
set interfaces bonding bond0 member interface 'eth0'
set interfaces bonding bond0 mode '802.3ad'

I have removed eth1 from there, for the moment.

Booting back to 1.2.0, everything comes up and works perfectly.

I'm stumped.

Details

Difficulty level
Normal (likely a few hours)
Version
VyOS 1.2-rolling-201910141726
Why the issue appeared?
Design mistake
Is it a breaking change?
Perfectly compatible

Event Timeline

xrobau created this task.Tue, Oct 29, 8:45 PM

1.2.0 complete bond0 output

root@mke-fw1:~# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 250
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: ac:1f:6b:7b:19:89
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 2
        Actor Key: 9
        Partner Key: 32771
        Partner Mac Address: 00:23:04:ee:be:01

Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: ac:1f:6b:7b:19:89
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
    system priority: 65535
    system mac address: ac:1f:6b:7b:19:89
    port key: 9
    port priority: 255
    port number: 1
    port state: 61
details partner lacp pdu:
    system priority: 32667
    system mac address: 00:23:04:ee:be:01
    oper key: 32771
    port priority: 32768
    port number: 258
    port state: 60

Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: ac:1f:6b:7b:19:88
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
    system priority: 65535
    system mac address: ac:1f:6b:7b:19:89
    port key: 9
    port priority: 255
    port number: 2
    port state: 61
details partner lacp pdu:
    system priority: 32667
    system mac address: 00:23:04:ee:be:01
    oper key: 32771
    port priority: 32768
    port number: 16642
    port state: 60
root@mke-fw1:~#
root@mke-fw1:~#
root@mke-fw1:~# show version
Version:          VyOS 1.2.0-rolling+201907210337
Built by:         autobuild@vyos.net
Built on:         Sun 21 Jul 2019 03:37 UTC
Build UUID:       d91aec58-9179-420c-b8fc-6323f4e07e8a
Build Commit ID:  8c22ceead487b7

Architecture:     x86_64
Boot via:         installed image
System type:      bare metal

Hardware vendor:  Supermicro
Hardware model:   Super Server
Hardware S/N:     0123456789
Hardware UUID:    00000000-0000-0000-0000-ac1f6b7b1988

Copyright:        VyOS maintainers and contributors
root@mke-fw1:~#

Working 1.2.0-rolling config (with the different bonding syntax)

set interfaces bonding bond0 description 'po3'
set interfaces bonding bond0 hash-policy 'layer2'
set interfaces bonding bond0 mode '802.3ad'
set interfaces ethernet eth0 bond-group 'bond0'
set interfaces ethernet eth1 bond-group 'bond0'

It looks like the problem occurs when both interfaces are present when the machine boots. I can remove either one, reboot the machine, and it works.

I can then add the missing interface, and it keeps working.

However, if I save the config with BOTH interfaces there, it only responds to a few pings while it's coming up, and then is broken.

While it was booting, it responded to three pings, and then nothing

From 192.168.18.44 icmp_seq=808 Destination Host Unreachable
From 192.168.18.44 icmp_seq=809 Destination Host Unreachable
From 192.168.18.44 icmp_seq=810 Destination Host Unreachable
From 192.168.18.44 icmp_seq=811 Destination Host Unreachable
From 192.168.18.44 icmp_seq=812 Destination Host Unreachable
64 bytes from 192.168.18.44 : icmp_seq=813 ttl=64 time=1207 ms
64 bytes from 192.168.18.44 : icmp_seq=814 ttl=64 time=207 ms
64 bytes from 192.168.18.44 : icmp_seq=815 ttl=64 time=0.241 ms

Removing either of the interfaces restores it to life

From 192.168.18.44 icmp_seq=811 Destination Host Unreachable
From 192.168.18.44 icmp_seq=812 Destination Host Unreachable
64 bytes from 192.168.18.44: icmp_seq=813 ttl=64 time=1207 ms
64 bytes from 192.168.18.44: icmp_seq=814 ttl=64 time=207 ms
64 bytes from 192.168.18.44: icmp_seq=815 ttl=64 time=0.241 ms
From 192.168.18.44 icmp_seq=966 Destination Host Unreachable
From 192.168.18.44 icmp_seq=967 Destination Host Unreachable
From 192.168.18.44 icmp_seq=968 Destination Host Unreachable
64 bytes from 192.168.18.44: icmp_seq=969 ttl=64 time=1786 ms
64 bytes from 192.168.18.44: icmp_seq=970 ttl=64 time=762 ms
64 bytes from 192.168.18.44: icmp_seq=971 ttl=64 time=0.329 ms
64 bytes from 192.168.18.44: icmp_seq=972 ttl=64 time=0.268 ms
64 bytes from 192.168.18.44: icmp_seq=973 ttl=64 time=0.384 ms
64 bytes from 192.168.18.44: icmp_seq=974 ttl=64 time=0.298 ms

You can then re-add the interface and it keeps working.

So, it appears that something subtly wrong is happening as part of the on-boot config application of bonding.

Is there any more debugging I can provide?

Oh, just to emphasize that it's a startup-config issue, if I disable and re-enable the ethernet port in the switch, it is still broken. The only way to get it working is to delete the member, commit, and re-add the member inside vyos.

xrobau added a comment.EditedWed, Oct 30, 12:20 AM

This is getting more and more crazy the more time I spend on it, as this is a niggly issue that shouldn't be this hard to figure out.

If I do a tcpdump on the bond0 interface when it's broken, everything starts working. So this means that something is filtering the mac either in the network card, or, in the kernel.

This machine does have intel network cards, and there IS a difference. This is the older kernel:

[   15.042825] Intel(R) Gigabit Ethernet Linux Driver - version 5.3.5.22s
[   15.042826] Copyright(c) 2007 - 2019 Intel Corporation.
[   15.142532] igb 0000:07:00.0: DCA enabled
[   15.142583] igb 0000:07:00.0: added PHC on eth0
[   15.142585] igb 0000:07:00.0: Intel(R) Gigabit Ethernet Linux Driver
[   15.142587] igb 0000:07:00.0: eth0: (PCIe:2.5GT/s:Width x1)
[   15.142589] igb 0000:07:00.0 eth0: MAC: ac:1f:6b:7b:19:88
[   15.142636] igb 0000:07:00.0: eth0: PBA No: 013A00-000
[   15.157884] igb 0000:07:00.0: LRO is disabled
[   15.157887] igb 0000:07:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)

... 

[   15.258646] igb 0000:08:00.0: DCA enabled
[   15.258740] igb 0000:08:00.0: added PHC on eth1
[   15.258741] igb 0000:08:00.0: Intel(R) Gigabit Ethernet Linux Driver
[   15.258744] igb 0000:08:00.0: eth1: (PCIe:2.5GT/s:Width x1)
[   15.258746] igb 0000:08:00.0 eth1: MAC: ac:1f:6b:7b:19:89
[   15.258794] igb 0000:08:00.0: eth1: PBA No: 011000-000
[   15.258826] igb 0000:08:00.0: LRO is disabled
[   15.258828] igb 0000:08:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)

This is the new kernel - it has a different Intel driver, and it has some warnings:

[   16.773264] Intel(R) Gigabit Ethernet Linux Driver - version 5.3.5.39
[   16.773266] Copyright(c) 2007 - 2019 Intel Corporation.
[   16.876852] igb 0000:07:00.0 eth0: mixed HW and IP checksum settings.
[   16.876862] igb 0000:07:00.0 eth0: mixed HW and IP checksum settings.
[   16.876971] igb 0000:07:00.0: DCA enabled
[   16.877021] igb 0000:07:00.0: added PHC on eth0
[   16.877022] igb 0000:07:00.0: Intel(R) Gigabit Ethernet Linux Driver
[   16.877024] igb 0000:07:00.0: eth0: (PCIe:2.5GT/s:Width x1)
[   16.877027] igb 0000:07:00.0 eth0: MAC: ac:1f:6b:7b:19:88
[   16.877073] igb 0000:07:00.0: eth0: PBA No: 013A00-000
[   16.892349] igb 0000:07:00.0: LRO is disabled
[   16.892351] igb 0000:07:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)


[   16.988778] igb 0000:08:00.0 eth1: mixed HW and IP checksum settings.
[   16.988788] igb 0000:08:00.0 eth1: mixed HW and IP checksum settings.
[   16.988892] igb 0000:08:00.0: DCA enabled
[   16.988970] igb 0000:08:00.0: added PHC on eth1
[   16.988971] igb 0000:08:00.0: Intel(R) Gigabit Ethernet Linux Driver
[   16.988973] igb 0000:08:00.0: eth1: (PCIe:2.5GT/s:Width x1)
[   16.988974] igb 0000:08:00.0 eth1: MAC: ac:1f:6b:7b:19:89
[   16.989021] igb 0000:08:00.0: eth1: PBA No: 011000-000
[   16.989053] igb 0000:08:00.0: LRO is disabled
[   16.989055] igb 0000:08:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)

This lead me to look at the actual ethtool params, and they're wildly different, too

Working (5.3.5.22s):

Features for eth0:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: on
        tx-checksum-ip-generic: off [fixed]
        tx-checksum-ipv6: on
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
        tx-tcp-segmentation: on
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp-mangleid-segmentation: off
        tx-tcp6-segmentation: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]

Not working (5.3.5.39):

Features for eth0:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: off [requested on]
        tx-checksum-ip-generic: on
        tx-checksum-ipv6: off [requested on]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: off
        tx-scatter-gather: off
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
        tx-tcp-segmentation: off
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp-mangleid-segmentation: off
        tx-tcp6-segmentation: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: on
tx-gre-csum-segmentation: on
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
tx-gso-partial: on
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]

The major difference is that gro is disabled on the newer driver version, as well as it's saying 'requested on'.

This appears to be a bug in that intel driver - there's people reporting the same issues here: https://sourceforge.net/p/e1000/bugs/649/

Can we roll back to the previous version?

xrobau renamed this task from Bonding is subtly broken between VyOS 1.2.0-rolling+201907210337 and VyOS 1.2-rolling-201910141726 to Bonding is broken in Daily Builds when using Intel NICs due to bug in Intel NIC Driver 5.3.5.39.Wed, Oct 30, 12:56 AM

OH. MY. GLOB. I just figured it out.

This is a vyos bug. The mac of eth0 is not being set to the mac of bond0 on boot

As soon as I alter anything, the macs are set correctly.

xrobau renamed this task from Bonding is broken in Daily Builds when using Intel NICs due to bug in Intel NIC Driver 5.3.5.39 to Bonding is broken in Daily Builds due to startup config not being applied correctly.Wed, Oct 30, 1:21 AM
xrobau updated the task description. (Show Details)
xrobau added a project: VyOS 1.3 Equuleus.

On the old image, the macs are set correctly

2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether ac:1f:6b:7b:19:89 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq master bond0 state DOWN group default qlen 1000
    link/ether ac:1f:6b:7b:19:89 brd ff:ff:ff:ff:ff:ff
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ac:1f:6b:7b:19:89 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ae1f:6bff:fe7b:1989/64 scope link
       valid_lft forever preferred_lft forever

I can't believe it took me so long to figure this out 8-(

c-po added a subscriber: c-po.Wed, Oct 30, 2:49 AM

@xrobau WOW! What a bisection and research on that problem! Thanks a lot!

I rewrote the complete bonding part in T1614 from the old configuration syntax to the new style - more maintainable - XML/Python interface. Seems something got lost in translation. To sumarize things up - the "problem" is that the MAC address of (???any???) should be configured on the bond if no explicid bond mac address is configured?

c-po changed the task status from Open to Confirmed.Wed, Oct 30, 2:49 AM
c-po claimed this task.
c-po triaged this task as High priority.
c-po removed a project: VyOS 1.2 Crux.
c-po changed Difficulty level from Unknown (require assessment) to Normal (likely a few hours).
c-po changed Why the issue appeared? from Will be filled on close to Implementation mistake.

To summarise, the MACs of interfaces that are bonded should all be the same (and should also match the mac of the bond interface). This works correctly in the older July build. However, this no longer works *on boot* in the latest builds. The screenshot above shows eth0, eth1, and bond0 all having different MACs which is why it's not working.

Changing ANYTHING in the bond rebuilds it, and sets the macs correctly, and everything starts working.

You can duplicate this quite simply, even with a VM. Take a working router, and add two new network interfaces to it. Reboot, and you'll see that they have different macs. Add them to a bond (and it'll be easier to specify the mac of the bond, so it's more obvious - this is what made the penny drop for me), commit, and you'll see the macs have changed on the interfaces to match the mac of the bond.

NOW REBOOT.

The macs WILL NOT be set to the mac of the bond. This is the problem.

xrobau added a comment.EditedWed, Oct 30, 3:58 AM

Basic config that duplicates this problem

set interfaces bonding bond0 mac '02:02:02:02:02:02'
set interfaces bonding bond0 member interface 'eth1'
set interfaces bonding bond0 member interface 'eth2'
set interfaces ethernet eth0 address 'dhcp'
set interfaces ethernet eth0 description input
set interfaces ethernet eth1 description bond0-left
set interfaces ethernet eth2 description bond0-right

This is what it looks like after a reboot

vyos@vyos:~$ ip addr
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:50:56:a7:69:e2 brd ff:ff:ff:ff:ff:ff
    inet XXX.XX.11.154/24 brd XXX.XX.11.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fea7:69e2/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000
    link/ether 00:50:56:a7:2c:a4 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000
    link/ether 00:50:56:a7:33:33 brd ff:ff:ff:ff:ff:ff
5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 02:02:02:02:02:02 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2:2ff:fe02:202/64 scope link
       valid_lft forever preferred_lft forever
vyos@vyos:~$

My hypothesis is that Interface.set_mac is being called AFTER the bond is applied, which sets the mac of the interface back to what it was originally. Probably adding a check to see if it's a bond member may solve it

https://github.com/vyos/vyos-1x/blob/a4230349ed5776a17e934ef5321d39289cf2c511/python/vyos/ifconfig.py#L210

This would explain why it works BRIEFLY before failing.

c-po added a comment.Sat, Nov 2, 4:09 PM

At first glance this looks like a very "easy" priority issue. Bonding interfaces are set up before the ethernet interfaces (makes no sense though).

c-po renamed this task from Bonding is broken in Daily Builds due to startup config not being applied correctly to Bonding interface MAC address missmatch after reboot.Sat, Nov 2, 4:18 PM
c-po changed the task status from Confirmed to Needs testing.
c-po changed Why the issue appeared? from Implementation mistake to Design mistake.
c-po moved this task from Need Triage to In Progress on the VyOS 1.3 Equuleus board.
xrobau added a comment.Sun, Nov 3, 8:42 PM
2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP group default qlen 1000
    link/ether 08:07:06:05:04:03 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP group default qlen 1000
    link/ether 08:07:06:05:04:03 brd ff:ff:ff:ff:ff:ff
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 1000
    link/ether 08:07:06:05:04:03 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::a07:6ff:fe05:403/64 scope link
       valid_lft forever preferred_lft forever

Fixed! This bond also has vlans attached to it, and vrrp, and everything is still seeming to come up and work!

vyos@mke-fw1:~$ show version
Version:          VyOS 1.3-rolling-201911030242
Built by:         autobuild@vyos.net
Built on:         Sun 03 Nov 2019 02:42 UTC
Build UUID:       e4082df1-c79d-432e-bbf2-96ee062132b3
Build Commit ID:  529220d610a6cf

Architecture:     x86_64
Boot via:         installed image
System type:      bare metal

Hardware vendor:  Supermicro
Hardware model:   Super Server
Hardware S/N:     0123456789
Hardware UUID:    00000000-0000-0000-0000-ac1f6b7b1988

Copyright:        VyOS maintainers and contributors
vyos@mke-fw1:~$
c-po closed this task as Resolved.Sun, Nov 3, 9:03 PM
c-po moved this task from In Progress to Finished on the VyOS 1.3 Equuleus board.
c-po changed Is it a breaking change? from Behavior change to Perfectly compatible.
pasik added a subscriber: pasik.Mon, Nov 4, 9:52 AM