WatchGuard Firebox M470 leaves an SFP+ interface down with third-party optics
Small office, one Firebox M470 on the perimeter, and I wanted to move the link to the core switch off copper and onto the built-in SFP+ ports. Bought a pair of generic SFP+ modules for it, one for each end. The switch side lights up straight away, the Firebox side never does.
Kit:
- WatchGuard Firebox M470, built-in SFP / SFP+ ports
- generic uncoded SFP+ modules, same model at both ends
- core switch on the far end, port comes up and stays up
- short patch, both ends cleaned before insertion
Interface status on the firewall, with the remote port left alone in between:
interface (SFP+) link: down speed: auto-negotiate
interface (SFP+) link: down speed: 10G fixed
Tried:
- moved the module to the second SFP+ cage, same result
- set the far end to a fixed 10G and back to auto, no difference either way
- put the same two modules back to back between two switches, where they link without complaint
Is this just the appliance refusing modules it does not know, or is there something on the negotiation side I should be setting before I give up and buy branded optics?
Comments 3
This is a known issue on their side rather than something you have configured wrong. It is logged as FBX-24737 in Fireware, article 000028191, still Open: interfaces that will not come up once a module from anyone but WatchGuard is fitted.
The note gives three things to work through, and the order matters.
First, check the transceiver against WatchGuard's supported-transceiver list for your exact appliance. Not the family, the model - the lists are not the same across the range.
Second, check that your module and whatever it is talking to on the far end really do agree on operating mode and on the features each expects of the other. Two modules that botth say 10G SR on the label can still differ in everything else.
Third, go at the negotiation settings from the remote equipment rather than from the firewall. Auto-negotiation first; if that leaves you with nothing, pin the rate by hand at 1G or at 10G, since plenty of modules run at one rate only and will sit there mute when asked for the other.
Be honest with yourself about what this is, though. It is a checklist for finding an interoperable module, not a fix: the issue is open and there is no unlock command that makes the appliance accept arbitrary optics. If the three checks do not produce a link, a module from the supported list is the shortest way out.
Which Fireware branch is on it, and are those modules on the supported-transceiver list for that appliance, or are they just 'generic 10G SR'? That list matters more on these boxes than people expect.
The other thing I woould want to see is what the far end really does. You say the switch port comes up, but comes up at what speed - if that port settles at 1G while the firewall insists on 10G you will never see a link, and the module you picked may not even do both rates. Plenty of them are single-rate.
And you have already ruled out the second SFP+ cage - does the module behave any differently in one of the plain SFP cages? Not that a 10G module will link at 1G there, but whether the box registers it at all separates the appliance rejecting the module from something about that par of cages.
Adding a case that runs the other way, because forcing the speed is not always the right reflex.
On a VSP 4450GSX the release notes are blunt about it: point a 1 Gb SFP at a switch from another vendor and autonegotiation has to stay on, permanently - and that applies to the module in either cage, the 1 Gb slot and the 10 Gb one alike. Switching it off is what breaks those links, which is the reverse of what most of us reach for when a port refuses to come up. With 1000BASE-T copper SFPs the notes push it one step further: decide how autoneg is set at the far copper end too and configure it there on purpose, or the next person who changes speed or duplex over there takes the link down with them.
The VSP 7254XSQ in the same family has no autonegotiation support whatsoever, so a 1 Gb SFP comes up there only if the remote end has it turned off. One vendor, two boxes, opposite settings. So test both directions on the remote side before you conclude the firewall is the guilty party.