North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
exchange point media
- From: Mikael Abrahamsson
- Date: Mon Jul 17 16:51:40 2000
We had a discussion here a while back about exchange point media. The
outcome was that Gigabit ethernet vendors do support jumbo frames and that
the MTU disadvantage GE has could be overcome.
Now, imagine the following scenario:
We connect a router (router1)to this fictous exchange point running
(gig)ethernet. This router does support jumbo frames and has a 8k MTU.
Somewhere else on the exchange point is another router (router2), also
connected to the same broadcast domain. This router does NOT support jumbo
frames but has the standard 1500 MTU.
What happens if router1 tries to send a packet to router2 which is > 1500
MTU? It thinks it's perfectly valid to send an 8k packet. (PMTUd won't
work here, we're talking layer2).
My guess is that if the switch inbetween the routers is configured for
jumbo frames the frame will be sent to router2 which will probably give a
frame error and discard the packet (silently from router1:s point of
My other guess is that if the switch in between (we're probably not
talking point-to-point-links here because this is an exchange point,
right?) is layer3-aware (as most are today) it could/would fragment the
packet or give a needtofrag-ICMP to the originator IP. Will any switch
today do this? What vendors do this? (I have been told that the old DEC
Gigaswitches will do this between FDDI and FastEth, it will fragment the
IP packet if neccessary).
A third solution would be that I think I saw somewhere that some OSes
support setting host routes where you could enter the MTU of certain
specific IPs. This could also rectify the problem by simply configuring
the switches for jumbo frames and then setting the default MTU to 1500 on
routers and then people who support jumbo frames could include this in
their perring announcements/agreements and if two parties do support these
both then their equipment could use the larger frames when talking to each
other over this shared medium.
Another option would be to pick the other unit's MTU off of the TCP
session enabled for the (very probable) BGP peering. I seem to remember
that TCP involves a MTU negotiation between endpoints and that would mean
that you implicitly get to know the MTU of all your peers (which are the
ones you might send packets to). Any vendors which do a "hack" like this?
This would not work if the default MTU is 1500 though, it would rather
mean you have to have a default MTU of 8k (or so) and find out anyone who
is not jumbo capable via the TCP session involved with the BGP peering.
Comments on all this, please?
Mikael Abrahamsson email: email@example.com