Project

General

Profile

Actions
Copy link

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 about 10 years ago.

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

100%

Estimated time:
Plus Target Version:
Release Notes:
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.

Files

fix_vlan_mtu.diff (3.28 KB) fix_vlan_mtu.diff Renato Botelho, 02/15/2013 07:52 AM
Actions
Copy link
 #1

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.

Actions
Copy link
 #2

Updated by Renato Botelho almost 12 years ago

  • File deleted (fix_vlan_mtu.diff)
Actions
Copy link
 #4

Updated by Renato Botelho almost 12 years ago

  • Status changed from Feedback to New
Actions
Copy link
 #5

Updated by Renato Botelho almost 12 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #6

Updated by Chris Buechler almost 12 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link
 #7

Updated by Andy Sayler over 10 years ago

This seems to be an issue again in 2.2.

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

Actions
Copy link
 #8

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

Actions
Copy link
 #9

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
Actions
Copy link
 #10

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
Actions
Copy link
 #11

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!

Actions
Copy link
 #12

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.

Actions
Copy link
 #13

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.

Actions
Copy link
 #14

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.

Actions
Copy link
 #15

Updated by Chris Buechler about 10 years ago

  • Status changed from Feedback to Resolved

fixed. lagg works fine here too

Actions
Copy link
 #16

Updated by Andy Sayler about 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:

  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.

Actions
Copy link
 #17

Updated by Chris Buechler about 10 years ago

  • Status changed from Resolved to Confirmed

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

Actions
Copy link
 #19

Updated by Ermal Luçi about 10 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #20

Updated by Ermal Luçi about 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.

Actions
Copy link
 #21

Updated by Chris Buechler about 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

Actions
Copy link
 #22

Updated by Ermal Luçi about 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....

Actions
Copy link
 #23

Updated by Chris Buechler about 10 years ago

  • Status changed from Feedback to Resolved

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

Actions
Copy link
 #24

Updated by Andy Sayler about 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.

Actions
Copy link

Also available in: Atom PDF