1 00:00:01,000 --> 00:00:09,190 So now on 3751 the switch that the monitoring station is connected to CONFT 2 00:00:11,000 --> 00:00:11,690 monitor, 3 00:00:13,070 --> 00:00:13,730 session. 4 00:00:15,020 --> 00:00:22,910 We want to configure a SPAN session so we use the session command. On this switch, 66 SPAN sessions 5 00:00:22,910 --> 00:00:30,350 could be configured if we wanted to configure SPAN on the 2950 switch it doesn't support 6 00:00:30,350 --> 00:00:33,860 the same number of sessions on this switch 7 00:00:33,860 --> 00:00:35,660 it only supports two sessions. 8 00:00:36,830 --> 00:00:41,220 The number of active SPAN sessions, however, is switch-dependent. 9 00:00:41,300 --> 00:00:43,220 Have a look at the documentation of the switch. 10 00:00:44,900 --> 00:00:51,190 Here, we'll simply configure session one to keep it simple, we need to specify a source as well as 11 00:00:51,200 --> 00:00:53,900 a destination of the SPAN session. 12 00:00:54,230 --> 00:00:59,210 So the source in our example will be VLAN 1 13 00:01:00,750 --> 00:01:05,550 and I want to capture traffic both sent and received in VLAN 1. 14 00:01:06,890 --> 00:01:14,210 You need to be careful spanning a VLAN if a lot of traffic is transmitted and received on that VLAN, 15 00:01:14,480 --> 00:01:21,050 you could oversubscribe the port as an example of this switch had 24 ports and you spanned all of 16 00:01:21,050 --> 00:01:23,810 those ports to this single interface. 17 00:01:24,410 --> 00:01:28,010 You would possibly overwhelm this physical interface. 18 00:01:28,550 --> 00:01:33,110 As another example, you don't want to span a gigabit port to 100 meg port 19 00:01:33,380 --> 00:01:38,630 and in the same way, you need to make sure that you're capturing device can handle the traffic that 20 00:01:38,630 --> 00:01:39,370 it's receiving. 21 00:01:39,830 --> 00:01:47,270 You don't want to, as an example, forward 1 gigabit per second of traffic to PC with a slow CPU 22 00:01:47,630 --> 00:01:52,250 that can't capture or handle the amount of traffic that you're throwing at it. 23 00:01:52,880 --> 00:02:01,400 As an analogy, we as people may drink water from a glass or from a tap, but generally not from a fire 24 00:02:01,400 --> 00:02:08,820 hydrant, because the rate of water that's sent out of a fire hydrant is far more than you can drink. 25 00:02:09,139 --> 00:02:17,000 So don't overload or overwhelm the port as well as the PC by sending too much SPAN traffic out of this 26 00:02:17,000 --> 00:02:17,370 port. 27 00:02:18,350 --> 00:02:25,340 So now monitor session, we need to specify the same session number and we're going to specify a 28 00:02:25,340 --> 00:02:27,740 destination in this case 29 00:02:28,250 --> 00:02:30,650 it's going to be a local interface on the switch, 30 00:02:31,190 --> 00:02:34,190 FastEthernet 105. 31 00:02:35,670 --> 00:02:39,970 I'll talk about the encapsulation and ingress options in a moment. 32 00:02:40,550 --> 00:02:44,030 For now, we're just going to forward the traffic out of the port. 33 00:02:44,540 --> 00:02:45,920 So do show run pipe 34 00:02:45,920 --> 00:02:47,630 include monitor. 35 00:02:50,330 --> 00:02:56,660 We configured this command as well as this command on the switch show monitor. 36 00:02:59,350 --> 00:03:05,020 We can see that we have one active session, it's a local session, it's looking at traffic sent and 37 00:03:05,020 --> 00:03:12,070 received on VLAN 1 that's the source destination is port FastEthernet 105. 38 00:03:12,670 --> 00:03:18,430 We're using the native VLAN as the encapsulation ingress traffic is disabled. 39 00:03:20,870 --> 00:03:24,650 So now on the capturing PC we'll filter for ICMP 40 00:03:25,750 --> 00:03:27,580 and let's restart that capture 41 00:03:30,280 --> 00:03:35,290 and on router 1, I'll ping router 2 42 00:03:36,360 --> 00:03:40,680 and notice, we can see the traffic, which we weren't able to see before. 43 00:03:41,870 --> 00:03:49,730 Here is a source ICMP packet from router 1 notice the Mac address ending in 01 going to 44 00:03:49,730 --> 00:03:50,500 router 2 45 00:03:50,810 --> 00:03:52,160 it's a unicast. 46 00:03:53,690 --> 00:03:57,120 Here are the IP addresses of 10.1.1.1 going to 10.1.1.2 47 00:03:57,860 --> 00:03:59,080 it's an echo request. 48 00:03:59,570 --> 00:04:00,770 Here's the reply. 49 00:04:01,950 --> 00:04:07,680 It's also a unicast frame from router 2 to router 1. 50 00:04:09,650 --> 00:04:21,290 Unicast IP addresses, it's a ping reply. Now if router 1 telnet to router 2 and logs in, we should 51 00:04:21,290 --> 00:04:25,520 be able to see that telnet traffic on the capturing device 52 00:04:25,520 --> 00:04:26,390 and we can. 53 00:04:27,520 --> 00:04:33,820 So notice as an example, here's some telnet information, I'll scroll down. 54 00:04:36,420 --> 00:04:38,280 The routers asking for a password, 55 00:04:40,820 --> 00:04:44,330 here's the password CISCO. 56 00:04:45,430 --> 00:04:47,620 We could also follow the TCP stream 57 00:04:50,360 --> 00:04:52,010 and we'll be able to see the password. 58 00:04:52,950 --> 00:04:57,870 In this example, because we are capturing traffic sent and received on the VLAN, we're getting some 59 00:04:57,870 --> 00:04:58,590 duplicates. 60 00:05:00,130 --> 00:05:04,530 But as an example, if I type enable password, show run 61 00:05:06,580 --> 00:05:09,520 and look at the running config of that router 62 00:05:12,050 --> 00:05:15,260 if I filter for telnet traffic again 63 00:05:17,770 --> 00:05:19,090 we'll be able to see 64 00:05:21,010 --> 00:05:28,330 the line VTY and the password is shown on the line VTY in the running-config of the router. So that's 65 00:05:28,330 --> 00:05:33,330 the config on the router and here it's seen in the wireshark capture. 66 00:05:34,270 --> 00:05:42,940 I could once again follow the TCP stream and I'll see the full configuration of the router as captured 67 00:05:42,940 --> 00:05:44,140 on the monitoring station. 68 00:05:45,280 --> 00:05:50,740 So what's happening now is when traffic is received or sent on VLAN 1 it's been forwarded out of 69 00:05:50,740 --> 00:05:55,040 this port and the capturing device running Wireshark is able to view the traffic. 70 00:05:56,110 --> 00:06:03,040 So what we did is create a monitoring session, monitor session 1, capturing on VLAN 1, and the 71 00:06:03,040 --> 00:06:09,880 destination is FastEthernet 105. If we remove the monitoring session 72 00:06:12,310 --> 00:06:14,920 so do show run pipe include monitor. 73 00:06:17,340 --> 00:06:20,880 We can see that there's no output, in other words, the monitoring session has been removed. 74 00:06:23,270 --> 00:06:24,950 Now, when we do the capture 75 00:06:30,720 --> 00:06:33,420 and we for instance filter for ICMP traffic 76 00:06:35,670 --> 00:06:44,340 and ping router 2 from router 1 we don't see any output, so no ICMP traffic is shown. 77 00:06:45,390 --> 00:06:47,100 If we filter for telnet 78 00:06:49,870 --> 00:06:52,810 and then telnet to 10.1.1.2 79 00:06:54,790 --> 00:07:03,790 we don't see anything, but if we put the monitoring session back. So monitor session, choose 80 00:07:03,790 --> 00:07:11,500 a number 1 and in this case, I'll monitor an interface f103 which is this interface 81 00:07:11,500 --> 00:07:12,100 over here 82 00:07:14,140 --> 00:07:19,150 and we'll do both and then we'll specify a destination 83 00:07:21,270 --> 00:07:25,200 of FastEthernet 105. 84 00:07:26,630 --> 00:07:35,990 What we should see now is once that kicks in, as you can see over there, we are able to see the telnet 85 00:07:36,380 --> 00:07:37,090 information. 86 00:07:37,700 --> 00:07:39,390 So there's the prompt of router 2 87 00:07:39,410 --> 00:07:42,130 and if I scroll up, we can see the password. 88 00:07:42,140 --> 00:07:49,070 So the routers asking for a enable password and he has the password that I typed, which is CISCO and 89 00:07:49,070 --> 00:07:53,000 then I pressed enter. Once again, if we follow that stream 90 00:07:54,110 --> 00:07:55,910 you can see the password that was typed. 91 00:07:58,220 --> 00:08:03,500 So it's as simple as that to create a monitoring session, so show monitor. 92 00:08:04,730 --> 00:08:12,560 In this example, we've got session 1 which is a local session, capturing traffic in and out of 93 00:08:12,650 --> 00:08:20,120 this port, and it's going to this destination port 105, 94 00:08:21,040 --> 00:08:23,600 encapsulation is native, ingress 95 00:08:23,620 --> 00:08:27,010 traffic is disabled. So let's talk about ingress traffic 96 00:08:28,530 --> 00:08:38,100 when you enable span on a switch, as we've got over here, the switch no longer learns Mac addresses 97 00:08:38,610 --> 00:08:41,030 on the span destination port. 98 00:08:41,669 --> 00:08:46,270 It also doesn't allow traffic to be received from that port. 99 00:08:47,220 --> 00:08:52,380 So if router 1 pings router 2, it works 100 00:08:55,190 --> 00:09:03,530 and the mac addresses are shown in the mac address table, but router 1 is not able to ping the capturing 101 00:09:03,530 --> 00:09:04,100 device. 102 00:09:05,210 --> 00:09:07,490 So filtering for ICMP 103 00:09:09,630 --> 00:09:19,150 the pings are being received from router 1 to the PC, but no replies are being accepted by the switch. 104 00:09:19,680 --> 00:09:25,980 So in other words, the ping from router 1 to the capturing device is received on this port 105 00:09:26,340 --> 00:09:32,760 and because of the port mirroring or span, the traffic is being sent out of this port and is received 106 00:09:32,760 --> 00:09:34,010 by the capturing device 107 00:09:34,440 --> 00:09:41,130 but when the capturing device replies that traffic is not accepted on the destination span port, so 108 00:09:41,130 --> 00:09:42,120 the pings are failing. 109 00:09:44,760 --> 00:09:52,170 So once again, notice there were no successes on the ping from router 1 to the capturing device and 110 00:09:52,170 --> 00:09:53,100 just to confirm 111 00:09:54,870 --> 00:10:02,370 that is the IP address of the capturing device, if we want to allow that device to send traffic, we 112 00:10:02,370 --> 00:10:07,430 have to configure the monitoring session to receive that traffic. 113 00:10:08,100 --> 00:10:11,370 So destination interface is Fast 114 00:10:11,370 --> 00:10:13,380 Ethernet 105 115 00:10:16,450 --> 00:10:21,070 and we have to add this option ingress to enable ingress traffic forwarding 116 00:10:23,790 --> 00:10:34,620 and to specify that is untagged traffic in VLAN 1. So I'll start the capture again 117 00:10:38,170 --> 00:10:44,200 and let's see if router 1 is able to ping that capturing station. 118 00:10:46,070 --> 00:10:53,900 Notice the ping succeed, here's the ping from router 1 to the capturing device, here's the reply and the 119 00:10:53,900 --> 00:10:54,990 pings succeeded. 120 00:10:55,970 --> 00:10:58,910 So just to prove that again, I'll do a repeat of just one. 121 00:11:01,990 --> 00:11:04,720 Play the Wireshark capture one ping, 122 00:11:06,090 --> 00:11:13,800 there's the ping sent from router 1 here's the reply, we've seen duplicates because we are looking 123 00:11:13,800 --> 00:11:16,950 at traffic sent and received on this port. 124 00:11:17,280 --> 00:11:23,670 So we're receiving duplicates because we are sending traffic to the monitoring station that's received 125 00:11:23,670 --> 00:11:25,680 or transmitted on this port. 126 00:11:26,130 --> 00:11:27,450 So we get some duplicates. 127 00:11:28,430 --> 00:11:41,960 But the point to remember is that if we don't use the ingress command, the monitoring station is not 128 00:11:41,960 --> 00:11:44,140 able to participate in the network. 129 00:11:44,660 --> 00:11:48,320 Essentially the Mac address is removed from the Mac address table. 130 00:11:50,120 --> 00:11:53,070 So the Mac address is not learnt, as you can see over here. 131 00:11:53,810 --> 00:12:02,180 Traffic is not allowed to be received on this interface, but with the ingress option, it can be received 132 00:12:03,580 --> 00:12:06,580 and the devices allowed to participate in the network.