Conference 7.286::fddi

1684.0. "IP Fragmentation Again!" by MAASUP::PORAMBO () Thu May 11 1995 15:59

Hello Everyone,

  Our customer at NASA has noticied a difference in the operation of IP 
fragmentation between a DECbridge 510 and a DECswitch900 EF. This difference
is apparent with a simple FTP of files between two end nodes with FDDI 
controllers across a routed network (these nodes are not not on same LAN).

  The network configuration is as follows:

 Sender	(VAX)							 Receiver
__________							__________	
|        |							|	 |
---------- \							----------
	  \ \						     / /
	FDDI						  FDDI
	    \ \						   / /
	     \ \				UNKNOW NETWORK COMPONENTS
		__________			__________
DECbridge 	|	 |			|	 |	
510		----------			----------  Cisco Bridge/Router
		    |				     |
	____________________________________________________________
				ETHERNET

	Note: CISCO is routing IP to/from the ethernet

  When the customer tries to FTP a large file from "Sender" to "Receiver" you
can see both ends announce their MTU's as near the maximum of 4500 bytes. 
"Sender" starts the FTP and an ethernet trace shows the DECbridge510 has
fragmented the first FDDI frame into three ethernet frames with the IP
fragmenting information set as expected. We are not clear at this time why, but
this transaction fails. The FTP is "aborted". We do not know the network
topology from the CISCO out to the "Receiver" node.


  Now put the DECswitch900 EF in place of the DECbridge510. This time we had
an FDDI analyzer in place and we could see that "Sender" sets the "DF" 
(don't fragment) bit in its first 4k frame. The DECswitch sees this, drops
the frame, and sends an ICMP message back to "Sender" indicating a fragmentation
error. "Sender" now sends a smaller MTU and this procedure continues until
the the end-to-end transaction can take place without error. I understand
what is going on here, it works as I believe to find the proper Path MTU.


  The 900EF has obviously worked with well with the IP end-to-end MTU path
size discovery method. The DECbridge510 has allowed the end systems to 
believe that the entire path could handle an FDDI size frame when that may not
be true.


  Here's where I confused.....

1)  Why didn't the DECbridge510 drop the 4k frame as the DECswitch did? I don't
have an FDDI trace of that transaction but the "Sender" and "Receiver" in both
instances were the same with no change to IP implementations on either node.
When the DECbridge510 receives a large frame with the "DF" bit set, shouldn't
it drop it?

2)  Does the DECbridge510 have the ability to send the ICMP "fragmentation 
error" message back to the sender just as the DECswitch900 EF can? I have 
heard rumors that it can not.

3)  Will the "Fragmentation Switch" have any impact on this situation? I
believe that it is enabled but we have no management station to access 
the DECbridge510. The only tool on site in DECELMS 1.1 which does not know
how to deal with this bridge. We reset the bridge to factory default.

4) Is firmare an issue here? This bridge is a 1.2 .

5) In reality is the DECbridge510 working as advertised and it functions
different than the 900 EF? 

Thanks for your comments,

Bob

>1)
>When the DECbridge510 receives a large frame with the "DF" bit set, shouldn't
>it drop it?

	yes.

>2)  Does the DECbridge510 have the ability to send the ICMP "fragmentation 
>error" message back to the sender just as the DECswitch900 EF can?

	no.

>4) Is firmare an issue here? This bridge is a 1.2 .

	1.2 is VERY old   1.5 is the latest.  see note 837
	however, it does not appear to me that installing the latest
	code will change your situation.

    
     Additional questions....
    
    
    1)  Are there any plans to include RFC1191 Path MTU Discovery
    mechanisms in the DECbridge 5xx/6xx products?
    
    2)  Assuming for a moment that in .0 the DECbridge 510 fragmented IP
    data even thought the "DF" bit was set, without RFC1191 support won't the
    customer will still have to manually set down the MTU size? In other
    words, even if we "fix" the problem of the bridge not reacting to the 
    "DF" bit, this will not buy the customer anything.
    
    Thanks,
    
    Bob

    I believe that the DECbridge 5xx/6xx products are going end-of-life 
    at the end of this quarter. 
    I'd contact Deb Flint (DELNI::FLINT) of you have any specific
    concerns about these products. She published a memo recently that
    listed products being moved to maintenance at the end of Q4.
    
    Bob