Packet Tracer file (PT Version 7.1): https://goo.gl/aaFD6n
Get the Packet Tracer course for only $10 by clicking here: https://goo.gl/vikgKN
Get my ICND1 and ICND2 courses for $10 here: https://goo.gl/XR1xm9 (you will get ICND2 as a free bonus when you buy the ICND1 course).
For lots more content, visit http://www.davidbombal.com – learn about GNS3, CCNA, Packet Tracer, Python, Ansible and much, much more.
#CCNA #PacketTracer #CCENT
Local SPAN-The SPAN feature is local when the monitored ports are all located on the same switch as the destination port. This feature is in contrast to Remote SPAN (RSPAN), which this list also defines.
Remote SPAN (RSPAN)-Some source ports are not located on the same switch as the destination port. RSPAN is an advanced feature that requires a special VLAN to carry the traffic that is monitored by SPAN between switches. RSPAN is not supported on all switches. Check the respective release notes or configuration guide to see if you can use RSPAN on the switch that you deploy.
Port-based SPAN (PSPAN)-The user specifies one or several source ports on the switch and one destination port.
VLAN-based SPAN (VSPAN)-On a particular switch, the user can choose to monitor all the ports that belong to a particular VLAN in a single command.
Local SPAN Overview
A local SPAN session is an association of source ports and source VLANs with one or more destinations. You configure a local SPAN session on a single switch. Local SPAN does not have separate source and destination sessions.
Local SPAN sessions do not copy locally sourced RSPAN VLAN traffic from source trunk ports that carry RSPAN VLANs. Local SPAN sessions do not copy locally sourced RSPAN GRE-encapsulated traffic from source ports.
Each local SPAN session can have either ports or VLANs as sources, but not both.
You can analyze network traffic passing through ports or VLANs by using SPAN or RSPAN to send a copy of the traffic to another port on the switch or on another switch that has been connected to a network analyzer or other monitoring or security device. SPAN copies (or mirrors) traffic received or sent (or both) on source ports or source VLANs to a destination port for analysis. SPAN does not affect the switching of network traffic on the source ports or VLANs. You must dedicate the destination port for SPAN use. Except for traffic that is required for the SPAN or RSPAN session, destination ports do not receive or forward traffic.
Only traffic that enters or leaves source ports or traffic that enters or leaves source VLANs can be monitored by using SPAN; traffic routed to a source VLAN cannot be monitored. For example, if incoming traffic is being monitored, traffic that gets routed from another VLAN to the source VLAN cannot be monitored; however, traffic that is received on the source VLAN and routed to another VLAN can be monitored.
You can use the SPAN or RSPAN destination port to inject traffic from a network security device. For example, if you connect a Cisco Intrusion Detection System (IDS) sensor appliance to a destination port, the IDS device can send TCP reset packets to close down the TCP session of a suspected attacker.
Local SPAN supports a SPAN session entirely within one switch; all source ports or source VLANs and destination ports are in the same switch or switch stack. Local SPAN copies traffic from one or more source ports in any VLAN or from one or more VLANs to a destination port for analysis.
Transcription:
Cisco CCNA Packet Tracer Ultimate labs: Local SPAN: Can you complete the lab?
5:49
In this lab, you need to configure local span or local switch port analyzer or local port monitoring. We have two topologies in this lab.
In the first topology, you need to configure local span so that all traffic sent and received by PC 1 is copied to PC 2.
For verification, use simulation mode in packet tracer to verify that ICMP packets sent and received from PC 1 to PC 3 are copied to PC 2.
Also use a simulation mode to verify that ICMP packets sent by PC 3 to PC 4 are not copied to PC 2.
So in other words, when you’ve configured port monitoring correctly traffic from PC 1 to PC 3 for example, will be copied to PC 2, but packets sent from PC 3 to PC 4 will not be copied to PC 2. By default, switches don’t flood Unicast packets.
So as an example, if PC 1 with IP address of 10.1.1.1 pings PC 3 with IP address 10.1.1.3 the Unicast packets will not be sent to PC 2.
The ARP broadcast will but notice this ARP reply which Unicast from PC 3 to PC 1 is not going to be copied to PC 2 and neither are ICMP messages.
So ICMP messages are sent directly between PC 1 and PC 3. PC 2 doesn’t see those ICMP messages or ICMP packets if you like….
