Tech Tips: March 2018

Tuesday, March 13, 2018

InContact Chat

Summary

I'll be discussing the basics of getting a chat implementation built on InContact. InContact is cloud contact center provider. All contact center functionality is provisioned and operates from their cloud platform.

Chat Model

Below is a diagram of how the various InContact chat configuration objects relate to each other. The primary object is the Point of Contact (POC). That object builds a relation between the chat routing scripts and a GUID that is used in the URL to initiate a chat session with an InContact Agent.

Chat Configuration

Below are screen shots of some very basic configuration of the objects mentioned above.

Below a screen shot of the basic InContact chat routing script I used for this example. The functionality is fairly straightforward with the annotations I included.

Chat Flow

Below is a diagram of the interaction flow using the out-of-box chat web client that InContact provides. The option also exists to write your own web client with InContact's REST API's.

Code

Below is a very crude web client implementation. It simply provides a button that will instantiate the InContact client in a separate window. As mentioned previously, the GUID assigned to your POC relates the web endpoint to your script.

<!DOCTYPE html>
<html>
 <head>
     <title>Chat</title>
  <script type = "text/javascript" >
   function popupChat() {
    url = "https://home-c7.incontact.com/inContact/ChatClient/ChatClient.aspx?poc=yourGUID&bu=yourBUID
&P1=FirstName&P2=LastName&P3=first.last@company.com&P4=555-555-5555";
    window.open(url,"ChatWin","location=no,height=630,menubar=no,status=no,width=410", true);
   }
  </script> 
 </head>
 <body>
  <h1>InContact Chat Demo</h1>
   <input id="StartChat" type="button" value="Start Chat" onclick="popupChat()">
 </body>
</html>

Execution

Screen-shots of the resulting web client and Agent Desktop in a live chat session.

Monday, March 5, 2018

Dual ISP - Bandwidth Reporting

Summary

This post is a continuation of the last on router configuration of two ISP's. In this one, I'll show how to configure a bandwidth reporting with a 3rd party package - MRTG. MRTG is a really nice open-source, graphical reporting package that can interrogate router statistics via SNMP.

Configuration

MRTG set up is fairly simple. It runs under a HTTP server (Apache) and has a single config file - mrtg.cfg. Configuration consists of setting a few options for each of the interfaces that you want monitored over SNMP.

HtmlDir: /var/www/mrtg
ImageDir: /var/www/mrtg
LogDir: /var/www/mrtg
ThreshDir: /var/lib/mrtg
Target[wisp]: \GigabitEthernet0/1:public@<yourRouterIp>
MaxBytes[wisp]: 12500000
Title[wisp]: Traffic Analysis
PageTop[wisp]: <H1>WISP Bandwidth Usage</H1>
Options[wisp]: bits

Target[dsl]: \Dialer1:public@<yourRouterIp>
MaxBytes[dsl]: 12500000
Title[dsl]: Traffic Analysis
PageTop[dsl]: <H1>DSL Bandwidth Usage</H1>
Options[dsl]: bits

Results

MRTG will provide daily, weekly, monthly and yearly statistics in a nice graphical format. Below are the screenshots of the graphs for the two interface configured above.

Another open-source reporting package called MRTG Traffic Utilization provides a easy-to-read aggregation of the bandwidth stats via the MRTG logs. Below is a screenshot of mrtgtu

Sunday, March 4, 2018

Cisco Performance Routing - Dual ISP's, Single Router

Summary

In this post I'll discuss how to set up dual ISP links in a sample scenario using a single Cisco router with Performance Routing (PfR). Traditionally, dual links could be set up with Policy-Based Routing (PBR) and IP-SLA. An example of that here. The combination of those two would yield fail-over functionality upon loss of one of the two links. It would not provide load-balancing of those links though. PfR provides both.

Scenario

