Bug 193953
| Summary: | vlan(4) on LACP lagg(4) do not update if_baudrate value and thus SNMP daemons do not provide high capacity counters | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Josh C <bsdbug-ihj> | ||||||
| Component: | bin | Assignee: | Wojciech Macek <wma> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Many People | CC: | ae, eugen, koobs, mjoras, net, wma, zarychtam | ||||||
| Priority: | --- | Flags: | koobs:
mfc-stable13+
koobs: mfc-stable12? |
||||||
| Version: | 10.0-RELEASE | ||||||||
| Hardware: | amd64 | ||||||||
| OS: | Any | ||||||||
| URL: | https://reviews.freebsd.org/D33405 | ||||||||
| See Also: | https://reviews.freebsd.org/D15112 | ||||||||
| Bug Depends on: | 157015 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Josh C
2014-09-26 16:03:23 UTC
Please re-test this using any supported FreeBSD version (e.g. 10.3+ or 11). It should work here now. (In reply to Eugene Grosbein from comment #1) I confirm aforementioned behavior for 11-STABLE r318137. 64 bit counters are reported, but not working correctly for VLAN interfaces created on LAGG, although they work fine for interfaces belonging to that LAGG. Maybe the issue is related to incorrect speed reported by this VLAN interfaces (10Mbps). I am stuck on this version of FreeBSD because of this unresolved bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219453 so, I am not able to test it on latest 11.1-BETA. (In reply to Marek Zarychta from comment #2) Please show output of "ifconfig -m" command for physical interface, for lagg and for vlan over lagg. (In reply to Eugene Grosbein from comment #3) This test has been done on the spare machine, which had been setup to test mentioned Bug 219453. The machine is currently running fresh FreeBSD 11.1-BETA2 #0 r319996. Ifconig -m doesn't show interface speed for this devices. Output is limited to physical interfaces belonging to the LAGG, LAGG interface itself and one child VLAN. IP addresses are not shown as irrelevant. ~# ifconfig -m msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000 options=80018<VLAN_MTU,VLAN_HWTAGGING,LINKSTATE> capabilities=c011b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE> ether 00:0e:0c:a4:53:5d hwaddr 00:0e:0c:a4:53:5c nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active supported media: media autoselect mediaopt flowcontrol media autoselect media 1000baseT mediaopt full-duplex,master media 1000baseT mediaopt full-duplex media 1000baseT mediaopt master media 1000baseT media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP media none em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000 options=98<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> capabilities=11389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,NETMAP> ether 00:0e:0c:a4:53:5d hwaddr 00:0e:0c:a4:53:5d nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active supported media: media autoselect media 1000baseT media 1000baseT mediaopt full-duplex media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000 options=18<VLAN_MTU,VLAN_HWTAGGING> capabilities=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING> ether 00:0e:0c:a4:53:5d inet (...) nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect status: active supported media: media autoselect groups: lagg laggproto lacp lagghash l2,l3,l4 laggport: msk0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> laggport: em0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000 ether 00:0e:0c:a4:53:5d inet (...) nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect status: active supported media: media autoselect vlan: 10 vlanpcp: 0 parent interface: lagg0 groups: vlan Here is the output of the command: ~# bsnmpwalk -v 2c -s public@127.0.0.1 (...) ifDescr[1] = msk0 ifDescr[2] = em0 ifDescr[3] = lo0 ifDescr[4] = lagg0 ifDescr[5] = lo1 ifDescr[6] = lo2 ifDescr[7] = lo3 ifDescr[8] = lo4 ifDescr[9] = lo5 ifDescr[10] = lo6 ifDescr[11] = vlan0 ifDescr[12] = vlan1 ifDescr[13] = vlan2 ifDescr[14] = vlan3 (...) ifSpeed[1] = 1000000000 ifSpeed[2] = 1000000000 ifSpeed[3] = 0 ifSpeed[4] = 2000000000 ifSpeed[5] = 0 ifSpeed[6] = 0 ifSpeed[7] = 0 ifSpeed[8] = 0 ifSpeed[9] = 0 ifSpeed[10] = 0 ifSpeed[11] = 10000000 ifSpeed[12] = 10000000 ifSpeed[13] = 10000000 ifSpeed[14] = 10000000 (...) For this system bsmnmpwalk shows 64-bit counters present for only 3 interfaces: ~# bsnmpwalk -v 2c -s public@127.0.0.1 1.3.6.1.2.1.31.1.1.1.6 ifHCInOctets[1] = 315994426 ifHCInOctets[2] = 400196178 ifHCInOctets[4] = 716190604 At present (11.1-PRERELEASE) this bug refers only to VLAN interfaces created from startup scripts on the top of LACP LAGGs. When the VLAN interface is created manually after the parent LACP LAGG is up, the speed reported by the interface reflects the speed of parent LAGG, also the 64-bit counters are present for such VLAN interface. Created attachment 190855 [details]
ugly_patch_exposing_64-bit_counters
This patch at least exposes exposes 64-bit interface counters for vlan children, althrouhg the speed of aggregate interface itself is still being calculated by LACP code.
Interface speed for LACP aggretated LAGGs is calculated in sys/net/ieee8023ad_lacp.c When the state of LACP interface changes VLAN children should also be made aware of this. Maybe someone will correct this by reinitializing valuse for LACP aggregate in right way by calling sys/net/ieee8023ad_lacp.c instead of comment /* LACP updates if_baudrate itself */.
Created attachment 190856 [details]
Another patch for FreeBSD 12-CURRENT
We use this patch to solve this problem.
Comment on attachment 190856 [details]
Another patch for FreeBSD 12-CURRENT
Note that the patch for CURRENT.
(In reply to Andrey V. Elsukov from comment #8) Plans to MFC this? High capacity counters are now available for these interfaces. Probably time to close this bug. ^Triage: Can we identify who and where (commit(s), merges) resolved this issue, either specifically or by way of framework improvement (eg: 64bit counters)? Would be great to attribute it. (In reply to Kubilay Kocak from comment #11) I think Marek means the patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=157015 It modified mibII bsnmp module, thus it always creates 64bit counters. Actually I already forget the cause why we used the patch from this PR. Probably this may be related to net-snmpd daemon. (In reply to Andrey V. Elsukov from comment #12) Thankn you. That is to say this issue is/was resolved by bug 157015, is that correct? (In reply to Kubilay Kocak from comment #13) I think I remembered why we use this patch. Without the proposed eventhandler vlan interfaces created on top of lagg will not modify if_boudrate when lagg's speed will be updated (e.g. added new port, or one port removed). And thus SNMP daemon reports incorrect interface speed in the IF-MIB::ifHighSpeed oid. I'll try to update the patch and post it into phabricator. Committed to main https://cgit.freebsd.org/src/commit/?id=f2ab9160 Thanks, we are looking forward to MFC. Thank you for the MFC[1] to stable/13 Wojciech. I am not the reporter, but it's probably time to close this almost 8 years old bug. [1] https://cgit.freebsd.org/src/commit/?id=067a4b656b9b ^Triage: Update meta with details and close. * review D15112 doesn't appear to have been committed. * Will set bug 157015 a dependent for tracking purposes. It is related and was the earliest underlying relevent changeset. * Assign to committer that resolved keeping net@ cc'd * Track merge to stable/13 (src 067a4b656b9b) * Request feedback for merge to stable/12 ^Triage: Include ae@ (author) for feedback (merge to stable/12 request) Please close this bug, as I can't do it. I am not the reporter but hijacked the PR. The original reporter reveals no interest. MFC to stable/12 will be probably a waste of the committer's time. It is not really a bug. It is a missing feature, but it's harmless and FreeBSD 12 can reach EoL without this feature. Moreover, MFC to stable/12 might be undesired. Andrey, Wojciech, thanks again for your work! (In reply to Marek Zarychta from comment #19) All else being equal, consistent issue resolution across supported FreeBSD stable branches is a desirable default. Rather than speculating on what might constitute a waste of committer time, it is perfectly reasonable to ask the question (re merges), if nothing else than to detail / clarify / reference any considerations or issues that might be relevent to merging (or not). Wojciech/Andrey are able to elucidate those considerations. Lastly, we appreciate people getting involved with helping issues progress to resolution, so thank you for doing that. (In reply to Kubilay Kocak from comment #20) I'd rather avoid this added burden to be placed on committers. >Lastly, we appreciate people getting involved with helping issues progress The pleasure is all mine. ^Triage: MFC to 12 is now OBE. |
