Home Blog About Me Resume

BGP Under the Hood (CCNP ENCOR Notes)

BGP isn’t just a routing protocol it’s a policy-based system. It doesn’t automatically choose the “best” path; it chooses the path that best matches the rules you define. Because of that, small misunderstandings in BGP behavior can lead to unexpected routing decisions or broken connectivity.

This section covers the core mechanics of BGP, including eBGP vs iBGP behavior, the iBGP split-horizon rule, next-hop handling, and the BGP state process. It then breaks down how BGP selects a best path using attributes like weight, local preference, AS-path, MED, and IGP cost. Finally, it introduces route-maps, which are the primary tool for applying BGP policy by matching routes and setting attributes using prefix-lists, AS-path lists, and communities.

Core BGP Mechanics

eBGP vs iBGP behavior

There are many diffrences between iBGP and eBGP. Aswell as diffrent use cases that it covers.
eBGP is typically used when connecting to diffrent Automous Systems.

The default TTL of eBGP is 1 requiring a direct connection in order for a peering realonship to form by default.

Modifying the next hop to be themselves.

eBGPS loop prevention mechnicism is checking th AS_Path path attirbute to see if its own ASN is a part of it and if it is then it knows it went through the router already.

eBGPs administrative distance is 20.

iBGP operates within the same AS and requires a full mesh, confederations, or route reflector to avoid loops, perserves the next hop, and relies on the underlying IGP Routing protocol to maintain reachability.

iBGP routing loop prevention mechanism is split horizon (iBGP routers do not re-advertise routes learned from one iBGP peer to another)

iBGP administrative distance is 200.

iBGP split-horizon rule (why full mesh exists)

A full mesh exists so every iBGP router can exchange routes directly without using route reflectors or confederations. This is needed becuase of the iBGP split-horizon rule where routes learned from one iBGP neighbor are not advertised to another iBGP neighbor. Without a full mesh (confederations or RRs), routes would stop propagating across the AS.

The split horizon rule is specifically because iBGP doesn’t modify the AS_PATH, so it can’t rely on AS_PATH loop detection like eBGP does.

Next-Hop behavior (esp. eBGP → iBGP)

When routes are learned via eBGP and advertised to iBGP peers, the next-hop attribute is not changed by default. This can cause internal routers to see an unreachable next hop, preventing the route from being installed. The next-hop-self command is commonly used to fix this.

BGP states (Idle → Established)

BGP uses a state machine to bring up and maintain neighbor sessions. Routers move through these states while forming a TCP connection on port 179 and exchanging routing information.

  • Idle – BGP is waiting to start. No TCP connection exists.

  • Connect – BGP is trying to establish a TCP session.

  • Active – TCP failed; BGP is retrying.

  • OpenSent – TCP is up, OPEN message sent.

  • OpenConfirm – OPEN received, waiting for keepalives.

  • Established – Session is up; routes are exchanged.

If a neighbor is stuck bouncing between Active and Connect, it usually points to reachability, TCP, or ACL issues rather than a BGP configuration problem.

BGP path attribute caterogies

BGP path attributes are used to describe routing information and influence best path selection. Attributes are grouped into categories based on how they are recognized and propagated.

Well-Known Mandatory

  • Must be supported by all BGP implementations
  • Must be included in every BGP update
  • Examples:
    • AS_PATH
    • NEXT_HOP
    • ORIGIN

Well-Known Discretionary

  • Supported by all BGP implementations
  • May or may not be included in an update
  • Examples:
    • LOCAL_PREF
    • ATOMIC_AGGREGATE

Optional Transitive

  • May not be recognized by all BGP implementations
  • If unknown, the attribute is passed along
  • Example:
    • COMMUNITY

Optional Non-Transitive

  • May not be recognized by all BGP implementations
  • If unknown, the attribute is dropped
  • Examples:
    • MED
    • AGGREGATOR

Best Path Selection

When multiple BGP paths exist for the same prefix, BGP chooses the best path based on attributes, not link speed or hop count.

