PAGEME1000
Technical User
Anyone here had any experience of this software solution for traffic monitoring or a switch/routed network?
Cheers
Page
Cheers
Page
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Netscouts nGenius RTM for Cisco Catalyst 6500 3
- Thread starter PAGEME1000
- Start date
- Status
-
1
- #2
I hope to have experience with it soon, as I am preparing a server to load nGenius on. I have had experience with its predecessor, NetScout's TrafficDirector for data capture, measurements, monitoring, etc. I'd be pleased to keep you updated as I get RTM online...
Page
Due to the Code Red virus and other requirements, I had not been able to get RTM online as I had hoped, but I do have it running now and have been testing it as a replacement for TrafficDirector. Part of the evolution included upgrading the Cisco (actually, they are NetScout) Ethernet probes to a new version of firmware. I can tell you right now that I am very pleased with the performance of RTM over TrafficDirector, especially with regard to uploading the packets after doing a capture. Now, let's see if we can work through your's/our concerns!
Mark
Due to the Code Red virus and other requirements, I had not been able to get RTM online as I had hoped, but I do have it running now and have been testing it as a replacement for TrafficDirector. Part of the evolution included upgrading the Cisco (actually, they are NetScout) Ethernet probes to a new version of firmware. I can tell you right now that I am very pleased with the performance of RTM over TrafficDirector, especially with regard to uploading the packets after doing a capture. Now, let's see if we can work through your's/our concerns!
Mark
Hi Page,
NetScout knocks the spots off TD (thank God!). It's fairly easy to configure and the interface/reports are much easier on the eye- and more likely to impress an MIS Manager.
However, it still relies on switchprobes (no surprise there). My companies network have just started using a different solution (dare I say it on this forum?) called Te-Vista by Chevin which doesn't rely on switchprobes, using visibility agents (High Speed RMON) on each segment instead. It's very good- and it costs less than one switchprobe to cover quite a large network.
Just an option,
Martin
ps. I don't work for (or resell for) Chevin!
NetScout knocks the spots off TD (thank God!). It's fairly easy to configure and the interface/reports are much easier on the eye- and more likely to impress an MIS Manager.
However, it still relies on switchprobes (no surprise there). My companies network have just started using a different solution (dare I say it on this forum?) called Te-Vista by Chevin which doesn't rely on switchprobes, using visibility agents (High Speed RMON) on each segment instead. It's very good- and it costs less than one switchprobe to cover quite a large network.
Just an option,
Martin
ps. I don't work for (or resell for) Chevin!
I, like Martin, do agree that RTM blows TD away in many aspects. However, I have two issues that keep me from removing TD at this time. First, although the documentation says that RTM can save packet captures in Sniffer format, a bug prevents this and a fix is due to be released in the next patch for RTM. Second, although the documentation covers the manual setup of a Network Analysis Module (NAM) for a Catalyst 5500 switch, there is nothing that refers to a NAM setup in a Catalyst 6509.
I mentioned "Sniffer" in my first issue. If you are not familiar with SnifferPro from Network Associates, it might be worth your time to take a look. The SnifferPro software will afford any machine on a segment the opportunity to capture all the packets that hit its port, whether they are destined for that machine or being forwarded/discarded. I like SnifferPro's analyzing features where as it has many more options for honing in on faults (i.e. One report which analyzes the packets offers technical diagnosis, symptoms and conversation statistics for each layer.). SnifferPro also allows one to export the host table from a capture into a file which can be imported into your favorite Spreadsheet or Database system.
As much as I like SnifferPro's robust reporting features, it is RTM that is the core to our successful packet captures and data analyzing. Since RTM is web based, that is a very big plus since one does not have to load a stand-alone application and configure all the agents individually on each person's machine. Also, since RTM does not have so many reporting features as SnifferPro, in tense situations it is much faster for performing a quick analysis when time is crucial.
I mentioned "Sniffer" in my first issue. If you are not familiar with SnifferPro from Network Associates, it might be worth your time to take a look. The SnifferPro software will afford any machine on a segment the opportunity to capture all the packets that hit its port, whether they are destined for that machine or being forwarded/discarded. I like SnifferPro's analyzing features where as it has many more options for honing in on faults (i.e. One report which analyzes the packets offers technical diagnosis, symptoms and conversation statistics for each layer.). SnifferPro also allows one to export the host table from a capture into a file which can be imported into your favorite Spreadsheet or Database system.
As much as I like SnifferPro's robust reporting features, it is RTM that is the core to our successful packet captures and data analyzing. Since RTM is web based, that is a very big plus since one does not have to load a stand-alone application and configure all the agents individually on each person's machine. Also, since RTM does not have so many reporting features as SnifferPro, in tense situations it is much faster for performing a quick analysis when time is crucial.
TD is for TrafficDirector, RTM is Real Time Monitor. Both are products developed by NetScout Systems and are bundled with CiscoWorks 2000. Prior to release 3 of CiscoWorks 2000, TrafficDirector was the only (of the two) one bundled. Real Time Monitor, is a solution to replace TrafficDirector. Go to Cisco.com and you'll find lots of info on both.
TD is for TrafficDirector, RTM is Real Time Monitor. Both are products developed by NetScout Systems and are bundled with CiscoWorks 2000. Prior to release 3 of CiscoWorks 2000, TrafficDirector was the only (of the two) one bundled. Real Time Monitor, is a solution to replace TrafficDirector. Go to Cisco.com and you'll find lots of info on both.
-
1
- Thread starter
- #11
PAGEME1000
Technical User
Right Guys
I have installed nGenius 1.2 (was a bit of a struggle)and had good look....I have been told it is a bit antiquated I'can't argue with that...I'm getting 1.3 later today....
It doesn't really keep/store some of the snmp information/data I would have hoped... I am also worried about the through put of the NAM card Network Analysis Module. The network where looking at is 4 core 6509's and around 50 edge 6509's with lots of gig trunking....
The ideal place would be 1 nam card in each core but according to the cisco web site the nam would probably keel over and die....
any thoughts people...
cheers
Page
I have installed nGenius 1.2 (was a bit of a struggle)and had good look....I have been told it is a bit antiquated I'can't argue with that...I'm getting 1.3 later today....
It doesn't really keep/store some of the snmp information/data I would have hoped... I am also worried about the through put of the NAM card Network Analysis Module. The network where looking at is 4 core 6509's and around 50 edge 6509's with lots of gig trunking....
The ideal place would be 1 nam card in each core but according to the cisco web site the nam would probably keel over and die....
any thoughts people...
cheers
Page
Hello Techies
I'm a new user of TD and I've never seen RTM before but I'll be loading it soon. Does the TD requires to have a switch probe to get traffic data? Since the RTM is set to replace TD, does that mean I just set aside using TD and concentrate more on RTM capabilities. Need you advise.
Thanks in advance.
Tekgal
I'm a new user of TD and I've never seen RTM before but I'll be loading it soon. Does the TD requires to have a switch probe to get traffic data? Since the RTM is set to replace TD, does that mean I just set aside using TD and concentrate more on RTM capabilities. Need you advise.
Thanks in advance.
Tekgal
I'm not sure what SNMP data Page is wanting from RTM, but it seems to give everything that TrafficDirector offered. I am having issues with RTM 1.3 that I did not run into with RTM 1.2. I currently have a case I'm working with Cisco over the fact that I cannot launch RTM 1.3 from a client's browser, but I can from the server's browser. This is an issue I did not have with version 1.2. Also, we recently got some 6509 NAMs and I am finding them awkward to setup compared to probes. Two of the three NAMs I have worked with want to go into a "fault" status for some unknown reason. Sometimes a reset of the NAM works to bring it back online, other times it has to be re-seated into the chassis to clear the fault condition. I have yet to get the NAM successfully configured in RTM where as I can do packet captures and decode. The probes, on the other hand, have been almost painless. I realize the probes are much more expensive, and Page's idea of having a NAM in each core switch is credible, but realize that there is a feature called RSPAN, which will allow one to initiate a SPAN session and carry the traffic over a VLAN to another device where the probe is connected for analyzing. That is the solution we are leaning towards, especially since we are deploying lots of CAT 4006s at the access layer and CATOS 6.3 for the 4006 is supposed to support the RSPAN feature. I haven't tested it, but hope to soon.
- Thread starter
- #14
PAGEME1000
Technical User
Hello All
You have to be very careful with the amount of data sent to the nam probe....as it can only handle 39% of single gig trunk sending 256byte packets at full rate ;-) ...o.k I understand you will never generate this amount of data...I was going to place a single NAM card in a core 6509 with 40 gig ports connecting to it.....?
Me tinks a probe would be more robust.....
Pageme
You have to be very careful with the amount of data sent to the nam probe....as it can only handle 39% of single gig trunk sending 256byte packets at full rate ;-) ...o.k I understand you will never generate this amount of data...I was going to place a single NAM card in a core 6509 with 40 gig ports connecting to it.....?
Me tinks a probe would be more robust.....
Pageme
Page,
A probe might give you what you desire. If you use a probe the most common way, which is by SPANing a port vice using the in-line tap, the only limitations are the capabilities of the port. I.e.- A gig port can handle a gig worth of traffic. I don't know if you are familiar with CiscoWorks Windows or Ipswitch Sotware's "What's Up Gold" product, but I believe you can get a free 30-day trial download either from Cisco or ZDNET. CiscoWorks Windows has What's Up Gold included in the suite. What's Up Gold has a MIB tool that will graph the returned MIB values and also store those values in a delimited text file. You can take that text file and import it into a spreadsheet or database application and perform magic with formulas to calculate port utilization. I mention this because, if you do a little research ahead of time on the port(s) you want to monitor, you can get an idea of the amount of traffic you'll be trying to capture. For example, let's say you have more than one gig link from the distribution layer to your one of your core switches. Will you need a gig probe connection for each, or can you get away with SPANing more than one port in a single SPAN session and stay within the destination port's bandwidth? Hmmmm... Those gig probes are pretty costly but are lots of fun! Don't scare the folks with the purse strings away.
A probe might give you what you desire. If you use a probe the most common way, which is by SPANing a port vice using the in-line tap, the only limitations are the capabilities of the port. I.e.- A gig port can handle a gig worth of traffic. I don't know if you are familiar with CiscoWorks Windows or Ipswitch Sotware's "What's Up Gold" product, but I believe you can get a free 30-day trial download either from Cisco or ZDNET. CiscoWorks Windows has What's Up Gold included in the suite. What's Up Gold has a MIB tool that will graph the returned MIB values and also store those values in a delimited text file. You can take that text file and import it into a spreadsheet or database application and perform magic with formulas to calculate port utilization. I mention this because, if you do a little research ahead of time on the port(s) you want to monitor, you can get an idea of the amount of traffic you'll be trying to capture. For example, let's say you have more than one gig link from the distribution layer to your one of your core switches. Will you need a gig probe connection for each, or can you get away with SPANing more than one port in a single SPAN session and stay within the destination port's bandwidth? Hmmmm... Those gig probes are pretty costly but are lots of fun! Don't scare the folks with the purse strings away.
Hello Martin,
Can you tell me more about Te-vista and your network. How are you using it? Is your network spread out (WAN)? Are you able to get manage your network and get the information, and troubleshoot your network? If you don't want to spread
the gosple on this form. Would you please email me at jjsniffit@yahoo.com? I sure would like that.
jjsniffit
JKEEPER
Can you tell me more about Te-vista and your network. How are you using it? Is your network spread out (WAN)? Are you able to get manage your network and get the information, and troubleshoot your network? If you don't want to spread
the gosple on this form. Would you please email me at jjsniffit@yahoo.com? I sure would like that.
jjsniffit
JKEEPER
- Thread starter
- #17
PAGEME1000
Technical User
Hi People....
Having now attempted to test the NAM card, nGenius RTM and also written a proposal for a large network. I can pass on a few comments....Not completely obvious but the RTM server is doing the data capture on specific types of data using RMON II, the other packages just use this data and display it in neat understandable tables. The server sets the profile onto the NAM card which then stores and returns the information during specific times.. O.k I understand you might think I'm a complete idiot...but I am looking to store vlan traffic information with the purpose of billing customers 4 network usuage...Further down the line I am going to use the traffic analysers for doing performance monitoring etc using the same information or by setting different templates...One has to be aware that the capabilites of the cisco processor can be severly degredated with large amounts of rmon traffic and number of queries it can handle....
As rightly pointed out, rspan could be used to monitor traffic on a different switch yes......but I am monitoring 60 -70 vlans for billing information. Although the vlans have low usage they are kept separate for security reasons...It then makes sense to have for NAMs trapping information separately without causing excess data flow between core switchs!
The question then is how big is the database gonna be on the Server....The RTM default is a 31 day turnaround.... this is fine for day to day monitoring but for billing information the requirement might be up to 1 year....(hard disk sales ching ching)....
So what do you reckon?
Page....
"I love it when a plan comes together"
Having now attempted to test the NAM card, nGenius RTM and also written a proposal for a large network. I can pass on a few comments....Not completely obvious but the RTM server is doing the data capture on specific types of data using RMON II, the other packages just use this data and display it in neat understandable tables. The server sets the profile onto the NAM card which then stores and returns the information during specific times.. O.k I understand you might think I'm a complete idiot...but I am looking to store vlan traffic information with the purpose of billing customers 4 network usuage...Further down the line I am going to use the traffic analysers for doing performance monitoring etc using the same information or by setting different templates...One has to be aware that the capabilites of the cisco processor can be severly degredated with large amounts of rmon traffic and number of queries it can handle....
As rightly pointed out, rspan could be used to monitor traffic on a different switch yes......but I am monitoring 60 -70 vlans for billing information. Although the vlans have low usage they are kept separate for security reasons...It then makes sense to have for NAMs trapping information separately without causing excess data flow between core switchs!
The question then is how big is the database gonna be on the Server....The RTM default is a 31 day turnaround.... this is fine for day to day monitoring but for billing information the requirement might be up to 1 year....(hard disk sales ching ching)....
So what do you reckon?
Page....
"I love it when a plan comes together"
I have installed CW2000 and am now about to install the last module RTM. I am a little confused and was hoping one of you could answer a question for me. Do I need to purchase probes\NAM to collect traffic or could I use an existing switch.
Help!!!
The Jester
Help!!!
The Jester
- Thread starter
- #19
PAGEME1000
Technical User
Hello Mate...
It should be possible to do this...although I never managed it myself..(too busy writing technical specs).
Enable RMON2 on the switch/router
Set the community strings to be the same on the switch/router as the cw2000 machine...
Then in the RTM server gui instead of using the probe tab use the switch tab and enter the details here...The nGenius software will then discover the switch....You will probably have limited functionality since you do not have a probe....hope this helps...
Page
It should be possible to do this...although I never managed it myself..(too busy writing technical specs).
Enable RMON2 on the switch/router
Set the community strings to be the same on the switch/router as the cw2000 machine...
Then in the RTM server gui instead of using the probe tab use the switch tab and enter the details here...The nGenius software will then discover the switch....You will probably have limited functionality since you do not have a probe....hope this helps...
Page
- Thread starter
- #20
PAGEME1000
Technical User
Hi All Me Again....
FYI
As mentioned before the Real Time Monitor stores the data up to 31 days, if you need more a longer period you need
to use the Capacity Planer for Probes our reporting-tool.
Just to give you an overview of the databasesize:
RTM one 100FD Eth interface with full monitoring for 30 days around 500 MBytes
CP4P one 100FD Eth interface with full monitoring for 90 days around 900 MBytes (db + reports)
"Page Off Buying Shares in Hard Drives...."
FYI
As mentioned before the Real Time Monitor stores the data up to 31 days, if you need more a longer period you need
to use the Capacity Planer for Probes our reporting-tool.
Just to give you an overview of the databasesize:
RTM one 100FD Eth interface with full monitoring for 30 days around 500 MBytes
CP4P one 100FD Eth interface with full monitoring for 90 days around 900 MBytes (db + reports)
"Page Off Buying Shares in Hard Drives...."
- Status
Similar threads
- Locked
- Question
- Locked
- Question