SCCP, MGCP and EIGRP (Cisco Protocols) not supported in Microsoft NetMon

Mar 15, 2013 at 6:28 PM
Hey Everyone,

I love using Microsoft NetMon, but I was wondering why it doesn't support Cisco proprietary protocols such as SCCP, MGCP, and EIGRP (Although EIGRP recently became Open Standard). I would love to see those added to the support of this program, but I'm not much of a coder :(.

Thanks!

John
Mar 18, 2013 at 1:34 PM
If you mean proprietary, there is no public documentation, then that would be a problem. And for Network Monitor, it's at the end of it's life as we are moving on to Message Analyzer (http://blogs.technet.com/MessageAnalyzer).

But I you know of detailed RFC or specification, we could put it on our list for Message Analyzer. Also perhaps you could add some justification here so we understand why it might be a priority for you. It would be nice to understand how you troubleshoot with these protocols and in what scenarios they are important for you.

Thanks,

Paul
Mar 18, 2013 at 4:12 PM
Hey Paul,

Thanks for the reply Paul. The protocols SCCP and MGCP are pretty well known protocols in Cisco VoIP. For example, SCCP is used for Cisco IP phones to register with the Cisco Unified Communications Manager (CallManager) and analyzing the transactions between the two can help determine issues with registration. MGCP is also a call-processing protocol. EIGRP as you may know is a Routing protocol. Unfortunately I cannot find RFCs or detailed specifications for SCCP, but there are for EIGRP and MGCP. Here is all the info I can gather on them:

SCCP = Skinny Call Control Protocol (Usually just referred to as Skinny)
Runs over TCP, on port 2000
Note: This shouldn't be confused with the Signalling Connection Control Part from SS7 Signalling Stack
http://en.wikipedia.org/wiki/Skinny_Call_Control_Protocol
http://wiki.wireshark.org/SKINNY

EIGRP = Enhanced Interior Gateway Routing Protocol
RFC = http://tools.ietf.org/html/draft-savage-eigrp-00

MGCP = Media Gateway Control Protocol
RFC = http://www.ietf.org/rfc/rfc2705.txt

By the way, thanks for letting me know that Message Analyzer was the new NetMon. I installed it already, although it does look a bit more confusing than Network Monitor. For example, it's not clear how to choose which Network Interface I want to monitor because the names are not the same as the connection names. Also when I open up a previous capture, I cannot separate the traffic based on which application it was using. I hope these will be addressed in the final release.

Thanks!

John
Mar 19, 2013 at 4:13 PM
Yes, thanks for the documentation pointers. That will help.

Regarding the Network Interface, it's certainly has changed. We now have Trace Scenarios because we are more than just a network sniffer, we can analyze many streams of data from different sources and formats. However, I see where we could make it easier to support the "Capture From Network Interface" scenario. At this point Link Layer captures all Network Interfaces by default. And you could take that as a start and create a scenario you would use most often and save it to the list. So perhaps that's a mitigation for now.

Regarding the previous capture and process info, we haven't implemented that yet. But it's on our radar and if we don't get it for v1, you won't have to wait too long for a refresh of some sort.

In terms of what you need to analyze this traffic, what do you use? Do you think that our visualizations could help? What types of diagnosis would help you see problems?

Thanks,

Paul
Mar 19, 2013 at 7:27 PM
Edited Mar 19, 2013 at 8:03 PM
Hey Paul,

Other than Microsoft Network Monitor, I primarily use another network packet capture/analyzer called Wireshark, which is also a free program. It is pretty much the Gold Standard when it comes to network packet capture analysis. What it does is that it allows you to choose which network interface(s) on your machine that you want to analyze packets and it will capture all of them. When you click on an individual packet in a trace, it separates all of layers according to the Internet/OSI model (i.e. Physical Layer, Data-Link Layer, Network Layer, Transport Layer, and Application Layer). It recognizes pretty much every known protocol in the market today, and if it detects it, you can add a filter to show only packets from that protocol. What's even more impressive for me as a VoIP specialist, is that it has a "VoIP Calls" option which allows you to view all VoIP calls that passed through the interface, and it will show a graph of the message and media transactions between all nodes involved.

However, There are a couple of flaws with Wireshark. They are:

1) Does not support all interfaces types on a Windows Machine, ie. VPN connections, Some IPv6 Tunnel Broker client interfaces

2) Choosing a network interface to capture is not always entirely clear as it shows it's Device ID rather than what is named in Windows Network Connections
For example: In Network Connections, one interface is named "Wireless Network Connection". In Wireshark, it's shown as "Microsoft: \Device\NPF_{4C968491-1244-4B63-916D-62EAD36268DE}". Message Analyzer (and NetMon) also did this, and I would like to see at least some kind of clear-cut correlation of the two.