BGP compares paths in this order (simplified):

  • Highest Weight (Cisco-only, local to the router)
  • Highest Local Preference
  • Locally originated routes
  • Shortest AS_PATH
  • Lowest Origin type (IGP < EGP < Incomplete)
  • Lowest MED
  • eBGP over iBGP
  • Lowest IGP cost to next hop
  • Oldest path
  • Lowest BGP Router ID
  • Lowest Neighbor IP address

BGP stops at the first difference and selects one best path.

Key takeaways

  • Weight beats everything (but only on Cisco)
  • Local Preference controls outbound traffic
  • AS_PATH influences inbound traffic
  • eBGP paths are preferred over iBGP paths
  • The last three steps are pure tie-breakers
  • BGP is policy-based, not performance-based

Weight (Cisco-only)

Weight is a Cisco-specific BGP attribute used to influence best path selection on the local router only. It is evaluated before all other BGP attributes and is not advertised to any BGP neighbors.

  • Highest weight is preferred
  • Local to the router only
  • Not shared with neighbors
  • Default weight is 0
  • Locally originated routes have a default weight of 32768

Weight is typically used to influence outbound traffic on a single router without impacting routing decisions elsewhere in the AS.

Local Preference

Local Preference is a well-known discretionary BGP attribute used to influence outbound traffic within an autonomous system. It is shared with all iBGP peers and is evaluated after Weight in the best path selection process.

  • Highest local preference is preferred
  • Propagated to all iBGP neighbors
  • Not advertised to eBGP neighbors
  • Default value is 100
  • Used to control which exit point an AS prefers

Local Preference is commonly set on edge routers to steer traffic toward a preferred upstream provider across the entire AS.

AS-Path

AS_PATH is a well-known mandatory BGP attribute that lists the autonomous systems a route has traversed. It is primarily used for loop prevention and influences best path selection.

  • Shorter AS_PATH is preferred
  • Automatically updated when routes are advertised between eBGP neighbors
  • Used by BGP to detect routing loops
  • Commonly manipulated to influence inbound traffic

AS_PATH is one of the main tools ISPs use to control how traffic enters their network.

Origin

Origin is a well-known mandatory BGP attribute that indicates how a route was introduced into BGP. It is used during best path selection after AS_PATH length.

BGP prefers origin values in this order:

  • IGP – Routes originated within the AS (best)
  • EGP – Learned via the legacy EGP protocol
  • Incomplete – Redistributed or learned by other means (worst)

Origin is rarely manually changed but can affect path selection when higher-priority attributes are equal.

MED (Multi-Exit Discriminator)

MED is an optional non-transitive BGP attribute used to influence inbound traffic from neighboring autonomous systems. It suggests the preferred entry point into an AS but is not guaranteed to be honored.

  • Lower MED is preferred
  • Advertised to eBGP neighbors only
  • Default value is 0
  • Can be overridden by BGP policies

MED is commonly used to influence traffic when multiple connections exist between two ASes.

IGP metric to next hop

The IGP metric to the next hop is the final tiebreaker in BGP best path selection after all BGP attributes have been considered. It represents the internal routing cost to reach the next-hop IP address.

  • Lowest IGP metric is preferred
  • Calculated using the internal IGP (OSPF, EIGRP, etc.) of the AS
  • Only evaluated after all other BGP attributes (Weight, Local Preference, AS_PATH, Origin, MED, eBGP/iBGP preference)

This ensures that, when multiple BGP paths are otherwise equal, the router chooses the path with the most efficient route to the next hop within the AS.

Route-Maps

Route-maps are flexible BGP tools used to filter, modify, or set attributes on routes. They work like “if-then” rules to control routing behavior.

  • Can match on various criteria (prefix lists, AS paths, communities, etc.)
  • Can set attributes (e.g., Weight, Local Preference, MED, next hop)
  • Applied to inbound or outbound BGP updates
  • Support multiple sequential statements with permit or deny actions
  • Evaluated in order; first match wins

Route-maps are commonly used for policy-based routing, influencing how traffic enters or exits the AS.

Example

1. Set Local Preference for inbound routes

ip prefix-list CUSTOMER_ROUTES seq 5 permit 10.1.0.0/16

