From: Philip Neeson (Philip.Neeson@xxxxxxxxxxxxx)
Date: Tue Feb 13 2001 - 19:20:22 GMT-3
It would appear the default behaviour of an access-list is to forward all
packets fragments. (The PIX 4.2(2)+ and I believe CBAC don't do this as they
track fragment streams and will only allow a fragment if the initial
fragment in the steam has been permitted.)
-From a 6K/MSFC Document-
"Handling Fragmented and Unfragmented Traffic
Layer 4 parameters of ACEs can filter unfragmented traffic and fragmented
traffic with fragments that have offset 0. IP fragments that have an offset
other than 0 miss the Layer 4 port information and cannot be filtered. The
following examples show how ACEs handle packet fragmentation.
In the example below, the traffic coming from 1.1.1.1 port 68 and going to
2.2.2.2 port 34 is permitted. If packets are fragmented, the first fragment
hits this entry and is permitted; fragments with an offset other than 0 are
also permitted as a default result for fragments.
Console>(enable) permit tcp host 1.1.1.1 eq 68 host 2.2.2.2 eq 34
In the example below, the fragment that has offset 0 of the traffic from
1.1.1.1 port 68 going to 2.2.2.2 port 34 is denied. The fragments that have
an offset other than 0 are permitted as a default.
Console>(enable) deny tcp host 1.1.1.1 eq 68 host 2.2.2.2 eq 34
"
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_4/msfc/acc_
list.htm#xtocid279279
Philip.
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Chuck Church
> Sent: 13 February 2001 19:47
> To: 'Shawn Bowen'; Ccielab@Groupstudy. Com
> Subject: RE: Fragmentation Concepts
>
>
> Maybe this means that an interface with an access list must
> re-assemble the
> fragmented packet before it can run it through the access-list?
> If I get a
> chance I'll try it in the lab.
>
> Chuck Church
> CCNP, CCDP, MCNE, MCSE
> Sr. Network Engineer
> Magnacom Technologies
> 140 N. Rt. 303
> Valley Cottage, NY 10989
> 845-267-4000 x218
>
>
> -----Original Message-----
> From: Shawn Bowen [mailto:shawn@bowen.com]
> Sent: Tuesday, February 13, 2001 2:06 PM
> To: Ccielab@Groupstudy. Com
> Subject: RE: Fragmentation Concepts
>
>
> What about a router that's in the middle of the network that the stream of
> packets is going across? How can the middle router effectively use an
> extended access-list if the port number is only contained in the first
> fragment?
>
> Thanks,
> Shawn
>
> -----Original Message-----
> From: Maness, Drew [mailto:drew.maness@veritect.com]
> Sent: Tuesday, February 13, 2001 10:41 AM
> To: 'Tariq Sharif'; Ccielab@Groupstudy. Com
> Subject: RE: Fragmentation Concepts
>
> The router will need to combine the fragmentations or (frames) to form the
> whole packet.
>
> -----Original Message-----
> From: Tariq Sharif [mailto:tariq_sharif@btinternet.com]
> Sent: Monday, February 12, 2001 1:14 PM
> To: Tariq Sharif; Priscilla Oppenheimer; David Ankers; Chuck Larrieu;
> Choon, Raymond (); Ccielab@Groupstudy. Com
> Subject: RE: Fragmentation Concepts
>
>
> Digging a bit deeper...
>
> When IP carrying UDP/TCP is fragmented, only 1st fragment has layer 4 info
> (i.e. port numbers). How do access lists handle this? Will a router open a
> port (say 69) for the 1st segment & looking at the ID/offset it keeps the
> port open for the rest of segments (which do not carry port #)?
>
> Hope you understand what I'm asking.
>
> Many thanks & regards.
>
> Tariq Sharif
>
>
> -----Original Message-----
> From: Tariq Sharif [mailto:tariq_sharif@btinternet.com]
> Sent: 07 February 2001 19:06
> To: Priscilla Oppenheimer; David Ankers; Chuck Larrieu; Choon, Raymond
> (); 'Tariq Sharif'; Ccielab@Groupstudy. Com
> Subject: RE: Fragmentation Concepts
>
>
> Hi Priscilla
>
> Great to have you onboard! Thanks to everyone for a mighty discussion!
>
> Many thanks & regards.
>
> Tariq Sharif
>
>
>
> -----Original Message-----
> From: Priscilla Oppenheimer [mailto:cilla@priscilla.com]
> Sent: 07 February 2001 18:37
> To: David Ankers; Chuck Larrieu; Choon, Raymond (); 'Tariq Sharif';
> Ccielab@Groupstudy. Com
> Subject: Re: Fragmentation Concepts
>
>
> Hi David,
>
> I'm not on the ccie groupstudy list, but it appears that my answer got
> there anyway. That's too bad, because it was wrong! &;-) Sorry.
>
> The host (end node) definitely reassembles, as you say, but I was worried
> about fragments of fragments, which could get kind of ugly. But
> right after
> sending my message I decided that they probably aren't any different than
> normal fragments. I checked RFC 791 and it doesn't talk about fragments of
> fragments, and, in fact, I couldn't find any mention in any documents of
> what a router does when it receives a fragment that it can't forward
> because the MTU for the outgoing interface is too small. But that's
> probably because it's pretty straight-forward.
>
> Say, the first router receives a 4000-byte packet that it needs to divide
> into 1000-byte frames.
>
> First fragment: ID = 4567, offset = 0, More fragments = 1 (true)
> Second fragment: ID = 4567, offset = 1000, More fragments = 1
> Third fragment ID = 4567, offset = 2000, More fragments = 1
> Fourth fragment ID = 4567, offset = 3000, More fragments = 0
>
> So, now think about an intermediate router further down the path that
> receives the first fragment. Say that router needs to forward the frame to
> a network with an MTU of 500. What should that router do? It should just
> keeps subdividing.
>
> Receive first fragment
> Divide it up:
> ID = 4567, offset = 0, More fragments = 1
> ID = 4567, offset = 500, More fragments = 1
>
> Receive next fragment
> Divide it up:
> ID = 4567, offset = 1000, More fragments = 1
> ID = 4567, offset = 1500, More fragments = 1
>
> Etc.
>
> I think that must be what it does, because the fragments could take
> different paths so the router can't just sit there and wait for them.
>
> The last fragment worries me a bit, because the more fragments
> bit would be
> 0, which is also the value for non-fragmented packets. But the
> offset would
> be non-zero, so I guess the recipient would figure it out.
>
> Anyway, thanks for your info. I will join the list now. I passed the
> written (though to be honest I have to take it again, because I let it
> expire before taking the lab.)
>
> Priscilla
>
> At 03:51 AM 2/7/01, you wrote:
> >Is this the Priscilla? Author of top down network design, I guess so as
> there
> >won't be than many Priscilla Oppenheimers around. Great book, thank you.
> >
> >The list you came across is the group study list for the ccie
> lab exam. It
> a
> >bunch of people that are going for the lab in the near future most are
> fairly
> >cluey but there are expections (me for instance :-). The list is run by
> >groupstudy and the joining info is here:
> >
> >http://www.groupstudy.com/list/CCIELab.html
> >
> >About the fragmentation.... Even when a router has to fragment fragments
> (sub
> >fragmentation), the end host is the only one that will reassemble them,
> ever.
> >(there is an exception where routers can do it called intranet
> fragmentation,
> >don't bother about it, even RFC 791 doesn't). Sub fragments look exactly
> the
> >same as the orginal (except for size), they are also not reassembled as a
> >seperate set of fragments by the end host as they contain their orginal
> >position in the orginal fragment. So it's not a hierarchical scheme as
> might
> >sumize. Trust me on this, I've written IP stack code to do it!
> >
> >I can't wait to get to IP version 6, PMTU discovery is the default there!
> >
> >Kind regards,
> >
> >David.
> >
> >
> >On Wednesday 07 February 2001 00:41, you wrote:
> > > What list did this come from and how do I join?
> > >
> > > Usually when a host or router fragments an IP datagram, it is not
> > > reassembled until it reaches the final destination. Each fragment has
> the
> > > same ID in the IP header. The offset field in the header allows the
> > > recipient to put the fragments back in order for delivery to the next
> layer
> > > up.
> > >
> > > What you are talking about in this devious example is fragmentation of
> > > fragments. In that case, I think the router would have to wait for all
> the
> > > original fragments to arrive, reassemble them, and refragment them for
> the
> > > new MTU. Obviously this should be avoided if at all possible.
> > >
> > > Applications can do an MTU discovery by sending varying sized frames
> with
> > > the Don't Fragment bit set until a good frame size is found.
> > >
> > > Priscilla
> > >
> > > At 03:56 PM 2/6/01, Chuck Larrieu wrote:
> > > >Original question:
> > > >
> > > >Host A sends 1500 bytes long packet to e0 of R1 (destined
> for Host B).
> > > >R1 s0 has MTU set to 750 bytes. So R1 fragments packet into 2.
> > > >R2 has MTU of 375 bytes on s1, R2 fragments packet into 2
> > > >R3 has MTU of 1500 on Ethernet LAN B, so it reassembles the fragments
> into
> > > >one 1500 byte long packet & hands it to Host B??
> > > >
> > > >Long winded response:
> > > >
> > > >Another way to look at this is in terms of protocol behaviour at the
> > > > various layers.
> > > >
> > > >Application / layer 7 is the interface between the rest of
> the protocol
> > > >stack and the user application
> > > >
> > > >TCP / layer 4 is responsible for reliable end to end
> reliable transfer
> of
> > > >data.
> > > >
> > > >IP / layer 3 is responsible for path determination and packet
> forwarding
> > > >
> > > >Frame/ layer 2 is where the physical limitations of packet
> size occur.
> > > > E.g. token ring MTU versus ethernet MTU
> > > >
> > > >If a router receives a valid packet, and has a route to the
> destination
> > > >contained within that packet, there is nothing for the
> router ( layer 3
> > > >device ) to do other than to forward it.
> > > >
> > > >In terms of the following model:
> > > >
> > >
> >Host_1----segment_1----Router_1------segment_2------Router_2----s
> egment_3-
> > > >-- ------Host_2
> > > >
> > > >( I'm going to assume that the OSI model doesn't exactly fit here in
> the
> > > >real world of computer processor operations, and that in terms of
> actual
> > > >stack operation, there is interaction up and down )
> > > >
> > > >Layer 7 - app sends 2 meg file to host_2
> > > >Layer 4 - TCP prepares the TCP packet, based on what it knows of the
> > > >transmission requirements, including MTU
> > > >Layer 3 - IP interacts with layer 2 data link - to get the
> proper size
> > > > frame to the next point in the path
> > > >Layer 3 - IP - router receives packet, forwards it. If the outbound
> > > >interface segment requires a smaller packet size, ip fragments it.
> > > >Layer 2 - data link - rules of the data link segments determine MTU
> > > >
> > > >Segment 1 is a token ring with an MTU of 4480, segment 2 is an
> ethernet
> > > >with an MTU 1500, and segment 3 is another token ring, with
> an MTU of
> > > >17000.
> > > >
> > > >Host 1 is sending a 2 meg file to host 2. TCP breaks that file into
> > > > smaller chunks, based on the segment MTU. IP fragments further based
> on
> > > > segment MTU at the next lower level. The data itself, i.e. the 2 meg
> > > > file, is of use to host 2 only as a single file. The
> protocol stack on
> > > > host 2 is responsible for receiving and checking the data, based on
> > > > information handed up from the lower layers.
> > > >
> > > >It would be highly inefficient for the routers along the path to have
> to
> > > >examine each packet with the purpose of determining if the
> packets had
> > > > been fragmented and could be consolidated, not to mention the nature
> of
> > > > the fragmentation. Layer 3 devices just send packets on their merry
> way
> > > > without any concern as to whether or not there are better ways to do
> > > > this.
> > > >
> > > >Hhmmmm.... This could be better written. To bad Priscilla
> Oppenheimer
> > > > isn't on this list. This deserves a good writer :->
> > > >
> > > >Chuck
> > > >
> > > >-----Original Message-----
> > > >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]
> On Behalf
> Of
> > > >Choon, Raymond ()
> > > >Sent: Tuesday, February 06, 2001 10:23 AM
> > > >To: 'Tariq Sharif'; Ccielab@Groupstudy. Com
> > > >Subject: RE: Fragmentation Concepts
> > > >
> > > >Routers don't reassemble packets. Host B receives packets
> with MTU of
> 375
> > > >bytes and host B will reassemble packets to 1500 bytes
> because this is
> the
> > > >original MTU from host A.
> > > >
> > > >I do not have any references for that. This is from my memory when I
> ran
> > > >into doing troubleshooting before. Correct me if I'm wrong.
> > > >
> > > >Raymond Choon
> > > >
> > > >-----Original Message-----
> > > >From: Tariq Sharif [mailto:tariq_sharif@btinternet.com]
> > > >Sent: Tuesday, February 06, 2001 1:01 PM
> > > >To: Ccielab@Groupstudy. Com
> > > >Subject: Fragmentation Concepts
> > > >
> > > >
> > > >Need some help on understanding IP fragmentation. In the setup below,
> are
> > > >the steps below correct?
> > > >
> > > >
> > > >LAN A |
> > > >
> > > >Host A_| Serial line 1 Serial line 2
> > > >
> > > >| LAN B
> > > >|
> > > > |______e0 R1 s0-------------------s0 R2
> > > >
> > > >s1---------------------------s0 R3 e0 -----------|
> > > >
> > > >|-------Host B
> > > >
> > > >Host A sends 1500 bytes long packet to e0 of R1 (destined
> for Host B).
> > > >R1 s0 has MTU set to 750 bytes. So R1 fragments packet into 2.
> > > >R2 has MTU of 375 bytes on s1, R2 fragments packet into 2
> > > >R3 has MTU of 1500 on Ethernet LAN B, so it reassembles the fragments
> into
> > > >one 1500 byte long packet & hands it to Host B??
> > > >
> > > >Any references to sites/books will be greatly appreciated.
> > > >
> > > >Many thanks & regards.
> > > >
> > > >Tariq Sharif
> > > >
> > > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:28:48 GMT-3