BGP Consultant: When to Hire One and What to Expect

You should hire a BGP consultant when a routing mistake would cost you more than the engagement: first ASN and IP space, first multihoming, a migration of live prefixes, or a security baseline (RPKI, IRR, prefix filters) you can't verify yourself. If you already run clean eBGP with two upstreams and only need a config tweak, you probably don't need one.

This article lists the situations where outside help pays off, what the work involves at RIR and router level, and what a good engagement should leave behind.

Signs you need a BGP consultant

Hire help when one or more of these apply:

• You have no ASN or provider-independent space yet and need to pick a RIR, a sponsoring LIR, or the transfer market.
• You're moving from a single upstream to multihoming and have never controlled inbound traffic with BGP.
• You're renumbering or migrating live customers to your own prefixes.
• Your upstreams ask for IRR objects, AS-SETs or ROAs and you aren't sure what to publish.
• You were hit by a route leak or hijack, or your prefixes show RPKI-invalid in public looking glasses.
• You plan to use DDoS scrubbing over BGP, which requires your own ASN and routable prefixes (see below).
• Your team is strong in switching or hosting but has little production BGP experience.

Getting an ASN and IP space

Pick the registry path

Registry rules, eligibility and fees change, so check the current policy before committing. A consultant should know which path fits your legal entity and country, and should warn you about the paperwork (legal documents, justification of need, contact objects).

Size the space correctly

On the public internet, most networks filter anything more specific than a /24 for IPv4 and a /48 for IPv6. So the practical minimum for announcing IPv4 space is a /24. Buying or leasing smaller blocks gives you addresses you can't announce independently.

Also check the history of any transferred or leased block. Blocklist reputation, stale IRR route objects and old ROAs from the previous holder are common sources of post-transfer problems.

Multihoming: what actually gets designed

Multihoming is more than adding a second BGP session. A competent design covers:

1. Upstream selection: diverse paths, different physical routes, and at least one upstream that can accept BGP communities for traffic engineering.
2. Inbound policy: AS-path prepending, communities and more-specifics to steer traffic, with a plan for what happens when one upstream fails.
3. Outbound policy: local-preference per upstream, and protection against becoming a transit path between your providers.
4. Router sizing: a full table needs enough FIB and RAM. A default-route-only design is valid for small networks, but it limits your control.
5. Failure testing: shutting a session in a maintenance window and measuring convergence.

Baseline: never transit between upstreams

The most common multihoming accident is leaking one upstream's routes to the other. Only announce your own prefixes (and your customers'). Example on Juniper, with a prefix-list generated from your AS-SET:

# Generate the list from IRR (bgpq4)
bgpq4 -Jl MY-PREFIXES AS64496:AS-CUSTOMERS

set policy-options policy-statement EXPORT-TRANSIT term mine from prefix-list MY-PREFIXES
set policy-options policy-statement EXPORT-TRANSIT term mine then accept
set policy-options policy-statement EXPORT-TRANSIT term default then reject

set protocols bgp group TRANSIT type external
set protocols bgp group TRANSIT export EXPORT-TRANSIT
set protocols bgp group TRANSIT neighbor 192.0.2.1 peer-as 64511

On Cisco IOS-XE the same idea uses a prefix-list and route-map on the neighbor:

router bgp 64496
 neighbor 192.0.2.1 remote-as 64511
 address-family ipv4
  neighbor 192.0.2.1 prefix-list MY-PREFIXES out
  neighbor 192.0.2.1 prefix-list DENY-ALL in   ! replace with real inbound policy
  neighbor 192.0.2.1 maximum-prefix 1000000 90

Adjust the maximum-prefix value to what you actually expect from the neighbor; the number above is only an illustration.

RPKI, IRR and AS-SET: the paperwork that decides if your routes are accepted

IRR route objects and AS-SET

Upstreams and IXPs build their prefix filters from IRR data. For each prefix you announce you need a route: (or route6:) object with the correct origin ASN in an IRR database your upstream trusts (RIPE DB, RADB, ARIN IRR and others). If you have downstream customers, publish an AS-SET that lists your ASN and theirs, preferably hierarchical:

