Re: Router trick - how to allow only one single packet

If you can find information in that packet that identifies retries,
you can filter them out using FPM. Otherwise - good luck :-)

Of course, the solution of your problem is to fix the application to
gracefully handle retries, or communicate properly (if that is
possible). Not everything is a network problem :-)

--
Marko Milivojevic - CCIE #18427
Senior Technical Instructor - IPexpert
FREE CCIE training: http://bit.ly/vLecture
Mailto: markom_at_ipexpert.com
Telephone: +1.810.326.1444
Web: http://www.ipexpert.com/
On Thu, Nov 4, 2010 at 15:19, Rich Collins <nilsi2002_at_gmail.com> wrote:
> There's really very little to distinguish the retries other than some
> encoded timing information. B The client assumes that the packets were
> dropped or lost.
>
> I am tending towards the idea of per packet loading balancing to
> sinkholes. B I just have to deal B with about 20 retries.
>
> Thnks
>
> On Thu, Nov 4, 2010 at 10:54 AM, Marko Milivojevic <markom_at_ipexpert.com> wrote:
>> If the retries are somehow distinguishable from the original requests,
>> you may want to consider using FPM.
>>
>> --
>> Marko Milivojevic - CCIE #18427
>> Senior Technical Instructor - IPexpert
>>
>> FREE CCIE training: http://bit.ly/vLecture
>>
>> Mailto: markom_at_ipexpert.com
>> Telephone: +1.810.326.1444
>> Web: http://www.ipexpert.com/
>>
>> On Thu, Nov 4, 2010 at 14:48, Rich Collins <nilsi2002_at_gmail.com> wrote:
>>> Hi all,
>>>
>>> I am trying to test a client application in the lab and need a method
>>> to block subsequent requests to a server. The retries (UDP packets
>>> with same length, port number) etc. from this client should not reach
>>> the server. B The retries occur less than a second later and continue.
>>>
>>> Limiting by CAR would still pass some of the requests a few seconds
>>> later. B I can't record and spoof this first packet because of the
>>> encoding in the packet.
>>>
>>> I was also thinking of load balancing by packet and creating numerous
>>> sinkholes at dummy destinations.
>>>
>>> Any ideas or EEM?
>>>
>>> Thanks
>>> Rich
Blogs and organic groups at http://www.ccie.net