| Title: | DEC Network Integration Server (DECNIS) |
| Notice: | Please read note 1 to use this conference effectively |
| Moderator: | MARVIN::WELCH |
| Created: | Wed Sep 18 1991 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3660 |
| Total number of notes: | 15082 |
Hi there !
A DECnis 3.1.8 logs lots and lots of events :
Event: IP Packet Discard from: Node ENST:.enst.lulli Routing,
at: 1997-02-25-14:17:16.130+01:00Iinf
Receiving Entity=Routing Circuit c14-serveurs,
IP Header='450005C4DFFA2000241134C1805D1C09E002E004'H,
IP Discard Reason=Reassembly Interference
What does it mean ????
Thanks in advance and best regards , Michele TSC france
Please find an ethernet analyzer trace below :
_______________________________________________________________________________
My feeling is that the DECnis belongs to IP
multicast 224.2.224.4 (why?) , so as it is the
IP destination of such UDP/IP fragmented datagrams,
it tries to reassemble them.
Doing so , when it receives the first fragment of
an IP datagram , it starts its IP reassembly timer,
then "sees" it received a fragment belonging to this
datagram BEFORE it received the first fragment, thus,
it discards the packet - if so, bug or expected behaviour ?
A funny thing : how is it possible that on ethernet , the last
fragments of a datagram can arrive before the first fragment ,
at such a great rate ? (ethernet failure , or very loaded ethernet?)
ETHER: Packet 19 arrived at 13:49:10.85
ETHER: Packet size = 112 bytes
ETHER: Destination = 1:0:5e:2:e0:4, (multicast)
ETHER: Source = 0:0:c:0:a7:c, Cisco
ETHER: Ethertype = 0800 (IP)
ETHER:
IP: ----- IP Header -----
IP:
IP: Version = 4
IP: Header length = 20 bytes
IP: Type of service = 0x00
IP: xxx. .... = 0 (precedence)
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: Total length = 98 bytes
IP: Identification = 53946
IP: Flags = 0x0
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 1480 bytes
IP: Time to live = 36 seconds/hops
IP: Protocol = 17 (UDP)
IP: Header checksum = 66aa
IP: Source address = 128.93.28.9, experiment2.inria.fr
IP: Destination address = 224.2.224.4, 224.2.224.4
IP: No options
IP:
UDP: [78 byte(s) of data, continuation of IP ident=53946]
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 20 arrived at 13:49:10.93
ETHER: Packet size = 1490 bytes
ETHER: Destination = 1:0:5e:2:e0:4, (multicast)
ETHER: Source = 0:0:c:0:a7:c, Cisco
ETHER: Ethertype = 0800 (IP)
ETHER:
IP: ----- IP Header -----
IP:
IP: Version = 4
IP: Header length = 20 bytes
IP: Type of service = 0x00
IP: xxx. .... = 0 (precedence)
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: Total length = 1476 bytes
IP: Identification = 53946
IP: Flags = 0x2
IP: .0.. .... = may fragment
IP: ..1. .... = more fragments
IP: Fragment offset = 0 bytes
IP: Time to live = 36 seconds/hops
IP: Protocol = 17 (UDP)
IP: Header checksum = 4201
IP: Source address = 128.93.28.9, experiment2.inria.fr
IP: Destination address = 224.2.224.4, 224.2.224.4
IP: No options
IP:
UDP: ----- UDP Header -----
UDP:
UDP: Source port = 2244
UDP: Destination port = 2244
UDP: Length = 1558 (Not all data contained in this fragment)
UDP: Checksum = DC5E
UDP:
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3563.1 | Fragment or part of multiply received ? | PRSSOS::MAGENC | Mon Mar 03 1997 11:28 | 16 | |
Hello !
Anybody listening/speaking there ?
An other idea : could this event "reassembly interference" simply
mean that the DECnis received the same fragment twice or more ?
or "intersecting" fragments ?
BTW : the sender of such UDP messages is a Cisco equipment
that transmits fragments in unpredictable order,
customer says, but as he notices : this is'nt disallowed !
Thnaks in advance for any comment/advice , Michele.
| |||||
| 3563.2 | cisco is sending incomplete fragments | MARVIN::RIGBY | No such thing as an alpha beta | Mon Mar 03 1997 13:00 | 21 |
RFC791 requires that fragmented datagrams are treated as blocks of 8 bytes, the fragment offset in the packet is actually measured in 8-byte units - freeing the don't fragment, more fragments and one reserved bit. The first fragment - delivered second, is ETHER: Packet size = 1490 bytes IP: Total length = 1476 bytes UDP: Length = 1558 and the second is ETHER: Packet size = 112 bytes IP: Total length = 98 bytes IP: Fragment offset = 1480 bytes UDP: [78 byte(s) of data, continuation of IP ident=53946] 1476 is 184.5 8-byte units - this is not allowed, and the second packet starts at offset 0x00b9 *8, 1480. There is a missing longword. The customer is suffering from some cisco induced problem and shouldn't be bothering DIGITAL with it. | |||||
| 3563.3 | mea culpa, the fragments are legal but there's a bit missing | MARVIN::RIGBY | No such thing as an alpha beta | Tue Mar 04 1997 08:49 | 13 |
Unfortunately I was incorrect in my analysis of the fragmentation. The 1476 includes the 20byte IP header but the 8-byte data chunks shouldn't. Thus, the first fragment is legal, covering the range 0-1455, the other fragment is also legal covering the range 1480-1557 (which is the right end for the UDP packet) this leaves a missing fragment for (1456-1479 - a legal 24 byte fragment), probably there have been two fragmentations, the originating end-system would have generated two fragments 0-1479 and 1480-1557 (this is the normal 1518 byte etherent frame fragmentation point) and then some intermediate system has fragmented the 0-1479 opening fragment into two and we don't see the second part. Whats the path from 128.93.28.9 to the DECNIS for multicast traffic? | |||||
| 3563.4 | incomplete packet arrived ? | PRSSOS::MAGENC | Wed Mar 05 1997 15:00 | 19 | |
Hi !
Thank you very much for your answers .
I did'nt notice that the middle of the message was missing.
At the moment, I could'nt contact the customer , so I dunno
the path used for multicasts from Cisco to DECnis.
Before getting this info, I'm still wandering :
if a missing fragment is the reason why the DECnis discards
the packet , why does'nt it use the documented reason
<< incomplete packet arrived >> instead of this mysterious
<< reassembly interference >> ?
"See you" , and best regards , Michele.
| |||||
| 3563.5 | incomplete = truncated | SHAND::shand | Mike Shand | Thu Mar 06 1997 05:48 | 10 |
I *think* that the incomplete packet arrived means that there is something
wrong with the length of the packet. e.g. the IP length is greater than the
datalink length. In this case, all the individual packets are OK, but when we
come to re-assemble we realize there is a missing fragment. Strictlty
"reassembly interference" refers to the case where a packet can't re
reassembled because the fragments overlap etc. However, I *think* it
gets overloaded to mean the case where the reassembly timer goes off as well.
Mike
| |||||