So now on Thursday 751 the switch that the monitoring station is connected to confetti monitor session.
We want to configure a spend sessions so we use the session command on the switch Sixty-Six spend sessions
could be configured if we wanted to configure spanne on the 21:15 switch.
It doesn't support the same number of sessions on the switch it only supports two sessions the number
of active spend 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 spend session.
So the source in our example will be the LAN one and I want to capture traffic both St. and received
in Villon one you need to be careful spending a villain if a lot of traffic is transmitted and received
on that.
You could oversubscribed the port as an example if the switch had 24 ports and you spanned all of those
ports to this single interface you would possibly overwhelm the physical interface as another example
you don't want to span a gigabit port to 100 make 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 for one gigabits per second of traffic to a PC with a slow you that
can't capture or handle the amount of traffic that you 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 spam traffic out of this
port.
So now monitus session we need to specify the same session number and we going to specify a destination.
In this case it's going to be a local interface on the switch fast Ethernet 1 0 5.
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 Said do show run piping clewed monitor.
We can get this command as well as the 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 villaine one that's the source destination is port phos
Ethan at 1 0 5.
We're using the native land as the encapsulation ingress traffic is disabled.
So now on the capturing piece will filter it for ICMP and let's restart that capture.
And on Route 1 all ping route to and notice we can see the traffic which we weren't able to see before.
Here is a source ICMP packet from wrote a one note as the MAC address ending in 0 1.
Going to write it to.
It's a unicast here the IP addresses are 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 Rodda to to route one unicast IP addresses.
It's a ping reply.
Now if Router one 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.
Some telnet information while scroll down the road is asking for a password
Here's the password c i s c o.
We could also follow the TZP stream
and we'll be able to see the password in this example because we are capturing traffic safety and received
on the villain.
We're getting some duplicates but as an example if on top enable password show run and look at the running
config of that router if I fall to full telnet traffic again we'll be able to see the line Viti Y and
the password is shown on the line Viti Y in the running config of the rods.
So that's the config on the router.
And here it's seen in the wash or capture.
I could once again follow the TZP stream and I'll see the full configuration of the Rodda as captured
on the monitoring station.
So what's happening now is when traffic is received or sent on villain 1 it's been forwarded out of
this port and the capturing device running was shock is able to view the traffic.
So what we did is create a monitoring session monitor session one capturing and Villon one and the destination
is Fasi Ethan at 1 0 5.
If we remove the monitoring session so do show run piping clewed 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 paying rodef to from Rodda one we don't see any output.
So no ICMP traffic is shown.
If we fail to TELLEMENT
and then telnet to 10 1 1 2 we don't see anything.
But if we put to the monitoring session back to session choose a number one.
And in this case all monitor and interface if one does 0 3 which is this interface over here.
And we'll do both and then we'll specify a destination of FASA Ethan at 1 0 5.
What we should see now is once that kicks in as you can see over there we are able to see the telenet
information.
So is the prompt of rotted too.
And if I scroll up we can see the password so the road is asking for the Enable password and he has
the posture that he typed which is Cisco and then pressed into 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 sessions a show to monitor.
In this example we've got session 1 which is a local section capturing traffic in and out of this port
and it's going to a destination port 1 0 5 kept the nation is native English.
Traffic is disabled.
So let's talk about ingress traffic when you enable spanne 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 road a one painting's Ratatouille it works
and the MAC addresses are shown in the MAC address table but rather one is not able to paying the capturing
device.
So filtering for ICMP the pings are being received from radio one to the PC but no replies are being
accepted by the switch.
So in other words the ping from Radio 1 to the capturing device is received on this port.
And because of the port murthering 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 spend port.
So the pings are failing.
So once again notice there were no successes on the paying from rodder one 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 Fosset Ethan at 1 0 5
and we have to add the option ingress to enable ingress traffic forwarding
and specify that as untagged traffic in the.
One cell start to the capture again
and let's see if Rodda one is able to ping that capturing station notice the pings succeed.
Here's the ping from one 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 of the watch shall capture one ping ping sent from Rodda one.
Here's the reply.
We've seen duplicates because we are looking at traffic sent and received on the port.
So we are 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 the interface but with the ingress option it can be received
and the device is allowed to participate in the network.