route-map SET_LOCAL_PREF permit 10
 match ip address prefix-list CUSTOMER_ROUTES
 set local-preference 200

router bgp 65001
 neighbor 192.0.2.2 route-map SET_LOCAL_PREF in

Matching prefixes & Setting attributes

Route-maps can match specific prefixes to selectively apply policies. This is done with prefix lists, which define which networks are included or excluded.

Example Prefix-List

ip prefix-list CUSTOMER_ROUTES seq 5 permit 10.1.0.0/16
ip prefix-list CUSTOMER_ROUTES seq 10 permit 10.2.0.0/16

Using a Route-Map to Match Prefixes

match ip address prefix-list CUSTOMER_ROUTES
 set local-preference 200

router bgp 65001
 neighbor 192.0.2.2 route-map SET_LOCAL_PREF in

Combining with prefix-lists / AS-path lists / communities

Combining with Prefix-Lists, AS-Path Lists, and Communities

Route-maps can match multiple criteria to apply policies selectively:

  • Prefix-Lists – match specific networks
  • AS-Path Lists – match routes based on AS path patterns
  • Communities – match or tag routes for policy purposes

Example: Match Prefix-List and AS-Path

ip as-path access-list BLOCK_AS _65002$

route-map POLICY permit 10
 match ip address prefix-list CUSTOMER_ROUTES
 match as-path BLOCK_AS
 set local-preference 200

router bgp 65001
 neighbor 192.0.2.2 route-map POLICY in

AS-PATH Access Lists (Regex)

AS-PATH access lists use regular expressions to match routes based on the autonomous systems they traverse. They allow precise control over which routes are permitted or denied in BGP policies.

Common Regex Symbols

  • ^ – matches the start of the AS path
  • $ – matches the end of the AS path
  • _ – matches a boundary between AS numbers
  • .* – matches any sequence of AS numbers
  • ^$ – matches an empty AS path (locally originated)

Examples

  • Match routes originating from AS 65001:

ip as-path access-list ORIGIN_65001 ^65001$
Match routes passing through AS 65002 anywhere:

ip as-path access-list THROUGH_65002 _65002_
Match routes starting with AS 65001:

ip as-path access-list START_65001 ^65001
Match routes ending with AS 65003:

ip as-path access-list END_65003 65003$
Match routes that include AS 65001 or AS 65002:

ip as-path access-list MULTI _65001_|_65002_
Note: The _ ensures the regex matches whole AS numbers, not parts of numbers.

Scaling & real enterprise design

Route Reflectors

Route Reflectors

Route Reflectors (RR) are used in iBGP to reduce the need for a full mesh of internal BGP peers. They allow routes to be shared between iBGP routers without every router peering with every other router.

  • Route Reflector (RR) – the router that reflects routes to clients
  • Clients – iBGP peers that receive reflected routes from the RR
  • Non-clients – iBGP peers that receive routes via normal iBGP rules

Key Points

  • Eliminates full mesh requirement in large iBGP networks
  • RR sets the ORIGINATOR_ID to prevent routing loops
  • Cluster ID identifies a set of RRs in the same cluster to avoid loops
  • iBGP split-horizon rule still applies between non-client peers

Example Configuration

router bgp 65001
 bgp cluster-id 1.1.1.1
 neighbor 192.0.2.2 route-reflector-client
 neighbor 192.0.2.3 route-reflector-client

Confederations

Confederations

BGP Confederations divide a large autonomous system (AS) into smaller, sub-ASes to reduce the number of iBGP peers and simplify management while appearing as a single AS to external neighbors.

  • Each sub-AS uses iBGP internally
  • Sub-ASes communicate with each other using eBGP rules
  • The external AS sees the entire confederation as one AS
  • Helps reduce full-mesh iBGP requirements in large networks

Key Points

  • Reduces the number of iBGP sessions needed
  • Preserves loop prevention using standard BGP mechanisms
  • Sub-ASes can use route reflectors internally
  • MEDs are preserved when routes cross sub-AS boundaries

Example Configuration

router bgp 65001
 bgp confederation identifier 65001
 bgp confederation peers 65002 65003

router bgp 65002
 neighbor 192.0.2.2 remote-as 65001

router bgp 65003
 neighbor 192.0.2.3 remote-as 65001

65001 is the confederation ID

65002 and 65003 are sub-ASes

External neighbors see all as AS 65001

Why iBGP full-mesh is bad

A full-mesh iBGP topology requires every iBGP router to peer with every other iBGP router. While it ensures route propagation, it does not scale well in large networks.

Problems with Full-Mesh iBGP

  • Scalability – Number of sessions grows quadratically: n*(n-1)/2
  • Complexity – Hard to configure and maintain as routers increase
  • CPU/Memory Load – Each router maintains many BGP sessions
  • Error-prone – One misconfiguration can disrupt multiple peers

Solution

  • Use Route Reflectors or Confederations to reduce the number of iBGP sessions
  • These solutions maintain proper route propagation without requiring a full mesh

RR rules (client vs non-client)

Route Reflectors (RR) control how iBGP routes are propagated between clients and non-clients. Understanding these rules prevents routing loops and ensures proper route distribution.

Rules

  1. Routes from a client

    • Sent to all other clients of the RR
    • Sent to all non-client iBGP peers

  2. Routes from a non-client

    • Sent only to client peers
    • Not sent to other non-clients

  3. Routes between clients

    • Do not get sent directly to other clients except through the RR

Key Notes

  • RR sets ORIGINATOR_ID to track the original router and avoid loops
  • Cluster ID ensures routes reflected through multiple RRs do not loop
  • Helps reduce the need for a full iBGP mesh while maintaining loop prevention

Cluster-ID

The Cluster ID is used in Route Reflector (RR) setups to prevent routing loops when multiple RRs exist in the same cluster.

  • Each RR in a cluster is assigned the same Cluster ID
  • When an RR reflects a route, it adds its Cluster ID to the CLUSTER_LIST attribute
  • If another RR sees its own Cluster ID in CLUSTER_LIST, it does not reflect the route again
  • Ensures safe route reflection between multiple RRs without looping

Example Configuration

router bgp 65001
 bgp cluster-id 1.1.1.1
 neighbor 192.0.2.2 route-reflector-client
 neighbor 192.0.2.3 route-reflector-client

1.1.1.1 is the Cluster ID shared by all RRs in the cluster

Prevents the same route from being reflected back multiple times

Loop prevention basics

BGP has built-in mechanisms to prevent routing loops in both eBGP and iBGP.

eBGP Loop Prevention

  • Uses the AS_PATH attribute
  • If a router sees its own AS in the AS_PATH, it rejects the route
  • Ensures routes do not circulate between ASes

iBGP Loop Prevention

  • Uses the split-horizon rule
  • iBGP-learned routes are not advertised to other iBGP peers by default
  • Requires full mesh, route reflectors, or confederations to propagate routes safely

Additional RR/Confederation Mechanisms

  • ORIGINATOR_ID (RR) – tracks the original router to prevent loops
  • CLUSTER_LIST (RR) – prevents the same route from bouncing between multiple RRs
  • Confederation sub-AS – treated as eBGP between sub-ASes, preserving loop prevention

Peer-Groups / Templates and why they exist

Peer-Groups / Templates

BGP Peer-Groups (Cisco) or neighbor templates (other vendors) are used to simplify configuration and improve performance when multiple neighbors share the same policies.

Why They Exist

  • Reduce configuration repetition – apply the same settings to many neighbors at once
  • Lower CPU load – BGP processes updates more efficiently
  • Simplify management – easier to update multiple neighbors by changing the group/template

Example: Peer-Group

router bgp 65001
 neighbor EBGP_PEERS peer-group
 neighbor EBGP_PEERS remote-as 65002
 neighbor EBGP_PEERS description "All eBGP uplinks"
 neighbor 192.0.2.2 peer-group EBGP_PEERS
 neighbor 192.0.2.3 peer-group EBGP_PEERS

Changes to the peer-group (e.g., timers, route-maps) automatically apply to all members

Useful for large networks with many BGP neighbors

Intra-AS BGP

Intra-AS BGP (iBGP) is used to distribute routes learned from eBGP within the same autonomous system.

Key Points

  • iBGP peers are within the same AS
  • AS_PATH is not modified
  • Next-hop is not changed by default (may require next-hop-self)
  • Routes learned via iBGP cannot be advertised to other iBGP peers directly (split-horizon rule)
  • Requires:
    • Full mesh, or
    • Route reflectors, or
    • Confederations for scalability

Use Case

  • Ensures that all routers inside an AS know external routes without looping

Edge routers vs core routers

Edge Routers vs Core Routers

In BGP networks, routers are often classified based on their role in the AS:

Edge Routers (Border Routers)

  • Connect the AS to external networks / ISPs
  • Run eBGP sessions with neighbors outside the AS
  • Typically handle:
    • Route filtering
    • Local Preference / MED policies
    • Prefix advertisement

Core Routers

  • Operate inside the AS
  • Mainly handle iBGP route propagation
  • Focus on:
    • Efficient internal distribution
    • Route reflection (if using RRs)
    • No direct external connections

Summary: Edge routers manage traffic entering and leaving the AS, while core routers handle internal route distribution.

Where iBGP lives in an enterprise

iBGP is typically deployed inside the AS to distribute routes learned from eBGP peers across the network.

Typical Placement

  • Edge Routers – run eBGP with ISPs and iBGP with core routers
  • Core Routers / Distribution Layer – run iBGP with other internal routers, often using:
    • Route Reflectors to reduce full-mesh requirements
    • Confederations in very large networks

Key Points

  • Ensures all internal routers know external routes
  • iBGP routes are used for internal forwarding decisions
  • Full mesh is avoided in large networks using RRs or confederations

Filtering, summarization & safety

Prefix Filtering

Prefix filtering controls which routes are accepted or advertised in BGP using prefix lists, route-maps, or distribute-lists.

Key Points

  • Protects the AS from unwanted or incorrect routes
  • Can be applied inbound (routes received) or outbound (routes advertised)
  • Often combined with route-maps to modify attributes for specific prefixes

Why filtering inbound is safer

Filtering inbound BGP routes is generally safer because it prevents unwanted or harmful routes from entering your AS before they affect your network.

Key Points

  • Stops bogus, hijacked, or misconfigured prefixes from propagating internally
  • Reduces the risk of routing loops or blackholing traffic
  • Avoids modifying outbound routes unnecessarily
  • Easier to manage and audit compared to outbound filtering

Best practice: filter as close to the source as possible, ideally on eBGP neighbors at the edge.

Preventing leaks

Preventing Route Leaks

Route leaks occur when routes from one AS are advertised to another AS incorrectly, potentially causing traffic to take unintended paths.

Best Practices to Prevent Leaks

  • Inbound filtering – only accept routes from eBGP neighbors that are expected
  • Outbound filtering – only advertise prefixes you are authorized to share
  • Use prefix-lists, route-maps, and AS-path filters to control route advertisement
  • Implement BGP communities to tag and control route propagation
  • Monitor and log BGP updates to detect unusual routes quickly

Preventing leaks protects both your network and the broader Internet from misrouting or blackholing traffic.

Summarization

Route summarization reduces the number of routes advertised in BGP, improving scalability and stability.

Key Points

  • Combines multiple specific prefixes into a single summary route
  • Can be applied inbound or outbound
  • Reduces routing table size and BGP update traffic
  • Often used on edge routers to advertise fewer routes to neighbors

Example: Outbound Summarization

router bgp 65001
 aggregate-address 10.0.0.0 255.0.0.0 summary-only

summary-only advertises only the aggregate, not the more specific prefixes

Helps simplify routing for upstream ISPs or other ASes

aggregate-address

The aggregate-address command in BGP is used to summarize multiple prefixes into a single route for advertisement.

Key Points

  • Reduces BGP table size and update traffic
  • Can advertise only the summary (summary-only) or include specific subnets
  • Helps simplify routing policies for neighbors
  • Commonly applied on edge routers

