www.question-defense.com | Engage: Visit :: Login :: Register
Translate to English Übersetzen Sie zum Deutsch/German Переведите к русскому/Russian Μεταφράστε στα ελληνικά/Greek Vertaal aan het Nederlands/Dutch ترجمة الى العربية/Arabic 中文翻译/Chinese Traditional 中文翻译/Chinese Simplified 한국어에게 번역하십시오/Korean 日本語に翻訳しなさい /Japanese Traduza ao Português/Portuguese Traduca ad Italiano/Italian Traduisez au Français/French Traduzca al Español/Spanish
0
The question is often raised of how to provide a redundant network solution when connecting your leased cabinet or cage to your colocation’s network. This goal can be achieved in numerous ways but most solutions are fairly expensive. Below I list an entry level option to provide network redundancy when connecting to your colo. One of my preferred vendors is Fortinet because of cost and functionality. Most Foritnet devices will handle BGP, IPS, and provide seamless redundancy between devices. The solution below can be upgraded by purchasing more powerful devices as well as introducing a couple more devices into the solution.


High Availability:

The hardware required to complete the option visually detailed in the image below includes two firewalls, two switches, two load balancers, and any number of servers depending on your traffic and application. The hardware I have recommend and have personally used in this configuration is two fortinet 200A firewalls, two dell 5424 gigabit switches, two foundry ServerIron load balancer switches, and a mix of Dell PowerEdge servers. To provide full redundancy we will be touching on network redundancy as well as hardware redundancy.

Hardware Redundancy:
First hardware redundancy is provided by having at least two of each device.

Firewall Redundancy:

The Fortiniet firewalls are configured in an active/passive configuration in NAT mode. The trick here is the Fortinet 200A firewalls will connect to the internal network on the DMZ port instead of the internal port. The reason for this is the devices will not allow you to configure VIP’s (used to NAT through to internal IP’s) on each of the WAN interfaces. The devices are connected via a cable on the DMZ2 interface of each device to pass a heartbeat back and forth. The device with the higher priority assumes the role of active firewall which provides the high availability for these devices.

Switch Redundancy:

The switches redundancy is easy since they are only providing layer two services. We will talk more about their mesh connection when we get to the network redundancy below.

Load Balancer Redundancy:

The load balancers are also in an active/passive configuration which allows them to keep sessions information between the two. Each load balancer has basically the same configuration also using VIP’s(Virtual IP’s).

Server Redundancy:

The servers that you deploy should have the same exact Operating System and OS packages installed on each. Make sure that you have at least two servers providing the same application services to the end user in each of the server farms shown in the image above. This allows any server downtime to not be noticed by any clients connecting to the application. If anything happens to SW01, FW01, or anything in server farm one then the servers in server farm two will perform.

Network Redundancy:

Network redundancy can be broken down into the internal network and the external network.

The external network can be redundant by obtaining two drops from your colo each from a different router. Typically each drop has its own /30 configured on it so you can set up communication between your firewalls and the colocations routers/firewalls. Then ask your colocation to route a your public IP space via BGP over each of the drops they have provided. BGP will allow your primary link to drop and be picked up by the secondary drop with minimal downtime without any human interaction. First you plug the each drop into a different switch on your network to then split out two Ethernet cables from each switch and plug them into the WAN ports on your firewalls. For instance drop one from the colo plugs into SW01 and then splits to plug into each WAN1 on each firewall. Drop two from the colo plugs into SW02 and splits out to plug into each WAN2 of each firewall. If you do not have the budget for four switches then you can create a VLAN on each switch with three ports in it to accomplish each goal.

The internal network redundancy is provided by plugging DMZ1 on FW01 into SW01 and DMZ1 on FW02 into SW02. SW01 and SW02 should be connected together as well to allow the servers in server farm one and server farm two to traverse the network out either firewall if necessary. LB01 should be plugged into SW01 and LB02 should be plugged into SW02.

