MSPSS: is there life after the helpdesk?

sharing solutions to uncommon IT problems

Archive for the ‘Networking’ Category

Splitting HTTP traffic between 2 servers using the same URL – Reverse Proxy

leave a comment »


Due to a problem with a customer, yesterday we found ourselves in a situation where they needed to split traffic between a remote and a local server for incoming HTTP requests for the same URL (different subfolders).

Our customer needed to redirect /* to their external server and /somesubfolder/* to a local server in our network.

The first reaction was “this cannot be done” but after some thinking I realized this could be achieved using a Reverse Proxy which would analyze the incoming traffic for that URL and redirect to the appropriate destination.

In our network we have a ISA Server which we use exclusively for publishing OWA, so I decided to give it a try and it worked! Here below are the steps to create a successful Reverse Proxy with multiple destinations:

– Create a web listener configured to listen on whichever IP address you will use to resolve your URL (obviously the IP Address needs to be added to the Nic of your ISA Server first).

– Create 2 Web Publishing Rules: one for the remote site, I called it “www publishing rule” and one for the internal site “internal site publishing rule”)

– The rules have to be configured in a pretty standard way: remember to select the correct listener in the listener tab and to insert the correct website name in the “Public Name” tab.

– The will only differ in the following tabs:

"Paths" Tab

“Paths” Tab

"To" Tab

“To” Tab




Written by zantoro

January 11, 2013 at 2:45 pm

Posted in ISA, Networking

Tagged with , ,

DNS A record change – World Wide replication

leave a comment »


this is just a brief post where I would like to share my findings about DNS changes and World Wide replication.

Up till now I was always told that a World Wide replication of a public DNS modification (e.g. A record) would take up to 72h. It seemed strange to me so I did some research and it turns out this if far from true.

World Wide replication time is entirely dependent on the record (not the zone) Time to Live which contrary to popular beliefs, IS a reliable setting.

For Windows users, in order to see the record’s TTL, you’ll have to click View -> Advanced in the DNS console.

The default setting on windows DNS is 1h which means a World Wide replication of a record change could take up to 70 or 80 minutes.

My suggestion is to set the record’s TTL to 5 minutes 24h before doing the DNS update and change it back to 1h right after you updated the record.



Written by zantoro

December 23, 2012 at 10:38 pm

Cascading Switches: how many switches can we cascade?

leave a comment »

One of our responsibilities here is to set up networks at big conferences hosted in hotels all around the world.
For a long time we have had a golden rule which I never understood: “never put more than 3 switches in cascade in the same network segment”.
1. Why no more than 3?
2. What’s the risk?

I searched Google everywhere for a canonical limitation in the number of switches cascading in the same segment but I only found very vague indications and none of them ever said why. Some said 7, some 8 and another guy 12 (still far from our golden rule of 3).

Personally I recognize 3 risks in having many switches in cascade:

  1. Bottlenecks: a switch allows communication among its ports using an very large internal bandwidth (aka backplane bandwidth). Connecting two switches over ethernet limits the speed on that segment to the speed of the port.
    Obviously there’s a lot more to the performances of a switch than the simple difference between internal speed and port speed but this is not the scope of this article.
  2. Fault tolerance: a line of switches in cascade means that if any of those fails (or if any of the connecting cables fails) a whole section of the network goes down. The more switches you introduce in your network the more chances you have of having a failure.
  3. Monitoring, administration and negotiation: if you have many switches, it is more difficult to keep them under control and especially in the event of different brands and models, bad negotiation is always behind the corner.

In some forums (please note that I found no official document supporting this theory) some people say extensive cascade switching could lead to Broadcast Storm.
As far as I know, Broadcast storm is usually caused either by an eccessive number of clients in the same broadcast network or by malicious clients attempting a DoS attack through Broadcast. Neither of these causes is consequence of the number of switches that you have in a network.

Last but not least I would like to state clearly that the 5-4-3 rule does not apply here because that rule does not apply to ethernet switched networks:

Written by zantoro

September 19, 2012 at 10:16 pm

Posted in Networking

Tagged with