as-set:   AS64496:AS-CUSTOMERS
members:  AS64496
members:  AS64501
mnt-by:   EXAMPLE-MNT
source:   RIPE

Keep it current. Stale members and forgotten customers are a classic reason a new customer's prefix is dropped by an upstream filter for days.

RPKI ROAs

A ROA states which ASN may originate a prefix and up to what length. Create ROAs in your RIR portal. Keep maxLength tight: if you announce a /24 only, set it to /24. An overly generous maxLength lets an attacker announce a more-specific that still validates.

If a third party will announce your prefixes on your behalf, for example a scrubbing provider, make sure ROAs and IRR objects cover that origin as well. Confirm the exact requirement with the provider before cutover.

Reject RPKI-invalid routes

Once your own ROAs are right, validate what you receive. You need a validator (Routinator, rpki-client, or similar) reachable from your routers via RTR.

Juniper:

set routing-options validation group RPKI session 192.0.2.10 port 3323
set policy-options policy-statement IMPORT-TRANSIT term rpki-invalid from protocol bgp
set policy-options policy-statement IMPORT-TRANSIT term rpki-invalid from validation-database invalid
set policy-options policy-statement IMPORT-TRANSIT term rpki-invalid then reject

Cisco IOS-XE:

router bgp 64496
 bgp rpki server tcp 192.0.2.10 port 3323 refresh 600
!
route-map RPKI-IN deny 10
 match rpki invalid
route-map RPKI-IN permit 20

Linux with BIRD 2:

roa4 table r4;
protocol rpki rpki1 {
  roa4 { table r4; };
  remote 192.0.2.10 port 3323;
  retry keep 90;
  refresh keep 900;
  expire keep 172800;
}

filter import_transit4 {
  if roa_check(r4, net, bgp_path.last) = ROA_INVALID then reject;
  accept;
}

On MikroTik RouterOS v7, RPKI and filter syntax differ between versions. Test it on a lab device before production.

What a good engagement looks like

A solid BGP engagement is scoped, documented and leaves your team able to operate it. Look for these elements:

• Discovery: current topology, upstreams, prefixes, router models, and what you want to achieve (redundancy, DDoS readiness, traffic engineering).
• Written design: a short document with the policy per neighbor (what you accept, what you announce, communities, local-pref), IP plan and the RIR/IRR/RPKI objects to create.
• Registry work: ROAs, route objects and AS-SET created or reviewed, with the consultant working through your accounts rather than owning them.
• Config in your hands: full router configs in version control or at least handed over, not just applied.
• Staged cutover: pre-checks (looking glass, bgp.tools or RIPEstat views), a change window, and a rollback plan.
• Verification: confirm the prefixes are visible, RPKI-valid, and that failover works.
• Knowledge transfer: a runbook covering "upstream down", "prefix not visible" and "I need to announce a new block".

Red flags include a consultant who needs permanent ownership of your RIR account, can't explain their filtering approach, or proposes "accept everything" policies to save time.

Common mistakes to avoid

• Announcing prefixes before IRR route objects and ROAs exist.
• Missing or weak outbound filters, leading to route leaks.
• ROAs with an overly large maxLength.
• Stale or missing AS-SET entries after onboarding a customer.
• Running a full table on routers without enough FIB capacity.
• Treating DDoS protection as an afterthought: without detection, a volumetric attack forces you to blackhole the victim IP at the upstream.

Where DDoS protection fits in

Once you have an ASN and prefixes, DDoS options open up. Flow-based detection can trigger BGP blackhole (RTBH) or FlowSpec, and a BGP-based scrubbing service can take attack traffic off your links. NixGuard Edge requires your own ASN and at least one /24: your prefixes are announced from the scrubbing edge, and clean traffic returns over a GRE tunnel with a BGP session inside. Getting the ASN, IRR and RPKI work done before you onboard avoids delays.

If you want help with design, registry work or router configuration, see the NixMon network consulting page.