Sponsored Content
Special Forums UNIX and Linux Applications Virtualization and Cloud Computing Mini Review: SliceHost v. Linode Customer Service Post 302376153 by Neo on Monday 30th of November 2009 06:35:23 PM
Old 11-30-2009
Quote:
Originally Posted by PHLAK
On the note of SliceHost... I've had a single 512 Slice with them for several months now (6-8?), and love them. Everything you've stated I have also found to be true. Their service is great, customer service is helpful and they are extremely transparent about everything they do.
Frantkly , I do worry about the credibility of folks who only have one post in the forums and that post is a glowing review of a company.

On the other hand, my experience with the customer service at Slicehost has been so favorable, it is easy to see how others might post in reply to my mini-review.

A long time ago there was this debate between Cisco and Wellfleet (later acquired by Bay Networks, as I recall). Wellfleets routers featured a faster performing backplane but had to be rebooted to change the configuration. Cisco routers, on the other hand, was a bit slower on the backplane, but you could change the configuration without rebooting the machine.

At the time, I explained to a USAF General in charge of communications that during the heat of battle, you don't want to have to reboot your router to add a filtering rule or change some other configuration.

That was around 1994. The USAF followed my advice (which they paid good money for !) and dropped Wellfleet in favor of Cisco and the rest is history. Few people know that one of Cisco's biggest and most influential customers, the USAF, got their foot in the door based on my work building network control centers and getting rid of the Wellfleets in favor of Cisco.

The theme of my short walk back in time above is to point out that speed, backplane performance, etc. are all great; but they are not the most important features to consider in most circumstances. Customer service is also very important as well.

In the digital age, I expect my VPS to be provisioned within 30 minutes, even with a fraud flag based on a primitive rule and I expect emails to be answered within that same time frame as well. A company should have employees with email on the mobiles answering queries, chatting, and more.

Wire speed is not enough. Linode needs to learn this lesson, I think.

Customer service "speed" is more important than "wire speed" for more people.
 

3 More Discussions You Might Find Interesting

1. HP-UX

Customer support engineer

Hi All, I need the help to deploy or implement HP MC service guard 2 node cluster step by step procedure is any1 who can help me to send me the step by step procedure. Thanks and Regards Jahangir (12 Replies)
Discussion started by: Jahangir
12 Replies

2. Virtualization and Cloud Computing

Mini Review: SliceHost v. Linode Ubuntu 9.10 Setup

October 2010 Update: Linode Versus Slicehost – One Year Later A few days ago I posted Mini Review: SliceHost v. Linode Customer Service. At that time, I was going to cancel my account with Linode based on problems during the sign-up period. However, Linode asked me to give them another... (2 Replies)
Discussion started by: Neo
2 Replies

3. Android

Mini Review: Samsung Galaxy S (Android 2.1) v. Nokia E63

Well, I've had my new Galaxy S around one day now and I must say, I am not sure if I regret buying it or not. Before buying it, I read a lot of reviews about the Galaxy S (e.g. Samsung I9000 Galaxy S review: From outer space), including reviews of problems with the GPS and some intermittent WiFi... (6 Replies)
Discussion started by: Neo
6 Replies
GRE(4)							   BSD Kernel Interfaces Manual 						    GRE(4)

NAME
gre -- encapsulating network device SYNOPSIS
To compile the driver into the kernel, place the following line in the kernel configuration file: device gre Alternatively, to load the driver as a module at boot time, place the following line in loader.conf(5): if_gre_load="YES" DESCRIPTION
The gre network interface pseudo device encapsulates datagrams into IP. These encapsulated datagrams are routed to a destination host, where they are decapsulated and further routed to their final destination. The ``tunnel'' appears to the inner datagrams as one hop. gre interfaces are dynamically created and destroyed with the ifconfig(8) create and destroy subcommands. This driver corresponds to RFC 2784. Encapsulated datagrams are prepended an outer datagram and a GRE header. The GRE header specifies the type of the encapsulated datagram and thus allows for tunneling other protocols than IP. GRE mode is also the default tunnel mode on Cisco routers. gre also supports Cisco WCCP protocol, both version 1 and version 2. The gre interfaces support a number of additional parameters to the ifconfig(8): grekey Set the GRE key used for outgoing packets. A value of 0 disables the key option. enable_csum Enables checksum calculation for outgoing packets. enable_seq Enables use of sequence number field in the GRE header for outgoing packets. EXAMPLES
192.168.1.* --- Router A -------tunnel-------- Router B --- 192.168.2.* / / +------ the Internet ------+ Assuming router A has the (external) IP address A and the internal address 192.168.1.1, while router B has external address B and internal address 192.168.2.1, the following commands will configure the tunnel: On router A: ifconfig greN create ifconfig greN inet 192.168.1.1 192.168.2.1 ifconfig greN inet tunnel A B route add -net 192.168.2 -netmask 255.255.255.0 192.168.2.1 On router B: ifconfig greN create ifconfig greN inet 192.168.2.1 192.168.1.1 ifconfig greN inet tunnel B A route add -net 192.168.1 -netmask 255.255.255.0 192.168.1.1 NOTES
The MTU of gre interfaces is set to 1476 by default, to match the value used by Cisco routers. This may not be an optimal value, depending on the link between the two tunnel endpoints. It can be adjusted via ifconfig(8). For correct operation, the gre device needs a route to the decapsulating host that does not run over the tunnel, as this would be a loop. The kernel must be set to forward datagrams by setting the net.inet.ip.forwarding sysctl(8) variable to non-zero. SEE ALSO
gif(4), inet(4), ip(4), me(4), netintro(4), protocols(5), ifconfig(8), sysctl(8) A description of GRE encapsulation can be found in RFC 2784 and RFC 2890. AUTHORS
Andrey V. Elsukov <ae@FreeBSD.org> Heiko W.Rupp <hwr@pilhuhn.de> BUGS
The current implementation uses the key only for outgoing packets. Incoming packets with a different key or without a key will be treated as if they would belong to this interface. The sequence number field also used only for outgoing packets. BSD
November 7, 2014 BSD
All times are GMT -4. The time now is 01:03 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy