Why is it that I need to enable the Calltracker in my Cisco?
Why is it that Big Bro uses a TELNET session instead of the more classy SNMP?
Can someone having a GW_Monitor jeopardize my traffic in any way?
Can someone using the GW_Monitor can change jeopardize my monitoring?
I already have a billing system, can I integrate the Big Bro CDR's to it?
Cisco gateways provide an already overwhelming amount of information about the call without the need of any Calltracker, what could possibly be missing? The answer is that it doesn't say something so basic as to which DS1 and DS0 (span and channel) all that information refers to. Why isn't that information provided? We wonder the same ourselves.
The Calltracker, makes reference to the DS1/DSO. By its own, the calltracker provides little information about the call, fortunately, it does provide you with the called and calling numbers and it clearly says if it is Answering or Originating. Big Bro manages to link both pieces of information (through the called and calling numbers) to the standard call info mentioned above.
It has been reported though, that an overuse of the call tracker, in some IOS versions, interfere with other processes in the gateway. Cisco IOS versions beyond 12.2(13)T, support the command "show voice call status". Big Bro also supports it and this command can replace the function of the calltracker. For older versions, if the calltracker is not enabled, you may still see the channel activity, but no call info will be available for monitoring or for the CDR's.
SNMP stands for Simple Network Management Protocol, it is not going to be the first time it is said that "Simple" here is an euphemism, there's nothing simple about SNMP. Using this approach would make Big Bro's code more involved and its installation more complex, since it would involve CISCOS MIB's , for a discussion of such difficulties you may read this from the Cisco website. In a nutshell, Big Bro would we wearing a more expensive price tag.
But let's go further, what goodies would SNMP be buying for you? Basically, the advantage of interrupt against polling or in other words, SNMP traps can notify you when a status change happens, with TELNET, you must be constantly asking (polling) about the status. At first sight the interrupt approach seems totally superior, but is not quite so. When status changes are fewer than the poll frequency, then SNMP is absolutely superior, in principle, it should use less bandwidth and CPU time from both the gateway and the relay host, but under heavy traffic there's not much of a difference. Since at low traffic no one really cares about CPU or bandwidth usage, the advantage of SNMP does not compensate for its inconveniences.
Let discuss the underlined comment in above paragraph "in principle". Problem being, that SNMP is a network standard with a big scope and so, it has a lot of overhead and does a lot of housekeeping even al low traffic. Below we reproduce a discussion from a F.A.Q in the Cisco website.
Quote:
However, under heavy use, such as when a network management application is retrieving large tables (such as autodiscovery retrieving the ipRouteTable and ipNetToMediaTable), the CPU usage can approach 100% and starve low priority processes.
Under certain circumstances, the IP-SNMP process can consume almost all of the CPU resources, starving other processes and causing erratic behavior in the device. The most obvious symptom is the loss of Transmission Control Protocol (TCP) connections to the device. The most likely cause of the problem is a flurry of SNMP requests being sent to the device in a short period of time, retrieving large amounts of data. This behavior is usually associated with network auto discovery mechanisms that retrieve the device's entire Address Resolution Protocol (ARP) cache and IP routing table on a periodic basis.
The problem is exacerbated by some network management applications, by default, performing auto discovery as often as every five minutes.
A partial workaround is to identify those devices that are performing auto discovery, and modify their default behavior.
Another workaround is to force the router to prematurely end the queries for the IP route table and ARP cache from the network management system server. Configure the router to respond with a complete message as soon as it receives the start of a request for the IP route table or ARP cache. An example of how to do this on a Cisco router is explained here.
Now let's see how the "uncool" and "unclassy" TELNET approach behaves.
Under no traffic:
CPU utilization for five seconds: 10%/2%; one minute: 14%; five minutes: 20%
PID
Runtime(ms) Invoked uSecs
5Sec 1Min 5Min TTY Process
3 557304
12063935 46 6.22% 6.85%
6.52% 2 Virtual Exec
Under 4 T1's 90% full traffic
CPU utilization for five seconds: 35%/24%; one minute: 45%; five minutes: 46%
PID Runtime(ms) Invoked
uSecs 5Sec 1Min 5Min TTY Process
3 181256
3367251 53 5.70% 4.89%
4.86% 2 Virtual Exec
CPU usage will always be below 12%, this won't interfere at all with even the lowest priority processes. You may notice that the actual CPU usage of the Big Bro's TELNET session decreased with traffic, which is consistent with the fact that Virtual Exec processes are medium priority ones. We reproduce below a statement from Cisco:
Quote
The Exec process in Cisco IOSŪ software is responsible for communication on the tty lines (console, auxiliary, asynchronous) of the router. The Virtual Exec process is responsible for the vty lines (telnet sessions).
The Exec and Virtual Exec processes are Medium-priority processes, so if there are other processes that have a higher priority (High or Critical), the higher priority processes get the CPU resources.
Unquote
Now a a frequently asked question from the #include staff to the reader...Did we make our point? If still you think we didn't, please contact us.
No, if the person watching doesn't have the enable password, what she or he can do is just that...watch.
Yes, if you grant administrative privileges to her or his connection, the GW_Relay can be restarted, this is not a big deal if it is running within a recursive batch file, but some cumulative variables will be reset affecting somewhat (not much) the averages for that half hour in the 24 hour summary.
By introducing an access list in the GW_Relay.ini file, you may specify which computers may connect to the relay. But it gets better, you may allow a connection but only permit that connection to see some specified DS0 group and/or IP addresses by adding "SelectID" numbers and related lists. To learn how, check the security features for GW_Relay.
Yes you can. All billing systems work with a database in some SQL server from Oracle, Microsoft, etc. Almost every SQL in the market supports Windows ODBC. GW_Relay connects to databases through ODBC. A CDR, is stored by calling a Stores procedure named "proc_GW_CDR" with all CDR information as parameters (for more info regarding CDR and databases go here). This procedure can be custom written to transform the BigBro CDR data structure into the one your Billing System uses.
If your billing system is not local to the GW_Relay, then an ODBC connection could be unreliable and/or inefficient, Big Bro has a solution to this too, check #include's Direct Replication Scheme.
In case your billing system is not accessible by ODBC in any way, you may still import the Big Bro CDR's data from text files..
#include staff can help with any customization you might need. Do you? then, Contact Us!