1. BGP Route Advertisement Considerations
In BGP, there are two primary methods for route advertisement:
- Advertise directly connected routes on each BGP-speaking device
- Advertise routes learned through IGP from non-BGP devices within the AS (most common scenario)
When BGP advertises routes from the local routing table, it carries the local IGP metric to reach those destinations. This metric is passed to BGP neighbors, enabling devices in other autonomous systems to select the nearest EBGP neighbor for each destination.
When a BGP device learns a route via IBGP with a metric value and needs to share it with other EBGP neighbors, the metric must be reset to zero. This causes suboptimal path selection because the original metric is lost. Therefore, it is recommended that if a BGP device in an AS advertises a particular route, all BGP-speaking devices in that AS should advertise the same route. This allows devices in other ASes to evaluate which of their EBGP neighbors provides the shortest path to the destination.
Summary: If only one device advertises a route, it carries its original metric. Other devices that do not advertise will learn it via BGP and strip the metric to zero, resulting in suboptimal routing decisions.
2. BGP Auto-Summarization Behavior
Modern router platforms have BGP auto-summarization disabled by default.
Auto-summarization rules do not affect:
- Routes shared between BGP neighbors
- Routes created via BGP network commands
Auto-summarization only applies to routes redistributed from IGP into BGP.
In BGP terminology, network statements can be viewed as per-entry redistribution of IGP routes into BGP. Redistributing IGP into BGP is essentially batch redistribution. However, routes created through these two methods have different origin attributes, with network statement routes being preferred over redistributed routes.
With auto-summarization enabled:
- Redistributed routes do not carry subnet masks; they enter with classful masks
- Metrics are not carried; they are set to zero
With auto-summarization disabled:
- Redistributed routes carry proper subnet masks
- Metrics are preserved
The only difference between network statement and redistribution methods (when auto-summarization is off) is the origin attribute. Therefore, its recommended to keep auto-summarization disabled.
If redistribution is performed in an AS, it should be configured on all BGP-speaking devices for consistency.
3. BGP Authentication
BGP authentication provides neighbor identity verification between BGP peers:
[R1-bgp]peer 192.168.1.2 password cipher SecureNet2024
Both neighbors must use identical keys. Passwords are encrypted during transmission.
4. BGP Route Aggregation (Summarization)
4.1 Non-Standard Aggregation Method
This approach leverages BGP's route advertisement characteristics to simplify configuration:
Characteristic: Any route present in the local routing table, regardless of its origin, can be advertised in BGP.
Instead of advertising individual routes one by one, you configure a null interface route for the summary address on the BGP speaker that serves as the update source, then advertise that summary in BGP.
In real-world deployments, since autonomous systems typically have numerous EBGP neighbor relationships, summary routes alone may not provide optimal path selection. Therefore, when sending aggregate routes, partial individual routes should also be advertised for path control.
To include specific明细 routes along with the summary, simply advertise the required明细 routes individually.
4.2 Standard BGP Aggregation Configuration
Procedure:
- First, advertise all individual routes
- Then configure aggregation on the update source router, which automatically generates null interface routes for loop prevention
[Router5-bgp]aggregate 10.10.0.0 22
// Aggregation with all individual routes transmitted
[Router5-bgp]aggregate 10.10.0.0 22 detail-suppressed
// Only the summary is transmitted; all individual routes are suppressed
If you need to transmit specific individual routes along with the aggregate, apply path control policies to selectively allow certain明细 routes.
5. Route Propagation Control Strategies
5.1 Suppress Map
First, allow all routes to propagate, then apply suppression policies. This method is only applicable during aggregation:
[Router5]ip ip-prefix SuppressList permit 10.10.1.0 24
[Router5]route-policy SuppressMap permit node 10
[Router5-route-policy]if-match ip-prefix SuppressList
[Router5-route-policy]quit
[Router5]bgp 64513
[Router5-bgp]aggregate 10.10.0.0 22 suppress-policy SuppressMap
// Routes matching the suppress policy will be blocked from transmission
5.2 Route Map as Distribution List
[Router5]ip ip-prefix RouteCtrl permit 10.10.1.0 24
[Router5]route-policy RouteCtrl deny node 10
[Router5-route-policy]if-match ip-prefix RouteCtrl
[Router5-route-policy]quit
[Router5]route-policy RouteCtrl permit node 20
// Empty table to allow all other routes
[Router5-route-policy]quit
[Router5]bgp 64513
[Router5-bgp]peer 10.10.10.4 route-policy RouteCtrl export
// Apply to neighbor, export direction
5.3 Distribution List
[Router5]ip ip-prefix FilterList deny 10.10.1.0 24
[Router5]ip ip-prefix FilterList permit 0.0.0.0 0 less-equal 32
[Router5]bgp 64513
[Router5-bgp]filter-policy ip-prefix FilterList export
// Applied globally to all interfaces; less precise control
5.4 Prefix List
Prefix lists can be directly used as distribution lists in BGP (commonly used):
[Router5]ip ip-prefix PrefixCtrl deny 10.10.1.0 24
[Router5]ip ip-prefix PrefixCtrl permit 0.0.0.0 0 less-equal 32
[Router5]bgp 64513
[Router5-bgp]peer 10.10.10.4 ip-prefix PrefixCtrl export
6. Conditional IBGP Split-Horizon Relaxation
6.1 Understanding the Problem
IBGP split-horizon rule: AS-BY-AS model, meaning BGP attributes remain unchanged within an AS.
In a typical AS with BGP speakers, every device usually has EBGP neighbors connecting to other autonomous systems. Due to IBGP split-horizon rules, when external routes enter the local AS, they must be shared with all IBGP peers. This requires establishing IBGP neighbor relationships between every pair of BGP devices, resulting in exponential growth of required neighbor sessions.
Conditional split-horizon relaxation aims to eliminate IBGP split-horizon constraints while maintaining loop prevention—preserving the AS-BY-AS property.
6.2 Route Reflector
Roles:
- RR (Route Reflector)
- Client
- Non-client
Only the RR decides whether to reflect routes. Both clients and non-clients must be IBGP neighbors of the RR. The RR and its clients/non-clients form a cluster. A cluster must contain at least one RR and one client, though multiple clients and non-clients are supported.
Reflection Rules:
Non-best routes are not propagated and cannot be reflected.
- Routes learned from EBGP neighbors can be sent to clients, non-clients, and other EBGP neighbors
- Routes learned from clients can be sent to other clients, non-clients, and EBGP neighbors
- Routes learned from non-clients can be sent to clients and EBGP neighbors, but NOT to other non-clients
[Router3-bgp]peer 2.2.2.2 reflect-client
// Neighbor 2.2.2.2 becomes a client, and Router3 becomes the RR
6.3 Confederation
A large AS is logically divided into multiple smaller autonomous systems (sub-ASes). From an external perspective, the confederation still appears as a single AS.
Sub-AS neighbors are internal EBGP neighbors within the confederation. They can exchange routes like regular EBGP neighbors, but attributes are not modified by default.
Internal EBGP relationships within a confederation have attributes following IBGP rules and propagation following EBGP rules.
Configuration Requirements:
- All operations use sub-AS numbers
- All devices in the confederation must declare the confederation AS number
- BGP devices in different sub-ASes must inform peers about their sub-AS number
[Router3]bgp 64512
[Router3-bgp]router-id 3.3.3.3
[Router3-bgp]confederation id 64520
// Declare the confederation AS number
[Router3-bgp]confederation peer-as 64513
// Advertise directly connected sub-AS numbers (omit if no direct connection to other sub-AS)
[Router3-bgp]peer 2.2.2.2 as-number 64512
[Router3-bgp]peer 2.2.2.2 connect-interface LoopBack 0
[Router3-bgp]peer 4.4.4.4 as-number 64513
[Router3-bgp]peer 4.4.4.4 connect-interface LoopBack 0
[Router3-bgp]peer 4.4.4.4 ebgp-max-hop 2
Note: In real deployments, route reflectors and confederation technologies are often used together within the same network topology.
6.4 Next-Hop-Local Command
[Router2]bgp 64512
[Router2-bgp]peer 172.16.1.3 next-hop-local
This command appears to modify the next-hop address to Router2's IP when sending routes to neighbor 172.16.1.3. However, in practice, it only modifies the next-hop for routes learned from local EBGP neighbors when being sent to IBGP neighbors.
Routes learned from other IBGP neighbors are not modified when sent to 172.16.1.3 (an IBGP neighbor).
Purpose: When exchanging routes between IBGP neighbors within an AS, modifying attributes arbitrarily can easily cause routing loops. This command maintains the AS-BY-AS characteristic.
7. BGP Next-Hop Issues in MA Networks
Consider a scenario where Router1, Router2, and Router3 are on the same multi-access network segment but belong to different autonomous systems. Router2 and Router3 establish neighbor relationships using physical interfaces.
When Router1 receives a route to Router4 from Router2, the next-hop automatically displays as Router3 if using physical interfaces (indicating the best path). However, when using loopback interfaces for peering, the next-hop displays as Router2 normally.
Requirements for this behavior:
- Router1, Router2, and Router3 must establish neighbor relationships using physical interfaces on the MA segment
- ICMP redirect must be enabled (default): When a router forwards traffic and discovers that the ingress and egress interfaces are the same, it informs the previous hop about a better next-hop address
8. BGP Routing Table Verification Commands
To view routes received from a specific BGP neighbor:
[Router1]display bgp routing-table peer 10.1.1.2 received-routes
To view routes advertised to a specific BGP neighbor:
[Router1]display bgp routing-table peer 10.1.1.2 advertised-routes