Jeff,
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: [email protected]
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
