Description

A Border Gateway Protocol (BGP) session can be established only when the direct route and the BGP configuration are in the same routing-instance. In some cases, you can leak a direct route from one instance to another using RIB groups, but the route in the secondary routing-table cannot be used to establish BGP sessions.

In the example demonstrated in this article, routers Router-1 and Router-2 are directly connected, and are trying to establish EBGP single-hop session on directly connected interfaces. However, the session cannot be established because the direct route is not in the same routing-instance as BGP configuration.

This article provides more details and gives a workaround.

Symptoms

Topology

+---------------------------------------------+
|                                             |
|                        +------------------+ |
|                        |                  | |
|           Router-1     |    TEST_VR       | |
|                        |                  | |
|                        +------------------+ |
|                                             |
+-----------+---------------------------------+
            |et-0/0/0.0
            |
            |
            |
            |
            |et-0/0/0.0
 +----------+-----------+
 |                      |
 |                      |
 |       Router-2       |
 |                      |
 |                      |
 +----------------------+ 

From Router-1, the route to 10.10.10.1 is directly connected to Router-2.

root@Router-1> show route 10.10.10.1 table inet.0    

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.0/30      *[Direct/0] 15:54:58
                    >  via et-0/0/0.0

Router-1 leaks the direct route from the global instance to the routing-instance test-vr.

set routing-options interface-routes rib-group inet inet->vr
set routing-options rib-groups inet->vr import-rib inet.0
set routing-options rib-groups inet->vr import-rib test-vr.inet.0

Due to the configured route leak, Router-1 has the route in the routing-instance test-vr.

root@Router-1> show route 10.10.10.1 table test-vr.inet.0  

test-vr.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.0/30      *[Direct/0] 01:07:30
                    >  via et-0/0/0.0

Now take another look at the route in both tables. Pay attention to the primary/secondary flag.

root@Router-1> show route 10.10.10.1 detail                  

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
10.10.10.0/30 (1 entry, 0 announced)
        *Direct Preference: 0
                Next hop type: Interface, Next hop index: 0
                Address: 0xce31750
                Next-hop reference count: 2
                Next hop: via et-0/0/0.0, selected
                State: <Active Int>
                Age: 15:57:16 
                Validation State: unverified 
                Task: IF
                AS path: I 
                Secondary Tables: test-vr.inet.0

test-vr.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

10.10.10.0/30 (1 entry, 1 announced)
        *Direct Preference: 0
                Next hop type: Interface, Next hop index: 0
                Address: 0xce31750
                Next-hop reference count: 2
                Next hop: via et-0/0/0.0, selected
                State: <Secondary Active Int>
                Age: 1:07:53 
                Validation State: unverified 
                Task: IF
                Announcement bits (1): 0-KRT 
                AS path: I 
                Primary Routing Table inet.0

Now when Router-1 tries to establish a BGP session in the routing-instance test-vr:

root@Router-1> show configuration routing-instances test-vr 
instance-type virtual-router;
protocols {
    bgp {
        group ebgp {
            type external;
            local-address 10.10.10.2;
            peer-as 65001;
            local-as 65000;
            neighbor 10.10.10.1;
            }
        }
    }
}

The BGP session gets stuck in active status.

root@Router-1> show bgp summary 
Threading mode: BGP I/O
Groups: 1 Peers: 2 Down peers: 1
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.10.10.1            65001          0          0       0       0     1:10:20 Active

Logs show that there is no usable route to 10.10.10.1, we can also see the global instance is sending a Connection Rejected message since it is receiving BGP messages but there is no configured peer on the master instance. 

Mar  8 09:26:05  c22-31 rpd[2065]: task_connect: task BGP_65001_65000.10.10.10.1 addr 10.10.10.1+179: No route to host
Mar  8 09:26:37  c22-31 rpd[2065]: BGP_CONNECT_FAILED: bgp_connect_start: connect 10.10.10.1 (External AS 65001): No route to host
Mar  8 09:26:37  c22-31 rpd[2065]: task_connect: task BGP_65001_65000.10.10.10.1 addr 10.10.10.1+179: No route to host
Mar  8 09:27:16  c22-31 rpd[2065]: bgp_pp_recv:4659: NOTIFICATION sent to 10.10.10.1+65437 (proto): code 6 (Cease) subcode 5 (Connection Rejected), Reason: no group for 10.10.10.1+65437 (proto) from AS 65001 found (Unconfigured Peer) in master(et-0/0/0.0), dropping him

Solution

A BGP session can be established only when the direct route and the BGP configuration are in the same routing-instance.

The route/interface to establish a BGP session should be native to the routing-instance (Virtual-Router or VRF), not through any form of route leaking.

When you compare this with other protocols such as OSPF/ISIS, for OSPF/ISIS, you would need to include the interface in the routing-instance itself. The protocol adjacency cannot be established for a route in secondary routing-table.

As a workaround to establish a BGP session, you can use a tunneling mechanism. A GRE tunnel is used as an example here:

  1. Configure a GRE tunnel on Router-1 and configure BGP for the tunnel end point:

set interfaces gr-0/0/0 unit 0 tunnel source 10.10.10.2
set interfaces gr-0/0/0 unit 0 tunnel destination 10.10.10.1
set interfaces gr-0/0/0 unit 0 family inet address 192.168.100.2/30

Add the GRE interface to the routing-instance, and add the peer IP along with the local address of the GRE tunnel to use:

set routing-instances test-vr interface gr-0/0/0.0
set routing-instances test-vr protocols bgp group TEST neighbor 192.168.100.1 local-address 192.168.100.2

Depending on your platform, configuring tunnel-services might be needed, for more information, please refer to tunnel-services (Chassis) | Junos OS | Juniper Networks :

set chassis fpc 0 pic 0 tunnel-services
  1. Configure a GRE tunnel on Router-2 and configure BGP for the tunnel end point:

set interfaces gr-0/0/0 unit 0 tunnel source 10.10.10.1
set interfaces gr-0/0/0 unit 0 tunnel destination 10.10.10.2
set interfaces gr-0/0/0 unit 0 family inet address 192.168.100.1/30

Depending on your platform, configuring tunnel-services might be needed, for more information, please refer to: tunnel-services (Chassis) | Junos OS | Juniper Networks :

set chassis fpc 0 pic 0 tunnel-services

Add the peer IP along with the local address of the GRE tunnel to use under BGP for Router-2:
set protocols bgp group ebgp neighbor 192.168.100.2 local-address 192.168.100.1

 

root@Router-1> show bgp summary 
Threading mode: BGP I/O
Groups: 1 Peers: 1 Down peers: 0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.100.1         65001        164        163       0       0     1:12:47 Establ
  test-vr.inet.0: 0/0/0/0

Modification History

2021-09-27: Added a workaround to establish a BGP session.
2022-03-08: Tested using QFXs, removed usage of LT interfaces and logical systems to simplify the configuration and topology.