10G XFP Deployment Notes: Rolling Out XFP in a Live Network

Deploying 10G XFP modules in a live network is a maintenance task more often than a greenfield task, because XFP equipment is usually equipment that is already in service. That changes the planning: the network must keep running during the deployment, the spares holding must cover the transition, and the testing must prove each link before it carries traffic. This note works through that planning, from inventory to testing, with the mistakes that cause failed links called out along the way.

Start with inventory, and be specific. List every XFP slot in the deployment: the equipment, the slot, the current module if any, the fiber type of the plant it connects to, the distance of the link, and the application the link carries — Ethernet, SDH or Fibre Channel. That inventory is the deployment plan, because it states, link by link, what must be bought, what must be tested, and what must be spared. An inventory that lists speeds but not fiber types, or equipment but not distances, is not a plan; it is a shopping list, and it will produce wrong orders.

The published XFP model on this site illustrates what a complete inventory entry looks like. The XFP LR states a 10G rate, a 1310nm wavelength, a 20km reach over single-mode fiber, a rate range of 9.95 to 11.1Gb/s, a duplex LC connector, power consumption below 2.5W and a 0 to 70 degree Celsius operating range, with applications in SDH, 10GBASE-LR and LW, and 10G Fibre Channel. An inventory entry for a link that will use that model should state the same properties for the link: single-mode fiber, up to 20km, LC connectors, and the application — Ethernet, SDH or Fibre Channel — so the configuration can be confirmed. An entry that states only the speed leaves the configuration to chance.

Spares planning follows inventory, and it should reflect the deployed mix rather than the catalogue. If the deployment uses three XFP titles, the spares holding should cover those three titles, in proportion to their deployment, plus one spare for the most critical link. A spares holding spread across the whole XFP family, with one of everything and two of nothing, is worse than a holding concentrated on the deployed titles, because the title that fails is almost always a deployed title. The XFP series page on this site lists the titles in the family, and a buyer planning spares should start from the deployed titles, not from the catalogue.

Testing is the step most often skipped and most often regretted. Every link should be tested before it carries traffic, and the test should cover what the link will actually do: the module seated correctly, the fiber clean and correctly mated, the link up at the expected rate, and the error rate clean over a test period. A link that comes up is not necessarily a good link: a dirty connector can produce a link that comes up and then drops errors under load, and only a test under load, or at least a test that checks error counters, will catch it. Testing each link before it carries traffic costs minutes per link and saves outages.

The mistakes that cause failed XFP links are familiar, and they are all avoidable. The wrong fiber type: a single-mode module on a multimode plant, or the reverse, produces a link that never comes up. The wrong application configuration: a module set for Ethernet on an SDH link, or the reverse, produces a link that comes up and then fails to frame traffic. The dirty connector: a link that comes up and drops errors, caused by a connector that was never cleaned. The unconfirmed variant: a bidirectional module ordered without its matched pair, producing two modules that transmit at the same wavelength and cannot talk. Each of those mistakes is prevented by stating the link — fiber type, distance, application, both ends — during the inquiry and at installation.

Before ordering, confirm quantity, price and delivery time during the inquiry, together with the inventory: the equipment, the fiber type, the distance and the application for each link. Certificates are available upon request.

Change windows and rollback planning are the operational side of XFP deployment, and they matter more in a live network than in a new build. A link migration in a live network must happen inside a change window, with traffic migrated away or with the service owner notified, and with a rollback plan: the old module kept, the old configuration recorded, and a tested route back if the new link fails. A deployment without a rollback plan is a gamble, because a link that fails at 3 a.m. with no way back becomes an outage rather than a failed change. The rollback plan costs a paragraph in the change record and saves an outage.

Firmware and compatibility matrices are the second operational check, and they are specific to legacy equipment. An XFP module that works in one firmware version of a switch may not work in another, because the switch reads the module's identification data and decides whether to accept it, and that decision logic changes between versions. A buyer deploying XFP modules across a mixed firmware estate should check the compatibility matrix for each switch model and firmware version in the deployment, not just for the newest version, because the oldest switch in the estate is usually the one with the strictest acceptance logic. Testing a new title in the actual switch model and firmware version, before wide deployment, is the practical form of that check.

Post-deployment monitoring is the step that proves a deployment rather than merely completing it. After each link is migrated, its error counters should be checked over a test period, and then checked again after a week of live traffic, because some faults — a marginal connector, a dirty end face, a variant mismatch — present as errors under load rather than as a dead link. Thresholds should be set per link type, not uniformly, because a legacy XFP link and a current SFP+ link report diagnostics differently, and a uniform threshold will either miss faults on one format or raise false alarms on the other. A deployment is complete when its links are monitored and clean, not when its modules are installed. Before ordering, confirm quantity, price and delivery time during the inquiry. Certificates are available upon request.

Training for the team that will maintain the deployment is the step most often treated as optional, and it should not be. A team that has maintained SFP+ links may not know the handling differences, the diagnostic differences or the spares differences of XFP, and a deployment that introduces a new format without training the maintainers introduces faults that training would have prevented. A short session — the format difference, the handling rules, the diagnostic coverage, the spares holding and the rollback plan — costs an hour and prevents the first three faults of the deployment. The session should be recorded, so the next team inherits it rather than rediscovering it.