cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2822
Views
0
Helpful
12
Replies

SPAN Issue

stephenshaw
Level 1
Level 1

Hi,

we are implementing a VoIP Recorder (which has not successfully captured both ends of the conversation, only one-way). The actual VoIP call is a two-way conversation - no issues in this regard.

To simply the situation, I connected Wireshark to a 3560 switch port and configured it to monitor one specific port, in both directions (default setting but I specified "both" regardless). The specific port contains an IP phone.

Wireshark does not sniff RTP packets in both directions, only one direction. When we change which phone initiates the call, the same scenario occurs.

This is a local SPAN, the sniffer and both IP phone connected to the exact same switch, the exact same VLANs. I even tried VSPAN but still get the same scenario. This is being done on either a 6513 or a 3560 switch (same result).

Any ideas would be appreciated.

A sample of how it was configured is:

monitor session 1 source interface Fa0/44

monitor session 1 destination interface Fa0/41

Fa0/44 would have the IP phone attached and Fa0/41 is where the sniffer is attached.

Thanks,

Steve

12 Replies 12

wdrootz
Level 4
Level 4

Issue 'show monitor session 1' command and compare with the sample output given below. If it is not same, you may have to remove the source commands and reconfigure.

CatSwitch#show monitor session 1

Session 1

---------

Source Ports:

RX Only: None

TX Only: None

Both: Fa0/44

Destination Ports: Fa0/41

CatSwitch#

Hi,

thanks for the suggestion but I do see this output.

I've tried SPAN on two completely different models (6513 and 3560) but get the exact same result.

I don't view this as an IOS code issue since it's occuring on diverse switches with diverse IOS codes and SPAN has been available now for quite a few years.

Hmmmmmm,

Steve

What about a ping reply? If set up a continuous ping to the devices do you see both the request and reply?

I don't have and VOIP traffic to test my setup with but mine works fine in this setup.

monitor session 1 source interface fastethernet 1/0/1 both

monitor session 1 destination remote vlan 101

on the remote switch i have

monitor session 1 source vlan 101 both

monitor session 1 destination interface fa 1/0/1

I'm running RSPAN because of the way my lab is setup next to my desk, but it doesn't introduce any significant changes in the setup.

What you could try is to monitor the VOIP VLAN instead of the interface.

monitor session 1 source vlan 101 both

monitor session 1 destination interface fa 1/44

HTH

Craig

Thanks Craig,

the first setup tried was using the voice VLAN as the source - only captured one side of the RTP traffic. That's when I changed it to capture on a specific port in which a VoIP call is being made. Only captured one side of the RTP traffic.

I do see traffic in both directions just not RTP traffic. I can see the call setup being done between the IP Phones and the signalling server in both directions.

I no longer view this issue as a configuration problem and certainly don't consider this to be an issue with the switches I've tried testing from.

Most likely it's how the device, being used to capture the RTP traffic, is setup. All information I've seen either here on the Cisco forum or on other Internet forums indicates my configuration is correct.

I do see traffic in both directions just not RTP traffic.

Thanks,

Steve

Hi,

maybe this will not help, but try to take your uplink port as a source (not the one connected to your IP phone).

For example, if the int gi 0/1 of your switch goes to your core or dist. switch, then use this port as a span source and on your sniffer filter only the traffic you want to see.

Just an idea :)

HTH

Regards

Ivan

Hi Ivan,

I am having a meeting with the vendor that supplies the IP phones.

You can't get any simpler than having the two IP phones on the same switch, same VLAN and do a local SPAN - this is one of the reasons I do not suspect it's the configuration of the SPAN that's the issue.

With VoIP, once the call setup is established, the RTP packets (in theory) would only need to be between the two IP phones. This is why I need the vendor involved since there's always a possibility that how the RTP packets flow is not what I anticipate. These are non-Cisco IP phones.

Regards,

Steve

Steve,

Not sure but i just tested it again on one of the 3560's and it seems perfectly fine

see the attched capture

Narayan

Thanks Narayan,

this is what I would expect to see in my captures but don't!

Did you capture this from the Verint server or a standalone sniffer? Is the capture mode "promiscuous?"

Regards,

Steve

To all that participated in this thread,

As a rsolution to the problem encountered ... it was, as I suspected, nothing to do with the SPAN configuration. Rather, the NIC card that was utilized by Wireshark is not a proper "promiscous" card and not capable of picking up all of the packets properly. Once a proper NIC was used, both sides of the conversation were captured.

Thanks,

Steve

johgill
Level 1
Level 1

Note the HW caveat with 3560's where you need "encapsulation replicate" on the monitor session destination session as per:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_25_see/configuration/guide/swspan.html#wp1036816

"On Catalyst 3560-24PS and 3560-48PS switches, egress SPAN routed packets (both unicast and multicast) show the incorrect source MAC address. For local SPAN packets with native encapsulation on the destination port, the packet shows the MAC address of VLAN 1. This problem does not appear with local SPAN when the encapsulation replicate option is used. This limitation does not apply to bridged packets. The workaround is to use the encapsulate replicate keywords in the monitor session global configuration command."

ogormam2
Level 1
Level 1

HI Steve,

im just wondering if you ever got this working, i am having exactly the same problem

thansk

marianne

Hi Ogormam2,

yes, the capturing of the RTP packets was due to a NIC issue.

Also, once this was resolved the actual design (which is still working) was to use a RSPAN to the different floors that need to be monitored and trunk the RSPAN to where the actual VoIP recorder is sitting.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: