Cisco’s Umbrella – Another Effective Layer of Security

umbUp and running for only 20 days, Cisco Umbrella has protected us from 358 potential security issues. Diving deeper into the actual events show that many of these events are potentially dangerous sites, but better safe than sorry.

The most compelling aspect of this product is that it works in the cloud, before the data even gets to you. Most Web Filtering security solutions work at the perimeter level, meaning the data gets to your firewall and then it is blocked. Umbrella, does this at the DNS layer in the cloud, ultimately cutting down on your own bandwidth usage and providing security. two birds with one stone.

While I wouldn’t suggest you go and throw out any of your other security solutions, Umbrella can be a great add on to your overall security strategy.

Feel free to contact me to discuss further.

Being All Things to All People

Having being in the Managed Services game for about 25 years, as you can imagine we have seen the industry change drastically. When End to end started 23 years ago there weren’t too many Managed Service Providers out there. Today everyone is doing it, but what I have noticed is that many are trying to be all things to all people. In our infancy as an organization we were very opportunistic and took any business that came our way. As we matured we have narrowed our focus so that we can be the best at what we do.

We are not a Server, Storage, Anti Virus, Windows or Print Managed Service provider. We are strictly a Voice, Data and Wireless Managed Service Provider. We focus on core infrastructure technologies and ensure our staff have the latest certifications to be the best in those areas.

End to End is a member of the Trust X Alliance, a group of trusted partners that have come together to deliver best in class solution for our customers. Each member has their area’s of expertise allowing each of the members to focus on what they do best.

When I look at an organizations web site and they claim to do everything from Web Development to Cabling, Security, Wireless, Data Centre, Cloud Services, Managed Services, Managed Security Services, Managed Print Service etc. it makes me wonder how good they are at each of these technologies. Even within the Data Centre, there are L2 and L3 Switching technologies, Hyper-V, VM Ware, Fibre Channel, Fibre Channel over Ethernet, Linux, Windows, Storage, Firewalls, Routing etc. after

And even within common technologies there are multiple vendors. Can you be a Firewall expert in Cisco, Juniper, Fortinet, Palo Alto, Checkpoint, Sonic Wall and Watchguard. I think not. You may be able to understand them all but you can only be an expert in two or three…

Now I know that there are large organizations out there that can and do deliver all of these services. But do they really act like one company. Does the Data Centre guy interface with the Firewall guy within that organization or are they in separate cities and have never met each other?

If you have a need for anything, you can call me up and if it is my core, I’d be happy to deliver it. If it is not, I’d be happy to give a referral to our of our Trust X Alliance partners, and if I can deliver some, but not all, I will be completely upfront that we would be bringing in a trusted partner to help deliver the services I can’t.

This allows End to End to deliver high quality Managed Services in Voice, Data and Wireless technologies, while leaving the other technologies to companies that focus on what they do best. We win, our partner wins and most importantly our customers win.

 

Command Line VS Graphical Interface

Early on in IT the only one way to manage a system, be it a MUX, Controller, Server or Modem was via the Command Line Interface (CLI). Windows and MAC’s were our first real introduction into GUI (Graphical User Interface) based management and for some tasks it was a lot easier to deal with. The younger generation has come to expect GUI systems and probably find CLI cumbersome and archaic, but the older generation, the generation that grew up with Unix, Cisco IOS and a number of other systems that don’t exist anymore, will probably tell you that CLI is the only way to go.

I sit somewhere in the middle. While I recognize the flexibility and speed that a CLI can give you, I sometimes yearn for the colours and charts that can make quick work of a task that requires a number of memorized commands with outputs that are sometimes hard to read. I have been configuring and Managing Cisco Routers and Switches for well over 15 years, so when it comes to Cisco IOS, Command Line is the obvious choice. It does require a fair amount of memory work but when you do it day in and day out it becomes second nature. Cisco attempted a few GUI systems for the old PIX and now ASA Firewalls, but I can tell you, as crazy as a complex Firewall configuration can get, the GUI system is that much more complex. A poorly written GUI can be even more confusing than CLI.

I recently worked with a customer that, for the most part, was not comfortable with CLI, and since we were looking at installing a number of Cisco switches in their network, I took the opportunity to give the customer a really quick Cisco CLI overview. As I said, Cisco CLI is second nature to me, but in listening to the reaction of the customer I realized how intuitive Cisco’s CLI really is.

Back before Juniper bought Netscreen, we were big fans of Netscreen’s ScreenOS. Not exactly like Cisco, but very intuitive. Juniper bought Netscreen and for a while it was status quo, but then Juniper decided to push the SRX series, based on the JunOS software. Now, I can use JunOS, but is it intuitive? Is it easy to use? NO and NO… I know there are a lot of JunOS fans out there and I am by no means knocking the product or its capabilities, just pointing out that in my opinion the interface for the CLI is not up to snuff.

