Thanks for the clarifications from your engineer.

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.

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. But in our application as a transport provider, our cell site routers want to appear transparent, to any application the consumer may want to use. Its standard that Ethernet is limited to 1500 MTU, and the Consumer should have not problem working around that, and when they want to lower their own MTU. However, as a provider, we never have a need to lower an MTU, as lowering an MTU would compromise the service delivered to the consumerthat would expect to receive 1500 MTU capabilty. 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).

Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband

WISPA Wireless List:



Reply via email to