5

First, please see the attached network diagram to see what I am trying to do.

enter image description here

On the 2 distribution switches, we run HSRP and have one Fortigate going to SW1 and the other going to SW2.

Then we have vmware esx hosts with connections to each of the fortigates. The fortigates are configured in an active-active ha config as are the vmware vswitches.

Now for some reason, when we disconnect the cable from the monitored wan1 port on either of the fortigates, the ip assigned the a vm on either of the esx hosts fails to be reachable however the ip assigned to the fortigates is reachable just fine. For some reason, traffic isn't being passed through the fortigates.

However, if you look at this diagram, the vm ip is reachable just fine when the devices failover.

enter image description here

I've tried setting different interface tracking options in hsrp and tried using "ip sla" as well to no avail.

Am I missing something somewhere either on the fortigates or on the distro switches?

  • Please, try to ping your server after activating the following: diagnose debug enable, diagnose debug flow function-name enable, diagnose debug flow show console enable, diagnose debug filter daddr <your firewall addr>, diagnose debug trace start 50. Put the output to pastebin and link the URL here – Marco Marzetti Aug 13 '13 at 10:37
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 8 '17 at 14:23
3

Let me preface this by saying that I have not used Fortigate, but speaking generally.

You should have two links from each firewall (FW ), one to each switch (SW), just as you have a link from each FW to each server (SRV).

This is what I suspect is happening. Assuming SW1 is the HSRP active interface, it initially receives traffic from SRV2 on the link to SW2 and creates an entry in the MAC and ARP tables. When the link between SW2 and FW2 goes down, SW2 removes the entries for that interface from it's tables, but SW1 doesn't know the link is down and maintains it's entries.

When traffic comes in to SW1 for SRV2, it looks up the ARP/MAC information and sends the traffic to SW2. SW2 doesn't have an entry for SRV2 anymore, and floods it out all ports except the one it received the traffic on (normal switch operations). This results in the traffic never reaching SRV2 as none of the other links on SW2 provide a path to SRV2.

With the second link the traffic between FWs and SWs, the flooded traffic would then be received at FW1 and be able to get to SRV2.

If you have outbound traffic from SRV2 after the link goes down, or you clear the MAC entries on SW1, I suspect that this would work as well.

| improve this answer | |
  • Thanks for the input. I just tested with connecting both WAN ports on each fortigate to each of the switches so it's a full mesh. I then shutdown one of the wan ports on the switch so the port is link down however the traffic does not continue forwarding out the 2nd wan interface. – Network Samurai Aug 13 '13 at 12:22
  • In that case, it must be something in the configuration somewhere in the setup. You will probably need to start adding config to your question. I would also,recommend opening a ticket with Fortigate. – YLearn Aug 13 '13 at 13:24
  • I was able to finally get this working. Fortigate has an option to separate the "internal" interface into individual ports. I did this and then setup a software switch between ports 1+2 which went to the respective distros. I have the Fortigate's in an Active-Active configuration. I then setup the appropriate ports on the distro switches and the monitored ports in the HA config. I also had to setup a separete vlan interface under the new software switch interface to point to the vlan I had trunked on the distro switches. Everything worked fine then! Thank you everyone :) – Network Samurai Aug 13 '13 at 14:37
0

I haven't set it up before but I think you'll need to either configure 'full-mesh' HA between the 100D's and your two switches. We use stacked 3750's for redundancy with 2x 100D's in HA instead, seems to work well enough.

http://docs.forticare.com/fos50hlp/50/FortiOS%205.0%20Help/full_mesh.120.05.html

I would assume on the the FG HA is working fine, but your 'Internal' switch isn't getting the message that the Primary 'internal' FG link is no longer the one it should be talking to.

| improve this answer | |
  • Thanks for the answer. The issue really isn't the internal switches in the 2nd diagram since that works ok. The issue is with the first diagram and the traffic flow when the failover happens. – Network Samurai Aug 13 '13 at 2:39
  • Sorry, didn't read closely enough. I would still think it's something to do with your hosts not knowing that they're now talking to the standby/failed fortigate. 'Active-Active' vs 'Active-Passive' is really only related to UTM offloading. Have you tried running VRRP on the fortigates instead of their HA mode? – atp Aug 13 '13 at 2:48
  • I was able to finally get this working. Fortigate has an option to separate the "internal" interface into individual ports. I did this and then setup a software switch between ports 1+2 which went to the respective distros. I have the Fortigate's in an Active-Active configuration. I then setup the appropriate ports on the distro switches and the monitored ports in the HA config. I also had to setup a separete vlan interface under the new software switch interface to point to the vlan I had trunked on the distro switches. Everything worked fine then! Thank you everyone :) – Network Samurai Aug 13 '13 at 14:56
  • Glad it's working :) I'd still test your various failover scenarios as much as you can before production (I find the FG HA to work great, but how devices on each side react can be a bit hard to understand). I don't think we have any FG's in production where the internal switch isn't running in interface mode, every site will have at least a Cisco 2960G for handling switching between internal hosts. You may want to make sure that the 2pt switch you've created isn't actually being processed in software. I'm confident it's not on the 100D's but it'll hit your CPU hard if it is. – atp Aug 14 '13 at 1:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.