[comp.protocols.tcp-ip] EGP updates over the top

Mills@UDEL.EDU (09/12/87)

Folks,

EGP jumbograms observed here have topped out above the ARPANET MTU of 1006+
octets, which means they will be fragmented. I'm sure the many Unix system
wizards will be casting spells on the reassembly buffer size and crank that
up accordingly. For the fuzzball system warlocks, be advised its EGP does
now reassemble updates. Fixes will be distributed over the weekend. The
reason I dropped this message on the full list is an interesting observation
that the LSI-11 core gateways set the don't-fragment bit on updates to
match the same bit on received packets. Thus, if your EGP code sets this bit
in the IP header, the update that comes back will self-destruct while coming
back. Obviously, the don't-fragment bit should not be set.

having flattened head while learning the above nugget today, I would like to
invite our BBN comrades to expand upon the theme.

Dave

brescia@PARK-STREET.BBN.COM (Mike Brescia) (09/14/87)

The number of nets has indeed been sloshing about the arpanet update size
limit, the 1006 octet MTU.

The fragmenting of NR messages sent by core systems will be happenning with
the next release of software to the butterfly and lsi11 gateways.  If you want
to try some pre-release tests, we can send you some test gateway addresses to
try this week.

Re: the DON'T FRAGMENT (DF) bit in the IP header; a meaning has been assigned
for use of gateway implementations which do not initially do reassembly.  If a
poll message is received with the DF bit set, the NR message sent in reply
will be truncated to fit the (1006) MTU of the net.  Thus you can get SOME
info until the time when your gateway implements reassembly.
NOTE: This meaning is only in the new code which has the capability of doing
fragmentation and reassembly.  The current release which does not do
reassembly will only send as many nets as fit in 1000 (+/-) octets.

Look for announcements of debugging this week.

    Mike

Mills@UDEL.EDU (09/14/87)

Mike,

Are you sure the new code has not escaped to ISI, PURDUE or BBN2? The behavior
I noticed last week, including the DF bit, occured with one or more of those
buzzards. Not to worry, though. At least the fuzz now do buzz EGP reassembly.

Dave

brescia@PARK-STREET.BBN.COM (Mike Brescia) (09/14/87)

Re: sending fragments - not yet in core

1. Except for a short time around the beginning of August, new code to
fragment EGP NR messages has not yet been run in the LSI11's.  Around that
time, the code was run up on BBN2 and PURDUE for a few hours.

2. The LSI11's will copy the dont-fragment (DF) bit from the IP header of a
EGP POLL request into the NR reply.  This sounds like what you are seeing.
Since the LSI11 was going to truncate the message anyway, the bit was
essentially ignored.

Mike