The CLI is harder to learn, requires a certain amount of memorization and probably requires you to get a better understanding of the technology and what it is doing. Sometimes you can get something working via a GUI just be clicking around until it works. Certainly not recommended, but I’ve see it in action.  Whatever your preference, don’t ignore the CLI. In most cases what you do in the GUI gets translated into commands via CLI behind the scenes. If you are unclear how to use the CLI on any particular system, I recommend using the GUI to set it up, then going back to the CLI to see what those GUI clicks did to the configuration in the CLI.

The 3G/4G LTE Challenge for Network Professionals

This post is a long time coming, but I couldn’t keep it inside anymore. 3G and more recently 4G has taken off in a way that has changed the way we communicate. For Handhelds, Tablets and Laptops instant access to the Internet has never been easier. This is a good thing right? Yes, I do not argue that at all.

The challenge I am going to describe is the same challenge Network professionals have had with all new technologies.

Back in about 1995 we would use 56K Leased Lines to connect two offices together. We started to migrate to ISDN (http://en.wikipedia.org/wiki/Integrated_Services_Digital_Network) dial up. ISDN BRI offered two Channels each at 64K, giving the customer 128K of throughput. Laughable today, but at the time 128K was awesome.

First there was confusion around the Hardware required to terminate the ISDN. A Terminal Adapter (TA) was required, but there was also an NT1 device that was always required but sometimes built into the TA. Although at the time the information about ISDN and how it worked was not easily available (no Wikipedia back then), we were able to fumble out way through enough to figure out the Hardware part of it.

In the beginning we used a Motorola UTA220 and the configuration of this unit was done with a front panel  LCD display with three buttons – Yes, No and Home. There were many parameters that needed to be set up, some obvious others not so much. If you missed the menu item you were looking for you would have to go back and start over again. Doesn’t sound to bad…The critical parameters of ISDN were the SPID Numbers and the DN’s. Without these in the configuration the line would not come up.

Each carrier required different parameters in their SPID and DN’s. This is where the real confusion started. I am sure the engineer that set it up and designed the system for (in this case) Bell Canada, knew what was required to set it up, but we could not find anyone to help us. All of the documentation we read told us to use the B channel phone numbers for the SPID and DN’s, but we could not get it to work.

Eventually, somehow and I can’t remember how we figured out that Bell Canada required 00 at the end of the phone numbers for the SPID settings and the DN’s required the Area Code as well as the number. How many days went by before we got this info I have no idea……So we got the TA connected and the channels up… Lets make an ISDN call to another TA and create a line….. No such luck. Every time we tried we got a fast busy. Again, I cant tell you how much effort of days went by before someone (Not Bell Canada) decided to dial a 9 before the number and presto we were in business.

Here we are back in 2012 and we have customers and a lot of them wanting to use 3G/4G as a primary in locations were there are no other options and as a backup to their broadband connection. Rogers, Bell Telus, Shaw and I am sure every other Canadian and US carrier is offering 3G/4G, so they are certainly easy to order. But what are you getting?

From the Carrier side you may get any one of the following:

1. A  connection with a private IP address that gets NAT’d to the internet.

2. A connection with a public IP address that gets NAT’d to the internet

3. A connection with a private IP Address that uses a Proxy Server to get to the Internet

4. A connection with a public IP Address that uses a Proxy Server to get to the Internet

OR

A connection with an IP that may be public or may be private that may or may not get NAT’d and/or may or May not go thorugh a proxy server because none of their Engineers, Sales and Operations folks actually know how their 3G/4G network has been designed and deployed.

Then you have the SIM Card / Modem debacle. As you know the SIM card is required from the Carrier to access the Network. In most cases this SIM card gets installed in a 3G/4G modem in the form of a USB stick. Many of the WAN devices now come with a USB slot for just this purpose. Each Hardware Vendor then releases a list of supported USB or Express Card Modems supported. The issue is that these modems are getting changed all the time and the Vendors and Carriers do not seem to be in synch at all.

We have also noticed Regional differences… A card that worked in Ontario with Rogers would not work in Alberta and when we got one working it was Proxying in one place and NATing in the other. WHY? no one knows!

I think there are different sizes of SIM Cards now, which confuses the issue just that much more.

Here is an example of the ongoing confusion from just one Vendor:

Wireless technologies supported (performance and throughput) PCEX-3G-HSPA-G

• HSPA: 850, 900, 1900, and 2100 MHz (forward link up to 7.2 Mbps; reverse link up to 5.76 Mbps)

• Backward compatibility:

• HSDPA: 850, 900, 1900, and 2100 MHz (forward link up to 7.2 Mbps; reverse link up to 384 kbps)

• UMTS: 850, 900, 1900, and 2100 MHz (forward link up to 2.0 Mbps; reverse link up to 384 kbps)

• EDGE: 850, 900, 1800, and 1900 MHz (forward link up to 236 kbps; reverse link up to 124 kbps)

• GPRS: 850, 900, 1800, and 1900 MHz (forward link up to 80 kbps; reverse link up to 42 kbps)

(part number CISCO881G-G-K9 or CISCO881G-K9)

PCEX-3G-HSPA-US

• HSPA: 850, 900, 1900, and 2100 MHz (forward link up to 7.2 Mbps; reverse link up to 2.0 Mbps)

• Backward compatibility:

• HSDPA: 850, 900, 1900, and 2100 MHz (forward link up to 7.2 Mbps; reverse link up to 384 kbps)

• UMTS: 850, 900, 1900, and 2100 MHz (forward link up to 2.0 Mbps; reverse link up to 384 kbps)

• EDGE: 850, 900, 1800, and 1900 MHz (forward link up to 236 kbps; reverse link up to 124 kbps)

• GPRS: 850, 900, 1800, and 1900 MHz (forward link up to 80 kbps; reverse link up to 42 kbps)

• Set for North American bands above global bands

• 3G Firmware is PTCRB Certified and also for AT&T’s network

(part numbers CISCO881G-A-K9 with PCEX-3G-HSPA-US)

PCEX-3G-CDMA-x*

• CDMA 1xEV-DO Rev A (forward link up to 3.1 Mbps; reverse link up to 1.8 Mbps)

• Backward compatibility:

• CDMA 1xEV-DO Rev 0 (forward link up to 2.4 Mbps; reverse link up to 153.6 kbps)

• CDMA 1xRTT (forward link up to 153.6 kbps; reverse link up to 153.6 kbps)

(part numbers CISCO881G-S-K9, CISCO881G-V-K9 and CISCO881G-B-K9)

*S=For Sprint Networks; V=For Verizon Wireless Networks; B=For BSNL Networks

Frequency bands supported PCEX-3G-HSPA-G

• 850-, 900-, 1900-, and 2100-MHz WCDMA bands (HSUPA, HSDPA and UMTS)

• 850-, 900-, 1800-, 1900-MHz GSM bands (EDGE and GPRS)

PCEX-3G-HSPA-US

• 850-, 900-, 1900-, and 2100-MHz WCDMA bands (HSUPA, HSDPA and UMTS)

• 850-, 900-, 1800-, 1900-MHz GSM, bands (EDGE and GPRS)
PCEX-3G-CDMA-x*

• 800 MHz: North American cellular band

• 1900 MHz: North American PCS band
Subscriber Identity Module (SIM) card Universal Subscriber Identity Module (USIM) or Subscriber Identity Module (SIM) card slot on the PCI Express card (HSPA, UMTS, and GSM)
Antenna connector For Express Card external antenna connection:

• TS9 type connector requires for PCEX-3G-HSPA-G and PCEX-3G-HSPA-US

• SSMB plug-type connector requires for PCEX-3G-CDMA-x*

http://www.cisco.com/en/US/prod/collateral/routers/ps380/ps10082/data_sheet_c78_498096.html

Try and find any of this information on the Carriers web site… Non existent! Is it because they want you to lock into three years and use there modem? I don’t know.

Then there are the rates and policies and fine print. Some of the services will detect multiple devices and block access. Some carriers will block IPSec traffic. Some will not provide warnings once you have reached your usage and then charge you exorbitant rates for your overage.

I know that as this technology matures it will get clearer and clearer until eventually anyone can get it working, but as I said earlier until then, it is and will continue to be a challenge.

Cisco Cius

As many of you may already know Cisco stopped development of the Cisco Cius, a 7 inch business tablet that promised so much. I believe it under delivered primarily due to it running such an old version of Android  – 2.3. The Call Manager Features on it were great and the phone cradle that is sat in was not only cool but it is functional. I did a quick video review when I first got the unit the test if you want to check it out.

 

 

 

 

 

 

 

 

http://www.youtube.com/watch?v=rPUfOHz7boc&feature=g-upl

Too bad they couldn’t keep up with the speed of the market. It may be that they will focus on providing this type of functionality via software on products that are already established in this market – i.e. ASUS and Samsung, Apple etc.

I still like the size of this tablet and the call and video quality is awesome… In Canada they were asking over $1800 for the Cius – again I could have swallowed that if they were able to keep the OS up to date. Not sure what will come of mine. I may root it, but then would probably loose the call manager functionality.

 

Data Centre Switching

Our area of expertise in Network Management always has and always will have a role to play in the data centre. But the data centre has traditionally had two distinct networks running in it. The Data Network and the Storage Network. As Network Managers we have rarely been involved in the Storage Network side of Data Centre, but those days appear to be over as the Storage and Data Networks are on a collision course.

Many of you may think I am behind the times, and in some ways I am. To small and medium enterprises though, this is a whole new ball game. Just like the adoption of IP Telephony and VoIP technologies, it is not until the products become affordable that the masses start deploying.

The Data Center is or was  comprised of two distinct camps. The Server Guys and the Network Guys. They usually play well together and for the most part the camps were completely separate, less the Ethernet cable that went between the server and the switch. Those days appear to be gone as the Storage Network is starting to run over the Data Network. What I like about this is that it is not the other way around. If the Data Network had to run over the Storage Infrastructure we’d all be in trouble. At least this way us Data guys are still in control.

FCoE – Fibre Channel over Ethernet is the topic I am referring to. Traditionally Fibre Channel ran between Server and SAN and can run at 1, 2,4, 8 and now 16 Gbps. Much more than the traditional Data Network. But with the quick adoption of 10Gig Ethernet and 40/100 Gig on the way, there is no need to maintain two distinct networks in the data centre. BTW I did not spell Centre wrong, that is the way it is spelled in Canada.

So here we are again on a collision course with Data Centre managers. We already battled the tradition Telephony guys and I’m pretty sure the Networking groups won that battle… There were never enough standards in traditional Telephony. The Data Centre is a different beast though and will require both groups to work together to ensure success.

If FCoE takes off the way I believe it will we will once again be consolidating the data centre. This time instead of consolidating Servers we will be consolidating Data and SAN switching and collapsing everything down to one “Unified Network”.

VoIP – Trouble Shooting

Aside

Back in the day before the Real Time Requirements of Voice and Video all we needed to worry about was Bandwidth. If there was enough everything worked the way it should. If there wasn’t enough, you could deploy some technologies that may help prioritize data that would provide a group of users with a better user experience. And if that didn’t work you bought more bandwidth.

Enter the Unified Communications Era – Voice, Video, Data and who knows what they’ll think of next, all running over the same network.

Delay, Jitter, Packet Loss, Bandwidth and contention from other applications are all things one needs to consider when managing these new multi-service networks.

As Network Managers we have always been cognizant of the user experience. For applications like telnet the appearance that your characters were being echo’s back to you immediately was important, even if they weren’t it was the user experience that mattered.

The quality of a phone call though is something that can’t really be measured scientifically. We attempt to measure using MOS scores based on the Delay, Jitter and Packet loss, but these don’t actually measure the users experience. One person may say the call is good while another says not so good. That same person may be biased based on their mood.

Recently we have been trouble shooting a customer with Echo problems. The difficulty here is that we receive a report of an echo problem at a site with little to no information on the Called Party, Calling Party, who heard the echo, was the echo constant, was the echo loud, what type of delay in echo was experienced, was there a headset in use, was it a conference phone, speaker phone? This is not to blame anyone, as the user is not expected to know that these items are important.

I came across a really good article while searching on a solution for this issue, and while most of the information I already knew it really helped us solidify the source of the issue. I will also say that our team of technical staff did a great job in implementing echo cancellation technologies that has ultimately solved the problem – albeit by masking the echo. I’d like to share some of the highlights of this article.

Most Importantly:

Bits do not leak, so you can disqualify the digital segment of the system

As long as VoIP calls continue to be terminated in analog tails, echo will be a problem. One major obstacle to widespread VoIP implementation is that many tail circuits have preexisting delays that will become noticeable only when service providers introduce digital segments to the networks.

Because of the fundamental delays associated with VoIP technologies, existing echos will be more annoying than with TDM, and even the normal operation of an echo canceler will be more apparent. Customers of VoIP networks need to be educated to expect the standard echo canceler operation previously described so that they do not confuse these types of echos with abnormal echos. Abnormal echos persist throughout a call and do not fade.

These problems will gradually be solved as digital networks extend out toward homes and telephone endpoints. Until then, how much echo can be expected? One call in 50? 100? 1000? Even if customers are trained to complain only when an echo problem is persistent and repeatable, a service provider cannot hunt down and destroy every echo complaint. No one has sufficient resources to do this task, and hunting down an echo is a necessarily intrusive process.

The challenge is to determine when an echo complaint is both solvable and worth solving. You know that the echo source is in the destination tail circuit. For an echo problem to be solved, the tail circuit needs to be accessible.

Even after the deployment of Echo Cancellation, there is still a Echo when the call is first answered, as the Echo Cancellation Mechanism must get some real data before it is able to effectively stop the echo.

So in short the real answer is to use all digital circuits. Other echo issues are sometimes related to the phone set itself. Lower end phone sets tend to have cheaper components and are not as good at isolating the microphone from picking up sound that has leaked from the speaker.

Document Source: http://www.cisco.com/en/US/docs/ios/solutions_docs/voip_solutions/EA_ISD.html#wp1042222