Hi Piotr, Below are my findings:
1. Only Protocols that requires application layer inspection (DPI) are reassembled for inspection. 2. The reassembly process happens on the copy of the packets, the original OOO packets are sent unmodified to the destination. 3. OOO packets sourced from the inside will "skip" the reassambly process. Only OOO packets that are comming from the outside zone are going through the reassembly process. 4. OOO packets are not dropped by default ip inspect tcp reassembly queue length 0 - turns off TCP reassambly eg will drop any OOO packet. Thanks again! Oszkar On Fri, Mar 16, 2012 at 11:19 AM, Piotr Matusiak <[email protected]> wrote: > Cool. Keep us posted! > > > > 2012/3/16 Imre Oszkar <[email protected]> > >> I have got it working. I have played with the rate limiter values and >> now I have OOO. >> So I'm ready for tests:) >> >> thanks! >> >> >> On Fri, Mar 16, 2012 at 9:31 AM, Imre Oszkar <[email protected]> wrote: >> >>> Hi Piotr, >>> >>> Here is the related config from BB1 and the full RIB and FIB table. >>> >>> interface FastEthernet0/1 >>> ip vrf forwarding lab >>> ip address 10.5.8.11 255.255.255.0 >>> ip load-sharing per-packet >>> ip pim sparse-mode >>> >>> ip route vrf lab 0.0.0.0 0.0.0.0 10.5.8.2 >>> ip route vrf lab 0.0.0.0 0.0.0.0 10.5.8.4 >>> >>> >>> BB1#sh ip route vrf lab >>> Gateway of last resort is 10.5.8.4 to network 0.0.0.0 >>> >>> 192.16.10.0/32 is subnetted, 1 subnets >>> S 192.16.10.10 [1/0] via 172.16.1.1, FastEthernet0/0 >>> 10.0.0.0/24 is subnetted, 1 subnets >>> C 10.5.8.0 is directly connected, FastEthernet0/1 >>> S* 0.0.0.0/0 [1/0] via 10.5.8.4 >>> [1/0] via 10.5.8.2 >>> >>> >>> BB1#sh ip cef vrf lab >>> Prefix Next Hop Interface >>> 0.0.0.0/0 10.5.8.2 FastEthernet0/1 >>> 10.5.8.4 FastEthernet0/1 >>> 0.0.0.0/8 drop >>> 0.0.0.0/32 receive >>> 10.5.8.0/24 attached FastEthernet0/1 >>> 10.5.8.0/32 receive FastEthernet0/1 >>> 10.5.8.2/32 attached FastEthernet0/1 >>> 10.5.8.4/32 attached FastEthernet0/1 >>> 10.5.8.11/32 receive FastEthernet0/1 >>> 10.5.8.255/32 receive FastEthernet0/1 >>> 127.0.0.0/8 drop >>> 192.16.10.10/32 172.16.1.1 FastEthernet0/0 >>> 224.0.0.0/4 drop >>> 224.0.0.0/24 receive >>> 240.0.0.0/4 drop >>> 255.255.255.255/32 receive >>> >>> Thanks! >>> Oszkar >>> >>> >>> >>> On Fri, Mar 16, 2012 at 12:26 AM, Piotr Matusiak <[email protected]> wrote: >>> >>>> can you paste config from BB1 and it's RIB? >>>> >>>> >>>> >>>> 2012/3/16 Imre Oszkar <[email protected]> >>>> >>>>> >>>>> Hi Piotr, >>>>> >>>>> Thanks for the idea! Seems that it should work, but for some reason I >>>>> cannot see any OOO packet. >>>>> >>>>> I set up the following scenario: >>>>> 1. unequal path between the source (BB1) and the destination >>>>> (server). BB1 is doing per-packet load balancing. >>>>> 2. Outbound rate limiter on R4 >>>>> >>>>> >>>>> >>>>> |----R4---R1----\ >>>>> |BB1|----| -----R3----R5---|SERVER| >>>>> |-----------R2----/ >>>>> >>>>> >>>>> Per packet load-balaning: >>>>> >>>>> BB1#traceroute 136.1.122.100 (Server) >>>>> >>>>> Type escape sequence to abort. >>>>> Tracing the route to 136.1.122.100 >>>>> >>>>> 1 10.5.8.2 4 msec >>>>> 10.5.8.4 0 msec >>>>> 10.5.8.2 4 msec >>>>> 2 10.5.9.1 0 msec >>>>> 10.5.11.3 4 msec >>>>> 10.5.9.1 0 msec >>>>> 3 136.1.121.5 4 msec >>>>> 10.5.10.3 0 msec >>>>> 136.1.121.5 0 msec >>>>> 4 136.1.121.5 4 msec >>>>> 136.1.122.100 0 msec >>>>> 136.1.121.5 0 msec >>>>> >>>>> >>>>> On R4 I have outbound rate-limiter which is heavily dropping packets. >>>>> >>>>> R4#sh interfaces rate-limit >>>>> FastEthernet0/0 >>>>> Output >>>>> matches: all traffic >>>>> params: 8000 bps, 1500 limit, 2000 extended limit >>>>> conformed 1286 packets, 72962 bytes; action: transmit >>>>> exceeded 12008 packets, 649782 bytes; action: drop >>>>> last packet: 1680ms ago, current burst: 0 bytes >>>>> last cleared 00:11:14 ago, conformed 0 bps, exceeded 7000 bps >>>>> >>>>> >>>>> I'm doing FTP file transfer between the Server and BB1 and I'm running >>>>> wireshark on the Server. Wireshark doesn't report a single OOO >>>>> packet. There is nothing enabled on the routers between BB1 and Server >>>>> that >>>>> would cause packet reassembling. >>>>> >>>>> Do I miss something here? Can you help me out? >>>>> >>>>> Thanks, >>>>> Oszkar >>>>> >>>>> >>>>> On Wed, Mar 14, 2012 at 10:08 AM, Piotr Matusiak <[email protected]>wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> CBAC does reassembly for all packets not only those subjected to DPI. >>>>>> I'm not sure about packet copy tho. >>>>>> For ZBF you must have at least 15.0 to make OOO packets work. It does >>>>>> not work for 12.4T. >>>>>> >>>>>> You can generate OOO packets by trying to setup unequal path to the >>>>>> destination and involve some rate-limiting on one leg. Then configure CEF >>>>>> per-packet load balancing and you'll see packets going through two paths >>>>>> being OOO at the destination. >>>>>> >>>>>> Regards, >>>>>> Piotr >>>>>> >>>>>> >>>>>> 2012/3/14 Imre Oszkar <[email protected]> >>>>>> >>>>>>> Hi Kings, >>>>>>> >>>>>>> I'm familiar with that output, but that doesn't really answer any of >>>>>>> my questions. >>>>>>> >>>>>>> CBAC: >>>>>>> 1. is it true that OOO reassembly works only for packets that >>>>>>> requires application inspection (DPI). If no appfw is configured OOO >>>>>>> packets are dropped. >>>>>>> 2. is it true that the packets reaching the destination will be >>>>>>> still OOO. (so all the reordering happens on a copy of the packet not >>>>>>> the >>>>>>> original packet) >>>>>>> >>>>>>> ZBF: >>>>>>> 1. in case of ZBF is it enough to configure L4 inspection (match >>>>>>> protocol TCP) in order to kick in the reassembly for the OOO packets? >>>>>>> >>>>>>> Nothing comes in my mind how can I generate OOO packets in a lab >>>>>>> environment to test all these, so if somebody could give me an idea that >>>>>>> would be wonderful. >>>>>>> >>>>>>> Thanks, >>>>>>> Oszkar >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 14, 2012 at 1:24 AM, Kingsley Charles < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> By default, CBAC support OoO. check out the following snippet. >>>>>>>> >>>>>>>> router#sh ip inspect all >>>>>>>> Dropped packet logging is enabled >>>>>>>> Session audit trail is disabled >>>>>>>> Session alert is enabled >>>>>>>> one-minute (sampling period) thresholds are [unlimited : unlimited] >>>>>>>> connections >>>>>>>> max-incomplete sessions thresholds are [unlimited : unlimited] >>>>>>>> max-incomplete tcp connections per host is unlimited. Block-time 0 >>>>>>>> minute. >>>>>>>> tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec >>>>>>>> tcp idle-time is 3600 sec -- udp idle-time is 30 sec >>>>>>>> *tcp reassembly queue length 16; timeout 5 sec; memory-limit 1024 >>>>>>>> kilo bytes* >>>>>>>> >>>>>>>> In 12.4(15)T, ZFW doesn't have the parameter map to configure OoO. >>>>>>>> And I guess, it supports it. >>>>>>>> >>>>>>>> With regards >>>>>>>> Kings >>>>>>>> >>>>>>>> On Tue, Mar 13, 2012 at 11:02 AM, Imre Oszkar <[email protected]>wrote: >>>>>>>> >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> Does anybody have a clear understanding of how OOO packets are >>>>>>>>> handled by the IOS firewall (CBAC and ZBF)? >>>>>>>>> I have found a lot of contradictory information about this topic >>>>>>>>> on the cisco site, and I'm getting confused. >>>>>>>>> >>>>>>>>> CBAC >>>>>>>>> >>>>>>>>> According to my understanding in case of CBAC OOO packets are >>>>>>>>> dropped by default. However if we configure L7 inspection for a >>>>>>>>> certain >>>>>>>>> protocol then OOO packet support kicks in for that particular >>>>>>>>> protocol. >>>>>>>>> That means that a copy of the out-of-order packets will be copied >>>>>>>>> into the >>>>>>>>> buffer while the original packet will be transmitted to the >>>>>>>>> destination as >>>>>>>>> it is. No reordering. Once the missing sequence arrives the firewall >>>>>>>>> will >>>>>>>>> fill the hole and will do the firewall logic and the result will be >>>>>>>>> a new >>>>>>>>> session. >>>>>>>>> >>>>>>>>> With the "ip inspect tcp reassembly queue lenght 0" I can disable >>>>>>>>> the OOO packet processing. So even the L7 inspected packets are going >>>>>>>>> to be >>>>>>>>> dropped if they are OOO. >>>>>>>>> >>>>>>>>> >>>>>>>>> Zone based firewall >>>>>>>>> >>>>>>>>> "OoO packets are dropped when IPS and zone-based policy firewall >>>>>>>>> with L4 inspection are enabled." >>>>>>>>> According to this sentence OOO are treated in the same way as in >>>>>>>>> case of CBAC, however the same config guide later on says: >>>>>>>>> >>>>>>>>> "In Cisco IOS Release 12.4(15)T, OoO processing was enabled for >>>>>>>>> zone-based firewall and for IPS shared sessions with Layer 4 match >>>>>>>>> (match >>>>>>>>> protocol TCP, match protocol http), and for any TCP-based Layer 7 >>>>>>>>> packet >>>>>>>>> ordering." >>>>>>>>> From this one I understand that OOO processing works for L4 >>>>>>>>> inspected packets as well eg for any TCP traffic. >>>>>>>>> >>>>>>>>> >>>>>>>>> http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_zbf/configuration/12-4t/sec-zone-pol-fw.html#GUID-CA37F2B4-CA9D-44DD-9B27-C9C235C4D4DE >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you for your comments! >>>>>>>>> Oszkar >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> For more information regarding industry leading CCIE Lab training, >>>>>>>>> please visit www.ipexpert.com >>>>>>>>> >>>>>>>>> Are you a CCNP or CCIE and looking for a job? Check out >>>>>>>>> www.PlatinumPlacement.com >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> For more information regarding industry leading CCIE Lab training, >>>>>>> please visit www.ipexpert.com >>>>>>> >>>>>>> Are you a CCNP or CCIE and looking for a job? Check out >>>>>>> www.PlatinumPlacement.com >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
