Skip to content
Log in Sign up My account

1.5 BGP Design

Blueprint 1.5: Stable, secure, and scalable routing designs for BGP

  • 1.5.a Address families (IPv4, IPv6, VPNv4, VPNv6, EVPN) and how to separate them
  • 1.5.b Basic route filtering (prefix-lists, AS-path filters, communities, route maps)
  • 1.5.c Attributes for path preference, inbound and outbound
  • 1.5.d Route reflectors (placement, redundancy, cluster design, alternatives)
  • 1.5.e Load sharing (multipath, dual homing, unequal-cost options)

BGP is the policy protocol. Where an IGP chooses the shortest path, BGP chooses the path your business prefers. Design questions therefore revolve around who you trust, which attribute influences which direction of traffic, and how to keep the table and session count manageable. Mechanics are in ENARSI BGP: best path, policies, route reflectors and sessions, plus ENCOR eBGP.

1.5.a Address families

Multiprotocol BGP (MP-BGP) carries many kinds of reachability in one session through address families. Each family has its own policy, neighbour activation and prefix limits.

Address family Carries Typical design use
IPv4 unicast Internet and enterprise IPv4 Edge peering, data centre underlay
IPv6 unicast IPv6 prefixes Dual-stack edge. Peer over IPv6 or carry IPv6 over an IPv4 session.
VPNv4 / VPNv6 Customer prefixes with route distinguisher MPLS L3VPN (ENARSI L3VPN)
L2VPN EVPN MAC and IP reachability Data centre and campus overlays
IPv4 multicast Multicast RPF information Inter-domain multicast

Design choices:

  • One session per address family set or separate sessions? One IPv4 session carrying IPv6 reduces session count but ties both stacks to one transport. Separate IPv4 and IPv6 sessions give independent failure domains and independent policy. With an ISP, separate sessions are common because the provider treats the families as separate services.
  • Next hop handling: when IPv6 prefixes are carried over an IPv4 session, the next hop must be set to a reachable IPv6 address (or an IPv4-mapped one in 6PE). A missing or unreachable next hop is the typical failure.
  • Keep policy per family. An inbound filter written for IPv4 does nothing for IPv6.

1.5.b Basic route filtering

Filtering is the first line of BGP stability and security: prefixes you accept from or send to a neighbour should be limited to what that neighbour is entitled to.

Tool Matches on Best for
Prefix-list Prefix and length (ge, le) Accepting only expected prefixes, blocking bogons and too-specific routes
AS-path access list / filter-list Regular expression on AS path Allow only locally originated routes outbound (^$), block transit
Community Tags attached to routes Scalable policy: provider sets the tag, you act on it
Route map Any combination, plus actions that set attributes Policy that both filters and changes attributes
Prefix limit (maximum-prefix) Count Protects the router from a leaked full table
ORF (outbound route filter) Prefix list sent to the neighbour Neighbour sends only what you want, saving bandwidth

Typical enterprise edge rules for a dual-homed customer:

  • Outbound: announce only your own prefixes (prefix-list) and never routes learned from one ISP to the other. This prevents your AS from becoming a transit AS between providers.
  • Inbound: accept a default route, or a default plus a partial table, or the full table. Block RFC 1918, the default if not wanted, your own prefixes, and overly specific prefixes (longer than /24 for IPv4).
  • Prefix limits with a warning threshold on every external neighbour.
  • Authentication and TTL security: MD5 or TCP-AO, and ttl-security hops for single-hop eBGP.
ip prefix-list MY-PREFIXES seq 5 permit 203.0.113.0/24
ip prefix-list FROM-ISP-A seq 5 permit 0.0.0.0/0
!
route-map TO-ISP-A permit 10
 match ip address prefix-list MY-PREFIXES
 set as-path prepend 65001 65001
!
router bgp 65001
 neighbor 198.51.100.1 remote-as 64500
 neighbor 198.51.100.1 password <secret>
 neighbor 198.51.100.1 ttl-security hops 1
 address-family ipv4
  neighbor 198.51.100.1 route-map TO-ISP-A out
  neighbor 198.51.100.1 maximum-prefix 500000 80
  neighbor 198.51.100.1 prefix-list FROM-ISP-A in

Exam trap

A multihomed enterprise with no outbound filter advertises everything it learns from one ISP to the other and becomes a transit network. The right fix is an outbound prefix-list or AS-path filter (^$) toward both providers, not a lower local preference.

