It combines as many features of the switch as possible so as to reduce the number of times that a packet traverses the backplane of the switch. In this case the packet is both marked for capture and routed to vlan 10 at the same time. Instead the supervisor just adds a single capture bit to the internal switch packet header, and sends the packet down the backplane of the switch.
So when the packet goes to the backplane of the switch it has already been routed from vlan 1 to vlan 10, and is a vlan 10 packet with a capture bit. As an alternative traffic analysis technique, you could consider using NetFlow.
This is a messaging system that is enabled on all Cisco devices and it will forward just the headers of packets to a central monitor. Once you have all the information at your fingertips about all of the traffic monitoring capabilities of your Cisco switches, you will be in a better position to decide which packet capture method to use.
This site uses Akismet to reduce spam. Learn how your comment data is processed. Comparitech uses cookies. More info. Menu Close. We are funded by our readers and we may receive a commission when you make purchases using the links on our site. Stephen Cooper. The Catalyst Switches support session configuration with the use of source and destination ports that reside on any of the switch stack members.
Therefore, you cannot have two SPAN sessions that use the same destination port. You can configure the SPAN, as in this example:. In order to monitor traffic for a particular vlan that resides in two switches directly connected, configure these commands on the switch that has the destination port. In this example, we monitor traffic from VLAN 5 that is spread across two switches:. The ability to see the If you do not specify the encapsulation keyword, the packets are sent untagged, which is the default in Cisco IOS Software Release RSPAN is not supported in this platform.
Both of these switch platforms use the identical command-line interface CLI of, and a configuration that is similar to, the configuration that the SPAN on the Catalyst , , , , , , , E, , and E Series Switches section covers.
Refer to these documents for the related configuration:. This table summarizes the different features that have been introduced and provides the minimum Cisco IOS Software release that is necessary to run the feature on the specified platform:.
This issue occurs due to a limitation in the packet forwarding architecture of the switch. The SPAN destination port does not perform any check to verify the source of the packets. This allows all traffic subject to egress SPAN to be sent across the fabric to the supervisor and then to the SPAN destination port, which can use significant system resources and affect user traffic.
The ports of the switch are attached to satellites that communicate to a switching fabric via radial channels. On the top, all the satellites are interconnected via a high-speed notify ring that is dedicated to signaling traffic. When a satellite receives a packet from a port, the packet is split into cells and sent to the switching fabric via one or more channels. The packet is then stored in the shared memory.
Each satellite has knowledge of the destination ports. In the diagram in this section, satellite 1 knows that the packet X is to be received by satellites 3 and 4. Satellite 1 sends a message to the other satellites via the notify ring. Then, satellites 3 and 4 can start to retrieve the cells from the shared memory via their radial channels and can eventually forward the packet.
Because the source satellite knows the destination, this satellite also transmits an index that specifies the number of times that this packet is downloaded by the other satellites. Each time a satellite retrieves the packet from the shared memory, this index is decremented.
When the index reaches 0, the shared memory can be released. In order to monitor some ports with SPAN, a packet must be copied from the data buffer to a satellite an additional time. The impact on the high-speed switching fabric is negligible. The monitoring port receives copies of transmitted and received traffic for all monitored ports. In this architecture, a packet that is destined for multiple destinations is stored in memory until all copies are forwarded.
If the monitoring port is 50 percent oversubscribed for a sustained period of time, the port likely becomes congested and holds part of the shared memory. There is a possibility that one or more of the ports that are monitored also experience a slowdown.
This diagram is a high-level overview of the path of a packet through the switch. The actual implementation is, in fact, much more complex:. The data path corresponds to the real transfer of data within the switch, from the control path, where all the decisions are taken. When a packet enters the switch, a buffer is allocated in the Packet Buffer Memory a shared memory.
While the data is copied into shared memory, the control path determines where to switch the packet. In order to make this determination, a hash value is computed from this information:. This virtual path entry in the VPT holds several fields that relate to this particular flow. The fields include the destination ports. The packet structure in the PDT is now updated with a reference to the virtual path and counter.
In the example in this section, the packet is to be transmitted to two different ports, so the counter initializes to 2. Finally, the packet structure is added to the output queue of the two destination ports.
From there, the data copies from the shared memory into the output buffer of the port, and the packet structure counter decrements. When it reaches 0, the shared memory buffer releases. With use of the SPAN feature, a packet must be sent to two different ports, as in the example in the Architecture Overview section.
The send of the packet to two ports is not an issue because the switching fabric is nonblocking. If the destination SPAN port is congested, packets are dropped in the output queue and are correctly released from the shared memory.
Therefore, there is no impact on the switch operation. Every line card in the switch starts to store this packet in internal buffers.
EARL sends the result index to all the line cards via the result bus. The knowledge of this index allows the line card to decide individually whether it should flush or transmit the packet as the line card receives the packet in its buffers.
Whether one or several ports eventually transmit the packet has absolutely no influence on the switch operation. Therefore, when you consider this architecture, the SPAN feature has no impact on the performance. With these versions, only one SPAN session is possible. The session stays in the configuration, even when you disable SPAN. With the issue of the set span enable command, a user reactivates the stored SPAN session. The action often occurs because of a typographical error, for example, if the user wants to enable STP.
Severe connectivity issues can result if the destination port is used to forward user traffic. Caution : This issue is still in the current implementation of the CatOS. Be very careful of the port that you choose as a SPAN destination. When you configure a SPAN session to monitor the port, the destination interface shows the state down monitoring , by design. The creation of a bridging loop typically occurs when the administrator tries to fake the RSPAN feature.
Also, a configuration error can cause the problem. There are two core switches that are linked by a trunk. In this instance, each switch has several servers, clients, or other bridges connected to it. The administrator creates a SPAN session that monitors the whole VLAN 1 on each core switch, and, to merge these two sessions, connects the destination port to the same hub or the same switch, with the use of another SPAN session.
The administrator achieves the goal. A sniffer eventually captures the traffic. The only problem is that the traffic is also reinjected into core 2 through the destination SPAN port. The reinjection of the traffic into core 2 creates a bridging loop in VLAN 1.
Note : Because of the introduction of the inpkts input packets option on the CatOS, a SPAN destination port drops any incoming packet by default, which prevents this failure scenario. Note : Even when the inpkts option prevents the loop, the configuration that this section shows can cause some problems in the network.
Network problems can occur because of MAC address learning issues that are associated with learning enabled on the destination port. See these sections of this document for information about the performance impact for the specified Catalyst platforms:.
Confirming the monitoring session and operation requires one simple command, show monitor session 1 :. To display the detailed information from a saved version of the monitor configuration for a specific session, issue the show monitor session 1 detail command:.
Turning to our network analyser, thanks to its predefined filters we were able to catch packets to and from the worksation monitored:. Back to Cisco Switches Section. Deal with bandwidth spikes Free Download. Web Vulnerability Scanner Free Download. Network Security Scan Download Now.
0コメント