Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    New Version 2.4.4 - Interface Error --> aq_add_macvlan err -53, aq_error 14

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    59 Posts 11 Posters 10.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      peterfranca
      last edited by peterfranca

      Hi everyone.

      I am installing the new Pfsense version 2.4.4 and having this error (aq_add_macvlan err -53, aq_error 14) whenever I am configuring interfaces or Vlan. Does anyone here is testing the new version and having the same error?
      P.S. When I was using the version 2.4.3 I was not having this error.

      Cheers,
      Peter

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        What type of interface is that happening on? Which driver?

        Are you spoofing the MAC address?

        Steve

        1 Reply Last reply Reply Quote 0
        • P
          peterfranca
          last edited by

          What do you mean by type of interface? Virtual/Physical? if so the type is Physical!
          The driver that I am using is this one, Intel(R) Ethernet Connection 700 Series PF Driver, Version - 1.9.9-k
          I am not spoofing the MAC address.

          Cheers,

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Sorry what I meant was what driver such as em0, igb0, ix0 etc.

            That looks like ixl though?

            I have seen that error once, also on an ixl card. It did not seems to be associated with any sort of problem in that instance.

            Steve

            1 Reply Last reply Reply Quote 0
            • P
              peterfranca
              last edited by

              You are correct the driver is ixl0
              Anything that I can try to do to get around it?

              Cheers,
              Peter Franca

              1 Reply Last reply Reply Quote 0
              • jimpJ
                jimp Rebel Alliance Developer Netgate
                last edited by

                Do you have a problem with that interface not working correctly? Or is it just logging that error repeatedly?

                Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                Need help fast? Netgate Global Support!

                Do not Chat/PM for help!

                1 Reply Last reply Reply Quote 0
                • P
                  peterfranca
                  last edited by

                  The interface is working correctly but that error keeps logging repeatedly.
                  Sometimes the server is rebooting without a single warning. Just today I went to enable the ssh remote access and the server crashed and then rebooted.

                  Cheers,
                  Peter Franca

                  1 Reply Last reply Reply Quote 0
                  • jimpJ
                    jimp Rebel Alliance Developer Netgate
                    last edited by

                    Did it happen to offer a crash report after the reboot?

                    Does that hardware have a serial console available? If so, try to setup a console client to log the output. If it does print crash data to the console that would help track down what is happening.

                    If it reboots without any crash data at all, that's more troubling and tends to lean more toward a hardware issue. FreeBSD 11.2 may be driving the hardware in a more strenuous way that didn't trigger an issue on older versions.

                    Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                    Need help fast? Netgate Global Support!

                    Do not Chat/PM for help!

                    1 Reply Last reply Reply Quote 1
                    • C
                      Cyren91
                      last edited by Cyren91

                      0_1540224153880_Problem_VLAN.JPG
                      I had to post a pic because the Antispam Solution of the Forum didn't allow the text.

                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        Was that just adding a new VLAN where others existed or is that the only VLAN on that card?
                        I assume you only see that when adding to ixl0 as the parent?

                        Steve

                        1 Reply Last reply Reply Quote 0
                        • C
                          Cyren91
                          last edited by

                          Hello Steve, we have about 10 VLANs, which where created under 2.4.3. These vlans work fine after the upgrade to 2.4.4, but creating a new vlan with ixl0 as parent is impossible.

                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            Hmm, interesting. The fact existing VLANs on ixl work OK implies it's something happening when they are created in the webgui.
                            Where exactly do you see this error?
                            How do you have the ixl NIC configured?

                            Are you able to try adding a VLAN by editing the config directly and rebooting?

                            Steve

                            1 Reply Last reply Reply Quote 0
                            • C
                              Cyren91
                              last edited by

                              0_1540308218766_steve.jpg

                              1 Reply Last reply Reply Quote 0
                              • S
                                sde
                                last edited by

                                Same hardware. Same issues.
                                Seems to not affect traffic flows, but editing one (of 21) interfaces and saving changes last round about 20 to 30 minutes.
                                For every interface pfsense seems to retry to set a vlanmac several times:
                                0_1540817125593_WIN_20181026_20_27_02_Pro.jpg

                                1 Reply Last reply Reply Quote 0
                                • JeGrJ
                                  JeGr LAYER 8 Moderator
                                  last edited by

                                  Hi there,

                                  just configured a new cluster for a customer last wednesday and saw those exact same error messages pop up in the general log. Never had these before but also never had ixL interfaces (the 10G ones were ix ones almost every time). Anything to do with the driver perhaps?

                                  As those are two completely new hardware machines that have a module bay with a 4-port SFP+ module (ixl0-3) and both had those messages right from the start, I don't think the hardware is at fault.

                                  Messages popped up when adding the 6 VLANs from the customers setup to the ixl0 interface and we have those popping up seemingly random and sparse in the logs but now the customer's worried if hardware or software is at fault.

                                  If there's anything to help analyze, I'm sure we can provide a few details to catch the meaning of it.

                                  Greets
                                  Jens

                                  Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                                  If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                                  1 Reply Last reply Reply Quote 1
                                  • stephenw10S
                                    stephenw10 Netgate Administrator
                                    last edited by

                                    Hmm, there does seem to be something that has snuck in here.

                                    The previous reports of this suggested that VLANs already added to the interface in 2.4.3 were not affected and continued to function. That implies it's something in the actual addition process that is triggering the error.
                                    It would be interesting to try manually editing the config to add a new VLAN with an ixl parent and see if that works.

                                    If that was the case though you would think that simply rebooting after adding those new VLANs would bring them up correctly.

                                    It does seem to be VLAN hardware offloading failing.

                                    Steve

                                    1 Reply Last reply Reply Quote 0
                                    • JeGrJ
                                      JeGr LAYER 8 Moderator
                                      last edited by

                                      Does is have something to do with the older "error" in this thread that mentioned the problem would be gone with a further driver update? Could this be related to a newer driver or driver changes to ixl on FreeBSD 11.2 perhaps?

                                      https://communities.intel.com/thread/103549

                                      Otherwise the VLANs came up alright, what I did see was CARP on those VLAN interfaces somewhat "jittery". If you refresh CARP status on both nodes, you could see the them switching master roles very very shortly but noticable for a second. After witnessing this, I rebooted both nodes. After a bit of research this weekend I found this thread and tried salvaging the reboot log from those boxes:

                                      Nov 2 15:48:06	kernel		done.
