Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[Junos] BGP session cannot establish with direct route that is not in same routing-instance as BGP configuration

0

0

Article ID: KB34981 KB Last Updated: 27 Sep 2021Version: 2.0
Summary:

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 instance via 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 R1 and R2 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 also gives a workaround.

Symptoms:

Topology

+---------------------------------------------+
|                                             |
|                        +------------------+ |
|                        |                  | |
|           R1           |    TEST_VR       | |
|                        |                  | |
|                        +------------------+ |
|                                             |
+-----------+---------------------------------+
            |lt-0/0/0.12
            |
            |
            |
            |
            |lt-0/0/0.21
 +----------+-----------+
 |                      |
 |                      |
 |          R2          |
 |                      |
 |                      |
 +----------------------+ 

Route 12.0.0.2 is directly connected to R2 in the 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 the direct route from the global instance to the 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 the 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

Now take another look at the route in both tables. Pay attention to the 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 when R1 tries to establish a BGP session in the 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;
                }
            }
        }
    }
}

The BGP session gets 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 that there is 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
Cause:

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

Solution:

The route/interface to establish a BGP session should be native to the routing-instance (Virtual-Router or VRF), not via 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 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 R1 and configure BGP for the tunnel end point.

set interfaces gr-0/0/0 unit 0 tunnel source 12.0.0.1
set interfaces gr-0/0/0 unit 0 tunnel destination 12.0.0.2
set interfaces gr-0/0/0 unit 0 family inet address 100.64.1.2/30
set chassis fpc 0 pic 0 tunnel-services
set routing-instances test-vr interface gr-0/0/0.0
set routing-instances test-vr  protocols bgp group TEST neighbor 100.64.1.1 local-address 100.64.1.2
  1. Configure a GRE tunnel on R2 and configure BGP for the tunnel end point:

set interfaces gr-0/0/0 unit 0 tunnel source 12.0.0.2
set interfaces gr-0/0/0 unit 0 tunnel destination 12.0.0.1
set interfaces gr-0/0/0 unit 0 family inet address 100.64.1.1/30
set chassis fpc 0 pic 0 tunnel-services

user@R1> show bgp summary instance test-vr
Jun 28 03:33:40
Threading mode: BGP I/O
Groups: 1 Peers: 2 Down peers: 1
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
100.64.1.1               11        137        137       0       0     1:01:26 Establ
  TEST.inet.0: 0/0/0/0
  TEST.inet6.0: 0/0/0/0
Modification History:

2021-09-27: Added a workaround to establish a BGP session

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search