1.5.c Attributes for path preference

The most tested BGP design skill is knowing which attribute influences which direction.

Goal Attribute Scope How
Choose the exit for outbound traffic Local preference Throughout your AS (iBGP) Set higher on the preferred ISP's routes. Highest wins.
Choose the exit on a single router Weight One router only (Cisco proprietary, not advertised) Quick local override
Influence which entry ISPs use inbound AS-path prepend To neighbours and beyond Lengthens the path on the backup link
Hint to a directly connected neighbour AS MED One AS hop, compared only between paths from the same neighbour AS by default Lower wins. Useful for multiple links to one ISP.
Scalable provider control Communities Anywhere they are propagated Provider maps community to local preference or prepend

Best-path order to remember (Cisco): highest weight, highest local preference, locally originated, shortest AS path, lowest origin code (IGP, then EGP, then incomplete), lowest MED, eBGP over iBGP, lowest IGP metric to next hop, then the tie-breakers (oldest eBGP path, lowest router ID, shortest cluster list, lowest neighbour address).

Practical rules:

  • Outbound control is yours: use local preference. It is strong, early in the order, and shared across all your routers.
  • Inbound control is only a request: prepending and MED influence but cannot force a provider's decision, because the provider's own local preference usually beats AS path length. Provider communities are the stronger inbound tool.
  • More specific prefixes beat everything else, because forwarding uses longest match before any BGP attribute. Splitting a /23 into two /24s and advertising each to a different ISP gives deterministic inbound load distribution, at the cost of table growth and of having no backup unless the /23 is also advertised on both links.
graph LR
    ENT["Enterprise AS 65001"] -- "primary: local-pref 200" --- A["ISP A"]
    ENT -- "backup: local-pref 100, prepended" --- B["ISP B"]
    A --- NET["Internet"]
    B --- NET

Exam trap

Local preference is not sent to eBGP neighbours, so it cannot influence how another AS sends traffic to you. If the requirement is "control how traffic enters our network", local preference is a wrong answer. Likewise AS-path prepending does nothing for outbound traffic.

1.5.d Route reflectors

The iBGP rule is that a route learned from an iBGP peer is not passed to another iBGP peer. A full mesh needs n(n-1)/2 sessions, which does not scale. Two solutions exist.

Option How it scales Trade-offs
Route reflector (RR) Clients peer only with RRs. RRs reflect client routes to other clients and non-client routes to clients. Single best path is reflected, so clients see less path diversity. Must avoid RR placement that causes suboptimal exit selection. Common choice.
Confederation Splits the AS into sub-ASes with eBGP inside More complex, useful when merging ASes. Rare in new designs

Design rules:

  • Redundancy: use at least two RRs, and peer every client with both. If the two RRs share a cluster ID, each discards routes reflected by the other (it sees its own cluster ID in the cluster list), so each stores less, but a client that loses its session to one RR depends entirely on the other. If the RRs use different cluster IDs, each also learns the routes through the other, which costs memory and updates but survives a client-to-RR session failure better. Choose deliberately and use the same scheme everywhere.
  • Hierarchy: for very large networks use a hierarchy of RRs (clients can themselves be RRs).
  • Placement: put RRs where the IGP topology gives them a good view of the network, ideally following the physical topology. An RR that is far from the clients can choose a best path that is optimal for the RR but not for them, because the RR selects the best path using its own IGP metric to the next hop.
  • Loop prevention: originator ID and cluster list protect against loops. An RR that is not in the forwarding path (a dedicated or out-of-band RR) is common in provider networks, and it still needs the IGP to reach next hops.
  • Add-path / best-external: gives clients more than one path to choose from, speeding convergence (BGP PIC) and enabling load sharing.
  • Peer groups and templates reduce configuration and update generation on RRs.
graph TB
    RR1["RR 1 cluster 1"] --- RR2["RR 2 cluster 1"]
    RR1 --- C1["Client PE1"]
    RR1 --- C2["Client PE2"]
    RR2 --- C1
    RR2 --- C2
    RR1 --- C3["Client PE3"]
    RR2 --- C3

1.5.e Load sharing

BGP picks one best path by default. Multiple paths are used only if they tie through the entire decision process up to the IGP metric.