Nov 2 15:48:05	php-cgi		rc.bootup: Configuring CARP settings finalize...
Nov 2 15:48:05	php-cgi		rc.bootup: pfsync done in 0 seconds.
Nov 2 15:48:05	php-fpm	334	/rc.carpbackup: HA cluster member "(192.168.91.4@ixl0.91): (V091_PHONE)" has resumed CARP state "BACKUP" for vhid 4
Nov 2 15:48:05	php-fpm	334	/rc.carpbackup: HA cluster member "(192.168.82.4@ixl0.82): (V082_BZD)" has resumed CARP state "BACKUP" for vhid 4
Nov 2 15:48:05	php-fpm	334	/rc.carpbackup: HA cluster member "(192.168.80.4@ixl0.80): (V080_HNR)" has resumed CARP state "BACKUP" for vhid 4
Nov 2 15:48:05	php-cgi		rc.bootup: waiting for pfsync...
Nov 2 15:48:05	php-fpm	335	/rc.carpbackup: HA cluster member "(192.168.95.4@ixl0.95): (V095_ADMIN)" has resumed CARP state "BACKUP" for vhid 4
Nov 2 15:48:05	php-fpm	334	/rc.carpbackup: HA cluster member "(10.0.0.4@ixl0.10): (V010_VERWA)" has resumed CARP state "BACKUP" for vhid 4
Nov 2 15:48:04	kernel		carp: 4@ixl0.91: INIT -> BACKUP (initialization complete)
Nov 2 15:48:04	kernel		ixl0.91: promiscuous mode enabled
Nov 2 15:48:04	check_reload_status		Carp backup event
Nov 2 15:48:04	kernel		carp: 4@ixl0.82: INIT -> BACKUP (initialization complete)
Nov 2 15:48:04	kernel		ixl0.82: promiscuous mode enabled
Nov 2 15:48:04	check_reload_status		Carp backup event
Nov 2 15:48:04	kernel		carp: 4@ixl0.80: INIT -> BACKUP (initialization complete)
Nov 2 15:48:04	kernel		ixl0.80: promiscuous mode enabled
Nov 2 15:48:04	check_reload_status		Carp backup event
Nov 2 15:48:04	kernel		carp: 4@ixl0.10: INIT -> BACKUP (initialization complete)
Nov 2 15:48:04	kernel		ixl0.10: promiscuous mode enabled
Nov 2 15:48:04	kernel		carp: demoted by 240 to 720 (interface down)
Nov 2 15:48:04	kernel		igb4: promiscuous mode enabled
Nov 2 15:48:04	kernel		carp: demoted by 240 to 480 (interface down)
Nov 2 15:48:04	kernel		igb0: promiscuous mode enabled
Nov 2 15:48:04	check_reload_status		Carp backup event
Nov 2 15:48:04	kernel		carp: 4@ixl0.95: INIT -> BACKUP (initialization complete)
Nov 2 15:48:04	kernel		ixl0.95: promiscuous mode enabled
Nov 2 15:48:04	kernel		ixl0: promiscuous mode enabled
Nov 2 15:48:04	kernel		carp: demoted by 240 to 240 (interface down)
Nov 2 15:48:04	kernel		igb1: promiscuous mode enabled
Nov 2 15:48:04	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:04	check_reload_status		Carp backup event
Nov 2 15:48:04	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:04	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:04	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:04	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:04	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:04	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:04	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:04	kernel		done.
Nov 2 15:48:03	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:03	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:03	kernel		done.
Nov 2 15:48:03	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:03	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:03	kernel		vlan4: changing name to 'ixl0.95'
Nov 2 15:48:03	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:03	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:03	syslogd		Logging subprocess 11242 (exec /usr/local/sbin/sshguard) exited due to signal 15.
Nov 2 15:48:03	sshd	10982	Server listening on 0.0.0.0 port 22.
Nov 2 15:48:03	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:03	sshd	10982	Server listening on :: port 22.
Nov 2 15:48:03	kernel		vlan3: changing name to 'ixl0.91'
Nov 2 15:48:03	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:03	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:03	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:03	kernel		vlan2: changing name to 'ixl0.82'
Nov 2 15:48:03	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:02	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:02	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:02	kernel		vlan1: changing name to 'ixl0.80'
Nov 2 15:48:02	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:02	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:02	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:02	kernel		ixl0: aq_add_macvlan err -53, aq_error 14
Nov 2 15:48:02	kernel		vlan0: changing name to 'ixl0.10'
Nov 2 15:48:02	kernel		device_attach: est3 attach returned 6
Nov 2 15:48:02	kernel		est: cpu_vendor GenuineIntel, msr 211200002200
Nov 2 15:48:02	kernel		est: CPU supports Enhanced Speedstep, but is not recognized.
Nov 2 15:48:02	kernel		est3: <Enhanced SpeedStep Frequency Control> on cpu3
Nov 2 15:48:02	kernel		coretemp3: <CPU On-Die Thermal Sensors> on cpu3

                                      (log is newest on top)
                                      Seems to me that assigning and renaming the VLANs somehow triggers that error, too.

                                      Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                                      If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                                      1 Reply Last reply Reply Quote 1
                                      • S
                                        sde
                                        last edited by

                                        I reported a bug for this case.
                                        https://redmine.pfsense.org/issues/9123

                                        1 Reply Last reply Reply Quote 0
                                        • stephenw10S
                                          stephenw10 Netgate Administrator
                                          last edited by

                                          It does look like there have been some driver updates in FreeBSD that might apply to this.
                                          If you're able to test FreeBSD 11-stable or 12 that would be useful.

                                          Steve

                                          P 1 Reply Last reply Reply Quote 0
                                          • JeGrJ
                                            JeGr LAYER 8 Moderator
                                            last edited by

                                            I'd like to help but as those are remote installations from a customer, I'm not at freedom to drive there, pull out the standby one and throw FreeBSD on it. ;) I'd like to (at least to help sort things out), but unfortunately that will be a hard one.

                                            Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                                            If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.