So now on 3751 the switch that the monitoring station is connected to CONFT
monitor,
session.
We want to configure a SPAN session so we use the session command. On this switch, 66 SPAN sessions
could be configured if we wanted to configure SPAN on the 2950 switch it doesn't support
the same number of sessions on this switch
it only supports two sessions.
The number of active SPAN sessions, however, is switch-dependent.
Have a look at the documentation of the switch.
Here, we'll simply configure session one to keep it simple, we need to specify a source as well as
a destination of the SPAN session.
So the source in our example will be VLAN 1
and I want to capture traffic both sent and received in VLAN 1.
You need to be careful spanning a VLAN if a lot of traffic is transmitted and received on that VLAN,
you could oversubscribe the port as an example of this switch had 24 ports and you spanned all of
those ports to this single interface.
You would possibly overwhelm this physical interface.
As another example, you don't want to span a gigabit port to 100 meg port
and in the same way, you need to make sure that you're capturing device can handle the traffic that
it's receiving.
You don't want to, as an example, forward 1 gigabit per second of traffic to PC with a slow CPU
that can't capture or handle the amount of traffic that you're throwing at it.
As an analogy, we as people may drink water from a glass or from a tap, but generally not from a fire
hydrant, because the rate of water that's sent out of a fire hydrant is far more than you can drink.
So don't overload or overwhelm the port as well as the PC by sending too much SPAN traffic out of this
port.
So now monitor session, we need to specify the same session number and we're going to specify a
destination in this case
it's going to be a local interface on the switch,
FastEthernet 105.
I'll talk about the encapsulation and ingress options in a moment.
For now, we're just going to forward the traffic out of the port.
So do show run pipe
include monitor.
We configured this command as well as this command on the switch show monitor.
We can see that we have one active session, it's a local session, it's looking at traffic sent and
received on VLAN 1 that's the source destination is port FastEthernet 105.
We're using the native VLAN as the encapsulation ingress traffic is disabled.
So now on the capturing PC we'll filter for ICMP
and let's restart that capture
and on router 1, I'll ping router 2
and notice, we can see the traffic, which we weren't able to see before.
Here is a source ICMP packet from router 1 notice the Mac address ending in 01 going to
router 2
it's a unicast.
Here are the IP addresses of 10.1.1.1 going to 10.1.1.2
it's an echo request.
Here's the reply.
It's also a unicast frame from router 2 to router 1.
Unicast IP addresses, it's a ping reply. Now if router 1 telnet to router 2 and logs in, we should
be able to see that telnet traffic on the capturing device
and we can.
So notice as an example, here's some telnet information, I'll scroll down.
The routers asking for a password,
here's the password CISCO.
We could also follow the TCP stream
and we'll be able to see the password.
In this example, because we are capturing traffic sent and received on the VLAN, we're getting some
duplicates.
But as an example, if I type enable password, show run
and look at the running config of that router
if I filter for telnet traffic again
we'll be able to see
the line VTY and the password is shown on the line VTY in the running-config of the router. So that's
the config on the router and here it's seen in the wireshark capture.
I could once again follow the TCP stream and I'll see the full configuration of the router as captured
on the monitoring station.
So what's happening now is when traffic is received or sent on VLAN 1 it's been forwarded out of
this port and the capturing device running Wireshark is able to view the traffic.
So what we did is create a monitoring session, monitor session 1, capturing on VLAN 1, and the
destination is FastEthernet 105. If we remove the monitoring session
so do show run pipe include monitor.
We can see that there's no output, in other words, the monitoring session has been removed.
Now, when we do the capture
and we for instance filter for ICMP traffic
and ping router 2 from router 1 we don't see any output, so no ICMP traffic is shown.
If we filter for telnet
and then telnet to 10.1.1.2
we don't see anything, but if we put the monitoring session back. So monitor session, choose
a number 1 and in this case, I'll monitor an interface f103 which is this interface
over here
and we'll do both and then we'll specify a destination
of FastEthernet 105.
What we should see now is once that kicks in, as you can see over there, we are able to see the telnet
information.
So there's the prompt of router 2
and if I scroll up, we can see the password.
So the routers asking for a enable password and he has the password that I typed, which is CISCO and
then I pressed enter. Once again, if we follow that stream
you can see the password that was typed.
So it's as simple as that to create a monitoring session, so show monitor.
In this example, we've got session 1 which is a local session, capturing traffic in and out of
this port, and it's going to this destination port 105,
encapsulation is native, ingress
traffic is disabled. So let's talk about ingress traffic
when you enable span on a switch, as we've got over here, the switch no longer learns Mac addresses
on the span destination port.
It also doesn't allow traffic to be received from that port.
So if router 1 pings router 2, it works
and the mac addresses are shown in the mac address table, but router 1 is not able to ping the capturing
device.
So filtering for ICMP
the pings are being received from router 1 to the PC, but no replies are being accepted by the switch.
So in other words, the ping from router 1 to the capturing device is received on this port
and because of the port mirroring or span, the traffic is being sent out of this port and is received
by the capturing device
but when the capturing device replies that traffic is not accepted on the destination span port, so
the pings are failing.
So once again, notice there were no successes on the ping from router 1 to the capturing device and
just to confirm
that is the IP address of the capturing device, if we want to allow that device to send traffic, we
have to configure the monitoring session to receive that traffic.
So destination interface is Fast
Ethernet 105
and we have to add this option ingress to enable ingress traffic forwarding
and to specify that is untagged traffic in VLAN 1. So I'll start the capture again
and let's see if router 1 is able to ping that capturing station.
Notice the ping succeed, here's the ping from router 1 to the capturing device, here's the reply and the
pings succeeded.
So just to prove that again, I'll do a repeat of just one.
Play the Wireshark capture one ping,
there's the ping sent from router 1 here's the reply, we've seen duplicates because we are looking
at traffic sent and received on this port.
So we're receiving duplicates because we are sending traffic to the monitoring station that's received
or transmitted on this port.
So we get some duplicates.
But the point to remember is that if we don't use the ingress command, the monitoring station is not
able to participate in the network.
Essentially the Mac address is removed from the Mac address table.
So the Mac address is not learnt, as you can see over here.
Traffic is not allowed to be received on this interface, but with the ingress option, it can be received
and the devices allowed to participate in the network.