Back atcha Tom: > The only comment I disagree with is.... > > > > The proper VLAN aware drivers show 1500 MTU for both the underlying interface and the VLAN interface but it treats VLAN packets with caution, so as not to truncate or drop them because of their longer size.
> >If that's true, then it isn't a "proper VLAN aware driver." The MTU should be set correctly and not just show 1500 and use something else. > My statement was just bringing up that the MTU is for the size of the packet before VLAN tags were added, and VLAN header bits are added on top of the existing full size packets. The reason for this is that we guarantee to deliver 1500 MTU to the consumer, and we want the setting to show what the customer expects to get. If we tag it with VLAN for our own use, we must be able to pass the higher size packet, and strip the VLAN off before delivering down to the client on the other end. The consumer's local Ethernet interface has an MTU of 1500. Nothing you do on the WAN side with VLANs, VPNs, etc. will affect that. They should see 1500 even if you use a StarOS box that clamps the WAN MTU down. I don't think that it is a good thing for interfaces to show an MTU of 1500 on both the primary Ethernet and VLAN devices. I know that, under Linux, they do that, but it doesn't make it correct. :-) It just makes it confusing. It's one of the reasons that I think so many people confuse MTU and MSS. > Opinions on this depend on what the provider is trying to do with the router. The needs as a customer premise router is different than the needs of a ISP transport provider router. The way StarOS does it, to shring the MTU, is appropriate for Customer premise routers, and it would make sense under that circumstance for the MTU setting to reflect the new MTU size that the customer would see. I guess that would depend on your customer. :-) I can't imagine creating that problem for customers. > receive 1500 MTU capability. The problem is not all ethernet devices pass IPSEC higher MTU. Its why it ended up not being a preferred method for tunneling across our network or other's network, without compromising delivery of 1500 MTU to subscribers. Thus the reason we switched to CIPE tunneling as our standard tunneling method. And major reason for selecting Linux based routers. > I'd like to add, that I believe ImageStream supports CIPE tunneling. One of the disadvantages of Mikrotik and StarOS, is that they do NOT support CIPE tunneling. It was one of the reasons we built our own routers 5 years ago. (Before MPLS switches allowing larger packets were mainstream and affordable). Just for the record, ImageStream supports but does not recommend using CIPE as our first choice. We highly encourage customers to use OpenVPN. It is more secure, far more extensible and feature-rich and has considerable market force behind it (unlike CIPE). Regards, Jeff Tom DeReggi RapidDSL & Wireless, Inc IntAirNet- Fixed Wireless Broadband -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
