Summary

  • A NANOG 98 presentation describes steering selected TCP ports from an aging site to a cloud destination while the legacy site kept the service IP advertised.
  • The speaker reports 3,000 ports moved in six months, two application-related rollbacks and zero transactional loss; RFC 8955 does not standardize the deck’s redirect-nh action.

A payment session does not care that a migration plan calls itself “gradual.” It cares whether its next packet reaches the same service. At NANOG 98, infrastructure architect Hervé Hildenbrand described a service whose clients used a hard-coded IP over raw TCP. There was no DNS record to repoint, no proxy hop the application could tolerate and no client firmware the team could change. Moving the whole /32 at once would move more than 3,000 TCP ports together; advertising it from two sites risked splitting live sessions.

The team’s answer, as shown in the NANOG presentation, was to keep ordinary traffic on the legacy route and redirect only chosen destination, protocol and port combinations. The slide deck shows BGP FlowSpec rules changing the next hop to an Anycast anchor in a new cloud, with MPLS carrying the redirected traffic between sites. Move a port when it is ready; leave the rest alone. Once the last service had moved, the deck’s final sequence advertises the /32 from the new edge, withdraws it from the old edge, then removes the FlowSpec redirects.

That is a neat use of a tool better known for traffic filtering. It is also a reminder that “FlowSpec” names the matching and distribution mechanism, not a universal steering command. RFC 8955 lets a rule match destination prefix, protocol and ports. But the RFC says the FlowSpec NLRI’s next-hop address is ignored. Its standardized redirect action sends matching traffic to a VRF selected through a route target. Hildenbrand’s slides instead show redirect-nh to an Anycast address. The RFC allows additional actions to be standardized separately or to be vendor-specific; it does not make this particular next-hop rewrite portable by declaration. The deck does not identify the implementation or provide its wire encoding.

The safety design is therefore part of the story, not supporting cast. The slides show rules declared in Git/Terraform, a CI/CD pipeline checking destination addresses, port ranges and authorized next hops, and router filters that reject an unauthorized target. An erroneous rule could affect traffic at forwarding speed across the backbone. Validation before injection and a hard filter at the device constrain who can turn a narrow migration rule into a very wide problem.

The slides report 3,000 TCP ports moved over six months, convergence below one second, two rollbacks caused by application issues and zero transactional loss. Those are figures from the presenter’s case study, not an independently audited service log. The address 192.0.2.50 in the diagrams is in RFC 5737’s documentation-only TEST-NET-1 block; 10.100.0.254 is private address space under RFC 1918. The deck gives no customer name or live address, and the routing example should be read as an illustration.

The most useful result is not “FlowSpec can move a service.” It is that the migration split one global identity—the IP address—into smaller operational decisions, then surrounded each decision with a specific match, an approved destination and a reversible change. That bought the team room to discover application problems without turning every one into a network-wide cutover.

Sources: NANOG 98 session; Hildenbrand’s NANOG 98 slides; RFC 8955; RFC 5737; RFC 1918.