From: Chris Home (clarson52@comcast.net)
Date: Wed Apr 23 2003 - 19:52:43 GMT-3
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_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:04 GMT-3