Below is a diagram of the example dual ISP scenario. One connection is to a DSL provider; the other to a wireless ISP (WISP). Available bandwidth on the links is grossly imbalanced, by a factor of 8. A dialer interface (PPOE) to an ATM interface connects the DSL ISP. There is a Gig Ethernet connection to the WISP. Behind the router/firewall are clients on private-range IP addresses. Two internet-facing web servers are segregated into a DMZ.

Interface Configurations

ISP Link 1 - DSL ISP - Dialer

The PfR-important items are highlighted below. You need to set an accurate figure for the expected bandwidth on the link and set load statistics interval to the lowest setting (30 sec). Also note that both interfaces are designated as 'outside' for NAT.

 interface Dialer1
 bandwidth 8000
 ip address negotiated
 ip access-group fwacl in
 ip mtu 1492
 ip nat outside
 ip inspect outside_outCBAC out
 ip virtual-reassembly in
 encapsulation ppp
 ip tcp adjust-mss 1452
 load-interval 30
 dialer pool 1
 dialer-group 1
 ppp authentication pap callin
 ppp chap refuse
 ppp pap sent-username yourUsername password yourPwd
 no cdp enable

ISP Link 2 - Wireless ISP - GigE

interface GigabitEthernet0/1
 bandwidth 64000
 ip address 2.2.2.2 255.255.255.0
 ip access-group fwacl in
 ip nat outside
 ip inspect outside_outCBAC out
 ip virtual-reassembly in
 load-interval 30
 duplex auto
 speed auto
 no cdp enable

Internal Link - GigE

The link to the LAN is configured as NAT inside.

interface GigabitEthernet1/0
 ip address 10.10.10.10 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 load-interval 30

Routing Configuration

Routing for this scenario is very simple. Just 2 static default routes to the next hop on the respective ISP's.

ip route 0.0.0.0 0.0.0.0 1.1.1.1
ip route 0.0.0.0 0.0.0.0 2.2.2.1

NAT Configuration

The item of interest is the 'oer' command on the NAT inside commands. This alleviates a potential issue with unicast reverse-path forwarding. It's discussed in detail here.

route-map wispnat_routemap permit 1
 match ip address nat_acl
 match interface GigabitEthernet0/1
 
route-map dslnat_routemap permit 2
 match ip address nat_acl
 match interface Dialer1
 
ip nat inside source route-map dslnat_routemap interface Dialer1 overload oer
ip nat inside source route-map wispnat_routemap interface GigabitEthernet0/1 overload oer
 
ip nat inside source static tcp 192.168.40.60 80 interface Dialer1 80
ip nat inside source static tcp 192.168.40.60 443 interface Dialer1 443
ip nat inside source static tcp 192.168.40.61 80 interface GigabitEthernet0/1 80
ip nat inside source static tcp 192.168.40.61 443 interface GigabitEthernet0/1 443

PfR Configuration

Loopback Interface + Key Chain

These are used for communication between the Master and Border elements of PfR.

interface Loopback0
 ip address 192.168.200.1 255.255.255.0
 
key chain pfr
 key 0
  key-string 7 071F275E450C00

PfR Border Router Config

Really simple config for the border component.

pfr border
 logging
 local Loopback0
 master 192.168.200.1 key-chain pfr

PfR Master Router Config

Configuring the Master is easy as well. In fact, just defining the key-chain and the internal+external interfaces is enough to enable basic load-balancing + fail-over. PfR will aggregrate routes on IP address prefixes and balance across those routes across the 2 ISP links. The extra commands below specify to keep the utilization of the two links within 10 percent of each other, use delay as route learning parameter, evaluate policies every 3 minutes, and make delay the top priority for policy.

pfr master
 max-range-utilization percent 10
 logging
 !
 border 192.168.200.1 key-chain pfr
  interface GigabitEthernet1/0 internal
  interface Dialer1 external
  interface GigabitEthernet0/1 external
 !
 learn
  delay
 periodic 180
 resolve delay priority 1 variance 10