The August 29th Telarus Tuesday call brought Telarus VP of Technology, Michael Brown to discuss Circuit Monitoring with Ticket Resolution. The entire recording can be found here.
Circuit Monitoring
If you sign someone up for circuit monitoring what happens today is that Telarus will monitor that circuit from an agent on the East Coast and the West Coast of the united states. We ping and traceroute test down to that circuit, and if we detect that circuit has gone down, we send an email alert to whoever you listed as the point of contact. This point of contact can be yourself, the end customer or a combination of those two. In addition to this, we provide a dashboard where we can go in and look at reporting. One of the questions that came up constantly was about what you should do if you receive an email alert letting you know that a circuit has gone down. This is what led to the latest iteration of the product set.
As we explained before circuits are tested from both coasts, and the system notifies our NOC of outages. Now in addition to whoever you’ve specified to receive those email messages we’re also going to open up a ticket within the NOC. After this happens, we will take the action of opening up a ticket with the carrier; this will potentially help us resolve the problem before your customer even knows what’s going on. Although we say simply sign up, we do require a little more information than what we’ve required in the past. The main thing we need is a letter of authorization with the carrier so we can open a ticket on your customer’s behalf. Telarus will also be requesting a credit card authorization form to simplify billing and automate the process. Another thing Telarus will ask for is the circuit information, to monitor it, we will need the IP address, supplier, circuit ID, and the contact information.
So what’s new? There is now a proactive ticket open with the carrier, for that ticketing solution, you will have a login to that ticketing system. This will make it possible for you to see all of the tickets that are open for your customers. We have anticipated that you’ll want to provide your end customer access to this. Once they log in, they can leave notes that they want to add to the ticket, as well as check real time status.
To get started, contact your support team; they’ll have all the forms that you will need. Once all the information is gathered, it can be submitted to circuithelp@telarus.com.Q&A
Q&A
Q: If someone has a circuit through a carrier and receives a notice of the down status but then a subsequent investigation shows that everything is okay, what can they do regarding the monitoring system to help interpret those results correctly and even change the way the monitoring is performed?
Michael: There’s a couple of things that we did so in the first iteration of the product we were just doing that ping and traceroute, and that up test from a single point on the internet. What we ran into because of the way that the internet routes, we could detect that a circuit is down when it’s just an issue with a peering point. So somewhere on that route between where we’re monitoring from to that circuit, there was an issue, but the customer circuit was up, one of the first improvement we made is to do that testing from multiple sites. Now we’re testing from the East Coast and West Coast; we don’t trigger an alarm unless both of those nodes detect that they’re unable to reach that circuit. Because they’re geographically dispersed, the chances are that they’re going gong to take a very different route when they’re trying to get down to the circuit. This went a long way as far as us not doing false alerts when the problem wasn’t with the circuit itself but instead was with a peering point. The next thing that we can do is when we configure a circuit to be monitored we use something called the template, and within that template, there are a couple of parameters that can be modified. One of those is how many tests in a row need to fail before I go down the path of sending out a notification, and so there are half a dozen selections that you can make when you’re choosing the template for that. One of those parameters in each of those templates is an X, so is it 2x, 15x? If you have a circuit where we’re checking that and it goes down but then comes right back what we can do is modify that template, we can then wait and maybe require that to fail five times in a row. What we are doing is we’re testing that internet connectivity, so if we’ve got two places on the internet that can’t get down to that circuit we see it as down. It’s feasible that if you contact the customer, they’re not going to notice because they’re not trying to get someplace that follows the same route on the internet. Those are the types of things we’ve tried to do to mitigate false alarms.
Q: Once we identify circuits that we’d like to have either monitored or to provide the trouble ticket resolution on, what’s the turnaround time for setting up those two pieces?
Michael: What we’ve always said is that once we receive the information, we’ll have the circuit monitoring turned up within three business days. I think that any of you that have participated in that have noticed that’s typically same business day if we’re receiving the information in the morning. If we’re just adding the additional pieces to it, I think once we have the information we need we can anticipate the same time frame of two to three business days.
Q: If a circuit is identified as being down, what happens after that? What is the process?
Michael: Once an alarm is generated with the existing or previously existing soft of monitoring solution we would send that email message to whoever you designate when within the signup form. When we get the ticket resolution, we’re going to ask for those same contacts, which again can be anyone you want. What we want to do is let you tell us who we should be communicating with. With the circuit monitoring once a ticket is open as that ticket is worked those updates are going to go out to those same contact people. You will have access to that ticketing solution; we will just follow what you tell us to do as far as who you want us to update and who you want to have access to the ticketing solution. We are very flexible with this so that whatever circumstance you may find yourself in we can accommodate.
Q: Does the monitoring take a look at any other circumstances besides a simple up-down situation? For example jitter or throughput?
Michael: We do look at a couple of other things. When we generate a ticket, we’re typically checking if someone’s not getting a response to ping. Within the circuit monitoring dashboard, you do have access to other metrics that we can collect like the ping and traceroute. One of those things would be delay. If a customer is reporting slow internet we can go back and see if historically there’s been a 30-millisecond delay, but now it’s suddenly up at 500, while the circuit is not down we can see that delay has increased. The other thing you can look at from a trace routing perspective within the circuit monitoring dashboard is the number of hops. If the number of hops is constantly changing what that typically is going to represent is a problem at a peering point, we have to reroute traffic a different way. We don’t do jitter based on ping. The throughput or bandwidth utilization we don’t do as part of the circuit monitoring product, but that is something available if we do full monitoring using the VX pulse solution. We do have some templates that will alarm on things like an increase in delay or a specific delay value. If you also want to monitor for an increase in latency we can do that; it would flow through the normal ticket process.
Q: Does anything change along the way if the client has a managed router from one of the carrier’s involved? If this is a hosted service, does it change the process at all?
Michael: I don’t think it will from our perspective, I think what we would be doing is just placing that phone call to the carrier rather than the end customer being in the position where they have to do that. With the circuit ID information, the carrier should recognize the service they have on that.
Q: Can you go over cost in more detail?
Michael: For free circuit monitoring there is obviously no charge, and to qualify for this that circuit has to have been sourced through Telarus. If you have a customer who wants the circuit monitoring, the dashboard and reporting functionality on a circuit which has not been sourced through Telarus the cost is $10 a month per circuit. If we want to do the monitoring plus ticket resolution, it’s $20 a month per circuit regardless of whether or not that circuit was sourced through Telarus. Now things can be more complex if you’re talking about something like MPLS circuits. In that case, those are typically not accessible via the internet, so in those situations, we can still do the monitoring for $20 per circuit or in an MPLS cloud it is per endpoint. This does require that we place a piece of technology on the customers MPLS network because we have to be able to collect that information, so this does have a very small price point on-time purchase.
Q: If partners wish to offer this to their clients and even discount the service there is a way to do that, correct?
Michael: Well the discount on the service in this particular case because we’ve got some substantial hard costs would have to be within their $5.
Q: Is this a month to month arrangement or is it a term agreement?
Michael: This is month-to-month, but we would obviously encourage you to go for a term agreement to protect your revenue stream as well.
Q: What about the ability to white label this service and resell it as a partner?
Michael: This will be a Telarus branded offering. We talked about it, but I think there are so many complexities with trying to white label this service that it will just be a Telarus branded services.
Q: What about circuits that for example come from a cable and have a dynamically assigned IP as opposed to a static IP address, if that IP address is changing can we still provide the monitoring?
Michael: We can’t. That is one of the requirements for the circuit monitoring baseline product which kind of feeds into this ticket resolution, we do require that static IP address for that to work. If that circuit is utilizing some form of dynamic DNS, then it could be done by name, but typically if someone is not requesting a static IP address, chances are that they don’t have the dynamic DNS services as part of that. If they do, then we can monitor by name as long as that dynamic DNS is available.
Q: If a customer is using SD-WAN will Telarus use the same static IP the SD-WAN provider is using or do we need a unique IP?
Michael: In SD-WAN you typically have multiple connections, what I would suggest is that we need to be monitoring the routers that are behind the SD-WAN solution so we can make sure both of those are up. If I’m in a situation where I’ve got a primary and a secondary circuit if I don’t know that my secondary has gone down I’m in for a big surprise when my primary does go down.
Q: If partners want to start looking over the LOA or the other required documentation, do we have that presently available?
Michael: They can contact their PSM who will have access to those forms. Also if you go to www.telarus.com/circuit-monitoring.php we have flyers with additional information.
Q: Why should partners go after this right away?
Michael: There are two reasons. First, this should be a differentiating conversation that you’re having with potential end customers. If we fall back to the free circuit monitoring if they purchase that through you, which means you are providing them a service at no cost. Secondarily, I believe that more and more businesses are almost completely dependent on internet connectivity. Not being able to monitor and know as soon as a circuit goes down does affect a company’s productivity.
