Esben Norby [EMAIL PROTECTED] wrote: > > This makes no sense imho, this mtu should be 1500, as the mtu of a vlan > interface is 1500. The mtu of a q-in-q interface should also be 1500. >
OpenBSD has no concept of q-in-q like it does for a single tag (IFCAP_VLAN_MTU), so you would really want to raise the MTU. But OpenBSD can do Cisco-style q-in-q (double tagging with 0x8100 ethertype on both tags), and the 0x88a8 (802.1ad) ethertype should be trivial to implement if someone gets the actual spec to verify that it is as simple as changing the outer tag ethertype. (In any event, most equipment allows you to specify the ethertype for q-in-q to be interoperable with cisco, and openbsd) Some of the drivers actually tell the chip to accept a packet that is 4 bytes larger when they are compiled with pseudo-device vlan in the kernel (#if NVLAN > 0), so it would be nice if you could program MTUs that are larger into the chips. # ifconfig vlan0 192.168.99.1 netmask 255.255.255.0 vlan 44 vlandev nfe0 # ifconfig vlan1 192.168.100.1 netmask 255.255.255.0 vlan 45 vlandev vlan0 # dmesg ... vlan1: initialized with non-standard mtu 1496 (parent vlan0) So if the nfe0 MTU(/MRU) in this example could be raised to 1508 then we could do q-in-q with a 1500 byte packet. There is a bug with the IFCAP_VLAN_MTU concept in that your MTU on the second vlan interface will end up 4 bytes lower, and not 8 bytes lower, once you manually set the mtu on the parent. I think FreeBSD or NetBSD solved this by internally managing vlan_mtu and ether_mtu across virtual interfaces (one reflects the size on the vlan interface before tagging, the other after tagging). We could do it in a simpler/less invastive way by simply recognizing that the parent is a vlan interface and subtracting the EVL_ENCAPLEN twice. This isn't quite as flexible, but we don't support any other types of ethernet encapsulation anyways and so there is really no reason to do something moe elaborate and invasive. There is another general problem in that most drivers don't really give you any way to raise the mru to 1508. Most of the ethernet either drivers do it way in advance (by programming a full jumbo frame MRU on initialization, or by programming 1504 and then asserting IFCAP_VLAN_MTU, or whatever feature the chip has that works for tagged packets as most drivers support IFCAP_VLAN_MTU these days.) > > Is there any way to either = > > > > - not check mtu in ospfd > > There is already a workaround in ospfd to prevent it from not disliking cisco > routers... Some older cisco send out 0 in mtu if i remember correctly... > > Could it be that the ignore-mtu in your Foundry router is help it play with > cisco's that have that flaw? > It's obviously a useful option. Clearly you can create problems by having different maximum packet sizes transported within the same OSPF network. But, as long as the network operator knows what they are doing when they enable it (as this guy does by trying to solve a tagging MTU mismatch), the person still has a fighting chance > > - allow mtu increasing in bge for my supermicro > > mtu 1504 would be "jumbo" frame capability? > > > So, why are you raising contention about this? The fact that OpenBSD doesn't support the ability to increase the MTU/MRU in some drivers is a bug, not a feature. > * sometimes it is nessecary to lower it to 1496 in case vlan tagging is used > in conjunction wiht old NICs that doesn't support more than 1500 byte frames > - thus needing the lowered mtu to fit the 4 byte vlan header... The vlan driver takes care of this for you by lowering the MTU on the vlan interface so account for the size of the tag when the Ethernet driver does not assert IFCAP_VLAN_MTU Chris
