Bug #2786
closed
Setting MTU on VLAN does not set MTU on parent interface in 2.2
Added by Jim Pingle almost 12 years ago. Updated almost 10 years ago.
100%
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.
Files
| fix_vlan_mtu.diff (3.28 KB) fix_vlan_mtu.diff | Renato Botelho, 02/15/2013 07:52 AM |
Updated by Renato Botelho almost 12 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.
Updated by Renato Botelho almost 12 years ago
- File fix_vlan_mtu.diff fix_vlan_mtu.diff added
Updated by Renato Botelho almost 12 years ago
- Status changed from Feedback to New
Updated by Renato Botelho over 11 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 4a7352101fbd6901b46a3b6a9a3c00d23b75f0e1.
Updated by Chris Buechler over 11 years ago
- Status changed from Feedback to Resolved
Updated by Andy Sayler over 10 years ago
This seems to be an issue again in 2.2.
Updated by Chris Buechler about 10 years ago
- Target version changed from 2.1 to 2.2
- Affected Version changed from All to 2.2
regressed in 2.2
Updated by Chris Buechler about 10 years ago
- Status changed from Resolved to Confirmed
- Assignee deleted (
Ermal Luçi) - % Done changed from 100 to 0
Updated by Chris Buechler about 10 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
Updated by Ermal Luçi about 10 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!
Updated by Andy Sayler about 10 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.
Updated by Chris Buechler about 10 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.
Updated by Ermal Luçi about 10 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.
Updated by Chris Buechler about 10 years ago
- Status changed from Feedback to Resolved
fixed. lagg works fine here too
Updated by Andy Sayler almost 10 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:
- Create a new VLAN (VLAN 33), assign it to igb1 NIC
- Create a new interface (TEST), assign it to VLAN33
- Set the MTU for TEST to 9000
- 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.
Updated by Chris Buechler almost 10 years ago
- Status changed from Resolved to Confirmed
this has regressed, doesn't work with lagg or physical interfaces
Updated by Ermal Luçi almost 10 years ago
- Status changed from Confirmed to Feedback
- % Done changed from 0 to 100
Applied in changeset 2b58f94e6005a4b1e8c3387341dc07f3c173269f.
Updated by Ermal Luçi almost 10 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.
Updated by Chris Buechler almost 10 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
Updated by Ermal Luçi almost 10 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....
Updated by Chris Buechler almost 10 years ago
- Status changed from Feedback to Resolved
all good, also doesn't require a reboot for the most common scenarios.
Updated by Andy Sayler almost 10 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.