3) You cannot separate traffic via the application that used it in Wireshark. For example: In Microsoft Network Monitor, with my VoIP Phone client program, I was able to see all transactions between the VoIP client and the VoIP server. This cannot be done in Wireshark, and I have not seen it in Message Analyzer. This is a feature that should have been passed over from Network Monitor to Message Analyzer, so please bring it back!

4) Packet capture sizes can become quite large over small periods of time and you may not even be able to open a capture that you made if it becomes too big.

Overall, if Wireshark addressed these issues, it would be perfect. In my opinion, if you can model the network analysis portion of Message Analyzer to mirror Wireshark while addressing all of Wiresharks short-comings as mentioned above, there's no question I would use Message Analyzer. But for now, I'll continue to use the combination of Wireshark and Network Monitor for my packet analysis needs! I'll say this though, Network Monitor was on the right track, it just lacked the protocol support (ie. Skinny, MGCP, EIGRP) and didn't have the graph options or VoIP call options.

I hope this helps. Let me know if you need any more opinions. I am glad to help!

Thanks,

John
Mar 19, 2013 at 10:36 PM
Hey Paul,

Up until I found out about Microsoft Network Monitor, I was using another network packet capture/analyzer called Wireshark, which is also a free program. It is pretty much the Gold Standard when it comes to network packet capture analysis. What it does is that it allows you to choose which network interface(s) on your machine that you want to analyze packets and it will capture all of them. When you click on an individual packet in a trace, it separates all of layers according to the Internet/OSI model (i.e. Physical Layer, Data-Link Layer, Network Layer, Transport Layer, and Application Layer). It recognizes pretty much every known protocol in the market today, and if it detects it, you can add a filter to show only packets from that protocol. What's even more impressive for me as a VoIP specialist, is that it has a "VoIP Calls" option which allows you to view all VoIP calls that passed through the interface, and it will show a graph of the message and media transactions between all nodes involved.

However, There are a couple of flaws with Wireshark. They are:

1) Does not support all interfaces types on a Windows Machine, ie. VPN connections, Some IPv6 Tunnel Broker client interfaces

2) Choosing a network interface to capture is not always entirely clear as it shows it's Device ID rather than what is named in Windows Network Connections
For example: In Network Connections, one interface is named "Wireless Network Connection". In Wireshark, it's shown as "Microsoft: \Device\NPF_{4C968491-1244-4B63-916D-62EAD36268DE}". Message Analyzer (and NetMon) also did this, and I would like to see at least some kind of clear-cut correlation of the two.

3) You cannot separate traffic via the application that used it in Wireshark. For example: In Microsoft Network Monitor, with my VoIP Phone client program, I was able to see all transactions between the VoIP client and the VoIP server. This cannot be done in Wireshark, and I have not seen it in Message Analyzer. This is a feature that should have been passed over from Network Monitor to Message Analyzer, so please bring it back!

4) Packet capture sizes can become quite large over small periods of time and you may not even be able to open a capture that you made if it becomes too big.

Overall, if Wireshark addressed these issues, it would be perfect. In my opinion, if you can model the network analysis portion of Message Analyzer to mirror Wireshark while addressing all of Wiresharks short-comings as mentioned above, there's no question I would use Message Analyzer. But for now, I'll continue to use the combination of Wireshark and Network Monitor for my packet analysis needs! I'll say this though, Network Monitor was on the right track, it just lacked the protocol support (ie. Skinny, MGCP, EIGRP) and didn't have the graph options or VoIP call options.

I hope this helps. Let me know if you need any more opinions. I am glad to help!

Thanks,

John
Mar 20, 2013 at 3:46 PM
Hey Paul,

Up until I found out about Microsoft Network Monitor, I was using another network packet capture/analyzer called Wireshark, which is also a free program. It is pretty much the Gold Standard when it comes to network packet capture analysis. What it does is that it allows you to choose which network interface(s) on your machine that you want to analyze packets and it will capture all of them. When you click on an individual packet in a trace, it separates all of layers according to the Internet/OSI model (i.e. Physical Layer, Data-Link Layer, Network Layer, Transport Layer, and Application Layer). It recognizes pretty much every known protocol in the market today, and if it detects it, you can add a filter to show only packets from that protocol. What's even more impressive for me as a VoIP specialist, is that it has a "VoIP Calls" option which allows you to view all VoIP calls that passed through the interface, and it will show a graph of the message and media transactions between all nodes involved.

