Re: 1)Accelar mirroring 2)JFWD

[Rob Jaeger <rfj@cs.umd.edu>]

> 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?

All the tests done by the JFWD service implementer used global filters.  I
modified the source I had to do source and destination filters.  Last time
I heard my changes had been folded into the release JFWD api.

 >  
> >> 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.

no.  i could always add them and remove them ... if you are uncertain as
to whether they are stored to flash, use the save command (or save through
the cli.

> > 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.

right ... apply writes it to flash.
> 
> 
> >> 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.

try using the cli to examine the ports for any filter.  However, the
filter is applied going INTO the box from the hosts, therefore, the mirror
would have to be on port 3 as well as 2 for this to happen.  If you have a
fourth machine sending to port 1, does IT get mirrored.  What about if you
just source traffic from X to A directly.

 > > > >> 
> >> 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.

rob