IOS Request For Validation: Noninitial fragments dropped due to reflexive ACL evaluation on outbound subinterface.

I have discovered that Cisco ACLs drop noninitial fragments with the use of the evaluate ACE regardless of the inclusion of a subsequent ACE explicitly permitting all traffic outbound on subinterfaces. Application of this concept to discrete physical interfaces did not result in fragment loss. This has been observed in IOS versions 12.3 and 12.4.

My proof of concept uses four devices: A 1605r, a 1721, a 2950 and a workstation. All devices are cabled to the 2950 switch. Two vlans are configured for the experiment, vlan 2 and vlan 24. The 1605r is a member of vlan 24. The workstation is a member of vlan 2. The 1721 is a member of both vlans and configured with a 802.1q trunk to the 2950. All interfaces are addressed appropriately and routing configured.

The ACLs are written and applied to the f0.24 subinterface on the 1721 router, the vlan 24 interface.

Extended IP access list f0.24-in 10 permit ip any any reflect f0.24-in-dyn Extended IP access list f0.24-out 10 evaluate f0.24-in-dyn 20 permit ip any any

A 64 byte ping from the workstation to the 1605r results in success. The echo request matches ACE 20 in the f0.24-out ACL and the traffic is permitted to reach the 1605r. A 2008 byte ping, requiring fragmentation, from the workstation to the 1605r results in failure. Switchport analysis of the 1605r indicates that the initial fragment is permitted to pass, but noninitial fragments are not.

Reordering of the f0.24-out ACL, that the permit ip any any comes first, results in success. This leads me to the conclusion that a bug exists causing the evaluate ACE to drop fragments, even though reflexive ACLs do not contain any explicit or implicit deny statements. The addition of numerous ACEs permitting fragments to the end of ACL f0.24-out have not facilitated success.

Reply to
Dennis Olvany
Loading thread data ...

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.