However, There are a couple of flaws with Wireshark. They are:

1) Does not support all interfaces types on a Windows Machine, ie. VPN connections, Some IPv6 Tunnel Broker client interfaces

2) Choosing a network interface to capture is not always entirely clear as it shows it's Device ID rather than what is named in Windows Network Connections
For example: In Network Connections, one interface is named "Wireless Network Connection". In Wireshark, it's shown as "Microsoft: \Device\NPF_{4C968491-1244-4B63-916D-62EAD36268DE}". Message Analyzer (and NetMon) also did this, and I would like to see at least some kind of clear-cut correlation of the two.

3) You cannot separate traffic via the application that used it in Wireshark. For example: In Microsoft Network Monitor, with my VoIP Phone client program, I was able to see all transactions between the VoIP client and the VoIP server. This cannot be done in Wireshark, and I have not seen it in Message Analyzer. This is a feature that should have been passed over from Network Monitor to Message Analyzer, so please bring it back!

4) Packet capture sizes can become quite large over small periods of time and you may not even be able to open a capture that you made if it becomes too big.

Overall, if Wireshark addressed these issues, it would be perfect. In my opinion, if you can model the network analysis portion of Message Analyzer to mirror Wireshark while addressing all of Wiresharks short-comings as mentioned above, there's no question I would use Message Analyzer. But for now, I'll continue to use the combination of Wireshark and Network Monitor for my packet analysis needs! I'll say this though, Network Monitor was on the right track, it just lacked the protocol support (ie. Skinny, MGCP, EIGRP) and didn't have the graph options or VoIP call options.

I hope this helps. Let me know if you need any more opinions. I am glad to help!

Thanks,

John
Mar 20, 2013 at 4:32 PM
Hey Paul,

Up until I found out about Microsoft Network Monitor, I was using another network packet capture/analyzer called Wireshark, which is also a free program. It is pretty much the Gold Standard when it comes to network packet capture analysis. What it does is that it allows you to choose which network interface(s) on your machine that you want to analyze packets and it will capture all of them. When you click on an individual packet in a trace, it separates all of layers according to the Internet/OSI model (i.e. Physical Layer, Data-Link Layer, Network Layer, Transport Layer, and Application Layer). It recognizes pretty much every known protocol in the market today, and if it detects it, you can add a filter to show only packets from that protocol. What's even more impressive for me as a VoIP specialist, is that it has a "VoIP Calls" option which allows you to view all VoIP calls that passed through the interface, and it will show a graph of the message and media transactions between all nodes involved.

However, There are a couple of flaws with Wireshark. They are:

1) Does not support all interfaces types on a Windows Machine, ie. VPN connections, Some IPv6 Tunnel Broker client interfaces

2) Choosing a network interface to capture is not always entirely clear as it shows it's Device ID rather than what is named in Windows Network Connections
For example: In Network Connections, one interface is named "Wireless Network Connection". In Wireshark, it's shown as "Microsoft: \Device\NPF_{4C968491-1244-4B63-916D-62EAD36268DE}". Message Analyzer (and NetMon) also did this, and I would like to see at least some kind of clear-cut correlation of the two.

3) You cannot separate traffic via the application that used it in Wireshark. For example: In Microsoft Network Monitor, with my VoIP Phone client program, I was able to see all transactions between the VoIP client and the VoIP server. This cannot be done in Wireshark, and I have not seen it in Message Analyzer. This is a feature that should have been passed over from Network Monitor to Message Analyzer, so please bring it back!

4) Packet capture sizes can become quite large over small periods of time and you may not even be able to open a capture that you made if it becomes too big.

Overall, if Wireshark addressed these issues, it would be perfect. In my opinion, if you can model the network analysis portion of Message Analyzer to mirror Wireshark while addressing all of Wiresharks short-comings as mentioned above, there's no question I would use Message Analyzer. But for now, I'll continue to use the combination of Wireshark and Network Monitor for my packet analysis needs! I'll say this though, Network Monitor was on the right track, it just lacked the protocol support (ie. Skinny, MGCP, EIGRP) and didn't have the graph options or VoIP call options.

I hope this helps. Let me know if you need any more opinions. I am glad to help!

Thanks,

John