BGP session can be established only when the direct route and the BGP configuration are in the same routing-instance. In some cases, via RIB-GROUPS, you can leak a direct route from one instance to another instance, but the route in the secondary routing-table cannot be used to establish BGP sessions.
In this example, R1 and R2 are directly connected, trying to establish EBGP single-hop session on directly connected interfaces.
Topology:
+---------------------------------------------+
| |
| +------------------+ |
| | | |
| R1 | TEST_VR | |
| | | |
| +------------------+ |
| |
+-----------+---------------------------------+
|lt-0/0/0.12
|
|
|
|
|lt-0/0/0.21
+----------+-----------+
| |
| |
| R2 |
| |
| |
+----------------------+
Route 12.0.0.2 is direct connected to R2 in R1 global instance
R1> show route 12.0.0.2 logical-system r1 table inet.0
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
12.0.0.0/30 *[Direct/0] 23:47:12
> via lt-0/0/0.12
R1 leaks direct route from global instance to routing-instance test-vr
set logical-systems r1 routing-options interface-routes rib-group inet inet->vr
set logical-systems r1 routing-options rib-groups inet->vr import-rib inet.0
set logical-systems r1 routing-options rib-groups inet->vr import-rib test-vr.inet.0
R1 has the route in routing-instance test-vr
R1> show route 12.0.0.2 logical-system r1 table test-vr.inet.0
test-vr.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
12.0.0.0/30 *[Direct/0] 23:42:02
> via lt-0/0/0.12
Take another look at the route in both tables. Pay attention to primary/secondary flag
R1> show route 12.0.0.2 logical-system r1 detail
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
12.0.0.0/30 (1 entry, 0 announced)
*Direct Preference: 0
Next hop type: Interface, Next hop index: 0
Address: 0x55f0850
Next-hop reference count: 2
Next hop: via lt-0/0/0.12, selected
State: <Active Int>
Age: 23:48:33
Validation State: unverified
Task: IF
AS path: I
Secondary Tables: test-vr.inet.0
test-vr.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
12.0.0.0/30 (1 entry, 1 announced)
*Direct Preference: 0
Next hop type: Interface, Next hop index: 0
Address: 0x55f0850
Next-hop reference count: 2
Next hop: via lt-0/0/0.12, selected
State: <Secondary Active Int>
Age: 23:42:31
Validation State: unverified
Task: IF
Announcement bits (1): 0-KRT
AS path: I
Primary Routing Table inet.0
Now R1 tries to establish BGP in routing-instance test-vr
R1#show configuration
routing-instances {
test-vr {
instance-type virtual-router;
protocols {
bgp {
group ebgp {
type external;
local-address 12.0.0.1;
peer-as 65001;
local-as 65000;
neighbor 12.0.0.2;
}
}
}
}
}
BGP will stuck in active status
R1> show bgp summary logical-system r1
Groups: 1 Peers: 1 Down peers: 1
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
12.0.0.2 65001 0 0 0 0 23:42:00 Active
Logs show no usable route to 12.0.0.2
Aug 22 07:20:05 tortellini r1:rpd[38831]: task_connect: task BGP_65001_65000.12.0.0.2+179 addr 12.0.0.2+179: No route to host
Aug 22 07:20:05 tortellini r1:rpd[38831]: BGP_CONNECT_FAILED: bgp_connect_start: connect 12.0.0.2 (External AS 65001): No route to host
Aug 22 07:20:08 tortellini r1:rpd[38831]: bgp_pp_recv:4624: NOTIFICATION sent to 12.0.0.2+65264 (proto): code 6 (Cease) subcode 5 (Connection Rejected), Reason: no group for 12.0.0.2+65264 (proto) from AS 65001 found (Unconfigured Peer) in master(lt-0/0/0.12), dropping him
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 BGP should be native to the routing-instance (Virtual-router or VRF), not via any form of route-leaking.
Taking other protocols like OSPF/ISIS as a comparison. For OSPF/ISIS, you need to include the interface in the routing-instance itself, protocol could not be established for a route in secondary routing-table.