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

Reply via email to