Actions
Bug #8446
closedQinQ interfaces are assigned incorrectly
Start date:
04/08/2018
Due date:
% Done:
0%
Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.3
Affected Architecture:
All
Description
When creating a QinQ interface in 2.4.3 it is stored in the config correctly and created as an interface as expected:
<qinqentry> <if>em0</if> <tag>100</tag> <members>200</members> <descr><![CDATA[test wan]]></descr> <vlanif>em0.100</vlanif> </qinqentry>
em0.100.200: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=28<VLAN_MTU,JUMBO_MTU> ether 00:90:7f:87:dc:75 inet6 fe80::290:7fff:fe87:dc75%em0.100.200 prefixlen 64 scopeid 0x10 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active
But when selecting that device to assign it in the GUI the resulting config is still using the old notation:
<opt2> <descr><![CDATA[OPT2]]></descr> <if>em0.100_200</if> <enable></enable> <spoofmac></spoofmac> </opt2>
Which results in expected failure:
Apr 9 01:03:35 php-fpm 8969 /interfaces_assign.php: The command '/sbin/ifconfig 'em0.100_200' -staticarp ' returned exit code '1', the output was 'ifconfig: interface em0.100_200 does not exist' Apr 9 01:03:35 php-fpm 8969 /interfaces_assign.php: The command '/usr/sbin/arp -d -i 'em0.100_200' -a > /dev/null 2>&1 ' returned exit code '1', the output was ''
That config updated correctly top the new notation and functioned but the GUI showed the parent interface only, see pic. Selecting the expected QinQ port broke the config.
Files
Updated by Steve Wheeler over 6 years ago
Updated by Jim Pingle over 6 years ago
- Status changed from New to Feedback
PR was merged earlier today.
Updated by Steve Wheeler over 6 years ago
This looks good now:
<qinqs> <qinqentry> <if>mvneta0</if> <tag>100</tag> <members>30</members> <descr><![CDATA[Test QinQ]]></descr> <vlanif>mvneta0.100</vlanif> </qinqentry> </qinqs>
<opt5> <descr><![CDATA[QinQ]]></descr> <if>mvneta0.100.30</if> <enable></enable> <ipaddr>172.25.56.2</ipaddr> <subnet>24</subnet> <spoofmac></spoofmac> </opt5>
mvneta0.100: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> ether 00:08:a2:0c:0b:ba inet6 fe80::208:a2ff:fe0c:bba%mvneta0.100 prefixlen 64 scopeid 0x11 groups: vlan vlan: 100 vlanpcp: 0 parent interface: mvneta0 media: Ethernet autoselect (none) status: no carrier nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> mvneta0.100.30: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=28<VLAN_MTU,JUMBO_MTU> ether 00:08:a2:0c:0b:ba inet6 fe80::208:a2ff:fe0c:bba%mvneta0.100.30 prefixlen 64 scopeid 0x12 inet 172.25.56.2 netmask 0xffffff00 broadcast 172.25.56.255 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
01:23:41.890037 00:08:a2:0c:0b:ba > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 50: vlan 100, p 0, ethertype 802.1Q, vlan 30, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.25.56.1 tell 172.25.56.2, length 28
The only anomaly I'm seeing is that the QinQ interface shows as UP with carrier even when the parent VLAN and it's parent NIC are down.
Updated by Steve Wheeler over 6 years ago
- Status changed from Feedback to Resolved
Actions