There was a throwaway line in a book I was reading (the CCNA: Security Official Certification Guide), that said that a disadvantage of ACL’s is:

Does not filter fragmented packets with the same accuracy as non fragmented packets.

I have no idea why this is true, and after a post on techexams.net, I decided to just set up a lab and have a go, and figure out the specifics of fragmentation as I go!

EDIT: The first thing I actually did was a waste of time. My first lab was Ethernet everywhere, and the 3700’s don’t support changing the MTU on a FastEthernet connection. So from here on is my second attempt!

The first thing I did was set up a lab in GNS3:

It’s pretty basic. The cloud is tied to a MS Loopback adapter on my Windows 7 machine, and the routers have minimal config on.

 **R1 config:**

     interface FastEthernet0/0
      ip address
      no shut
     interface Serial0/0
      ip address
      clock rate 8000000
      no shut
 **R2 config:**

     no ip routing
     interface Serial0/0
      ip address
      clock rate 8000000
      no shut
     ip default-gateway

R2 doesn’t actually need to be a router, but it saved firing up a VM, and makes packet capture easier because I can do it direct from GNS3.

To be able to ping from Windows to the end router, I needed to add a route to Windows – this was to stop it trying to use my internet connection to access the lab. To do this, I just entered the following into a command prompt with administrative privileges.

route add mask

For some reason, I can now ping from windows TO R2, with successful replies – yet if I initiate the ping from R2 then it fails. I’ve wiresharked the loopback adapter, and the ping gets there – Windows doesn’t reply though. Firewall is disabled, and the route is there. Strange, but it won’t affect what I’m playing with here, so I’ll leave it for now. Anyone has any idea why, please let me know. EDIT: Since I changed to a serial connection, it now magically works. I guess it’s just flaky virtualisation?
The first thing I’m going to do is verify the MTU that should work across the network:

R1#sh int s0/0 | i MTU|address
  Internet address is
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

R1#sh int fa0/0 | i MTU|address
 Hardware is Gt96k FE, address is c200.12f0.0000 (bia c200.12f0.0000)
  Internet address is
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec

R2#sh int s0/0 | i MTU|address
  Internet address is
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

And on Windows:

     C:\Windows\system32>netsh interface ipv4 show subinterfaces

     MTU    MediaSenseState Bytes In  Bytes Out Interface
     ------ --------------- --------- --------- -------------
     4294967295           1         0   1037944 Loopback Pseudo-Interface
      1500                1 313921062  20230510 Wireless Network Connection
      1500                5         0     60352 Wireless Network Connection 2
      1500                5         0     61664 Local Area Connection
      1477                5         0     60352 Local Area Connection 2
      1500                1      7640    290354 Loop
      1500                1         0    497266 VirtualBox Host-Only Network

So that means I’m happy that the MTU across my whole network is 1500.

I’m going to lower the MTU on the serial connection, both ends, to 500. This will then give me a line where packets should fragment. The reason is, if I try sending packets that are bigger than 1500 then I’m not seeing how the router will fragment as Windows will do silly things with it first.

Under interface Serial0/0 on both routers, I entered mtu 500.

The next thing to do is some pings of various sizes from my PC to R2. I’ll do one at 200 bytes, one at 600 bytes, and one at 1600 bytes. That should give me no fragments, 2 fragments, and 4 fragments respectively.

I opened up a command prompt on my host, and entered:

     ping -n 1 -l 200
     ping -n 1 -l 600
     ping -n 1 -l 1600

There’s my three pings. And here is the wireshark capture, after filtering out only the incoming packets (I’m not interested in the replies the the moment, and there’s also SLARP and CDP stuff that I wanted to filter):

!!! Missing image

Interesting results, and slightly different to what I expected. The first ping came in at 232 bytes (200 bytes payload plus headers), and arrived in one packet. As expected. The second (the 600 byte payload) came in two packets as expected. However, the third one, which was 1600 bytes payload, got split in to 5 packets. I expected this to be 4, as it could have fit in 4.

Another thing that confused me initially was the packet sizes. The first packet is a little smaller than I guessed it would be…but that’s because I overlooked the fact that the layer two header is HDLC, not Ethernet. Ethernet adds 14 bytes to a packet usually, where HDLC adds 4.

This also accounts for the 504 byte fragments, as the MTU excludes the 4-byte L2 header.

The next step is to swap the ICMP traffic for TCP traffic, to allow for some access list manipulation, and then start implementing access lists. But this half has taking me longer than expected, so I’m going to leave that for a part 2 some other day.

Thanks for reading, any questions, or any errors you’ve noticed or anything you want to chat about, please get in touch!

Nick Shaw

Nick Shaw

I'm Nick, a knowledgeable and versatile security focussed network specialist. I have years of experience delivering complex projects for large and small organisations alike. As a full-stack engineer, I look at the end to end requirements and come up with a solution to match, rather than focussing just on one aspect. When I'm not working, I have three main interests: my family, football (Barnsley FC) and motorsports.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.