Posted: 4/26/2013 8:46:12 PM EDT
I put this in Urban Commandos but I know all the nerds are hanging in General tonight. 
I am trying to span a port on a Cisco 3550 switch. Here is what I am doing Config # monitor session 1 source interface FastEthernet 0/1 Config# monitor session 1 destination interface FastEthernet 0/22 #sh mon session 1 Session 1 --------- Type : Local Session Source Ports : Both : Fa0/1 Destination Ports : Fa0/22 Encapsulation : Native Ingress : Disabled All that I am seeing on port 22 is ARP traffic. What am I doing wrong? Here are the two interfaces. That's possible. Do you see anything obviously wrong? FastEthernet0/1 is up, line protocol is up (connected) FastEthernet0/22 is up, line protocol is down (monitoring) |
|
Quoted:
Post your port and appropriate sh run output perhaps? Sure Current configuration : 2412 bytes |
|
Quoted:
Ingress disabled? Why is that? Is there a VLAN assignment on one of the ports? Is traffic on the source getting a VLAN tag maybe? Perhaps the source port is a VLAN trunk and we don't realize it? I don't have a VLAN assigned to any of the ports. I was under the impression that the Ingress feature was only used for VLAN's. Is that not correct? |
|
Quoted:
Ingress disabled? Why is that? Is there a VLAN assignment on one of the ports? Is traffic on the source getting a VLAN tag maybe? Perhaps the source port is a VLAN trunk and we don't realize it? This. If it is a trunk you only see untagged packets by default on the destination port. |
|
Quoted:
Quoted:
Ingress disabled? Why is that? Is there a VLAN assignment on one of the ports? Is traffic on the source getting a VLAN tag maybe? Perhaps the source port is a VLAN trunk and we don't realize it? This. If it is a trunk you only see untagged packets by default on the destination port. The switchports are currently configured for dynamic desireable. I've also tried setting the destination switchport mode to access. |
|
Do "sh int trunk" and see if the source port has become a trunk.
Do "show spanning-tree vlan 1" and make sure the source port is forwarding traffic on that vlan. Your SPAN config is correct, there isn't a whole lot to it. What you need to do is make sure the traffic you think is transiting port fa0/1 really is, and not going out somewhere else. |
|
Quoted:
Do "sh int trunk" and see if the source port has become a trunk. Do "show spanning-tree vlan 1" and make sure the source port is forwarding traffic on that vlan. I appreciate all the help guys. sac-3550-1#sh int trunk I also just tried changing the fa0/1 source interface to switchport mode access with no change. |
|
Quoted:
Trunk status looks OK. What is on fa0/1, an uplink or a PC / server? If PC / server, try pinging it and you should see the pings come in, at least.... if your capture is set up correctly. Here is the info you requested. sac-3550-1#show spanning-tree vlan 1 Fa0/1 is the "green" side of my firewall. |
|
Quoted:
STP looks good. Vlan 1 is active and forwarding on that port. What are you using as a sniffer on the destination port? Could you have inadvertently activated a filter when you started your capture? I have a linux box sitting on it using tcpdump. All that I am seeing is arp traffic and that is with no filters. tcpdump -i eth2 I've verified that this is the proper interface. |
|
Quoted:
Quoted:
STP looks good. Vlan 1 is active and forwarding on that port. What are you using as a sniffer on the destination port? Could you have inadvertently activated a filter when you started your capture? I have a linux box sitting on it using tcpdump. All that I am seeing is arp traffic and that is with no filters. tcpdump -i eth2 I've verified that this is the proper interface. I assume the FW is active and passing traffic? Verified the arp entry of the FW IP and the corresponding mac address showing up on fa0/1? i.e. ping 192.168.0.1 show ip arp 192.168.0.1 sh mac-address | i [last 4 of mac shown above] |
|
Quoted:
Quoted:
Quoted:
STP looks good. Vlan 1 is active and forwarding on that port. What are you using as a sniffer on the destination port? Could you have inadvertently activated a filter when you started your capture? I have a linux box sitting on it using tcpdump. All that I am seeing is arp traffic and that is with no filters. tcpdump -i eth2 I've verified that this is the proper interface. I assume the FW is active and passing traffic? Verified the arp entry of the FW IP and the corresponding mac address showing up on fa0/1? i.e. ping 192.168.0.1 show ip arp 192.168.0.1 sh mac-address | i [last 4 of mac shown above] The firewall is up and forwarding traffic. sac-3550-1#ping 10.26.0.1 |
| I don't know. I haven't messed around with dynamic vlans too much, so I'm not sure there isn't something weird going on there. Ditto with tcpdump, though I suppose there's always the possibility you aren't tcpdumping the interface you think you are. I can say the monitor session config looks good, though. |
|
Quoted:
I don't know. I haven't messed around with dynamic vlans too much, so I'm not sure there isn't something weird going on there. Ditto with tcpdump, though I suppose there's always the possibility you aren't tcpdumping the interface you think you are. I can say the monitor session config looks good, though. I wouldn't be surprised if it had something to do with the vlan. I've checked the other interfaces on the linux box and they are seeing what they are supposed to see. This switch may need a swift kick in the nuts. |
|
Quoted:
Quoted:
I don't know. I haven't messed around with dynamic vlans too much, so I'm not sure there isn't something weird going on there. Ditto with tcpdump, though I suppose there's always the possibility you aren't tcpdumping the interface you think you are. I can say the monitor session config looks good, though. I wouldn't be surprised if it had something to do with the vlan. I've checked the other interfaces on the linux box and they are seeing what they are supposed to see. This switch may need a swift kick in the nuts. I would change all your ports to "switchport mode access" to take that dynamic config out. The rule of thumb I go by is, if you don't need dynamic vlans, don't use 'em. ETA: you could also try changing your monitor source to vlan 1. |
|
Quoted:
Quoted:
Quoted:
I don't know. I haven't messed around with dynamic vlans too much, so I'm not sure there isn't something weird going on there. Ditto with tcpdump, though I suppose there's always the possibility you aren't tcpdumping the interface you think you are. I can say the monitor session config looks good, though. I wouldn't be surprised if it had something to do with the vlan. I've checked the other interfaces on the linux box and they are seeing what they are supposed to see. This switch may need a swift kick in the nuts. I would change all your ports to "switchport mode access" to take that dynamic config out. The rule of thumb I go by is, if you don't need dynamic vlans, don't use 'em. I'll give it a try, thanks again. |
|
Maybe because the destination port is trunked?
Destination Port Each SPAN session must have a destination port (also called a monitoring port) that receives a copy of traffic from the source port. The destination port has these characteristics: •It must reside on the same switch as the source port. •It can be any Ethernet physical port. •It can participate in only one SPAN session at a time (a destination port in one SPAN session cannot be a destination port for a second SPAN session). •It cannot be a source port. •It cannot be an EtherChannel port or a VLAN. •When it is active, incoming traffic is disabled; it does not forward any traffic except that required for the SPAN session. •It does not participate in spanning tree while the SPAN session is active. •When it is an active destination port, it does not participate in any of the Layer 2 protocols (STP, VTP, CDP, DTP, PagP). •A destination port that belongs to a source VLAN of any SPAN session is excluded from the source list and is not monitored. •No address learning occurs on the destination port. Edit- Scratch that idea. I found the following, so that dest port should not have trunked.... Switchport mode dynamic desirable – This command makes the interface actively attempt to convert the link to a trunk link. The interface becomes a trunk interface if the neighboring interface is set to trunk, desirable, or auto mode. This is the default mode for all Ethernet interfaces. If the neighboring interface is set to the access or non-negotiate mode, the link will become a non-trunking link. |
|
Quoted:
Maybe because the destination port is trunked? Destination Port Each SPAN session must have a destination port (also called a monitoring port) that receives a copy of traffic from the source port. The destination port has these characteristics: •It must reside on the same switch as the source port. •It can be any Ethernet physical port. •It can participate in only one SPAN session at a time (a destination port in one SPAN session cannot be a destination port for a second SPAN session). •It cannot be a source port. •It cannot be an EtherChannel port or a VLAN. •When it is active, incoming traffic is disabled; it does not forward any traffic except that required for the SPAN session. •It does not participate in spanning tree while the SPAN session is active. •When it is an active destination port, it does not participate in any of the Layer 2 protocols (STP, VTP, CDP, DTP, PagP). •A destination port that belongs to a source VLAN of any SPAN session is excluded from the source list and is not monitored. •No address learning occurs on the destination port. Edit- Scratch that idea. I found the following, so that dest port should not have trunked.... Switchport mode dynamic desirable – This command makes the interface actively attempt to convert the link to a trunk link. The interface becomes a trunk interface if the neighboring interface is set to trunk, desirable, or auto mode. This is the default mode for all Ethernet interfaces. If the neighboring interface is set to the access or non-negotiate mode, the link will become a non-trunking link. Would that have shown up with sh int trunk? sac-3550-1#sh int trunk |
|
The 0/22 port is showing some traffic.
5 minute output rate 14000 bits/sec, 11 packets/sec
42038 packets output, 18833405 bytes, 0 underruns Which seems rather high for just ARP traffic. The spanned monitor port looks like it's set up correctly but it's possible your packet capture isn't. I'm a WireShark fan but your tcpdump looks right. Clear counters on that interface and see if the new numbers reflect the span traffic you expect to see. |
|
Quoted:
The 0/22 port is showing some traffic. 5 minute output rate 14000 bits/sec, 11 packets/sec
42038 packets output, 18833405 bytes, 0 underruns Which seems rather high for just ARP traffic. The spanned monitor port looks like it's set up correctly but it's possible your packet capture isn't. I'm a WireShark fan but your tcpdump looks right. Clear counters on that interface and see if the new numbers reflect the span traffic you expect to see. I'll give it a try. Thanks. |
|
Quoted:
The 0/22 port is showing some traffic. 5 minute output rate 14000 bits/sec, 11 packets/sec
42038 packets output, 18833405 bytes, 0 underruns Which seems rather high for just ARP traffic. The spanned monitor port looks like it's set up correctly but it's possible your packet capture isn't. I'm a WireShark fan but your tcpdump looks right. Clear counters on that interface and see if the new numbers reflect the span traffic you expect to see. I am watching it with Wireshark right now. I have ARP, STP and some ocassionaly SSDP. I reset the counters and and waiting for a few minutes to post that info. |
OK, here is a few minutes. Note that I did change the output interface to Fa0/20. I wanted to make sure it wasn't something with the other port I was using.
sac-3550-1#sh int fa0/20 |
|
Quoted:
Quoted:
I'll toss another machine on that port in the morning and see if there is a difference. Keep the recommendations coming, I greatly appreciate it. Are the latest attempts on fa0/20 with this new machine? Is this machine a Linux box? I have not thrown a different linux box on that interface yet. I will do that later today. This is still from the same box. |
|
Quoted: Quoted: Quoted: I'll toss another machine on that port in the morning and see if there is a difference. Keep the recommendations coming, I greatly appreciate it. Are the latest attempts on fa0/20 with this new machine? Is this machine a Linux box? I have not thrown a different linux box on that interface yet. I will do that later today. This is still from the same box. Cool, gotcha. It really is acting like traffic is being firewalled on eth2, somehow. Are you using iptables, or anything like that? |
|
Quoted:
Im thinking your nic on your linux box isnt set to promiscuous mode. This would prevent you from seeing any traffic on that port not destined to that nic. Try typing "ifconfig eth0 promisc" where eth0 is your nic. I hoped like crazy that this was it. The NIC is in promiscuous mode. I'll get a box loaded up in a bit here and see what I can find. ETA: Hrmmmmm, this got me thinking. The linux box is a virtual machine so that interface most likely needs configuration within VMWare. BRB, thanks for the idea. |
I think what bugs me the most about the whole thing is I have already done this with the other side of the firewall.
I even have my home network documented fairly well but I guess I need to document the virtual side of things better. Off to Evernote to put together some reminders. Kind of sad when the home setup starts to become more complex than the work setup 
|
It's nice having full visibility of the home network. Last night I watched as someone made a brute force attempt on my website. They gave up after 13,000+ tries which I feel was a little weak. Sure I could have closed it down with a quick firewall rule but it's more fun to watch.
Again, I appreciate everyone's help. I love being able to bounce things off intelligent people. You don't always get the exact answer but you almost always get something that tips you off and sends you in the right direction. Now to get my IDS moved to a physical box as it's really working my ESX box. |