From: Scott Morris (swm@emanon.com)
Date: Sun Dec 28 2003 - 11:55:27 GMT-3
The idea being that you lose the original VLAN tag associated with the
frame. So if you are attempting to monitor a trunk, or monitor multiple
source VLANs at the same time, then you will lose all reference to where
the packets originally came from. It's as if the rspan VLAN information
overwrites any existing VLAN information (whether dot1q or isl) that was
previously on the frame.
I found (IMHO) a better explanation at:
http://www.cisco.com/en/US/products/hw/switches/ps646/products_configura
tion_guide_chapter09186a008011594e.html#xtocid20
HTH,
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
CISSP, JNCIS, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Soup Shi
Sent: Sunday, December 28, 2003 1:43 AM
To: ccielab@groupstudy.com
Subject: SPAN/RSPAN encapsulation
Hi, group,
A simple question that confuses me for a long time is the encapsulation
of
the SPAN/RSPAN destination port. If not set, the docCD says it is in
'native' mode, which I think is no-tagging mode. If so, there is no way
to
tell traffic from different VLAN if we want to monitor a trunk
interface.Does it mean in this case, we have to encapsulate dot1Q or ISL
on
the destination port and use an analyser with NIC card supporting trunk?
By the way, since the prune may filter the RSPAN vlan crossing switches,
I
should disable the prune for the specific VLAN as needed. The docCD
mentions
it several times, but it makes things more unclear.
Any comments?
(Thanks, Scott, you are so helpful.)
Soup
This archive was generated by hypermail 2.1.4 : Sat Jan 03 2004 - 08:25:45 GMT-3