Example: Outbound Aggregation

router bgp 65001
 aggregate-address 10.0.0.0 255.0.0.0 summary-only

Combines all 10.x.x.x prefixes into one advertised route

Only the summary route is sent to neighbors, keeping the routing table smaller

Suppress-map / Advertise-map

BGP suppress-map and advertise-map allow conditional route advertisement based on prefix lists or route-maps.

Suppress-Map

  • Prevents specific prefixes from being advertised
  • Often used to hide certain subnets while still keeping them in the local table
  • Advertises only the prefixes matching a route-map
  • Useful for controlling which routes go to specific neighbors

Example: Suppress Specific Routes

ip prefix-list HIDE_ROUTES seq 5 permit 10.1.0.0/16

router bgp 65001
 neighbor 192.0.2.2 suppress-map HIDE_ROUTES

Example: Advertise Only Certain Routes

ip prefix-list ADVERTISE_ONLY seq 5 permit 10.2.0.0/16

router bgp 65001
 neighbor 192.0.2.2 advertise-map ADVERTISE_ONLY

Both features provide fine-grained control over which prefixes are shared with BGP neighbors

Why auto-summary is trash

The auto-summary feature in BGP (and older EIGRP) automatically summarizes routes at classful boundaries. In modern networks, it’s generally avoided because it can cause routing issues.

Problems with Auto-Summary

  • Summarizes routes incorrectly across discontiguous subnets
  • Can create routing loops or blackholes
  • Reduces granularity, making traffic engineering harder
  • Often conflicts with CIDR-based policies used in enterprise networks

Best Practice

  • Disable auto-summary in BGP and rely on manual summarization using aggregate-address

Communities

BGP communities are optional transitive attributes used to tag routes for policy control. They help influence route handling across ASes without modifying the route itself.

Key Points

  • Standardized or extended numeric values (e.g., 65001:100)
  • Can be used for:
    • Route filtering
    • Traffic engineering
    • Controlling route redistribution
  • Communities are transitive – they can be passed along multiple ASes

Example: Setting a Community

route-map TAG_ROUTES permit 10
 match ip address prefix-list CUSTOMER_ROUTES
 set community 65001:100

router bgp 65001
 neighbor 192.0.2.2 route-map TAG_ROUTES out

Downstream routers can match on the community to apply policies

Provides a flexible way to manage routing without changing AS paths or prefixes

Tagging routes

BGP allows routes to be tagged with attributes for policy control, tracking, or redistribution. Common methods include communities, route-maps, and the BGP tag attribute.

Key Points

  • Tags help identify the origin or purpose of a route
  • Useful for filtering, redistribution, or route selection
  • Works with iBGP and eBGP routes
  • Often combined with route-maps for conditional policies

Example: Tagging with a Route-Map

route-map TAG_ROUTES permit 10
 match ip address prefix-list CUSTOMER_ROUTES
 set tag 100

router bgp 65001
 neighbor 192.0.2.2 route-map TAG_ROUTES out

Routes matching the prefix-list are assigned tag 100

Downstream routers or redistribution processes can match on the tag to apply policies

Filtering based on meaning, not prefixes

Filtering Based on Meaning, Not Prefixes

Instead of filtering purely by IP prefixes, BGP allows policies based on attributes or semantics of routes, making filtering more flexible and policy-driven.

Key Criteria

  • AS-Path – block or allow routes from specific ASes
  • Communities – tag routes for selective handling
  • Route Tags – track and filter routes based on origin or purpose
  • Next-Hop or MED – control which routes are preferred

Example: Block Routes from a Specific AS

ip as-path access-list BLOCK_AS _65002$
route-map FILTER_AS permit 10
 match as-path BLOCK_AS
 set local-preference 50

router bgp 65001
 neighbor 192.0.2.2 route-map FILTER_AS in

Focuses on route meaning, not just address space

Allows precise traffic engineering and policy enforcement

Setting policy with communities

BGP communities can be used to control routing policies without modifying prefixes or AS paths. They act as tags that downstream routers can interpret to take specific actions.

