make sure you have one set to Primary and one set to Secondary in the failover page.
Mike, Thanks for the response.
We did set one one as primary and the other as secondary.
Both ports were marked as ENABLED. Should the primary be REQUIRED?
> ... v3.1.5u1 / v3.1.3 ...
Its a good idea to run the latest firmware. Perhaps 4.0.5 is too big a step - but upgrading to 3.2.2
on both of these is a no-brainer, particularly since there were a number of HA/failover/highavaild
related fixes between 3.1.5u1 and 3.2.2.
> ... network traffic gets to the 2nd SG560 ....
presumably you are using tcpdump or the equivalent UI tool to see this happening.
check the src/dst addr of the packets in question and make sure routing/NAT is set
up on the 2nd 560 to deal with it. eg. return traffic could be going into a bit-bucket, or
dst-addr could be being directed to the wrong place. There is a route-table under
'Diagnostics'. or you can ssh into the cli and type 'route'.
If a 'tcpdump -ni any' doesn't show the packet(s) leaving to anywhere, they are probably
being dropped by the firewall. Worth comparing 'known good traffic going through 2nd 560'
tcpdump -ni any behavior. Use a port restrictor to eliminate noise. eg.
'tcpdump -ni any icmp' or 'tcpdump -ni any port 23'
then generate test-traffic appropriate for the filter (eg. ping, or telnet some-internal-site
All these can work from the 'Diagnostics -> Packet Capture' window as well, I just find
the CLI tcpdump command quicker/easier once I get stuck into a debug cycle.
Check syslog for any firewall rule dropping packets unexpectedly, and/or custom firewall
rule counters (can be hard to see if other network traffic is going on).
That's probably enough to establish a baseline and eliminate a bunch of potential issues.