EBGP
EBGP peerings are the core component of the BGP protocol on the Internet. EBGP is the exchange of network prefixes between autonomous systems. The following behaviors are different on EBGP sessions when compared to IBGP sessions:
Time to Live (TTL) on BGP packets is set to one. BGP packets drop in transit if a multihop BGP session is attempted (TTL on IBGP packets is set to 255, which allows for multihop sessions).
The advertising router modifies the BGP next-hop to the IP address sourcing the BGP connection.
The advertising router prepends its ASN to the existing AS_PATH.
The receiving router verifies that the AS_PATH does not contain an ASN that matches the local routers. BGP discards the NLRI if it fails the AS_PATH loop prevention check.
The configuration for EBGP and IBGP sessions are fundamentally the same on IOS, IOS XR, and NX-OS devices, except that the ASN in the remote-as statement is different from the ASN defined in the BGP process.
EBGP learned paths always have at least one ASN in the AS_PATH. If multiple ASs are listed in the AS_PATH, the most recent AS is always prepended (the furthest to the left). The BGP attributes for all paths to a specific network prefix can be shown with the command show bgp ipv4 unicast network on IOS, IOS XR, and NX-OS devices.
Example 1-8 displays the BGP path attributes for the remote prefix (192.168.3.3/32).
Example 1-8 BGP Prefix Attributes for Remote Prefix
R1-IOS# show bgp ipv4 unicast 192.168.3.3
BGP routing table entry for 192.168.3.3/32, version 11
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65200 65300
10.1.12.2 from 10.1.12.2 (192.168.2.2)
Origin IGP, localpref 100, valid, external, best
Table 1-5 explains the output provided in Example 1-8 and its correlation to BGP. Some of the BGP path attributes may change depending on the BGP features used.
Table 1-5 BGP Prefix Attributes
Output |
Description |
Paths: (1 available, best #1) |
Provides a count of BGP paths in the BGP Loc-RIB and identifies the path selected as the BGP best path. All the paths and BGP attributes are listed after this. |
Not advertised to any peer |
Identifies whether the prefix was advertised to a BGP peer or not. BGP neighbors are consolidated into BGP update-groups. Explicit neighbors can be seen with the command show bgp ipv4 unicast update-group on IOS or IOS XR nodes. |
65200 65300 |
This is the AS_PATH for the NLRI as it was received. |
10.1.12.2 from 10.1.12.2 (192.168.2.2) |
The first entry lists the IP address of the EBGP edge peer. The from field lists the IP address of the IBGP router that received this route from the EBGP edge peer. (In this case, the route was learned from an EBGP edge peer, so the address will be the EBGP edge peer.) Expect this field to change when an external route is learned from an IBGP peer. The number in parentheses is the BGP Identifier (RID) for that node. |
Origin IGP |
The Origin is the BGP well-known mandatory attribute that states the mechanism for advertising this route. In this instance, it is an Internal route |
metric 0 |
Displays the optional nontransitive BGP attribute Multiple-Exit Discriminator (MED), also known as BGP metric. |
localpref 100 |
Displays the well-known discretionary BGP attribute Local Preference. |
valid |
Displays the validity of this path. |
External |
Displays how the route was learned. It will be internal, external, or local. |
EBGP and IBGP Topologies
Combining EBGP sessions with IBGP sessions can cause confusion in terminology and concepts. Figure 1-6 provides a reference topology for clarification of concepts. R1 and R2 form an EBGP session, R3 and R4 form an EBGP session as well, and R2 and R3 form an IBGP session. R2 and R3 are IBGP peers and follow the rules of IBGP advertisement, even if the routes are learned from an EBGP peer.
){kind=link}
As an EBGP prefix is advertised to an IBGP neighbor, issues may arise with the NLRI passing the validity check and the next-hop reachability check preventing advertisements to other BGP peers. The most common issue involves the failure of the next-hop accessibility. IBGP peers do not modify the next-hop address if the NLRI has a next-hop address other than 0.0.0.0. The next-hop address must be resolvable in the global RIB for it to be valid and advertised to other BGP peers.
To demonstrate this concept, only R1 and R4 have advertised their loopback interfaces into BGP, 192.168.1.1/32, and 192.168.4.4/32. Figure 1-7, displays the BGP table for all four routers. Notice that the BGP best path symbol (>) is missing for the 192.168.4.4/32 prefix on R2, and for the 192.168.1.1/32 on R3.
)
Figure 1-7 EBGP and IBGP Topology
R1’s BGP table is missing the 192.168.4.4/32 prefix because the prefix did not pass R2’s next-hop accessibility check preventing the execution of the BGP best path algorithm. R4 advertised the prefix to R3 with the next-hop address of 10.1.34.4, and R3 advertised the prefix to R2 with a next-hop address of 10.1.34.4. R2 does not have a route for the 10.1.34.4 IP address and deems the next-hop inaccessible. The same logic applies to R1’s 192.168.1.1/32 prefix when advertised toward R4.
Example 1-9 shows the BGP attributes on R3 for the 192.168.1.1/32 prefix. Notice that the prefix is not advertised to any peer because the next-hop is inaccessible.
Example 1-9 BGP Path Attributes for 192.168.1.1/32
R3-IOS# show bgp ipv4 unicast 192.168.1.1
BGP routing table entry for 192.168.1.1/32, version 2
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
65100
10.1.12.1 (inaccessible) from 10.1.23.2 (192.168.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal
To correct the issue, the peering links, 10.1.12.0/24 and 10.1.34.0/24, need to be in both R2’s and R3’s routing table via either technique:
IGP advertisement. Remember to use the passive interface to prevent an accidental adjacency from forming. Most IGPs do not provide the filtering capability like BGP.
Advertising the networks into BGP.
Both techniques allow the prefixes to pass the next-hop accessibility test.
Figure 1-8 displays the topology with both transit links advertised into BGP. Notice that this time all four prefixes are valid with a BGP best path selected.
)
Figure 1-8 EBGP and IBGP Topology After Advertising Peering Links
Next-Hop Manipulation
Imagine a service provider network with 500 routers and every router containing 200 EBGP peering links. To ensure that the next-hop address is reachable to the IBGP peers requires the advertisement of 100,000 peering networks in BGP or an IGP consuming router resources.
Another technique to ensure that the next-hop address check passes without advertising peering networks into a routing protocol involves the modification of the next-hop address in the BGP advertisement. The next-hop IP address can be modified on inbound or outbound neighbor routing policies. Managing IP addresses in a route policy can be a complicated task. Configuring the next-hop-self address-family feature modifies the next-hop address in all external NLRIs using the IP address of the BGP neighbor.
The command neighbor ip-address next-hop-self [all] is used for each neighbor under the address-family configuration on IOS nodes, and the command next-hop-self is applied under the neighbor address-family configuration for IOS XR and NX-OS devices.
Figure 1-9 shows the topology and BGP routing table for all four routers. Notice that R2 and R3 advertised the EBGP routes to each other with the next-hop address as the BGP session IP address, allowing the NLRIs to pass the next-hop accessibility check.
)
Figure 1-9 EBGP and IBGP Topology with Next-Hop-Self