Skip to main content
Coplango
Request a BGP and peering review

Backbone design and traffic engineering

Most backbones are planned once and then patched. We rebuild the picture from the routers, measure what the traffic actually does, and plan changes against every failure you might see at busy hour.
Request a BGP and peering reviewRelated case studies
Failure simulation on a six-PoP backboneSix points of presence connected in a ring with one cross link. The map fails one link at a time and shows the path traffic from PoP A to PoP C takes, then brings the link back. When the link between PoP B and PoP C fails, traffic runs from PoP B down to PoP E, across to PoP F and up to PoP C. When the link between PoP A and PoP B fails, it runs from PoP A down to PoP D, across to PoP E and PoP F and up to PoP C. When the link between PoP E and PoP F fails, the traffic isn’t affected and still runs through PoP B.PoP APoP BPoP CPoP DPoP EPoP F
  • Traffic from A to C
  • Backbone
  • Failed link

What usually prompts the call

  • One link saturating at busy hour while parallel paths have room
  • Nobody sure what happens if a particular cable or router fails
  • IGP metrics set years ago by people who have since left
  • Capacity bought where traffic is today, not where it goes after a failure
  • An MPLS core that’s hard to operate, or a segment-routing migration that keeps slipping

What we do

  • Start from the routers

    A read-only collector builds the topology, links and IGP adjacencies from the routers themselves, so the model matches the network rather than the last diagram.

  • Estimate the traffic matrix

    From interface counters you already collect, or from flow data where you have it. The estimate is checked against links held back from the fit.

  • Simulate every failure

    Every single cable, router and LAG-member failure at busy hour, with ECMP, and the links each one would overload.

  • Change one metric at a time

    Only changes that improve normal operation and don’t make any simulated failure worse go into the plan, each with a rollback.

What you get

  • A traffic matrix and a topology model of your backbone
  • A failure report: which failures overload which links
  • A metric plan to apply one change at a time
  • MPLS or segment-routing designs, with TI-LFA and Flex-Algo where they pay off

Technologies

  • OSPF
  • IS-IS
  • ECMP
  • BGP-LS
  • MPLS (LDP, RSVP-TE)
  • segment routing
  • TI-LFA
  • Flex-Algo
  • Juniper
  • Arista
  • OcNOS
All case studies

Questions

Do we need a commercial traffic-engineering tool?

No. Interface counters and a model of your topology are enough to start. Corepath, our own platform, does this continuously if you want it to.

Will you change metrics on our live network?

Only one at a time, in your change windows, with your engineers, and with the rollback written down before we start.

Start with the review.

Configs and two weeks of flow data are enough for us to tell you what we’d change first.

Request a BGP and peering review