Project

General

Profile

Bug #2786

Setting MTU on VLAN does not set MTU on parent interface in 2.2

Added by Jim Pingle over 6 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Ermal Luçi
Category:
Interfaces
Target version:
Start date:
01/29/2013
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.2
Affected Architecture:

Description

When altering the MTU on a VLAN, the physical interface needs to follow. Currently it does not, and you have to assign the parent and change it to match, or use some other manual means to set the MTU.

We need some extra logic to maintain that relationship on the backend, and possibly in the GUI as well, since changing one VLAN should change them all, and note that in the GUI.

fix_vlan_mtu.diff (3.28 KB) fix_vlan_mtu.diff Renato Botelho, 02/15/2013 07:52 AM

Associated revisions

Revision 4a735210 (diff)
Added by Renato Botelho over 6 years ago

Make parent interface and all VLANs use the same MTU. Fixes #2786

Revision 14f7afb1 (diff)
Added by Ermal Luçi over 4 years ago

Do the tests check properly related to Ticket #2786

Revision 2b58f94e (diff)
Added by Ermal Luçi over 4 years ago

Fixes #2786, properly handle the chain of interfaces during lagg configuration for mtu. For most interfaces this works, bridge will be added in a separate commit

Revision bc8f3264 (diff)
Added by Ermal Luçi over 4 years ago

Ticket #2786 there is an issue with convert_real_interface_to_friendly_interface which might return not expected data as in the situation checked for vlan case her ein the validation. Avoid for this case here the issue to allow properly setting mtu on vlans with not assigned parent.

Revision 2c4301fa (diff)
Added by Ermal Luçi over 4 years ago

Ticket #2786 handle the mtu on bridge same as on lagg. Cleanup some not needed code while here

History

#1 Updated by Renato Botelho over 6 years ago

  • File fix_vlan_mtu.diff added
  • Status changed from New to Feedback

I did an attempt to implement a fix, please review and let me know if it's ok.

#2 Updated by Renato Botelho over 6 years ago

  • File deleted (fix_vlan_mtu.diff)

#4 Updated by Renato Botelho over 6 years ago

  • Status changed from Feedback to New

#5 Updated by Renato Botelho over 6 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#6 Updated by Chris Buechler over 6 years ago

  • Status changed from Feedback to Resolved

#7 Updated by Andy Sayler almost 5 years ago

This seems to be an issue again in 2.2.

