From: Chris Home (clarson52@comcast.net)
Date: Wed Apr 23 2003 - 23:25:14 GMT-3
Is rspan specific to the 3550? I have only read about it recently in the
3550 docs and never had an occasion to look on a 6500. Is it available on
both?
----- Original Message -----
From: "Chris Home" <clarson52@comcast.net>
To: "Mike Williams" <ccie2be@swbell.net>; "'David Buechner'"
<dbuechn@attglobal.net>; <ccielab@groupstudy.com>
Sent: Wednesday, April 23, 2003 10:15 PM
Subject: Re: 3550 - RSPAN - Reflector Port
> 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