From: Chris Home (clarson52@comcast.net)
Date: Wed Apr 23 2003 - 23:15:54 GMT-3
Your right all Cats are not the same. I believe the document I read is
specific to the 6000/6500 series. So that is cool with the 3550. I wasn't
aware it worked that way. Interesting. Thanks for the info.
----- Original Message -----
From: "Mike Williams" <ccie2be@swbell.net>
To: "'Chris Home'" <clarson52@comcast.net>; "'David Buechner'"
<dbuechn@attglobal.net>; <ccielab@groupstudy.com>
Sent: Wednesday, April 23, 2003 9:26 PM
Subject: RE: 3550 - RSPAN - Reflector Port
> Careful here. Remember there are A LOT of different Cat switches and
> many of them have different architectures. The 3550 has a shared memory
> architecture, so (if my understanding of the technology is correct) when
> a frame comes in, it's stored in shared memory, and then only the port
> (or ports if spanning) that it will exit are passed a pointer to that
> frame in memory. Very little overhead there. However, I'm not sure how
> long it keeps that frame in that same memory location, so if the span
> port is current outputing another frame, I can't say that it would keep
> that frame in memory, or copy it to a buffer. That would become an ugly
> scenario as it's possible that your source ports (if you're spanning
> more than one port as the input) could burst to an excessively high
> speed that would overrun the output buffer of the output span port. I'm
> sure at this point Cisco engineers (the people that build this hardware)
> are really the only ones that truly know what kind of performance hit a
> switch might take in this situation trying to juggle these spanned
> frames, etc...
>
> But all in all I would agree with the original post that there is some
> sort of ASIC or something that handles the RSPAN technique to keep the
> load off the CPU.
>
> 2 cents.
>
> Mike W.
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Chris Home
> Sent: Wednesday, April 23, 2003 5:53 PM
> To: David Buechner; ccielab@groupstudy.com
> Subject: Re: 3550 - RSPAN - Reflector Port
>
>
> In fact when a cat switch receives ANY frame it is copied to every port.
> When a switch receives a frame, as soon as it gets access to the
> backplane the frame is copied to every port as it travels. When a
> forwarding decision is made the interfaces that should not forward are
> told to flush their buffer of the frame or ignore it (I am not exactly
> sure which. I have heard both ignore and flush). The forwarding ports
> are left to forward. So a span port simply never gets told to flush or
> ignore any packets. Little to no performance loss. There is also an
> excellent document on this and the 6500 architecture that covers more of
> this kind of stuff. Very informative and interesting doc.
>
> I am not sure how this applies on dCEF cards. Since the forwarding
> decision is made at the module. I think it might be the same, the
> forwarding decision is just made sooner. I dunno really.
>
>
> ----- Original Message -----
> From: "David Buechner" <dbuechn@attglobal.net>
> To: <ccielab@groupstudy.com>
> Sent: Wednesday, April 23, 2003 2:53 PM
> Subject: RE: 3550 - RSPAN - Reflector Port
>
>
> > Daniel,
> >
> > Here's how I understand it:
> >
> > First, let's start with a SPAN session. In SPAN you have some traffic
> that
> > you're monitoring which is then duplicated on a port local to the
> > switch
> so
> > that it is visible to a locally attached device (such as a protocol
> > analyzer). One of the things that I suspect is important to switch
> > performance here is that very little processing is done on the
> > duplicated packet - it's just copied to the monitor port.
> >
> > Now consider the RSPAN scenario. Here, instead of copying the frame
> > to a particular port you need to get it into a particular VLAN and
> > then switch it as new traffic for that VLAN, thus enabling delivery to
>
> > a remote destination port. The mechanism on the local switch to do
> > this is the reflector port. In essence the reflector port acts
> > similarly to a destination port, only instead of transmitting the
> > packet out the physical port it transmits it out the RSPAN VLAN. I
> > don't know the hardware intimately, but I would guess that maybe the
> > ASIC in the port can handle "reflecting" the traffic back to the RSPAN
>
> > VLAN thereby keeping the switch CPU from having to modify the packet.
>
> > (I'd be happy to hear from someone who knows the hardware better to
> > see if my WAG is right! :-))
> >
> > If I'm wrong in any of this I'd very much appreciate commentary!
> >
> > David
> >
> > At 07:25 am 4/23/2003 -0600, groupstudy wrote:
> >
> >http://www.cisco.com/en/US/products/hw/switches/ps646/products_configur
> >atio
> n_guide_chapter09186a00800c6f4c.html
> > >Pretty good explanation
> > >
> > >-----Original Message-----
> > >From: Daniel Cisco Group Study [mailto:danielcgs@imc.net.au]
> > >Sent: Wednesday, April 23, 2003 6:19 AM
> > >To: ccielab@groupstudy.com
> > >Subject: 3550 - RSPAN - Reflector Port
> > >
> > >
> > >Hi all,
> > >
> > >Can someone explain the use / purpose of the reflector port when
> > >setting up RSPAN?
> > >
> > >The docs are a bit vague on this.
> > >
> > >Thanks in advance.
> > >
> > >Daniel
> > >
> > >
> > >
> > >*********************************************************************
> > >*
> > >This email and any files transmitted with it are confidential and
> > >intended solely for the use of the individual or entity to whom they
> > >are addressed. If you have received this email in error please notify
> > >the system manager.
> > >This footnote also confirms that this email message has been swept by
> > >MIMEsweeper for the presence of computer viruses.
> > >www.mimesweeper.com
> >
> >**********************************************************************
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:36:04 GMT-3