If there are any questions relating to the above comments please contact us. Question Defense contributers also provide consulting services as well.

DeliciousStumbleUponDiggTwitterMixxTechnoratiFacebookNews VineLinkedInYahoo! Bookmarks
Related posts:
  1. Fortinet CLI Equivalent To “show ip bgp” Recently I worked on a network installation using Fortinet 200A...
  2. Network Port Scanning With iPhone, Network Discovery with iPod Touch, Network Troubleshooting with iDevices I purchased an amazing application from the iTunes store tonight...
  3. Securing Default Passwords on Your Network. This is going to be a little bit of a...
  4. How To Remove Cisco Systems VPN Adapter From Network Connections If you have recently removed the Cisco Systems VPN client...
  5. Lacie 2Big Network NAS Device: Shares Not Displaying In The Admin Interface A small business I with has a Lacie 2Big Network...

Tags: , , , , , , , , , , , ,
7 Responses to “Set Up A Redundant Network In A Colo”
  1. Jim says:

    Interesting, we’re just about to move from VPS to colo and are primarily web devs and not a vast amount of network structure/topology knowledge. Your article is what we’re looking at implementing.
    With reference to the image, the top units at the top of “Your Network”, are they switches/routers and if switches, would 5424’s do (I couldn’t find reference to them working with BGP on the dell site).
    Also, “Then ask your colocation to route a your public IP space via BGP” as I understand this is PI space, is this correct?

    If we were to implement the above/similar in a staged setup to keep startup costs down, would the layout be [with PI space from the outset]:
    COLO FEED -> switch [5424?] -> firewall ->
    switch
    | |
    V V
    svr1 svr2
    or would it be Feed > fwall > switch > servers.

    Thanks

    [Reply]

    alex Reply:

    Hello Jim,

    At the top of the network used in the example those are switches and 5424’s will work fine. The BGP is actually done with the firewalls located behind the switches. The switches are used for to provide more redundancy. I am not familiar with the term PI, but maybe you mean public Internet? You wouldn’t need the switch out front to do thise setup if you only had one firewall. So you would only need firewall to switch so your second example is the proper way.

    If you have more questions let me know via the contact form on the site.

    Hope this was helpful.

    [Reply]

  2. Mark says:

    Alex, this article caught my eye as I’m attempting a nearly identical setup, even including two Fortigates and two Dell 5424 switches. In my case, there are a series of Dell servers, each with two NICs. My understanding is to make them redundant across two switches, I need to “bond” the NICs (Red Hat EL 5.4). So I set that up, plugged eth0 into one switch, and eth1 into the other. Everything seemed fine, but within a few minutes, I could no longer ping anything else in the environment from the server I was working with. My guess (and it really is a guess) is that I created a network loop. So I guess what I’m asking is, how to I cable the NICs to Switches to Firewalls and avoid this issue?
    Thanks

    [Reply]

    alex Reply:

    Hello Mark,

    You cannot have two Ethernet cards on the same LAN. How I had this set up was to have eth0 on a private LAN with Internet access and eth1 on a completely separate LAN that was blocked from the Internet. For instance eth0 was on the 192.168.1.0/24 and eth1 was on the 192.168.200.0/24 network. If you wanted two NIC’s (Ethernet Cards) for redundancy then you could write a shell script that only brings up eth1 when a ping to the gateway fails. There is also another way to do this these days in the form of a Linux package but I forget specifically what it is right off. I have done it in the past with a shell script however the preferred method is to add a load balancer to the mix and only direct traffic to *UP* web servers for instance.

    Hope that helps some. If you continue to have issues I specialize in consulting related to redundant networks so shoot me a message if there is anything I can assist with.

    Thanks.
    alex

    [Reply]

  3. loopzy says:

    Thank you! just what I need to read right now…

    [Reply]

    alex Reply:

    Hello loopzy,

    No problem. Hope it is everyhing you are hoping for.

    Thanks.
    alex

    [Reply]

  4.  
Leave a Reply