Scenario Command or technique Condition
Two links to the same ISP maximum-paths N (eBGP multipath) Same neighbour AS, same attributes up to the IGP-metric step
Links to different ISPs maximum-paths N with bgp bestpath as-path multipath-relax AS paths must be the same length but may differ in content
iBGP multipath maximum-paths ibgp N Same attributes, same IGP metric to the next hops
Both eBGP and iBGP maximum-paths eibgp N Used in some PE designs
Unequal cost DMZ link bandwidth (bgp dmzlink-bw) with extended community Traffic is shared in proportion to the configured link bandwidth
Inbound sharing Split the address space into more specifics advertised to different links, or per-prefix prepending Only a partial solution, since the remote AS decides

Operational concerns: per-flow hashing, not per-packet, is used, so a single large flow stays on one link. Keep link capacities aligned to avoid unbalanced load when equal sharing is used on unequal links.

Exam trap

Multipath does not make unequal paths equal. If one path has a different local preference, weight, AS-path length or IGP metric, it does not qualify and the router uses a single best path. A question that says "two ISPs, same customer, load share outbound" needs either the same local preference plus multipath-relax, or a per-prefix split of local preference, not simply maximum-paths.

How much of the Internet table to accept

Approach Table size Best for Risk
Default route only Smallest Single-homed or primary/backup No visibility, cannot pick best exit per destination
Default plus partial (customer routes) Small Dual-homed with a clear primary Some destinations take a suboptimal exit
Full table Hundreds of thousands of routes Multi-homed content or transit networks Requires memory and TCAM capacity, and strict filtering

Design exercise

Scenario. A university with a /20 of provider-independent space and AS 65100 (assume the AS is public) connects to two ISPs, ISP A (1 Gbps) and ISP B (500 Mbps), at two campus edge routers. The university wants all outbound traffic to use ISP A unless it fails, and wants inbound traffic to prefer ISP A as well, with fast failover to B. A recent leak caused the university to appear as a transit path between ISP A and ISP B. The edge routers have limited memory, and the two edge routers are the only iBGP speakers.

Requirements and constraints.

  • Prefer ISP A in both directions, with failover.
  • Prevent transit through the university.
  • Edge routers have limited memory.
  • Only two iBGP speakers.
Model answer

Outbound: accept a default route from each ISP (no full table, because of memory), and set a higher local preference on the ISP A default, which both routers share over iBGP. ISP B's default becomes the backup.

Inbound: advertise the /20 to both ISPs, but prepend the university AS on the ISP B advertisement (and, if ISP B offers it, use its backup community to lower local preference). This is only a request, so also keep the prefix visible through both ISPs for failover.

Transit prevention: apply an outbound prefix-list permitting only the university's /20 (or ^$ AS-path filter) to both ISPs, and an inbound prefix limit.

Session design: the two edge routers form a direct iBGP session, so no route reflector is needed. With only two speakers a full mesh is the simplest design.

Rejected alternatives:

  • Full tables: memory cannot support it and a partial benefit is small when A is primary anyway.
  • Local preference on the inbound side: local preference is internal to the AS and cannot affect how the ISPs send traffic in.
  • MED to both ISPs: MED is only compared among paths from the same neighbouring AS, so it does nothing between two different providers.
  • maximum-paths: would load share between unequal links and defeat the "prefer A" requirement.
  • Route reflector or confederation: unnecessary complexity for two speakers.

Quick check

Which attribute should be used to prefer one exit among several for all routers in your AS?

Local preference, because it is carried within the AS by iBGP and is evaluated early in the decision process. Weight is local to a single router.

Two routers both have routes to a prefix, one via an iBGP RR client and one via eBGP. Which is preferred when everything earlier ties?

The eBGP path, since eBGP beats iBGP before the IGP metric comparison.

What does a route reflector reflect when it learns a prefix from a client?

It reflects it to all other clients and to non-client iBGP peers. A route learned from a non-client is reflected to clients only.

References

  • BGP Configuration Guide, Cisco IOS XE (search "IP Routing BGP Configuration Guide IOS XE" on cisco.com)
  • RFC 4271 (BGP-4), RFC 4456 (route reflection), RFC 4760 (multiprotocol extensions), RFC 7454 (BGP operations and security) at rfc-editor.org
  • Cisco BGP best path selection algorithm (search on cisco.com)
  • Cisco Live On-Demand Library: search "BGP design" and "enterprise internet edge"