From: Volkov, Dmitry (IDS Canada) (dmitry_volkov@ca.ml.com)
Date: Thu Apr 24 2003 - 12:24:58 GMT-3
Chris,
What is the document You refer to ?
Dmitry Volkov
CCIE # 10292
> -----Original Message-----
> From: Chris Home [mailto:clarson52@comcast.net]
> Sent: Wednesday, April 23, 2003 6: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/product
s_configuratio
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:05 GMT-3