EBGP Route Resolution to a Static Route
This chapter provides information about EBGP route resolution to a static route.
Topics in this chapter include:
Applicability
The CLI in the latest update of this chapter corresponds to SR Linux Release 26.7.3.
Overview
The configuration in this chapter resembles the configuration in chapter Inter-AS VPN Model C, but in this chapter, the EBGP peering between the ASBRs is using loopback addresses instead of interface addresses.
Typically, service providers use interface IP addresses in EBGP sessions toward an Autonomous System Border Router (ASBR) of an untrusted ISP, but it is possible to use loopback addresses, such as system IP addresses. This requires the ASBRs to provide visibility on each other's loopback address; for example, by defining static routes. EBGP route resolution to a static route only works for ASBRs that are directly connected. As an alternative, MPLS (for example, LDP) can be configured on the interfaces between the ASBRs, which is the only viable solution when the peering ASBRs are multiple hops away.
Configuring MPLS on the interface toward an ASBR of an untrusted ISP is considered insecure. For directly connected ASBRs, EBGP route resolution to a static route mitigates these security issues. On each ASBR, static routes are configured toward the loopback address of the peer ASBR. Additionally, the following command enables labeled routes to be resolved via a route when no tunnel is available:
network-instance default {
protocols {
bgp {
afi-safi ipv4-labeled-unicast {
admin-state enable
ipv4-labeled-unicast {
next-hop-resolution {
ipv4-next-hops {
route-resolution {
admin-state enable # fallback when no tunnel is found
}
Even with this feature enabled, the system first tries to resolve the BGP next-hop to a tunnel, such as an LDP LSP before the IP route table is attempted.
Configuration
Example topology shows the example topology with four routers in two different ASs. ASBR-2 and ASBR-3 are connected via two links, which implies that there are multiple next-hops configured for the static route entry toward the loopback IP address of the EBGP peer. Also, BGP multipath is enabled between these ASBRs.
The initial configuration on the nodes includes the following:
-
IS-IS as IGP on the interfaces within an AS
-
LDP on the interfaces within an AS
BGP peering shows the BGP sessions to be configured:
-
IBGP sessions for the ipv4-labeled-unicast address family between the PEs within each AS
-
EBGP sessions for the ipv4-labeled-unicast address family between ASBR-2 and ASBR-3
-
a multi-hop EBGP session for the l3vpn-ipv4-unicast address family between PE-1 and PE-4
On PE-1, IBGP is configured for the ipv4-labeled-unicast address family, as follows. The configuration on PE-4 is similar.
# on PE-1:
enter candidate
network-instance default {
protocols {
bgp {
admin-state enable
autonomous-system 64501
router-id 192.0.2.1
bgp-label {
labeled-unicast {
dynamic-label-block dlb-bgp-lu
}
}
afi-safi ipv4-labeled-unicast {
admin-state enable
ipv4-labeled-unicast {
next-hop-resolution {
ipv4-next-hops {
tunnel-resolution {
allowed-tunnel-types [
ldp
]
}
}
}
}
}
group grp-IBGP {
admin-state enable
peer-as 64501
export-policy [
rp-export-bgp
]
}
neighbor 192.0.2.2 {
peer-group grp-IBGP
}
}The following export policy exports the loopback IP address from PE-1 to ASBR-2. A similar export policy exports the loopback IP address from PE-4 to ASBR-3.
# on PE-1, PE-4:
enter candidate
routing-policy {
community-set cs-1-0 { # on PE-4: cs-4-0
member [
1:0 # on PE-4: 4:0
]
}
prefix-set ps-pe-sys {
prefix 192.0.2.0/28 mask-length-range 32..32 {
}
}
policy rp-export-bgp {
statement export-local-sys-with-comm-1-0 { # on PE-4: export-local-sys-with-comm-4-0
match {
protocol local
prefix {
prefix-set ps-pe-sys
}
}
action {
policy-result accept
bgp {
communities {
add cs-1-0 # on PE-4: cs-4-0
}
}
}
}
}On ASBR-2, IBGP and EBGP are configured for the ipv4-labeled-unicast address family, as follows. Two links are connecting ASBR-2 to ASBR-3 and, therefore, BGP multipath is enabled. For more information, see the BGP Multipath chapter. The BGP configuration on ASBR-3 is similar.
# on ASBR-2:
enter candidate
routing-policy {
community-set cs-1-0 {
member [
1:0
]
}
community-set cs-4-0 {
member [
4:0
]
}
policy rp-comm-1:0 {
statement accept-comm-1-0 {
match {
bgp {
community-set cs-1-0
}
}
action {
policy-result accept
}
}
}
policy rp-comm-4:0 {
statement accept-comm-4-0 {
match {
bgp {
community-set cs-4-0
}
}
action {
policy-result accept
}
}
}
}
network-instance default {
protocols {
bgp {
admin-state enable
autonomous-system 64501 # on ASBR-3: 64504
router-id 192.0.2.2 # on ASBR-3: 192.0.2.3
bgp-label {
labeled-unicast {
dynamic-label-block dlb-bgp-lu
}
}
best-path-selection {
advertise-inactive true # to advertise system IP@ of PE-1 to ASBR-3
}
afi-safi ipv4-labeled-unicast {
admin-state enable
multipath {
ebgp {
maximum-paths 2
}
ibgp {
maximum-paths 2
}
}
ipv4-labeled-unicast {
next-hop-resolution {
ipv4-next-hops {
route-resolution {
admin-state disable # No fallback when no tunnel is found
}
tunnel-resolution {
allowed-tunnel-types [
ldp
]
}
}
}
}
}
group grp-EBGP {
peer-as 64504 # on ASBR-3: 64501
export-policy [
rp-comm-1:0 # on ASBR-3: rp-comm-4:0
]
import-policy [
rp-comm-4:0 # on ASBR-3: rp-comm-1:0
]
}
group grp-IBGP {
peer-as 64501 # on ASBR-3: 64504
}
neighbor 192.0.2.1 { # on ASBR-3: 192.0.2.4
peer-group grp-IBGP
}
neighbor 192.0.2.3 { # on ASBR-3: 192.0.2.2
peer-group grp-EBGP
transport {
local-address 192.0.2.2 # loopback ; on ASBR-3: 192.0.2.3
}
multihop {
admin-state enable
maximum-hops 2 # SR Linux sends EBGP packets with TTL=1
}
}
}On EBGP sessions, routes are by default rejected unless import and export policies are defined (RFC 8212).
On the ASBRs, the BGP routes with the loopback IP addresses of the local AS PEs are not active because IGP routes are preferred. The advertise-inactive true option ensures that the ASBRs also advertise these inactive routes to each other. ASBR-2 advertises prefix 192.0.2.1/32 to ASBR-3; ASBR-3 advertises prefix 192.0.2.4/32 to ASBR-2.
However, no prefixes can be exchanged between the ASBRs because the EBGP session is not in the established state yet; they still lack routing to each other's loopback IP address.
Eventually, the labeled IPv4 routes for prefixes PE-1 and PE-4 will be exchanged between ASBRs and forwarded to the PEs in the peer AS. PE-1 will have a route toward PE-4 in its routing table, and PE-4 will have a route toward PE-1. Both PEs can then set up a multi-hop EBGP session to each other for the l3vpn-ipv4-unicast address family; for example, on PE-1, as follows:
# on PE-1:
enter candidate
network-instance default {
protocols {
bgp {
group grp-EBGP-multihop {
peer-as 64504 # on PE-4: 64501
transport {
local-address 192.0.2.1 # on PE-4: 192.0.2.4
}
multihop {
admin-state enable
maximum-hops 10
}
afi-safi l3vpn-ipv4-unicast {
admin-state enable
export-policy [
rp-vrf1-export
]
import-policy [
rp-vrf1-import-from-pe4 # on PE-4: rp-vrf1-import-from-pe1
]
}
afi-safi ipv4-labeled-unicast {
admin-state disable # do not inherit from global BGP context
}
}
neighbor 192.0.2.4 { # on PE-4: 192.0.2.1
peer-group grp-EBGP-multihop
}
}For EBGP, by default, export and import policies are required. To ensure that PE-1 and PE-4 can advertise routes to and receive routes from their EBGP peer, the following policies are defined:
# on PE-1: # similar policies on PE-4
enter candidate
routing-policy {
prefix-set ps-vrf1-pe1 { # on PE-4: ps-vrf1-pe4
prefix 10.1.1.1/32 mask-length-range exact { # on PE-4: 10.4.4.4/32
}
}
extended-community-set ecs-vrf1-pe1 {
member [
target:64501:1
]
}
extended-community-set ecs-vrf1-pe4 {
member [
target:64504:1
]
}
policy rp-vrf1-export {
default-action {
policy-result reject
}
statement export-pe1-loopback { # on PE-4: export-pe4-loopback
match {
prefix {
prefix-set ps-vrf1-pe1 # on PE-4: ps-vrf1-pe4
}
}
action {
policy-result accept
bgp {
extended-community {
operation add
referenced-sets [
ecs-vrf1-pe1 # on PE-4: ecs-vrf1-pe4
]
}
}
}
}
}
policy rp-vrf1-import-from-pe4 { # on PE-4: rp-vrf1-import-from-pe1
default-action {
policy-result reject
}
statement import-target:64504:1 { # on PE-4: import-target:64501:1
match {
bgp {
extended-community {
extended-community-set ecs-vrf1-pe4 # on PE-4: ecs-vrf1-pe1
}
}
}
action {
policy-result accept
}
}
}
}On PE-1, VRF 1 is configured with loopback address 10.1.1.1/32, as follows:
# on PE-1:
enter candidate
network-instance VRF1 {
type ip-vrf
admin-state enable
interface lo0-10.1.1.1 { # on PE-4: lo0-10.4.4.4
interface-ref {
interface lo0
subinterface 0
}
}
protocols {
bgp-ipvpn {
bgp-instance 1 {
admin-state enable
encapsulation-type mpls
mpls {
next-hop-resolution {
allowed-tunnel-types [
bgp
]
}
}
}
}
bgp-vpn {
bgp-instance 1 {
route-distinguisher {
rd 64501:1 # on PE-4: rd 64504:1
}
route-target {
import-rt target:64504:1 # on PE-4: target:64501:1
export-rt target:64501:1 # on PE-4: target:64504:1
}
}
}
}The configuration of PE-4 resembles the configuration of PE-1, whereas the configuration of ASBR-3 resembles that of ASBR-2.
This configuration is almost identical to the configuration in chapter Inter-AS VPN Model C, with the difference that the EBGP session between the ASBRs does not use interface IP addresses, but loopback addresses. The problem is that the ASBRs cannot reach each other's loopback IP address, so the EBGP session between the ASBRs cannot be established, which can be verified in the BGP summary, as follows:
--{ + running }--[ ]--
A:admin@ASBR-2# show / network-instance default protocols bgp neighbor
----------------------------------------------------------------------------------------------------------------------------------------------------------------
BGP neighbor summary for network-instance "default"
Peer flags: see legend after the summary when applicable.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------------------------------
+------------------+--------------------------+------------------+------+----------+--------------+--------------+-------------------------------------+
| Net-Inst | Peer | Group | Flag | Peer-AS | State | Uptime | AFI/SAFI [Rx/Active/Tx] |
| | | | s | | | | |
+==================+==========================+==================+======+==========+==============+==============+=====================================+
| default | 192.0.2.1 | grp-IBGP | S | 64501 | established | 0d:0h:1m:26s | ipv4-labeled-unicast [1/0/0] |
| default | 192.0.2.3 | grp-EBGP | S | 64504 | connect | - | |
+------------------+--------------------------+------------------+------+----------+--------------+--------------+-------------------------------------+
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Summary:
2 configured neighbors, 1 configured sessions are established, 0 disabled peers
0 dynamic peers
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Peer flag legend:
S Static neighbor
The state of the BGP session toggles between Active and Connect. The last event is an openFail, as follows:
--{ + running }--[ ]--
A:admin@ASBR-2# show / network-instance default protocols bgp neighbor 192.0.2.3 detail | grep Admin-state --before-context 10 --after-context 9
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Peer : 192.0.2.3, remote AS: 64504, local AS: 64501, peer-type : ebgp
Type : static
Description : None
Group : grp-EBGP
Export policies : ['rp-comm-1:0']
Import policies: ['rp-comm-4:0']
Under maintenance: False
Maintenance group:
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Admin-state is enable, session-state is connect, up for N/A
TCP connection is 192.0.2.2 [0] -> 192.0.2.3 [0]
TCP-MD5 authentication is disabled
0 messages in input queue, 0 messages in output queue
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Last-state was active, last-event was openFail, 0 peer-flaps
Last establish exit event: N/A
Last received Notification was Error: None SubError: None
Failure detection: BFD is False, fast-failover is True
----------------------------------------------------------------------------------------------------------------------------------------------------------------
When the EBGP session between the ASBRs is not established, no IP prefixes are learned from the peer AS. This implies that PE-1 does not have a route toward PE-4 in its routing table. Therefore, no multi-hop EBGP session can be established between PE-1 and PE-4, which can be shown as follows:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default ipv4 route
========================================================================================
IPv4-unicast route table for default network-instance
----------------------------------------------------------------------------------------
Flags: > (best), * (unviable), ! (failed)
: L (leaked route from another network-instance)
: B (backup NHG active and displayed)
: S (statistics supported)
: D (dynamic LB), R (resilient LB)
----------------------------------------------------------------------------------------
Prefix Route Type Metric Pref Flags Next-Hop(s)
----------------------------------------------------------------------------------------
192.0.2.2/32 isis 10 18 > 192.168.12.2(ethernet-1/2.0)
192.168.12.0/30 local 0 0 > 192.168.12.1(ethernet-1/2.0)
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default protocols bgp neighbor
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
BGP neighbor summary for network-instance "default"
Peer flags: see legend after the summary when applicable.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+-------------------+---------------------------+-------------------+-------+----------+---------------+---------------+----------------------------------------+
| Net-Inst | Peer | Group | Flags | Peer-AS | State | Uptime | AFI/SAFI [Rx/Active/Tx] |
+===================+===========================+===================+=======+==========+===============+===============+========================================+
| default | 192.0.2.2 | grp-IBGP | S | 64501 | established | 0d:0h:3m:59s | ipv4-labeled-unicast [0/0/1] |
| default | 192.0.2.4 | grp-EBGP-multihop | S | 64504 | connect | - | |
+-------------------+---------------------------+-------------------+-------+----------+---------------+---------------+----------------------------------------+
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Summary:
2 configured neighbors, 1 configured sessions are established, 0 disabled peers
0 dynamic peers
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Peer flag legend:
S Static neighbor
The state of the multi-hop EBGP session toggles between Active and Connect. The last event is openFail, as follows:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default protocols bgp neighbor 192.0.2.4 detail | grep Admin-state --before-context 10 --after-context 9
----------------------------------------------------------------------------------------------------------------------------------------------
Peer : 192.0.2.4, remote AS: 64504, local AS: 64501, peer-type : ebgp
Type : static
Description : None
Group : grp-EBGP-multihop
Export policies : []
Import policies: []
Under maintenance: False
Maintenance group:
----------------------------------------------------------------------------------------------------------------------------------------------
Admin-state is enable, session-state is connect, up for N/A
TCP connection is 192.0.2.1 [0] -> 192.0.2.4 [0]
TCP-MD5 authentication is disabled
0 messages in input queue, 0 messages in output queue
----------------------------------------------------------------------------------------------------------------------------------------------
Last-state was active, last-event was openFail, 0 peer-flaps
Last establish exit event: N/A
Last received Notification was Error: None SubError: None
Failure detection: BFD is False, fast-failover is True
----------------------------------------------------------------------------------------------------------------------------------------------
The loopback IP addresses of the ASBRs can be made reachable by configuring static routes on each ASBR to the loopback IP address of the peer ASBR. This is sufficient to establish the EBGP session between the ASBRs, but no BGP labeled IPv4 routes can be advertised to PE-1 and PE-4 yet. ASBR-2 and ASBR-3 are connected by two links and the static route entry contains two next-hops; for example, for ASBR-2, as follows. The configuration is similar for ASBR-3.
# on ASBR-2:
enter candidate
network-instance default {
static-routes {
route 192.0.2.3/32 {
static-next-hop-group NHG-192.0.2.3
}
}
static {
next-hop 1 {
ip-address 192.168.23.2
}
next-hop 2 {
ip-address 192.168.23.6
}
next-hop-group NHG-192.0.2.3 {
next-hop 1 {
}
next-hop 2 {
}
}
}The routing table in ASBR-2 contains two routes toward ASBR-3, as follows:
--{ + running }--[ ]--
A:admin@ASBR-2# show / network-instance default ipv4 route 192.0.2.3/32
=======================================================================================
IPv4-unicast route table for default network-instance
---------------------------------------------------------------------------------------
Flags: > (best), * (unviable), ! (failed)
: L (leaked route from another network-instance)
: B (backup NHG active and displayed)
: S (statistics supported)
: D (dynamic LB), R (resilient LB)
---------------------------------------------------------------------------------------
Prefix Route Type Metric Pref Flags Next-Hop(s)
---------------------------------------------------------------------------------------
192.0.2.3/32 static 1 5 > 192.168.23.6(route:local)
192.168.23.2(route:local)
The EBGP session between the ASBRs is established; for example, on ASBR-2, as follows:
--{ + running }--[ ]--
A:admin@ASBR-2# show / network-instance default protocols bgp neighbor
------------------------------------------------------------------------------------------------------------------------------------------------------------
BGP neighbor summary for network-instance "default"
Peer flags: see legend after the summary when applicable.
------------------------------------------------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------------------------------------------
+-----------------+-------------------------+-----------------+------+---------+--------------+--------------+------------------------------------+
| Net-Inst | Peer | Group | Flag | Peer-AS | State | Uptime | AFI/SAFI [Rx/Active/Tx] |
| | | | s | | | | |
+=================+=========================+=================+======+=========+==============+==============+====================================+
| default | 192.0.2.1 | grp-IBGP | S | 64501 | established | 0d:0h:6m:45s | ipv4-labeled-unicast [1/0/0] |
| default | 192.0.2.3 | grp-EBGP | S | 64504 | established | 0d:0h:0m:44s | ipv4-labeled-unicast [1/0/1] |
+-----------------+-------------------------+-----------------+------+---------+--------------+--------------+------------------------------------+
------------------------------------------------------------------------------------------------------------------------------------------------------------
Summary:
2 configured neighbors, 2 configured sessions are established, 0 disabled peers
0 dynamic peers
------------------------------------------------------------------------------------------------------------------------------------------------------------
Peer flag legend:
S Static neighbor
Even though ASBR-2 receives a BGP-LU route for prefix 192.0.2.4/32 from ASBR-3, the route is not active because the BGP-LU route cannot be resolved to a tunnel and the fallback to route-resolution. ASBR-2 does not advertise the route to PE-1 and the multi-hop EBGP session between PE-1 and PE-4 cannot be established yet. The state of the multi-hop EBGP session toggles between active and connect and the following output from PE-1 shows that the last event was openFail:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default protocols bgp neighbor 192.0.2.4 detail | grep Admin-state --before-context 10 --after-context 9
----------------------------------------------------------------------------------------------------------------------------------------------
Peer : 192.0.2.4, remote AS: 64504, local AS: 64501, peer-type : ebgp
Type : static
Description : None
Group : grp-EBGP-multihop
Export policies : []
Import policies: []
Under maintenance: False
Maintenance group:
----------------------------------------------------------------------------------------------------------------------------------------------
Admin-state is enable, session-state is connect, up for N/A
TCP connection is 192.0.2.1 [0] -> 192.0.2.4 [0]
TCP-MD5 authentication is disabled
0 messages in input queue, 0 messages in output queue
----------------------------------------------------------------------------------------------------------------------------------------------
Last-state was active, last-event was openFail, 0 peer-flaps
Last establish exit event: N/A
Last received Notification was Error: None SubError: None
Failure detection: BFD is False, fast-failover is True
----------------------------------------------------------------------------------------------------------------------------------------------
ASBR-2 advertised an inactive route for prefix 192.0.2.1/32 to ASBR-3 and received from ASBR-3 a route for prefix 192.0.2.4/32. The following output shows that the route for prefix 192.0.2.4/32 is not valid on ASBR-2:
--{ + running }--[ ]--
A:admin@ASBR-2# show / network-instance default protocols bgp routes ipv4-labeled-unicast summary | grep -v 0.0.0.0 | grep -v 192.168
------------------------------------------------------------------------------------------------------------------------------------------------------
Show report for the BGP route table of network-instance "default"
------------------------------------------------------------------------------------------------------------------------------------------------------
Status codes: u=used, *=valid, >=best, x=stale, b=backup, w=unused-weight-only
Origin codes: i=IGP, e=EGP, ?=incomplete
------------------------------------------------------------------------------------------------------------------------------------------------------
+--------+-----------------------------------+-----------------------------------+--------+--------+------------------------------------------------+
| Status | Network | Next Hop | MED | LocPre | Path Val |
| | | | | f | |
+========+===================================+===================================+========+========+================================================+
| * | 192.0.2.1/32 | 192.0.2.1 | | 100 | i |
| | 192.0.2.4/32 | 192.0.2.3 | | | i[64504] |
+--------+-----------------------------------+-----------------------------------+--------+--------+------------------------------------------------+
------------------------------------------------------------------------------------------------------------------------------------------------------
---snip---
Consequently, ASBR-2 does not advertise this invalid route to its IBGP peer PE-1 and PE-1 does not have a route toward PE-4 in its routing table, as follows:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default ipv4 route
=========================================================================================
IPv4-unicast route table for default network-instance
-----------------------------------------------------------------------------------------
Flags: > (best), * (unviable), ! (failed)
: L (leaked route from another network-instance)
: B (backup NHG active and displayed)
: S (statistics supported)
: D (dynamic LB), R (resilient LB)
-----------------------------------------------------------------------------------------
Prefix Route Type Metric Pref Flags Next-Hop(s)
-----------------------------------------------------------------------------------------
192.0.2.2/32 isis 10 18 > 192.168.12.2(ethernet-1/2.0)
192.168.12.0/30 local 0 0 > 192.168.12.1(ethernet-1/2.0)
PE-1 and PE-4 cannot set up a multi-hop EBGP session to one another to exchange routes for VRF 1. This problem can be solved in two different ways:
-
Enable MPLS (in this example, LDP) on the interfaces between the ASBRs.
-
Enable the route-resolution fallback option.
It is risky to enable MPLS toward a peer ASBR belonging to an untrusted ISP, but it is required between distant ASBRs if loopback addresses are used in EBGP peering.
In the following section, the first solution is described (LDP is enabled on the interfaces between the ASBRs); the section after that describes how to allow EBGP route resolution as a fallback in case no tunnels are found.
Enable LDP toward peer ASBR
LDP is configured on the interfaces between the ASBRs; for example, on ASBR-2, as follows. The configuration is similar on ASBR-3.
# on ASBR-2:
enter candidate
network-instance default {
protocols {
ldp {
discovery {
interfaces {
interface ethernet-1/3.0 {
ipv4 {
admin-state enable
}
}
interface ethernet-1/13.0 {
ipv4 {
admin-state enable
}
}
}
}ASBR-2 now has a valid, best, and used route for prefix 192.0.2.4/32, as follows:
--{ + running }--[ ]--
A:admin@ASBR-2# show / network-instance default protocols bgp routes ipv4-labeled-unicast summary | grep -v 0.0.0.0 | grep -v 192.168
---------------------------------------------------------------------------------------------------------------
Show report for the BGP route table of network-instance "default"
---------------------------------------------------------------------------------------------------------------
Status codes: u=used, *=valid, >=best, x=stale, b=backup, w=unused-weight-only
Origin codes: i=IGP, e=EGP, ?=incomplete
---------------------------------------------------------------------------------------------------------------
+------+-------------------------+-------------------------+------+------+----------------------------------+
| Stat | Network | Next Hop | MED | LocP | Path Val |
| us | | | | ref | |
+======+=========================+=========================+======+======+==================================+
| * | 192.0.2.1/32 | 192.0.2.1 | | 100 | i |
| u*> | 192.0.2.4/32 | 192.0.2.3 | | | i[64504] |
+------+-------------------------+-------------------------+------+------+----------------------------------+
---snip---
PE-1 has a valid route for prefix 192.0.2.4/32, as follows:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default protocols bgp routes ipv4-labeled-unicast summary | grep -v 0.0.0.0 | grep -v 192.168
---------------------------------------------------------------------------------------------------------------
Show report for the BGP route table of network-instance "default"
---------------------------------------------------------------------------------------------------------------
Status codes: u=used, *=valid, >=best, x=stale, b=backup, w=unused-weight-only
Origin codes: i=IGP, e=EGP, ?=incomplete
---------------------------------------------------------------------------------------------------------------
+------+-------------------------+-------------------------+------+------+----------------------------------+
| Stat | Network | Next Hop | MED | LocP | Path Val |
| us | | | | ref | |
+======+=========================+=========================+======+======+==================================+
| u*> | 192.0.2.4/32 | 192.0.2.2 | | 100 | i[64504] |
+------+-------------------------+-------------------------+------+------+----------------------------------+
---------------------------------------------------------------------------------------------------------------
4 received BGP routes: 4 used, 4 valid, 0 stale
4 available destinations: 0 with ECMP multipaths
---------------------------------------------------------------------------------------------------------------
The following routing table shows that PE-1 has a BGP labeled route toward PE-4:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default ipv4 route
===============================================================================================================
IPv4-unicast route table for default network-instance
---------------------------------------------------------------------------------------------------------------
Flags: > (best), * (unviable), ! (failed)
: L (leaked route from another network-instance)
: B (backup NHG active and displayed)
: S (statistics supported)
: D (dynamic LB), R (resilient LB)
---------------------------------------------------------------------------------------------------------------
Prefix Route Type Metric Pref Flags Next-Hop(s)
---------------------------------------------------------------------------------------------------------------
192.0.2.2/32 isis 10 18 > 192.168.12.2(ethernet-1/2.0)
192.0.2.4/32 bgp-label 10 170 > mpls(192.0.2.2/32, ldp:65537, label:30002)
192.168.12.0/30 local 0 0 > 192.168.12.1(ethernet-1/2.0)
A multi-hop EBGP session is established for address family VPN-IPv4 between PE-1 and PE-4, as follows:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default protocols bgp neighbor
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
BGP neighbor summary for network-instance "default"
Peer flags: see legend after the summary when applicable.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+-------------------+---------------------------+-------------------+-------+----------+---------------+---------------+---------------------------------------+
| Net-Inst | Peer | Group | Flags | Peer-AS | State | Uptime | AFI/SAFI [Rx/Active/Tx] |
+===================+===========================+===================+=======+==========+===============+===============+=======================================+
| default | 192.0.2.2 | grp-IBGP | S | 64501 | established | 0d:0h:14m:28s | ipv4-labeled-unicast [1/1/1] |
| default | 192.0.2.4 | grp-EBGP-multihop | S | 64504 | established | 0d:0h:3m:19s | l3vpn-ipv4-unicast [1/1/1] |
+-------------------+---------------------------+-------------------+-------+----------+---------------+---------------+---------------------------------------+
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Summary:
2 configured neighbors, 2 configured sessions are established, 0 disabled peers
0 dynamic peers
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Peer flag legend:
S Static neighbor
The loopback address defined in VRF 1 on PE-4 (10.4.4.4/32) is advertised as VPN-IPv4 route in this multi-hop EBGP session on PE-1, as follows:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default protocols bgp routes l3vpn-ipv4-unicast summary | grep -v 0.0.0.0
---------------------------------------------------------------------------------------------------------------
Show report for the BGP route table of network-instance "default"
---------------------------------------------------------------------------------------------------------------
Status codes: u=used, *=valid, >=best, x=stale, b=backup, w=unused-weight-only
Origin codes: i=IGP, e=EGP, ?=incomplete
---------------------------------------------------------------------------------------------------------------
+--------------+--------------+--------------+--------------+--------------+--------------+--------------+
| Status | Route Distin | Network | Next Hop | MED | LocPref | Path Val |
| | guisher | | | | | |
+==============+==============+==============+==============+==============+==============+==============+
| u*> | 64504:1 | 10.4.4.4/32 | 192.0.2.4 | | | i[64504] |
+--------------+--------------+--------------+--------------+--------------+--------------+--------------+
---------------------------------------------------------------------------------------------------------------
2 received BGP routes: 2 used, 2 valid, 0 stale
2 available destinations: 0 with ECMP multipaths
---------------------------------------------------------------------------------------------------------------
The routing table for VRF 1 on PE-1 includes a BGP-VPN route to PE-4, as follows:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance VRF1 ipv4 route
==================================================================================================
IPv4-unicast route table for ip-vrf network-instance: VRF1
--------------------------------------------------------------------------------------------------
Flags: > (best), * (unviable), ! (failed)
: L (leaked route from another network-instance)
: B (backup NHG active and displayed)
: S (statistics supported)
: D (dynamic LB), R (resilient LB)
--------------------------------------------------------------------------------------------------
Prefix Route Type Metric Pref Flags Next-Hop(s)
--------------------------------------------------------------------------------------------------
10.4.4.4/32 bgp-ipvpn 1000 170 > 192.0.2.4(tunnel:bgp, label:40000)
To restore the configuration, LDP is disabled on the interfaces between the ASBRs, as follows for ASBR-2. The configuration is similar on ASBR-3.
# on ASBR-2:
enter candidate
network-instance default {
protocols {
ldp {
discovery {
interfaces {
delete interface ethernet-1/3.0
delete interface ethernet-1/13.0
}
}EBGP route resolution to a static route
The static routes are already configured on both ASBRs and the EBGP session between the ASBRs is established.
BGP-LU route resolution needs to be enabled on ASBR-2 and ASBR-3 using the following command:
# on ASBR-2, ASBR-3:
enter candidate
network-instance default {
protocols {
bgp {
afi-safi ipv4-labeled-unicast {
ipv4-labeled-unicast {
next-hop-resolution {
ipv4-next-hops {
route-resolution {
admin-state enable
ignore-default-routes true # prevents resolution through 0.0.0.0
}
}
}
}On ASBR-2, the labeled IPv4 route for prefix 192.0.2.4/32 is now valid, best, and used, as follows:
--{ + running }--[ ]--
A:admin@ASBR-2# show / network-instance default protocols bgp routes ipv4-labeled-unicast summary | grep -v 0.0.0.0 | grep -v 192.168
-----------------------------------------------------------------------------------------------------------------------
Show report for the BGP route table of network-instance "default"
-----------------------------------------------------------------------------------------------------------------------
Status codes: u=used, *=valid, >=best, x=stale, b=backup, w=unused-weight-only
Origin codes: i=IGP, e=EGP, ?=incomplete
-----------------------------------------------------------------------------------------------------------------------
+------+---------------------------+---------------------------+------+------+--------------------------------------+
| Stat | Network | Next Hop | MED | LocP | Path Val |
| us | | | | ref | |
+======+===========================+===========================+======+======+======================================+
| * | 192.0.2.1/32 | 192.0.2.1 | | 100 | i |
| u*> | 192.0.2.4/32 | 192.0.2.3 | | | i[64504] |
+------+---------------------------+---------------------------+------+------+--------------------------------------+
-----------------------------------------------------------------------------------------------------------------------
---snip---
PE-1 learns the following BGP labeled IPv4 route for prefix 192.0.2.4/32 from ASBR-2:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default protocols bgp routes ipv4-labeled-unicast summary | grep -v 0.0.0.0 | grep -v 192.168
-----------------------------------------------------------------------------------------------------------------------
Show report for the BGP route table of network-instance "default"
-----------------------------------------------------------------------------------------------------------------------
Status codes: u=used, *=valid, >=best, x=stale, b=backup, w=unused-weight-only
Origin codes: i=IGP, e=EGP, ?=incomplete
-----------------------------------------------------------------------------------------------------------------------
+------+---------------------------+---------------------------+------+------+--------------------------------------+
| Stat | Network | Next Hop | MED | LocP | Path Val |
| us | | | | ref | |
+======+===========================+===========================+======+======+======================================+
| u*> | 192.0.2.4/32 | 192.0.2.2 | | 100 | i[64504] |
+------+---------------------------+---------------------------+------+------+--------------------------------------+
-----------------------------------------------------------------------------------------------------------------------
4 received BGP routes: 4 used, 4 valid, 0 stale
4 available destinations: 0 with ECMP multipaths
-----------------------------------------------------------------------------------------------------------------------
The routing table on PE-1 contains a BGP labeled IPv4 route to 192.0.2.4/32:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default ipv4 route
================================================================================================================
IPv4-unicast route table for default network-instance
----------------------------------------------------------------------------------------------------------------
Flags: > (best), * (unviable), ! (failed)
: L (leaked route from another network-instance)
: B (backup NHG active and displayed)
: S (statistics supported)
: D (dynamic LB), R (resilient LB)
----------------------------------------------------------------------------------------------------------------
Prefix Route Type Metric Pref Flags Next-Hop(s)
----------------------------------------------------------------------------------------------------------------
192.0.2.2/32 isis 10 18 > 192.168.12.2(ethernet-1/2.0)
192.0.2.4/32 bgp-label 10 170 > mpls(192.0.2.2/32, ldp:65537, label:30003)
192.168.12.0/30 local 0 0 > 192.168.12.1(ethernet-1/2.0)
The multi-hop EBGP session between PE-1 in AS 64501 and PE-4 in AS 64504 is established, as follows:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default protocols bgp neighbor
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
BGP neighbor summary for network-instance "default"
Peer flags: see legend after the summary when applicable.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
+------------------+--------------------------+------------------+------+----------+---------------+---------------+--------------------------------------+
| Net-Inst | Peer | Group | Flag | Peer-AS | State | Uptime | AFI/SAFI [Rx/Active/Tx] |
| | | | s | | | | |
+==================+==========================+==================+======+==========+===============+===============+======================================+
| default | 192.0.2.2 | grp-IBGP | S | 64501 | established | 0d:0h:23m:10s | ipv4-labeled-unicast [1/1/1] |
| default | 192.0.2.4 | grp-EBGP- | S | 64504 | established | 0d:0h:12m:1s | l3vpn-ipv4-unicast [1/1/1] |
| | | multihop | | | | | |
+------------------+--------------------------+------------------+------+----------+---------------+---------------+--------------------------------------+
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Summary:
2 configured neighbors, 2 configured sessions are established, 0 disabled peers
0 dynamic peers
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Peer flag legend:
S Static neighborThe loopback address defined in VRF 1 on PE-4 (10.4.4.4/32) is advertised as VPN-IPv4 route in this multi-hop EBGP session on PE-1, as follows:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance default protocols bgp routes l3vpn-ipv4-unicast summary | grep -v 0.0.0.0
----------------------------------------------------------------------------------------------------------------
Show report for the BGP route table of network-instance "default"
----------------------------------------------------------------------------------------------------------------
Status codes: u=used, *=valid, >=best, x=stale, b=backup, w=unused-weight-only
Origin codes: i=IGP, e=EGP, ?=incomplete
----------------------------------------------------------------------------------------------------------------
+--------------+--------------+--------------+--------------+--------------+--------------+--------------+
| Status | Route Distin | Network | Next Hop | MED | LocPref | Path Val |
| | guisher | | | | | |
+==============+==============+==============+==============+==============+==============+==============+
| u*> | 64504:1 | 10.4.4.4/32 | 192.0.2.4 | | | i[64504] |
+--------------+--------------+--------------+--------------+--------------+--------------+--------------+
----------------------------------------------------------------------------------------------------------------
2 received BGP routes: 2 used, 2 valid, 0 stale
2 available destinations: 0 with ECMP multipaths
----------------------------------------------------------------------------------------------------------------
The routing table for VRF 1 on PE-1 includes the following BGP-VPN route to 10.4.4.4/32:
--{ + running }--[ ]--
A:admin@PE-1# show / network-instance VRF1 ipv4 route
================================================================================================================
IPv4-unicast route table for ip-vrf network-instance: VRF1
----------------------------------------------------------------------------------------------------------------
Flags: > (best), * (unviable), ! (failed)
: L (leaked route from another network-instance)
: B (backup NHG active and displayed)
: S (statistics supported)
: D (dynamic LB), R (resilient LB)
----------------------------------------------------------------------------------------------------------------
Prefix Route Type Metric Pref Flags Next-Hop(s)
----------------------------------------------------------------------------------------------------------------
10.4.4.4/32 bgp-ipvpn 1000 170 > 192.0.2.4(tunnel:bgp, label:40000)
The results are similar on PE-4 and PE-1, and on ASBR-3 and ASBR-2.
For directly connected ASBRs, inter-AS VPN model C can be configured using loopback addresses on the ASBRs without the need to enable MPLS between the ASBRs.
Conclusion
Most service providers use interface IP addresses in EBGP sessions, in which case this feature is not needed. However, some providers build directly connected EBGP sessions based on loopback interfaces. The loopback interface of the peer ASBR must be reachable and the labeled IPv4 routes for the remote AS PEs must be advertised to the local AS PEs. This advertisement can be achieved by configuring static routes on the ASBRs to the loopback address of their EBGP peer and enabling the EBGP route resolution to a static route. Enabling EBGP route resolution to a static route is much more secure than enabling MPLS on the interface to the peer ASBR of an untrusted ISP. However, when the ASBRs are distant and loopback addresses are used for the EBGP peering, MPLS must be enabled between the ASBRs.