See [[https://forum.pfsense.org/index.php?topic=79180.0]].

#8 Updated by Chris Buechler over 4 years ago

  • Target version changed from 2.1 to 2.2
  • Affected Version changed from All to 2.2
  • Affected Documentation 0 added

regressed in 2.2

#9 Updated by Chris Buechler over 4 years ago

  • Status changed from Resolved to Confirmed
  • Assignee deleted (Ermal Luçi)
  • % Done changed from 100 to 0

#10 Updated by Chris Buechler over 4 years ago

  • Subject changed from Setting MTU on VLAN does not set MTU on parent interface to Setting MTU on VLAN does not set MTU on parent interface in 2.2

#11 Updated by Ermal Luçi over 4 years ago

  • Status changed from Confirmed to Rejected
  • Assignee set to Ermal Luçi

What is the problem here really?
Normally an interface should have its own mtu and vlan is its own interface.
Why the parent needs to change mtu if the vlan has its own mtu?

Adapting vlans code works quite well i tested this.
Even when different assigned vlans have different mtus and the parent interface is handled as well.

Please describe why current behaviour is a problem!

#12 Updated by Andy Sayler over 4 years ago

Currently, setting the MTU on an interface assigned to a VLAN seems to be ignored by pfSense.

For example, running the 2.2-BETA (amd64) Sat Nov 15 10:08:19 CST 2014 build, I have the following interface setup:

lagg0 -> igb2 + igb3 (lacp)
vlan3 -> lagg0
vlan6 -> lagg0
vlan9 -> lagg0
LAN   -> lagg0_vlan9 -> v4: 192.168.9.1/24
DMZ   -> lagg0_vlan6 -> v4: 192.168.6.1/24
MGMT  -> lagg0_vlan3 -> v4: 192.168.3.1/24

I also have the following MTUs set for each interface via the pfSense web interface:

MGMT = 9000
DMZ = 9000
LAN = 9000

Yet, when I SSH into and run ifconfig on the system, all the MTUs are still set to 1500 (even after multiple reboots, etc):

[2.2-BETA]/root: ifconfig
...
igb2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=407bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO>
    ether 00:90:0b:33:e2:40
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
igb3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=407bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO>
    ether 00:90:0b:33:e2:40
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
...
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=407bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO>
    ether 00:90:0b:33:e2:40
    inet6 fe80::290:bff:fe33:e240%lagg0 prefixlen 64 scopeid 0xb 
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: active
    laggproto lacp lagghash l2,l3,l4
    laggport: igb3 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
lagg0_vlan3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=303<RXCSUM,TXCSUM,TSO4,TSO6>
    ether 00:90:0b:33:e2:40
    inet6 fe80::290:bff:fe33:e240%lagg0_vlan3 prefixlen 64 scopeid 0xc 
    inet 192.168.3.1 netmask 0xffffff00 broadcast 192.168.3.255 
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: active
    vlan: 3 vlanpcp: 0 parent interface: lagg0
lagg0_vlan6: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=303<RXCSUM,TXCSUM,TSO4,TSO6>
    ether 00:90:0b:33:e2:40
    inet6 fe80::290:bff:fe33:e240%lagg0_vlan6 prefixlen 64 scopeid 0xd 
    inet 192.168.6.1 netmask 0xffffff00 broadcast 192.168.6.255 
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: active
    vlan: 6 vlanpcp: 0 parent interface: lagg0
lagg0_vlan9: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=303<RXCSUM,TXCSUM,TSO4,TSO6>
    ether 00:90:0b:33:e2:40
    inet6 fe80::290:bff:fe33:e240%lagg0_vlan9 prefixlen 64 scopeid 0xe 
    inet 192.168.9.1 netmask 0xffffff00 broadcast 192.168.9.255 
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: active
    vlan: 9 vlanpcp: 0 parent interface: lagg0

As you can see, the web interface VLAN setting is getting lost somewhere and not propagating down to the actual underlying interface settings. This has been further confirmed by actually trying to send farms larger than 1500 bytes across each interface above. All such tests fail.

When I bypass the VLANs and set the MTU directly on a physical or lagg interface, the system works fine:

lagg1     -> igb4 + igb5 (lacp)
TEST_PHY  -> igb1  -> None
TEST_LAGG -> lagg1 -> None
TEST_PHY  = 9000
TEST_LAGG = 9000
[2.2-BETA]/root: ifconfig
...
igb1: flags=8c03<UP,BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 9000
    options=407bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO>
    ether 00:90:0b:33:e2:3f
    inet6 fe80::290:bff:fe33:e23f%igb1 prefixlen 64 scopeid 0x2 
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: no carrier
...
igb4: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000
    options=407bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO>
    ether 00:90:0b:33:e2:42
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: no carrier
igb5: flags=8c03<UP,BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 9000
    options=407bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO>
    ether 00:90:0b:33:e2:42
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: no carrier
...
lagg1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000
    options=407bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO>
    ether 00:90:0b:33:e2:42
    inet6 fe80::290:bff:fe33:e242%lagg1 prefixlen 64 scopeid 0x10 
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: no carrier
    laggproto lacp lagghash l2,l3,l4
    laggport: igb5 flags=0<>
    laggport: igb4 flags=0<>

We need a fix to make sure that MTU settings on interfaces assigned to VLANs are actually being applied.

#13 Updated by Chris Buechler over 4 years ago

  • Status changed from Rejected to Confirmed

The original post describes the problem, which is a regression from 2.1x. Say you have em0 and em0_vlan10. Set MTU on em0_vlan10. It doesn't set it on em0 so setting it on em0_vlan10 fails.

#14 Updated by Ermal Luçi over 4 years ago

  • Status changed from Confirmed to Feedback

Can you retry again with the commit i made yesterday.

Lagg still might need special case here.

#15 Updated by Chris Buechler over 4 years ago

  • Status changed from Feedback to Resolved

fixed. lagg works fine here too

#16 Updated by Andy Sayler over 4 years ago

I'm still seeing this issue on the Mon Nov 24 07:19:16 CST 2014 build, even without using LAGG.

Steps to reproduce:

  1. Create a new VLAN (VLAN 33), assign it to igb1 NIC
  2. Create a new interface (TEST), assign it to VLAN33
  3. Set the MTU for TEST to 9000
  4. Check ifconfig for actual MTU of VLAN33 and igb1 -> both will still be 1500
...
igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO>
    ether 00:90:0b:33:e2:3f
    inet6 fe80::290:bff:fe33:e23f%igb1 prefixlen 64 scopeid 0x2 
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: no carrier
...
igb1_vlan33: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=303<RXCSUM,TXCSUM,TSO4,TSO6>
    ether 00:90:0b:33:e2:3f
    inet6 fe80::290:bff:fe33:e23f%igb1_vlan33 prefixlen 64 scopeid 0x10 
    inet 192.168.33.1 netmask 0xffffff00 broadcast 192.168.33.255 
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: no carrier
    vlan: 33 vlanpcp: 0 parent interface: igb1

When I take the VLAN out of the equation and assign the interface directly to igb1, everything works fine.

igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000
    options=507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO>
    ether 00:90:0b:33:e2:3f
    inet6 fe80::290:bff:fe33:e23f%igb1 prefixlen 64 scopeid 0x2 
    inet 192.168.33.1 netmask 0xffffff00 broadcast 192.168.33.255 
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: no carrier

I ran these tests without a network cable actually attached to igb1, but unless that should make a difference, there still seems to be a bug. I should also note that I have other NICs and VLANs setup on this device unrelated to igb1 and VLAN33 in case those are making a difference for some reason. All of those interfaces exhibit the same "always 1500 MTU" behavior, regardless of the interface MTU setting.

Let me know if I can provide more info.

#17 Updated by Chris Buechler over 4 years ago

  • Status changed from Resolved to Confirmed

this has regressed, doesn't work with lagg or physical interfaces

#18 Updated by Chris Buechler over 4 years ago

  • Affected Documentation 1 added
  • Affected Documentation deleted (0)

#19 Updated by Ermal Luçi over 4 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100

#20 Updated by Ermal Luçi over 4 years ago

Ok works for me.
Lagg needs a restart when the mtu is changed on a vlan on top of it properly the same behaviour wiht bridge.

#21 Updated by Chris Buechler over 4 years ago

  • Status changed from Feedback to Confirmed

unchanged for physical interface where parent isn't assigned. Clear test case on 172.27.32.125, igb1 and igb1_vlan10. Please test there

#22 Updated by Ermal Luçi over 4 years ago

  • Status changed from Confirmed to Feedback

Now works better than ever :)

Though on complex scenarios still needs a reboot to apply proper MTU allover as in GIF/GRE....

#23 Updated by Chris Buechler over 4 years ago

  • Status changed from Feedback to Resolved

all good, also doesn't require a reboot for the most common scenarios.

#24 Updated by Andy Sayler over 4 years ago

Yep, seems to be working correctly now. Thanks!

I did end up having to reboot after changing the MTU setting for multiple VLANs atop a single LAGG interface. Might be nice to add a "Reboot Required" message or something similar if possible in those kinds of scenarios.

Also available in: Atom PDF