Key Uses

  • Influence route preference (Local Preference, MED)
  • Control redistribution to other neighbors
  • Enable selective advertisement or filtering
  • Support traffic engineering across multiple ASes

Example: Tag Routes with a Community

route-map SET_COMMUNITY permit 10
 match ip address prefix-list CUSTOMER_ROUTES
 set community 65001:100

router bgp 65001
 neighbor 192.0.2.2 route-map SET_COMMUNITY out

Example: Match a Community to Apply Policy

ip community-list 1 permit 65001:100

route-map POLICY_BY_COMMUNITY permit 10
match community 1
set local-preference 200

router bgp 65001
neighbor 192.0.2.3 route-map POLICY_BY_COMMUNITY in

Allows fine-grained routing control without touching the network prefixes

Communities can be transitive or non-transitive, depending on the policy needs

Security

BGP authentication

BGP supports authentication to secure sessions between peers and prevent unauthorized route injection.

Key Points

  • Uses MD5 passwords for session authentication
  • Applies to both eBGP and iBGP neighbors
  • Prevents spoofed BGP messages and session hijacking
  • Each neighbor must have the same password configured

Example: MD5 Authentication

router bgp 65001
 neighbor 192.0.2.2 remote-as 65002
 neighbor 192.0.2.2 password MyBGPpassword

If passwords mismatch, the BGP session will not establish

Essential for securing external BGP connections and sensitive internal peering

TTL security

BGP TTL Security

BGP TTL security (TTL Security Check) helps protect eBGP sessions from attacks by verifying the hop count between peers.

Key Points

  • Ensures BGP packets are coming from directly connected or expected neighbors
  • Helps prevent spoofed BGP sessions from remote attackers
  • Commonly used on eBGP links over untrusted networks

Example: Enable TTL Security

router bgp 65001
 neighbor 192.0.2.2 remote-as 65002
 neighbor 192.0.2.2 ttl-security hops 2

ttl-security hops 2 allows packets within 2 hops of the neighbor

Packets exceeding this TTL are discarded, securing the session

Maximum-prefix

The maximum-prefix feature in BGP limits the number of routes a neighbor can advertise. This helps protect against route table overload or accidental route leaks.

Key Points

  • Prevents a neighbor from sending too many prefixes
  • Can trigger:
    • Warning only
    • Session reset when the limit is exceeded
  • Useful for both eBGP and iBGP sessions

Example: Limit Prefixes

router bgp 65001
 neighbor 192.0.2.2 remote-as 65002
 neighbor 192.0.2.2 maximum-prefix 100 warning-only

Limits neighbor to 100 prefixes

Only generates a warning; the session stays up (warning-only)

Without warning-only, the BGP session resets if the limit is exceeded

Hijacking & leaking concepts

Understanding BGP hijacks and leaks is critical for network security and route stability.

BGP Hijacking

  • Occurs when an AS advertises prefixes it does not own
  • Can cause traffic to be misrouted or intercepted
  • Often the result of misconfiguration or malicious intent
  • Example: AS 65002 announces 10.1.0.0/16, which actually belongs to AS 65001

BGP Leaking

  • Occurs when routes from one AS are improperly advertised to another AS
  • Can create routing loops, traffic blackholes, or policy violations
  • Often caused by misconfigured iBGP-to-eBGP propagation or confederation rules

Prevention Strategies

  • Use prefix filtering on inbound and outbound routes
  • Implement AS-PATH filtering and route-maps
  • Tag routes with communities for policy-based control
  • Monitor BGP updates for unexpected prefixes

RPKI (Resource Public Key Infrastructure)

RPKI is a security framework that helps prevent BGP route hijacking by allowing network operators to cryptographically verify that an AS is authorized to announce a prefix.

Key Points

  • Associates IP prefixes with valid AS numbers using digital certificates
  • Routers can validate BGP announcements before accepting them
  • Helps prevent unauthorized or hijacked route announcements
  • Does not replace normal BGP routing, but enhances trust in received routes
  • Increasingly adopted by ISPs and large networks for Internet security