Keeno's questions

We have a client who is having difficulty viewing our content over their VPN. If they browse to the content it appears with all crazy characters. I think I have worked out its somthing to do with GZIP, possibly the header is being stripped out?

Example of what it looks like: http://temp.a2om.com.s3-website-eu-west-1.amazonaws.com/help.html Note: i manually removed the header on that so you can see what it looks like for the client, and to help me diagnose the problem

However, the real files DO have the real headers, for example: http://temp.a2om.com.s3-website-eu-west-1.amazonaws.com/works.html This comes back with the headers Accept-Encoding:gzip, deflate, sdch

Any ideas why this would do this over a VPN, is there anything we can do (apart from uploading uncompressed)

Headers from mine(bottom) client(top)

Many thanks

Background: We need to deliver a video heavy e-learning course to a classroom of ~15 users. This video will be MP4 delivered via HTML5 video so progressive download. As from what I can gather you can't stream to HTML5 Video.

These 15 users will be in the same room, sharing an internet connection.

The video will be lots and lots of short (30 sec) clips, about 9 MB each. These files will be delivered from Amazon Cloudfront (CDN)

With progressive downloads, does each "client" download as fast as it can?

Is this theory correct or way off?

• user A is the first to download a clip, and starts downloading at near-full speed
• user B and C then get to the same stage, so they start downloading but there isn't much bandwidth so they download REALLY SLOWLY
• users D-P are screwed!

How can I advise my client what internet connection he will need to guarantee smooth playback?

Any thoughts/advice?

I am having some trouble with what should be a very simple task.

I have set up IIS 8 on server 2012

If I log in using a domain admin account, or the first admin account that was created when the machine was setup, I can connect to IIS Manager no problem

If I try and connect using a user that I have since created locally on the machine, and added to the local admins group. I can not connect.

Now, here is the extra wierd bit: If I remote in using the new admin account, and try and connect to IIS using the domain or other admin accounts that previously worked (if I remote in using those) i get the same error and I cant connect!

Steps I am using:

1. Remote in using the NEW admin account
2. Launch IIS (IIS doesnt show local server)
3. Connect to server (localhost)
4. Type in credentials (ANY account)

the error is: "Could not connect to the specified computer" "Details: Unable to connect to the remote server"

HELP! & Thanks

I am having some real issues setting up a VPN between out office and AWS VPC. The "tunnels" appear to be up, however I don't know if they are configured correctly.

The device I am using is a Netgear VPN Firewall - FVS336GV2

