Re: 1)Accelar mirroring 2)JFWD

[Brett Wilson <bwilson@tislabs.com>]

Rob,

Comments included.  I've also sent this to the openet list as 
Phil has copied your other reply there.

On 06-Sep-2000 Rob Jaeger wrote:
> On Thu, 31 Aug 2000, Brett Wilson wrote:
> 
>> A question about the Accelar filters packet mirroring.
>> 
>> 1) The image that came with the box only does src/dst filters. Correct?
> no.  it can do filters based on any 5 tuple value ... src just means it
> MUST have a src specified and it checks that first ... dst just means it
> MUST have dst ip and therefore checks for it matching first.
> 
>> 2) The JVM image only does global filters. Correct? > 
> no.  it should do all of them ... did you have a problem? can you explain.


I understand that all of the filters work on a 5-tuple, just that a src
filter requires a src address (range) and that a dst filter requires a
dst address (range).  My question is to what is implemented.

When I boot up in the default non-JVM, non-ORE image, it prints a line
stating that "Global filters are not implemented in this release".  I am
assmuming that means that if I try to create a global filter when running
that image, it will be installed but it won't actually filter things.

And when we talked in Glenwood some time ago, you mentioned that all of the
ORE stuff was implemented using global filters.  Does this mean that src/dst
filters aren't implemented at all in the JVM release?
 
>> 3) Have you guys had problems with using the Management tool for adding
>>    and removing filters.
> are you talking about the GUI?  or the cli?  I dont recall problems

GUI.

> specifically related to that ... however, i did have some problems that i
> thought were gui related ... they turned out to be config problems
> (e.g. the link between two routers was half duplex which seemed to make
> high and default priority packet throughput have unexpected values
>>    Not just some of the little catches like making
>>    sure you refresh the port filter screen after turning a filter off and
>>    applying a change to the default before you turn it back on, but rather
>>    filters not always doing what they should.  Sometimes is seems like the
>>    changes I tried to apply haven't actually been applied to the hardware.
>>    Usually rebooting the system clears the problem.  The problem seemed
>>    more likely using the JVM image.  I can't give exact details as I've 
>>    been gone for a few weeks but I will if it happens again.
> if you use the cli, you should always type save afterwards to ensure they 
> are in the memory.  i have had similar problems through the applications
> i wrote but when i got the half/full duplex thing fixed, they appeared to 
> go away.


I think I ended up doing something similar in the GUI, ie. refreshing the
screen constatly and doing an apply after each change.


>> 4) Using 3 computers and 3 separate physical ports, I tried the following:
>> 
>>    Computer A  (Port 1)
>>    Computer B  (Port 2)
>>    Computer X  (Port 3)
>> 
>>    Set filter on Port 2 to match all ICMP traffic destined for Computer A.
>>    (OR all ICMP traffic from Computer B)
>>    Set the port mirror flag on the filter and set filter to deny.
>>    RCMirrorPort is set to Port 3.
>> 
>>    Computer B sends an Echo Request to Computer A.
>>    The Router deny's the packet but mirrors it to port 3.
>>    Computer X picks up the packet, decides its ok and resends it.
> 
> this is expected, right? so far so good.

Yup.  So far so good.
 
>>    Computer A recives the request and replies to B,  BUT at the
>>      same time, the router re-mirrors the resent packet back to
>>      port 3 and does a ttl--.
> 
> hmmm ... is there a filter on port 3?

Oops.  I sometimes forget to layout some of the details.
See below.
 
>> 
>>    As you can see, a nasty loop is created that only stops once
>>    the ttl of the packet drops to zero.  Another thing I noted
>>    was that in both the source and destination filters, the packet
>>    that is mirrored to Port 3 has the ethernet header for:
>>           Port1->ComputerA
>>    not
>>           ComputerB->Port2
>>    which is where I would think it would be considering the packet
>>    filter is supposedly set to Port 2.
> I am confused.  The header is ComputerB (src eth) to ComputerA (dst
> eth) when it leaves computer B.  I think the computer on port 3 must be in
> promiscuous mode to receive the mirrored packets


Yes.  Computer X is in promiscuous mode (and I made a small mod to the kernel
so that the packet filtering kernel code would get promiscous packets).  
Computer X receives all the packets mirrored onto port 3.  Of the packets it
sees, any it deems ok are resent.  (Computer X is the only computer on port
3).

On the way back to the router from Computer X, the HW address information is
correct and the router routes the packet over to Computer A (The original dest)
and the HW address information on that network segment is correct.  The odd
thing is that I get the same packet I sent out (and which _was_ delievered out
port 1) sent back at me (with the TTL--;)   And like your question above, it 
seems like there is a filter on port 3... but there isn't.  Its like its getting
the mirror option of filter on port 2 but not implementing the DENY part. 
Almost like the mirror option of the filter on port 2 is implemented at port 1
instead of port 2.


>> 
>> 5) Are the JFWD/JCapture packages almost completed for the 1100?
>>    The preference would be to try and rate limit in the router itself
>>    (though this relies on the CPU now) but I will need the JFWD and
>>    JCapture stuff to do that.
> I'll need to check with Rob in santa clara.

Yeah, I was just wondering what the release status was on the JFWD stuff.
Being able to do some basic rate limiting in-router is a key point for
our demo coming up in December.

Brett

---------------------------------------------------------
Brett M. Wilson                     <bwilson@tislabs.com>
Adaptive Network Defense Group
NAI Labs, Glenwood, MD