If you see in the attached config downloaded from VPC (#3 Tunnel Interface Configuration), it gives me some "inside" addresses for the tunnel. When setting up the IPsec tunnels do I use the inside tunnel IP's (e.g. 169.254.254.2/30) or do I use my internal network subnet (10.1.1.0/24)

I have tried both, when I tried the local network (10.1.1.x) the tracert stops at the router. When I tried with the "inside" ips, the tracert to the amazon VPC (10.0.0.x) goes out over the internet.

this all leads me to the next question, for this router, how do I set up stage #4, the static next hop?

What are these seemingly random "inside" addresses and where did amazon generate them from? 169.254.254.x seems odd?

With a device like this, is the VPN behind the firewall?

I have tweaked any IP addresses below so that they are not "real". I am fully aware, this is probably badly worded. Please if there is any further info/screenshots that will help, let me know.

 Amazon Web Services
Virtual Private Cloud

IPSec Tunnel #1
================================================================================
#1: Internet Key Exchange Configuration

Configure the IKE SA as follows
  - Authentication Method    : Pre-Shared Key 
  - Pre-Shared Key           : ---
  - Authentication Algorithm : sha1
  - Encryption Algorithm     : aes-128-cbc
  - Lifetime                 : 28800 seconds
  - Phase 1 Negotiation Mode : main
  - Perfect Forward Secrecy  : Diffie-Hellman Group 2

#2: IPSec Configuration

Configure the IPSec SA as follows:
  - Protocol                 : esp
  - Authentication Algorithm : hmac-sha1-96
  - Encryption Algorithm     : aes-128-cbc
  - Lifetime                 : 3600 seconds
  - Mode                     : tunnel
  - Perfect Forward Secrecy  : Diffie-Hellman Group 2

IPSec Dead Peer Detection (DPD) will be enabled on the AWS Endpoint. We
recommend configuring DPD on your endpoint as follows:
  - DPD Interval             : 10
  - DPD Retries              : 3

IPSec ESP (Encapsulating Security Payload) inserts additional
headers to transmit packets. These headers require additional space, 
which reduces the amount of space available to transmit application data.
To limit the impact of this behavior, we recommend the following 
configuration on your Customer Gateway:
  - TCP MSS Adjustment       : 1387 bytes
  - Clear Don't Fragment Bit : enabled
  - Fragmentation            : Before encryption

#3: Tunnel Interface Configuration

Your Customer Gateway must be configured with a tunnel interface that is
associated with the IPSec tunnel. All traffic transmitted to the tunnel
interface is encrypted and transmitted to the Virtual Private Gateway.

The Customer Gateway and Virtual Private Gateway each have two addresses that relate
to this IPSec tunnel. Each contains an outside address, upon which encrypted
traffic is exchanged. Each also contain an inside address associated with
the tunnel interface.

The Customer Gateway outside IP address was provided when the Customer Gateway
was created. Changing the IP address requires the creation of a new
Customer Gateway.

The Customer Gateway inside IP address should be configured on your tunnel
interface. 

Outside IP Addresses:
  - Customer Gateway                : 217.33.22.33 
  - Virtual Private Gateway         : 87.222.33.42

Inside IP Addresses
  - Customer Gateway                : 169.254.254.2/30
  - Virtual Private Gateway             : 169.254.254.1/30

Configure your tunnel to fragment at the optimal size:
  - Tunnel interface MTU     : 1436 bytes


#4: Static Routing Configuration:

To route traffic between your internal network and your VPC, 
you will need a static route added to your router.

Static Route Configuration Options:

  - Next hop       : 169.254.254.1

You should add static routes towards your internal network on the VGW.
The VGW will then send traffic towards your internal network over 
the tunnels.        

IPSec Tunnel #2
================================================================================
#1: Internet Key Exchange Configuration

Configure the IKE SA as follows
  - Authentication Method    : Pre-Shared Key 
  - Pre-Shared Key           : ---
  - Authentication Algorithm : sha1
  - Encryption Algorithm     : aes-128-cbc
  - Lifetime                 : 28800 seconds
  - Phase 1 Negotiation Mode : main
  - Perfect Forward Secrecy  : Diffie-Hellman Group 2

#2: IPSec Configuration

Configure the IPSec SA as follows:
  - Protocol                 : esp
  - Authentication Algorithm : hmac-sha1-96
  - Encryption Algorithm     : aes-128-cbc
  - Lifetime                 : 3600 seconds
  - Mode                     : tunnel
  - Perfect Forward Secrecy  : Diffie-Hellman Group 2

IPSec Dead Peer Detection (DPD) will be enabled on the AWS Endpoint. We
recommend configuring DPD on your endpoint as follows:
  - DPD Interval             : 10
  - DPD Retries              : 3

IPSec ESP (Encapsulating Security Payload) inserts additional
headers to transmit packets. These headers require additional space, 
which reduces the amount of space available to transmit application data.
To limit the impact of this behavior, we recommend the following 
configuration on your Customer Gateway:
  - TCP MSS Adjustment       : 1387 bytes
  - Clear Don't Fragment Bit : enabled
  - Fragmentation            : Before encryption

#3: Tunnel Interface Configuration

Outside IP Addresses:
  - Customer Gateway                : 217.33.22.33 
  - Virtual Private Gateway         : 87.222.33.46

Inside IP Addresses
  - Customer Gateway                : 169.254.254.6/30
  - Virtual Private Gateway             : 169.254.254.5/30

Configure your tunnel to fragment at the optimal size:
  - Tunnel interface MTU     : 1436 bytes


#4: Static Routing Configuration:

Static Route Configuration Options:

  - Next hop       : 169.254.254.5

You should add static routes towards your internal network on the VGW.
The VGW will then send traffic towards your internal network over 
the tunnels.  

EDIT #1

After writing this post, I continued to fiddle and something started to work, just not very reliably. The local IPs to use when setting up the tunnels where indeed my network subnets. Which further confuses me over what these "inside" IP addresses are for.

The problem is, results are not consistent what so ever. I can "sometimes" ping, I can "sometimes" RDP using the VPN. Sometimes, Tunnel 1 or Tunnel 2 can be up or down.

When I came back into work today, Tunnel 1 was down, so I deleted it and re-created it from scratch. Now I cant ping anything, but Amazon AND the router are telling me tunnel 1/2 are fine.

I guess the router/vpn hardware I have just isnt up to the job.....

EDIT #2

Now Tunnel 1 is up, Tunnel 2 is down (I didn't change any settings) and I can ping/rdp again.

EDIT #3

Screenshot of route table that the router has built up. Current state (tunnel 1 still up and going string, 2 is still down and wont re-connect)

First off, I am not a network engineer so apologies if I get terminology messed up, i realize accuracy is important here.

Currently, we have a small(ish) network with around 40 devices and 20 IP phones all connected over the same LAN. For some reason the call quality on the VoIP system has tanked and we are getting a ton of "Jitter" and very occasionally a dropped call. That's the problem in essence, so after some research I have discovered.

1. Ideally, the VoIP system should be on its own VLAN - to minimise broadcast traffic
2. Some QoS should be setup on the switches

I have checked my switch (Netgear GS724T) and it supports VLAN. I am pretty sure I could get this working if I plug the VoIP server into the VoIP VLAN but I don't see how this is achievable while also keeping it on the default VLAN so it can talk to the Domain controller.

Whats the best setup for this, remembering the overall goal that is removing the jitter and improving call quality

Should the VOIP server be off the domain and on the VLAN with the phones and just totally segregate it that way? Then, would they be better of on their own IP subnet also?

Whats more likely to be the issue, the fact that they share the LAN, or the lack of QoS. Should I do both? I have no idea in my switch how to prioritize VoIP traffic. Do the "interfaces/ports" get prioritized? Do I need to care about QoS if the VoIP system eventually gets its own private network.

Are there any other options I can look into to help reduce the jitter?

Phew, thanks for any advice, I didn't set this network up, I have inherited so I realise there are probably other glaring issues here also....

ADDITIONAL INFORMATION:

I should note that currently the VOIP server is virtualised, so, do I have to move it to a physical box to plug it into the VoIP VLAN?

I am having troubles with SQL server (or IIS, but I am pretty sure its SQL)

I have posted before with a more vague question, however its still happening and I have some more detailed information.

Previous Post

The problem: SQL Server 2008r2 to Website (iis 7) appears to be limiting data transfer speed when the IIS website tries to access it. The speed appears to get limited to 1Mb per second.

This fixes itself if I restart the database service, or take the DB offline, but I would rather not have to do this every week.

Some trouble shooting:

• File transfers from the same machines are fine, so I don't think its the network.
• I can connect from my local SQL Management studio, and query the SAME database fine
• Other websites on the same IIS server to the SQL server do not suffer talking to other DBs
• Pointing our dev server to the live troublesome database has the same issues
• Taking a copy of the database and putting that on another SQL doesn't have the issue

So, I think I have whittled it down to one Database within SQL seems to be having intermittent troubles transferring data to IIS.

• Any ideas what would be causing this?
• Why would it happen after a few days of working normally?
• Where can I start trouble shooting?

EDIT 1: NEW INFO I have done some more tests, it seems that it is one specific Stored Procedure that, only sometimes, is only using 10% of the network speed.

When I was fiddling around with the SP, doing nothing other than "tweaking it" seemed to break the bottleneck and thus it started working normally again.

Help, this is driving me mad!

Thank you

I am really new to RAIDs and all that goes along with them.

I simply added a disk (same 500mb size and part number) into the MSA60 raid enclosure and basically everything started going wrong. The raid 5 (3 hds) crashed and subsequently all the VMs running on that raid stopped working.

I was under the impression that you could add disks at runtime, thats what all this hot swap business was about?

Its a MSA60 running off a P800 raid controller in a HP DL380 G5. Windows Server 2008 r2

The machine reboots and sees the disk ok

So my question - When adding a disk to an existing raid, or to a raid enclosure to create a NEW raid, do you need to power down the machine to do so?

MORE INFO - 19/06/2012

I found another couple of disks and tried those in the machine. Same thing happened. The raid just slowly, over the span of around 5 mins, ground to a halt.

I have a dedicated server setup that has just started causing us issues. Our immediate problem, is that last week, could log into an admin page of one of our websites just fine, now we can't.

It does do a heavy SQL procedure on the SQL database, but as its only a small usage site, im ok with that.

The problem the website is timing out, and the admin's can not log in.

It seems that when the log-in is taking place, the SQL machine and Local server are communicating ok, but the network is being severely restricted. It appears to be being capped at 1.2Mbps.

Transfer speed graph http://driveiq.co.uk/temp/speed.png

Its not the SQL query, this runs and completes in 5 seconds. The script timeout on IIS is set to 120 seconds (i dont really want to extend this) SQL machine is a physical box, the webserver is a Virtual machine It looks like we SHOULD be getting 100 Mbps over the local network

Any ideas ?

Edit 1 : Here is a pic showing the local network between the two local machines capped at 200 bytes per second (1 meg) If I can transfer a file at 10 Meg a second, why is SQL server only transmitting its data out at 1 Meg ? http://www.driveiq.com/temp/1meg.png

Edit 2, the INTERNET network connection is 1 MEG, is that just a coincidence that it looks like the SQL server is transmitting over the internet connection as the speed are the same?

My question is about Virtual Machines and delivering their content over the servers connection to the internet.

I have an Ec2 windows instance, and its network connection appears to be 100mbps

If I was to be delivering content from that EC2 instance, is THAT my potential bottleneck?

How does s3 differ, I am guess their is no real potential outbound bottleneck with s3?

Note : I know s3 and their CDN would be better for static content, however I need to explore this situation for now. Our HTML pages need to access a server side page via AJAX, and because there is no bombproof work around for this at the moment our content and our server needs to be on exactly the same domain, so it rules out using S3.

Bandwidth needed : I am not sure, we could have up to 100 users downloading videos at any time, probably no more. Videos can be up to 5mb each, but they would view up to 20.

So....

In IIS, if you use the in-build FTP you need to combine the FTP host header in the FTP username e.g. www.hello.com|domain/username

So, the FTP program gets its "hook" from the username. However, you can connect to the FTP site using www.hello.com:21 over the FTP port.

Why then, doesnt the FTP service work the same way as the HTTP service?

IIS knows what site to serve back based on the host header after all....

Thanks!